From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14891 invoked by alias); 4 Feb 2006 23:41:49 -0000 Received: (qmail 14870 invoked by uid 48); 4 Feb 2006 23:41:48 -0000 Date: Sat, 04 Feb 2006 23:41:00 -0000 Message-ID: <20060204234148.14869.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/26099] support for type traits is not available In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "pcarlini at suse dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-02/txt/msg00363.txt.bz2 List-Id: ------- Comment #5 from pcarlini at suse dot de 2006-02-04 23:41 ------- Really, what Stefaan is saying is trivially correct and totally sensible. The only doubt I have is which *specific* shape the compiler support must take. In fact, I find TR1, 4.9 too vague about that. Then the point would be (I think Andrew will agree): let's suppose some sort of ""reflection"" becomes part of the next C++ standard, then the whole core C++ + type_traits becomes absolutely natural and neat. I think many people would like standardization in this area, but if C++0x will not include it (a huge number of new features is already scheduled!), we have to accept ""extensions"" if we want performance and QoI in the library. This is already happening today in many areas, consider, e.g., thread safe locales, math builtins, lots of examples, really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099