On 7/10/12, Gabriel Dos Reis g...@cs.tamu.edu wrote:
Jason Merrill ja...@redhat.com writes:
| On 07/09/2012 06:00 PM, Lawrence Crowl wrote:
| Done. New patch attached, but note that the html tags have been
| stripped from the patch to avoid mailer problems.
|
| Thanks. If nobody else
Lawrence Crowl cr...@google.com writes:
| On 7/10/12, Gabriel Dos Reis g...@cs.tamu.edu wrote:
| Jason Merrill ja...@redhat.com writes:
|
| | On 07/09/2012 06:00 PM, Lawrence Crowl wrote:
| | Done. New patch attached, but note that the html tags have been
| | stripped from the patch to
On 07/09/2012 06:00 PM, Lawrence Crowl wrote:
Done. New patch attached, but note that the html tags have been
stripped from the patch to avoid mailer problems.
Thanks. If nobody else has any comments, I think this is good to go.
Jason
Jason Merrill ja...@redhat.com writes:
| On 07/09/2012 06:00 PM, Lawrence Crowl wrote:
| Done. New patch attached, but note that the html tags have been
| stripped from the patch to avoid mailer problems.
|
| Thanks. If nobody else has any comments, I think this is good to go.
Great!
--
On 7/4/12, Jason Merrill ja...@redhat.com wrote:
On 07/03/2012 04:37 PM, Lawrence Crowl wrote:
On 7/1/12, Jason Merrillja...@redhat.com wrote:
As discussed, I would say that RTTI is currently not permitted
but could be added later.
But isn't could be added later always true? Other folks
On 07/03/2012 04:37 PM, Lawrence Crowl wrote:
On 7/1/12, Jason Merrillja...@redhat.com wrote:
As discussed, I would say that RTTI is currently not permitted
but could be added later.
But isn't could be added later always true? Other folks have
objected to such wording on the grounds that it
On 7/1/12, Gabriel Dos Reis g...@integrable-solutions.net wrote:
On Fri, Jun 29, 2012 at 1:17 PM, Lawrence Crowl cr...@google.com wrote:
Resend, as I replied to a message that didn't have the usual suspects
on the cc line.
On 6/27/12, Lawrence Crowl cr...@google.com wrote:
..., does anyone
On 7/1/12, Jason Merrill ja...@redhat.com wrote:
On 06/29/2012 02:17 PM, Lawrence Crowl wrote:
+h4a name=RTTIRTTI andcodedynamic_cast/code/a/h4
+
+p
+Run-time type information (RTTI) is permitted
+when certain non-defaultcode--enable-checking/code options are
enabled,
+so as to
Lawrence Crowl cr...@google.com writes:
| On 7/1/12, Gabriel Dos Reis g...@integrable-solutions.net wrote:
| On Fri, Jun 29, 2012 at 1:17 PM, Lawrence Crowl cr...@google.com wrote:
| Resend, as I replied to a message that didn't have the usual suspects
| on the cc line.
|
| On 6/27/12,
On Fri, Jun 29, 2012 at 1:17 PM, Lawrence Crowl cr...@google.com wrote:
Resend, as I replied to a message that didn't have the usual suspects
on the cc line.
On 6/27/12, Lawrence Crowl cr...@google.com wrote:
..., does anyone object to removing the permission to use C++
streams?
Having
On 06/29/2012 02:17 PM, Lawrence Crowl wrote:
+h4a name=RTTIRTTI andcodedynamic_cast/code/a/h4
+
+p
+Run-time type information (RTTI) is permitted
+when certain non-defaultcode--enable-checking/code options are
enabled,
+so as to allow checkers to report dynamic types.
+However, by default,
Resend, as I replied to a message that didn't have the usual suspects
on the cc line.
On 6/27/12, Lawrence Crowl cr...@google.com wrote:
..., does anyone object to removing the permission to use C++
streams?
Having heard no objection, I removed the permission.
The following patch is the
On Wed, 27 Jun 2012, Lawrence Crowl wrote:
+h4a name=Namespace_UseNamespaces/a/h4
+
+p
+Namespaces are encouraged.
+All separable libraries should have a unique global namespace.
+All individual tools should have a unique global namespace.
+Nested include directories names should
On 6/27/12, Lawrence Crowl cr...@google.com wrote:
..., does anyone object to removing the permission to use C++
streams?
Having heard no objection, I removed the permission.
The following patch is the current state of the changes. Since the
discussion appears to have died down, can I commit
On Wed, Jun 27, 2012 at 2:35 AM, Magnus Fromreide ma...@lysator.liu.se wrote:
On Mon, 2012-06-25 at 15:17 -0700, Lawrence Crowl wrote:
On 6/25/12, Joseph S. Myers jos...@codesourcery.com wrote:
On Mon, 25 Jun 2012, Diego Novillo wrote:
[ Added doc maintainers in CC ]
I have added a bit
[...]
| Two spaces for members is common practice with GNU, and it seems to be
| used for libstdc++.
|
| One space for protection labels is not something I have heard of before
| and libstdc++ uses no indentation for them.
|
| A freshly started emacs also doesn't indent access labels.
|
On Wed, Jun 27, 2012 at 2:19 AM, Lawrence Crowl cr...@google.com wrote:
On 6/26/12, Jason Merrill ja...@redhat.com wrote:
On 06/25/2012 06:26 PM, Lawrence Crowl wrote:
+orcodegcc_unreachable/code. If the checks are expensive or the
+compiler can reasonably carry on after the error, they may
On Wed, Jun 27, 2012 at 2:35 PM, Chiheng Xu chiheng...@gmail.com wrote:
On Wed, Jun 27, 2012 at 2:19 AM, Lawrence Crowl cr...@google.com wrote:
On 6/26/12, Jason Merrill ja...@redhat.com wrote:
On 06/25/2012 06:26 PM, Lawrence Crowl wrote:
+orcodegcc_unreachable/code. If the checks are
On Tue, Jun 19, 2012 at 6:28 AM, Lawrence Crowl cr...@google.com wrote:
pFunction prototypes for extern functions should only occur in
header files. Functions should be ordered within source files to
minimize the number of function prototypes, by defining them before
@@ -121,13 +208,13 @@
Hi,
On Tue, Jun 26, 2012 at 11:06:15AM -0700, Lawrence Crowl wrote:
On 6/26/12, Martin Jambor mjam...@suse.cz wrote:
On Mon, Jun 25, 2012 at 03:26:01PM -0700, Lawrence Crowl wrote:
I have no idea. I don't use emacs. The two-space rule for
members comes from the wiki. The one-space
On 06/27/2012 08:35 AM, Chiheng Xu wrote:
dynamic_cast use RTTI, while TREE_CODE are poor man's type info. RTTI
is better than TREE_CODE. But, If you decide to use RTTI, TREE_CODE
become redundant, that means all use of TREE_CODE should be removed,
sooner or later. Are you prepared for that ?
On 6/27/12, Martin Jambor mjam...@suse.cz wrote:
On Tue, Jun 26, 2012 at 11:06:15AM -0700, Lawrence Crowl wrote:
On 6/26/12, Martin Jambor mjam...@suse.cz wrote:
On Mon, Jun 25, 2012 at 03:26:01PM -0700, Lawrence Crowl wrote:
+but think twice before using it in code
+intended to last
Hi,
On Mon, Jun 25, 2012 at 03:26:01PM -0700, Lawrence Crowl wrote:
...
I have no idea. I don't use emacs. The two-space rule for members
comes from the wiki. The one-space rule for protection labels is
common practice. If folks want something else, changes are fine
with me.
I'll
On 06/25/2012 06:26 PM, Lawrence Crowl wrote:
+orcodegcc_unreachable/code. If the checks are expensive or the
+compiler can reasonably carry on after the error, they may be
+conditioned oncode--enable-checking/code./p
by using codegcc_checking_assert/code
[Rationale]
+FIXME: Discussion of
On 6/25/12, Alexandre Oliva aol...@redhat.com wrote:
On Jun 25, 2012, Lawrence Crowl cr...@google.com wrote:
+These conventions will change over time,
+but changing them requires that a convincing rationale.
s/that//
+Complex heirarchies are to be avoided.
s/heir/hier/
Both fixed.
--
On 6/26/12, Martin Jambor mjam...@suse.cz wrote:
On Mon, Jun 25, 2012 at 03:26:01PM -0700, Lawrence Crowl wrote:
I have no idea. I don't use emacs. The two-space rule for
members comes from the wiki. The one-space rule for protection
labels is common practice. If folks want something
With that concern stated, I will write into the conventions whatever
concensus arises.
Of course, I have no objection to an occasional inline cleanup.
That is, build with -Werror and adjusting inlines that have,
through the course of time, become larger than is useful.
This seems to be
On 6/26/12, Jason Merrill ja...@redhat.com wrote:
On 06/25/2012 06:26 PM, Lawrence Crowl wrote:
+orcodegcc_unreachable/code. If the checks are expensive or the
+compiler can reasonably carry on after the error, they may be
+conditioned oncode--enable-checking/code./p
by using
On Tue, 26 Jun 2012, Lawrence Crowl wrote:
Shall we enable RTTI?
I think any proposal for adding a new C++ feature to the standards should
go in its own thread on the gcc list with a meaningful subject, not this
thread which should simply be about integrating uncontroversial standards
in the
On 06/26/2012 02:47 PM, Joseph S. Myers wrote:
We should start by documenting standards that are a conservative and
uncontroversial extension of the C coding standards currently used - if we
need to ask the question about whether something should be allowed, it
should not be allowed in the
On Jun 26, 2012, at 11:06 AM, Lawrence Crowl wrote:
Alternatively, one could change the conventions to match an emacs
style. Either is fine we me, as long as the style is reasonable.
It is really nice to be able to use 5 year old emacsen out of the box on the
source tree and have it just
On Mon, 2012-06-25 at 15:17 -0700, Lawrence Crowl wrote:
On 6/25/12, Joseph S. Myers jos...@codesourcery.com wrote:
On Mon, 25 Jun 2012, Diego Novillo wrote:
[ Added doc maintainers in CC ]
I have added a bit more in the rationale, reached through the link
at the end of that section.
Magnus Fromreide ma...@lysator.liu.se writes:
Two spaces for members is common practice with GNU, and it seems to be
used for libstdc++.
One space for protection labels is not something I have heard of before
and libstdc++ uses no indentation for them.
A freshly started emacs also doesn't
[ Added doc maintainers in CC ]
While I'm not particularly interested in the details of the coding
conventions, I am interested in getting them in getting them installed
before we merge cxx-conversion to trunk.
Joseph, Gerald, do we have a process for accepting changes to coding
conventions?
It
On Mon, 25 Jun 2012, Diego Novillo wrote:
[ Added doc maintainers in CC ]
While I'm not particularly interested in the details of the coding
conventions, I am interested in getting them in getting them installed
before we merge cxx-conversion to trunk.
Joseph, Gerald, do we have a
On 6/25/12, Joseph S. Myers jos...@codesourcery.com wrote:
On Mon, 25 Jun 2012, Diego Novillo wrote:
[ Added doc maintainers in CC ]
While I'm not particularly interested in the details of the
coding conventions, I am interested in getting them in getting
them installed before we merge
On 6/25/12, Lawrence Crowl cr...@google.com wrote:
On 6/25/12, Joseph S. Myers jos...@codesourcery.com wrote:
On Mon, 25 Jun 2012, Diego Novillo wrote:
[ Added doc maintainers in CC ]
While I'm not particularly interested in the details of the
coding conventions, I am interested in
Hey Lawrence, thanks for this work and for keeping the public
up-to-date with this gcc-patches posting.
This looks pretty good to me.
The only remaining issue for me is the
fuzzyness/handwaving around inlining. I think the only way to really
enforce what can be inlined is not to have people
On 6/25/12, Benjamin Kosnik b...@redhat.com wrote:
The only remaining issue for me is the fuzzyness/handwaving
around inlining. I think the only way to really enforce what
can be inlined is not to have people use their best judgement,
or what they think is a small function, or what they
On Jun 25, 2012, Lawrence Crowl cr...@google.com wrote:
+These conventions will change over time,
+but changing them requires that a convincing rationale.
s/that//
+Complex heirarchies are to be avoided.
s/heir/hier/
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You
This patch updates the coding conventions to C++. The primary
source file is codingconventions.html. The coding conventions now
refer to a new file, codingrationale.html, providing the rationale
for some of the C++ conventions. The two files in question are
attached whole for your convenience.
41 matches
Mail list logo
