Re: ODR violation for std::cout etc.
Paolo Carlini [EMAIL PROTECTED] writes: | Michael Veksler wrote: | | What do you think? | | I think that the current solution is very, very old, and heaven | knows how many others didn't work at the time on some exotic | platforms. I would suggest filing a PR and CCing Benjamin. The current situation was the best compromise we arrived at in the very old days of GCC-3.x.x -- see the archive for discussions. I'd suspect that nowadays we have better ways of handling the issues -- though I've not done any new investigation. -- Gaby
Re: ODR violation for std::cout etc.
The current situation was the best compromise we arrived at in the very old days of GCC-3.x.x -- see the archive for discussions. Indeed. I would resist change just for change's sake, especially when we have not seen a detailed bug report filed. I'd suspect that nowadays we have better ways of handling the issues -- though I've not done any new investigation. I've been waiting to revisit this issue until we have correct alignment support for template objects (std::aligned_storage, etc.) in g++. Then, we can use array_allocator to deal with this stuff in a much more transparent and C++ friendly way. -benjamin
Re: ODR violation for std::cout etc.
Benjamin Kosnik [EMAIL PROTECTED] writes: | I've been waiting to revisit this issue until we have correct | alignment support for template objects (std::aligned_storage, etc.) | in g++. Then, we can use array_allocator to deal with this stuff in a | much more transparent and C++ friendly way. I'm in full agreement with that position. -- Gaby
ODR violation for std::cout etc.
Hello, Currently libstdc++ violates ODR: iostream: extern ostream cout; global_io.cc: fake_ostream cout; It assumes that gcc will work fine with this. Apparently it does, for now. After solving a similar problem in my code using a similar technique - to find out that it does not work for MS VS-2005 - when I had to find a different fix. The question is, why does GCC has to resolve to such construction-order issue this way? Idea (which I used): don't violate ODR in global_io.cc. Instead, construct and destroy std::cout two times, in a safe way: static PreSecondCtor coutPreSecondCtor(std::cout); ostream std::cout(NULL); static PostSecondCtor coutPostSecondCtor(coutPreSecodCtor); When PreSecondCtor saves all relevant data of cout (error bits, state, rdbuf, etc.), and then calls std::cout.~ostream(); Note that before this point, std::cout has already been constructed by an std::ios::Init, and we need to avoid double construction. In PostSecondCtor, restore the state of cout out of the saved data in outPreSecondCtor. During destruction the order is reversed. I still have a vague feeling that this solution is also undefined (since we are calling the constructor of std::cout, using placement new, after it had been automatically destroyed by the C++ environment). I don't have the standard near me, so I can't check. Anyway, even if this is undefined, the situation is arguably better since it does not seem to break whole program compilation (like current implementation might). What do you think? Michael
Re: ODR violation for std::cout etc.
Michael Veksler wrote: What do you think? I think that the current solution is very, very old, and heaven knows how many others didn't work at the time on some exotic platforms. I would suggest filing a PR and CCing Benjamin. Thanks, Paolo.
Re: ODR violation for std::cout etc.
Michael Veksler wrote: What do you think? On Tue, Jul 10, 2007 at 06:58:50PM +0200, Paolo Carlini wrote: I think that the current solution is very, very old, and heaven knows how many others didn't work at the time on some exotic platforms. I would suggest filing a PR and CCing Benjamin. The ODR is a rule that applies to users' programs; if they violate it, we can't make any promises that their program will work. If there's a violation in the internals of the libstdc++ implementation, then this only really matters if it breaks something. Otherwise I'd suggest classifying the bug P5 (absolute lowest priority); there are any number of real bugs that are more important to fix.
