From: David Abrahams (dave_at_[hidden])
Date: 2004-07-22 12:00:55
"Arkadiy Vertleyb" <vertleyb_at_[hidden]> writes:
> "David Abrahams" <dave_at_[hidden]> wrote
>> "Arkadiy Vertleyb" <vertleyb_at_[hidden]> writes:
>> > ultimately, at some point, somebody is writing a CPP file. This end
>> > has to collect all such headers, and "chain" them in a single header,
>> > 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
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.
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk