«

"Kaz Kylheku" <> wrote in message
news:...
> On 2011-11-12, BartC <> wrote:

>> In other words, anything is allowed, including source code, of C or
>> anything
>> else.
>
> No, because the formal language allowed within the comment excludes the
> digraph */ which may occur in the source code of C, inside a string
> literal, as part of a comment, or inside a // comment.

Well, yes; I mentioned */ a sentence or two later.

> It's more than a style issue; it's a formal language issue. Comments can
> only
> contain a subset of the possible set of C strings.
>
> It is useful that you can have a subset of C within comments, for
> instance,
> coding examples. They just can't have /*...*/ comments of their own, which
> is
> fine since they are already inside a comment which can explain everything.

What you're saying then is that /*...*/ comments are not a suitable
mechanism for commenting out code? The reason being that code might contain
(in perhaps one program in a thousand) a '*/' or "*/" token? Yet everyone
does this, and the world hasn't yet ended.

And perhaps /*...*/ isn't suitable for writing comments, period, since there
will from time to time be content that will break it. For example I couldn't
paste */this sentence/* into such a comment. Yet that doesn't bother many
people either.

> A mechanism for commenting out arbitrary code must be robust, period. This
> way
> it can be applied to a 50,000 line piece of source code without worry that
> anything breaks.
>
> #if 0 ... #endif satisfies that requirement.

Only if the code you're trying to 'comment out' is well-formed. If it's
unfinished, has open literals, and unbalanced #endifs scattered about, then
there will be problems. In this case /*...*/ might be a better bet...

--
bartc

Keith Thompson wrote:
) Willem <> writes:
)> Which is why I have changed my preference to writing this:
)>
)> some_function(10 /* param1 */
)> ,20 /* param2 */
)> #if 0
)> ,30 /* param3 */
)> #endif
)> );
)>
)> And not only in C, but in almost any language.
)>
)> The point is that this plays a lot nicer with revision control systems,
)> because adding or removing an argument is a 1-line change, whereas in the
)> other case it can potentially change the previous line as well.
)
) And if you want to comment out the *first* argument?
)
) I see your point, but personally I find that layout rather hard on
) my eyes. The need to comment out a single parameter is rare enough
) that I don't think it's worth it.

And the need to play nice with revision control systems ?
I do it a lot more for the benefit of version control than anything else
(though commenting out is a very rudimentary form of version control.)

If the language did allow a trailing comma, it wouldn't be an issue,
and even a change on the first argument would not be a problem:

some_function(
10, /* param1 */
20, /* param2 */
30, /* param3 */
);

Not allowing trailing commas means you wither get in trouble for the first
argument, or the last argument. Oh, and it makes automatic code generation
a tiny bit harder as well (generating JSON has the same problem).

