Re: Using C++ in GCC is OK
On 06/03/2010 09:47 PM, Robert Dewar wrote: Andrew Haley wrote: Right, but I didn't think there was any plan to convert en masse to C++ -- just to allow people to use it where appropriate. Apart from anything else, there's always a nonzero probablility of breaking something. It's the where appropriate that is the sneaky detail here :-) You're quite right. Perhaps I should have written where appropriate, in the course of making changes or additions for reasons not related simply to a change of language. Or something. :-) Andrew.
Re: Using C++ in GCC is OK
On 06/03/10 14:39, Steinar Bang wrote: Larry Evans cppljev...@suddenlink.net: claims that switch statements are faster than virtual function calls. That's not really interesting, is it? The overhead and downsides of virtual functions are well known. The upside is the possibility to use polymorphism to make frameworks. All kinds of pluggable frameworks. And as polymorphism goes, virtual functions are pretty cheap. Agreed; however, according the the 2nd link I provided: http://lists.boost.org/Archives/boost/2008/01/132074.php apparently speed is more important, and the 1st link: http://sourceforge.net/mailarchive/message.php?msg_name=3f49a9f41003031715g19a23b94p47ccec2251acd55%40mail.gmail.com suggested that the author had experienced problems with using switch vs virtual functions: P.P.S. Yes, the design you are using is a sore spot for me, I was bit with such things many years ago, it is one of my quests to educate people about the better ways now. I'd had some experience with compilers written in c++ that had large switch statements and wondered why the authors hadn't used virtual functions. IOW, I believed as you do; however, OvermindDl1's post caused me some doubt. I even checked clang's code to see if they used switch's or virtual functions and was surprised to learn they used switch's: http://llvm.org/svn/llvm-project/cfe/trunk/lib/Analysis/CFG.cpp (in particular, the CFGBuilder::Visit function). Hence, I figured there must be something I'm missing about the pros and cons of switch's vs virtual functions. -regards, Larry
Re: Using C++ in GCC is OK
On Thu, Jun 3, 2010 at 13:42, Andrew Haley a...@redhat.com wrote: I'll turn that into a question: does any GCC maintainer intend to convert working code into C++, with no substantive changes? Not me. Mostly new code and re-engineer only those parts where the value of C++ is a clear advantage. Diego.
Re: Using C++ in GCC is OK
Hi, What's about the friends in C++.. I think it should be forbidden by C++ coding-style, as it is mainly a sign of weak OO design to use them. Kai | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination
Re: Using C++ in GCC is OK
On Wed, 2 Jun 2010, Richard Guenther wrote: I'd like us to stick with C comments only. I defintely do not like a mix of both styles and I can't see an advantage of C++ comments. Agreed. Moving code between bits of the compiler should not mean creating ugly inconsistencies of formatting and I can see no good reason to convert existing comments. The same applies to all other aspects of formatting that are meaningful for both C and C++ code (such as the presence or position of whitespace in various cases): keep the existing practice that is usual for C code in GCC and the GNU project rather than adopting something else because it is said to be conventional for C++. -- Joseph S. Myers jos...@codesourcery.com
RE: Using C++ in GCC is OK
On Wed, 2 Jun 2010, Bingfeng Mei wrote: Converting to C++ is a major change. Does that justify to have a major release (5.0.0)? No. It's not in any way user-visible. In principle I agree with what Zack said in http://gcc.gnu.org/ml/gcc/2004-06/msg00243.html on version numbers; certainly an implementation detail can't justify such a change. -- Joseph S. Myers jos...@codesourcery.com
Re: Using C++ in GCC is OK
On Mon, 31 May 2010, Ian Lance Taylor wrote: I have written a proposed set of C++ coding conventions on the wiki at http://gcc.gnu.org/wiki/CppConventions This is only a preliminary proposal. It requires fleshing out and discussion. Comments welcome. I think the coding style warning option is an important piece to get in early before many C++ changes are made. I propose GCC 4.1 as the baseline GCC version that should be able to build versions of GCC built as C++. (PPL requires at least 4.0 so anyone building a Graphite-enabled compiler will have a 4.0 or later C++ compiler for the host, and 4.1 was more widely used than 4.0.) In addition to what I said about avoiding any bulk changes to formatting conventions, I think there should be a principle that changes of existing code to use C++ features should generally improve the maintainability and comprehensibility of the code. Conversion to standard C++ features where macros are used to emulate e.g. templates (STL or otherwise) or inheritance is much more desirable than converting qsort calls to std::sort since qsort is a well-understood standard C feature rather than a pile of GCC-specific macros. I repeat my request from the RM QA for a guide for reviewers on how to detect hidden overhead in the presence of C++ features. When will a structure/class/union be larger than might be expected in C? When will C++ statements involve runtime overhead that might not be expected from equivalent C statements? -- Joseph S. Myers jos...@codesourcery.com
Re: Using C++ in GCC is OK
Joseph S. Myers jos...@codesourcery.com writes: On Wed, 2 Jun 2010, Bingfeng Mei wrote: Converting to C++ is a major change. Does that justify to have a major release (5.0.0)? No. It's not in any way user-visible. In principle I agree with what Zack said in http://gcc.gnu.org/ml/gcc/2004-06/msg00243.html on version numbers; certainly an implementation detail can't justify such a change. I think we should change the gcc major release to 5 when we change the libstdc++.so major version number to 7. Ian
Re: Using C++ in GCC is OK
On Fri, Jun 4, 2010 at 3:55 PM, Ian Lance Taylor i...@google.com wrote: Joseph S. Myers jos...@codesourcery.com writes: I think we should change the gcc major release to 5 when we change the libstdc++.so major version number to 7. seconded. -- Gaby
Re: Using C++ in GCC is OK
On 4 June 2010 21:55, Ian Lance Taylor wrote: I think we should change the gcc major release to 5 when we change the libstdc++.so major version number to 7. I don't speak for the other libstdc++ maintainers, but I think that's a great idea.
Re: Using C++ in GCC is OK
Joseph S. Myers wrote: I repeat my request from the RM QA for a guide for reviewers on how to detect hidden overhead in the presence of C++ features. When will a structure/class/union be larger than might be expected in C? When will C++ statements involve runtime overhead that might not be expected from equivalent C statements? I think you're being unnecessarily fearful. A C++ structure/class/union will be larger than the same data structure written in C iff (a) it uses virtual functions, (b) it uses virtual inheritance. The former adds exactly one pointer to the very beginning of the structure, independent of the number of virtual functions, and even if there is (non-virtual) inheritance. The latter is forbidden by Ian's proposed coding standards. So, you do indeed want to avoid virtual functions in small, plentiful objects, as it can make them much bigger. Statements in the C subset of C++ have the same performance they would in C. (I'm sure someone can come up with an exception, but it will be vanishingly rare.) In C++, you can of course make what looks like simple code do something expensive; for example, you can make a + b be arbitrarily complex if a and b are instances of class types and you have overloaded +. But, if you just recompile your C program as C++, it doesn't suddenly get significantly bigger or slower. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
On 06/04/10 18:48, Mark Mitchell wrote: In C++, you can of course make what looks like simple code do something expensive; for example, you can make a + b be arbitrarily complex if a and b are instances of class types and you have overloaded +. And, in general, we are trying to avoid situations where seemingly simple code does something expensive, right? Jeff
Re: Using C++ in GCC is OK
Jeff Law wrote: In C++, you can of course make what looks like simple code do something expensive; for example, you can make a + b be arbitrarily complex if a and b are instances of class types and you have overloaded +. And, in general, we are trying to avoid situations where seemingly simple code does something expensive, right? Right. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
On Fri, Jun 4, 2010 at 7:55 PM, Jeff Law l...@redhat.com wrote: On 06/04/10 18:48, Mark Mitchell wrote: In C++, you can of course make what looks like simple code do something expensive; for example, you can make a + b be arbitrarily complex if a and b are instances of class types and you have overloaded +. And, in general, we are trying to avoid situations where seemingly simple code does something expensive, right? Yes. I trust reviewers to spot instances where people are being creative with expensive operations. -- Gaby
Re: Using C++ in GCC is OK
STL is good, but may surplus what GCC really needs, and will introduce many complex, uncontrollable C++ features. Personally, I think what GCC need most is an simple, generic, one layer containers of pointers to objects, with their iterators. Instead of containers of arbitrary types. That means the type parameters of the standard templates is restricted to pointer to objects. If you can't refrain from using STL and don't like the mess it may introduce, you can derive classes from instantiated standard templates with pointer as type parameters, and use the derived, template-free classes in rest of your code. The complexity of compiler determined that , in compiler, Java style C/C++ code may be unavoidable. In Java language, there are only two kinks of types, primitive types and reference types. When translated to C/C++, reference type are converted to pointer(to object) types. So, In a C/C++ program, if you only use primitive types and pointer(to object) types, I will call it Java style C/C++ code. You can use Java language to write arbitrary complex programs ? It may be true you can use Java style C/C++ code to write compiler, with some garbage collection mechanism, of course. But C++ may have an another advantage, it can use ADT(Abstract Data Type) to extend its set of primitive type, e.g., string. recommendation: 1. develop a host independent C++ library(I will call it GCC Foundation Class), providing the ADTs, containers, iterators, garbage collectors, pass manager, optimizer infrastructures, etc, suitable for GCC internal use. This is much like Qt. Qt essentially define a C++-like language itself. 2. gradually transform GCC code to use only the interface provided the library and use nothing else. -- 徐持恒(Chiheng Xu) Wuhan,China
Re: Using C++ in GCC is OK
On 06/02/2010 09:19 PM, DJ Delorie wrote: Robert Dewar de...@adacore.com writes: I would create a specific committee to reccommend a C++ coding standard (preferably based on one of the standard ones available, such as Google). Doing things in secret like that is not the Open Source Way. No, having endless bikeshed arguments is! a. GCC is not Open Source, and b. There's no reason not to produce a coding standard in private for public discussion and approval. Andrew.
Re: Using C++ in GCC is OK
On 06/01/2010 08:10 AM, Ian Lance Taylor wrote: Mark Mitchellm...@codesourcery.com writes: I am pleased to report that the GCC Steering Committee and the FSF have approved the use of C++ in GCC itself. Of course, there's no reason for us to use C++ features just because we can. The goal is a better compiler for users, not a C++ code base for its own sake. I would like to thank Mark and the SC for securing this agreement. Before we start to actually use C++, we need to determine a set of coding standards that will apply to use of C++ within GCC. I have written a proposed set of C++ coding conventions on the wiki at http://gcc.gnu.org/wiki/CppConventions This is only a preliminary proposal. It requires fleshing out and discussion. Comments welcome. Another rule came to mind after skimming Effective C++. It's obviously too late to convert casts to C++ casts, but we should never use C casts when a static_cast would not be enough. Or, at least, when a const_cast would be required. This should also be warned by the compiler. Paolo
Re: Using C++ in GCC is OK
On Thu, Jun 3, 2010 at 10:24 AM, Andrew Haley a...@redhat.com wrote: On 06/02/2010 09:19 PM, DJ Delorie wrote: Robert Dewar de...@adacore.com writes: I would create a specific committee to reccommend a C++ coding standard (preferably based on one of the standard ones available, such as Google). Doing things in secret like that is not the Open Source Way. No, having endless bikeshed arguments is! Indeed. It is, well, perhaps not surprising, but quite annoying (to me at least) that a possible move to C++ as implementation language of GCC is so much bigger news than all the amazing amounts of work done in the last few years on things like LTO, the vectorizer, IRA, etc... Ciao! Steven
Re: Using C++ in GCC is OK
Steven Bosscher wrote: Indeed. It is, well, perhaps not surprising, but quite annoying (to me at least) that a possible move to C++ as implementation language of GCC is so much bigger news than all the amazing amounts of work done in the last few years on things like LTO, the vectorizer, IRA, etc... And indeed you have to worry a bit that productive work on critical areas like this may be siphoned off developing, reviewing and testing changes from C to C++ whose benefit may often be much less than the work involved in doing them. Redoing working code in language A into language B is always a bit dubious. I would be very cautious and judicious in allowing changes to existing working code. New stuff is a different matter, and where there is an argument in any case for reengineering it may make sense. Ciao! Steven
Re: Using C++ in GCC is OK
On Thu, Jun 3, 2010 at 12:51 PM, Robert Dewar de...@adacore.com wrote: Steven Bosscher wrote: Indeed. It is, well, perhaps not surprising, but quite annoying (to me at least) that a possible move to C++ as implementation language of GCC is so much bigger news than all the amazing amounts of work done in the last few years on things like LTO, the vectorizer, IRA, etc... And indeed you have to worry a bit that productive work on critical areas like this may be siphoned off developing, reviewing and testing changes from C to C++ whose benefit may often be much less than the work involved in doing them. Redoing working code in language A into language B is always a bit dubious. I would be very cautious and judicious in allowing changes to existing working code. New stuff is a different matter, and where there is an argument in any case for reengineering it may make sense. Indeed ;) I'd like us to switch to the C / C++ common soon (thus, use C for stage1 and C++ for stage2 and stage3). That will help us sort out problems on the various host/target combinations that will surely exist. Then wait for this special very-nice-and-we-definitely-want-to-have-it patch that requires C++. And only then switch to C++. (you could argue that we can as well use C++ for stage1 and C for stage2 and stage3, that would work for me as well but would for example not allow starting to use C++ in the Java frontend only). With all this discussion I am more and more back-pedaling on the conversion to C++ - there is very much cleanup work to do inside GCC that does not require or benefit from C++. I'd not like to see people jumping on the let's convert GCC to C++ wagon leaving all the obvious existing problems unaddressed. We do not have an implementation language problem - we do have many others. Oh, I do like C++ and I can see some cases where ongoing cleanup might benefit a tiny bit from using C++ - mostly syntactic sugar-wise. But GCC will continue to exist even if we cannot use the STL for GCC 4.6. Richard.
Re: Using C++ in GCC is OK
On 06/03/2010 12:51 PM, Robert Dewar wrote: Steven Bosscher wrote: Indeed. It is, well, perhaps not surprising, but quite annoying (to me at least) that a possible move to C++ as implementation language of GCC is so much bigger news than all the amazing amounts of work done in the last few years on things like LTO, the vectorizer, IRA, etc... And indeed you have to worry a bit that productive work on critical areas like this may be siphoned off developing, reviewing and testing changes from C to C++ whose benefit may often be much less than the work involved in doing them. I know someone who works at a National Lab in the US (that will not be named) who had his management decide to rewrite a rather crucial (to that Lab's core business) 6+ million line Fortran system into C++. He told me that 11 years ago. When I met him again in February, I related to him that I referred to that project as the one with its return on investment date firmly in the 22nd century to *my* management. He replied that his management currently doesn't believe it will have a return on investment at all - they've written it off as a valuable learning experience. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran
Re: Using C++ in GCC is OK
On 06/03/2010 12:09 PM, Richard Guenther wrote: On Thu, Jun 3, 2010 at 12:51 PM, Robert Dewar de...@adacore.com wrote: Steven Bosscher wrote: Indeed. It is, well, perhaps not surprising, but quite annoying (to me at least) that a possible move to C++ as implementation language of GCC is so much bigger news than all the amazing amounts of work done in the last few years on things like LTO, the vectorizer, IRA, etc... And indeed you have to worry a bit that productive work on critical areas like this may be siphoned off developing, reviewing and testing changes from C to C++ whose benefit may often be much less than the work involved in doing them. Redoing working code in language A into language B is always a bit dubious. I would be very cautious and judicious in allowing changes to existing working code. New stuff is a different matter, and where there is an argument in any case for reengineering it may make sense. Indeed ;) I'd like us to switch to the C / C++ common soon (thus, use C for stage1 and C++ for stage2 and stage3). That will help us sort out problems on the various host/target combinations that will surely exist. Then wait for this special very-nice-and-we-definitely-want-to-have-it patch that requires C++. And only then switch to C++. (you could argue that we can as well use C++ for stage1 and C for stage2 and stage3, that would work for me as well but would for example not allow starting to use C++ in the Java frontend only). With all this discussion I am more and more back-pedaling on the conversion to C++ - there is very much cleanup work to do inside GCC that does not require or benefit from C++. I'd not like to see people jumping on the let's convert GCC to C++ wagon leaving all the obvious existing problems unaddressed. We do not have an implementation language problem - we do have many others. Right, but I didn't think there was any plan to convert en masse to C++ -- just to allow people to use it where appropriate. Apart from anything else, there's always a nonzero probablility of breaking something. I'll turn that into a question: does any GCC maintainer intend to convert working code into C++, with no substantive changes? Andrew.
Re: Using C++ in GCC is OK
On Thu, Jun 3, 2010 at 6:09 AM, Richard Guenther richard.guent...@gmail.com wrote: Indeed ;) I'd like us to switch to the C / C++ common soon (thus, use C for stage1 and C++ for stage2 and stage3). That will help us sort out problems on the various host/target combinations that will surely exist. Here is a concrete proposal: During stage 1 (meaning now), * require a C++ compiler as bootstrapping compiler * allow people to use C++ for *NEW* functionality. * don't allow conversion of existing working code unless it is required for NEW functionality * postpone conversions to later major releases. -- Gaby
Re: Using C++ in GCC is OK
On Thu, 2010-06-03 at 13:05 -0500, Gabriel Dos Reis wrote:
On Thu, Jun 3, 2010 at 6:09 AM, Richard Guenther
richard.guent...@gmail.com wrote:
Indeed ;) I'd like us to switch to the C / C++ common soon (thus,
use C for stage1 and C++ for stage2 and stage3). That will help
us sort out problems on the various host/target combinations that
will surely exist.
Here is a concrete proposal: During stage 1 (meaning now),
* require a C++ compiler as bootstrapping compiler
* allow people to use C++ for *NEW* functionality.
* don't allow conversion of existing working code unless it is
required for NEW functionality
This is a good concrete proposal, but I would permit some flexibility on
that point. Sometimes, converting existing code to C++ could perhaps not
be required, but be *very* useful to future C++ code (but I don't have
any concrete scenarii in mind).
* postpone conversions to later major releases.
Great.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Using C++ in GCC is OK
Mark Mitchell m...@codesourcery.com: I think virtual functions are on the edge; quite useful, but do result in the compiler adding a pointer to data objects and in uninlinable indirect calls at run-time. Therefore, I would avoid them in the initial subset of C++ used in GCC. Umm...? Virtual functions are _the_ core C++ feature for creating OO frameworks. Allowing C++ but avoiding virtual functions seems odd to me.
Re: Using C++ in GCC is OK
Larry Evans cppljev...@suddenlink.net: claims that switch statements are faster than virtual function calls. That's not really interesting, is it? The overhead and downsides of virtual functions are well known. The upside is the possibility to use polymorphism to make frameworks. All kinds of pluggable frameworks. And as polymorphism goes, virtual functions are pretty cheap.
Re: Using C++ in GCC is OK
Steinar Bang s...@dod.no writes: Mark Mitchell m...@codesourcery.com: I think virtual functions are on the edge; quite useful, but do result in the compiler adding a pointer to data objects and in uninlinable indirect calls at run-time. Therefore, I would avoid them in the initial subset of C++ used in GCC. Umm...? Virtual functions are _the_ core C++ feature for creating OO frameworks. GCC is a compiler, not an OO framework. I expect we are going to to want to use virtual functions in a few places, but I don't see why we would ever use them widely. In the gccgo frontend I use them in the IR, but I don't see why gcc proper would need or want to adopt that given the existing IRs. The only other place I use them in the gccgo frontend is in the import reader, where I use them to read either import data from a couple of different types of input sources. In gcc we currently use various structs of hook functions which could be replaced by virtual functions, but as Jakub has pointed out that would introduce an additional memory read to each use of a hook. If we were starting from scratch we would probably use virtual functions, but going from where we are not to using virtual function doesn't seem like a win. Ian
RE: Using C++ in GCC is OK
On Thu, Jun 3, 2010 at 6:09 AM, Richard Guenther richard.guent...@gmail.com wrote: Indeed ;) I'd like us to switch to the C / C++ common soon (thus, use C for stage1 and C++ for stage2 and stage3). That will help us sort out problems on the various host/target combinations that will surely exist. Here is a concrete proposal: During stage 1 (meaning now), * require a C++ compiler as bootstrapping compiler * allow people to use C++ for *NEW* functionality. * don't allow conversion of existing working code unless it is required for NEW functionality * postpone conversions to later major releases. Pragmatism, I like it.
Re: Using C++ in GCC is OK
Andrew Haley wrote: Right, but I didn't think there was any plan to convert en masse to C++ -- just to allow people to use it where appropriate. Apart from anything else, there's always a nonzero probablility of breaking something. It's the where appropriate that is the sneaky detail here :-) I'll turn that into a question: does any GCC maintainer intend to convert working code into C++, with no substantive changes? Andrew.
Re: Using C++ in GCC is OK
Steinar Bang wrote: Mark Mitchell m...@codesourcery.com: I think virtual functions are on the edge; quite useful, but do result in the compiler adding a pointer to data objects and in uninlinable indirect calls at run-time. Therefore, I would avoid them in the initial subset of C++ used in GCC. Umm...? Virtual functions are _the_ core C++ feature for creating OO frameworks. Allowing C++ but avoiding virtual functions seems odd to me. Not at all, data abstraction and inheritance do not depend on virtual functions. You can do a lot without allowing dynamic dispatching. Of course there are some cases where dynamic dispatching makes things easier, but to regard it as *the* core feature of C++ seems dubious to me (the STL in general relies on templates, but not dynamic dispatching as far as I know).
Re: Using C++ in GCC is OK
On 3 June 2010 20:35, Steinar Bang wrote: Mark Mitchell m...@codesourcery.com: I think virtual functions are on the edge; quite useful, but do result in the compiler adding a pointer to data objects and in uninlinable indirect calls at run-time. Therefore, I would avoid them in the initial subset of C++ used in GCC. Umm...? Virtual functions are _the_ core C++ feature for creating OO frameworks. Allowing C++ but avoiding virtual functions seems odd to me. C++ is not an OO language. http://www2.research.att.com/~bs/bs_faq.html#Object-Oriented-language
Re: Using C++ in GCC is OK
Basile Starynkevitch bas...@starynkevitch.net writes:
On Tue, 2010-06-01 at 19:49 -0500, Gabriel Dos Reis wrote:
(2) we should prefer standard solution over home-grown hacks, unless
there is a clear demonstration of value. For example, it would be
unwise to prefer our current VEC_xxx over std::vector. Conversely,
we should probably have our own hash table, since there is none in
C++98.
I am not entirely convinced of that. VEC is supported not only by
infamous vec.h macros (which we surely want to replace by some template,
possibly std::vec) but also by gengtype (and the Gcc Garbage Collector).
As you say, gengtype includes specific support for VEC. Using
std::vector instead will require some work in gengtype, but not too
much. Currently gengtype generates code like this for a VEC:
size_t l0 = (size_t)(((*x).base).num);
for (i0 = 0; i0 != l0; i0++) {
if ((*x).base.vec[i0].jump_functions != NULL) {
It should be entirely feasible to make it generate std::vector
accessor functions instead.
Ian
Re: Using C++ in GCC is OK
2010/6/2 Basile Starynkevitch bas...@starynkevitch.net: I am not entirely convinced of that. VEC is supported not only by infamous vec.h macros (which we surely want to replace by some template, possibly std::vec) but also by gengtype (and the Gcc Garbage Collector). I strongly believe we will need a garbage collector (perhaps improving the current one). So we surely will continue to need garbage collected vectors (with all the variants existing in today's GCC). How would we handle these in a C++ GCC? I have no clear ideas on that today. Perhaps we might See http://gcc.gnu.org/wiki/gcc-in-cxx , section Major TODO: work out the details of using STL containers with GC allocated objects. This means teaching gengtype how to generate code to traverse STL containers, which would then be used during GC. This is not a task for the faint-hearted. Basically we can teach gengtype to walk std::vector. But I don't see how we can avoid dependency in gengtype on vector internal structures (_M_impl) and similar, and if that would not preclude building gcc with 3rd party standard library (which would be a real concern). c. add special annotations on every use of our vectors. BTW, this is what our current practice of vec.h already do. We can make gengtype recognize std::vector variables even without GTY annotations. -- Laurynas
Re: Using C++ in GCC is OK
Laurynas Biveinis laurynas.bivei...@gmail.com writes:
2010/6/2 Ian Lance Taylor i...@google.com:
As you say, gengtype includes specific support for VEC. Using
std::vector instead will require some work in gengtype, but not too
much. Currently gengtype generates code like this for a VEC:
size_t l0 = (size_t)(((*x).base).num);
for (i0 = 0; i0 != l0; i0++) {
if ((*x).base.vec[i0].jump_functions != NULL) {
It should be entirely feasible to make it generate std::vector
accessor functions instead.
Ian, do you have an idea on how to avoid _M_impl dependency in
gengtype or what else to do about it?
Because we can trivially make gengtype mark the vector itself and mark
whatever was put into vector, but not _M_impl.
I don't think I understand the question. _M_impl is a field of the
vector itself. It's not allocated separately.
Ian
Re: Using C++ in GCC is OK
2010/6/2 Ian Lance Taylor i...@google.com: Ian, do you have an idea on how to avoid _M_impl dependency in gengtype or what else to do about it? Because we can trivially make gengtype mark the vector itself and mark whatever was put into vector, but not _M_impl. I don't think I understand the question. _M_impl is a field of the vector itself. It's not allocated separately. But the _M_impl._M_start is allocated separately. -- Laurynas
Re: Using C++ in GCC is OK
On 06/01/2010 04:11 PM, Ian Lance Taylor wrote:
In the gccgo IR I don't represent everything with a single type.
Instead, I use a separate base class for types, expressions and
statements (in Go there is more of a distinction between expressions
and statements than there is in C/C++). I represent specific types,
etc., as child classes. The base class uses a protected virtual
function interface which the child classes implement.
However, as you observe, some code does need to use pattern matching,
so that approach is awkward to use by itself. I also declare an enum
in the base class, and so given a pointer to the base class you can
examine that enum to know which kind of object you have.
This made me wondering if we are looking at the C++ conversion from the
wrong point of view.
In particular, I wonder if the best use of C++ wouldn't be a set of
functions (including templates, etc.) implementing a kind of RTTI with a
less verbose syntax than what we have now.
Just to give an idea:
templateenum tree_code CODE
static inline bool isa(tree t)
{
return TREE_CODE (t) == CODE;
}
templateenum tree_node_structure_enum TS
static inline bool isa(tree t)
{
return CODE_CONTAINS_STRUCT (TREE_CODE (t), TS);
}
templateenum tree_code_class CLASS
static inline bool isa(tree t)
{
return TREE_CODE_CLASS (TREE_CODE (t)) == CLASS;
}
templateenum rtx_code CODE
static inline bool isa(rtx t)
{
return GET_RTX_CODE (t) == CODE;
}
This is just a stupid example of course, but my point is: are we sure
that the main benefit of C++ comes from object-orientation?
Paolo
Re: Using C++ in GCC is OK
On Wed, Jun 02, 2010 at 08:28:53AM +0200, Laurynas Biveinis wrote: See http://gcc.gnu.org/wiki/gcc-in-cxx , section Major TODO: work out the details of using STL containers with GC allocated objects. This means teaching gengtype how to generate code to traverse STL containers, which would then be used during GC. This is not a task for the faint-hearted. Basically we can teach gengtype to walk std::vector. But I don't see how we can avoid dependency in gengtype on vector internal structures (_M_impl) and similar, and if that would not preclude building gcc with 3rd party standard library (which would be a real concern). But do we really want to use std::vector? The vec.h, appart from having ugly syntactic sugar, seems to be more space efficient, has better aliasing properties (given that it is just one pointer, you can e.g. use restrict on it easily) and seems to have more operations than std::vector has (std::vector has 3 pointers, while vec is just one pointer + 2 unsigned ints, I don't see counterparts to operations like VEC_quick_push or VEC_unordered_remove). Jakub
Re: Using C++ in GCC is OK
On Tue, Jun 1, 2010 at 6:58 PM, Ian Lance Taylor i...@google.com wrote: Richard Guenther richard.guent...@gmail.com writes: Overall the wiki document looks good. I'd like to disallow * Operators may only be overloaded for types which implement numeric values, where the overloaded operators implement the usual numeric semantics. though. My thinking here is that it would be reasonable to implement real_arithmetic and mpfr/mpc using overloaded operators. I could certainly be wrong. It will hide the cost which is IMHO not wanted. Richard. I'd also like to avoid destructors where possible as we want as many core data types to be POD. I adjusted the wiki accordingly. Ian
Re: Using C++ in GCC is OK
On Tue, Jun 1, 2010 at 6:37 PM, Robert Dewar de...@adacore.com wrote: Richard Guenther wrote: On Tue, Jun 1, 2010 at 4:48 PM, Mark Mitchell m...@codesourcery.com wrote: Ian Lance Taylor wrote: I have written a proposed set of C++ coding conventions on the wiki at http://gcc.gnu.org/wiki/CppConventions This is only a preliminary proposal. It requires fleshing out and discussion. Thank you for volunteering to do this. How would you like to receive comments? Directly on the Wiki page, or by email? Overall the wiki document looks good. I'd like to disallow * Operators may only be overloaded for types which implement numeric values, where the overloaded operators implement the usual numeric semantics. which do you want to disallow, the may or the only, not clear The may. Richard.
Re: Using C++ in GCC is OK
On Wed, Jun 2, 2010 at 1:38 AM, Ian Lance Taylor i...@google.com wrote: DJ Delorie d...@redhat.com writes: I did mean that all virtual functions should be protected. This forbids the most useful thing about virtual functions - letting child classes implement a public ABI defined by the base class. There are really two cases to consider, and actually the coding standard should describe this. 1) The parent class consists only of pure virtual methods. In that case it is perfectly reasonable for those methods to be public. 2) The parent class does not consist only of pure virtual methods. In that case I am arguing that all virtual methods should be protected. In cases where the virtual method implements something which is part of the public interface, there should be a public method which calls the protected method. The reason for the latter case is that the parent class is providing a public interface, and it is doing so by using a separate interface defined by child classes. The two interfaces are obviously related, but they are not the same. In particular, as new child classes are implemented and the parent class interface evolves, they evolve in different ways. Keeping the two interfaces separate from the start avoids confusion and makes it easy to redesign either interface separately from the other one. * All data members should be private. * All data members should have names which end with an underscore. This makes all structures illegal. I'd remove the first All and replace the second with Private: This text only refers to classes. As the convention says in the following major bullet, structs are handled as they are today. I don't agree that *all* data members of classes should be private. It's not always appropriate - it depends on the design of the class. I'd hate to be forced to do this for every datum: int count; int get_count (); void set_count (int); That gets messier when the datum are pointers. foo-bounds-left is cleaner than foo-get_bounds()-get_left(). I think I'm advocating a reasonable position here. With our current data structures such as tree and rtx, we generally do not use direct field access, but always use accessors. For cases where direct field access is appropriate can use structs. What do other people think? * Use C-style comments for multi-line comments, and C++-style comments for single-line comments. I'm not sure i agree with this, because I don't see anything wrong with multi-line C++-style comments. It assumes your editor can do block-reformatting while preserving the comment syntax. I've had too many // cases of Emacs guessing wrong // and putting // throughout a reformatted // block. I don't see why the coding standard should prohibit using a good editor, but I'm willing to hear what other people think. I'd like us to stick with C comments only. I defintely do not like a mix of both styles and I can't see an advantage of C++ comments. Richard. Ian
Re: Using C++ in GCC is OK
I'd like us to stick with C comments only. I defintely do not like a mix of both styles and I can't see an advantage of C++ comments. It indeed seems to fall into the buy-us-nothing category. -- Eric Botcazou
Re: Using C++ in GCC is OK
On Wed, Jun 2, 2010 at 2:49 AM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Tue, Jun 1, 2010 at 7:38 PM, DJ Delorie d...@redhat.com wrote: Hargett, Matt matt.harg...@bluecoat.com writes: As noted earlier I think we do want to use some STL classes. I agree with Mark's earlier declaration that it is relatively straight-forward, low-hanging fruit to replace VEC_* I do not object to simple and obvious uses of STL to replace equivalent functionality, but I've seen code that layers STL over STL over STL to the point where the code is very difficult to understand. Hence, my recommendation to avoid STL *at first*. I think that would be most unproductive and misguided. The first thing we should do is (1) resist NIH Then (2) we should prefer standard solution over home-grown hacks, unless there is a clear demonstration of value. For example, it would be unwise to prefer our current VEC_xxx over std::vector. Conversely, we should probably have our own hash table, since there is none in C++98. Well, on the one hand I agree - but on the other hand I see people eagerly waiting to be the first to post patches to convert all VEC uses that allocate from the heap(!) (yes - we can't use STL for GC allocated stuff!), leaving us with files that use a mix of stl::vector and VEC. VEC is clearly superior here in that it provides a general vector implementation which can allocate from GC space, heap or even the stack. Why switch to a less capable implementation? OTOH for pointer-map and pointer-set I see little value keeping it (it can't be used for GC allocated stuff), so std::map and std::set are a perfect fit. For libiberty hashtables the same issues exist as with VEC - furthermore there is no real hashtable implementation in C++98, so there isn't even a 1:1 thing to substitute. Richard. It teaches caution against over-abstracting and arbitrary complexity. avoiding over-abstracting is not reached by banning standard solutions -- that only lead to more brittle and bug-ridden hacks. The way we avoid over-abstracting is to have people write simple codes, and reviewers use their best judgments.
RE: Using C++ in GCC is OK
Converting to C++ is a major change. Does that justify to have a major release (5.0.0)? Bingfeng -Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Richard Guenther Sent: 02 June 2010 10:36 To: Gabriel Dos Reis Cc: DJ Delorie; Hargett, Matt; gcc@gcc.gnu.org Subject: Re: Using C++ in GCC is OK On Wed, Jun 2, 2010 at 2:49 AM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Tue, Jun 1, 2010 at 7:38 PM, DJ Delorie d...@redhat.com wrote: Hargett, Matt matt.harg...@bluecoat.com writes: As noted earlier I think we do want to use some STL classes. I agree with Mark's earlier declaration that it is relatively straight-forward, low-hanging fruit to replace VEC_* I do not object to simple and obvious uses of STL to replace equivalent functionality, but I've seen code that layers STL over STL over STL to the point where the code is very difficult to understand. Hence, my recommendation to avoid STL *at first*. I think that would be most unproductive and misguided. The first thing we should do is (1) resist NIH Then (2) we should prefer standard solution over home-grown hacks, unless there is a clear demonstration of value. For example, it would be unwise to prefer our current VEC_xxx over std::vector. Conversely, we should probably have our own hash table, since there is none in C++98. Well, on the one hand I agree - but on the other hand I see people eagerly waiting to be the first to post patches to convert all VEC uses that allocate from the heap(!) (yes - we can't use STL for GC allocated stuff!), leaving us with files that use a mix of stl::vector and VEC. VEC is clearly superior here in that it provides a general vector implementation which can allocate from GC space, heap or even the stack. Why switch to a less capable implementation? OTOH for pointer-map and pointer-set I see little value keeping it (it can't be used for GC allocated stuff), so std::map and std::set are a perfect fit. For libiberty hashtables the same issues exist as with VEC - furthermore there is no real hashtable implementation in C++98, so there isn't even a 1:1 thing to substitute. Richard. It teaches caution against over-abstracting and arbitrary complexity. avoiding over-abstracting is not reached by banning standard solutions -- that only lead to more brittle and bug-ridden hacks. The way we avoid over-abstracting is to have people write simple codes, and reviewers use their best judgments.
Re: Using C++ in GCC is OK
On 02/06/2010 00:38, Ian Lance Taylor wrote: DJ Delorie d...@redhat.com writes: * Use C-style comments for multi-line comments, and C++-style comments for single-line comments. I'm not sure i agree with this, because I don't see anything wrong with multi-line C++-style comments. It assumes your editor can do block-reformatting while preserving the comment syntax. I've had too many // cases of Emacs guessing wrong // and putting // throughout a reformatted // block. I don't see why the coding standard should prohibit using a good editor, but I'm willing to hear what other people think. I don't think the coding standard should be dragged into the religious wars over editor choices. cheers, DaveK
Re: Using C++ in GCC is OK
Well, on the one hand I agree - but on the other hand I see people eagerly waiting to be the first to post patches to convert all VEC uses that allocate from the heap(!) (yes - we can't use STL for GC allocated stuff!), leaving us with files that use a mix of stl::vector and VEC. VEC is clearly superior here in that it provides a general vector implementation which can allocate from GC space, heap or even the stack. Why switch to a less capable implementation? OTOH for pointer-map and pointer-set I see little value keeping it (it can't be used for GC allocated stuff), so std::map and std::set are a perfect fit. Seriously? Hashtable vs. red-black tree looks like a major change. Remember that pointer-sets in the beginning were introduced because they were faster than libiberty hashtables. http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01227.html For libiberty hashtables the same issues exist as with VEC - furthermore there is no real hashtable implementation in C++98, so there isn't even a 1:1 thing to substitute. Right. But importing libstdc++'s hash_set/hash_map and use that instead would probably give a decent speedup, so why not do that? Personally, the only sensible change that I see is to change our macro-based pseudo iterators to be real STL iterators, and using STL algorithms such as sort when applicable. This BTW means that iterator operator== and operator++ would be a special case in which operator overloading would be allowed. Similarly, we could still use gengtype's VEC machinery but with a template-based implementation instead of doing everything in macros; and with a C++ usage flavor. Interestingly, this would push C++ usage in exactly the opposite direction: the only feature we'd use (though in a controlled manner) would be templates. I know Ian doesn't like custom containers, and I agree, but our GC requirements make things a bit clumsy. Paolo
Re: Using C++ in GCC is OK
Hi, On Tue, 1 Jun 2010, Ian Lance Taylor wrote: * Use C-style comments for multi-line comments, and C++-style comments for single-line comments. I'm not sure i agree with this, because I don't see anything wrong with multi-line C++-style comments. It assumes your editor can do block-reformatting while preserving the comment syntax. I've had too many // cases of Emacs guessing wrong // and putting // throughout a reformatted // block. I don't see why the coding standard should prohibit using a good editor, Rather they should not prohibit the use of non-good editors. but I'm willing to hear what other people think. I always liked the GNU coding standard for comments, to not put the comment leader onto each line (a '*' in C comments), for specifically the reason of easier formatting with random editors. Allowing multi-line C++ comments would reintroduce this awkwardness that I dislike in some other projects. Ciao, Michael.
Re: Using C++ in GCC is OK
Hi, On Wed, 2 Jun 2010, Richard Guenther wrote: Well, on the one hand I agree - but on the other hand I see people eagerly waiting to be the first to post patches to convert all VEC uses that allocate from the heap(!) (yes - we can't use STL for GC allocated stuff!), leaving us with files that use a mix of stl::vector and VEC. VEC is clearly superior here in that it provides a general vector implementation which can allocate from GC space, heap or even the stack. Why switch to a less capable implementation? OTOH for pointer-map and pointer-set I see little value keeping it (it can't be used for GC allocated stuff), so std::map and std::set are a perfect fit. Except of course that our STL map and set are binary tree based and pointer_map/set are hash based, and hence require less lookups in most cases. Ciao, Michael.
Re: Using C++ in GCC is OK
On Tue, Jun 1, 2010 at 11:43 PM, Basile Starynkevitch bas...@starynkevitch.net wrote: On Tue, 2010-06-01 at 19:49 -0500, Gabriel Dos Reis wrote: (2) we should prefer standard solution over home-grown hacks, unless there is a clear demonstration of value. For example, it would be unwise to prefer our current VEC_xxx over std::vector. Conversely, we should probably have our own hash table, since there is none in C++98. I am not entirely convinced of that. VEC is supported not only by infamous vec.h macros (which we surely want to replace by some template, possibly std::vec) but also by gengtype (and the Gcc Garbage Collector). I strongly believe we will need a garbage collector (perhaps improving the current one). So we surely will continue to need garbage collected vectors (with all the variants existing in today's GCC). std::vector can be garbage collected. How would we handle these in a C++ GCC? I have no clear ideas on that today. Perhaps we might a. have our own vector template which is almost exactly like std::vector but named differently except that it is specially supported by GGC gengtype. b. add special annotations (maybe attributes or pragmas or GTY macros invocations or something else...) inside the code of the definition of std::vec template (perhaps inside libstdc++-v3/include/std/vector) to no, you don't want to do this because we wan't to start with any C++98 compiler including GCC's we released before the switch. add GTY support. However, this makes our compiler less able to use some other's vendor std::vec c. add special annotations on every use of our vectors. BTW, this is what our current practice of vec.h already do. But still I don't understand how precisely we would have garbage collected vectors, or vectors of garbage collected pointers. We need them. And if possible, the solution should be generic enough to work for any other standard C++ container (i.e. maps, ...).
Re: Using C++ in GCC is OK
On Wed, Jun 2, 2010 at 1:22 AM, Ian Lance Taylor i...@google.com wrote:
Basile Starynkevitch bas...@starynkevitch.net writes:
On Tue, 2010-06-01 at 19:49 -0500, Gabriel Dos Reis wrote:
(2) we should prefer standard solution over home-grown hacks, unless
there is a clear demonstration of value. For example, it would be
unwise to prefer our current VEC_xxx over std::vector. Conversely,
we should probably have our own hash table, since there is none in
C++98.
I am not entirely convinced of that. VEC is supported not only by
infamous vec.h macros (which we surely want to replace by some template,
possibly std::vec) but also by gengtype (and the Gcc Garbage Collector).
As you say, gengtype includes specific support for VEC. Using
std::vector instead will require some work in gengtype, but not too
much. Currently gengtype generates code like this for a VEC:
size_t l0 = (size_t)(((*x).base).num);
for (i0 = 0; i0 != l0; i0++) {
if ((*x).base.vec[i0].jump_functions != NULL) {
It should be entirely feasible to make it generate std::vector
accessor functions instead.
parsing class definition is sufficiently simpler than parsing full C++.
We can just enhance gengtype pseudo-parse any C++ standard header
to write out the object layout of any struct we are interested in
(e.g. std::vector).
The pseudo-parser would have to skip most top-level declarations except those
that declare types.
Re: Using C++ in GCC is OK
On Mon, 2010-05-31 at 08:40 -0700, Mark Mitchell wrote: Eric Botcazou wrote: We do require long long for 32-64 cross compilers. Right, only in this case, and I don't see why this should be changed with the transition to C++, that's orthogonal. I agree. We need it for any configuration that defines need_64bit_hwint=yes in config.gcc. Those are mostly 64-bit (or include a variant that is), but I don't see anything that restricts it to that). R
Re: Using C++ in GCC is OK
On Wed, Jun 2, 2010 at 2:44 AM, Paolo Bonzini bonz...@gnu.org wrote: In particular, I wonder if the best use of C++ wouldn't be a set of functions (including templates, etc.) implementing a kind of RTTI with a less verbose syntax than what we have now. Agreed. I don't agree with the rejection of simple function templates and class templates. Many macro-games we currently play, are good candidates as you shown in your message. Furthermore, many of the casts are there because C does not give us 'generic type macros' that scale. In the guidelines, I would like to include: (1) cast should be minimized (2) if you define a class template used mostly with pointer type arguments, consider specializing for void* (or const void*) and define all other pointer specialization in terms of that.
Re: Using C++ in GCC is OK
On Wed, Jun 2, 2010 at 4:19 AM, Richard Guenther richard.guent...@gmail.com wrote: I'd like us to stick with C comments only. I defintely do not like a mix of both styles and I can't see an advantage of C++ comments. It does not have a 'gotcha' for commenting out codes.
Re: Using C++ in GCC is OK
On Wed, Jun 2, 2010 at 3:04 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Wed, Jun 2, 2010 at 4:19 AM, Richard Guenther richard.guent...@gmail.com wrote: I'd like us to stick with C comments only. I defintely do not like a mix of both styles and I can't see an advantage of C++ comments. It does not have a 'gotcha' for commenting out codes. Neither does #if 0 #endif which we currently use. Richard.
Re: Using C++ in GCC is OK
On Wed, Jun 2, 2010 at 4:35 AM, Richard Guenther richard.guent...@gmail.com wrote: On Wed, Jun 2, 2010 at 2:49 AM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Tue, Jun 1, 2010 at 7:38 PM, DJ Delorie d...@redhat.com wrote: Hargett, Matt matt.harg...@bluecoat.com writes: As noted earlier I think we do want to use some STL classes. I agree with Mark's earlier declaration that it is relatively straight-forward, low-hanging fruit to replace VEC_* I do not object to simple and obvious uses of STL to replace equivalent functionality, but I've seen code that layers STL over STL over STL to the point where the code is very difficult to understand. Hence, my recommendation to avoid STL *at first*. I think that would be most unproductive and misguided. The first thing we should do is (1) resist NIH Then (2) we should prefer standard solution over home-grown hacks, unless there is a clear demonstration of value. For example, it would be unwise to prefer our current VEC_xxx over std::vector. Conversely, we should probably have our own hash table, since there is none in C++98. Well, on the one hand I agree - but on the other hand I see people eagerly waiting to be the first to post patches to convert all VEC uses that allocate from the heap(!) (yes - we can't use STL for GC allocated stuff!), leaving us with files that use a mix of stl::vector and VEC. VEC is clearly superior here in that it provides a general vector implementation which can allocate from GC space, heap or even the stack. Why switch to a less capable implementation? std::vector takes an allocator parameter -- wihch can give storage from GC. OTOH for pointer-map and pointer-set I see little value keeping it (it can't be used for GC allocated stuff), so std::map and std::set are a perfect fit. std::set and std::map are binary trees. For libiberty hashtables the same issues exist as with VEC - furthermore there is no real hashtable implementation in C++98, so there isn't even a 1:1 thing to substitute. yes, I did not propose to replace them with a C++98 standard container.
Re: Using C++ in GCC is OK
Jakub Jelinek ja...@redhat.com writes: But do we really want to use std::vector? The vec.h, appart from having ugly syntactic sugar, seems to be more space efficient, has better aliasing properties (given that it is just one pointer, you can e.g. use restrict on it easily) and seems to have more operations than std::vector has (std::vector has 3 pointers, while vec is just one pointer + 2 unsigned ints, I don't see counterparts to operations like VEC_quick_push or VEC_unordered_remove). std::vector can be printed by gdb today. Admittedly we could add similar support for VEC. The std::vector operations are shorter and easier to read and write. VEC_quick_push is implemented by std::vector::reserve and std::vector::push. VEC_unordered_remove is easy enough to write using std::vector::operator[] and std::vector::pop. Ian
Re: Using C++ in GCC is OK
Laurynas Biveinis laurynas.bivei...@gmail.com writes: 2010/6/2 Ian Lance Taylor i...@google.com: Ian, do you have an idea on how to avoid _M_impl dependency in gengtype or what else to do about it? Because we can trivially make gengtype mark the vector itself and mark whatever was put into vector, but not _M_impl. I don't think I understand the question. _M_impl is a field of the vector itself. It's not allocated separately. But the _M_impl._M_start is allocated separately. But that's the part which we can scan in the code generated by gengtype, by having it use std::vector methods in the generated loop. Ian
Re: Using C++ in GCC is OK
Richard Guenther richard.guent...@gmail.com writes: On Tue, Jun 1, 2010 at 6:58 PM, Ian Lance Taylor i...@google.com wrote: Richard Guenther richard.guent...@gmail.com writes: Overall the wiki document looks good. I'd like to disallow * Operators may only be overloaded for types which implement numeric values, where the overloaded operators implement the usual numeric semantics. though. My thinking here is that it would be reasonable to implement real_arithmetic and mpfr/mpc using overloaded operators. I could certainly be wrong. It will hide the cost which is IMHO not wanted. I agree that that is the usual problem with overloaded operators. I don't really agree that that is a problem in this specific case. We have to do those operations anyhow. I don't think the ease of writing the code is going to cause us to do extra operations in the target floating point format. Ian
Re: Using C++ in GCC is OK
On 06/02/2010 03:01 PM, Gabriel Dos Reis wrote: In the guidelines, I would like to include: (2) if you define a class template used mostly with pointer type arguments, consider specializing for void* (or const void*) and define all other pointer specialization in terms of that. I have no idea what you're saying. :-) What do you mean by define all other pointer specialization in terms of that? Wouldn't specializing on T* just work? Paolo
Re: Using C++ in GCC is OK
On 06/02/2010 03:54 PM, Ian Lance Taylor wrote: Richard Guentherrichard.guent...@gmail.com writes: On Tue, Jun 1, 2010 at 6:58 PM, Ian Lance Taylori...@google.com wrote: Richard Guentherrichard.guent...@gmail.com writes: Overall the wiki document looks good. I'd like to disallow * Operators may only be overloaded for types which implement numeric values, where the overloaded operators implement the usual numeric semantics. though. My thinking here is that it would be reasonable to implement real_arithmetic and mpfr/mpc using overloaded operators. I could certainly be wrong. It will hide the cost which is IMHO not wanted. I agree that that is the usual problem with overloaded operators. I don't really agree that that is a problem in this specific case. We have to do those operations anyhow. I don't think the ease of writing the code is going to cause us to do extra operations in the target floating point format. As mentioned elsewhere in this huge thread, I'd like to allow operator++ (preincrement), operator==, operator!= and operator* (unary) for iterators. That is, only forward input operators. We're going to use them anyway for the STL, so we might as well use them for bitmaps etc. Paolo
Re: Using C++ in GCC is OK
On Wed, Jun 2, 2010 at 9:05 AM, Paolo Bonzini bonz...@gnu.org wrote:
On 06/02/2010 03:01 PM, Gabriel Dos Reis wrote:
In the guidelines, I would like to include:
(2) if you define a class template used mostly with pointer type
arguments,
consider specializing for void* (or const void*) and define all
other
pointer specialization in terms of that.
I have no idea what you're saying. :-) What do you mean by define all
other pointer specialization in terms of that? Wouldn't specializing on T*
just work?
yes, it would work, but it may duplicate same executable several times
for those concerned about code size.
Imagine a vector class template
templatetypename T struct Vec;// primary template
// specialize for T=void*
template
struct Vecvoid* {
void* get(int i) { }
// ...
};
// specialize all T* in terms of void*
templatetypename T
struct VecT* : private VecVoid* {
typedef VecVoid* Impl;
// define all operations in as forwarding functions to Impl
T* get(int i) { return static_castT*(Impl::get(i));
// and so on.
};
you only have one ultimate implementation, all others being simple inline
fowarding functions. This is for people concerned about code size.
Re: Using C++ in GCC is OK
Now that we are talking about STL templates: What about boost?
On Wed, Jun 2, 2010 at 11:22 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Wed, Jun 2, 2010 at 9:05 AM, Paolo Bonzini bonz...@gnu.org wrote:
On 06/02/2010 03:01 PM, Gabriel Dos Reis wrote:
In the guidelines, I would like to include:
(2) if you define a class template used mostly with pointer type
arguments,
consider specializing for void* (or const void*) and define all
other
pointer specialization in terms of that.
I have no idea what you're saying. :-) What do you mean by define all
other pointer specialization in terms of that? Wouldn't specializing on T*
just work?
yes, it would work, but it may duplicate same executable several times
for those concerned about code size.
Imagine a vector class template
templatetypename T struct Vec; // primary template
// specialize for T=void*
template
struct Vecvoid* {
void* get(int i) { }
// ...
};
// specialize all T* in terms of void*
templatetypename T
struct VecT* : private VecVoid* {
typedef VecVoid* Impl;
// define all operations in as forwarding functions to Impl
T* get(int i) { return static_castT*(Impl::get(i));
// and so on.
};
you only have one ultimate implementation, all others being simple inline
fowarding functions. This is for people concerned about code size.
--
Emilio Wuerges
LAPS - Laboratorio de Automacao de Projeto de Sistemas
UFSC - Universidade Federal de Santa Catarina
Brasil
Re: Using C++ in GCC is OK
On 2 June 2010 15:33, Emílio Wuerges wrote: Now that we are talking about STL templates: What about boost? The requirement for a C++98 compiler is a much weaker requirement than C++98 compiler + working Boost. Boost is not tested on most of the platforms that GCC targets. Also, Boost APIs are less stable than the C++ standard library, so specific range of versions might be required. I use Boost widely, but it is not appropriate in this context.
Re: Using C++ in GCC is OK
On 2 June 2010 15:05, Paolo Bonzini wrote: On 06/02/2010 03:01 PM, Gabriel Dos Reis wrote: In the guidelines, I would like to include: (2) if you define a class template used mostly with pointer type arguments, consider specializing for void* (or const void*) and define all other pointer specialization in terms of that. I have no idea what you're saying. :-) What do you mean by define all other pointer specialization in terms of that? Wouldn't specializing on T* just work? It would work, but can result in a large number of instantiations which generate identical instructions. This sort of template bloat is possible with C++, but is easily avoided. I think what Gaby proposes is to have a common implementation in terms of void*, and then specialisations for other pointer types which are simple forwarding wrappers around the void* specialisation with appropriate casts. This can greatly reduce the amount of code generated if you use the function with many pointer types, because the bulk of the code is only instantiated once for void*.
Re: Using C++ in GCC is OK
On Wed, Jun 2, 2010 at 9:33 AM, Emílio Wuerges wuer...@gmail.com wrote: Now that we are talking about STL templates: What about boost? My personal inclination it to keep the dependencies strictly to a C++98 implementation. When times come that we need more dependencies and the benefits clearly demonstrated, they will be naturally added, just like we have done with any other C packages used in GCC. For the moment, I recommend caution for a switch.
Re: Using C++ in GCC is OK
Ian Lance Taylor wrote: Richard Guenther richard.guent...@gmail.com writes: I agree that that is the usual problem with overloaded operators. I don't really agree that that is a problem in this specific case. We have to do those operations anyhow. I don't think the ease of writing the code is going to cause us to do extra operations in the target floating point format. I agree that judicious use of overloading of arithmetic operators is a big syntactic convenience that does not have any downside. For an example, look at the definitions of + etc for universal reals and universal integers in the Ada front end. Ian
Re: Using C++ in GCC is OK
A rather global comment. I think trying to do language design by the flood-of-email method is dubious. I would create a specific committee to reccommend a C++ coding standard (preferably based on one of the standard ones available, such as Google). And then when there is a completed document, ask for comments.
Re: Using C++ in GCC is OK
Robert Dewar de...@adacore.com writes: A rather global comment. I think trying to do language design by the flood-of-email method is dubious. I would create a specific committee to reccommend a C++ coding standard (preferably based on one of the standard ones available, such as Google). And then when there is a completed document, ask for comments. For those who missed it, I have already started that process, at http://gcc.gnu.org/wiki/CppConventions It is not based on an existing standard because I think we need to accomodate the fact that GCC is a large existing code base written in C and following an existing set of C conventions. Ian
Re: Using C++ in GCC is OK
Basile == Basile Starynkevitch bas...@starynkevitch.net writes:
Basile Still, my concerns on C++ is mostly gengtype related. I believe we need
Basile to keep a garbage collector even with C++, and I believe that changing
Basile gengtype to follow C++ could be quite painful if we follow the usual
Basile route of parsing our headers. Making a gengtype able to parse almost any
Basile C++ header file would be painful.
It seems to me that C++ can actually make gengtype's job simpler.
For example, rather than generating code that knows about the layout of
container types, we can just instantiate template functions that walk a
container using the standard iterator API.
So if you see:
static GTY(()) std::vectortree some_global;
gengtype can just emit
template mark std::vectortree ();
...
mark (some_global);
Mark would be a template function, with specializations for gcc data
types and various STL things (hopefully I got the C++ right here :-):
templatetypename T
void mark (const std::vectorT c)
{
T::const_iterator i = c.begin(), e = c.end();
for (; i != e; ++i)
mark (*i);
}
In this sort of setup, unlike with C, gengtype needs to know very little
about the structure of std::vector. Instead most of the work is
deferred to g++. With this approach, maybe gengtype only needs to know
about roots; each data type could supply its own mark specialization.
Tom
Re: Using C++ in GCC is OK
On Wed, Jun 2, 2010 at 6:03 PM, Tom Tromey tro...@redhat.com wrote:
Basile == Basile Starynkevitch bas...@starynkevitch.net writes:
Basile Still, my concerns on C++ is mostly gengtype related. I believe we
need
Basile to keep a garbage collector even with C++, and I believe that changing
Basile gengtype to follow C++ could be quite painful if we follow the usual
Basile route of parsing our headers. Making a gengtype able to parse almost
any
Basile C++ header file would be painful.
It seems to me that C++ can actually make gengtype's job simpler.
For example, rather than generating code that knows about the layout of
container types, we can just instantiate template functions that walk a
container using the standard iterator API.
So if you see:
static GTY(()) std::vectortree some_global;
gengtype can just emit
template mark std::vectortree ();
...
mark (some_global);
Mark would be a template function, with specializations for gcc data
types and various STL things (hopefully I got the C++ right here :-):
templatetypename T
void mark (const std::vectorT c)
{
T::const_iterator i = c.begin(), e = c.end();
for (; i != e; ++i)
mark (*i);
}
In this sort of setup, unlike with C, gengtype needs to know very little
about the structure of std::vector. Instead most of the work is
deferred to g++. With this approach, maybe gengtype only needs to know
about roots; each data type could supply its own mark specialization.
True. But then either we have to write all markers manually or have
gengtype generate those template overloads for types it handles.
The question is how error-prone it would be - but if we put in a
templatetypename T
void mark(const T) { gcc_unreachable (); }
we might be safe to not miss implementations for something gengtype
does not handle itself.
Richard.
Re: Using C++ in GCC is OK
On 02/06/2010 17:22, Richard Guenther wrote:
templatetypename T
void mark(const T) { gcc_unreachable (); }
we might be safe to not miss implementations for something gengtype
does not handle itself.
Wouldn't
templatetypename T
void mark(const T) { gcc_does_not_exist_causes_link_failure (); }
do an even better job of that?
cheers,
DaveK
Re: Using C++ in GCC is OK
On Mon, 2010-05-31 at 10:02 -0700, Mark Mitchell wrote: I think virtual functions are on the edge; quite useful, but do result in the compiler adding a pointer to data objects and in uninlinable indirect calls at run-time. Therefore, I would avoid them in the initial subset of C++ used in GCC. We do, of course, have one very big 'virtual function' table in gcc -- namely the target hooks. It would be a shame if that couldn't be made into a proper class with virtual functions by some arbitrary rule -- it's a perfect example of when they should be considered. R.
Re: Using C++ in GCC is OK
On Mon, 2010-05-31 at 08:22 -0400, Robert Dewar wrote: Gcc is very widespread at this point. Yes, there is the issue of completely new targets, but these can be easily handled by building cross-compilers. Provided that the object format for binaries is published and that we can therefore create some binutils tools as well. Not every platform uses GAS as its assembler, even today. R.
Re: Using C++ in GCC is OK
Richard Earnshaw wrote: I think virtual functions are on the edge; quite useful, but do result in the compiler adding a pointer to data objects and in uninlinable indirect calls at run-time. Therefore, I would avoid them in the initial subset of C++ used in GCC. We do, of course, have one very big 'virtual function' table in gcc -- namely the target hooks. It would be a shame if that couldn't be made into a proper class with virtual functions by some arbitrary rule -- it's a perfect example of when they should be considered. Ian has bravely taken on the task of C++ coding standards and he's more liberal than I am with respect to the subset to use. (That suits me fine, since I like virtual functions fine, and now I don't have to feel guilty about stuffing them down anybody's throat.) So, anyhow, it looks to me as if current consensus is trending in the direction you suggest... -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
On Wed, Jun 02, 2010 at 06:17:25PM +0100, Richard Earnshaw wrote: On Mon, 2010-05-31 at 10:02 -0700, Mark Mitchell wrote: I think virtual functions are on the edge; quite useful, but do result in the compiler adding a pointer to data objects and in uninlinable indirect calls at run-time. Therefore, I would avoid them in the initial subset of C++ used in GCC. We do, of course, have one very big 'virtual function' table in gcc -- namely the target hooks. It would be a shame if that couldn't be made into a proper class with virtual functions by some arbitrary rule -- it's a perfect example of when they should be considered. And the advantage would be? Currently targetm is a struct with function pointers, so calling targetm.hook_xyz (); means reading a pointer from targetm + off, then calling it. If you make it a class with virtual functions and targetm would be an object of that class, then targetm.hook_xyz (); call means reading pointer from targetm (the vtable pointer), followed by reading the function pointer from the virtual table, then calling it. One extra memory read for hook call. Jakub
Re: Using C++ in GCC is OK
On Wed, 2010-06-02 at 19:50 +0200, Jakub Jelinek wrote: On Wed, Jun 02, 2010 at 06:17:25PM +0100, Richard Earnshaw wrote: On Mon, 2010-05-31 at 10:02 -0700, Mark Mitchell wrote: I think virtual functions are on the edge; quite useful, but do result in the compiler adding a pointer to data objects and in uninlinable indirect calls at run-time. Therefore, I would avoid them in the initial subset of C++ used in GCC. We do, of course, have one very big 'virtual function' table in gcc -- namely the target hooks. It would be a shame if that couldn't be made into a proper class with virtual functions by some arbitrary rule -- it's a perfect example of when they should be considered. And the advantage would be? Currently targetm is a struct with function pointers, so calling targetm.hook_xyz (); means reading a pointer from targetm + off, then calling it. If you make it a class with virtual functions and targetm would be an object of that class, then targetm.hook_xyz (); call means reading pointer from targetm (the vtable pointer), followed by reading the function pointer from the virtual table, then calling it. One extra memory read for hook call. A missing virtual hook would be a build failure, rather than a runtime error. So the advantage is easier maintenance. R.
Re: Using C++ in GCC is OK
On Wed, Jun 02, 2010 at 06:52:11PM +0100, Richard Earnshaw wrote: Currently targetm is a struct with function pointers, so calling targetm.hook_xyz (); means reading a pointer from targetm + off, then calling it. If you make it a class with virtual functions and targetm would be an object of that class, then targetm.hook_xyz (); call means reading pointer from targetm (the vtable pointer), followed by reading the function pointer from the virtual table, then calling it. One extra memory read for hook call. A missing virtual hook would be a build failure, rather than a runtime error. So the advantage is easier maintenance. All the target hooks have defaults, so what means a missing virtual hook? And, how often are target hooks changed compared to how often target hooks are called during compilation? Jakub
Re: Using C++ in GCC is OK
Robert Dewar de...@adacore.com writes: I would create a specific committee to reccommend a C++ coding standard (preferably based on one of the standard ones available, such as Google). Doing things in secret like that is not the Open Source Way.
RE: Using C++ in GCC is OK
I'm not sure i agree with this, because I don't see anything wrong with multi-line C++-style comments. I'm with Ian on this one. Is there a reason for this, other than one's personal tool preference for editing code may make C-style multi-line comments easier to add/remove? Anything that makes comments harder to maintain, I'm against. But there's a grey area for 2-5 line comments preceeding a line of code, for example. I'd really hate to see 50 lines of formatted paragraphs and diagrams, each with // at the beginning, when a single /* at the beginning and */ at the end would do just as well and avoid decorating every single line of what is essentially documentation. That makes sense, though I can still see it both ways. Sticking with the existing C-style comment standard in order to avoid mixed-style comments would probably make things the easiest for all the existing developers. As for personal tool preference, I prefer emacs, which is one of the editors that *can* deal with C++-style block comments, and I still want to avoid them. You've already convinced me, but you originally described a problem where emacs' paragraph formatting would incorrectly rearrange multi-line C++ comments. Out of personal curiosity, does emacs actually have a bug in this regard or not? One thing I disagree with in the wiki is the complete disallowance of multiple inheritance. Multiple inheritance is evil. IMHO class heirarchy reflects an is-a relationship, and one thing cannot be two things. It gets worse when the two immediate ancestors are derived from a common ancestor, and it becomes less obvious which path is taken to get to the common methods and data. If you need to add child-specific intelligence to a method, which ancestor's method do you call next to continue processing? Who calls the common ancestor? Multiple inheritance of behavioral classes should indeed be avoided in pretty much every case -- on this I agree. For many who lived through a multiple-inheritance apocalypse, the phrase multiple inheritance often becomes a sort of a puritanical bad word. It is more than possible, as I have proven in several professional contexts, to use multiple inheritance of pure interfaces (along with favoring delegation) as a way to avoid/remove duplication of implementation code, duplication of declaration, parallel inheritance hierarchies, and inappropriate casting that violates the Liskov Substitution Principle. That being said, you have a very valid point that many people (even those with many years of experience with C++) don't have a firm enough grasp of what *not* to do with regard to inheritance and object-orientation. As I said in my previous message, I would suggest introducing a new warning that trips when a class multiply inherits from non-pure virtual classes (not counting empty virtual dtors). This would help people be aware of when they inadvertently multiple-inherit non-interface classes so they can refactor away from the situation. (Typically, by extracting a pure interface class from one of the behavioral classes, inheriting from the interface, and delegating to the implementation class.) Said warning could also act as an enforcement, just in case GCC code reviews happened to miss the situation. As far as implementing said warning, it seems like the virtual dtor warning could be used as the basis for this new warning. Once you've seen a heirarchy with dozens if not hundreds of members and wild multiple inheritance schemes, you'll understand. My primary job is helping companies with legacy codebases untangle their often completely ridiculous webs of various coding problems. I've lived through the nightmare you describe in both massive C++ projects, as well as with the practice of monkey patching on Ruby projects. I have arrived at the recommendation I make from both having to help dig existing teams/companies out of holes involving extreme uses of multiple inheritance, but also from creating new C++ codebases where a strict single-inheritance policy was adhered to and seeing what issues eventually came about from that extreme. What do you think of a guideline that says multiple inheritance is discouraged in general, but if you think multiple inheritance of pure-virtual (interface) classes is better than the alternatives, email the list and/or module maintainers for specific guidance?
Re: Using C++ in GCC is OK
You've already convinced me, but you originally described a problem where emacs' paragraph formatting would incorrectly rearrange multi-line C++ comments. Out of personal curiosity, does emacs actually have a bug in this regard or not? It happens to work correctly in a well-formed C++ test file. I've seen it mess up reformatting in other types of documents. Heck, I've seen it take a large fully-formed document and turn it into a single monolithic paragraph. What do you think of a guideline that says multiple inheritance is discouraged in general, but if you think multiple inheritance of pure-virtual (interface) classes is better than the alternatives, email the list and/or module maintainers for specific guidance? I think *every* style guideline should allow for the maintainers to revisit them on a case-by-case basis.
Re: Using C++ in GCC is OK
Mark Mitchell m...@codesourcery.com writes: I am pleased to report that the GCC Steering Committee and the FSF have approved the use of C++ in GCC itself. Of course, there's no reason for us to use C++ features just because we can. The goal is a better compiler for users, not a C++ code base for its own sake. I would like to thank Mark and the SC for securing this agreement. Before we start to actually use C++, we need to determine a set of coding standards that will apply to use of C++ within GCC. I have written a proposed set of C++ coding conventions on the wiki at http://gcc.gnu.org/wiki/CppConventions This is only a preliminary proposal. It requires fleshing out and discussion. Comments welcome. Ian
Re: Using C++ in GCC is OK
On 05/31/2010 12:30 PM, 徐持恒 wrote: I think compiler can and should be host independent, like LLVM. It is. Changes to code generation depending on the host are considered to be serious bugs, and have been long before LLVM existed. Paolo
Re: Using C++ in GCC is OK
On Mon, 31 May 2010 18:24:00 -0400, Joern Rennecke wrote: Quoting Vladimir Makarov vmaka...@redhat.com: Reviewers are frequently busy. I bet not a lot of reviewers apply patches and play with it. So it would be nice that people who submits such patches report changes in compile time/footprint/build time (at least I am going to ask this for parts which I review even if such changes in these parts will be not critical for whole compiler as tree or rtl infrastructure changes). Otherwise, we are in danger to get slowly degrading compiler. I'm not sure that this will be effective against bloat creep. When considering one small patch that slows down the compiler (and/or slows down build time) by 0.1%, the difference will be in the noise and impossible to measure with a manageable sample size. But if you combine 1100 of such small patches, the compiler will be three times slower. So, unless we can get some coding style/review mechanism in place that prevents such bloat creep by examining the source code change and the area where it is applied, I think we would need a way to magnify the performance impact of abstraction penalties. E.g. if the penalty is a vtable lookup, making it take a hundred times more specifically in the changed places would magnify the 0.1% overall change to a measurable delta of 10%. Your argument is applicable to any changes in GCC, not just to C to C++ conversions. Do patches that slow down the current C code base by 0.1% get rejected? They do not. -- VH
Re: Using C++ in GCC is OK
On 01/06/10 10:03, Paolo Bonzini wrote: On 05/31/2010 12:30 PM, 徐持恒 wrote: I think compiler can and should be host independent, like LLVM. It is. Changes to code generation depending on the host are considered to be serious bugs, and have been long before LLVM existed. Perhaps 徐持恒 meant target independent, in the sense that with LLVM the choice of target is made at run-time, and not when building LLVM [*]. Just a guess though. Ciao, Duncan. [*] It is possible to choose which targets to build when configuring LLVM. If only one is chosen then of course that's the only one that can be chosen at run-time.
Re: Using C++ in GCC is OK
On Tue, Jun 1, 2010 at 10:22 AM, Duncan Sands baldr...@free.fr wrote: [*] It is possible to choose which targets to build when configuring LLVM. If only one is chosen then of course that's the only one that can be chosen at run-time. This should eventually be made possible in GCC too. It's what all the target macro to target hook conversion is about (although that in itself is not enough). Ciao! Steven
Re: Using C++ in GCC is OK
On 05/31/2010 06:26 PM, Basile Starynkevitch wrote: On Mon, 2010-05-31 at 08:53 -0700, Mark Mitchell wrote: There's no reason to get into these kinds of questions at this point. The goal is not to reimplement GCC from the ground up using modern OO/C++ techniques. The goal is simply to permit ourselves to use C++ features where appropriate in the codebase. Except that perhaps these questions are important for any gengtype enhancement. In particular, one could consider that marking a GTY-ed data would be done by a virtual method (generated by gengtype), and then having every GTY-ed data inheriting from an abstract class providing this method will make both gengtype ggc*.c simpler. The same can be said about PCH serialization, or debug dumping. I'm not sure. Virtual methods have the overhead of a pointer in the object, while gengtype does 100% static typing so it doesn't need a virtual method. Also, in general compiler IRs are used in so many places that a pattern matching style (similar to ML) actually works better than a class hierarchy style. In other words, I doubt that C++ would remove many of the switch statements we have in the code. With respect to this, I'm curious about Ian's experience with gccgo. Adjusting RTL and trees involve a huge rewrite effort, as pointed out elsewhere in the thread, and in the end our own DSL would probably suit the task just as well (or better). In particular, our trees have a kind of multiple inheritance. Personally, the first place where I'd start using C++ is the pass manager. Even then, I'm wary about the compile-time cost of passing this around all the time. But then I have no time for anything of this, so I can just as well shut up. Paolo
Re: Using C++ in GCC is OK
Hello On 01.06.10, you wrote: making it take a hundred times more specifically in the changed places would magnify the 0.1% overall change to a measurable delta of 10%. Your argument is applicable to any changes in GCC, not just to C to C++ conversions. Do patches that slow down the current C code base by 0.1% get rejected? They do not. compile a program in g++ mode really slowdown lots.A build of GCC need on my system 25 minutes, when gcc compile in g++ mode i think it need to compile more than 1 hour. you can see that when you look at C++ programs with same exe size.compile time is around 3* higher in compare to C program, even if c++ is called not make so small code. when i look on Visual C++ in C++ programs i see not so much slowdown. maybe G++ can speedup in any way ? -- VH Regards
Re: Using C++ in GCC is OK
Paolo Bonzini bonz...@gnu.org writes: Also, in general compiler IRs are used in so many places that a pattern matching style (similar to ML) actually works better than a class hierarchy style. In other words, I doubt that C++ would remove many of the switch statements we have in the code. With respect to this, I'm curious about Ian's experience with gccgo. In the gccgo IR I don't represent everything with a single type. Instead, I use a separate base class for types, expressions and statements (in Go there is more of a distinction between expressions and statements than there is in C/C++). I represent specific types, etc., as child classes. The base class uses a protected virtual function interface which the child classes implement. However, as you observe, some code does need to use pattern matching, so that approach is awkward to use by itself. I also declare an enum in the base class, and so given a pointer to the base class you can examine that enum to know which kind of object you have. Some operations are naturally described as virtual functions, such as converting to GENERIC or the general IR walker. Others are naturally described by examining the enums, such as checking whether two types are compatible. The main advantage of using virtual functions in the IR is that it significantly reduces the number of switch statements that have to be updated to add a new kind of IR. Instead most of the operations are kept in one place, in the child class implementation. To be clear, I don't think it would be appropriate at this time to use virtual functions for trees, GIMPLE, or RTL. Ian
Re: Using C++ in GCC is OK
I would highly suggest looking at google guidelines. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml They are aimed at taking some of the landlines out of c++ and give pros and cons for each argument. There are many places in the gcc source where we are already doing C++ things. I would think those would be the best places to start. Adding classes (especially with inheritance) should not be a development decision but instead a design decision. To really move towards C++ we really need to develop a model of what we would like the code to look like.
Re: Using C++ in GCC is OK
Ian Lance Taylor wrote: I have written a proposed set of C++ coding conventions on the wiki at http://gcc.gnu.org/wiki/CppConventions This is only a preliminary proposal. It requires fleshing out and discussion. Thank you for volunteering to do this. How would you like to receive comments? Directly on the Wiki page, or by email? Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
On Tue, Jun 1, 2010 at 4:48 PM, Mark Mitchell m...@codesourcery.com wrote: Ian Lance Taylor wrote: I have written a proposed set of C++ coding conventions on the wiki at http://gcc.gnu.org/wiki/CppConventions This is only a preliminary proposal. It requires fleshing out and discussion. Thank you for volunteering to do this. How would you like to receive comments? Directly on the Wiki page, or by email? Overall the wiki document looks good. I'd like to disallow * Operators may only be overloaded for types which implement numeric values, where the overloaded operators implement the usual numeric semantics. though. I'd also like to avoid destructors where possible as we want as many core data types to be POD. Btw - can we intially just link with libsup++ omitting libstdc++ so that we do not get the expected flood of convert-to-STL patches? Or is the idea of an STL free gcc bad? Thanks, Richard.
Re: Using C++ in GCC is OK
Mark Mitchell m...@codesourcery.com writes: Ian Lance Taylor wrote: I have written a proposed set of C++ coding conventions on the wiki at http://gcc.gnu.org/wiki/CppConventions This is only a preliminary proposal. It requires fleshing out and discussion. Thank you for volunteering to do this. How would you like to receive comments? Directly on the Wiki page, or by email? Hmmm, good question. I guess either is fine, but it's probably simpler if people add comments directly on the wiki page. For simplicity, I suggest that unless you are correcting a typo or other obvious error, put additions or comments in parentheses or in a separate bullet item with your name attached. As the wiki page says, when this converges it will be moved to a .html page under CVS control. Ian
Re: Using C++ in GCC is OK
Richard Guenther wrote: Btw - can we intially just link with libsup++ omitting libstdc++ so that we do not get the expected flood of convert-to-STL patches? Or is the idea of an STL free gcc bad? I view STL as one of the bits of low-hanging C++ fruit. I think we're all vaguely confused by the VEC APIs, for example; using std::vector seems much better. And, using those kinds of things doesn't require a lot of knowledge of C++ arcana, even if the implementations may use some of that arcana. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
Hi, I hope you don't mind my comment as I an not a project member, just a long term multi-platform GCC user. With all due respect, I fail to understand the decision to switch to C++ without being able to elucidate the specific features of C++ that will benefit the GCC team and the GCC compiler collection. It seems to me that outlining the specific advantages to both the compiler and development team of using C++ over C would be step one in defining what is and is not to be allowed. (I'm sure there is such a document, but I haven't been able to find it.) To begin, what are the specific reasons or advantages for switching to C++ for the GCC compiler? Will C++ produce faster or more efficient code and if so how and using what specific constructs? Will using C++ produce less buggy code and, again, if so how and using what specific constructs. And so forth. Each specific reason for using C++ over C should have clear and definable benefits for both current and future developers and product; each of these benefits should form the basis for the coding standards for the GCC project. One final note: it is my experience that having developers not using the tool/product they are developing reduces product quality dramatically. For the one cent my two cents is worth, the C front end should be written in C, the C++ front end should be written in C++ and so forth. Thanks again to the whole compiler team for the great work and great products. Rich Wallick 19255 NW North Star Dr. Banks, OR 97016 503 324 9189
Re: Using C++ in GCC is OK
Richard Guenther wrote: On Tue, Jun 1, 2010 at 4:48 PM, Mark Mitchell m...@codesourcery.com wrote: Ian Lance Taylor wrote: I have written a proposed set of C++ coding conventions on the wiki at http://gcc.gnu.org/wiki/CppConventions This is only a preliminary proposal. It requires fleshing out and discussion. Thank you for volunteering to do this. How would you like to receive comments? Directly on the Wiki page, or by email? Overall the wiki document looks good. I'd like to disallow * Operators may only be overloaded for types which implement numeric values, where the overloaded operators implement the usual numeric semantics. which do you want to disallow, the may or the only, not clear \
Re: Using C++ in GCC is OK
Mark Mitchell m...@codesourcery.com writes: Richard Guenther wrote: Btw - can we intially just link with libsup++ omitting libstdc++ so that we do not get the expected flood of convert-to-STL patches? Or is the idea of an STL free gcc bad? I view STL as one of the bits of low-hanging C++ fruit. I think we're all vaguely confused by the VEC APIs, for example; using std::vector seems much better. And, using those kinds of things doesn't require a lot of knowledge of C++ arcana, even if the implementations may use some of that arcana. Agreed. In particular, we can take advantage of the cool new gdb work to easily print vectors and other STL types in the debugger. Dealing with VECs in the debugger is a pain. Ian
Re: Using C++ in GCC is OK
Richard Guenther richard.guent...@gmail.com writes: Overall the wiki document looks good. I'd like to disallow * Operators may only be overloaded for types which implement numeric values, where the overloaded operators implement the usual numeric semantics. though. My thinking here is that it would be reasonable to implement real_arithmetic and mpfr/mpc using overloaded operators. I could certainly be wrong. I'd also like to avoid destructors where possible as we want as many core data types to be POD. I adjusted the wiki accordingly. Ian
Re: Using C++ in GCC is OK
Rich Wallick rwall...@gmail.com writes: I hope you don't mind my comment as I an not a project member, just a long term multi-platform GCC user. With all due respect, I fail to understand the decision to switch to C++ without being able to elucidate the specific features of C++ that will benefit the GCC team and the GCC compiler collection. It seems to me that outlining the specific advantages to both the compiler and development team of using C++ over C would be step one in defining what is and is not to be allowed. (I'm sure there is such a document, but I haven't been able to find it.) Here are the slides from my presentation on the topic at the 2008 GCC Summit: http://airs.com/ian/cxx-slides.pdf . To begin, what are the specific reasons or advantages for switching to C++ for the GCC compiler? See above slides for my summary. Will C++ produce faster or more efficient code and if so how and using what specific constructs? Using C++ in the compiler will not produce faster or more efficient generated code. In some cases it should make the compiler itself run more efficiently, as when using STL sort rather than qsort. Will using C++ produce less buggy code and, again, if so how and using what specific constructs. My hope is that using C++ in the compiler should help make the compiler itself less buggy, in particular in areas related to memory use. One final note: it is my experience that having developers not using the tool/product they are developing reduces product quality dramatically. For the one cent my two cents is worth, the C front end should be written in C, the C++ front end should be written in C++ and so forth. I do hope that writing gcc in C++ will increase the performance of the C++ frontend. I'm skeptical that it will have any negative effect on the C frontend. Ian
Re: Using C++ in GCC is OK
On Tue, 2010-06-01 at 10:33 -0700, Ian Lance Taylor wrote:
Here are the slides from my presentation on the topic at the 2008 GCC
Summit: http://airs.com/ian/cxx-slides.pdf .
Ian, what is that status of your GCC in C++ branch? What should be
re-usable from it? Do you think it makes sense to reuse it, or was it a
proof of concept only work?
[I admit I never took time to look in detail into your branch]
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Using C++ in GCC is OK
Basile Starynkevitch bas...@starynkevitch.net writes: On Tue, 2010-06-01 at 10:33 -0700, Ian Lance Taylor wrote: Here are the slides from my presentation on the topic at the 2008 GCC Summit: http://airs.com/ian/cxx-slides.pdf . Ian, what is that status of your GCC in C++ branch? What should be re-usable from it? Do you think it makes sense to reuse it, or was it a proof of concept only work? [I admit I never took time to look in detail into your branch] I merged the branch into mainline last year. Ian
Re: Using C++ in GCC is OK
My suggestions: * When it is appropriate to use a child class with virtual functions, the virtual functions should all be declared as protected in the parent class. At first reading, I thought you meant all virtual functions should be protected, but I think you meant if a child ADDS a virtual function that the parent doesn't have, ..., but in that case I don't see why the parent needs a declaration at all. This should be clarified. * Namespaces In general, I don't like namespaces, unless you're defining a package. Class names create their own name spaces, globals should be global, etc. Saying everything should be in a namespace is IMHO an inappropriate restriction. Indicate where namespaces are appropriate, leave it at that. * All data members should be private. * All data members should have names which end with an underscore. This makes all structures illegal. I'd remove the first All and replace the second with Private: * Data members should be private. * Private data members should have names which end with an underscore. * When a method refers to a non-static data member, it should always qualify the reference with this-. I'm very opposed to this. To me, it makes the code less readable because it lets the author write code that's hard to understand at a larger scope. I would forbid explicit references to this except to pass it unadorned as a parameter to some other function. If it's not clear where method call data comes from, write clearer code! If you're implementing a class, it should be clear you're implementing a class, and implied that data/methods come from the class unless specified otherwise (which you'd have to do anyway, like foo-reg_p()). If it's not clear, you've not properly encapsulated the class and you need to redesign it so it *is* properly contained and easy to understand. If you're not implementing a class, you'd never use this anyway. DJ never refers to himself in the third person, I don't see why his code should. * At least for now we will continue to use printf style I/O rather than iostream style I/O THANK YOU! * use of existing templates, e.g., from the standard library, is fine I'd prefer avoiding pulling in STL stuff at first. I find STL to be quite a culture shock relative to C. When used I'd limit it to one STL object at a time - avoid containers of lists of vectors of strings, etc. Additions: * Local variables should be declared where they're first used, if their use is contiguous and localized. If they're ubiquitous (like a return value temporary) or reused later (like i for for-loop iterators), declare them at the beginning of the function. * Use C-style comments for multi-line comments, and C++-style comments for single-line comments.
