From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-25 00:48:36
OK - it seems to me that you've got everything covered. I'm anxious
to try this out. I just have to figure a way to make it optional
pending acceptance (or rejection) from boost.
The "const" question isn't a big deal for me but I just like
to you "const" every chance I get. I number of the static
objects in the serialization libary are just to hold pointers
to some template instantiations for unknown derived types
so they could be "const".
I now understand the static "internal type" instance.
But it's very confusing when one reads the documentation.
There's not explanation that it overloads the -> operator
(other than the table entry in requirements. Given this
I expect the synopsis to read
static "internal type" *instance
which one would expect to apply the -> operator to.
Then there's the issue of using what looks like a public member
variable as an interface. There are going to be complaints
I realize that these things could be dismissed as "cosmetic"
- they are "cosmetic" - but going along with common customs
and patterns makes it easier to grasp. So think about this.
Tutorial - include an example of using this as an aditional
base class in a multiple inheritance. This would not have
occurred to me until it was probably too late but I think it
might be very helpful to me now.
Is there any way to test the claim that this thing keeps one
instance even though the interface is used from mainline or
DLLS. With serialization library it sometimes happens that
users use a type in the mainline and the go do the same thing
in the DLL. This results in two instances being created as
the static initializer is compiled into each translation unit as
a local function. This results in multiple typeinfo records
corresponding to the same type.which could create some
problems. I haven't figured out to use bjam to create a
DLL in the same directory as the mainline test module so
that this proposition can verified.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk