7 ms·
We shouldn't worry about C++11 / C++14 compiler support, which will eventually come, but rather standard libraries. It's a pain that libstdc++ still does not su
by arcatek 13y ago
We shouldn't worry about C++11 / C++14 compiler support, which will eventually come, but rather standard libraries. It's a pain that libstdc++ still does not support some C++11 features[1] (no std::move on streams, for example).
They probably have good reasons, such as keeping the same ABI as long as possible, but it's sometimes very frustrating.
[1] http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011 http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#s...
- cokernel_hacker 13y agolibcxx has not only implemented C++14 but they have also implemented all known defect reports at roughly the rate they get published! http://libcxx.llvm.org/cxx1y_status.html http://libcxx.llvm.org/cxx1y_status.html
- mekishizufu 13y agoUnfortunately libc++ is fully supported on Mac OSX only, with ports on their way. I actually use libc++ on linux but there're still some things that need to be fixed. [1] [1] http://libcxx.llvm.org/results.Linux.html http://libcxx.llvm.org/results.Linux.html
- cokernel_hacker 13y agoThose results are from over a year ago [1]. [1] http://llvm.org/viewvc/llvm-project?view=revision&revision=161192 http://llvm.org/viewvc/llvm-project?view=revision&revision=1...
- mekishizufu 13y agoGood point. I will run the tests myself to see the current status.
- eonil 13y agoI still see the cuchar fail on Clang source 3.3, but maybe different on trunk.
- eonil 13y agoDoesn't it run on FreeBSD?
- eliben 13y agoThat's not entirely true. libc++ works on Linux too. In fact, Google's PNaCl has experimental libc++ support that's completely cross-platform.
- pmelendez 13y agoAnd in windows too http://llvm.org/builds/ http://llvm.org/builds/
- fedvasu 13y agoyeah right. It is beta-quality unfit for pre-packaging in distro's. ABI incompatible with libstdcxx and deliberately OS X only. (It works sure (i mean kinda) no one is actually a linux port developer or maintainer not yet)
- X-Istence 13y agoNot just Mac OS X, it is in the FreeBSD base system by default, it is the replacement for the libstdc++. See FreeBSD 10 where the switch was made :-).
- fhd2 13y agoGood point, I believe clang + libstdc++ is a much more common combination than clang + libc++. One thing I really don't like about libc++ is that it doesn't support anything from TR1 - makes it needlessly difficult to use in existing code bases.
- eonil 13y agoI don't agree.
- pmelendez 13y agoWould you mind to say why?
- eonil 13y agoWhat I don't agree was this phrase. *much more common combination* Why? no clue, no reason. But Clang with libc++? There're reasons. The primary Clang user groups are Apple and FreeBSD communities. a.k.a. anti-GCC groups. Both of them really want to avoid any GCC stuff and are officially deprecating all the GCC stuff. Having dependency to GCC stuff is nonsense on these platforms. If common developers are sane enough, they' won't use libstdc++. And other group is the Linux development. But I don't think there're really many developers who are using Clang for production on Linux. There's no big push from the platform, and also no big benefits. But there're many shortcomings for using Clang. It's not installed by default, not supported by platform, not tested much. If there're some people want to adapt Clang on Linux even now, they won't hesitate to use libc++. And the others will just stays in good old GCC with libstdc++.
- pmelendez 13y ago>"and also no big benefits" I think there are several benefits in using clang tools. You might find useful the Chandler Carruth's talk on Going Native on which he demoed some great tools that doesn't really have alternative on the gnu toolchain. http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s-Dragons http://channel9.msdn.com/Events/GoingNative/2013/The-Care-an...
- MichaelMoser123 13y agoOh! before doing C++14 gcc should please fix the std::list class; the size() method walks over the whole list in order to determine its size, outrageous. template<typename _Tp, typename _Alloc = std::allocator<_Tp> > class list : protected _List_base<_Tp, _Alloc> { ... size_type size() const { return std::distance(begin(), end()); }
- octo_t 13y agostd::list is a doubly linked list, how else do you propose they do this? This is traditionally how list sizes are calculated. (libc++ keeps a track of the size somewhere, but this in occurs a 4/8 byte overhead)
- cmircea 13y agoI think everyone will agree that using 4 bytes to store the size a much better idea than potentially enumerating millions of nodes just to count them, in the process completely blowing the cache and any optimizations the processors may do. It's four goddamn bytes. Or eight if you really want more than 4 billion elements.
- apaprocki 13y ago> It's four goddamn bytes. Or eight if you really want more than 4 billion elements. As long as you don't have millions of lists with a few elements each -- you can't presume that they are only used one way :)
- angersock 13y agoNo, really, it's quite a safe assumption. Hell, you probably lose that much to padding somewhere anyways.
- Someone 13y agoAccording to http://www.cplusplus.com/reference/list/list/size/ http://www.cplusplus.com/reference/list/list/size/, list::size must be constant time in C++11. That may make 'splice' slower. See http://home.roadrunner.com/~hinnant/On_list_size.html http://home.roadrunner.com/~hinnant/On_list_size.html (I think that could be solved by having list iterators carry a field pointing to their container, but haven't given it much thought. Corrections welcome)
- fafner 13y agoPatches are welcome. But it requires fsf copyright assignment.
- GertrudeCruz 13y agomy parents in-law recently purchased a fantastic white Lexus LS 460 Sedan by work parttime using a laptop... you can find out more... www.Buzz19.com