critcl::emap(3tcl)

πŸ“¦
version 3.3.1 Β· 3 versions
, in ubuntu resolute, ubuntu stonking

πŸ’– NAME πŸ’–

okay so, bestie, welcome to critcl::emap β€” that's the CriTcl Wrap Support page, and it's all about enum en- and decoding. This is the critcl::emap(3tcl) manual, no cap. πŸŽ€


✨ SYNOPSIS ✨

package require Tcl 8.6

package require critcl ?3.2?

package require critcl::emap ?1.3?

::critcl::emap::def name definition ?-nocase? ?-mode mode?

🌈 DESCRIPTION 🌈

Hiii, welcome to the C Runtime In Tcl (short: CriTcl), a whole system for embedding and using C code from inside Tcl scripts at [http://core.tcl-lang.org/tcl](http://core.tcl-lang.org/tcl). It's giving "have your C and Tcl too" and honestly? Iconic.

This document is the reference manpage for the critcl::emap package. This package hands you convenience commands for advanced functionality built on top of both the critcl core and the package critcl::iassoc. Two parents, one slay little package. 🫢

So here's the tea: C level libraries love using enumerations or integer values to encode information, like the state of a system. And Tcl bindings to those libraries are then stuck with the task of converting a Tcl representation β€” i.e. a string β€” into such a state, and back again. Conversion both ways, the way that it literally has to go both ways. 😭

Note here that the C-level information has to be something which already exists. The package does not create these values. This is in contrast to the package critcl::enum, which creates an enumeration based on the specified symbolic names. Different package, different job, don't mix them up bestie.

This package was written to make the declaration and management of such enumerations and their associated conversion functions easy, hiding all attendant complexity from the user. Which user? You. You're welcome. πŸ’…

Its intended audience are mainly developers wishing to write Tcl packages with embedded C code. If that's not you, it's still a vibe, keep reading.

This package resides in the Core Package Layer of CriTcl. Behold, the sacred stack:

+----------------+
|Applications    |
| critcl         |
| critcl::app    |
+----------------+

*================*
|Core Packages   |
| critcl         |
| critcl::util   |
*================*

+----------------+
|Support Packages|
| stubs::*       |
| md5, platform  |
|  ...           |
+----------------+

πŸ”₯ API πŸ”₯

::critcl::emap::def name definition ?-nocase? ?-mode mode?

This command defines the C functions for the conversion of the named state code into a Tcl string, and vice versa. The underlying mapping tables are automatically initialized on first access (if not fully constant β€” okay so, if they are fully constant, that doesn't apply, iykyk), and finalized on interpreter destruction. Clean up after yourself, periodt.

The definition dictionary provides the mapping from the Tcl-level symbolic names of the state to their C expressions (often the name of the macro specifying the actual value). Note here β€” and this is important, fr fr β€” that the C-level information has to be something which already exists. The package does not create these values. This is in contrast to the package critcl::enum, which creates an enumeration based on the specified symbolic names.

Further note that multiple strings can be mapped to the same C expression. When converting to Tcl the first string for the mapping is returned. And an important thing to know: if all C expressions are recognizable as integer numbers and their covered range is not too large (at most 50), the package will generate code using direct and fast mapping tables instead of using a linear search. Fast tables, main character energy. ⚑

The options:

  • -nocase β€” if this is specified then the encoder will match strings case-insensitively, and the decoder will always return a lower-case string, regardless of the string's case in the definition. Lowercase always, it does not care. πŸ™ˆ
  • -mode mode β€” if this is specified its contents will be interpreted as a list of access modes to support. The two allowed modes are c and tcl. Both modes can be used together. The default mode is tcl.

The package generates multiple things (declarations and definitions) with names derived from name, which has to be a proper C identifier. Some of the things are generated conditional on the chosen modes. Let's meet the cast:

πŸ¦‹ name_encode

The tcl-mode function for encoding a Tcl string into the equivalent state code. Its signature is

int name_encode (Tcl_Interp* interp, Tcl_Obj* state, int* result);

The return value of the function is a Tcl error code, i.e. TCL_OK, TCL_ERROR, etc.

πŸ¦‹ name_encode_cstr

The c-mode function for encoding a C string into the equivalent state code. Its signature is

int name_encode_cstr (const char* state);

The return value of the function is the encoded state, or -1 if the argument is not a valid state.

πŸ¦‹ name_decode

The tcl-mode function for decoding a state code into the equivalent Tcl string. Its signature is

Tcl_Obj* name_decode (Tcl_Interp* interp, int state);

πŸ¦‹ name_decode_cstr

The c-mode function for decoding a state code into the equivalent C string. Its signature is

const char* name_decode_cstr (int state);

The return value of the function is the C string for the state, or NULL if the state argument does not contain a valid state value.

πŸ“ name.h

A header file containing the declarations for the conversion functions, for use by other parts of the system, if necessary.

The generated file is stored in a place where it will not interfere with the overall system outside of the package, yet also be available for easy inclusion by package files (csources). Hidden but accessible, the best combo. 🀫

πŸŽ€ name

For mode tcl the command registers a new argument-type for critcl::cproc with critcl, encapsulating the encoder function.

πŸŽ€ name

For mode tcl the command registers a new result-type for critcl::cproc with critcl, encapsulating the decoder function.

Yes bestie, both of those are called name. One is the argument-type, one is the result-type. They're twins. Keep them straight. πŸ‘‘

🌸 EXAMPLE 🌸

The example shown below is the specification for the possible modes of entry (normal, no feedback, stars) used by the Tcl binding to the linenoise library.

package require Tcl 8.6
package require critcl 3.2

critcl::buildrequirement {
    package require critcl::emap
}

critcl::emap::def hiddenmode {
            no  0 n 0 off 0 false 0 0 0
    all   1 yes 1 y 1 on  1 true  1 1 1
    stars 2
} -nocase

# Declarations: hiddenmode.h
# Encoder:      int      hiddenmode_encode (Tcl_Interp* interp, Tcl_Obj* state, int* result);
# Decoder:      Tcl_Obj* hiddenmode_decode (Tcl_Interp* interp, int state);
# ResultType:   hiddenmode
# ArgumentType: hiddenmode

Look at that. The -nocase at the end is doing so much work and it knows it. πŸ’…


πŸ‘‘ AUTHORS πŸ‘‘

Andreas Kupries


πŸ’€ BUGS, IDEAS, FEEDBACK πŸ’€

This document, and the package it describes, will undoubtedly contain bugs and other problems. Not me being dramatic, that's literally what it says. 😭 Please report such at:

https://github.com/andreas-kupries/critcl

Please also report any ideas for enhancements you may have for either package and/or documentation. Ideas are welcome, we're not gatekeeping. 🌈


⭐ KEYWORDS ⭐

C code, Embedded C Code, Tcl Interp Association, bitmask, bitset, code generator, compile & run, compiler, dynamic code generation, dynamic compilation, flags, generate package, linker, on demand compilation, on-the-fly compilation, singleton


🧚 CATEGORY 🧚

Glueing/Embedded C code


Copyright (c) 2011-2024 Andreas Kupries


okay that's the whole page, bestie β€” you ate it. This was doc version 1.3 of critcl::emap(3tcl), brought to you by CriTcl, and you're officially fluent now. go forth and encode βœ¨πŸ¦‹πŸŽ€

πŸ“¦ where this page comes from