DJ Delorie d...@redhat.com writes:
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,
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.
* All data members should be private.
* All data members should have names which end with an
On 1 June 2010 22:13, Ian Lance Taylor wrote:
DJ Delorie writes:
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
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
On 01/06/2010 22:13, Ian Lance Taylor wrote:
* 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
In a project with as many globals as we have, it's kinda handy to
know at a glance whether a member function is accessing a data
member or a global.
Add a globals-in-namespaces rule, or a ::global syntax, and you have
even more overkill.
IMHO we should make it easy to implement a clean
A suggestion about:
Method bodies may only appear in the class definition if they are very short,
no more than five lines. Otherwise the method body should be defined outside of
the class definition.
To avoid dependency explosions that increase compile times and allow for
link-time
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
Jonathan Wakely jwakely@gmail.com writes:
Nothing in C++ prevents a struct from having member functions,
constructors, base classes, virtual functions, private members etc.
If the intention is to impose a distinction between structs and
classes, based on which keyword is used to define
On 06/02/2010 01:42 AM, Ian Lance Taylor wrote:
The 'this-' is needed when the current class and base class are both
templates and the name is declared in the base class, and not if it's
declared in the current class. That is not likely to happen in a
hurry while the convention is to not
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.
What about the case where the parent provides default implementations
of methods that are infrequently overridden by children? Otherwise,
you end up with
Right, but it may happen some day. Also there is the issue of
clarity. I think it is clearer to see this-get() rather than get().
this-put_size (this-get_bounds (this-get_x(), this-get_y()),
this-get_variance (this-default_variance ()))
I'd like to avoid needing to assign
gold is using this convention, isn't it?
I find the gold sources harder to read than the rest of binutils, and
would like to avoid propogating that style elsewhere. This from
someone who's been writing C++ code for twenty years now.
Also, gold was added to binutils without this type of
On Tue, Jun 1, 2010 at 7:00 PM, Bernd Schmidt ber...@codesourcery.com wrote:
On 06/02/2010 01:42 AM, Ian Lance Taylor wrote:
The 'this-' is needed when the current class and base class are both
templates and the name is declared in the base class, and not if it's
declared in the current class.
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
On Tue, Jun 1, 2010 at 7:05 PM, DJ Delorie d...@redhat.com wrote:
Right, but it may happen some day. Also there is the issue of
clarity. I think it is clearer to see this-get() rather than get().
this-put_size (this-get_bounds (this-get_x(), this-get_y()),
this-get_variance
On Tue, Jun 1, 2010 at 7:03 PM, DJ Delorie d...@redhat.com wrote:
Maybe you and I have completely different ideas about how the whole
class heirarchy works. I'm not a firm believer that the base-most
class should be an empty shell of a class that does nothing but
provide a placeholder for
On 06/01/10 17:42, Ian Lance Taylor wrote:
The biggest need for this- is when calling methods in the current
class if the current class happens to be in a template.
The 'this-' is needed when the current class and base class are both
templates and the name is declared in the base
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 think that would be most unproductive and misguided.
Maybe I should step back and restate my original desires.
I don't want us to move *too quickly* towards an all-STL
implementation, and end up with a hairy mess that's hard to
understand. I've had to debug our STL implementation before,
On Tue, Jun 1, 2010 at 8:03 PM, DJ Delorie d...@redhat.com wrote:
I think that would be most unproductive and misguided.
Maybe I should step back and restate my original desires.
I don't want us to move *too quickly* towards an all-STL
implementation, and end up with a hairy mess that's
Right, but it may happen some day. Also there is the issue of
clarity. I think it is clearer to see this-get() rather than get().
this-put_size (this-get_bounds (this-get_x(), this-get_y()),
this-get_variance (this-default_variance ()))
I think clarity can be a mixed bag
Bernd Schmidt ber...@codesourcery.com writes:
On 06/02/2010 01:42 AM, Ian Lance Taylor wrote:
The 'this-' is needed when the current class and base class are both
templates and the name is declared in the base class, and not if it's
declared in the current class. That is not likely to happen
Gabriel Dos Reis g...@integrable-solutions.net writes:
As I matter of fact, I have comments about the conventions being put forward,
I do not know the proper way to get them reflected in the proposal.
As I said earlier, send e-mail here, or update the wiki page. When
updating the wiki page,
On Tue, Jun 1, 2010 at 8:41 PM, Ian Lance Taylor i...@google.com wrote:
Gabriel Dos Reis g...@integrable-solutions.net writes:
As I matter of fact, I have comments about the conventions being put forward,
I do not know the proper way to get them reflected in the proposal.
As I said earlier,
DJ Delorie d...@redhat.com writes:
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.
What about the case where the parent provides default implementations
of methods that are infrequently overridden by
On Jun 1, 2010, at 17:41, DJ Delorie wrote:
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.
With Ada we have no choice, and only have -- comments. I
On Wed, Jun 2, 2010 at 9:55 AM, 徐持恒 chiheng...@gmail.com wrote:
On Wed, Jun 2, 2010 at 8:38 AM, 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
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,
On Tue, 2010-06-01 at 19:43 -0500, Gabriel Dos Reis wrote:
On Tue, Jun 1, 2010 at 7:03 PM, DJ Delorie d...@redhat.com wrote:
Maybe you and I have completely different ideas about how the whole
class heirarchy works. I'm not a firm believer that the base-most
class should be an empty
But C/C++ may have an another advantage, it can use ADT(Abstract Data
Type) to extend its set of primitive type, e.g., string.
But C++ may have an another advantage, it can use ADT(Abstract Data
Type) to extend its set of primitive type, e.g., string.
--
徐持恒(Chiheng Xu)
Wuhan,China
On Mon, May 31, 2010 at 12:28 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
At last, there is a very important issue when switching to C++. What is
our ideal class hierarchy?
The ideal class hierarchy is independent of the language used. The language
matters only to the extend that
For example, I think it goes without question that at this point we are
limiting ourselves to C++98 (plus long long so that we have a 64-bit
integer type);
Where does this long long requirement come from? We should only require an
ISO C++98 compiler, just like we currently require only an ISO
On Mon, May 31, 2010 at 01:39:08AM -0500, Gabriel Dos Reis wrote:
On Mon, May 31, 2010 at 12:28 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
At last, there is a very important issue when switching to C++. What is
our ideal class hierarchy?
The ideal class hierarchy is
Eric Botcazou ebotca...@adacore.com writes:
Where does this long long requirement come from? We should only require an
ISO C++98 compiler, just like we currently require only an ISO C90 compiler.
C90 does not have long long either, yet we use it as required (for HWI).
Andreas.
--
Andreas
C90 does not have long long either, yet we use it as required (for HWI).
No, we use it when present but we don't require it, see hwint.h.
--
Eric Botcazou
On 05/31/2010 11:48 AM, Eric Botcazou wrote:
C90 does not have long long either, yet we use it as required (for HWI).
No, we use it when present but we don't require it, see hwint.h.
Both of you are right, as our requirements for building a cross compiler
are stricter than for a native
Sent from my iPhone
On May 31, 2010, at 2:48 AM, Eric Botcazou ebotca...@adacore.com
wrote:
C90 does not have long long either, yet we use it as required (for
HWI).
No, we use it when present but we don't require it, see hwint.h.
Kinda. It depends on the host and target. If the
Both of you are right, as our requirements for building a cross compiler
are stricter than for a native compiler.
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.
--
Eric
Eric Botcazou ebotca...@adacore.com writes:
Right, only in this case, and I don't see why this should be changed with the
transition to C++, that's orthogonal.
It will be used as required.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7
On Mon, May 31, 2010 at 8:26 AM, Mark Mitchell m...@codesourcery.com wrote:
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
On Mon, May 31, 2010 at 5:54 PM, Andrew Pinski pins...@gmail.com wrote:
Sent from my iPhone
On May 31, 2010, at 2:48 AM, Eric Botcazou ebotca...@adacore.com wrote:
C90 does not have long long either, yet we use it as required (for HWI).
No, we use it when present but we don't require it,
徐持恒 wrote:
I have FUD on the use of advanced C++ features like template(even
standard template), namespace, exceptions. This is partly because my
favorite source code analyzer can not handle them properly. I have
tried to use my favorite source code analyzer to analyze LLVM source
code, which
On Mon, May 31, 2010 at 6:41 PM, Robert Dewar de...@adacore.com wrote:
It's a pity to exclude namespaces, the advantage of breaking the
single-big-namespace model are evident.
Yes, the advantage of namespace is obvious.
But, I think namespace is just a syntax sugar. You can name your
On Mon, May 31, 2010 at 12:41 PM, Robert Dewar de...@adacore.com wrote:
徐持恒 wrote:
I have FUD on the use of advanced C++ features like template(even
standard template), namespace, exceptions. This is partly because my
favorite source code analyzer can not handle them properly. I have
tried
徐持恒 wrote:
On Mon, May 31, 2010 at 6:41 PM, Robert Dewar de...@adacore.com wrote:
It's a pity to exclude namespaces, the advantage of breaking the
single-big-namespace model are evident.
Yes, the advantage of namespace is obvious.
But, I think namespace is just a syntax sugar. You can name
On Mon, May 31, 2010 at 12:59 PM, Robert Dewar de...@adacore.com wrote:
徐持恒 wrote:
On Mon, May 31, 2010 at 6:41 PM, Robert Dewar de...@adacore.com wrote:
It's a pity to exclude namespaces, the advantage of breaking the
single-big-namespace model are evident.
Yes, the advantage of namespace
There are several C++ features which not all compilers support well,
these features should be avoided if possible.
For example VC++ 2008 treats
struct foo{ static const int bar=1; };
As if the coder has also written (at the same spot)
const int foo::bar;
The consequence is
One interesting issue is whether it is important for gcc to be
able to be compiled with foreign compilers (other than gcc).
I know that historically this has been an important requirement,
but I wonder whether it is still relevant.
Gcc is very widespread at this point. Yes, there is the issue
On Mon, May 31, 2010 at 3:42 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Mon, May 31, 2010 at 01:39:08AM -0500, Gabriel Dos Reis wrote:
On Mon, May 31, 2010 at 12:28 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
At last, there is a very important issue when
On Mon, May 31, 2010 at 4:58 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Mon, May 31, 2010 at 3:42 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Mon, May 31, 2010 at 01:39:08AM -0500, Gabriel Dos Reis wrote:
On Mon, May 31, 2010 at 12:28 AM, Basile Starynkevitch
On Mon, May 31, 2010 at 5:03 PM, Richard Guenther
richard.guent...@gmail.com wrote:
And we definitely should not do so just because we can. I see
little value in turning our tree upside-down just because we now
can use C++ and make everything a class rather than a union.
If hiding the
On Mon, May 31, 2010 at 7:22 AM, Robert Dewar de...@adacore.com wrote:
One interesting issue is whether it is important for gcc to be
able to be compiled with foreign compilers (other than gcc).
I know that historically this has been an important requirement,
but I wonder whether it is still
On Mon, May 31, 2010 at 10:03 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, May 31, 2010 at 4:58 PM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Mon, May 31, 2010 at 3:42 AM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Mon, May 31, 2010 at 01:39:08AM
For example, I think it goes without question that at this point we are
limiting ourselves to C++98 (plus long long so that we have a 64-bit
integer type); C++0x features should not be used. Using multiple
inheritance, templates (other than when using the C++ standard library,
e.g. std::listX),
On Mon, May 31, 2010 at 5:09 PM, Steven Bosscher stevenb@gmail.com wrote:
On Mon, May 31, 2010 at 5:03 PM, Richard Guenther
richard.guent...@gmail.com wrote:
And we definitely should not do so just because we can. I see
little value in turning our tree upside-down just because we now
can
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.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Gabriel Dos Reis g...@integrable-solutions.net writes:
[...] I do not think so, and I would not suggest that the use of
C++ is an excuse do ditch the possibility of bootstrapping with
anything other than GCC.
Right. It would be good to enumerate any language/design constraints
that other
On Mon, May 31, 2010 at 5:29 PM, David Fang f...@csl.cornell.edu wrote:
For example, I think it goes without question that at this point we are
limiting ourselves to C++98 (plus long long so that we have a 64-bit
integer type); C++0x features should not be used. Using multiple
inheritance,
On Mon, May 31, 2010 at 10:29 AM, David Fang f...@csl.cornell.edu wrote:
For example, I think it goes without question that at this point we are
limiting ourselves to C++98 (plus long long so that we have a 64-bit
integer type); C++0x features should not be used. Using multiple
inheritance,
On Mon, May 31, 2010 at 11:09, Steven Bosscher stevenb@gmail.com wrote:
On Mon, May 31, 2010 at 5:03 PM, Richard Guenther
richard.guent...@gmail.com wrote:
And we definitely should not do so just because we can. I see
little value in turning our tree upside-down just because we now
can
Basile Starynkevitch wrote:
At last, there is a very important issue when switching to C++. What is
our ideal class hierarchy? Do we aim at a large forest, or on the
contrary at a single tree of classes, so we have a single root class,
providing common services (dump or debug printing,
On Mon, May 31, 2010 at 11:27, Richard Guenther
richard.guent...@gmail.com wrote:
Well - if somebody does the work and _completely_ converts
tree and its accessor functions and macros to use a class-based
tree then more power to him. What I do not like to see is
partial conversions to C++.
On Mon, May 31, 2010 at 11:54, Richard Guenther
richard.guent...@gmail.com wrote:
It's a lot of work (tree extends in all three Frontends, middle-end
and backends). And my fear is we'll only get a halfway transition -
something worse than no transition at all.
Yeah, that's true.
Diego.
Mark Mitchell wrote:
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.
On Mon, May 31, 2010 at 5:53 PM, Diego Novillo dnovi...@google.com wrote:
On Mon, May 31, 2010 at 11:09, Steven Bosscher stevenb@gmail.com wrote:
On Mon, May 31, 2010 at 5:03 PM, Richard Guenther
richard.guent...@gmail.com wrote:
And we definitely should not do so just because we can. I
On Mon, May 31, 2010 at 12:00:21PM -0400, Vladimir Makarov wrote:
Mark Mitchell wrote:
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
On Mon, 2010-05-31 at 08:53 -0700, Mark Mitchell wrote:
Basile Starynkevitch wrote:
At last, there is a very important issue when switching to C++. What is
our ideal class hierarchy? Do we aim at a large forest, or on the
contrary at a single tree of classes, so we have a single root
Basile Starynkevitch wrote:
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
I'm not enthusiastic about that either.
FWIW neither am I.
Nor will grow the memory footprint, at least of the important data
structures, or increase maintanance costs by making the code less readable,
etc.
It's clear that we don't want blind conversions to fancy C++ style, but Mark
was
Jakub Jelinek wrote:
I just really hope we will have strict criteria that any transition will
not make compiler slower and will not increase compiler build time.
Nor will grow the memory footprint, at least of the important data
structures, or increase maintanance costs by making the code
On Mon, May 31, 2010 at 09:44:08AM -0700, Mark Mitchell wrote:
I just really hope we will have strict criteria that any transition will
not make compiler slower and will not increase compiler build time.
Nor will grow the memory footprint, at least of the important data
structures, or
Richard Guenther wrote:
Oh - and we didn't yet decide to switch to C++ as implementation
language. Did we?
I'm not sure exactly what you're asking. We now have permission to
switch. The reason we wanted permission to switch was that there was a
consensus that we wanted to switch; as far as
On Mon, May 31, 2010 at 11:54 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, May 31, 2010 at 09:44:08AM -0700, Mark Mitchell wrote:
I just really hope we will have strict criteria that any transition will
not make compiler slower and will not increase compiler build time.
Nor will grow
On Mon, May 31, 2010 at 12:11:14PM -0500, Gabriel Dos Reis wrote:
aren't we already doing this with the various hooks we have?
Currently hooks are used mainly for target or language hooks, that's far
different from using virtual methods say on the tree or rtl objects.
We do not need to
On Mon, May 31, 2010 at 12:02 PM, Mark Mitchell m...@codesourcery.com wrote:
Richard Guenther 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
Gabriel Dos Reis wrote:
There are good C++ coding standards out there, and I would be reluctant
to encourage a NIH-driven design as opposed to adapting existing ones
that have been given lot of considerations:
http://www2.research.att.com/~bs/bs_faq2.html#coding-standard
Gabriel Dos Reis wrote:
On Mon, May 31, 2010 at 11:54 AM, Jakub Jelinek ja...@redhat.com wrote:
Similarly if the compiler massively starts using virtual methods everywhere,
there will be slow downs caused by the increased number of harder to predict
indirect calls.
that is why
On Mon, May 31, 2010 at 12:31 PM, Mark Mitchell m...@codesourcery.com wrote:
Gabriel Dos Reis wrote:
There are good C++ coding standards out there, and I would be reluctant
to encourage a NIH-driven design as opposed to adapting existing ones
that have been given lot of considerations:
On Mon, May 31, 2010 at 12:33 PM, Vladimir Makarov vmaka...@redhat.com wrote:
So it would be nice that people who submits such patches report changes in
compile time/footprint/build time
I thought this has been part of our usual procedure for a while now.
-- Gaby
Gabriel Dos Reis wrote:
On Mon, May 31, 2010 at 12:33 PM, Vladimir Makarov vmaka...@redhat.com wrote:
So it would be nice that people who submits such patches report changes in
compile time/footprint/build time
I thought this has been part of our usual procedure for a while now.
Mark Mitchell m...@codesourcery.com writes:
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
Is that still true given profile feedback
Andi Kleen 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
Is that still true given profile feedback and the recent
On Mon, 2010-05-31 at 11:48 -0700, Mark Mitchell wrote:
Andi Kleen wrote:
Don't get me wrong; I think virtual functions are very useful. The
target hooks and language hooks we have are essentially poor man's
virtual functions, and we could naturally (and mechanically) convert
them to
Because C++ is a big language, I think we should try to enumerate what
is OK, rather than what is not OK.
Is there anyone who would like to volunteer to develop the C++ coding
standards?
I hope you you don't mind my question (as I am currently not an active GCC
developer), but what is the
Thomas Neumann wrote:
Now I know that this is totally unrealistic in the context of the GCC
project, and some people here get really nervous about a potential C++
creep, but IMHO artificial limitations on a pure syntax base are not really
meaningful. One should look at the consequences and
Well anyone can think anything, but this view is way out of the
mainstream. I do not know of a single large real project using a
large complex language that does not have coding standards that
limit the use of the language.
I know this, but I do not understand this. I have worked in reasonably
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
Quoting Gabriel Dos Reis g...@integrable-solutions.net:
Definitely. That document is interesting in that it offers views
and rationale
about some of the restrictions being put forward. For example, I would not
discount easily sections 4.10, 4.11, 4.12.
I think we have grounds to modify
On 05/31/2010 04:36 PM, Thomas Neumann wrote:
Well anyone can think anything, but this view is way out of the
mainstream. I do not know of a single large real project using a
large complex language that does not have coding standards that
limit the use of the language.
I know this, but I
On Tue, Jun 1, 2010 at 1:12 AM, Joel Sherrill joel.sherr...@oarcorp.com wrote:
Another thing that has bothered me is the fear of
getting slower. If using C++ makes GCC slower, then
GCC C++ needs to get faster. This is eating our own
dog food. :)
Indeed. If we can avoid the obvious problems
On 05/31/10 14:30, Basile Starynkevitch wrote:
[snip]
I would believe that replacing a complex function like above (which
contains a switch) with a virtual function call could probably be a win
in performance, not a loose.
But perhaps my intuition is wrong. Honestly, I don't have exact
On Mon, May 31, 2010 at 6:29 PM, Larry Evans cppljev...@suddenlink.net wrote:
However, that boost devel post claims using a switch statement would
be faster.
Switching to C++ should never be excuse to bring more more brittle codes
or more obscurities. Rather, it should be opportunity to write
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.
Before we start to actually
Mark Mitchell wrote:
Is there anyone who would like to volunteer to develop the C++ coding
standards? I think that this could be done as a Wiki page. (If nobody
volunteers, I will volunteer myself.) Whoever ends up doing this, I
would urge the rest of us not to spend too much time in the C++
Hi,
On Sun, May 30, 2010 at 10:03 PM, Robert Dewar de...@adacore.com wrote:
Mark Mitchell wrote:
Is there anyone who would like to volunteer to develop the C++ coding
standards? I think that this could be done as a Wiki page. (If nobody
volunteers, I will volunteer myself.) Whoever ends
On Sun, 2010-05-30 at 17:26 -0700, Mark Mitchell wrote:
I am pleased to report that the GCC Steering Committee and the FSF have
approved the use of C++ in GCC itself. [...]
For example, I think it goes without question that at this point we are
limiting ourselves to C++98 (plus long long so
101 - 197 of 197 matches
Mail list logo
