Type identifier management and object factories

[Mark F. Haigh]

In Andrei Alexandrescu's book _Modern C++ Design_, Chapter 8 ("Object
Factories"), Section 8.4 ("Type Identifiers"), he states:
The only problem that remains is the management of type identifiers.
Still, adding type identifiers requires a fair amount of dicipline
and centralized control. [...]

The only conclusion that can be drawn here is that type identifier
management is not the business of the object factory itself.
Because C++ cannot guarantee a unique, persistent type ID, type ID
management becomes an extra-linguistic issue that must be left to
the programmers.
This strikes me as overly pessimistic. It seems to me that one could
use the address of a static variable defined within a new block, all
within a macro:
#define FACTORY_REGISTE R(fn, cb) \
do { \
static int foo = 42; \ <- foo's address is unique
fn(&foo, cb); \
} while(0)
Quoting ISO/IEC C++ 14882:2003, 3.7.1 (4):

If an object of static storage duration has initialization [...],
it shall not be eliminated even if it appears to be unused [...]
On non-pathological platforms where there is an integer size large
enough to hold this pointer value, it could simply convert it, and use
it, for efficiency. For more portability, though, I see no reason that
stringification of this value would not work. The block scope will
prevent collisions with another 'foo'.

I'd appreciate it if somebody could tell me specifically why this (or a
related derivation of it) is a bad idea. It would seem to be a fairly
obvious strategy, but I spend most of my time doing systems programming
in C, so that certainly colors my thinking on the matter.
Thanks,
Mark F. Haigh
mf*****@sbcglob al.net

[David Hilsee]

"Mark F. Haigh" <mf*****@sbcglo bal.ten> wrote in message
news:YY******** ********@newssv r21.news.prodig y.com...

In Andrei Alexandrescu's book _Modern C++ Design_, Chapter 8 ("Object
Factories"), Section 8.4 ("Type Identifiers"), he states:
The only problem that remains is the management of type identifiers.
Still, adding type identifiers requires a fair amount of dicipline
and centralized control. [...]

The only conclusion that can be drawn here is that type identifier
management is not the business of the object factory itself.
Because C++ cannot guarantee a unique, persistent type ID, type ID
management becomes an extra-linguistic issue that must be left to
the programmers.
This strikes me as overly pessimistic. It seems to me that one could
use the address of a static variable defined within a new block, all
within a macro:
#define FACTORY_REGISTE R(fn, cb) \
do { \
static int foo = 42; \ <- foo's address is unique
fn(&foo, cb); \
} while(0)
Quoting ISO/IEC C++ 14882:2003, 3.7.1 (4):

If an object of static storage duration has initialization [...],
it shall not be eliminated even if it appears to be unused [...]
On non-pathological platforms where there is an integer size large
enough to hold this pointer value, it could simply convert it, and use
it, for efficiency. For more portability, though, I see no reason that
stringification of this value would not work. The block scope will
prevent collisions with another 'foo'.

I'd appreciate it if somebody could tell me specifically why this (or a
related derivation of it) is a bad idea. It would seem to be a fairly
obvious strategy, but I spend most of my time doing systems programming
in C, so that certainly colors my thinking on the matter.

I'm not 100% sure that the approach you used is legal, but it really doesn't
matter. One could generate unique IDs by allocating objects dynamically and
using the pointers as keys. However, these approaches do not portably
generate _persistent_ ids, which is what Alexandrescu desired. Note that
one of his issues with using typeid(class).n ame() for this purpose was that
the string value is not guaranteed to be the same every time the application
is run. There may be non-portable ways to work around this, but he is
primarily interested in a portable approach.

--
David Hilsee