This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

O(1) tuple_element and PCH weirdness


Hi,

I'm away from home for a conference and in some spare time decided to look into this small issue. As far as I can see this kind of solution should do the job:

 template<int __i, typename... _Elements>
   struct tuple_element<__i, tuple<_Elements...> >
   {
     template<typename _Head, typename... _Tail>
       static _Head
       __tohead(_Tuple_impl<__i, _Head, _Tail...>);

static tuple<_Elements...> __maketuple();

     typedef decltype(__tohead(__maketuple())) type;
   };

What do you think?


Unfortunately, while trying to minimally test it, I noticed that something weird is happening with the PCH, at least on powerpc-darwin:


In file included from /Users/powerbook/gcc-head-build/powerpc-apple-darwin8.10.0/libstdc++-v3/include/tr1/tuple:55,
from /Users/powerbook/gcc-head-build/powerpc-apple-darwin8.10.0/libstdc++-v3/include/tr1/functional:48,
from /Users/powerbook/gcc-head/gcc/libstdc++-v3/include/precompiled/stdtr1c++.h:53:
/Users/powerbook/gcc-head-build/powerpc-apple-darwin8.10.0/libstdc++-v3/include/tr1_impl/tuple:240: error: '__tohead' is not a type
/Users/powerbook/gcc-head-build/powerpc-apple-darwin8.10.0/libstdc++-v3/include/tr1_impl/tuple:240: error: expected ';' before 'type'
make[2]: *** [powerpc-apple-darwin8.10.0/bits/stdtr1c++.h.gch/O2g.gch] Error 1



Any clue? If I remember correctly, we should be able to use any c++0x new facility without limitations in the headers, right? Apparently however, only if I add by hand -std=c++0x to the command line the PCH builds... Alternately, everything builds if I use __decltype, which makes for another weird thing: I see that indeed we are registering in lex.c the double score version too, but we are not doing the same for static_assert, for example, and if I remember correctly, we decided never doing that...


Thanks for any feedback,
Paolo


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]