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
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
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.
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
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
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
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
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
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
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.
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
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
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
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
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.
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.
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
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
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,
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
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
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
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
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
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...?
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
; 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
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
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
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
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
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
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
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
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
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.
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++
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
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
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
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
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
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
*
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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.
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?
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
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
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
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
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
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
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
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
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.
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++
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
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.
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
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
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
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
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++
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
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
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
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
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
1 - 100 of 196 matches
Mail list logo
