Comment by tialaramex | Hacker News Reader

Comment by tialaramex | Hacker News Reader

Parent Full thread

Right, and C++ got a lot of its compiler performance for large projects by making this an embarrassingly parallel problem even though the consequences are negative for the main consumers of the code (people, not compilers).

One cost of being embarrassingly parallel is the One Definition Rule. If we can compile N different code units in parallel, but they're all allowed to define things in the same namespace, obviously those definitions might contradict each other and we wouldn't notice. So, the C++ language explicitly forbids this, knowing you'll probably do it anyway, at least by mistake. If (when) you do, that isn't a valid C++ program, but the compiler isn't expected to produce any diagnostic (warning or error). So, you get a binary, but the language doesn't care what that binary does. Maybe it does exactly what you expected. Maybe it does almost exactly what you expected. If not too bad, the One Definition Rule means your compiler was fast and that's what matters.

I usually fails at link time doesn't it?

No. I have intentionally violated the one definition rule and nothing broke at all. In my case I wrote a second timer, which had hooks my unit test system could use to advance time without having to inject timers.

It will fail at link time if you link everything into the same library. Even here there is an escape: there are ways to mark something as a weak symbol and than the linker won't complain about more than one definition.

See your OS documentation for how this works on your implementation. (though don't be surprised if the documentation is wrong...)

> No. I have intentionally violated the one definition rule and nothing broke at all.

did you use LTO ? It always catches ODR issues for me. There is also GNU Gold's --detect-odr-violations switch.

No. LTO is something I've been meaning to look at. Though if I can't violate the ODR intentionally I might not be interested.

If you violate ODR intentionally you are just writing code that will break in a future version of GCC / Clang / ..

That is a risk I know I'm taking.

Though I've been tempted to write a paper for C++ to make it defined behavior. I know it works in some form on most implementations even though it isn't legal. Thus there seems to be some other use cases for it that could/should be formalized. If anyone can give me other examples of why you want to do this and what the rules are on each platform I'll take a shot at it.

> I know it works in some form on most implementations even though it isn't legal.

it definitely does not, every time I had an ODR issue that caused actual bugs. For instance, dynamic_cast not working because a typeid was defined in two shared objects, etc.

What would be the behaviour you expect if you have

    a.cpp: 
    int constant() { return 123; }

    b.cpp:     
    int constant() { return 456; }

    c.cpp: 
    int constant();
    int main() { return constant(); }

how could you define this meaningfully other than "hard error" ?

e.g. here with gcc, if a and b are put into shared libraries, the return value depends on the order in which the libraries are passed to g++ when linking. e.g.

    g++ c.cpp a.so b.so

calls the version in a.so, while

    g++ c.cpp b.so a.so

calls the version in b.so

You can do that because the order in which libraries are passed to the linker is something you can control. Of course linkers don't have to do this, and future versions can do something different, but it works and the rules for gcc are currently "the order in which the libraries are passed to g++ when linking", which is defined. Of course gcc has the right to change those rules (I suspect the real rules are a bit more complex)

Gcc also has the concept of weak symboles which if invoked (and the linker supports it) would allow you to make one of the two weaker than the others and then the whole doesn't depend on link order. Visual C++ also seems to have something like this, but I'm sure it is different.

Like I said, I want to write a paper to make it defined - but the paper will be a lot longer than would fit in a response here, and depending on information that I currently don't know.

> I wrote a second timer, which had hooks my unit test system could use to advance time without having to inject timers.

This use case isn't an ODR violation. Its just using the linker to mock an interface.

> It will fail at link time if you link everything into the same library.

That is an ODR violation, although there are variations on this pattern that are not required to be detectable. Template instantiation is an easy way to get a silent ODR violation.

Reply on news.ycombinator.com