So I would be all in favour of this feature.
Is there any possible (existing) code that this would break ?
AFAIK, it will turn something that was a syntax error into good code.
(It may even be that existing implementations are allowed to let you off
with a warning and generate code as if the trailing comma weren't there.)


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

On 12-Nov-11 08:44, Eric Sosman wrote:
> On 11/12/2011 9:21 AM, Stephen Sprunk wrote:
>> On 11-Nov-11 15:54, Keith Thompson wrote:
>>> C99 changed the syntax to permit a trailing comma in an enum
>>> declaration. It would have made sense to permit a trailling
>>> comma for *any* comma-separated list. (Probably not for the comma
>>> operator, though.)
>>
>> Why not? If ";" is a valid statement, then why shouldn't ",;" be valid?
>
> Do you think `*;' should be valid?
>
> (If so, how many operands have been omitted?

Amusing, but sort of misses the point since it hinges on _how_ "," is
defined rather than defending _why_ it is so defined.

Absent side effects, "x,y;" is equivalent to "y;". The expression ""
cannot have side effects, so ",y;" should also be equivalent to "y;" and
therefore be valid.

Absent side effects, ",y;" is equivalent to ";". The expression ""
cannot have side effects, so ",;" should also be equivalent to ";" and
therefore valid.

Absent side effects, "x,;" is equivalent to "x;". The expression ""
cannot have side effects, so "x,;" should also be equivalent to ";" and
therefore valid.

The problem is that both operands must be evaluated by the operator
before it can discard the results, and the current language definition
does not define how to evaluate a null expression. However, what if it did?

This is similar to not allowing objects of type void; such an object is
obviously meaningless, but there are certain corner cases where
uniformity matters more than meaning.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

On Fri, 2011-11-11, Aron Packer wrote:
> Hi all,
>
> (Apologies if this is in a FAQ somewhere, I couldn't find anything).
>
> Almost every time I do any significant amount of coding in C or C++, I
> end up wishing C-style comments would nest. It would make rapid
> debugging much more convenient (vs. #if 0/#endif or editor macros).

This is not an answer, but IMNSHO:

Commenting out code is almost always a mistake. Either
(a) read the code and reason about it until you can make it right
or
(b) remove it and pick it up from version control or the undo feature
of your editor if it turns out you really need it

At the other extreme, when people leave commented-out code in
committed code (code they feel is ready to share with others) you can
be reasonably sure that something is very wrong.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

"BartC" <> writes:
[...]
> What you're saying then is that /*...*/ comments are not a suitable
> mechanism for commenting out code? The reason being that code might contain
> (in perhaps one program in a thousand) a '*/' or "*/" token? Yet everyone
> does this, and the world hasn't yet ended.

/*...*/ comments are not a suitable mechanism for commenting out code
because code often includes its own /*...*/ comments, and they don't
nest.

Most of the issues involving '*/' or "*/" tokens don't even arise until
you start talking about changing the language to allow /*...*/ comments
to nest, and any such change would break existing code.

It's been mentioned several times that changing the language to allow
/*...*/ comments to nest would break existing code. If you've ever
acknowledged that very important point, I've missed it.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Willem <> writes:
> Keith Thompson wrote:
> ) Willem <> writes:
> )> Which is why I have changed my preference to writing this:
> )>
> )> some_function(10 /* param1 */
> )> ,20 /* param2 */
> )> #if 0
> )> ,30 /* param3 */
> )> #endif
> )> );
> )>
> )> And not only in C, but in almost any language.
> )>
> )> The point is that this plays a lot nicer with revision control systems,
> )> because adding or removing an argument is a 1-line change, whereas in the
> )> other case it can potentially change the previous line as well.
> )
> ) And if you want to comment out the *first* argument?
> )
> ) I see your point, but personally I find that layout rather hard on
> ) my eyes. The need to comment out a single parameter is rare enough
> ) that I don't think it's worth it.
>
> And the need to play nice with revision control systems ?
> I do it a lot more for the benefit of version control than anything else
> (though commenting out is a very rudimentary form of version control.)

Revision control systems can fend for themselves. If they end up
storing an extra line or two of diffs, that's not much of a problem.
Diff tools can be configured to show a few lines of context around each
change; some do so by default.

> If the language did allow a trailing comma, it wouldn't be an issue,
> and even a change on the first argument would not be a problem:
>
> some_function(
> 10, /* param1 */
> 20, /* param2 */
> 30, /* param3 */
> );
>
> Not allowing trailing commas means you wither get in trouble for the first
> argument, or the last argument. Oh, and it makes automatic code generation
> a tiny bit harder as well (generating JSON has the same problem).
>
> So I would be all in favour of this feature.
> Is there any possible (existing) code that this would break ?
> AFAIK, it will turn something that was a syntax error into good code.
> (It may even be that existing implementations are allowed to let you off
> with a warning and generate code as if the trailing comma weren't there.)

A syntax error, like a constraint violation, merely requires the
compiler to issue a diagnostic. What it does after that is undefined.

More realistically, perhaps, a compiler could permit trailing commas in
a non-conforming mode (most compilers are non-conforming by default
anyway).

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson wrote:
) Willem <> writes:
)> And the need to play nice with revision control systems ?
)> I do it a lot more for the benefit of version control than anything else
)> (though commenting out is a very rudimentary form of version control.)
)
) Revision control systems can fend for themselves. If they end up
) storing an extra line or two of diffs, that's not much of a problem.
) Diff tools can be configured to show a few lines of context around each
) change; some do so by default.

It's the merging where the problems start. I know, I've seen it happen.
Enough times for me to change my preference to the comma at the start of
theline, which would have avoided those merge conflicts.

)> So I would be all in favour of this feature.
)> Is there any possible (existing) code that this would break ?
)> AFAIK, it will turn something that was a syntax error into good code.
)> (It may even be that existing implementations are allowed to let you off
)> with a warning and generate code as if the trailing comma weren't there.)
)
) A syntax error, like a constraint violation, merely requires the
) compiler to issue a diagnostic. What it does after that is undefined.

So yes, they are allowed to let you off with a warning?
AFAIK, an implementation can define what it does in the case of certain
undefined behaviour. So, here's to compiler writers: make it a warning!

) More realistically, perhaps, a compiler could permit trailing commas in
) a non-conforming mode (most compilers are non-conforming by default
) anyway).

If enough compilers permit it, it would go into the next standard.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

On 11/13/2011 05:30 AM, Willem wrote:
> Keith Thompson wrote:
....
> ) A syntax error, like a constraint violation, merely requires the
> ) compiler to issue a diagnostic. What it does after that is undefined.
>
> So yes, they are allowed to let you off with a warning?
> AFAIK, an implementation can define what it does in the case of certain
> undefined behaviour.

You can drop the word "certain" there, It is always the case that if the
behavior is undefined, the C standard imposes no restrictions, leaving
an implementation free to provide its own definition.
--
James Kuyper

James Kuyper wrote:
) On 11/13/2011 05:30 AM, Willem wrote:
)> Keith Thompson wrote:
) ...
)> ) A syntax error, like a constraint violation, merely requires the
)> ) compiler to issue a diagnostic. What it does after that is undefined.
)>
)> So yes, they are allowed to let you off with a warning?
)> AFAIK, an implementation can define what it does in the case of certain
)> undefined behaviour.
)
) You can drop the word "certain" there, It is always the case that if the
) behavior is undefined, the C standard imposes no restrictions, leaving
) an implementation free to provide its own definition.

Yes, but the implementation can choose that it only does that for some
behaviours, and not for others. I see how the wording is confusing.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

"BartC" <> writes:
> "Ian Collins" <ian-> wrote in message
> news:...
> > On 11/12/11 11:54 PM, BartC wrote:
> >> "Kaz Kylheku"<> wrote in message
> >> news:...
> >>> On 2011-11-11, BartC<> wrote:
> >>
> >>>> Perhaps have #comment ... #end then
> >>>
> >>> That's a useless syntactic sugar for #if 0; furthermore, it's badly
> >>> named since this feature is not for commenting. Your "comment" has
> >>> to be written in valid C preprocessor tokens.
> >>
> >> That was before I realised that #if 0 didn't work as I expected, ie.
> >> ignore
> >> everything except what was necessary to find a matching #endif.
> >
> > Removing the code works as expected.
>
> That's rather a drastic measure. Especially if you've just downloaded some
> source code and big chunks of it have been cut out! Rather difficult to
> reinstate then.

For values of 'difficult' almost indistinguishable from 'trivial'

$ git reset --hard HEAD

> Anyway suppose the commented lines are actually intended to be read?

"The" commented lines? Which commented lines? Your hypothetical is
purely in your own head currently. It's hard to suggest solutions to
problems unless they're unambiguously described. If there's no reason
to change the code you've been given, and it's valid code - then just
leave it alone. That's not, however, any justification for creating
new code that contains evidence of sloppy development practices.

Phil
--
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator