"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
ultimately, at some point, somebody is writing a CPP file. This end user has to collect all such headers, and "chain" them in a single header,
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes: thus
emulating a single enum.
That sounds like a serious usability problem to me. Furthermore, we'll still have an ODR violation if two separately-compiled libraries do the chaining in different ways. Am I wrong?
Right, but it does provide the ability to create the ODR-complient code (even if only inside one module) by applying certain discipline... And I don't quite agree that this discipline is too hard to follow. People use system-wide enums left and right...
Yes, but there's seldom a requirement that they be unique system-wide while at the same time being distributed across headers.
and in many cases this is just classes from a couple of libraries that the user really needs.
As for separately-compiled libraries, do you think such a library could have any remaining traces of the template instantiations we are discussing?
If not, the original ODR problem is a total non-issue from a practical POV so you might as well go ahead with automatic ID generation.
Futhermore, without the discipline, provided people don't care about ODR, it can be made almost as easy as automatic registration. For example the registration headers can directly #include the "enum"-headers, so that if they wern't previously chained, they chain in a random way. Even automatic ID-generation faciities can be provided in addition, for end-users who do not care about ODR.
OK.
But, as it was said here yesturday, I think we should not punish "I know what I am doing" group. Let's at least provide the ability to create the ODR-complient code...
If the ODR matters in this case, we have to do it. Otherwise, I don't care one way or the other. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com