genfunc.hpp File Reference

Go to the source code of this file.

Description

Generic functions to build identification schemes.

These template functions are meant as common extension point. The purpose is to streamline and disentangle the various identification schemes in use at various places within Lumiera. We strive to cover all the common basic usage situations through these functions

• build a symbolic ID
• build a classification record
• create a readable yet unique ID
• render an ID in human readable form
• derive a hash function

Todo:

better unit test coverage

improve implementation of typeFullID

See also

GenericIdFunction_test

EntryID

Definition in file genfunc.hpp.

#include "lib/hash-value.h"
#include "lib/symbol.hpp"
#include "lib/typed-counter.hpp"
#include <typeinfo>
#include <string>

Functions
template<typename TY >
string	categoryFolder ()
string	demangleCxx (Literal rawName)
	Fallback type-ID: More...
template<class TY >
string	generateExtendedID (string prefix="")
	build a long type based identifier, with running counter and custom prefix. More...
template<class TY >
string	generateSymbolicID ()
	build a per-type identifier, with type prefix and running counter. More...
template<typename TY >
HashVal	getTypeHash ()
string	humanReadableTypeID (lib::Literal)
	pretty-print an internal C++ type representation More...
string	instance_format (string const &prefix, size_t instanceNr)
string	instance_hex_format (string const &prefix, size_t instanceNr)
template<typename TY >
string	instanceTypeID (const TY *const obj)
	designation of an distinct object instance More...
template<typename TY >
string	namePrefix ()
string	primaryTypeComponent (lib::Literal)
	extract core name component from a raw type spec More...
string	sanitisedFullTypeName (lib::Literal)
	build a sanitised ID from full type name
TypedCounter &	sharedInstanceCounter ()
template<typename TY >
string	typeFullID ()
	Complete unique type identifier. More...
template<typename TY >
string	typeSymbol ()
	Short readable type identifier, not necessarily unique or complete. More...

Namespaces
	lib
	Implementation namespace for support and library code.
	lib::idi
	Identification Schemes.

Function Documentation

demangleCxx()

std::string demangleCxx

(

Literal

rawName

)

Fallback type-ID:

reverse the effect of C++ name mangling.

Returns

unaltered internal type-ID

string in language-level form of a C++ type or object name, or a string with the original input if demangling fails.

Warning

implementation relies on the cross vendor C++ ABI in use by GCC and compatible compilers, so portability is limited. The implementation is accessed through libStdC++ Name representation in emitted object code and type IDs is essentially an implementation detail and subject to change.

Examples:

/Werk/devel/lumi/src/lib/test/test-helper.hpp.

Definition at line 168 of file format-obj.cpp.

References lib::meta::demangleCxx().

Referenced by lib::meta::demangleCxx(), lib::meta::humanReadableTypeID(), and lib::meta::primaryTypeComponent().

Here is the call graph for this function:

Here is the caller graph for this function:

humanReadableTypeID()

std::string humanReadableTypeID

(

Literal

rawType

)

pretty-print an internal C++ type representation

implementation notes

• we do not strip type adornments like const, & or *, however, the typical usage from within util::typeStr() is arranged in a way to absorb these adornments by the way the template signatures are defined
• we do simplify the type display and strip some obnoxious namespace prefixes with the help of std::regex_replace
• we perform those simplifying rewrites in place thus overwriting the result string. This exploits the fact that the replacements are always shorter than what is being replaced (beware).
• standard regular expressions can be assumed to be threadsafe. Thus, we're able to build an embedded shared static variable on demand and use the performance optimisation offered by the standard library
• performance wise we'll assume the transformation happens within the cache, so it doesn't make much of a difference if we scan the same comparatively short string multiple times

See also

format-obj.cpp implementation

Examples:

/Werk/devel/lumi/src/lib/test/test-helper.hpp.

Definition at line 199 of file format-obj.cpp.

References lib::meta::demangleCxx(), and lib::meta::humanReadableTypeID().

Referenced by lib::meta::humanReadableTypeID(), and lib::meta::sanitisedFullTypeName().

Here is the call graph for this function:

Here is the caller graph for this function:

primaryTypeComponent()

std::string primaryTypeComponent

(

Literal

rawType

)

extract core name component from a raw type spec

implementation notes

We want to get at the name of the most relevant type entity. This in itself is a heuristic. But we can work on the assumption, that we get a sequence of nested namespaces and type names, and we'll be interested in the last, the innermost of these types. In the most general case, each type could be templated, and thus will be followed by parameter specs enclosed in angle braces. Behind this spec, only type adornments will follow. Thus we'll inspect the string from the back side, skipping over all type parameter contents, until we reach brace level zero again. From this point, we have to search backwards to the first namespace separator ::

Warning

we acknowledge this function can fail in various ways, some of which will be indicated by returning the string "void". But it may well happen that the returned string contains whitespace, superfluous punctuation or even the whole demangled type specification as is.

Returns

simple identifier possibly "the" type

Warning

implemented lexically, not necessarily correct!

Definition at line 270 of file format-obj.cpp.

References lib::meta::demangleCxx(), lib::meta::primaryTypeComponent(), and lib::meta::typeStr().

Referenced by lib::meta::primaryTypeComponent().

Here is the call graph for this function:

Here is the caller graph for this function: