[gentoo-dev] Re: How to support C++11 in libraries?
On Thu, 19 Dec 2013 10:18:55 +0100 Michał Górny wrote: > And that brings another issue in Gentoo -- gcc-config. AFAIR this tool > is completely insane and switches libstdc++ along with gcc version. > As a result, after switching to a gcc version with different C++ ABI, > installed software gets broken. And you can't really fix it without > going through the broken-system state or some hackery. This hasn't been true for a while now. The latest version of libstdc++ is always used, no matter what version is selected. I can't remember when this was changed but we've gone through a couple GCC stabilizations since. I have no opinion on how to support C++-11, except that it can't be globally enabled. We have to support compilers that predate the standard. I wouldn't like any pkg-config hackery like ICU tried to pull a while back, but now that we have a version of gcc that at least understands the flag in stable at least it wouldn't instantly break everything. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[gentoo-dev] Re: How to support C++11 in libraries?
Jan Kundrát wrote: >> And no, the languages are _not_ "source-incompatible". That would be a >> scandal! > > You might argue about this, but that doesn't change these facts. I think nobody had doubts that *theoretical* such examples can be constructed (I even mentioned the case of name collission on which your example builds). The question is how often does this occur in *real-world* projects. > does not change the fact that there *is* code out there Your example is not "code out there". I would bet that the name collission case hits less than 1% of existing projects. If name collissions would be the only case, it would not even be worth to discuss these things. The more restrictive syntax for string concatenation (mentioned in some bug posted in this thread) is a more realistic issue, but at least in this case, the project has already fixed the problem. Again: Numbers are needed; somebody (preferrably somebody with a fast machine, so I am out ;) ) has to try to compile w/test the whole ~x86/~amd64 tree with CXXFLAGS=-std=c++11, and only then one can seriously discuss how "source-incompatible" the languages really are. My guess is still that you will observe less problems than with a minor gcc upgrade, but it is only a guess, of course.
[gentoo-dev] Re: How to support C++11 in libraries?
Jan Kundrát wrote: > On Friday, 20 December 2013 10:00:43 CEST, Martin Vaeth wrote: >> The example with string reference-counters which you gave is IMHO >> typical; > > You have not considered the implications of the updated requirements It seems you are changing the topic: We were talking about downward-compatibility of source code. There is no doubt that the C++11 requirements need a new ABI: > without breaking the ABI [...] > but I do not expect that the end result will allow linking a translation > unit built for C++98 by GCC <= 4.8 with one built for C++11 by the new > compiler. That's why it might be a good idea to translate with C++11 by default. No old units <-> no problem ;) Again: It is clear that this route is possible only if the number of packages breaking with such a default is small, and fixes are simple. Which needs to be examined by "experiment" and not by theoretical considerations.
[gentoo-dev] Re: How to support C++11 in libraries?
Jan Kundrát wrote: > > Before you invest any more time in this, please understand that C++98 and > C++11 are source-incompatible. The question is what impact this theoretical incompatibility in a few corner cases has in practice. > There is no way to expect that a package builds fine when you > throw -std=c++11 on it. Yes, but the same is true for any gcc upgrade. I repeat that numbers are necessary: If practice shows that there is only a few packages in the tree needing a few trivial patches then the same can be assumed about 3rd party software. The situation is rather different if it turns out that almost nothing runs without severe patches. Nobody can know the answer without actually trying. However, I would be very surprised if the latter is true: The example with string reference-counters which you gave is IMHO typical; one would really need to write strange code to make it work *with* reference counters but break without. Hard to believe that this happens in practice. What *will* happen in practice is that the execution speed changes (probably getting slower, but there might also be exceptions).
[gentoo-dev] Re: How to support C++11 in libraries?
Michał Górny wrote: > > Then, many developers just won't bother. Users will be the ones to hit > the incompatible package build failures first. Is Diego's tinderbox still available? My feeling is that the non-downward compatbility (API-wise) of C++11 is much smaller than e.g. the gcc upgrades 4.5->4.6 or similar ones - except for rather exotic cases or possible name-clashes there are only very few changes and AFAIK no regressions concerning features - at most tiny syntax changes. If one could verify by sandbox that only a few packages are actually involved and can easily be fixed then one could make -std=c++11 the compiler default (perhaps it is necessary to disable some c++11 specific warnings by default in addition to avoid broken behaviour with -Werror which unfortunately is still used by some projects). Concerning binary blobs, one would need a list first ...
