nesting coments

[Mantorok Redgormor]

I have a question for the sages here.

the comp.lang.c faq says:

20.20: Why don't C comments nest? Are they legal inside quoted
strings?

A: C comments don't nest because PL/I's comments don't either. The
character sequences /* and */ are not special within double-
quoted strings.
so what is the reason for the latter mentioned language
to not nest comments? Was it purely a design choice?
i.e., it wasn't that it was difficult to implement
it was just horribly ugly?

I, myself, wouldn't want nested comments because
it opens doors for allowing unnecessary cluttering
and conflation. But I'm curious as to the actual reason
behind disallowing it.

--
nethlek

[Leor Zolman]

On 8 Apr 2004 16:04:31 -0700, ne*****@tokyo.com (Mantorok Redgormor) wrote:

I have a question for the sages here.

the comp.lang.c faq says:

20.20: Why don't C comments nest? Are they legal inside quoted
strings?

A: C comments don't nest because PL/I's comments don't either. The
character sequences /* and */ are not special within double-
quoted strings.
so what is the reason for the latter mentioned language
to not nest comments? Was it purely a design choice?
i.e., it wasn't that it was difficult to implement
it was just horribly ugly?

I, myself, wouldn't want nested comments because
it opens doors for allowing unnecessary cluttering
and conflation. But I'm curious as to the actual reason
behind disallowing it.

To quickly nip "runaway" comments in the bud? Personally, I always wanted
to be able to use nested comments, so I believe I had BDS C support them
(it is amazing how many specific features of that compiler I cannot
remember precisely). But at the same time (or at least soon after folks
began complaining), I included a diagnostic pointing to the /start/ of the
outer-level runaway comment if the compiler reached EOF and was still
within a comment. Without that diagnostic ability, the "feature" would have
been a nightmare...
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[CBFalconer]

Mantorok Redgormor wrote:

.... snip ...
I, myself, wouldn't want nested comments because it opens doors
for allowing unnecessary cluttering and conflation. But I'm
curious as to the actual reason behind disallowing it.

Probably because back in pre-historic times it was much easier to
parse. We read the sequence "/*", discard it, and read source
until the sequence "*/" appears, returning a single blank. No
need to count things, save things, whatever.

It remains easier to parse.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Martin Dickopp]

Leor Zolman <le**@bdsoft.com> writes:

Personally, I always wanted to be able to use nested comments,

Why? What would you possibly want to say in a comment (i.e. in an
explanatory text) that requires nested comments?

The only reason I can see why one would nest comments is to temporarily
"comment out" code sections. For that, I prefer #if 0 ... #endif, which
does nest.

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[Leor Zolman]

On Fri, 09 Apr 2004 09:54:55 +0200, Martin Dickopp
<ex****************@zero-based.org> wrote:

Leor Zolman <le**@bdsoft.com> writes:

Personally, I always wanted to be able to use nested comments,
Why? What would you possibly want to say in a comment (i.e. in an
explanatory text) that requires nested comments?

The only reason I can see why one would nest comments is to temporarily
"comment out" code sections. For that, I prefer #if 0 ... #endif, which
does nest.

Well, /I/ prefer commenting out code sections with comments while
debugging...less typing, more intuitive to me. Your mileage obviously
varies. Note that I don't prefer it /enough/ to go throwing compiler
switches now in order to have it supported. I just use C++ comments
everywhere...so I can temporarily comment out at least one non-nested
section when necessary using C comments.

I grumble when code I've copied-and-pasted from a newsgroup post has C
comments and I need to comment out a section ;-)
-leor

Martin

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On Fri, 09 Apr 2004 07:06:13 GMT, CBFalconer <cb********@yahoo.com> wrote:

Mantorok Redgormor wrote:

... snip ...

I, myself, wouldn't want nested comments because it opens doors
for allowing unnecessary cluttering and conflation. But I'm
curious as to the actual reason behind disallowing it.

Probably because back in pre-historic times it was much easier to
parse. We read the sequence "/*", discard it, and read source
until the sequence "*/" appears, returning a single blank. No
need to count things, save things, whatever.

It remains easier to parse.

But not by much, and the resources saved on contemporary systems would have
to be described as infinitesimal.

As I recall, when that BDS C user complained about the "unexpected EOF"
message early versions of the compiler gave as a result of runaway
comments, it took me all of an hour or so to add the smarter diagnostic
capability (and most of that was waiting for the assembler to churn through
several debug cycles.) Afterwards I felt like an idiot for not having
thought of doing that in the first place. I must not have written any test
programs with runaway comments.
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[CBFalconer]

Leor Zolman wrote:

.... snip ...
I grumble when code I've copied-and-pasted from a newsgroup post
has C comments and I need to comment out a section ;-)

I grumble AND BITCH when such code has C++ comments, illegal under
C89, and even worse, wrapped during posting.

--
Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses. - James Rhodes.

[Leor Zolman]

On Fri, 09 Apr 2004 14:47:28 GMT, CBFalconer <cb********@yahoo.com> wrote:

Leor Zolman wrote:

... snip ...

I grumble when code I've copied-and-pasted from a newsgroup post
has C comments and I need to comment out a section ;-)

I grumble AND BITCH when such code has C++ comments, illegal under
C89, and even worse, wrapped during posting.

I /have/ been trying to remember to use only C comments here in clc, in
deference to folks having (or choosing) to use compilers (or settings) that
don't support the C++-style comments. And yes, the wrapping /is/ a total
pain in the ass, I must agree.

But this does still seem to be a case of irresistable force meets immovable
object...
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Leor Zolman]

On Fri, 09 Apr 2004 14:47:28 GMT, CBFalconer <cb********@yahoo.com> wrote:

Leor Zolman wrote:

... snip ...

I grumble when code I've copied-and-pasted from a newsgroup post
has C comments and I need to comment out a section ;-)

