[TUHS] // comment in C++

[TUHS] // comment in C++

[Paul McJones]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

> I'm fairly certain it was originally in BCPL.
> 
> You could just drop a note to Bjarne Stroustrup and ask. :-)

On page 44 of _The Design and Evolution of C++_ (Addison-Wesley, 1994), Stroustrup says:

“However, only C, Simula, Algol68, an in one case BCPL left noticeable traces in C++ as released in 1985. Simula gave classes, Algol68 operating overloading, references, and the ability to declare variables anywhere in a block, and BCPL gave // comments.”

He says a bit more about // comments on page 93, including an example of how they introduced an incompatibility with C.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/7c07a996/attachment.html>

[TUHS] // comment in C++

[Marc Rochkind]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

Those were JCL COMMANDS??? Damn! I thought they were comments. No wonder
nothing ever worked.

--Marc

On Wed, Feb 8, 2017 at 5:03 PM, Paul McJones <paul at mcjones.org> wrote:

> I'm fairly certain it was originally in BCPL.
>
> You could just drop a note to Bjarne Stroustrup and ask. :-)
>
>
> On page 44 of _The Design and Evolution of C++_ (Addison-Wesley, 1994),
> Stroustrup says:
>
> “However, only C, Simula, Algol68, an in one case BCPL left noticeable
> traces in C++ as released in 1985. Simula gave classes, Algol68 operating
> overloading, references, and the ability to declare variables anywhere in a
> block, and BCPL gave // comments.”
>
> He says a bit more about // comments on page 93, including an example of
> how they introduced an incompatibility with C.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/9a9f3b72/attachment.html>

[TUHS] // comment in C++

[Tony Finch]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]

Paul McJones <paul at mcjones.org> wrote:

> > I'm fairly certain it was originally in BCPL.
> >
> > You could just drop a note to Bjarne Stroustrup and ask. :-)
>
> On page 44 of _The Design and Evolution of C++_ (Addison-Wesley, 1994),
> Stroustrup says:
>
> “However, only C, Simula, Algol68, an in one case BCPL left noticeable
> traces in C++ as released in 1985. Simula gave classes, Algol68
> operating overloading, references, and the ability to declare variables
> anywhere in a block, and BCPL gave // comments.”
>
> He says a bit more about // comments on page 93, including an example of
> how they introduced an incompatibility with C.

There's more in Stroustrup's paper for the second History of Programming
Languages conference, http://www.stroustrup.com/hopl2.pdf

See especially the prehistory section 2.1 on page 3 where he talks about
the painful tooling he was faced with in Cambridge, where Simula was nice
for program design but had a woefully slow implementation, whereas BCPL
was fast but grievously unsafe.

The quote above is repeated in the HOPL2 paper on page 12 in section 2.4.4
on "Why C?" and there's a bit more about comment syntax in section 3.3.1
on page 21.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Wight, Portland: East or northeast 4 or 5, increasing 6 at times. Slight or
moderate, occasionally rough in Portland. Showers. Moderate or good.

[TUHS] // comment in C++

[Steffen Nurpmeso]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7503 bytes --]

That is an honour to me, Mr. Doug McIlroy.

Doug McIlroy <doug at cs.dartmouth.edu> wrote:
 |With no offense intended, I can't help noting the irony of the
 |following paragraph appearing in a message in the company of
 |others that address Unix "bloat".

To me writing documentation is an enormous pain.  I find it
extraordinary hard to find the words to describe some technical
aspect to an imaginery broad audience of human beings.
It requires many iterations until i am somewhat satisfied, and, as
something like an excuse, this specific part is very fresh.

 |Except for the ISO citations, this paragraph says the same
 |thing more succinctly.
 |
 |'\cX'    represents a nonprintable character Y in terms of the
 |          printable character X whose binary code is obtained
 |          by adding 0x40 (decimal 64) to that for Y. (In some
 |          historical contexts, '^' plays the role of '\c'.)
 |          Alternative standard representations for certain
 |          nonprinting characters, e.g. '\a', '\n', '\t' above,
 |          are preferred by S-nail. '\c@' (NUL) serves as a
 |          string terminator regardless of following characters.
 |
 |And this version, 1/3 the length of the original, tells all
 |one really needs to know.
 |
 |'\cX'    represents a nonprintable character Y in terms of the
 |          printable character X whose binary code is obtained
 |          by adding 0x40 (decimal 64) to that for Y. '\c@'
 |          (NUL) serves as a string terminator regardless of
 |          following characters.

This is brief and concise.  The last sentence could not be used
like that, because the \c@ is an extension that, different to \0*,
\x0*, \[uU]0*, really terminates the entire argument list, not
"further output for the quoted argument".  I have to mark it as
a non-standard extension.  Thanks for pointing this out.

I am wondering.  Chekhov said:

  Ich glaube nicht an unsere Intelligenz, die heuchlerisch,
  falsch, hysterisch, ungebildet und faul ist, ich glaube ihr
  sogar dann nicht, wenn sie leidet und klagt, denn ihre
  Unterdrücker kommen doch aus ihrem eigenen Schoß. Ich glaube an
  den einzelnen Menschen, ich sehe die Rettung in den
  Einzelpersönlichkeiten[.]

  I don't believe in our Intelligence, that is insincere, false,
  hysterical, illiterate and lazy, i don't believe in it even when
  she [it] suffers and laments, because her [its] suppressors
  still come from her [its] own womb.  I believe in the individual
  Human, i see the Salvage in the Individual.

