"David Abrahams" <dave@boost-consulting.com> wrote
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.
Isn't it possible that compiler keeps some information in memory as it compiles different units? So that, when it sees a class second time, it detects the ODR violation, and does whatever it desides appropriate to do (maybe just ignore, and use the first one, current one, one randomly selected from whatever it had so far, etc.). But I can hardly imagine that the compiler would persist the information about such class in the object module... And this would be the only way for the linker to get it noticed at all for the separately compiled libraries...
If the ODR matters in this case, we have to do it. Otherwise, I don't care one way or the other.
So here is the question, how do we know whether it matters or not? If we come up with an obvious example of ODR violation, and the compiler will not complain about it, can we be sure that it will not complain in other contexts? Or, can we be sure that other context will not cause some kind of "ICE"? I guess my point is that I would like to prove that ODR is not important in this case, but I don't have enough knowledge of compilers to do it with reasonable accuracy :( Where are those good old days when it was claimed that comilation of one unit is totaly independent from the other? Maybe we just all should totally switch to anonimous namespaces? ;-) Arkadiy