I grumble AND BITCH when such code has C++ comments, illegal under
C89, and even worse, wrapped during posting.

BTW, I cracked up over your Mr. Ed sig on that message...and finally
realized the value of that funky "-- " sig separator as I tried to reply
and include the quote in my response ;-)
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Peter Pichler]

"Mantorok Redgormor" <ne*****@tokyo.com> wrote in message
news:41*************************@posting.google.co m...

I have a question for the sages here.

the comp.lang.c faq says:

20.20: Why don't C comments nest? Are they legal inside quoted
strings?

Just an observation: this is the first time I see this "frequently asked
question" actually asked.

Peter

[Leor Zolman]

On Fri, 9 Apr 2004 17:38:53 +0100, "Peter Pichler" <pi*****@pobox.sk>
wrote:

"Mantorok Redgormor" <ne*****@tokyo.com> wrote in message
news:41*************************@posting.google.c om...

I have a question for the sages here.

the comp.lang.c faq says:

20.20: Why don't C comments nest? Are they legal inside quoted
strings?
Just an observation: this is the first time I see this "frequently asked
question" actually asked.

So that implies either that it isn't really an FA'd Q, or that we have new
posters quivering in their boots about posting Q's from the FAQ and
everyone has read the answer there already... (NOT!)
-leor

Peter

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Joe Wright]

Leor Zolman wrote:

[ snip all ]

What would be the harm in a compiler allowing and supporting nested
comments? Even though Standard C doesn't support it, is a conforming
compiler required to diagnose it as an error?

But now that I think about it, nesting comments doesn't make sense. In
fact we probably use the term 'comment' badly and abuse its intent. What
do we think when we 'comment out' parts of our program? We are not
making a comment, we are trying to hide the stuff from the compiler.

At least two methods for hiding code come immediately to mind.

#if 0
...hidden code..
#endif

and

if (0) {
..hidden code..
}

Both methods can be nested.

Note that the ..hidden code.. is still parsed by the compiler. Syntax
and other errors are checked and reported. You can't put free-form text
in there the way you do with comments.
--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Peter Pichler]

"Joe Wright" <jo********@comcast.net> wrote in message
news:bO********************@comcast.com...

#if 0
..hidden code..
#endif
<snip>
Note that the ..hidden code.. is still parsed by the compiler. Syntax
and other errors are checked and reported. You can't put free-form text
in there the way you do with comments.

A minor correction: it is parsed by the /preprocessor/. Syntax and other
errors are /not/ checked and reported, provided they form valid
preprocessor tokens. Your last sentence is true, though.

Peter

[Leor Zolman]

On Fri, 09 Apr 2004 13:15:53 -0400, Joe Wright <jo********@comcast.net>
wrote:

Leor Zolman wrote:

[ snip all ]

What would be the harm in a compiler allowing and supporting nested
comments? Even though Standard C doesn't support it, is a conforming
compiler required to diagnose it as an error?

But now that I think about it, nesting comments doesn't make sense.
Not for code you wish to release, of course not.
In
fact we probably use the term 'comment' badly and abuse its intent. What
do we think when we 'comment out' parts of our program? We are not
making a comment, we are trying to hide the stuff from the compiler.
Precisely. In my case, for debugging purposes.

At least two methods for hiding code come immediately to mind.

#if 0
..hidden code..
#endif

and

if (0) {
..hidden code..
}

Both methods can be nested.
And both are a pain compared to simply commenting out sections of code;
say, if you're trying to play with two alternate forms of a construct, and
don't wish to have to go "formalize" the process with a preprocessor
symbol, etc. etc. ad nauseam.

Note that the ..hidden code.. is still parsed by the compiler.
In the scenarios I'm talking about, that's /not/ what I want!
Syntax
and other errors are checked and reported. You can't put free-form text
in there the way you do with comments.

With nested comments, I can have any ole' broken, half-baked code in there,
and that's exactly what I /do/ want to be able to have in there.
-leor


--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Eric Sosman]

Joe Wright wrote:

Leor Zolman wrote:

[ snip all ]

What would be the harm in a compiler allowing and supporting nested
comments? Even though Standard C doesn't support it, is a conforming
compiler required to diagnose it as an error?

The compiler is not required to issue a diagnostic when
`/*' appears inside a comment, if that's what you mean. On
the other hand, the compiler must diagnose `/* /* */ */'
because the comment ends at the first `*/', and the second
`*/' is a syntax error.

With C99, of course, nested comments are perfectly legal:

/* This is an outer comment ...
// ... containing a nested comment ...
... and then the outer comment continues */

However, the use of the term "nested" is debatable here.

It's possible to concoct valid sources that somewhat
resemble nested comments, e.g.

int i = 1
/* outer comment
/* inner comment */
*//
0;

.... whose effect is the same as `int i = 0;'.

--
Er*********@sun.com

[Leor Zolman]

On Fri, 09 Apr 2004 14:19:37 -0400, Eric Sosman <Er*********@sun.com>
wrote:

Joe Wright wrote:

Leor Zolman wrote:

[ snip all ]

What would be the harm in a compiler allowing and supporting nested
comments? Even though Standard C doesn't support it, is a conforming
compiler required to diagnose it as an error?

The compiler is not required to issue a diagnostic when
`/*' appears inside a comment, if that's what you mean. On
the other hand, the compiler must diagnose `/* /* */ */'
because the comment ends at the first `*/', and the second
`*/' is a syntax error.

With C99, of course, nested comments are perfectly legal:

/* This is an outer comment ...
// ... containing a nested comment ...
... and then the outer comment continues */

However, the use of the term "nested" is debatable here.

It's possible to concoct valid sources that somewhat
resemble nested comments, e.g.

int i = 1
/* outer comment
/* inner comment */
*//
0;