I know for sure that this last example of yours is too concise for
a broad audience, a "nonprintable character" without a describing
context is an anachronism.  To me the question is, in a world of
increasingly omnipresent trivialism, where the human being remains
just as hormone driven, and not in only a small propertion
somewhat unreflected, as it always has been, but becomes more and
more de-facto controllable, far, far beyond the purging sunday
morning thunderstorm from the pulpit (and here being optimistic,
and wearing western world glasses), faster, much faster than most
souls, and here the story of the African Expedition which was
beaten along by the white master, until after some days the
bearers refused to march on at any cost, to "wait for their souls
to catch up", are, so how to strengthen the individual with its,
that is my believe, as a Buddhist, sole obligation of doing that
step towards reflection, of self-awareness in a holistic whole.

I know the software i maintain is by far not where i want to see
it, also regarding the documentation.  For one we are by far not
powerful enough, other aspects are much too bloated.  We do not
yet fully comply to the POSIX standard.  But we slowly become more
reliable, also for non-interactive use cases.  And correct.  And
i refer to the not yet released version, which will be a step
forward, after one year and a half of what i call full-time
development.

I want us to move to a place where even an inexperienced user can
teach her- or himself, and gain -- hopefully -- satisfying results
simply by reading the manual.  To get a notion of what actually
happens, or at least a notion of the problems that are involved.
Or, at the very least, to get some hints to keep in mind for the
next time Internet is accessible or an experienced user can be
talked to etc.  I think that, and i want to see and have a lower
hurdle on the documentation side.  I get frustrated when i really
have to go Google, and cannot get any help, but see a nice and
stylish link asking whether "this page was helpful".  Or HTMLized
GNU info pages, with a paragraph per HTML page.  I think that such
behaviour increases aggression, increases the feeling of
inferiority, and if its under the surface.  It will at least try
to rise to the surface, one way or the other, that is programmed
in the afterbrain, or at a not too much higher level.  Some
intellegent millionairs and other alpha leaders may even think it
is funny to play with that, but i, for myself, reject that
direction.

It is a little bit ridiculous.
For now i end up with

  ‘\cX’    Emits the non-printable (ASCII and compatible) C0 con‐
           trol codes 0 (NUL) to 31 (US), and 127 (DEL).  Print‐
           able representations of ASCII control codes can be
           created by mapping them to a different part of the
           ASCII character set, which is possible by adding the
           number 64 for the codes 0 to 31, e.g., 7 (BEL) is ‘7 +
           64 = 71 = G’.  The real operation is a bitwise logical
           XOR with 64 (bit 7 set, see vexpr[253]), thus also
           covering code 127 (DEL), which is mapped to 63 (ques-
           tion mark): ‘vexpr ^ 127 64’.

           Whereas historically circumflex notation has often
           been used for visualization purposes of control codes,
           e.g., ‘^G’, the reverse solidus notation has been
           standardized: ‘\cG’.  Some control codes also have
           standardized (ISO 10646, ISO C) aliases, as shown
           above (e.g., ‘\a’, ‘\n’, ‘\t’): whenever such an alias
           exists it will be used for display purposes.  The con‐
           trol code NUL (‘\c@’, a non-standard extension) ends
           argument processing without producing further output.

