From stdcxx-dev-return-219-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Wed Sep 28 18:21:40 2005 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 97881 invoked from network); 28 Sep 2005 18:21:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 28 Sep 2005 18:21:39 -0000 Received: (qmail 18292 invoked by uid 500); 28 Sep 2005 18:21:39 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 18255 invoked by uid 500); 28 Sep 2005 18:21:38 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 18242 invoked by uid 99); 28 Sep 2005 18:21:38 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Sep 2005 11:21:38 -0700 X-ASF-Spam-Status: No, hits=0.9 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_WHOIS,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of lancediduck@nyc.rr.com designates 24.29.109.5 as permitted sender) Received: from [24.29.109.5] (HELO ms-smtp-01.rdc-nyc.rr.com) (24.29.109.5) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Sep 2005 11:21:44 -0700 Received: from LanceLaptop (cpe-66-65-46-64.nyc.res.rr.com [66.65.46.64]) by ms-smtp-01.rdc-nyc.rr.com (8.12.10/8.12.7) with ESMTP id j8SIKo1i017402 for ; Wed, 28 Sep 2005 14:20:54 -0400 (EDT) Message-Id: <200509281820.j8SIKo1i017402@ms-smtp-01.rdc-nyc.rr.com> From: "Lance Diduck" To: Subject: RE: type_traits and other things Date: Wed, 28 Sep 2005 14:21:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcXDuBADzyUy/u/cT3uM0BodFLbq8gAZvRng X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <4339D0D4.9050500@roguewave.com> X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 > struct is_array_impl:false_type {}; > template > struct is_array_impl: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 > struct is_array_impl:true_type {}; > #endif > }//detail > template > struct is_array:integral_constant ::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