stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Diduck" <>
Subject RE: type_traits and other things
Date Wed, 28 Sep 2005 18:21:14 GMT
On shared_ptr and type_traits -- I've requested to copyright release and IP
review from work, that could take a couple of weeks. I have most of Sections
2 and 4. Most of this stuff will be crammed with various copyrights, from
boost, a couple of books (notably Vandevoorde and Josuttiss), and other
attributions to different contributors collected over the course of time.  

The easiest way to separate them IMHO would be to have them in a working
directory separate from the existing std stuff. This area would not follow
the review then commit rules. The rule would only apply when the library was
voted for release, and then merged to 'tr1' or whatever it would be called
upon vote. Then the rule applies. 
The Clearcase SCCS makes this easy, and I'll have to find out how to do this
with SVN.
We finished up a shared_ptr regression tester at work as well, tests
shared_ptr but does no rely on the fact that the template is called
shared_ptr. Allows testing of a number of implementations without changing
the tester. Make "what-if" analysis far far easier.

<< Keep in mind that for the final version we will need a better name
for the macro >> Oh of course. I would want to take advantage of all the
stdcxx stuff, to make the maintenance more sane. But this particular macro
fixes a bug in 5.2, which is there in 5.3, so hopefully it will be

-----Original Message-----
From: Martin Sebor [] 
Sent: Tuesday, September 27, 2005 7:08 PM
Subject: Re: type_traits and other things

> I finally did get SVN to work through http here at work. This works out
> Still plugging away on the build 


> On workaround and type traits -- I did get most of type_traits working for
> 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
> 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
> <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

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
> 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