|
Boost : |
From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2004-07-10 06:53:17
"Andy Little" <andy_at_[hidden]> wrote
> Any chance to make it so it automagically registers types in its database
as
> user uses the mechanism in code, rather than user having to do so
manually.
> Other problem is that each "client" should really have a GUID. Any ideas
on
> how that would work?
We have to tell the compiler about types/templates (whether it's done by the
library itself or it's user -- is a different story). Therefore some kind
of registration looks inavoidable.
When I first posted this (a couple of months ago) I was trying to generate
IDs automatically. Initially I used the MS-specific __COUNTER__ macro, then
I switched to the method suggested by Paul Mensonides -- slightly less
elegant, but much more portable. It turned out, however, that both these
methods have the same problem -- they do not preserve IDs between
compilation units, and therefore eventially leed to the ODR violation. I
tried to work this around by using anonimous namespaces, but then David
Abrahams proved that the ODR violation would still present in certain usage
contexts.
So I gave up, and started using manually-supplies IDs. I do realize that
this is a significant inconvenience. Please note, however, that the IDs are
specified on per-file rather than per-class basis (I use __LINE__ to
distinguish inside one file).
If we consider usage patterns of this facility, in many cases 3 parties are
present:
- the typeof library;
- some other library (user library) that uses expression templates
techniques (such as Spirit, Lambda, etc.);
- the end user.
In this case, the user library can register it's own classes. The end user
than could just use the typeof for all the expressions geherated by this
library, and would not have to worry about registration. In other words,
the library authors could achieve the effect of typeof enabled for their
library (I did this for Spirit -- can be found in the spirit repository in
the TYPEOF_DEV branch).
Of course, this assumes the best-case scenario, where no user-defined
classes are used. When they are, they should still be registered by the end
user.
I am extremely interested in any strategies of generating IDs. GUID would
be excelent, but, unfortunately, this is not an integer (can't be passed
through sizeof). My current understanding -- the libraries should register
their types against some undefined symbols which would be resolved by the
end-user in the system-wide enum, so that different libraries can co-exist,
something like this:
enum
{
SPIRIT_REGISTRATION_GROUP = BOOST_TYPEOF_USER_GROUP,
LAMBDA_REGISTRATION_GROUP,
MY_GROUP1,
MY_GROUP2,
...
};
Regards,
Arkadiy
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk