You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Martin Sebor <se...@roguewave.com> on 2005/09/28 01:08:04 UTC
Re: type_traits and other things
LANCE DIDUCK, BLOOMBERG/ 731 LEXIN wrote:
> I finally did get SVN to work through http here at work. This works out great.
> Still plugging away on the build
Great!
>
> 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! :)
Martin
RE: type_traits and other things
Posted by Lance Diduck <la...@nyc.rr.com>.
<< I'm not sure about these non-ASF copyrights. >>
Yes these are a pain in the (*|*) and before I do anything we'll go over a
cut. I have a friend who may be interested in helping in the legal area,
I'll try to remember to ask tomorrow. He is a NY Bar member who specializes
in software issues, and helped me a lot with getting my employer comfortable
in my involvement with ASF.
The copyright is largely like the all the STL implementations carrying the
HP license. It would be hard to get rid of the reference version license,
and after all, they did come up with the design. Most of the other stuff may
be doable, but in any case the licenses would be of the "no warranty" type,
and far less stringent that the Stallman variety licenses, i.e. no
copylefts.
In any case, any non-ASF license would make it non-deployable, and not much
use.
The commit then review would be very helpful, at least to a separate
"work-in-progress" area. Doing this for the Cygwin port would help too. I'm
finishing up some changes that I hope will be a differentiating point from
the boost implementation, and giving it a shot at work now -- no interface
or semantic changes, of course, just more options in the implementations
(like different ways of handling undefined behavior), and beefier tests.
Lance
-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com]
Sent: Wednesday, September 28, 2005 4:52 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: type_traits and other things
Lance Diduck wrote:
> 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.
I'm not sure about these non-ASF copyrights. AFAIK, the ASF frowns
on, or at least questions such things, even if they are compatible
with the Apache License. Our mentors will need to take a look at it
and give their yay or nay before we can use the code. It would be
easier to get rid of as much as you legally can.
>
> 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.
Going the commit-then-review route sounds like a sensible approach for
new files. I believe some of the TR1 bits are mixed in with the existing
stuff so at least in some cases people will need to do both (touch the
existing headers in addition to the experimental ones). To isolate the
changes in the existing headers we'll need to guard them all with some
macro (such as _RWSTD_EXT_TR1). We might also want to consider creating
a separate branch for TR development.
> The Clearcase SCCS makes this easy, and I'll have to find out how to do
this
> with SVN.
My initial thought on the directory layout for the TR1 stuff is simply
to add
include/tr1/ -- TR1 headers
src/tr1/ -- TR1 sources
The thing to decide on will be the mechanism to enable the TR1 bits in
our builds. We could require that a macro be set in addition to adding
-Itr1 to the preprocessor options or require only that -Itr1 be before
any other -I options so that its headers are found before any existing
headers with the same name.
> 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.
We'll definitely need tests for all TR contributions. I'm still refining
the test driver but most of it is already in place. Whenever you have
a chance it would be great if you could take a look at it and post your
feedback.
Martin
Re: type_traits and other things
Posted by Martin Sebor <se...@roguewave.com>.
Lance Diduck wrote:
> 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.
I'm not sure about these non-ASF copyrights. AFAIK, the ASF frowns
on, or at least questions such things, even if they are compatible
with the Apache License. Our mentors will need to take a look at it
and give their yay or nay before we can use the code. It would be
easier to get rid of as much as you legally can.
>
> 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.
Going the commit-then-review route sounds like a sensible approach for
new files. I believe some of the TR1 bits are mixed in with the existing
stuff so at least in some cases people will need to do both (touch the
existing headers in addition to the experimental ones). To isolate the
changes in the existing headers we'll need to guard them all with some
macro (such as _RWSTD_EXT_TR1). We might also want to consider creating
a separate branch for TR development.
> The Clearcase SCCS makes this easy, and I'll have to find out how to do this
> with SVN.
My initial thought on the directory layout for the TR1 stuff is simply
to add
include/tr1/ -- TR1 headers
src/tr1/ -- TR1 sources
The thing to decide on will be the mechanism to enable the TR1 bits in
our builds. We could require that a macro be set in addition to adding
-Itr1 to the preprocessor options or require only that -Itr1 be before
any other -I options so that its headers are found before any existing
headers with the same name.
> 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.
We'll definitely need tests for all TR contributions. I'm still refining
the test driver but most of it is already in place. Whenever you have
a chance it would be great if you could take a look at it and post your
feedback.
Martin
RE: type_traits and other things
Posted by Lance Diduck <la...@nyc.rr.com>.
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
deprecated
Lance
-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com]
Sent: Tuesday, September 27, 2005 7:08 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: type_traits and other things
LANCE DIDUCK, BLOOMBERG/ 731 LEXIN wrote:
> I finally did get SVN to work through http here at work. This works out
great.
> Still plugging away on the build
Great!
>
> 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! :)
Martin