The vexpr[253] is an active link.  (In a capable less(1).  And to
yet another new builtin command which performs arithmetic and
string operations, but we now have macros with arguments, and even
though we do not yet have loop control statements, managing
counters etc. may already be useful.  As an overall question, if
we would have a multi-process approach, like sam has, maybe we
could simply use a communication channel to some arbitrary shell
or awk script to perform such things.  But this software will see
its 39th birthday in six weeks and one day from now on, and it was
not designed that way.  So it is easier to have a 483 line `vexpr'
implementation.  It also does have saturated signed 64-bit
arithmetic.  And it provides the right error messages.  I do hope
the future will bring some size reduction again nonetheless, while
also providing better message access.  Or any access at all.  In
the end, it does not make sense to provide a clean program if it
is of no use at all, nor can be plugged together with other
programs to form a Unix pipe that provides something useful.
I hope for both, and that increasingly reliable.)

--steffen

[TUHS] // comment in C++

[arnold]

Dave Horsfall <dave at horsfall.org> wrote:

> On Thu, 9 Feb 2017, Dan Cross wrote:
>
> > Well, it wasn't in c89, but it's been part of ANSI C since 1999: almost 20
> > years!
>
> Not in my C book 2nd ed. (ANSI), it isn't...
>
>     A2.2 Comments
>
>     The characters /* introduce a comment, which terminates with the 
>     characters */.  Comments do not not nest, and they do not occur within 
>     string or character literals.
>
> There is no mention of "//"; I have the 51st printing, August 2013.

Sadly, although it's a recent printing, the contents date from 1989,
only covering the first standard for C. C99 is the second, and C11 is
the third.

(My first printing of the 2nd edition from 1989 has "draft ANSI" or some
such on the cover. :-)

Arnold

[TUHS] // comment in C++

[arnold]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

> On Thu, 9 Feb 2017, Michael Kjörling wrote:
>
> > I didn't know that // was now accepted to begin a comment in C, but I 
> > strongly suspect that any compiler modern enough to know about that will 
> > know just as well about #if 0.

Dave Horsfall <dave at horsfall.org> wrote:
> // isn't in ANSI C, but I've been using it for years on quite a few 
> platforms (I see that even M$ supports it); I don't know where I first saw 
> it.

It was added in C99.

Arnold

[TUHS] // comment in C++

[Dave Horsfall]

On Thu, 9 Feb 2017, Nemo wrote:

> Hhmmm... I do not have ANSI C99 (or C11) but ISO/IEC 9899:TC3 states
> (in Para. 6.4.9):

[...]

Yeah; someone told me in private.  My mistake...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] // comment in C++

[Nemo]

On 9 February 2017 at 20:58, Dave Horsfall <dave at horsfall.org> wrote:
> On Thu, 9 Feb 2017, Dan Cross wrote:
>
>> Well, it wasn't in c89, but it's been part of ANSI C since 1999: almost 20
>> years!
>
> Not in my C book 2nd ed. (ANSI), it isn't...
>
>     A2.2 Comments
>
>     The characters /* introduce a comment, which terminates with the
>     characters */.  Comments do not not nest, and they do not occur within
>     string or character literals.
>
> There is no mention of "//"; I have the 51st printing, August 2013.

Hhmmm... I do not have ANSI C99 (or C11) but ISO/IEC 9899:TC3 states
(in Para. 6.4.9):

Except within a character constant, a string literal, or a comment,
the characters //
introduce a comment that includes all multibyte characters up to, but
not including, the
next new-line character.

N.


>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] // comment in C++

[Dave Horsfall]

On Thu, 9 Feb 2017, Dan Cross wrote:

> Well, it wasn't in c89, but it's been part of ANSI C since 1999: almost 20
> years!

Not in my C book 2nd ed. (ANSI), it isn't...

    A2.2 Comments

    The characters /* introduce a comment, which terminates with the 
    characters */.  Comments do not not nest, and they do not occur within 
    string or character literals.

There is no mention of "//"; I have the 51st printing, August 2013.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] // comment in C++

[Dan Cross]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

On Thu, Feb 9, 2017 at 4:56 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Thu, 9 Feb 2017, Michael Kjörling wrote:
> > I didn't know that // was now accepted to begin a comment in C, but I
> > strongly suspect that any compiler modern enough to know about that will
> > know just as well about #if 0.
>
> // isn't in ANSI C, but I've been using it for years on quite a few
> platforms (I see that even M$ supports it); I don't know where I first saw
> it.


Well, it wasn't in c89, but it's been part of ANSI C since 1999: almost 20
years!

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/f341dc71/attachment-0001.html>

[TUHS] // comment in C++

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

On Thu, 9 Feb 2017, Michael Kjörling wrote:

> I didn't know that // was now accepted to begin a comment in C, but I 
> strongly suspect that any compiler modern enough to know about that will 
> know just as well about #if 0.

// isn't in ANSI C, but I've been using it for years on quite a few 
platforms (I see that even M$ supports it); I don't know where I first saw 
it.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] // comment in C++

[Doug McIlroy]

With no offense intended, I can't help noting the irony of the
following paragraph appearing in a message in the company of
others that address Unix "bloat".

>'\cX'    A mechanism that allows usage of the non-printable
>          (ASCII and compatible) control codes 0 to 31: to cre-
>          ate the printable representation of a control code the
>          numeric value 64 is added, and the resulting ASCII
>          character set code point is then printed, e.g., BEL is
>          '7 + 64 = 71 = G'.  Whereas historically circumflex
>          notation has often been used for visualization pur-
>          poses of control codes, e.g., '^G', the reverse
>          solidus notation has been standardized: '\cG'.  Some
>          control codes also have standardized (ISO 10646, ISO
>          C) alias representations, as shown above (e.g., '\a',
>          '\n', '\t'): whenever such an alias exists S-nail will
>          use it for display purposes.  The control code NUL
>          ('\c@') ends argument processing without producing
>          further output.

Except for the ISO citations, this paragraph says the same
thing more succinctly.

'\cX'    represents a nonprintable character Y in terms of the
          printable character X whose binary code is obtained
          by adding 0x40 (decimal 64) to that for Y. (In some
          historical contexts, '^' plays the role of '\c'.)
          Alternative standard representations for certain
          nonprinting characters, e.g. '\a', '\n', '\t' above,
          are preferred by S-nail. '\c@' (NUL) serves as a
          string terminator regardless of following characters.

And this version, 1/3 the length of the original, tells all
one really needs to know.

'\cX'    represents a nonprintable character Y in terms of the
          printable character X whose binary code is obtained
          by adding 0x40 (decimal 64) to that for Y. '\c@'
          (NUL) serves as a string terminator regardless of
          following characters.

Doug]

[TUHS] // comment in C++

[Steffen Nurpmeso]

Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

 |jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:
 ||> From: Michael Kjorling
 ...
 |You xor it via toupper(X)^0x40, yes of course.  My code is right,

To be exact, it is

  c = upperconv(c2) ^ 0x40;
  if((ui8_t)c > 0x1F && c != 0x7F){ /* ASCII C0: 0..1F, 7F */

and converts from \cX notation to the actual control character.
That is, we do test the result in advance, which i wanted to add.
Ciao.

--steffen

[TUHS] // comment in C++

[Steffen Nurpmeso]

jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:
 |> From: Michael Kjorling
 |> That wouldn't have anything to do with how ^@ is a somewhat common
 |> representation of 000, would it? .. I've always kind of wondered where
 |> that notation came from.
 |
 |Well, CTRL-<*> is usually just the <*> character with the high bits \
 |cleared.
 |So, to have a printing representation of NULL, you have two character \
 |choices
 |- SPACE, and '@'. Printing "^ " is not so hot, so "^@" is better.
 |
 |Also, if you look at an ASCII table, usually people just take the @-_ \
 |column,
 |and use that, since every character in that column has a printing
 |representation. The ' '-? column is missing the ' ', and `-<DEL> is missing
 |the DEL. So if you just take a CTRL character and set the 0100 bit, \
 |and print
 |it as "^<char>", you get something readable.

You xor it via toupper(X)^0x40, yes of course.  My code is right,
it is just the manual that is incomplete or even false: i will
clarify it.  It is just that i know that many people which use
free software don't know what a xor operation is, at least without
looking into Wikipedia.  (And even though i use it frequently
myself, that is often contaminated by politics, just yesterday
i had a hard time with some paragraphs on the German Wikipedia
page on intellectual properties.)

 |(Note that CTRL-' ' _is_ usually used when one needs to _input_ a NUL
 |character.)
 |
 | Noel

--steffen

[TUHS] // comment in C++

[Random832]

On Thu, Feb 9, 2017, at 09:37, Random832 wrote:
> And for where ^? for DEL comes from,

> In fact, this is exactly how the control key worked on early terminals

I should clarify, these are two separate comments. Ctrl-? did *not*
generate DEL on physical terminals (which typically had a dedicated key
for it), from the documentation that I've read it seems those that
allowed the combination at all tended to generate ^_. Which is something
that persists in modern terminal emulators for Ctrl-/, though I think
some do support Ctrl-? as DEL.

[TUHS] // comment in C++

[Noel Chiappa]

    > From: Michael Kjorling

    > That wouldn't have anything to do with how ^@ is a somewhat common
    > representation of 000, would it? .. I've always kind of wondered where
    > that notation came from.

Well, CTRL-<*> is usually just the <*> character with the high bits cleared.
So, to have a printing representation of NULL, you have two character choices
- SPACE, and '@'. Printing "^ " is not so hot, so "^@" is better.

Also, if you look at an ASCII table, usually people just take the @-_ column,
and use that, since every character in that column has a printing
representation. The ' '-? column is missing the ' ', and `-<DEL> is missing
the DEL. So if you just take a CTRL character and set the 0100 bit, and print
it as "^<char>", you get something readable.

(Note that CTRL-' ' _is_ usually used when one needs to _input_ a NUL
character.)

	Noel

[TUHS] // comment in C++

[Random832]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1349 bytes --]

On Thu, Feb 9, 2017, at 07:26, Lars Brinkhoff wrote:
> Michael Kjörling <michael at kjorling.se> writes:
> > That wouldn't have anything to do with how ^@ is a somewhat common
> > representation of 000, would it? (Yes, using octal on purpose.) I've
> > always kind of wondered where that notation came from.  That ^A
> > through ^Z were representations of 001 through 032 makes more sense.
> 
> Look at two slices of the ASCII table:

And for where ^? for DEL comes from, (0377 + 0100) & 0377 == 0077 [where
the first 0377 is the control character of interest.] I am sure I've
seen code that calculates the character to be displayed in precisely
this way, but I can't remember where.

In fact, this is exactly how the control key worked on early terminals
(I recently had reason to look up an ASR-33 manual). The Shift key
toggled the 0020 bit (so shift-2 is " - if you look at the relevant
slice of an ASCII table), resulting in shift-K is [ (which did not have
a dedicated key) and shift-ctrl-K is ESC (which did have a dedicated key
as well, but the other non-letter control characters did not, and were
on shift-ctrl-LMNOP).

There was a mechanical lockout for keys that shift didn't make sense
with - all other letters and zero (which would otherwise have produced a
space), and one for ctrl (which locked out all the number and symbol
keys)

[TUHS] // comment in C++

[Nick Downing]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3527 bytes --]

Haha well I never liked that idiom but I recently found out that
#ifdef was present in the first CPPs whereas #if was much later. So
that's why #ifdef notdef is seen a lot in old code. Anyway, personally
I use #if 0 and #if 1 quite a lot for debugging or questionable stuff.
For a while, I was quite into the idea of doing compile time options
like #define SOME_OPTION 1 and then using #if SOME_OPTION, as I felt
it was nicer than #ifdef SOME_OPTION. But I've changed my mind, as
this is pretty nonstandard usage and can be misleading. It's also not
really safer than #ifdef, since for some reason CPP accepts undefined
symbols and treats them as 0 in a #if statement. Go figure.
cheers, Nick

On Thu, Feb 9, 2017 at 11:18 PM, Brantley Coile <brantleycoile at me.com> wrote:
> That’s a good convention. I use the convention that the permanent comments use the slash-splat form and the slash-slash from is used for temporary comment that will need attention later. They are TODO comments.
>
> I also use empty comments in the first column to note debugging stuff to remove laters. For example:
>
> void
> main(int argc, char **argv)
> {
>         ARGBEGIN {
>         default:
>                 usage();
>         } ARGEND
> /**/    print(“argc=%d argv=%p\n”, argc, argv);
> /**/    if (argc == 3)
> /**/            print(“that funny number again\n”);
>         if (argc == 0) {
>                 usestdin();
>         …
> }
>
> This lets the flow of the test logic clear yet is easy to find and remove the code later.
>
> I also use “#ifdef notdef” to comment out blocks of code. Have done since v7 days. Once I worked with a guy who saw the ifdefs and wondered what the function was that was def’ed out. He added -Dnotdef and all hell broke out!
>
>   Brantley
>
>> On Feb 8, 2017, at 11:55 PM, Steve Johnson <scj at yaccman.com> wrote:
>>
>> Well, personally I use // for almost all comments in C/C++.  I reserve /* */ for commenting out blocks of code.   Since, for some reason, /* */ doesn't nest, if I stick to this style life is good.
>>
>> Steve
>>
>>
>>
>> ----- Original Message -----
>> From:
>> "Steve Nickolas" <usotsuki at buric.co>
>>
>> To:
>> "The Eunuchs Hysterical Society" <tuhs at tuhs.org>
>> Cc:
>>
>> Sent:
>> Wed, 8 Feb 2017 21:47:49 -0500 (EST)
>> Subject:
>> Re: [TUHS] // comment in C++
>>
>>
>> On Thu, 9 Feb 2017, Dave Horsfall wrote:
>>
>> > On Wed, 8 Feb 2017, Steve Johnson wrote:
>> >
>> >> I remember some discussion about this.  In reality, a C comment really
>> >> requires you to type 8 characters, because putting anything adjacent to
>> >> the /* or */ looks terrible.  Many languages used single characters
>> >> (e.g., # for make).  The argument was "if you make comments easier to
>> >> type, you'll get more of them in the code"  (viz. the Unix kernel).  I'm
>> >> guessing Bjarne was aware of these discussions, although I don't
>> >> remember specifically that he was...
>> >
>> > My favourite C /* */ style is this:
>> >
>> > /*
>> > * foo
>> > * bar
>> > */
>>
>> This is the way I usually write my comments, too.
>>
>> > Is that what you meant? And recent C also accepts // as a comment, which
>> > I use like this:
>> >
>> > /*
>> > * This is where we do some neat stuff.
>> > */
>> > foo();
>> > weird_function();   // Yes, we need to call this here...
>> > bar();
>> >
>> > I'm quite taken by BIND, though, which accepts
>> >
>> > /* this */
>> > // this
>> > # and this.
>>
>> Unrealircd likewise accepts those 3 different types of comments.
>>
>> -uso.
>

[TUHS] // comment in C++

[Steffen Nurpmeso]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1890 bytes --]

Paul Ruizendaal <pnr at planet.nl> wrote:
 |> On 9 Feb 2017, at 13:12, Michael Kjörling <michael at kjorling.se> wrote:
 |> On 8 Feb 2017 17:50 -0500, from ron at ronnatalie.com (Ron Natalie):
 |>> Amusingly in the UNIVAC FIELDDATA character set.   The @ had the \
 |>> value zero
 |>> (and was called the master space).
 |> 
 |> That wouldn't have anything to do with how ^@ is a somewhat common
 |> representation of 000, would it? (Yes, using octal on purpose.) I've
 |> always kind of wondered where that notation came from.
 |> 
 |> That ^A through ^Z were representations of 001 through 032 makes more
 |> sense.
 |
 |Isn’t it because it is simply the control code + 0100 to arrive at the
 |capitals column of the ascii table? (http://www.asciitable.com)
 |
 |Hence ^@ for NULL and ^[ for ESC.

That is also what i thought and think.  The MUA i maintain now
documents (in the next release):

  ‘\cX’    A mechanism that allows usage of the non-printable
           (ASCII and compatible) control codes 0 to 31: to cre‐
           ate the printable representation of a control code the
           numeric value 64 is added, and the resulting ASCII
           character set code point is then printed, e.g., BEL is
           ‘7 + 64 = 71 = G’.  Whereas historically circumflex
           notation has often been used for visualization pur‐
           poses of control codes, e.g., ‘^G’, the reverse
           solidus notation has been standardized: ‘\cG’.  Some
           control codes also have standardized (ISO 10646, ISO
           C) alias representations, as shown above (e.g., ‘\a’,
           ‘\n’, ‘\t’): whenever such an alias exists S-nail will
           use it for display purposes.  The control code NUL
           (‘\c@’) ends argument processing without producing
           further output.

I hope this is correct.

--steffen

[TUHS] // comment in C++

[Paul Ruizendaal]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 729 bytes --]


> On 9 Feb 2017, at 13:12, Michael Kjörling <michael at kjorling.se> wrote:
> 
> On 8 Feb 2017 17:50 -0500, from ron at ronnatalie.com (Ron Natalie):
>> Amusingly in the UNIVAC FIELDDATA character set.   The @ had the value zero
>> (and was called the master space).
> 
> That wouldn't have anything to do with how ^@ is a somewhat common
> representation of 000, would it? (Yes, using octal on purpose.) I've
> always kind of wondered where that notation came from.
> 
> That ^A through ^Z were representations of 001 through 032 makes more
> sense.

Isn’t it because it is simply the control code + 0100 to arrive at the
capitals column of the ascii table? (http://www.asciitable.com)

Hence ^@ for NULL and ^[ for ESC.

[TUHS] // comment in C++

[Lars Brinkhoff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

Michael Kjörling <michael at kjorling.se> writes:
> That wouldn't have anything to do with how ^@ is a somewhat common
> representation of 000, would it? (Yes, using octal on purpose.) I've
> always kind of wondered where that notation came from.  That ^A
> through ^Z were representations of 001 through 032 makes more sense.

Look at two slices of the ASCII table:

  0 ^@    64 @
  1 ^A    65 A
  2 ^B    66 B
  3 ^C    67 C
  4 ^D    68 D
  5 ^E    69 E
  6 ^F    70 F
  7 ^G    71 G
  8 ^H    72 H
  9 ^I    73 I
 10 ^J    74 J
 11 ^K    75 K
 12 ^L    76 L
 13 ^M    77 M
 14 ^N    78 N
 15 ^O    79 O
 16 ^P    80 P
 17 ^Q    81 Q
 18 ^R    82 R
 19 ^S    83 S
 20 ^T    84 T
 21 ^U    85 U
 22 ^V    86 V
 23 ^W    87 W
 24 ^X    88 X
 25 ^Y    89 Y
 26 ^Z    90 Z
 27 ^[    91 [
 28 ^\    92 \
 29 ^]    93 ]
 30 ^^    94 ^
 31 ^_    95 _

[TUHS] // comment in C++

[Brantley Coile]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2580 bytes --]

That’s a good convention. I use the convention that the permanent comments use the slash-splat form and the slash-slash from is used for temporary comment that will need attention later. They are TODO comments. 

I also use empty comments in the first column to note debugging stuff to remove laters. For example:

void
main(int argc, char **argv)
{
	ARGBEGIN {
	default:
		usage();
	} ARGEND
/**/	print(“argc=%d argv=%p\n”, argc, argv);
/**/	if (argc == 3)
/**/		print(“that funny number again\n”);
	if (argc == 0) {
		usestdin();
	…
}

This lets the flow of the test logic clear yet is easy to find and remove the code later. 

I also use “#ifdef notdef” to comment out blocks of code. Have done since v7 days. Once I worked with a guy who saw the ifdefs and wondered what the function was that was def’ed out. He added -Dnotdef and all hell broke out!

  Brantley

> On Feb 8, 2017, at 11:55 PM, Steve Johnson <scj at yaccman.com> wrote:
> 
> Well, personally I use // for almost all comments in C/C++.  I reserve /* */ for commenting out blocks of code.   Since, for some reason, /* */ doesn't nest, if I stick to this style life is good.
> 
> Steve
> 
> 
> 
> ----- Original Message -----
> From:
> "Steve Nickolas" <usotsuki at buric.co>
> 
> To:
> "The Eunuchs Hysterical Society" <tuhs at tuhs.org>
> Cc:
> 
> Sent:
> Wed, 8 Feb 2017 21:47:49 -0500 (EST)
> Subject:
> Re: [TUHS] // comment in C++
> 
> 
> On Thu, 9 Feb 2017, Dave Horsfall wrote:
> 
> > On Wed, 8 Feb 2017, Steve Johnson wrote:
> >
> >> I remember some discussion about this.  In reality, a C comment really
> >> requires you to type 8 characters, because putting anything adjacent to
> >> the /* or */ looks terrible.  Many languages used single characters
> >> (e.g., # for make).  The argument was "if you make comments easier to
> >> type, you'll get more of them in the code"  (viz. the Unix kernel).  I'm
> >> guessing Bjarne was aware of these discussions, although I don't
> >> remember specifically that he was...
> >
> > My favourite C /* */ style is this:
> >
> > /*
> > * foo
> > * bar
> > */
> 
> This is the way I usually write my comments, too.
> 
> > Is that what you meant? And recent C also accepts // as a comment, which
> > I use like this:
> >
> > /*
> > * This is where we do some neat stuff.
> > */
> > foo();
> > weird_function();	// Yes, we need to call this here...
> > bar();
> >
> > I'm quite taken by BIND, though, which accepts
> >
> > /* this */
> > // this
> > # and this.
> 
> Unrealircd likewise accepts those 3 different types of comments.
> 
> -uso.

[TUHS] // comment in C++

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

On 8 Feb 2017 17:50 -0500, from ron at ronnatalie.com (Ron Natalie):
> Amusingly in the UNIVAC FIELDDATA character set.   The @ had the value zero
> (and was called the master space).

That wouldn't have anything to do with how ^@ is a somewhat common
representation of 000, would it? (Yes, using octal on purpose.) I've
always kind of wondered where that notation came from.

That ^A through ^Z were representations of 001 through 032 makes more
sense.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] // comment in C++

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

On 8 Feb 2017 20:55 -0800, from scj at yaccman.com (Steve Johnson):
> Well, personally I use // for almost all comments in C/C++.  I
> reserve /* */ for commenting out blocks of code.   Since, for some
> reason, /* */ doesn't nest, if I stick to this style life is good.

#if 0 ... #endif also works, and nests if needed.

I didn't know that // was now accepted to begin a comment in C, but I
strongly suspect that any compiler modern enough to know about that
will know just as well about #if 0.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

[TUHS] // comment in C++

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

Well, personally I use // for almost all comments in C/C++.  I
reserve /* */ for commenting out blocks of code.   Since, for some
reason, /* */ doesn't nest, if I stick to this style life is good.

Steve

----- Original Message -----
From: "Steve Nickolas" <usotsuki@buric.co>
To:"The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Cc:
Sent:Wed, 8 Feb 2017 21:47:49 -0500 (EST)
Subject:Re: [TUHS] // comment in C++

 On Thu, 9 Feb 2017, Dave Horsfall wrote:

 > On Wed, 8 Feb 2017, Steve Johnson wrote:
 >
 >> I remember some discussion about this.  In reality, a C comment
really
 >> requires you to type 8 characters, because putting anything
adjacent to
 >> the /* or */ looks terrible.  Many languages used single
characters
 >> (e.g., # for make).  The argument was "if you make comments
easier to
 >> type, you'll get more of them in the code"  (viz. the Unix
kernel).  I'm
 >> guessing Bjarne was aware of these discussions, although I don't
 >> remember specifically that he was...
 >
 > My favourite C /* */ style is this:
 >
 > /*
 > * foo
 > * bar
 > */

 This is the way I usually write my comments, too.

 > Is that what you meant? And recent C also accepts // as a comment,
which
 > I use like this:
 >
 > /*
 > * This is where we do some neat stuff.
 > */
 > foo();
 > weird_function(); // Yes, we need to call this here...
 > bar();
 >
 > I'm quite taken by BIND, though, which accepts
 >
 > /* this */
 > // this
 > # and this.

 Unrealircd likewise accepts those 3 different types of comments.

 -uso.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/a6dd92a5/attachment.html>

[TUHS] // comment in C++

[Warner Losh]

On Wed, Feb 8, 2017 at 7:46 PM, Dave Horsfall <dave at horsfall.org> wrote:
> On Wed, 8 Feb 2017, Corey Lindsly wrote:
>
>> > I'm quite taken by BIND, though, which accepts
>> >
>> > /* this */
>> > // this
>> > # and this.
>>
>> Not that.
>>
>> ; But this.
>
> Perhaps I meant named.conf (part of BIND):
>
>     named.conf is the configuration file for named. Statements are enclosed
>     in braces and terminated with a semi-colon. Clauses in the statements
>     are also semi-colon terminated. The usual comment styles are supported:
>
>     C style: /* */
>
>     C++ style: // to end of line
>
>     Unix style: # to end of line
>
> Where did you get
>
>     ; But this?

Old School assembler comments. This found its way into a number of
config files long after most uses of Old School assembler had moved
on...

Macro-16 is where I first encountered it, but it is much older. It is
common in DEC syntax, and some others.

Warner

[TUHS] // comment in C++

[Corey Lindsly]

> Perhaps I meant named.conf (part of BIND):
> 
>     named.conf is the configuration file for named. Statements are enclosed
>     in braces and terminated with a semi-colon. Clauses in the statements
>     are also semi-colon terminated. The usual comment styles are supported:
> 
>     C style: /* */
> 
>     C++ style: // to end of line
> 
>     Unix style: # to end of line
> 
> Where did you get
> 
>     ; But this?

Ah, yes, you're correct for named.conf. I was referring to the zone files.

--corey

[TUHS] // comment in C++

[Steve Nickolas]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]

On Thu, 9 Feb 2017, Dave Horsfall wrote:

> On Wed, 8 Feb 2017, Steve Johnson wrote:
>
>> I remember some discussion about this.  In reality, a C comment really
>> requires you to type 8 characters, because putting anything adjacent to
>> the /* or */ looks terrible.  Many languages used single characters
>> (e.g., # for make).  The argument was "if you make comments easier to
>> type, you'll get more of them in the code"  (viz. the Unix kernel).  I'm
>> guessing Bjarne was aware of these discussions, although I don't
>> remember specifically that he was...
>
> My favourite C /* */ style is this:
>
> /*
>  * foo
>  * bar
>  */

This is the way I usually write my comments, too.

> Is that what you meant?  And recent C also accepts // as a comment, which
> I use like this:
>
>    /*
>     * This is where we do some neat stuff.
>     */
>    foo();
>    weird_function();	// Yes, we need to call this here...
>    bar();
>
> I'm quite taken by BIND, though, which accepts
>
> /* this */
> // this
> # and this.

Unrealircd likewise accepts those 3 different types of comments.

-uso.

[TUHS] // comment in C++

[Dave Horsfall]

On Wed, 8 Feb 2017, Corey Lindsly wrote:

> > I'm quite taken by BIND, though, which accepts
> > 
> > /* this */
> > // this
> > # and this.
> 
> Not that.
> 
> ; But this.

Perhaps I meant named.conf (part of BIND):

    named.conf is the configuration file for named. Statements are enclosed
    in braces and terminated with a semi-colon. Clauses in the statements
    are also semi-colon terminated. The usual comment styles are supported:

    C style: /* */

    C++ style: // to end of line

    Unix style: # to end of line

Where did you get

    ; But this?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] // comment in C++

[Corey Lindsly]

> 
> I'm quite taken by BIND, though, which accepts
> 
> /* this */
> // this
> # and this.

Not that.

; But this.

Cheers,

--corey

[TUHS] // comment in C++

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 981 bytes --]

On Wed, 8 Feb 2017, Steve Johnson wrote:

> I remember some discussion about this.  In reality, a C comment really 
> requires you to type 8 characters, because putting anything adjacent to 
> the /* or */ looks terrible.  Many languages used single characters 
> (e.g., # for make).  The argument was "if you make comments easier to 
> type, you'll get more of them in the code"  (viz. the Unix kernel).  I'm 
> guessing Bjarne was aware of these discussions, although I don't 
> remember specifically that he was...

My favourite C /* */ style is this:

/*
 * foo
 * bar
 */

Is that what you meant?  And recent C also accepts // as a comment, which 
I use like this:

    /*
     * This is where we do some neat stuff.
     */
    foo();
    weird_function();	// Yes, we need to call this here...
    bar();

I'm quite taken by BIND, though, which accepts

/* this */
// this
# and this.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] // comment in C++

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

I remember some discussion about this.  In reality, a C comment
really requires you to type 8 characters, because putting anything
adjacent to the /* or */ looks terrible.  Many languages used single
characters (e.g., # for make).  The argument was "if you make
comments easier to type, you'll get more of them in the code"  (viz.
the Unix kernel).  I'm guessing Bjarne was aware of these
discussions, although I don't remember specifically that he was...

Steve

----- Original Message -----
From: arnold@skeeve.com
To:<tuhs at minnie.tuhs.org>, <rminnich at gmail.com>
Cc:
Sent:Wed, 08 Feb 2017 11:17:28 -0700
Subject:Re: [TUHS] // comment in C++

 ron minnich <rminnich at gmail.com> wrote:

 > I've always wondered if this was done in honor of JCL, as sort of a
riff on
 > the dd command. Anyone know?
 >
 > ron

 I'm fairly certain it was originally in BCPL.

 You could just drop a note to Bjarne Stroustrup and ask. :-)

 Arnold

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/d8a7449b/attachment.html>

[TUHS] // comment in C++

[Greg 'groggy' Lehey]

On Wednesday,  8 February 2017 at 22:51:12 +0000, ron minnich wrote:
> On Wed, Feb 8, 2017 at 2:45 PM Greg 'groggy' Lehey <grog at lemis.com> wrote:
>
>> // had a very different meaning in IBM JCL.  It's a sequence
>> indicating that a command follows, and I have a suspicion that it's
>> related to a prompt.
>>
>
> oh, believe me, I typed enough JCL to know. I was always just so amused by
> the dd command that when I first saw // in C++, I had to wonder. It's a
> question that's been banging around in my head for several decades ...

I suppose one argument might be that JCL also had a /*

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/f4fb6719/attachment.sig>

[TUHS] // comment in C++

[Greg 'groggy' Lehey]

On Wednesday,  8 February 2017 at 17:50:57 -0500, Ron Natalie wrote:
> Amusingly in the UNIVAC FIELDDATA character set.   The @ had the value zero
> (and was called the master space).
> It's sort of like making NUL the command character :)

Well, except that there were no non-printing characters in Fieldata.

> Amusingly UNIVAC had their own punched card format (same size card,
> which was by the way, the size of a dollar bill in Hollerith's day)
> but used two banks of 45 round holes for 90 columns.

Yes, I heard of them, but they didn't seem to be a commercial success.
I worked with UNIVAC kit from 1973 to 1977, on the 1108/1106 and the
494, but I never saw any card like that.  They also had a very nice
card punch, the VIP, that buffered a card content and only punched
when you released the card, thus enabling erasures.  But it used
standard IBM format cards.

> -Ron "I had a cat named @FURPUR" Natalie

:-)

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/18593a3a/attachment.sig>

[TUHS] // comment in C++

[ron minnich]

On Wed, Feb 8, 2017 at 2:45 PM Greg 'groggy' Lehey <grog at lemis.com> wrote:

>
> // had a very different meaning in IBM JCL.  It's a sequence
> indicating that a command follows, and I have a suspicion that it's
> related to a prompt.
>

oh, believe me, I typed enough JCL to know. I was always just so amused by
the dd command that when I first saw // in C++, I had to wonder. It's a
question that's been banging around in my head for several decades ...

thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/0b7f82bf/attachment-0001.html>

[TUHS] // comment in C++

[Ron Natalie]

Amusingly in the UNIVAC FIELDDATA character set.   The @ had the value zero
(and was called the master space).
It's sort of like making NUL the command character :)

Amusingly UNIVAC had their own punched card format (same size card, which
was by the way, the size of a dollar bill in Hollerith's day) but used two
banks of 45 round holes for 90 columns.

-Ron "I had a cat named @FURPUR" Natalie

[TUHS] // comment in C++

[Greg 'groggy' Lehey]

On Wednesday,  8 February 2017 at 18:06:53 +0000, ron minnich wrote:
> I've always wondered if this was done in honor of JCL, as sort of a riff on
> the dd command. Anyone know?

// had a very different meaning in IBM JCL.  It's a sequence
indicating that a command follows, and I have a suspicion that it's
related to a prompt.  In JCL (on punched cards) you had to punch it
with the rest, but interactive programs printed it for you, usually a
single character.  UNIVAC OS/1100 used @, and OMEGA used #, for
example.

Does anybody else have input?

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170209/6828e370/attachment.sig>

[TUHS] // comment in C++

[arnold]

ron minnich <rminnich at gmail.com> wrote:

> I've always wondered if this was done in honor of JCL, as sort of a riff on
> the dd command. Anyone know?
>
> ron

I'm fairly certain it was originally in BCPL.

You could just drop a note to Bjarne Stroustrup and ask. :-)

Arnold

[TUHS] // comment in C++

[A. P. Garcia]

On 2/8/17, ron minnich <rminnich at gmail.com> wrote:
> I've always wondered if this was done in honor of JCL, as sort of a riff on
> the dd command. Anyone know?
>
> ron

it's from bcpl...

[TUHS] // comment in C++

[ron minnich]

I've always wondered if this was done in honor of JCL, as sort of a riff on
the dd command. Anyone know?

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170208/2b97e431/attachment.html>