From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20795 invoked by alias); 27 Apr 2005 12:13:36 -0000 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 Received: (qmail 20129 invoked by uid 48); 27 Apr 2005 12:12:51 -0000 Date: Wed, 27 Apr 2005 12:13:00 -0000 Message-ID: <20050427121251.20128.qmail@sourceware.org> From: "pcarlini at suse dot de" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050426232113.21238.bduerner@gmx.de> References: <20050426232113.21238.bduerner@gmx.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug libstdc++/21238] conflicting "typedef __numpunct_cache<_CharT> __cache_type;" in std::numpunct makes specialization impossible X-Bugzilla-Reason: CC X-SW-Source: 2005-04/txt/msg03841.txt.bz2 List-Id: ------- Additional Comments From pcarlini at suse dot de 2005-04-27 12:12 ------- Thanks for the testcase. The issue is subtle and the typedef is only the tip of the iceberg: num_get (involved in >>(int)) uses the caching facilities provided by the primary numpunct, which a specialization simply misses, generally. As our library is currently designed, you cannot specialize numpunct and then use the primary num_get template with it. Maybe we have a slighlty different instance of the problem with istream members that we fixed for 4.0: we should have generic implementations of num_get (and num_put) not exploitng any numpunct-provided caching and efficient specializations for char and wchar_t. Seems doable, at the expense of a non-trivial code-growth, but maybe within the present ABI. Benjamin? -- What |Removed |Added ---------------------------------------------------------------------------- CC| |bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21238