... whose effect is the same as `int i = 0;'.

I did /not/ need to see that :P
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Rob Thorpe]

CBFalconer <cb********@yahoo.com> wrote in message news:<40***************@yahoo.com>...

Mantorok Redgormor wrote:

... snip ...

I, myself, wouldn't want nested comments because it opens doors
for allowing unnecessary cluttering and conflation. But I'm
curious as to the actual reason behind disallowing it.

Probably because back in pre-historic times it was much easier to
parse. We read the sequence "/*", discard it, and read source
until the sequence "*/" appears, returning a single blank. No
need to count things, save things, whatever.

It remains easier to parse.

Disallowing nested comments has one key advantage:

If they are disallowed then C comments can be described with a regular
expression.

This makes it easier to use grep, awk, or your editors regexp replace
on your code.

The only significant problems with the practice of using
#if 0
#endif

is that it looks strange. It's good that there are now editors that
can deal with it visually.

[August Derleth]

On Fri, 09 Apr 2004 17:34:54 -0700, Rob Thorpe wrote:

CBFalconer <cb********@yahoo.com> wrote in message news:<40***************@yahoo.com>...

Mantorok Redgormor wrote:

> ... snip ...

>
> I, myself, wouldn't want nested comments because it opens doors
> for allowing unnecessary cluttering and conflation. But I'm
> curious as to the actual reason behind disallowing it.

Probably because back in pre-historic times it was much easier to
parse. We read the sequence "/*", discard it, and read source
until the sequence "*/" appears, returning a single blank. No
need to count things, save things, whatever.

It remains easier to parse.

Disallowing nested comments has one key advantage:

If they are disallowed then C comments can be described with a regular
expression.

True regexes can't match nested structures because they can't describe
recursion. (They aren't Turing-complete, in other words.) This is one
reason why the language-theoretic `pure regexes' suck.

