Lawrence Crowl writes:
| On 7/10/12, Gabriel Dos Reis wrote:
| > Jason Merrill writes:
| >
| > | On 07/09/2012 06:00 PM, Lawrence Crowl wrote:
| > | > Done. New patch attached, but note that the tags have been
| > | > stripped from the patch to avoid mailer problems.
| > |
| > | Thanks. If n
On 7/10/12, Gabriel Dos Reis wrote:
> Jason Merrill writes:
>
> | On 07/09/2012 06:00 PM, Lawrence Crowl wrote:
> | > Done. New patch attached, but note that the tags have been
> | > stripped from the patch to avoid mailer problems.
> |
> | Thanks. If nobody else has any comments, I think this
Jason Merrill writes:
| On 07/09/2012 06:00 PM, Lawrence Crowl wrote:
| > Done. New patch attached, but note that the 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!
-- Gaby
On 07/09/2012 06:00 PM, Lawrence Crowl wrote:
Done. New patch attached, but note that the 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
On 7/4/12, Jason Merrill wrote:
> On 07/03/2012 04:37 PM, Lawrence Crowl wrote:
>> On 7/1/12, Jason Merrill 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
On 07/03/2012 04:37 PM, Lawrence Crowl wrote:
On 7/1/12, Jason Merrill 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 adds no inform
Lawrence Crowl writes:
| On 7/1/12, Gabriel Dos Reis wrote:
| > On Fri, Jun 29, 2012 at 1:17 PM, Lawrence Crowl 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 wrote:
| >>> ..., does anyone object to re
On 7/1/12, Jason Merrill wrote:
> On 06/29/2012 02:17 PM, Lawrence Crowl wrote:
> > +RTTI anddynamic_cast
> > +
> > +
> > +Run-time type information (RTTI) is permitted
> > +when certain non-default--enable-checking options are
> > enabled,
> > +so as to allow checkers to report dynamic types.
>
On 7/1/12, Gabriel Dos Reis wrote:
> On Fri, Jun 29, 2012 at 1:17 PM, Lawrence Crowl 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 wrote:
>>> ..., does anyone object to removing the permission to use C++
>>> st
On 06/29/2012 02:17 PM, Lawrence Crowl wrote:
+RTTI anddynamic_cast
+
+
+Run-time type information (RTTI) is permitted
+when certain non-default--enable-checking options are
enabled,
+so as to allow checkers to report dynamic types.
+However, by default, RTTI is not permitted
+and the compiler m
On Fri, Jun 29, 2012 at 1:17 PM, Lawrence Crowl 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 wrote:
>> ..., does anyone object to removing the permission to use C++
>> streams?
>
> Having heard no objection, I remo
Resend, as I replied to a message that didn't have the usual suspects
on the cc line.
On 6/27/12, Lawrence Crowl 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
On 6/27/12, Lawrence Crowl 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 this patch?
BT
On Wed, 27 Jun 2012, Lawrence Crowl wrote:
> >> +Namespaces
> >> +
> >> +
> >> +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 map to nes
On 6/27/12, Martin Jambor wrote:
> On Tue, Jun 26, 2012 at 11:06:15AM -0700, Lawrence Crowl wrote:
> > On 6/26/12, Martin Jambor 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 a long time.
> >
On 6/27/12, Chiheng Xu wrote:
> On Jun 19, 2012, Lawrence Crowl wrote:
> > Function 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
On 6/27/12, Gabriel Dos Reis wrote:
>
> [...]
>
> | > 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
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 ?
Hi,
On Tue, Jun 26, 2012 at 11:06:15AM -0700, Lawrence Crowl wrote:
> On 6/26/12, Martin Jambor 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 f
On Tue, Jun 19, 2012 at 6:28 AM, Lawrence Crowl wrote:
> Function 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 @@
> necessary,
On Wed, Jun 27, 2012 at 2:35 PM, Chiheng Xu wrote:
> On Wed, Jun 27, 2012 at 2:19 AM, Lawrence Crowl wrote:
>> On 6/26/12, Jason Merrill wrote:
>>> On 06/25/2012 06:26 PM, Lawrence Crowl wrote:
>>> > +orgcc_unreachable. If the checks are expensive or the
>>> > +compiler can reasonably carry on
On Wed, Jun 27, 2012 at 2:19 AM, Lawrence Crowl wrote:
> On 6/26/12, Jason Merrill wrote:
>> On 06/25/2012 06:26 PM, Lawrence Crowl wrote:
>> > +orgcc_unreachable. If the checks are expensive or the
>> > +compiler can reasonably carry on after the error, they may be
>> > +conditioned on--enable-
[...]
| > 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 label
On Wed, Jun 27, 2012 at 2:35 AM, Magnus Fromreide wrote:
> On Mon, 2012-06-25 at 15:17 -0700, Lawrence Crowl wrote:
>> On 6/25/12, Joseph S. Myers wrote:
>> > On Mon, 25 Jun 2012, Diego Novillo wrote:
>> > > [ Added doc maintainers in CC ]
>> > >
>
>> I have added a bit more in the rationale, rea
Magnus Fromreide 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 indent access l
On Mon, 2012-06-25 at 15:17 -0700, Lawrence Crowl wrote:
> On 6/25/12, Joseph S. Myers 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.
>
> > > > +
>
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 wor
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 initia
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
Lawrence Crowl writes:
[...]
| Shall we enable RTTI?
Benjamin made compelling arguments for doing this. And I agree.
-- Gaby
On 6/26/12, Jason Merrill wrote:
> On 06/25/2012 06:26 PM, Lawrence Crowl wrote:
> > +orgcc_unreachable. If the checks are expensive or the
> > +compiler can reasonably carry on after the error, they may be
> > +conditioned on--enable-checking.
>
> by using gcc_checking_assert
I inserted that su
> 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
On 6/26/12, Martin Jambor 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 else,
On 6/25/12, Alexandre Oliva wrote:
> On Jun 25, 2012, Lawrence Crowl 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.
--
Lawrence Crowl
On 06/25/2012 06:26 PM, Lawrence Crowl wrote:
+orgcc_unreachable. If the checks are expensive or the
+compiler can reasonably carry on after the error, they may be
+conditioned on--enable-checking.
by using gcc_checking_assert
[Rationale]
+FIXME: Discussion of deleting inappropraite special
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
On Jun 25, 2012, Lawrence Crowl 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 must be the chan
On 6/25/12, Benjamin Kosnik 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 intend
> for th
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 u
On 6/25/12, Lawrence Crowl wrote:
> On 6/25/12, Joseph S. Myers 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
>> > t
On 6/25/12, Joseph S. Myers 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 cxx-conversio
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
[ 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
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.
44 matches
Mail list logo
