From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26944 invoked by alias); 4 Feb 2006 23:14:00 -0000 Received: (qmail 26929 invoked by uid 48); 4 Feb 2006 23:13:58 -0000 Date: Sat, 04 Feb 2006 23:14:00 -0000 Message-ID: <20060204231358.26928.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: "stefaan dot deroeck at gmail dot com" 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/msg00355.txt.bz2 List-Id: ------- Comment #2 from stefaan dot deroeck at gmail dot com 2006-02-04 23:13 ------- When I saw "tr1" in the path, I assumed this referred to the technical report of the standards committee. I recognize a technical report is not a standard, thus I am simply inquiring if there is interest in adding this feature. I see code in , function _Destroy, that allows for optimizations when this support is available. A second example, I am myself writing a container class that allows allocation+construction of chunks of variable size at a time (aiming for lower computational cost). When erasing a single element from that container, its destruction would have to be done immediately, while its memory chunk would remain allocated. Some (expensive) bookkeeping has to be done to later facilitate correct destruction and deallocation of remaining elements when the container itself is destroyed. If has_trivial_destructor would be true_type, all this bookkeeping could be omitted, and on destruction of the container just the deallocation of all the used memory would be sufficient. I am no expert on the implementation details of existing containers, but I guess similar optimizations throughout libstdc++ are possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099