Perl regexes, on the other hand, /can/ match nested structures. This is a
fundamental departure from theory, of course, and it relies on the ability
to assign a regex to a value and then refer to that value within the regex
itself. This is one reason why Perl regexes are called `patterns' in that
text, and it could allow hideously complex Perl patterns to do the work of
less hideous Perl programs. ;)

(On the upside, Perl patterns are probably at least as powerful as BNF
now, which could lead to some interesting compiler design decisions.)

The example:

my $np;
$np = qr{
\(
(?:
(?> [^()]+ ) # Non-parens without backtracking.
|
(??{ $np }) # Group with matching parens.
)*
\)
}x;

my $funpat = qr/\w+$np/;
'myfun(1, (2*(3+4)),5)' =~ /^$funpat$/; # Matches!

This makes it easier to use grep, awk, or your editors regexp replace
on your code.
Perl is, on most *nix systems, at least as common as the GNU coreutils (or
their non-free equivalents). The disk images for PDP-11 V7 UNIX I
downloaded last night didn't have it, but I suppose us antiquarians must
make concessions to unpleasant realities.

In any case, a simple bison (or yacc) program (with a flex/lex frontend)
can trivially match nested comments.

But, in the general case, you are absolutely correct: The standard text
utilities use regexes that are fairly close to the language-theoretic
ones, and therefore can't handle recursion correctly. But making language
design decisions on that basis alone seems rather sideways.

The only significant problems with the practice of using
#if 0
#endif

is that it looks strange. It's good that there are now editors that
can deal with it visually.

--
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.

[Arthur J. O'Dwyer]

On Sat, 10 Apr 2004, August Derleth wrote in his .sig:

"Makes hackers smile" makes hackers smile.

"Is the first half of this quine" is the first half of this quine.

;-)

-Arthur,
as long as the [OT] tag is already there

[Michael Wojcik]

In article <5v********************************@4ax.com>, Leor Zolman <le**@bdsoft.com> writes:

On Fri, 09 Apr 2004 13:15:53 -0400, Joe Wright <jo********@comcast.net>
wrote:

What would be the harm in a compiler allowing and supporting nested
comments? Even though Standard C doesn't support it, is a conforming
compiler required to diagnose it as an error?
Breaks existing code. I've seen source where several lines, each
ending with a comment, are commented out by replacing the first two
characters (which were spaces) with "/*". For example:

/* x = foo(); /* get result of foo */

While I certainly don't *recommend* that, it is existing practice,
and changes to the standard usually seek to minimize adverse
effects on existing code.
At least two methods for hiding code come immediately to mind.

#if 0
..hidden code..
#endif
And both are a pain compared to simply commenting out sections of code;

I don't see how inserting a

#if 0

and a

#endif

is any more trouble than inserting comment delimiters. It's a grand
total of 9 more characters (10 if you count the newlines, but
commenting out code without putting the delimiters on a separate
line is a barbarism not to be contemplated).
say, if you're trying to play with two alternate forms of a construct, and
don't wish to have to go "formalize" the process with a preprocessor
symbol, etc. etc. ad nauseam.
#if 0 is *better* than a comment for trying two different forms,
since you can put them into the two halves of a #if / #else and
switch between them by changing a single character (0 becomes 1).

If by "preprocessor symbol" you mean a macro as the operand of
the "defined" operator (or of #ifdef), none is required. But you
*can* use one if you'd like to be able to select which form you're
using without editing the source (in typical implementations) - a
luxury not available if you use comments to remove code.
With nested comments, I can have any ole' broken, half-baked code in there,
and that's exactly what I /do/ want to be able to have in there.

So long as it's a string of legal pp-tokens, you can do the same
with #if 0. No need for it to be legal C code.

--
Michael Wojcik mi************@microfocus.com

Q: What is the derivation and meaning of the name Erwin?
A: It is English from the Anglo-Saxon and means Tariff Act of 1909.
-- Columbus (Ohio) Citizen

[Leor Zolman]

On 13 Apr 2004 19:59:32 GMT, mw*****@newsguy.com (Michael Wojcik) wrote:

In article <5v********************************@4ax.com>, Leor Zolman <le**@bdsoft.com> writes:

On Fri, 09 Apr 2004 13:15:53 -0400, Joe Wright <jo********@comcast.net>
wrote:

>What would be the harm in a compiler allowing and supporting nested
>comments? Even though Standard C doesn't support it, is a conforming
>compiler required to diagnose it as an error?
Breaks existing code. I've seen source where several lines, each
ending with a comment, are commented out by replacing the first two
characters (which were spaces) with "/*". For example:

/* x = foo(); /* get result of foo */

While I certainly don't *recommend* that, it is existing practice,
and changes to the standard usually seek to minimize adverse
effects on existing code.

OK, but I see nested comments as a personal time-saving device, and the
technique above as some kind of parallel time-saving device. Clearly the
two devices should not be placed in close proximity, and in any sane shop
they wouldn't be...or not for very long.

>At least two methods for hiding code come immediately to mind.
>
>#if 0
>..hidden code..
>#endif

And both are a pain compared to simply commenting out sections of code;

I don't see how inserting a

#if 0

and a

#endif

is any more trouble than inserting comment delimiters. It's a grand
total of 9 more characters (10 if you count the newlines, but
commenting out code without putting the delimiters on a separate
line is a barbarism not to be contemplated).

Well, and then there's finding the shift key, finding the # key (twice for
both), being in a hurry so having to backspace a few times while typing it
all out, .... ;-)

say, if you're trying to play with two alternate forms of a construct, and
don't wish to have to go "formalize" the process with a preprocessor
symbol, etc. etc. ad nauseam.
#if 0 is *better* than a comment for trying two different forms,
since you can put them into the two halves of a #if / #else and
switch between them by changing a single character (0 becomes 1).

Yes, there I'm now inclined to agree with you.

If by "preprocessor symbol" you mean a macro as the operand of
the "defined" operator (or of #ifdef), none is required. But you
*can* use one if you'd like to be able to select which form you're
using without editing the source (in typical implementations) - a
luxury not available if you use comments to remove code.

With nested comments, I can have any ole' broken, half-baked code in there,
and that's exactly what I /do/ want to be able to have in there.

So long as it's a string of legal pp-tokens, you can do the same
with #if 0. No need for it to be legal C code.

Okay, some pros and cons. BTW, I don't use nested comments any more at all,
just because of the hassle of dealing with the compiler settings I'd have
to finagle across all the platforms I currently play musical compilers
with. But I'll probably end up adopting your #if 0 / #if 1/ #else
suggestion for switching alternate blocks of code.
Thanks,
-leor
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Keith Thompson]

mw*****@newsguy.com (Michael Wojcik) writes:

In article <5v********************************@4ax.com>, Leor Zolman
<le**@bdsoft.com> writes:

[...]

At least two methods for hiding code come immediately to mind.

#if 0
..hidden code..
#endif

And both are a pain compared to simply commenting out sections of code;

I don't see how inserting a

#if 0

and a

#endif

is any more trouble than inserting comment delimiters. It's a grand
total of 9 more characters (10 if you count the newlines, but
commenting out code without putting the delimiters on a separate
line is a barbarism not to be contemplated).

[...]

Personally, I like comments that extend from a delimiter to the end of
a line, and cannot cross line boundaries (like Ada's "--", C99/C++'s
"//", and Perl's "#"). In any decent text editor (both emacs and vi
qualify), it's easy to comment out or uncomment a range of lines, and
the comment marker is clearly visible on each line. If you comment
out a section of code with "#if 0" ... "#endif", it's easy to miss the
preprocessor directives if you're looking at the middle of the
commented-out section. You can even (effectively) nest comments:

// some code that we're not currently using;
// // a comment about it
// and some more code that we're not currently using;
some code that we are using; // and a comment about it

I know, of course, that "//" comments aren't portable to C90
compilers, and that they can cause line-wrapping problems in code
posted to Usenet. But when I build my time machine, one of the
suggestions I'm going to make is to support "//" comments and *not*
"/* ... */" comments in C from the very beginning. (I'll also suggest
ignoring any whitespace between a '\' and the end of a line.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Leor Zolman]

On Tue, 13 Apr 2004 20:53:30 GMT, Keith Thompson <ks***@mib.org> wrote:

Personally, I like comments that extend from a delimiter to the end of
a line, and cannot cross line boundaries (like Ada's "--", C99/C++'s
"//", and Perl's "#"). In any decent text editor (both emacs and vi
qualify), it's easy to comment out or uncomment a range of lines, and
the comment marker is clearly visible on each line.

I've done a lot of Perl hacking over the past three years, and I've sorely
missed C-style comments. I just now did a Google search and discovered
something that looks like:

=pod

blah blah

=cut

which I guess comes close to /* ... */. I guess I should have done that
Googling three years ago ;-)
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Mabden]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

mw*****@newsguy.com (Michael Wojcik) writes:

In article <5v********************************@4ax.com>, Leor Zolman
<le**@bdsoft.com> writes:

[...]

>At least two methods for hiding code come immediately to mind.
>
>#if 0
>..hidden code..
>#endif

And both are a pain compared to simply commenting out sections of

code;
I don't see how inserting a

#if 0

and a

#endif

is any more trouble than inserting comment delimiters. It's a grand
total of 9 more characters (10 if you count the newlines, but
commenting out code without putting the delimiters on a separate
line is a barbarism not to be contemplated).

[...]

That construct doesn't compile in C#, FWIW, so don't get too used to it.
As soon as MicroGates takes over the world, you will be assimilated.
Resistance is futile. For reals.

--
Mabden

[Dan Pop]

In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

posted to Usenet. But when I build my time machine, one of the
suggestions I'm going to make is to support "//" comments and *not*
"/* ... */" comments in C from the very beginning.
You'll have a strong case for that: IIRC, B supported // comments.
(I'll also suggest
ignoring any whitespace between a '\' and the end of a line.)

Even better, make \ outside of character and string literals a syntax
error, except for macro definitions.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <8r********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On Tue, 13 Apr 2004 20:53:30 GMT, Keith Thompson <ks***@mib.org> wrote:

Personally, I like comments that extend from a delimiter to the end of
a line, and cannot cross line boundaries (like Ada's "--", C99/C++'s
"//", and Perl's "#"). In any decent text editor (both emacs and vi
qualify), it's easy to comment out or uncomment a range of lines, and
the comment marker is clearly visible on each line.

I've done a lot of Perl hacking over the past three years, and I've sorely
missed C-style comments. I just now did a Google search and discovered
something that looks like:

=pod

blah blah

=cut

which I guess comes close to /* ... */. I guess I should have done that
Googling three years ago ;-)

That's not a particularly bright idea, either. Some day, you may want to
use this Perl feature for its intended purpose (keeping Perl code and its
documentation together) and having PODs containing "garbage" will bite
you.

Do yourself a favour and read the perlpod man page...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Leor Zolman]

On 14 Apr 2004 13:22:38 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <8r********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On Tue, 13 Apr 2004 20:53:30 GMT, Keith Thompson <ks***@mib.org> wrote:

Personally, I like comments that extend from a delimiter to the end of
a line, and cannot cross line boundaries (like Ada's "--", C99/C++'s
"//", and Perl's "#"). In any decent text editor (both emacs and vi
qualify), it's easy to comment out or uncomment a range of lines, and
the comment marker is clearly visible on each line.
I've done a lot of Perl hacking over the past three years, and I've sorely
missed C-style comments. I just now did a Google search and discovered
something that looks like:

=pod

blah blah

=cut

which I guess comes close to /* ... */. I guess I should have done that
Googling three years ago ;-)

That's not a particularly bright idea, either. Some day, you may want to
use this Perl feature for its intended purpose (keeping Perl code and its
documentation together) and having PODs containing "garbage" will bite
you.

I guess I'm really in danger of developing an inferiority complex if I keep
drawing the kinds of replies I've been getting from /you/ lately ;-)

Anything that would have helped me (during the countless hours of
debugging I've been doing with Perl scripts) to comment out large sections
of code easily would have indeed been a "particularly bright idea" (or at
least a useful one), and saved me much misery. I've never used this Perl
feature "for its intended purpose", nor do I suspect I ever will. As I
believe I must have mentioned several times now in various points in this
thread, I don't generally ship code with large sections of code commented
out (at least not on purpose). This hack would've been for my internal
debugging use only.

Do yourself a favour and read the perlpod man page...

I'll put it on my list, thanks.
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Dan Pop]

In <g8********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On 14 Apr 2004 13:22:38 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <8r********************************@4ax.com> Leor Zolman <le**@bdsoft.com> writes:

On Tue, 13 Apr 2004 20:53:30 GMT, Keith Thompson <ks***@mib.org> wrote:

Personally, I like comments that extend from a delimiter to the end of
a line, and cannot cross line boundaries (like Ada's "--", C99/C++'s
"//", and Perl's "#"). In any decent text editor (both emacs and vi
qualify), it's easy to comment out or uncomment a range of lines, and
the comment marker is clearly visible on each line.

I've done a lot of Perl hacking over the past three years, and I've sorely
missed C-style comments. I just now did a Google search and discovered
something that looks like:

=pod

blah blah

=cut

which I guess comes close to /* ... */. I guess I should have done that
Googling three years ago ;-)

That's not a particularly bright idea, either. Some day, you may want to
use this Perl feature for its intended purpose (keeping Perl code and its
documentation together) and having PODs containing "garbage" will bite
you.

Anything that would have helped me (during the countless hours of
debugging I've been doing with Perl scripts) to comment out large sections
of code easily would have indeed been a "particularly bright idea" (or at
least a useful one), and saved me much misery.

And you couldn't figure out that Perl's goto was *exactly* what you
needed?

goto end_comment1;

perl code commented out

end_comment1:

By using a consistent naming convention for the label names (as suggested
above) you could immediately tell the difference between a "good" goto
(if you used any in your code) and the ones used for commenting out
large blocks of Perl code.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Leor Zolman]

On 14 Apr 2004 17:39:33 GMT, Da*****@cern.ch (Dan Pop) wrote:

And you couldn't figure out that Perl's goto was *exactly* what you
needed?

Nope, never knew it had one. I was rather surprised to just see that Larry
Wall put in in there. (And I'm really *not* interested in hearing about why
you think I was wrong to be surprised.)
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[CBFalconer]

Leor Zolman wrote:

On 14 Apr 2004 13:22:38 GMT, Da*****@cern.ch (Dan Pop) wrote:
.... snip ...

That's not a particularly bright idea, either. Some day, you may
want to use this Perl feature for its intended purpose (keeping
Perl code and its documentation together) and having PODs
containing "garbage" will bite you.

I guess I'm really in danger of developing an inferiority complex
if I keep drawing the kinds of replies I've been getting from /you/
lately ;-)

Dan is noted for his diplomatic coddling and gentle chastisement.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Keith Thompson]

Leor Zolman <le**@bdsoft.com> writes:

On 14 Apr 2004 13:22:38 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <8r********************************@4ax.com> Leor Zolman
<le**@bdsoft.com> writes: [...]That's not a particularly bright idea, either.

[...]
I guess I'm really in danger of developing an inferiority complex if I keep
drawing the kinds of replies I've been getting from /you/ lately ;-)

Don't worry about it. Apparently we're all inferior to Dan.

8-)} 8-)} 8-)} 8-)} 8-)} 8-)} 8-)} 8-)} 8-)} 8-)} 8-)}

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Arthur J. O'Dwyer]

On Wed, 14 Apr 2004, Dan Pop wrote:

[Leor: using POD to "comment out" Perl code]
[Dan: don't do that]

[Leor: then what?]

And you couldn't figure out that Perl's goto was *exactly* what you
needed?

goto end_comment1;

perl code commented out

end_comment1:

By using a consistent naming convention for the label names (as suggested
above) you could immediately tell the difference between a "good" goto
(if you used any in your code) and the ones used for commenting out
large blocks of Perl code.

That's an even worse idea than the POD idea! First of all, if you
use a "consistent naming convention" for all those comment-block-
delimiting labels, you'll eventually slip up and type the same label
name twice. Then you'll have

goto foo;
blah;
foo:
bar;
goto foo;
baz;
foo:

about which 'perl' will not complain at all, according to the cursory
test program I just ran. So you'll get an infinite loop when you
thought you were just skipping down the page!
Secondly, 'goto' does NOT remove the offending code from the program!
It will still be not only parsed, but actually run: any 'my' variables
in the "commented-out" section will get declared, for example. So
you'll end up with errors at best, and silent bugs at worst.

The best way to "comment out" Perl code I can think of --- and I
don't pretend to be any good at Perl --- is to simply enclose the
offending code in a here-document, like this:

<<'COMMENT';
my $j = 42; # This variable will never be declared!
comment1: # This label will never be jumped to!
biguglypieceofcode; # This code will never be compiled!
COMMENT
;

Perhaps if you ask a Perl hacker, he'll tell you how to make that
construct more user-friendly with some kind of macro or something,
I dunno.

And just for the record, from the mouth of 'perlsyn' itself:
"One may also use pod directives to quickly comment out a section of
code."

(-:
-Arthur

[Dan Pop]

In <Pi***********************************@unix46.andr ew.cmu.edu> "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:

On Wed, 14 Apr 2004, Dan Pop wrote:

>>> [Leor: using POD to "comment out" Perl code]
>> [Dan: don't do that]
> [Leor: then what?]
And you couldn't figure out that Perl's goto was *exactly* what you
needed?

goto end_comment1;

perl code commented out

end_comment1:

By using a consistent naming convention for the label names (as suggested
above) you could immediately tell the difference between a "good" goto
(if you used any in your code) and the ones used for commenting out
large blocks of Perl code.

That's an even worse idea than the POD idea! First of all, if you
use a "consistent naming convention" for all those comment-block-
delimiting labels, you'll eventually slip up and type the same label
name twice. Then you'll have

goto foo;
blah;
foo:
bar;
goto foo;
baz;
foo:

about which 'perl' will not complain at all, according to the cursory
test program I just ran.

If you can't trust yourself to be able to generate unique comment block
delimiting labels, "grep foo: *" is all you need to check for clashes.
One doesn't need a PhD in CS to be able to figure this out...

I prefer the goto method because it works in all the languages I'm
currently using. Well chosen label names make its usage for this
particular purpose obvious. Of course, in C I use the idiomatic #if 0
(if the code is littered with #endif's, a unique comment used in both
directives helps matching them).
And just for the record, from the mouth of 'perlsyn' itself:
"One may also use pod directives to quickly comment out a section of
code."

That's the biggest problem with Perl: its documentation and tutorials
abound in bad advice. I started liking Perl only after realising that
I don't have to use the horrible style of the examples in the "camel
book" in my own code.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <nc********************************@4ax.com> Irrwahn Grausewitz <ir*******@freenet.de> writes:

>>> [Leor: using POD to "comment out" Perl code]
>> [Dan: don't do that]
> [Leor: then what?]
[Dan: use goto]
[Arthur: that's even worse]

Da*****@cern.ch (Dan Pop) wrote:

[...]

I prefer the goto method because it works in all the languages I'm
currently using. Well chosen label names make its usage for this
particular purpose obvious.

[...]

I'm not a perl expert, but I just have to ask: how do you deal with
the other side effects Arthur mentioned:

AJO> Secondly, 'goto' does NOT remove the offending code from the
AJO> program! It will still be not only parsed, but actually run:
AJO> any 'my' variables in the "commented-out" section will get
AJO> declared, for example. So you'll end up with errors at best,
AJO> and silent bugs at worst.

Show me a concrete example and I'll address it.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Irrwahn Grausewitz]

Da*****@cern.ch (Dan Pop) wrote:

In <nc********************************@4ax.com> Irrwahn Grausewitz <ir*******@freenet.de> writes:

> >>> [Leor: using POD to "comment out" Perl code]
> >> [Dan: don't do that]
> > [Leor: then what?]
> [Dan: use goto]
[Arthur: that's even worse]
[Dan: I prefer the goto]
I'm not a perl expert, but I just have to ask: how do you deal with
the other side effects Arthur mentioned:

<snip>Show me a concrete example and I'll address it.

Got me. Guess I'm not ready to expose my, *cough*, "skills"
in writing well-formed line noi^W^W perl code, not even in an
OT thread in c.l.c, sorry. :-/

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

[Thomas Stegen]

Alan Balmer wrote:

My father used to tell me sometimes "You'll be a man before your
mother is." It will be a very long time before C# is any kind of
member of the "C family", in spite of the bookstores which seem to
think it is. C# is much closer to Java than C. Yes, I'm aware that
some people consider Java a "better C", but that gets harder to
maintain with each new Java release.

But I saw a book once which covered C/C++/C# so obviously they must
be more or less the same language!

--
Thomas.

[Dan Pop]

In <kf********************************@4ax.com> Irrwahn Grausewitz <ir*******@freenet.de> writes:

Got me. Guess I'm not ready to expose my, *cough*, "skills"
in writing well-formed line noi^W^W perl code, not even in an
OT thread in c.l.c, sorry. :-/

For some strange reason, my Perl code is ressembling to my C code.

The best way for a C programmer to learn Perl is to get only the most
basic features (data types, operators, file I/O) and start writing code
using the C syntax. If the interpreter complains about syntax errors,
figure out the *minimal* changes required to make it happy.

Taking the K&R2 newbie program already discussed in another thread as an
example:

#!/usr/local/bin/perl -w

my ($fahr, $celsius);
my ($lower, $upper, $step);

$lower = 0;
$upper = 300;
$step = 20;

$fahr = $lower;
while ($fahr <= $upper) {
$celsius = 5 * ($fahr - 32) / 9;
printf("%d\t%d\n", $fahr, $celsius);
$fahr = $fahr + $step;
}

The only change I had to do in the "meat" of the program was adding the
dollar signs in front of each variable.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Richard Harnden]

"Irrwahn Grausewitz" <ir*******@freenet.de> wrote in message
news:nc********************************@4ax.com...

>>> [Leor: using POD to "comment out" Perl code]
>> [Dan: don't do that]
> [Leor: then what?]
[Dan: use goto]
[Arthur: that's even worse]

Da*****@cern.ch (Dan Pop) wrote:

[...]

I prefer the goto method because it works in all the languages I'm
currently using. Well chosen label names make its usage for this
particular purpose obvious.

[...]

I'm not a perl expert, but I just have to ask: how do you deal with
the other side effects Arthur mentioned:

AJO> Secondly, 'goto' does NOT remove the offending code from the
AJO> program! It will still be not only parsed, but actually run:
AJO> any 'my' variables in the "commented-out" section will get
AJO> declared, for example. So you'll end up with errors at best,
AJO> and silent bugs at worst.

So ... if you use goto to skip over code that introduces new variables, and
then you later try to use them and your program crashes because either they
aren't there or they contain junk, then surely you didn't comment out
*enough* code.

Or am I missing something ?

--
rh

[Leor Zolman]

On 16 Apr 2004 15:13:38 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <kf********************************@4ax.com> Irrwahn Grausewitz <ir*******@freenet.de> writes:

Got me. Guess I'm not ready to expose my, *cough*, "skills"
in writing well-formed line noi^W^W perl code, not even in an
OT thread in c.l.c, sorry. :-/

For some strange reason, my Perl code is ressembling to my C code.

The best way for a C programmer to learn Perl is to get only the most
basic features (data types, operators, file I/O) and start writing code
using the C syntax. If the interpreter complains about syntax errors,
figure out the *minimal* changes required to make it happy.

Well, that's /one/ way, but not necessarily the best way. Just as there are
at least two ways for a C programmer to learn C++, the "old-fashioned" way
(start by writing Yet Another String Class, etc.) and the modern way (a la
Accelerated C++), the same sort of thing applies to learning Perl. In the
case of Perl, though, I think it could be even more damaging to do what you
suggested up there than it is in the parallel case of learning C++ that
way.

Perl, being highly idiomatic, provides many succinct native
(non-function/operator, at least in part) constructs for doing things that
require lots of function calls in C. For example, there are some really
nice Perl features (involving $`, $& and $') that I didn't know about
until I'd already written a lot of code that did things the "C" way, using
functions such as index and substr. To this day, I haven't gone back and
changed any of it, adhering to the "If it aint broke, don't fix it" rule
(which I finally learned quite well by working for Robert Ward at CUJ).
Nevertheless, I have no doubt that I could improve both the performance and
the clarity of my Perl code by going back and re-working those sections to
take advantage of the features I didn't know about.

