* [TUHS] // comment in C++
@ 2017-02-09 21:14 Doug McIlroy
2017-02-10 17:39 ` Steffen Nurpmeso
0 siblings, 1 reply; 40+ messages in thread
From: Doug McIlroy @ 2017-02-09 21:14 UTC (permalink / raw)
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]
^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 21:14 [TUHS] // comment in C++ Doug McIlroy @ 2017-02-10 17:39 ` Steffen Nurpmeso 0 siblings, 0 replies; 40+ messages in thread From: Steffen Nurpmeso @ 2017-02-10 17:39 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ @ 2017-02-09 14:44 Noel Chiappa 2017-02-09 16:51 ` Steffen Nurpmeso 0 siblings, 1 reply; 40+ messages in thread From: Noel Chiappa @ 2017-02-09 14:44 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 14:44 Noel Chiappa @ 2017-02-09 16:51 ` Steffen Nurpmeso 2017-02-09 19:36 ` Steffen Nurpmeso 0 siblings, 1 reply; 40+ messages in thread From: Steffen Nurpmeso @ 2017-02-09 16:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 16:51 ` Steffen Nurpmeso @ 2017-02-09 19:36 ` Steffen Nurpmeso 0 siblings, 0 replies; 40+ messages in thread From: Steffen Nurpmeso @ 2017-02-09 19:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <mailman.204.1486594285.3779.tuhs@minnie.tuhs.org>]
* [TUHS] // comment in C++ [not found] <mailman.204.1486594285.3779.tuhs@minnie.tuhs.org> @ 2017-02-09 0:03 ` Paul McJones 2017-02-09 2:28 ` Marc Rochkind 2017-02-09 13:11 ` Tony Finch 0 siblings, 2 replies; 40+ messages in thread From: Paul McJones @ 2017-02-09 0:03 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 0:03 ` Paul McJones @ 2017-02-09 2:28 ` Marc Rochkind 2017-02-09 13:11 ` Tony Finch 1 sibling, 0 replies; 40+ messages in thread From: Marc Rochkind @ 2017-02-09 2:28 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 0:03 ` Paul McJones 2017-02-09 2:28 ` Marc Rochkind @ 2017-02-09 13:11 ` Tony Finch 1 sibling, 0 replies; 40+ messages in thread From: Tony Finch @ 2017-02-09 13:11 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ @ 2017-02-08 18:06 ron minnich 2017-02-08 18:08 ` A. P. Garcia ` (2 more replies) 0 siblings, 3 replies; 40+ messages in thread From: ron minnich @ 2017-02-08 18:06 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-08 18:06 ron minnich @ 2017-02-08 18:08 ` A. P. Garcia 2017-02-08 18:17 ` arnold 2017-02-08 22:45 ` Greg 'groggy' Lehey 2 siblings, 0 replies; 40+ messages in thread From: A. P. Garcia @ 2017-02-08 18:08 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-08 18:06 ron minnich 2017-02-08 18:08 ` A. P. Garcia @ 2017-02-08 18:17 ` arnold 2017-02-08 23:39 ` Steve Johnson 2017-02-08 22:45 ` Greg 'groggy' Lehey 2 siblings, 1 reply; 40+ messages in thread From: arnold @ 2017-02-08 18:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-08 18:17 ` arnold @ 2017-02-08 23:39 ` Steve Johnson 2017-02-08 23:52 ` Dave Horsfall 0 siblings, 1 reply; 40+ messages in thread From: Steve Johnson @ 2017-02-08 23:39 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-08 23:39 ` Steve Johnson @ 2017-02-08 23:52 ` Dave Horsfall 2017-02-09 2:11 ` Corey Lindsly 2017-02-09 2:47 ` Steve Nickolas 0 siblings, 2 replies; 40+ messages in thread From: Dave Horsfall @ 2017-02-08 23:52 UTC (permalink / raw) [-- 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." ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-08 23:52 ` Dave Horsfall @ 2017-02-09 2:11 ` Corey Lindsly 2017-02-09 2:46 ` Dave Horsfall 2017-02-09 2:47 ` Steve Nickolas 1 sibling, 1 reply; 40+ messages in thread From: Corey Lindsly @ 2017-02-09 2:11 UTC (permalink / raw) > > I'm quite taken by BIND, though, which accepts > > /* this */ > // this > # and this. Not that. ; But this. Cheers, --corey ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 2:11 ` Corey Lindsly @ 2017-02-09 2:46 ` Dave Horsfall 2017-02-09 2:53 ` Corey Lindsly 2017-02-09 4:38 ` Warner Losh 0 siblings, 2 replies; 40+ messages in thread From: Dave Horsfall @ 2017-02-09 2:46 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 2:46 ` Dave Horsfall @ 2017-02-09 2:53 ` Corey Lindsly 2017-02-09 4:38 ` Warner Losh 1 sibling, 0 replies; 40+ messages in thread From: Corey Lindsly @ 2017-02-09 2:53 UTC (permalink / raw) > 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 2:46 ` Dave Horsfall 2017-02-09 2:53 ` Corey Lindsly @ 2017-02-09 4:38 ` Warner Losh 1 sibling, 0 replies; 40+ messages in thread From: Warner Losh @ 2017-02-09 4:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-08 23:52 ` Dave Horsfall 2017-02-09 2:11 ` Corey Lindsly @ 2017-02-09 2:47 ` Steve Nickolas 2017-02-09 4:55 ` Steve Johnson 1 sibling, 1 reply; 40+ messages in thread From: Steve Nickolas @ 2017-02-09 2:47 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 2:47 ` Steve Nickolas @ 2017-02-09 4:55 ` Steve Johnson 2017-02-09 11:59 ` Michael Kjörling 2017-02-09 12:18 ` Brantley Coile 0 siblings, 2 replies; 40+ messages in thread From: Steve Johnson @ 2017-02-09 4:55 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 4:55 ` Steve Johnson @ 2017-02-09 11:59 ` Michael Kjörling 2017-02-09 21:56 ` Dave Horsfall 2017-02-09 12:18 ` Brantley Coile 1 sibling, 1 reply; 40+ messages in thread From: Michael Kjörling @ 2017-02-09 11:59 UTC (permalink / raw) [-- 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) ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 11:59 ` Michael Kjörling @ 2017-02-09 21:56 ` Dave Horsfall 2017-02-10 0:17 ` Dan Cross 2017-02-10 9:19 ` arnold 0 siblings, 2 replies; 40+ messages in thread From: Dave Horsfall @ 2017-02-09 21:56 UTC (permalink / raw) [-- 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." ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 21:56 ` Dave Horsfall @ 2017-02-10 0:17 ` Dan Cross 2017-02-10 1:58 ` Dave Horsfall 2017-02-10 9:19 ` arnold 1 sibling, 1 reply; 40+ messages in thread From: Dan Cross @ 2017-02-10 0:17 UTC (permalink / raw) [-- 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-10 0:17 ` Dan Cross @ 2017-02-10 1:58 ` Dave Horsfall 2017-02-10 2:46 ` Nemo 2017-02-10 9:30 ` arnold 0 siblings, 2 replies; 40+ messages in thread From: Dave Horsfall @ 2017-02-10 1:58 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-10 1:58 ` Dave Horsfall @ 2017-02-10 2:46 ` Nemo 2017-02-10 2:49 ` Dave Horsfall 2017-02-10 9:30 ` arnold 1 sibling, 1 reply; 40+ messages in thread From: Nemo @ 2017-02-10 2:46 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-10 2:46 ` Nemo @ 2017-02-10 2:49 ` Dave Horsfall 0 siblings, 0 replies; 40+ messages in thread From: Dave Horsfall @ 2017-02-10 2:49 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-10 1:58 ` Dave Horsfall 2017-02-10 2:46 ` Nemo @ 2017-02-10 9:30 ` arnold 1 sibling, 0 replies; 40+ messages in thread From: arnold @ 2017-02-10 9:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 21:56 ` Dave Horsfall 2017-02-10 0:17 ` Dan Cross @ 2017-02-10 9:19 ` arnold 1 sibling, 0 replies; 40+ messages in thread From: arnold @ 2017-02-10 9:19 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 4:55 ` Steve Johnson 2017-02-09 11:59 ` Michael Kjörling @ 2017-02-09 12:18 ` Brantley Coile 2017-02-09 13:31 ` Nick Downing 1 sibling, 1 reply; 40+ messages in thread From: Brantley Coile @ 2017-02-09 12:18 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 12:18 ` Brantley Coile @ 2017-02-09 13:31 ` Nick Downing 0 siblings, 0 replies; 40+ messages in thread From: Nick Downing @ 2017-02-09 13:31 UTC (permalink / raw) [-- 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. > ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-08 18:06 ron minnich 2017-02-08 18:08 ` A. P. Garcia 2017-02-08 18:17 ` arnold @ 2017-02-08 22:45 ` Greg 'groggy' Lehey 2017-02-08 22:50 ` Ron Natalie 2017-02-08 22:51 ` ron minnich 2 siblings, 2 replies; 40+ messages in thread From: Greg 'groggy' Lehey @ 2017-02-08 22:45 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-08 22:45 ` Greg 'groggy' Lehey @ 2017-02-08 22:50 ` Ron Natalie 2017-02-08 23:22 ` Greg 'groggy' Lehey 2017-02-09 12:12 ` Michael Kjörling 2017-02-08 22:51 ` ron minnich 1 sibling, 2 replies; 40+ messages in thread From: Ron Natalie @ 2017-02-08 22:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-08 22:50 ` Ron Natalie @ 2017-02-08 23:22 ` Greg 'groggy' Lehey 2017-02-09 12:12 ` Michael Kjörling 1 sibling, 0 replies; 40+ messages in thread From: Greg 'groggy' Lehey @ 2017-02-08 23:22 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-08 22:50 ` Ron Natalie 2017-02-08 23:22 ` Greg 'groggy' Lehey @ 2017-02-09 12:12 ` Michael Kjörling 2017-02-09 12:26 ` Lars Brinkhoff 2017-02-09 12:31 ` Paul Ruizendaal 1 sibling, 2 replies; 40+ messages in thread From: Michael Kjörling @ 2017-02-09 12:12 UTC (permalink / raw) [-- 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) ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 12:12 ` Michael Kjörling @ 2017-02-09 12:26 ` Lars Brinkhoff 2017-02-09 14:37 ` Random832 2017-02-09 12:31 ` Paul Ruizendaal 1 sibling, 1 reply; 40+ messages in thread From: Lars Brinkhoff @ 2017-02-09 12:26 UTC (permalink / raw) [-- 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 _ ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 12:26 ` Lars Brinkhoff @ 2017-02-09 14:37 ` Random832 2017-02-09 14:49 ` Random832 0 siblings, 1 reply; 40+ messages in thread From: Random832 @ 2017-02-09 14:37 UTC (permalink / raw) [-- 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) ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 14:37 ` Random832 @ 2017-02-09 14:49 ` Random832 0 siblings, 0 replies; 40+ messages in thread From: Random832 @ 2017-02-09 14:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 12:12 ` Michael Kjörling 2017-02-09 12:26 ` Lars Brinkhoff @ 2017-02-09 12:31 ` Paul Ruizendaal 2017-02-09 13:07 ` Steffen Nurpmeso 1 sibling, 1 reply; 40+ messages in thread From: Paul Ruizendaal @ 2017-02-09 12:31 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-09 12:31 ` Paul Ruizendaal @ 2017-02-09 13:07 ` Steffen Nurpmeso 0 siblings, 0 replies; 40+ messages in thread From: Steffen Nurpmeso @ 2017-02-09 13:07 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-08 22:45 ` Greg 'groggy' Lehey 2017-02-08 22:50 ` Ron Natalie @ 2017-02-08 22:51 ` ron minnich 2017-02-08 23:22 ` Greg 'groggy' Lehey 1 sibling, 1 reply; 40+ messages in thread From: ron minnich @ 2017-02-08 22:51 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
* [TUHS] // comment in C++ 2017-02-08 22:51 ` ron minnich @ 2017-02-08 23:22 ` Greg 'groggy' Lehey 0 siblings, 0 replies; 40+ messages in thread From: Greg 'groggy' Lehey @ 2017-02-08 23:22 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2017-02-10 17:39 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-02-09 21:14 [TUHS] // comment in C++ Doug McIlroy 2017-02-10 17:39 ` Steffen Nurpmeso -- strict thread matches above, loose matches on Subject: below -- 2017-02-09 14:44 Noel Chiappa 2017-02-09 16:51 ` Steffen Nurpmeso 2017-02-09 19:36 ` Steffen Nurpmeso [not found] <mailman.204.1486594285.3779.tuhs@minnie.tuhs.org> 2017-02-09 0:03 ` Paul McJones 2017-02-09 2:28 ` Marc Rochkind 2017-02-09 13:11 ` Tony Finch 2017-02-08 18:06 ron minnich 2017-02-08 18:08 ` A. P. Garcia 2017-02-08 18:17 ` arnold 2017-02-08 23:39 ` Steve Johnson 2017-02-08 23:52 ` Dave Horsfall 2017-02-09 2:11 ` Corey Lindsly 2017-02-09 2:46 ` Dave Horsfall 2017-02-09 2:53 ` Corey Lindsly 2017-02-09 4:38 ` Warner Losh 2017-02-09 2:47 ` Steve Nickolas 2017-02-09 4:55 ` Steve Johnson 2017-02-09 11:59 ` Michael Kjörling 2017-02-09 21:56 ` Dave Horsfall 2017-02-10 0:17 ` Dan Cross 2017-02-10 1:58 ` Dave Horsfall 2017-02-10 2:46 ` Nemo 2017-02-10 2:49 ` Dave Horsfall 2017-02-10 9:30 ` arnold 2017-02-10 9:19 ` arnold 2017-02-09 12:18 ` Brantley Coile 2017-02-09 13:31 ` Nick Downing 2017-02-08 22:45 ` Greg 'groggy' Lehey 2017-02-08 22:50 ` Ron Natalie 2017-02-08 23:22 ` Greg 'groggy' Lehey 2017-02-09 12:12 ` Michael Kjörling 2017-02-09 12:26 ` Lars Brinkhoff 2017-02-09 14:37 ` Random832 2017-02-09 14:49 ` Random832 2017-02-09 12:31 ` Paul Ruizendaal 2017-02-09 13:07 ` Steffen Nurpmeso 2017-02-08 22:51 ` ron minnich 2017-02-08 23:22 ` Greg 'groggy' Lehey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).