incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: type_traits and other things
Date Wed, 28 Sep 2005 20:52:13 GMT
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

Mime
View raw message