libstdc++

According to http://flamingdangerzone.com/cxx11/2012/07/06/optimal-tuple-i.html , with regards to std::tuple... libstdc++ always places the members in reverse order, and libc++ always places the members in the order given Assuming that's true, is there a reason (historical or otherwise) why libstdc++ uses reverse order? Bonus: Has either implementation ever changed its std::tuple ordering for any reason? Howard Hinnant See this answer for why libc++ chose forward order. As for why libstdc++ chose reverse order, that is probably because that's how it was demonstrated in the variadics template

My basic idea was to derive my own class from std::tuple to get some helper types inside like this: template <typename ... T> class TypeContainer: public std::tuple<T...> { public: using BaseType = std::tuple<T...>; static const size_t Size = sizeof...(T); TypeContainer(T... args):std::tuple<T...>(args...){}; using index_sequence = std::index_sequence_for<T...>; }; Now I try to use the code as follows: using MyType_tuple_with_empty = std::tuple< std::tuple<float,int>, std::tuple<>, std::tuple<int>>; using MyType_typecontainer_with_empty = TypeContainer< TypeContainer<float,int>, TypeContainer<

The following (toy) program returns different things when linked against libstdc++ and libc++. Is this a bug in libc++ or do I not understand how istream eof() works? I have tried running it using g++ on linux and mac os x and clang on mac os x, with and without -std=c++0x. It was my impression that eof() does not return true until an attempt to read (by get() or something else) actually fails. This is how libstdc++ behaves, but not how libc++ behaves. #include <iostream> #include <sstream> int main() { std::stringstream s; s << "a"; std::cout << "EOF? " << (s.eof() ? "T" : "F") << std::endl;

What is a good way of checking for the presence of specific C++11 features of the standard library . For compiler features I just went by the way of checking the compiler version for the (IMHO) major compilers ( VC++ , gcc , clang at the moment, maybe Intel ) Although this is not the best and most flexible approach, I don't know of anything better yet, except for clang which has the really nice __has_feature macros. But it's even worse for library features, which are not coupled that rigidly to the compiler. At the moment I want to use the same approach of checking the compiler version for VC+

I'm writing some C++11 code that makes assumptions about the nature of std::string that are valid, but represent behavior that was changed in C++11. In the earlier days, libstdc++'s basic_string implementation conformed to the 98/03 requirements, but not to the more strict C++11 requirements. As I understand it, libstdc++ has fixed the issues around basic_string . The problem is that there are many versions of the library that people use which do not implement this fix. And my code may silently fail in many unpleasant ways on them. I would like to have a static_assert fire if the user attempts

Consider this simplified and very specific implementation of a recursive variant on top of std::variant : #include <map> #include <variant> struct recursive_tag; template <typename...> struct RecursiveVariant; template <> struct RecursiveVariant<int, std::map<int, recursive_tag>> : std::variant<int, std::map<int, RecursiveVariant<int, std::map<int, recursive_tag>>>> { using underlying = std::variant<int, std::map<int, RecursiveVariant<int, std::map<int, recursive_tag>>>>; using underlying::underlying; }; int main() { RecursiveVariant<int, std::map<int, recursive_tag>> rv; } This fails to

Is it possible to port a C++ application which uses the STL extensively to Android? I understand that currently the NDK does not support this, but is there any effort (open source or otherwise) underway to achieve this? If not is there a way to cross compile libstdc++ for Android? UPDATE: Ndk Revision 5 promises a default STL implementation based on STLport. http://android-developers.blogspot.com/2011/01/gingerbread-ndk-awesomeness.html Read this official NDK blog post , http://developer.android.com/sdk/ndk/index.html>and the revision notes. You may want to start with Dmitry Moskalchuk's