From: David Abrahams (dave_at_[hidden])
Date: 2004-07-10 10:21:01
Doug Gregor <dgregor_at_[hidden]> writes:
>> "Arkadiy Vertleyb" <vertleyb_at_[hidden]> writes:
>> I'm not convinced that this particular ODR violation ends up being a
>> problem in practice, though -- ultimately we end up getting the same
>> type out of any typeof(...), and if we're never generating linker
>> symbols within the computation performed by typeof, we're probably
>> going to get away with it. I think it's worth trying an automatic
>> scheme and stress-testing it to see if we can make it break. Better
>> yet, explicitly construct a pared-down version _designed_ to break
>> and see if we can cause a problem.
> The only time I've ever seen a compiler/toolchain diagnose an ODR
> violation is when it results in two symbols with the same name and
> different sizes being linked together.
Well, it's the *un-* diagnosed ODR violations that are really
> As you said, we're not
> generating anything for the linker so this case won't crop up. Fear,
> Uncertainty, and Doubt make me wonder if trying to use Arkadiy's
> typeof in an exported template would trigger an ODR violation
> diagnostic in an EDG compiler, but I have neither proof nor the
> compiler around.
> I say we try to get away with the ODR violation. We know we're getting
> typeof/decltype eventually, so the ODR violation will eventually
> disappear anyway.
...but I agree with you anyway.
-- 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