[lug] C++ question, without buying expensive doc.s
Paul E Condon
pecondon at mesanetworks.net
Mon Jan 10 19:37:35 MST 2005
On Mon, Jan 10, 2005 at 07:02:22PM -0700, Tkil wrote:
> >>>>> "Paul" == Paul E Condon <pecondon at mesanetworks.net> writes:
>
> Paul> There is a predefined in GNU C++ whose name is __FUNCTION__.
> Paul> This evaluates to the name of the function that is currently
> Paul> being compiled. I think this can be used to store the name of a
> Paul> class in the date contained in its instances. This is useful for
> Paul> serialize/deserialize.
>
> Interesting.
>
> Paul> a. is this standards compliant
>
> It appears it's not...
>
> Paul> b. is there some other standards compliant predefine that would
> Paul> be better
>
> Paul> My experience is that when one finds the section on predefines
> Paul> in the manual, the docment 'the more important predefined names'
> Paul> and often leave out some of the ones that are required by the
> Paul> standard.
>
> Yeah, I know that pain.
>
> Paul> It's not being a language lawyer. Serialize/deserialize really
> Paul> needs a linkage (_not_ in the compiler technical sense) from an
> Paul> object back to its text name, otherwise such linkage must be
> Paul> hand crafted for each individual object that is to be
> Paul> serialized.
>
> Huh. In my very limited exposure to environments that try to do
> serialization "automagically" in C++, I was never very happy with the
> results.
>
> I wonder what Tom Tromey has to say about it...
>
> Good luck!
>
To do serialization 'automagically' they need to put a distinct 'magic
number' in the serializations of distinct object types. Usually this
is attempted without language/compiler support by having a hidden
database somewhere in the development environment, and registering
magic numbers there. I believe they would be much better off using the
actual object text name rather than a secretly maintained magic number
database.
But maybe I'm just a lunatic outlier.
By the way, who is Tom Tromey?
--
Paul E Condon
pecondon at mesanetworks.net
More information about the LUG
mailing list