
"Andy Little" <andy@servocomm.freeserve.co.uk> 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