stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: type_traits and other things
Date Tue, 27 Sep 2005 23:08:04 GMT
> I finally did get SVN to work through http here at work. This works out great. 
> Still plugging away on the build 


> On workaround and type traits -- I did get most of type_traits working for Sun 
> 5.2 -- and also for 5.3, aCC, vacpp, MSVC 7.1 and 8, and gcc.  Most feature made
>  it through, it just took a while. There are a few workarounds and weirdness, 
> like specializations that relied on volatile, and arrays e.g.
> #if defined( __SUNPRO_CC ) && __SUNPRO_CC<0x550  
>  #define TYPENAME 
> #else   
>  #define TYPENAME  typename 
> #endif

Keep in mind that for the final version we will need a better name
for the macro (with underscores in the right places) and that we might
also need a config test for it (unless it's very specific to a SunPro
bug). Since we already have a _TYPENAME for the common cases and this
doesn't look like one of them I think we might need to go with
something like _RWSTD_NESTED_TYPENAME (ugh).

>     namespace detail{        
>         template<typename tr1_templateargU>  
>         struct is_array_impl:false_type {};    
>         template<typename tr1_templateargU, std::size_t tr1_templateargC>  
>         struct is_array_impl<tr1_templateargU[tr1_templateargC]>:true_type {};
> #if (!defined( __SUNPRO_CC) && __SUNPRO_CC<0x550 ) && !defined( _AIX)

This conditional will need to be replaced by some platform-independent
autoconfigured macro based on a test exposing the limitations in all
the affected compilers.

>      template<typename tr1_templateargU>  
>         struct is_array_impl<tr1_templateargU[]>:true_type {};
> #endif   
>  }//detail
> template<typename tr1_templateargU>  
> struct is_array:integral_constant<bool,detail::is_array_impl<TYPENAME remove_cv

> <tr1_templateargU>::type >::value> {   };
> The STDCXX build and config system would do wonders for this library though, It 
> seems that every change in a build option or compiler release breaks something. 

Yes, I have no doubt we'll be adding a bunch of config tests for all
the new compiler bigs that TR1 will bring out. I also want to make
sure we report all the bugs to the compiler vendors and keep track
of each bug report in Jira. I have a database of some 300 to 500
compiler and OS bugs that I want to migrate from the Rogue Wave
Bugzilla over to Jira and that will be helpful in porting TR1 to
all the compilers the rest of stdcxx already works on. I need to
figure out how best to enter these in Jira.

> Little wonder that there are few who have ported this guy. If you want I can 
> post the code so we have a starting point.    

Sure, that would be great!

We should probably come up with a way to commit these experimental
pieces that lets us continue to build the library without them by
default and enable them for porting to new compilers and platforms.
Suggestions are welcome! :)


View raw message