From owner-svn-src-projects@FreeBSD.ORG Tue Mar 2 00:04:59 2010 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29166106566B; Tue, 2 Mar 2010 00:04:59 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1EB998FC14; Tue, 2 Mar 2010 00:04:57 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id BAA11129; Tue, 02 Mar 2010 01:45:14 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NmFIY-000PSI-Fj; Tue, 02 Mar 2010 01:45:14 +0200 Message-ID: <4B8C5189.40102@freebsd.org> Date: Tue, 02 Mar 2010 01:45:13 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: John Baldwin , Roman Divacky References: <201003012130.o21LUB0I022574@svn.freebsd.org> <201003011744.45410.jhb@freebsd.org> In-Reply-To: <201003011744.45410.jhb@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r204537 - in projects/clangbsd/contrib/libstdc++: include/ext src X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 00:04:59 -0000 on 02/03/2010 00:44 John Baldwin said the following: > On Monday 01 March 2010 4:30:11 pm Roman Divacky wrote: >> Author: rdivacky >> Date: Mon Mar 1 21:30:11 2010 >> New Revision: 204537 >> URL: http://svn.freebsd.org/changeset/base/204537 >> >> Log: >> Make this a little more like C++. Clang++ can grok all libstdc++ >> now. >> >> Modified: >> projects/clangbsd/contrib/libstdc++/include/ext/ropeimpl.h >> projects/clangbsd/contrib/libstdc++/src/locale-inst.cc >> >> Modified: projects/clangbsd/contrib/libstdc++/include/ext/ropeimpl.h >> > ============================================================================== >> --- projects/clangbsd/contrib/libstdc++/include/ext/ropeimpl.h Mon Mar 1 > 21:04:10 2010 (r204536) >> +++ projects/clangbsd/contrib/libstdc++/include/ext/ropeimpl.h Mon Mar 1 > 21:30:11 2010 (r204537) >> @@ -382,7 +382,7 @@ _GLIBCXX_BEGIN_NAMESPACE(__gnu_cxx) >> { >> _Rope_RopeLeaf<_CharT, _Alloc>* __l >> = (_Rope_RopeLeaf<_CharT, _Alloc>*)this; >> - __l->_Rope_RopeLeaf<_CharT, _Alloc>::~_Rope_RopeLeaf(); >> + __l->template _Rope_RopeLeaf<_CharT, _Alloc>::~_Rope_RopeLeaf(); >> _L_deallocate(__l, 1); >> break; >> } > > Hmm, this hurts my brain to have 'template ' in the middle of a dereference. Meet the beauty of modern C++. You can find a similar usage of 'typename' keyword too. > I also don't see why it should be needed. Hmm, I am not sure too, I think that the changed line could be simply written as follows without any ambiguity: __l->~_Rope_RopeLeaf(); but our base c++ complains about that construct, c++ 4.3, 4.4 and 4.5 from ports happily accept all three forms. clang++ from llvm-devel-2.7.r96348_1 didn't like any of the forms. I am not a C++ expert by any stretch, though. Here is some minimalistic test code: //************************************** template struct B { B() {} ~B() {} }; template struct S : public B { S() {} ~S() {} }; template struct C { void f() { S* s = reinterpret_cast*>(this); s->~S(); s->S::~S(); s->template S::~S(); } }; //************************************** >> Modified: projects/clangbsd/contrib/libstdc++/src/locale-inst.cc >> > ============================================================================== >> --- projects/clangbsd/contrib/libstdc++/src/locale-inst.cc Mon Mar 1 > 21:04:10 2010 (r204536) >> +++ projects/clangbsd/contrib/libstdc++/src/locale-inst.cc Mon Mar 1 > 21:30:11 2010 (r204537) >> @@ -180,11 +180,11 @@ _GLIBCXX_END_LDBL_NAMESPACE >> template class messages_byname; >> >> // ctype >> - inline template class __ctype_abstract_base; >> + template class __ctype_abstract_base; >> template class ctype_byname; >> >> // codecvt >> - inline template class __codecvt_abstract_base; >> + template class __codecvt_abstract_base; >> template class codecvt_byname; > > Perhaps try moving the 'template' before the 'inline'? Randomly dropping > 'inline' isn't really ideal I think. My C++ skills are a bit dusty but is there such a thing as 'inline class'? And that code (before the change) looks like an attempt at such thing via explicit template instantiation. -- Andriy Gapon