So I'd have to say that the "best" way for a C programmer to learn Perl is
to try to forget everything he/she knows about C, and read a good Perl book
/before/ trying to write code to emulate the behavior of a C program (or
even to just do things the "C way").
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html

[Michael Wojcik]

In article <lc********************************@4ax.com>, Alan Balmer <al******@att.net> writes:

On 15 Apr 2004 17:34:49 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote:

I suspect my component atoms will be scattered o'er the globe before
C# becomes the dominant member of the C family.

My father used to tell me sometimes "You'll be a man before your
mother is." It will be a very long time before C# is any kind of
member of the "C family", in spite of the bookstores which seem to
think it is. C# is much closer to Java than C. Yes, I'm aware that
some people consider Java a "better C", but that gets harder to
maintain with each new Java release.

It depends on what you consider a language "family", of course.
I think of Java and C# as, oh, cousins (perhaps not first cousins)
of C, since they adopt significant chunks of C (and C++) syntax and
semantics.

But it's also certainly true that there are huge differences between
Java and C# on the one hand, and C++ on the other, and of course C
is even further. So if you prefer, read my statement as "before C#
becomes more prevalent than C (or C++ or Java)". (I suppose it
might have an outside, long-term chance against Java.)

--
Michael Wojcik mi************@microfocus.com

We are subdued to what we work in. (E M Forster)

[Irrwahn Grausewitz]

>> >>> >>> [Leor: using POD to "comment out" Perl code]

>>> >> [Dan: don't do that]
>>> > [Leor: then what?]
>>> [Dan: use goto]
>> [Arthur: that's even worse]
> [Dan: I prefer the goto method] [Irrwahn: what about Arthur's objection:]

AJO> Secondly, 'goto' does NOT remove the offending code from the
AJO> program! It will still be not only parsed, but actually run:
AJO> any 'my' variables in the "commented-out" section will get
AJO> declared, for example. So you'll end up with errors at best,
AJO> and silent bugs at worst.

"Richard Harnden" <ri*************@lineone.net> wrote:
So ... if you use goto to skip over code that introduces new variables, and
then you later try to use them and your program crashes because either they
aren't there or they contain junk, then surely you didn't comment out
*enough* code.
Right, but you're not _guaranteed_ to notice that something went
terribly wrong, until Friday afternoon. Cf. undefined behaviour
caused by use of uninitialized variables in C.
Or am I missing something ?

The main objection? 'goto' is just not an appropriate construct to
hide code from the translator, in any language I can think of right
now. If I were seriously suggesting a similar approach in C, Dan
would certainly call me a patent idiot, and rightfully so.

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

[Keith Thompson]

Da*****@cern.ch (Dan Pop) writes:

In <kf********************************@4ax.com> Irrwahn Grausewitz
<ir*******@freenet.de> writes:

Got me. Guess I'm not ready to expose my, *cough*, "skills"
in writing well-formed line noi^W^W perl code, not even in an
OT thread in c.l.c, sorry. :-/

For some strange reason, my Perl code is ressembling to my C code.

The best way for a C programmer to learn Perl is to get only the most
basic features (data types, operators, file I/O) and start writing code
using the C syntax. If the interpreter complains about syntax errors,
figure out the *minimal* changes required to make it happy.

Taking the K&R2 newbie program already discussed in another thread as an
example:

#!/usr/local/bin/perl -w

my ($fahr, $celsius);
my ($lower, $upper, $step);

$lower = 0;
$upper = 300;
$step = 20;

$fahr = $lower;
while ($fahr <= $upper) {
$celsius = 5 * ($fahr - 32) / 9;
printf("%d\t%d\n", $fahr, $celsius);
$fahr = $fahr + $step;
}

The only change I had to do in the "meat" of the program was adding the
dollar signs in front of each variable.

I'd add "use strict;" at the top to enable stronger error checking.
(I use both "-w" and "use strict;" in all my Perl programs.)

This program actually does something quite different from the C
version. The calculation of $celsius is done in floating-point, not
in integer arithmetic. The results are displayed as integers because
of the "%d" specifiers in the printf. Perl's printf, unlike C's,
knows the actual types of its arguments, and converts them as
necessary. You can see the real values by changing the printf to:

print "$fahr\t$celsuis\n";

or, if you prefer to be more C-like:

printf("%g\t%g\n", $fahr, $celsius);

Anyway, the thread is actually about commenting out blocks of code.
It would never occur to me to use goto for this in any language;
any time this would work:

goto END_OF_SKIPPED_SECTION;
... lots of code here
END_OF_SKIPPED_SECTION:

this would work better:

if (0) {
... lots of code here
}

In Perl, it's also not very helpful if I want to comment out a
subroutine definition.

But in Perl, if I want to comment out a block of code, I just comment
it out, inserting a '#' at the beginning of each line. Most text
editors should let you do this in a few keystrokes, and the result is
a block of code that's unmistakably commented out.

This is, of course, a matter of style; YMMV.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Arthur J. O'Dwyer]

On Fri, 16 Apr 2004, Richard Harnden wrote:

"Irrwahn Grausewitz" <ir*******@freenet.de> wrote...

>> >>> [Leor: using POD to "comment out" Perl code]
>> >> [Dan: don't do that]

Da*****@cern.ch (Dan Pop) wrote:

I prefer the goto method because it works in all the languages I'm
currently using. Well chosen label names make its usage for this
particular purpose obvious.

AJO> Secondly, 'goto' does NOT remove the offending code from the
AJO> program! It will still be not only parsed, but actually run:
AJO> any 'my' variables in the "commented-out" section will get
AJO> declared, for example. So you'll end up with errors at best,
AJO> and silent bugs at worst.

So ... if you use goto to skip over code that introduces new variables,
and then you later try to use them and your program crashes because
either they aren't there or they contain junk, then surely you didn't
comment out *enough* code.

Or am I missing something ?

I don't know enough Perl to give you a concrete example, but I'd
look for situations like this:

goto new_version; # OLD VERSION -- SKIP IT
my @bigtable;
new_version: # NEW VERSION
my %bigtable; # much better!

# do something accessing a member of 'bigtable'

Perl *will* do weird things if you use $ or # on a hash as if it were
an array, or vice versa. And then of course there's always the
pathological cases... ;-)

goto new_version; # OLD VERSION -- SKIP IT
while ($foo) {
if (bar()) goto done;
}
done:
new_version: # NEW VERSION
while ($foo) {
if (new_improved_bar()) goto done;
}
done:

But if you want real answers, I still encourage you to talk to a
Perl hacker, in a Perl newsgroup. My work here is done.

-Arthur,
over and out

[Keith Thompson]

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> writes:
[...]

I don't know enough Perl to give you a concrete example, but I'd
look for situations like this:

goto new_version; # OLD VERSION -- SKIP IT
my @bigtable;
new_version: # NEW VERSION
my %bigtable; # much better!

# do something accessing a member of 'bigtable'

Perl *will* do weird things if you use $ or # on a hash as if it were
an array, or vice versa. And then of course there's always the
pathological cases... ;-)

See, this is why we usually don't discuss Perl in comp.lang.c.
@bigtable (an array) and %bigtable (a hash) are two different
variables; the syntax is such that references to them are unambiguous.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Dan Pop]

In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

Da*****@cern.ch (Dan Pop) writes:

Taking the K&R2 newbie program already discussed in another thread as an
example:

#!/usr/local/bin/perl -w

my ($fahr, $celsius);
my ($lower, $upper, $step);

$lower = 0;
$upper = 300;
$step = 20;

$fahr = $lower;
while ($fahr <= $upper) {
$celsius = 5 * ($fahr - 32) / 9;
printf("%d\t%d\n", $fahr, $celsius);
$fahr = $fahr + $step;
}

The only change I had to do in the "meat" of the program was adding the
dollar signs in front of each variable.

This program actually does something quite different from the C
version.

The two programs have the same specification and generate identical
output. The rest is irrelevant...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de