Re: Idiotic programming style edicts
Jonathan de Boyne Pollard
>>
>> If an obscure technique is being employed, then a comment to that
>> effect is a helpful pointer but I have seen _REALLY USEFUL_ comments
>> along the following lines ...
>>
>> x := X + 1 ; increment x
>>
>> ... which only serve to increase the noise floor.
>>
> In our shop, those appeared when we got the idiotic edict that each
> line had to have a comment.
>
Such edicts make one want to write code in the form
x /* The variable x */
= /* is assigned */
x /* its value * /
+ /* plus * /
2 /* one */
; /* . */
Eric Chomko
Or,
char *x /* magic pointer */
x--; /* bump the pointer backwards */
Kenny McCormack
Jonathan de Boyne Pollard <J.deBoynePoll...@NTLWorld.COM> wrote:
>>
>>>
>>> If an obscure technique is being employed, then a comment to that
>>> effect is a helpful pointer but I have seen _REALLY USEFUL_ comments
>>> along the following lines ...
>>>
>>> x := X + 1 ; increment x
A true CLC pedantic would point out that the above does not increment x
(unless x and X have the same value).
>>> ... which only serve to increase the noise floor.
>>>
>> In our shop, those appeared when we got the idiotic edict that each
>> line had to have a comment.
>>
>Such edicts make one want to write code in the form
>
> x /* The variable x */
> = /* is assigned */
> x /* its value * /
> + /* plus * /
> 2 /* two */
> ; /* . */
Correction applied. HTH.
--
(This discussion group is about C, ...)
Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...
ImpalerCore
newsgro...@NTLWorld.COM> wrote:
It also shows that maintaining these kinds of comment are more trouble
than the comment is worth. The maintenance of these comments is way
higher than the information they give, i.e. Who forgot to change the '/
* one */' to '/* two */'?
Andrew Poelstra
x /* The pointer */
-> /* equals */
x /* itself */
= /* minus */
2 /* five */
; /* :( */
--
Andrew Poelstra
http://www.wpsoftware.net/andrew
ImpalerCore
wrote:
Then you start questioning which is right, the comment or the code,
which can end up leading to a lot more work to figure it out.
> --
> Andrew Poelstrahttp://www.wpsoftware.net/andrew
Nick Keighley
> In article <IU.D20100316.T165150.P1185...@J.de.Boyne.Pollard.localhost>,
> Jonathan de Boyne Pollard <J.deBoynePollard-newsgro...@NTLWorld.COM> wrote:
> >>> If an obscure technique is being employed, then a comment to that
> >>> effect is a helpful pointer but I have seen _REALLY USEFUL_ comments
> >>> along the following lines ...
>
> >>> x := X + 1 ; increment x
>
> A true CLC pedantic would point out that the above does not increment x
> (unless x and X have the same value).
it plainly isn't C. Perhaps in whatever-it-is-written-in cares about
case.
What *is* it written in?
> >>> ... which only serve to increase the noise floor.
>
> >> In our shop, those appeared when we got the idiotic edict that each
> >> line had to have a comment.
>
> >Such edicts make one want to write code in the form
>
> > x /* The variable x */
> > = /* is assigned */
> > x /* its value * /
> > + /* plus * /
> > 2 /* two */
> > ; /* . */
>
> Correction applied. HTH.
#include "crlzyzz.h" /* obvious meaning */
if it's obvious, why did you comment it?
jmfbahciv
Fortunately, your code would produce many detected errors.
/BAH
jmfbahciv
basic OS coding. It's very nice to be able to scan the listing
just like the CPU would do when executing.
/BAH
jmfbahciv
obvious to the reader, then a search for the author
or his/her specs is in order.
/BAH
Robert Marshall
> In article
> <IU.D20100316.T...@J.de.Boyne.Pollard.localhost>,
> Jonathan de Boyne Pollard <J.deBoynePoll...@NTLWorld.COM> wrote:
>>>
>>>>
>>>> If an obscure technique is being employed, then a comment to that
>>>> effect is a helpful pointer but I have seen _REALLY USEFUL_
>>>> comments along the following lines ...
>>>>
>>>> x := X + 1 ; increment x
>
> A true CLC pedantic would point out that the above does not increment
> x (unless x and X have the same value).
>
and would also point out that the comment should read 'increment x by 1'
(so if X >= x it still increments x unless we start having integer
overflow)
Robert
--
La grenouille songe..dans son château d'eau
Jonathan de Boyne Pollard
>>>
>>> In our shop, those appeared when we got the idiotic edict that each
>>> line had to have a comment.
>>>
>> Such edicts make one want to write code in the form
>>
>> x /* The variable x */
>> = /* is assigned */
>> x /* its value * /
>> + /* plus * /
>> 2 /* one */
>> ; /* . */
>>
> And would make all tapes spill over to two magtapes.
>
> Fortunately, your code would produce many detected errors.
>
Nick Keighley
> Nick Keighley wrote:
> > On 16 Mar, 18:13, gaze...@shell.xmission.com (Kenny McCormack) wrote:
> >> In article <IU.D20100316.T165150.P1185...@J.de.Boyne.Pollard.localhost>,
> >> Jonathan de Boyne Pollard <J.deBoynePollard-newsgro...@NTLWorld.COM> wrote:
>
> >>>>> If an obscure technique is being employed, then a comment to that
> >>>>> effect is a helpful pointer but I have seen _REALLY USEFUL_ comments
> >>>>> along the following lines ...
> >>>>> x := X + 1 ; increment x
> >> A true CLC pedantic would point out that the above does not increment x
> >> (unless x and X have the same value).
>
> > it plainly isn't C. Perhaps in whatever-it-is-written-in cares about
> > case.
doh!
///doesn't care about case///
> > What *is* it written in?
>
> >>>>> ... which only serve to increase the noise floor.
> >>>> In our shop, those appeared when we got the idiotic edict that each
> >>>> line had to have a comment.
> >>> Such edicts make one want to write code in the form
> >>> x /* The variable x */
> >>> = /* is assigned */
> >>> x /* its value * /
> >>> + /* plus * /
> >>> 2 /* two */
> >>> ; /* . */
> >> Correction applied. HTH.
>
> > #include "crlzyzz.h" /* obvious meaning */
>
> > if it's obvious, why did you comment it?
>
> Now that one may have usefulness :-). If it's not
> obvious to the reader, then a search for the author
> or his/her specs is in order.
to beat him about the head and shoulders with
Ahem A Rivet's Shot
Nope that's perfectly valid C code - provided that x is declared in
scope.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Patricia Shanahan
> On Wed, 17 Mar 2010 07:03:43 -0500
> jmfbahciv <jmfbahciv@aol> wrote:
>
>> Jonathan de Boyne Pollard wrote:
>
>>> Such edicts make one want to write code in the form
>>>
>>> x /* The variable x */
>>> = /* is assigned */
>>> x /* its value * /
>>> + /* plus * /
>>> 2 /* one */
>>> ; /* . */
>>>
>> And would make all tapes spill over to two magtapes.
>>
>> Fortunately, your code would produce many detected errors.
>
> Nope that's perfectly valid C code - provided that x is declared in
> scope.
>
This sort of thing is one of the strongest arguments for *always*
editing and viewing code in an editor with syntax highlighting for the
source language. The problem and the reason why the compiler would
accept the code both become glaringly obvious.
Patricia
Alf P. Steinbach
Can't see the invisible u know.
Cheers,
- Alf
Keith Thompson
[...]
>> In article <IU.D20100316.T165150.P1185...@J.de.Boyne.Pollard.localhost>,
>> Jonathan de Boyne Pollard <J.deBoynePollard-newsgro...@NTLWorld.COM> wrote:
>
>> >>> If an obscure technique is being employed, then a comment to that
>> >>> effect is a helpful pointer but I have seen _REALLY USEFUL_ comments
>> >>> along the following lines ...
>>
>> >>> x := X + 1 ; increment x
>>
>
> it plainly isn't C. Perhaps in whatever-it-is-written-in cares about
> case.
>
> What *is* it written in?
I don't recognize the language, but it was originally posted only
to alt.folklore.computers. Somebody decided to add a cross-post
to comp.programming and comp.lang.c and didn't bother to mention it.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
jacka...@gmail.com
> > What *is* it written in?
>
> [...]
>
> I don't recognize the language, but it was originally posted only
> to alt.folklore.computers. Somebody decided to add a cross-post
> to comp.programming and comp.lang.c and didn't bother to mention it.
>
pascal uses := as an assignment operator
Keith Thompson
But it doesn't use ; to introduce a comment.
Of course, the code could have been incorrect.
Magnum
news:lniq8vd...@nuthaus.mib.org...
> "jacka...@gmail.com" <jacka...@gmail.com> writes:
>>> > What *is* it written in?
>>>
>>> [...]
>>>
>>> I don't recognize the language, but it was originally posted only
>>> to alt.folklore.computers. Somebody decided to add a cross-post
>>> to comp.programming and comp.lang.c and didn't bother to mention it.
>>
>> pascal uses := as an assignment operator
>
> But it doesn't use ; to introduce a comment.
>
> Of course, the code could have been incorrect.
or it could have been notional code in no particular language as the
context was the illustration of pointless commenting, and the X instead
of x just being a typo?
Eric Chomko
> On Wed, 17 Mar 2010 07:03:43 -0500
>
> jmfbahciv <jmfbahciv@aol> wrote:
> > Jonathan de Boyne Pollard wrote:
> > > Such edicts make one want to write code in the form
>
> > > x /* The variable x */
> > > = /* is assigned */
> > > x /* its value * /
> > > + /* plus * /
> > > 2 /* one */
> > > ; /* . */
>
> > And would make all tapes spill over to two magtapes.
>
> > Fortunately, your code would produce many detected errors.
>
> Nope that's perfectly valid C code - provided that x is declared in
> scope.
>
Isn't "in scope" redundant here? I mean scope only applies to binding
time, no? Locals vs. globals vs. non-locals which are not global,
etc. But I agree the code is fine from the stand point of the
compiler.
Keith Thompson
Agreed. But note that the "its value" and "plus" comments aren't
properly terminated, so the "/*" on the "its value" line introduces a
comment that isn't terminated until the "*/" on the "one" line.
The net result is "x = x;"
Scott Lurndal
>On Mar 17, 9:33=A0am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>> On Wed, 17 Mar 2010 07:03:43 -0500
>>
>> jmfbahciv <jmfbahciv@aol> wrote:
>> > Jonathan de Boyne Pollard wrote:
>> > > Such edicts make one want to write code in the form
>>
>> > > =A0 =A0 =3D =A0/* is assigned */
>> > > =A0 =A0 x =A0/* its value * /
>> > > =A0 =A0 + =A0/* plus * /
>> > > =A0 =A0 2 =A0/* one */
>> > > =A0 =A0 ; =A0 /* . */
>>
>> > And would make all tapes spill over to two magtapes.
>>
>> > Fortunately, your code would produce many detected errors.
>>
>eclared in
>> scope.
>>
>
>Isn't "in scope" redundant here? I mean scope only applies to binding
>time, no? Locals vs. globals vs. non-locals which are not global,
>etc. But I agree the code is fine from the stand point of the
>compiler.
except for the two occurances of '* /' instead of '*/'.
scott
Jonathan de Boyne Pollard
>>>>
>>>> Such edicts make one want to write code in the form
>>>> x /* The variable x */
>>>> = /* is assigned */
>>>> x /* its value * /
>>>> + /* plus * /
>>>> 2 /* one */
>>>> ; /* . */
>>>>
>>> It also shows that maintaining these kinds of comment are more
>>> trouble than the comment is worth. The maintenance of these
>>> comments is way higher than the information they give, i.e. Who
>>>
>> x /* The pointer */
>> -> /* equals */
>> x /* itself */
>> = /* minus */
>> 2 /* five */
>> ; /* :( */
>>
> Then you start questioning which is right, the comment or the code,
> which can end up leading to a lot more work to figure it out.
>
Jonathan de Boyne Pollard
>>
>> Such edicts make one want to write code in the form
>>
> x /* The variable x */
> = /* is assigned */
> x /* its value * /
> + /* plus * /
> 2 /* two */
> ; /* . */
>
> Correction applied. HTH.
>
subtle point. The discrepancy in the mandatory comment prose caused you
to overlook another error. I deliberately made it a well-known and
fairly basic C programming error that most of the people participating
in this thread from comp.lang.c should all be familiar with, and
regularly leap upon in posted code, moreover.
Jonathan de Boyne Pollard
>
> Agreed. But note that the "its value" and "plus" comments aren't
> properly terminated, so the "/*" on the "its value" line introduces a
> comment that isn't terminated until the "*/" on the "one" line. The
> net result is "x = x;"
>
took and how many would do so.
So not only does the mandatory comment on every line not match the
apparent code, but the apparent code isn't the actual code, as a direct
consequence of the mandatory comments.
I'm assuming that M. Shanahan either spotted this too, or would have
done so.
Kenny McCormack
Jonathan de Boyne Pollard <J.deBoynePoll...@NTLWorld.COM> wrote:
...
>As has been finally spotted, there was a subtler point in there, too.
We could play the "Who subtler now?" game until the cows come home.
The point I was making was that that's what we do in CLC.
The standard CLC thing is to pounce upon something stupid, like the
upper/lower case thing, and totally ignore real issues. It's the whole
"prototyping main()" thing, that we do so well.
Nick Keighley
> "jackassp...@gmail.com" <jackassp...@gmail.com> writes:
> >> > What *is* it written in?
>
> >> [...]
>
> >> I don't recognize the language, but it was originally posted only
> >> to alt.folklore.computers. Somebody decided to add a cross-post
> >> to comp.programming and comp.lang.c and didn't bother to mention it.
>
> > pascal uses := as an assignment operator
>
> But it doesn't use ; to introduce a comment.
>
> Of course, the code could have been incorrect.
scheme uses ; as a comment- but of course doesn't look anything like
the above
Jonathan de Boyne Pollard
>>
>> Such edicts make one want to write code in the form
>>
>> x /* The variable x */
>> = /* is assigned */
>> x /* its value * /
>> + /* plus * /
>> 2 /* one */
>> ; /* . */
>>
> editing and viewing code in an editor with syntax highlighting for the
> source language. The problem and the reason why the compiler would
> accept the code both become glaringly obvious.
>
several places other than Usenet, that syntax colouring would have been
right there in the posting itself. Had I written it, for example, on a
MediaWiki wiki (with the appropriate extensions), simply placing the
code within a <syntaxhighlight> HTML element (with the language set to C
or C++) would have revealed the problem. One can envisage a future
extension to HTML where the <code> element causes browser-side syntax
colouring. There are already places where it causes server-side syntax
colouring. Stack Overflow is one such. Again, had I posted the snippet
in a Stack Overflow Q&A thread, within a <code> element, it would have
been automatically coloured, showing the extent of the comment.
A text/plain bodypart in a Usenet posting doesn't have such a
capability, of course.
We're probably all aware of the extra problems that posting to Usenet
introduces into code, including posting mechanisms that introduce
mandatory line wrap, some of which (Step forward, Google Groups.) not
only provide no mechanism for inhibiting line wrapping but don't even
let the poster know ahead of time where the line wrapping will actually
be, which can play havoc with "C++-style" comments. This is a case of
posting to Usenet helping to make a problem more difficult to spot than
it would be in (some) editors, on (some) wikis, and on some WWW
programming discussion fora.
Ahem A Rivet's Shot
sc...@slp53.sl.home (Scott Lurndal) wrote:
They don't stop it from being fine from the point of view of the
compiler - they just add another dimension of the comments being wrong.
Ahem A Rivet's Shot
Patricia Shanahan <pa...@acm.org> wrote:
> Ahem A Rivet's Shot wrote:
> > On Wed, 17 Mar 2010 07:03:43 -0500
> > jmfbahciv <jmfbahciv@aol> wrote:
> >
> >> Jonathan de Boyne Pollard wrote:
> >
> >>> Such edicts make one want to write code in the form
> >>>
> >>> x /* The variable x */
> >>> = /* is assigned */
> >>> x /* its value * /
> >>> + /* plus * /
> >>> 2 /* one */
> >>> ; /* . */
> >>>
> >> And would make all tapes spill over to two magtapes.
> >>
> >> Fortunately, your code would produce many detected errors.
> >
> > Nope that's perfectly valid C code - provided that x is
> > declared in scope.
> >
>
> This sort of thing is one of the strongest arguments for *always*
> editing and viewing code in an editor with syntax highlighting for the
> source language.
I do.
> The problem and the reason why the compiler would
> accept the code both become glaringly obvious.
The spaces between the * and / in two carefully selected spaces ?
They're not problems they're part of the charm of the example.
jmfbahciv
>>
>>>>
assembled some code because MACRO would report a "successful"
assembly with the comment "No errors detected". Think about it. ;-)
/BAH
jmfbahciv
valuable.
/BAH
spinoza1111
wrote:
> In article <IU.D20100316.T165150.P1185...@J.de.Boyne.Pollard.localhost>,
> Jonathan de Boyne Pollard <J.deBoynePollard-newsgro...@NTLWorld.COM> wrote:
>
>
>
> >>> If an obscure technique is being employed, then a comment to that
> >>> effect is a helpful pointer but I have seen _REALLY USEFUL_ comments
> >>> along the following lines ...
>
> >>> x := X + 1 ; increment x
>
> A true CLC pedantic would point out that the above does not increment x
> (unless x and X have the same value).
Richard Heathfield, thou should'st be here at this hour:
England hath need of thee
>
> >>> ... which only serve to increase the noise floor.
>
> >> In our shop, those appeared when we got the idiotic edict that each
> >> line had to have a comment.
>
> >Such edicts make one want to write code in the form
>
> > x /* The variable x */
> > = /* is assigned */
> > x /* its value * /
> > + /* plus * /
> > 2 /* two */
> > ; /* . */
Nothing wrong with this style of commenting in assembler, at all. And,
this code sample looks like the one byte per instruction language
Mouse.
Sure, programmers without verbal skills hate commenting, for obvious
reasons. They are unable to come up with witty and amusing comments.
But don't make a new edict for those of us who can write.
int strlen(char *strString) // Of strings I sing, and their Length
{ // Oh muse, give me strength
int intIndex1 = 0; // To not fuck it up, like that Pup
for (; // Seebach, coder extraordinaire
*(strString+intIndex1);// Who doesn't care
intIndex1++); // That he makes us tear our hair.
return intIndex1; // And so my code is Done
} // And all had great fun
...five minutes including the poem...
>
> Correction applied. HTH.
jmfbahciv
> On Mar 17, 2:13 am, gaze...@shell.xmission.com (Kenny McCormack)
> wrote:
>> In article <IU.D20100316.T165150.P1185...@J.de.Boyne.Pollard.localhost>,
>> Jonathan de Boyne Pollard <J.deBoynePollard-newsgro...@NTLWorld.COM> wrote:
<snip>
>>> Such edicts make one want to write code in the form
>>> x /* The variable x */
>>> = /* is assigned */
>>> x /* its value * /
>>> + /* plus * /
>>> 2 /* two */
>>> ; /* . */
>
> Nothing wrong with this style of commenting in assembler, at all. And,
> this code sample looks like the one byte per instruction language
> Mouse.
<snip>
Are you nuts?
/BAH
Bradley K. Sherman
Jonathan de Boyne Pollard <J.deBoynePoll...@NTLWorld.COM> wrote:
>> ...
>Such edicts make one want to write code in the form
>
> x /* The variable x */
> = /* is assigned */
> x /* its value * /
> + /* plus * /
> ; /* . */
>
That's great for those new AI compilers that throw away
the code and compile the comments.
--bks
p.s. Yes, stolen from Stan Kelly-Bootle.
Nick Keighley
> spinoza1111 wrote:
> > On Mar 17, 2:13 am, gaze...@shell.xmission.com (Kenny McCormack)
> >> Jonathan de Boyne Pollard <J.deBoynePollard-newsgro...@NTLWorld.COM> wrote:
> >>> Such edicts make one want to write code in the form
> >>> x /* The variable x */
> >>> = /* is assigned */
> >>> x /* its value * /
> >>> + /* plus * /
> >>> 2 /* two */
> >>> ; /* . */
>
> > Nothing wrong with this style of commenting in assembler, at all. And,
> > this code sample looks like the one byte per instruction language
>
> <snip>
>
> Are you nuts?
yes, check his posting history
Charlie Gibbs
writes:
> <grin> My language is MACRO-10. JMF was always tickled whenever
> he assembled some code because MACRO would report a "successful"
> assembly with the comment "No errors detected". Think about it. ;-)
"As far as we know, the system has never had an undetected error."
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Charlie Gibbs
<4f0aac38-8622-4a1f...@k36g2000prb.googlegroups.com>,
spino...@yahoo.com (spinoza1111) writes:
> int strlen(char *strString) // Of strings I sing, and their Length
> { // Oh muse, give me strength
> int intIndex1 = 0; // To not fuck it up, like that Pup
> for (; // Seebach, coder extraordinaire
> *(strString+intIndex1);// Who doesn't care
> intIndex1++); // That he makes us tear our hair.
> return intIndex1; // And so my code is Done
> } // And all had great fun
int daysinmonth (int month, year)
{
if ((month == 9) /* Thirty days hath September, */
|| (month == 4) /* April, */
|| (month == 6) /* June, */
|| (month == 11)) { /* and November. */
return (30);
} else if (month != 2) { /* All the rest have thirty-one, */
return (31);
} else { /* Except for February alone, */
if ((year % 4) != 0) {
return (28); /* Which has but 28 days clear, */
} else {
return (29); /* And 29 in each leap year. */
}
}
}
Adding the century rule is left as an exercise for the reader.
Walter Bushell
"Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
> In article <hnt5b...@news4.newsguy.com>, jmfbahciv@aol (jmfbahciv)
> writes:
>
> > <grin> My language is MACRO-10. JMF was always tickled whenever
> > he assembled some code because MACRO would report a "successful"
> > assembly with the comment "No errors detected". Think about it. ;-)
>
> "As far as we know, the system has never had an undetected error."
That is true of *all* the code I have wrote.
--
A computer without Microsoft is like a chocolate cake without mustard.
Patrick Scheible
Lessons:
Even a small change, like adding a comment, can introduce a bug (as
Barb has been saying).
A syntax-highlighting editor can be helpful in reducing trivial errors.
Languages in which the end of the line ends a comment (such as C++,
Ada, Unix shell scripts, Icon, others) reduce or contain syntax
errors.
-- Patrick
spinoza1111
No, just that rarity: a competent programmer (the best one in this
newsgroup, probably) who's literate. You snipped this:
int strlen(char *strString) // Of strings I sing, and their Length
{ // Oh muse, give me strength
int intIndex1 = 0; // To not fuck it up, like that Pup
for (; // Seebach, coder extraordinaire
*(strString+intIndex1);// Who doesn't care
intIndex1++); // That he makes us tear our hair.
return intIndex1; // And so my code is Done
} // And all had great fun
...five minutes including the poem...
>
> /BAH
spinoza1111
> In article
>
> spinoza1...@yahoo.com (spinoza1111) writes:
> > int strlen(char *strString) // Of strings I sing, and their Length
> > { // Oh muse, give me strength
> > int intIndex1 = 0; // To not fuck it up, like that Pup
> > for (; // Seebach, coder extraordinaire
> > *(strString+intIndex1);// Who doesn't care
> > intIndex1++); // That he makes us tear our hair.
> > return intIndex1; // And so my code is Done
> > } // And all had great fun
>
> int daysinmonth (int month, year)
> {
> if ((month == 9) /* Thirty days hath September, */
> || (month == 4) /* April, */
> || (month == 6) /* June, */
> || (month == 11)) { /* and November. */
> return (30);
> } else if (month != 2) { /* All the rest have thirty-one, */
> return (31);
> } else { /* Except for February alone, */
> if ((year % 4) != 0) {
> return (28); /* Which has but 28 days clear, */
> } else {
> return (29); /* And 29 in each leap year. */
> }
> }
>
> }
>
> Adding the century rule is left as an exercise for the reader.
Good, but my poem was original and I wrote it while coding the simple
strlen.
I can walk and simultaneously chew Nicorette Gum
Can you, chum?
BruceS
<OT> AIUI, C++ accepts /* */ multiline comments without artificially
terminating said comments at the end of line. I don't have a C++
Standard in front of me, so I can't confirm that it isn't simply an
artifact of environments in which I've written C++, but I'm relatively
confident that these work the same as in C. </OT>
According to The C Standard, 6.4.9p2, C allows comments that *do*
automatically terminate at the end of the line, just as this style of
comment works in C++. One could avoid the bug in the earlier code by
writing it:
x // The variable x
= // is assigned
x // its value
+ // plus
2 // pi
; // .
Oh, I'd better put in a :) or we'll have started another pointless
whinefest.
Keith Thompson
[...]
> <OT> AIUI, C++ accepts /* */ multiline comments without artificially
> terminating said comments at the end of line. I don't have a C++
> Standard in front of me, so I can't confirm that it isn't simply an
> artifact of environments in which I've written C++, but I'm relatively
> confident that these work the same as in C. </OT>
In both C and C++, a comment that begins with /* is not
"artificially" terminated at the end of the line. Instead, it's
"artificially" terminated by the next */. (In other words, I'm
not sure what's so artificial about it.)
> According to The C Standard, 6.4.9p2, C allows comments that *do*
> automatically terminate at the end of the line, just as this style of
> comment works in C++.
[...]
Yes, both C and C++ now permit comments introduced by // and
terminated by the end of the line. These were introduced in BCPL,
one of C's distant ancestors from the 1960s. But they were dropped
from C, and only reintroduced by the 1999 ISO C standard (which
superseded the 1990 ISO C standard, which itself superseded the
de facto standard of Kernighan & Ritchie's book). C++ has always
supported // comments.
Today, most C compilers fully support at least the C90 standard,
but only a subset of the C99 standard. // comments are very widely
supported. On the other hand, they can be rejected if you choose
to invoke your C compiler in a strict C90-conforming mode, or if
you're using a sufficiently old compiler, so /*...*/ comments are
arguably more portable. // comments can also cause problems in
Usenet posts; implicit line wrapping can introduce syntax errors.
(Most people here in comp.lang.c already know this stuff; I'm posting
it mostly for the benefit of those in alt.folklore.computers and
comp.programming, to which this thread is cross-posted.)
Patrick Scheible
> On Mar 18, 11:10=A0am, Patrick Scheible <k...@zipcon.net> wrote:
> > Jonathan de Boyne Pollard <J.deBoynePollard-newsgro...@NTLWorld.COM> writ=
> es:
> >
> >
> >
> >
> >
> > > > Agreed. But note that the "its value" and "plus" comments aren't
> > > > properly terminated, so the "/*" on the "its value" line introduces a
> > > > comment that isn't terminated until the "*/" on the "one" line. The
> > > > net result is "x =3D x;"
> >
> > > Hooray! =A0At last! =A0Well spotted. =A0I've been waiting to see how lo=
> ng it
> > > took and how many would do so.
> >
> > > So not only does the mandatory comment on every line not match the
> > > apparent code, but the apparent code isn't the actual code, as a direct
> > > consequence of the mandatory comments.
> >
> > > I'm assuming that M. Shanahan either spotted this too, or would have
> > > done so.
> >
> > Lessons:
> >
> > Even a small change, like adding a comment, can introduce a bug (as
> > Barb has been saying).
> >
> > A syntax-highlighting editor can be helpful in reducing trivial errors.
> >
> > Languages in which the end of the line ends a comment (such as C++,
> > Ada, Unix shell scripts, Icon, others) reduce or contain syntax
> > errors.
>
> <OT> AIUI, C++ accepts /* */ multiline comments without artificially
> terminating said comments at the end of line. I don't have a C++
> Standard in front of me, so I can't confirm that it isn't simply an
> artifact of environments in which I've written C++, but I'm relatively
> confident that these work the same as in C. </OT>
Yes, C++ accepts such comments, but it introduced the // to end of
line style comments and that is what I am talking about.
> According to The C Standard, 6.4.9p2, C allows comments that *do*
> automatically terminate at the end of the line, just as this style of
> comment works in C++.
C allows that now? I knew several compilers accept it,
I didn't know it was part of the standard.
-- Patrick
BruceS
Yes, it's part of the C99 standard. The smiley was because "The
Standard" can refer to either the old C99 standard or the older C89
standard, depending on who's talking. IMO, this was a very useful
addition to the language. I've been using these comments for some
time, either as extensions to the standard or as part of the standard
for a language not quite C.
BruceS
> BruceS <bruce...@hotmail.com> writes:
>
> [...]
>
> > <OT> AIUI, C++ accepts /* */ multiline comments without artificially
> > terminating said comments at the end of line. I don't have a C++
> > Standard in front of me, so I can't confirm that it isn't simply an
> > artifact of environments in which I've written C++, but I'm relatively
> > confident that these work the same as in C. </OT>
>
> In both C and C++, a comment that begins with /* is not
> "artificially" terminated at the end of the line. Instead, it's
> "artificially" terminated by the next */. (In other words, I'm
> not sure what's so artificial about it.)
"Artificially" may have been a poor choice of word. "Automatically"?
I was simply pointing out that both languages have the multiline
comment form that presented the misleading effect.
> > According to The C Standard, 6.4.9p2, C allows comments that *do*
> > automatically terminate at the end of the line, just as this style of
> > comment works in C++.
>
> [...]
>
> Yes, both C and C++ now permit comments introduced by // and
> terminated by the end of the line. These were introduced in BCPL,
> one of C's distant ancestors from the 1960s. But they were dropped
> from C, and only reintroduced by the 1999 ISO C standard (which
> superseded the 1990 ISO C standard, which itself superseded the
> de facto standard of Kernighan & Ritchie's book). C++ has always
> supported // comments.
>
> Today, most C compilers fully support at least the C90 standard,
> but only a subset of the C99 standard. // comments are very widely
> supported. On the other hand, they can be rejected if you choose
> to invoke your C compiler in a strict C90-conforming mode, or if
> you're using a sufficiently old compiler, so /*...*/ comments are
> arguably more portable. // comments can also cause problems in
> Usenet posts; implicit line wrapping can introduce syntax errors.
>
> (Most people here in comp.lang.c already know this stuff; I'm posting
> it mostly for the benefit of those in alt.folklore.computers and
> comp.programming, to which this thread is cross-posted.)
You've made clear what I was pointing out less directly. The lack
of // comments is only when strictly adhering to the C90 (I keep
calling it "C89"; are the two terms equivalent or am I just getting it
wrong?) standard. Patrick's point is well taken, that these auto-
terminating comments can help avoid certain errors. Of course, that
would also avoid some of the humor in the early post.
Mensanator
Hey! Some of us folklorists actually DO know how to program.
Keith Thompson
[...]
> You've made clear what I was pointing out less directly. The lack
> of // comments is only when strictly adhering to the C90 (I keep
> calling it "C89"; are the two terms equivalent or am I just getting it
> wrong?) standard. Patrick's point is well taken, that these auto-
> terminating comments can help avoid certain errors. Of course, that
> would also avoid some of the humor in the early post.
Yes, C89 and C90 are (two documents that describe) the same language.
ANSI published the first C standard in 1989. ISO adopted ANSI's
standard in 1990; they added some non-normative introductory material
and renumbered the sections (ANSI sections 3 and 4 are ISO sections
6 and 7), but the text is otherwise unchanged. ANSI officially
adopted the ISO C90 standard shortly thereafter.
There was a 1995 amendment that added some relatively minor features.
The 1999 standard was issued directly by ISO (and ANSI adopted it).
There have been three Technical Corrigenda since then (folded
into <http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>,
which isn't *quite* 100% official but it's close enough). Work is
in progress on C201X.
Ben Bacarisse
about C standards:
<snip>
> The 1999 standard was issued directly by ISO (and ANSI adopted it).
> There have been three Technical Corrigenda since then (folded
> into <http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>,
> which isn't *quite* 100% official but it's close enough).
I thought there had been only two TCs. Not that it really matters how
many there are, but if there is a third I can't find it and I'd like
to have a look.
> Work is in progress on C201X.
--
Ben.
Keith Thompson
Definitely three.
Go to <http://webstore.ansi.org/> and enter "9899" as the document
number; all three TCs are available as free downloads.
The C99 standard itself is available for the low low price of $275,
$30, $349, or $235, depending on which ADD TO CART button you click.
(I think I paid $18 for my copy).
Larry__Weiss
At least we think we remember that we know how to program.
And some of us still demonstrate it by actually programming from time to time.
Some of us wonder why we need all of these languages...
http://en.wikipedia.org/wiki/List_of_programming_languages
- Larry
Ben Bacarisse
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>> Keith Thompson <ks...@mib.org> writes:
>> about C standards:
>> <snip>
>>> The 1999 standard was issued directly by ISO (and ANSI adopted it).
>>> There have been three Technical Corrigenda since then (folded
>>> into <http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>,
>>> which isn't *quite* 100% official but it's close enough).
>>
>> I thought there had been only two TCs. Not that it really matters how
>> many there are, but if there is a third I can't find it and I'd like
>> to have a look.
>
> Definitely three.
So there are.
> Go to <http://webstore.ansi.org/> and enter "9899" as the document
> number; all three TCs are available as free downloads.
Thanks. I tried to find it on WG14's web pages and could see only
two. The main page does talk about TC3 but there is no text for it.
It turns out you can get it from the ISO as well: http://www.iso.org
> The C99 standard itself is available for the low low price of $275,
> $30, $349, or $235, depending on which ADD TO CART button you click.
> (I think I paid $18 for my copy).
! The last time I tried to get the older C90 from the BSI it was 400
pounds sterling.
--
Ben.
Larry__Weiss
> I thought there had been only two TCs. Not that it really matters how
> many there are, but if there is a third I can't find it and I'd like
> to have a look.
>
http://www.open-std.org/jtc1/sc22/wg14/www/standards.html
- Larry
Dave Hansen
> In article <hnt5bs22...@news4.newsguy.com>, jmfbahciv@aol (jmfbahciv)
> writes:
>
> > <grin> My language is MACRO-10. JMF was always tickled whenever
> > he assembled some code because MACRO would report a "successful"
> > assembly with the comment "No errors detected". Think about it. ;-)
>
> "As far as we know, the system has never had an undetected error."
I'm reminded of the hypothetical "conforming" C implementation that,
no matter what is provided for input, displays the message "The input
may contain one or more errors", and emits a dummy program similar (or
identical) to Unix "true". Could be implemented with a shell script.
I'm also reminded of the arguments whether such an implementation was
truly conforming or not, but I don't want to go there...
Regards,
-=Dave
Mensanator
Oo, they even got Seed7 listed.
Would you believe Seed7 actually has a function named "bigCLit"?
(Perhaps the author isn't up on American slang. I know he's European
because he spoke of not living on the same continent.)
But where's BrainFuck?
I certainly don't wonder why.
>
> - Larry
jmfbahciv
thanks. What a relief!
/BAH
jmfbahciv
> In article <hnt5b...@news4.newsguy.com>, jmfbahciv@aol (jmfbahciv)
> writes:
>
>> <grin> My language is MACRO-10. JMF was always tickled whenever
>> he assembled some code because MACRO would report a "successful"
>> assembly with the comment "No errors detected". Think about it. ;-)
>
> "As far as we know, the system has never had an undetected error."
>
/BAH
jmfbahciv
> In article <601.764T26...@kltpzyxm.invalid>,
> "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>
>> In article <hnt5b...@news4.newsguy.com>, jmfbahciv@aol (jmfbahciv)
>> writes:
>>
>>> <grin> My language is MACRO-10. JMF was always tickled whenever
>>> he assembled some code because MACRO would report a "successful"
>>> assembly with the comment "No errors detected". Think about it. ;-)
>> "As far as we know, the system has never had an undetected error."
>
>
> That is true of *all* the code I have wrote.
>
/BAH
jmfbahciv
> Jonathan de Boyne Pollard <J.deBoynePoll...@NTLWorld.COM> writes:
>
>>>
>>> Agreed. But note that the "its value" and "plus" comments aren't
>>> properly terminated, so the "/*" on the "its value" line introduces a
>>> comment that isn't terminated until the "*/" on the "one" line. The
>>> net result is "x = x;"
>>>
>> Hooray! At last! Well spotted. I've been waiting to see how long it
>> took and how many would do so.
>>
>> So not only does the mandatory comment on every line not match the
>> apparent code, but the apparent code isn't the actual code, as a direct
>> consequence of the mandatory comments.
>>
>> I'm assuming that M. Shanahan either spotted this too, or would have
>> done so.
>
> Lessons:
>
> Even a small change, like adding a comment, can introduce a bug (as
> Barb has been saying).
>
> A syntax-highlighting editor can be helpful in reducing trivial errors.
>
You are optimistic. In my shop, the high-lighting would also be
buggy since we'ld have been developing and maintaining that
software, too. I'm glad we had stupid terminals during our
hayday.
/BAH
jmfbahciv
> On Mar 18, 9:19 pm, jmfbahciv <jmfbahciv@aol> wrote:
>> spinoza1111 wrote:
>>> On Mar 17, 2:13 am, gaze...@shell.xmission.com (Kenny McCormack)
>>> wrote:
>>>> In article <IU.D20100316.T165150.P1185...@J.de.Boyne.Pollard.localhost>,
>>>> Jonathan de Boyne Pollard <J.deBoynePollard-newsgro...@NTLWorld.COM> wrote:
>> <snip>
>>
>>>>> Such edicts make one want to write code in the form
>>>>> x /* The variable x */
>>>>> = /* is assigned */
>>>>> x /* its value * /
>>>>> + /* plus * /
>>>>> 2 /* two */
>>>>> ; /* . */
>>> Nothing wrong with this style of commenting in assembler, at all. And,
>>> this code sample looks like the one byte per instruction language
>>> Mouse.
>> <snip>
>>
>> Are you nuts?
>
> No, just that rarity: a competent programmer (the best one in this
> newsgroup, probably)
Now I know you have a 99% reality filter.
>who's literate.
Wrong. there are more capable people in a.f.c.
>You snipped this:
<snip>
/BAH
jmfbahciv
We had a TECO macro which was run over the monitor sources after
the weekly edit to match angle brackets. Do you have to do the
same thing for C's multiple line comment characters (or any
other language)?
/BAH
jmfbahciv
/BAH
Nick Keighley
does the name Edward Nilges ring a bell?
Jongware
> On Mar 17, 2:13 am, gaze...@shell.xmission.com (Kenny McCormack)
> wrote:
>> In article<IU.D20100316.T165150.P1185...@J.de.Boyne.Pollard.localhost>,
>> Jonathan de Boyne Pollard<J.deBoynePollard-newsgro...@NTLWorld.COM> wrote:
>>
>>
>>>> In our shop, those appeared when we got the idiotic edict that each
>>>> line had to have a comment.
>>
>>> Such edicts make one want to write code in the form
>>
>>> x /* The variable x */
>>> = /* is assigned */
>>> x /* its value * /
>>> + /* plus * /
>>> 2 /* two */
>>> ; /* . */
>
> Nothing wrong with this style of commenting in assembler, at all.
Really? Example: (from a previous discussion on comp.programming)
mov edx,len ; move constant into register edx
mov ecx,msg ; move address into register ecx
mov ebx,1 ; move constant into register ebx
mov eax,4 ; move constant into register eax
int 0x80 ; call system interrupt
mov eax,1 ; move constant into register eax
int 0x80 ; call system interrupt
This is Intel 80x86 assembly, and the comments exactly describe what
each of the opcodes do -- completely comparable to your
+ /* plus */
Now how useful is that? Compare with:
mov edx,len ;message length
mov ecx,msg ;message to write
mov ebx,1 ;file descriptor (stdout)
mov eax,4 ;system call number (sys_write)
int 0x80 ;call kernel
mov eax,1 ;system call number (sys_exit)
int 0x80 ;call kernel
.. and suddenly it makes sense, even to one not used to assembly.
[Jw]
jmfbahciv
Nope. What does this have to do programming productivity?
/BAH
Jongware
Nothing whatsoever. That particular name is an inextractible part of
usenet lore, though.
[Jw]
Charlie Gibbs
<19d8b04d-a307-4f2e...@z1g2000prc.googlegroups.com>,
spino...@yahoo.com (spinoza1111) writes:
> I can walk and simultaneously chew Nicorette Gum
> Can you, chum?
I don't smoke.
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Pascal J. Bourguignon
writes:
>>
>>>
>>> Such edicts make one want to write code in the form
>>>
>> x /* The variable x */
>> = /* is assigned */
>> x /* its value * /
>> + /* plus * /
>> 2 /* two */
>> ; /* . */
>>
>> Correction applied. HTH.
>>
> As you now know, you got the correction wrong. This was a
> deliberately subtle point. The discrepancy in the mandatory comment
> prose caused you to overlook another error. I deliberately made it a
> well-known and fairly basic C programming error that most of the
> people participating in this thread from comp.lang.c should all be
> familiar with, and regularly leap upon in posted code, moreover.
Moreover, the original might have been correct actually. For example,
with the following declarations:
enum{ POINTER_TAG=0,
FIXNUM_TAG,
TAG_MASK=1,
BIGNUM_TAG=2,
CHAR_TAG,
STRING_TAG,
CONS_TAG,
ARRAY_TAG
/* ... */ };
typedef int object;
int boxed_tag(object o){
unsigned char* p=(char*)o;
return((int)(*p)); }
object x=((random()&1)==0)?FIXNUM_TAG:fixnum_to_bignum(FIXNUM_TAG);
if((x&TAG_MASK)==FIXNUM_TAG){
x /* The variable x */
= /* is assigned */
x /* its value * /
+ /* plus * /
2 /* ONE */
; /* . */
}else if(boxed_tag(x)==BIGNUM_TAG){
x=bignum_add(x,fixnum_to_bignum(2)); /* still ONE */
}else{
type_error("x must be an integer");
}
--
__Pascal Bourguignon__
Larry__Weiss
> .. and suddenly it makes sense, even to one not used to assembly.
>
Assembly is the one instance where I find comments mandatory to writing good code.
In languages where I'm not constrained in choosing names, I just write readable
code.
- Larry
Jonathan de Boyne Pollard
>
> One could avoid the bug in the earlier code by writing it [using C++
> style comments].
>
Don't forget what I wrote about the problems of posting code to Usenet
in text/plain bodyparts. (For best results, compare what your NUA
displays to you with the raw text of the posting.)
x // The variable x
= // is assigned
// FIXME: The spec says:
1.0
/
x // its value
+ // plus
2.0 // one
; // .
Scott Lurndal
Another example (real-world, from data comm module in a Burroughs MCP)
.TEXT BST -HHT Must move text too
.BIGUN LIX IH-1AV X5 IX1 Get first header
CPN NILPTR IX1 End of list?
EQL +NAKU Yes, NAK & Unlock
MVW TP-FWD X1 IH-1AV X5 Set new flink
BST TP-BIG X1 Note large header
.GOTIT UNLK IH-TLK X5 Unlock tag pool
MVW DP-HDR X6 TP-ENT X1 Move header to tag
SIX -TAGP IX1 Save tag pointer
scott
Seebs
>> does the name Edward Nilges ring a bell?
> Nope.
Ahh, you're missing... well.
Edward Nilges is this guy. He's spent the last couple of years railing
against the Cruele And Unjust Turns Of Fate by which Herbert Schildt has
acquired a negative reputation. For instance, because every competent
programmer who's ever commented on his books says they're pants.
He recently responded to my posting of a quick one-off solution to a problem
(figure 10-15 lines of code) with a >100 line version which took him a couple
of hours to write, and several hours to debug. To demonstrate by complete
incompetence at choosing variable names, he had variables named ptrIndex0,
ptrIndex1, ptrIndex2, and ptrIndex3.
The amazing thing is that, so far as anyone can tell, he actually believes
himself to be serious. Never mind that he has repeatedly sworn to sue various
people for defamation and never yet gotten to it.
Here's a fairly representative example:
> In particular, Stroustrup had learned about
> object oriented programming using Simula in Denmark before coming to
> the US, because in Denmark labor unions had real power and demanded
> that factory automation be documented for union oversight.
That was on one of his comparatively lucid days.
(Posting in detail just because afc people might find this amusing.)
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Mensanator
No idea. I didn't write it, I'm just fingering it trying to help
the author figure out why Seed7 won't compile on Mac OS 10.6.
The problem is that Mac is now using a 64-bit processor, so things
like "int" and "long int" changed meanings under the current C
compiler. (The author is pissed that C compilers don't use constant
names like Java so that "short int" is always 16 bits, "int" always
32,
"long int" always 64, etc.). I don't blame him, if C wasn't so half-
assed
there wouldn't be a need for Seed7. So I've been putting in patches at
the author's direction since he doesn't have a Mac he can try it on.
Changing "long int" to "int" solved the Segment Fault caused by trying
to parse BigIntegers, but apparently has hosed the pointers as some
programs now compile but get a fault when executed.
So we haven't licked it yet.
>
> /BAH
spinoza1111
> On 2010-03-19, jmfbahciv <jmfbahciv@aol> wrote:
>
> >> does the name Edward Nilges ring a bell?
> > Nope.
>
> Ahh, you're missing... well.
>
> Edward Nilges is this guy. He's spent the last couple of years railing
> against the Cruele And Unjust Turns Of Fate by which Herbert Schildt has
> acquired a negative reputation. For instance, because every competent
> programmer who's ever commented on his books says they're pants.
Citing your document, Peter, which listed twenty "errors" (including
shibboleth and trivia) and claimed in a contradictory fashion there
were hundreds in a malicious and defamatory fashion.
>
> He recently responded to my posting of a quick one-off solution to a problem
> (figure 10-15 lines of code) with a >100 line version which took him a couple
> of hours to write, and several hours to debug. To demonstrate by complete
> incompetence at choosing variable names, he had variables named ptrIndex0,
> ptrIndex1, ptrIndex2, and ptrIndex3.
Yes.
"ptr", jerkface, is a pre-Szymonyi "Hungarian" prefix, because it
appears to me that because John Diebold described the use of
systematic prefixes in 1962, when Szymonyi was disrupting Hungary's
attempt to evolve towards decency under Communism, Szymonyi stole an
IBM standard on the job and transformed it without proper attribution
into a PhD thesis.
Furthermore, "index" is spelled out so it can be pronounced, even by
creeps like you, in code walkthroughs and in pair programming.
Finally, an index has a certain point of first use and a scope which
is best expressed by a number, for subsequent to its scope we may need
to reuse it for a completely different purpose, such that giving it a
name tied to its first use would be misleading.
>
> The amazing thing is that, so far as anyone can tell, he actually believes
> himself to be serious. Never mind that he has repeatedly sworn to sue various
> people for defamation and never yet gotten to it.
Mature people generally seek redress first without using lawyers for
the same reason great programmers aren't subservient, autistic little
code monkeys who come in here to get their stupid mistakes debugged.
We are at the stage where I complain to Apress. It shall escalate. You
can end this by apologizing to me and Schildt.
>
> Here's a fairly representative example:
>
> > In particular, Stroustrup had learned about
> > object oriented programming using Simula in Denmark before coming to
> > the US, because in Denmark labor unions had real power and demanded
> > that factory automation be documented for union oversight.
>
> That was on one of his comparatively lucid days.
You're mocking text sourced in the New York Times, in an obituary of
Krysten Nygaard by respected technology journalist John Markoff,
available at
http://www.nytimes.com/2002/08/14/world/kristen-nygaard-75-who-built-framework-for-modern-computer-languages.html?scp=1&sq=ole%20johan%20dahl&st=cse:
"From 1962 to 1967, with his co-worker Ole-Johan Dahl, Mr. Nygaard
designed Simula, a programming language intended to simulate complex
real-world systems. The ideas underlying Simula emerged from Mr.
Nygaard's work in the area of operations research while he was
employed at the Norwegian Defense Research Establishment from 1948 to
1960."
"Although the original use for Simula was a physics simulation for a
military laboratory, workers at the Norwegian Iron and Metal Union
approached Mr. Nygaard, in the late 1960's with concerns about
computers in displacing and altering their jobs. Mr. Nygaard began
working with them, pioneering an approach that became known as
participatory design, in which workers help design new technologies in
the workplace."
'''It was originally thought of as a socialistic movement,' said Dr.
Madsen, who worked with Mr. Nygaard over several decades. 'However,
eventually large corporations began to realize this was a reasonable
practice and it is widely used around the globe today.'"
"Simula was significant for pioneering the concept of ''object
oriented'' programming."
You might think labor unions are a joke, but people in Denmark don't.
Simula was developed so Dahl, and his assistant Stroustrup, could step
by step explain and justify industrial systems to labor unions, which
unlike American unions under the American Taft-Hartley act of 1948,
participate in work decisions. This gives ordinary workers, including
computer programmers, dignity and a self-respect which you do not
have: which you cannot imagine: which think is a fucking joke.
Programmers, especially programmers like you, who are deeply
incompetent and who backstab colleagues in your fashion, typically
have "careers" lasting not much more than ten or fifteen years, with
no long term security such as would be provided by a labor union and
consequently your lack of dignity and self-respect.
Your lack of dignity and self-respect is evident in the way you have
inappropriately written about your personal problems and lack of
academic preparation in a bizarre fashion here which may bring your
employer into disrepute. It is also evident in the way you constantly
make errors which show no programming skill and no academic prep (off
by one strlen, evaluating the index for zero on the right hand side of
a logical And, use of the letter o as a single character identifier,
thinking "the heap is a DOS term), and then get cute about how,
somehow, make trivial errors but get the important stuff right and
must be forgiven because you're a normal (white?) person when all is
said and done...who unlike Nilges doesn't read or write above his
station in life.
Your lack of dignity and self-respect causes you to believe that
others lack dignity, self-respect or reputation, or that their
dignity, self-respect and reputation can be abused, defamed and mocked
by you if they talk like a fag or if in your opinion, their shit's
somehow all fucked up.
You're a normalized deviant, a useful tool who will be thrown away
soon, a dime a dozen hacker and a complete fool.
>
> (Posting in detail just because afc people might find this amusing.)
We don't find your behavior amusing, Peter. It shall have serious
consequences unless you change.
Note to afc: although I left programming in disgust after thirty years
because of dweebs like Peter, my programming career spans the IBM
1401, supercomputing, and .Net object oriented coding. I am the author
of "Build Your Own .Net Language and Compiler", published by Apress in
2004. Although I taught C at Princeton and was asked to assist John "A
Beautiful Mind" Nash with C in 1991, I abandoned it as my code
addressed GUI platforms as inadequate. I've debugged Fortran compilers
with no source, and created a very successful hydrostatic stability
monitor with a graphics library that may have saved lives. I have most
of the work completed in the MSCS with a straight A average.
Peter Seebach, although another Apress author who's written some sort
of scripting book, the quality of which is unknown to me, has no
academic preparation in computer science and claims he has a learning
disorder. His "day job" by his own admission, is a typically factored
and rationalized clerical paraprogramming job in which he finds and
reports compiler bugs, perhaps writing a lot of scripts. His 1995
document "C: the Complete Nonsense" is in fact the sole source of
rumors about computer author Herb Schildt, who's written several large
books on programming which have sold well and gone into multiple
editions, but which, like most computer books, has errors which are
fixed in each new edition. He has harmed Herb materially, causing him
and his family emotional distress.
He's also, as we see above, a very ignorant and incurious person.
I would not normally write this about a colleague. I do so because of
his and Richard Heathfield's malicious and defamatory harassment on
comp.lang.c.
>
> -s
> --
> Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
des...@verizon.net
If you need ints of specific sizes sys/types.h contains all the
int types you might want.
Keith Thompson
[...]
> If you need ints of specific sizes sys/types.h contains all the
> int types you might want.
sys/types.h is not defined by the C standard (it's probably POSIX).
<stdint.h> is standard; it defines typedefs a variety of integer
types of specified sizes. One drawback is that it's new in C99,
and some compilers still might not support it. But even in that
case, it's not too difficult to roll your own; see, for example,
<http://www.lysator.liu.se/c/q8/index.html>.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mensanator
> des...@verizon.net writes:
>
> [...]
>
> > If you need ints of specific sizes sys/types.h contains all the
> > int types you might want.
>
> sys/types.h is not defined by the C standard (it's probably POSIX).
>
> <stdint.h> is standard; it defines typedefs a variety of integer
> types of specified sizes. One drawback is that it's new in C99,
> and some compilers still might not support it. But even in that
> case, it's not too difficult to roll your own; see, for example,
> <http://www.lysator.liu.se/c/q8/index.html>.
Well, I guess if it's not standard and the compiler doesn't support
the things that are standard, we should not be too surprised that
nothing works. The author said the next release was due Sunday and
that all the types would be fixed by then.
But he's been quiet for the last couple days. Perhaps he's bitten
off more than he can chew. I suppose I'll find out Sunday.
Marco S Hyman
> Another example (real-world, from data comm module in a Burroughs MCP)
>
> .TEXT BST -HHT Must move text too
> .BIGUN LIX IH-1AV X5 IX1 Get first header
> CPN NILPTR IX1 End of list?
> EQL +NAKU Yes, NAK & Unlock
> MVW TP-FWD X1 IH-1AV X5 Set new flink
> BST TP-BIG X1 Note large header
> .GOTIT UNLK IH-TLK X5 Unlock tag pool
> MVW DP-HDR X6 TP-ENT X1 Move header to tag
> SIX -TAGP IX1 Save tag pointer
>
> scott
Line by line comments can be interesting. I think it was the
Burroughs Medium Systems dumpall program that, if you read closely,
would find a treatise on go carts. I don't remember if it was
written by one author, or a back and forth between several :-)
/\/\arc
Scott Lurndal
Actually, I wrote part of DMPALL. Specifically the code that added
conditional criteria for record extraction. DMPALL was developed by several
engineers over a 20 year time frame. (Although I didn't keep a listing
of DMPALL, and don't recall the gocart stuff; not having seen the source
since 1986).
What may be the last Medium Systems in the USA was just shut down two
weeks ago, after running since 1988.
I have an emulator, however, and am working on getting a B974 emulation
working so I can support CANDE.
scott
(first @ last dot org)
bartc
Keith Thompson wrote:
> des...@verizon.net writes:
> [...]
>> If you need ints of specific sizes sys/types.h contains all the
>> int types you might want.
>
> sys/types.h is not defined by the C standard (it's probably POSIX).
>
> <stdint.h> is standard; it defines typedefs a variety of integer
> types of specified sizes. One drawback is that it's new in C99,
> and some compilers still might not support it. But even in that
> case, it's not too difficult to roll your own; see, for example,
> <http://www.lysator.liu.se/c/q8/index.html>.
(The files (inttypes.h and stdint.h anyway) appear to be LF-delimited. So in
Internet Explorer 7, they appear as one giant, monolithic block of text
(you'd think software that sophisticated would be able to cope with
LF-newlines...))
The contents of the files, well, starting with stdint.h: I'd only ever seen
the final list of macros, and thought that was bad enough, but the hundreds
of lines of gobbledygook necessary to make even that possible...
There must, surely, be a simpler, more elegant way of declaring an int or
float of a particular width.
(Fortran used to allow:
integer*4
One of my projects also allows:
int:32
Pascal allowed:
[integer]: 0 .. 255 { or syntax along those lines...}
Even C itself allows:
int ... :16 /* but only for bitfields */
And so on. All part of the language as it should be, instead of being
apparently bolted-on as it is here.)
And what's all the print format stuff about in inttypes.h? Are people really
supposed to use these horrible looking things in the middle of format
strings?
If anyone had doubts about needing a 'cleaned up C' (see recent thread on
this started 5-Mar-10), then just look at a few system header files and see
what hoops need to be jumped through to achieve quite mundane things...
--
Bartc
Seebs
> There must, surely, be a simpler, more elegant way of declaring an int or
> float of a particular width.
Not really.
The goal is not to mandate the availability of every conceivable size, but
rather, to allow people to indicate which sizes the machine has.
> (Fortran used to allow:
> integer*4
Sure. And if C's intent were to require that a "4-byte" integer type MUST
exist, something more like that might well have been used.
> And so on. All part of the language as it should be, instead of being
> apparently bolted-on as it is here.)
I think the current division is about right for C -- we don't want to mandate
the existence of types which don't exist. At least with the long/long long
stuff, it's pretty straightforward to make a composite type Large Enough.
What would you do if you wanted to make something SMALLER than the smallest
available word?
> And what's all the print format stuff about in inttypes.h? Are people really
> supposed to use these horrible looking things in the middle of format
> strings?
Do you have a better suggestion?
> If anyone had doubts about needing a 'cleaned up C' (see recent thread on
> this started 5-Mar-10), then just look at a few system header files and see
> what hoops need to be jumped through to achieve quite mundane things...
I don't think a cleanup that addressed this would leave us a language viable
on a broad variety of systems.
-s
--
Keith Thompson
> [other groups dropped]
> Keith Thompson wrote:
>> des...@verizon.net writes:
>> [...]
>>> If you need ints of specific sizes sys/types.h contains all the
>>> int types you might want.
>>
>> sys/types.h is not defined by the C standard (it's probably POSIX).
>>
>> <stdint.h> is standard; it defines typedefs a variety of integer
>> types of specified sizes. One drawback is that it's new in C99,
>> and some compilers still might not support it. But even in that
>> case, it's not too difficult to roll your own; see, for example,
>> <http://www.lysator.liu.se/c/q8/index.html>.
>
> (The files (inttypes.h and stdint.h anyway) appear to be LF-delimited. So in
> Internet Explorer 7, they appear as one giant, monolithic block of text
> (you'd think software that sophisticated would be able to cope with
> LF-newlines...))
>
> The contents of the files, well, starting with stdint.h: I'd only ever seen
> the final list of macros, and thought that was bad enough, but the hundreds
> of lines of gobbledygook necessary to make even that possible...
>
> There must, surely, be a simpler, more elegant way of declaring an int or
> float of a particular width.
Well, in C99 there certainly is:
Just write "#include <stdint.h>" at the top of your source file, and
you can use int32_t (if it's available). That's why the C99 standard
added it to the language.
Why does it matter how ugly the implementation of <stdint.h> is, as
long as it works? *You* don't have to write it, or even read it.
[...]
> And what's all the print format stuff about in inttypes.h? Are people really
> supposed to use these horrible looking things in the middle of format
> strings?
I agree that the printf format strings are quite ugly. I've never
used them myself. For printf, I generally convert to a standard type
that I know is big enough and use the appropriate specifier.
But I'm not sure they could have been done any more cleanly (at least
not without a major redesign of printf).
> If anyone had doubts about needing a 'cleaned up C' (see recent thread on
> this started 5-Mar-10), then just look at a few system header files and see
> what hoops need to be jumped through to achieve quite mundane things...
You'd have a better point if you need to jump through those hoops in
your own code.
Joe Morris
> According to The C Standard, 6.4.9p2, C allows comments that *do*
> automatically terminate at the end of the line, just as this style of
> comment works in C++. One could avoid the bug in the earlier code by
> writing it:
>
> x // The variable x
> = // is assigned
> x // its value
> + // plus
> 2 // pi
> ; // .
>
> Oh, I'd better put in a :) or we'll have started another pointless
> whinefest.
Thread drift warning...
My (non-parity-checked) memory tells me that there was a code block in the
MFT-1 (OS/360 release 14 or maybe 13) nucleus that had register equates
named the traditional Rn (0 <= n <= 15),
but with Rn set equal to a value other than n. I *think* it was in the FLIH
(First-Level Interrupt Handler), in code assembled at sysgen. I always
assumed (as speculation) that when the code was written there was one
register use convention that was later changed, and someone was too lazy to
chase all of the register references in the code and rename them.
Does this sound familiar to anyone?
Joe Morris
Charles Richmond
You can tell when Nigles is off his medication... :-)
--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+
ArarghMai...@not.at.arargh.com
<j.c.m...@verizon.net> wrote:
<snip>
>
>Thread drift warning...
>
>My (non-parity-checked) memory tells me that there was a code block in the
>MFT-1 (OS/360 release 14 or maybe 13) nucleus that had register equates
>named the traditional Rn (0 <= n <= 15),
>but with Rn set equal to a value other than n. I *think* it was in the FLIH
>(First-Level Interrupt Handler), in code assembled at sysgen. I always
>assumed (as speculation) that when the code was written there was one
>register use convention that was later changed, and someone was too lazy to
>chase all of the register references in the code and rename them.
>
>Does this sound familiar to anyone?
>
it in other parts of the source. Can't find any examples, though.
If you should happen to remember the source file name, I could look.
However, a lot of the routines I looked at appear as if somebody at
some point in time said: "Thou shall not use hard coded numbers",
because I see a lot of equates like "d1 equ 1". :-)
--
ArarghMail003 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the extra stuff from the reply address.
Andrew Swallow
> On Fri, 19 Mar 2010 21:11:04 -0400, "Joe Morris"
> <j.c.m...@verizon.net> wrote:
> <snip>
>> Thread drift warning...
>>
>> My (non-parity-checked) memory tells me that there was a code block in the
>> MFT-1 (OS/360 release 14 or maybe 13) nucleus that had register equates
>> named the traditional Rn (0 <= n <= 15),
>> but with Rn set equal to a value other than n. I *think* it was in the FLIH
>> (First-Level Interrupt Handler), in code assembled at sysgen. I always
>> assumed (as speculation) that when the code was written there was one
>> register use convention that was later changed, and someone was too lazy to
>> chase all of the register references in the code and rename them.
>>
>> Does this sound familiar to anyone?
>>
> I don't know about the location you mentioned, but I think I have seen
> it in other parts of the source. Can't find any examples, though.
> If you should happen to remember the source file name, I could look.
>
> However, a lot of the routines I looked at appear as if somebody at
> some point in time said: "Thou shall not use hard coded numbers",
> because I see a lot of equates like "d1 equ 1". :-)
>
d1 equ 1
but m1 changes
m1 equ 2
This means that a third of the +1 become +2. Without the use of
macros there is plenty of room to get that edit wrong.
Andrew Swallow
Jonathan de Boyne Pollard
>>>
>>> does the name Edward Nilges ring a bell?
>>>
>> Nope.
>>
> within, fore, and aft. Look away now if you don't want to hear the
> result. ...]
>
> (Posting in detail just because afc people might find this amusing.)
>
Jonathan de Boyne Pollard
>>>
>>> int strlen(char *strString) // Of strings I sing, and their Length
>>> { // Oh muse, give me strength
>>> int intIndex1 = 0; // To not fuck it up, like that Pup
>>> for (; // Seebach, coder extraordinaire
>>> *(strString+intIndex1);// Who doesn't care
>>> intIndex1++); // That he makes us tear our hair.
>>> return intIndex1; // And so my code is Done
>>> } // And all had great fun
>>>
>> int daysinmonth (int month, year) [...]
>>
> Good, but my poem was original and I wrote it while coding the simple
> strlen.
>
> I can walk and simultaneously chew Nicorette Gum
> Can you, chum?
>
don't know, myself. The last time that I chummed was over a decade
ago. I might have lost the knack.
Aratzio
Jonathan de Boyne Pollard <J.deBoynePoll...@NTLWorld.COM>
Nilges doesn't but Pavlov does.
Ian Bush
>
> There must, surely, be a simpler, more elegant way of declaring an int or
> float of a particular width.
>
> (Fortran used to allow:
>
> integer*4
>
Errrr, no. Very common extension but never standard.
Fortran now, i.e. for the last 20 years, has parameterized types which
allows
you to ask for a minimum range and, for floating point types,
precision, but
no way of asking for a particular width,
Ian
Jonathan de Boyne Pollard
>
> Buried deep in a project, I wrote the following code:
> len = strlen(foo);
> free(foo);
> memcpy(bar, foo, len);
>
> Now, just about anyone can tell you that this, while technically
> wrong, is virtually guaranteed to be harmless in practice — there's
> simply nothing there to reuse the space after the free.
>
I wouldn't be one of the people giving such a guarantee. In several of
the implementations that I'm familiar with, there exists the
possibility, if the string is longer than a page, that deallocating the
storage will cause one or more pages that formed part (or all) of the
string to be decommitted by the C library's heap management, resulting
in an access to decommitted page fault at the point of memcpy(). Even
for strings shorter than a page, there exists the possibility that free
block consolidation would result in the whole page containing the string
becoming free, and hence being decommitted.
Seebs
Yes. If it had segfaulted, I would not have been at all surprised.
Getting a perfectly valid string, which happened to be a different
but reasonably recently used and relevant, surprised me a lot.
bartc
> On 19 Mar, 23:40, "bartc" <ba...@freeuk.com> wrote:
>>
>> There must, surely, be a simpler, more elegant way of declaring an
>> int or float of a particular width.
>>
>> (Fortran used to allow:
>>
>> integer*4
>>
>
> Errrr, no. Very common extension but never standard.
Well I used that on at least 2 systems (both byte-addressed) about 30 years
ago.
But this was more an example of how widths can be specified in syntax,
without an explosion of new identifiers.
> Fortran now, i.e. for the last 20 years, has parameterized types which
> allows
> you to ask for a minimum range and, for floating point types,
> precision, but
> no way of asking for a particular width,
Sounds like it's made the types more abstract.
Which is fine for Fortran, but C is supposed to be a low-level language used
to implement the fiddly bits of operating systems, device drivers, the
runtimes of other languages, and to work on various small processors. All
that sort of thing.
You'd think then the language itself would allow you to choose or specify
the widths of these basic types, and have slightly more abstract ones
(short, int, long, etc) bolted on. Whereas it seems to be the other way
around.
So those header files must somehow define int32_t, say, in terms of the
fuzzy char, short, int, long and long long types of the language.
--
Bartc
Peter Flass
> On 2010-03-20, Jonathan de Boyne Pollard <J.deBoynePoll...@NTLWorld.COM> wrote:
>>> len = strlen(foo);
>>> free(foo);
>>> memcpy(bar, foo, len);
>
>>> Now, just about anyone can tell you that this, while technically
>>> wrong, is virtually guaranteed to be harmless in practice — there's
>>> simply nothing there to reuse the space after the free.
>
>> I wouldn't be one of the people giving such a guarantee. In several of
>> the implementations that I'm familiar with, there exists the
>> possibility, if the string is longer than a page, that deallocating the
>> storage will cause one or more pages that formed part (or all) of the
>> string to be decommitted by the C library's heap management, resulting
>> in an access to decommitted page fault at the point of memcpy(). Even
>> for strings shorter than a page, there exists the possibility that free
>> block consolidation would result in the whole page containing the string
>> becoming free, and hence being decommitted.
>
> Yes. If it had segfaulted, I would not have been at all surprised.
>
> Getting a perfectly valid string, which happened to be a different
> but reasonably recently used and relevant, surprised me a lot.
>
> -s
Multi-threading can cause strange effects.
jmfbahciv
<grin> You wouldn't believe the picture in mind when I read that
line of diatribe against Charlie. Spinzie's walk was not
straight-forward, let alone the chew part.
/BAH
jmfbahciv
> On 2010-03-19, jmfbahciv <jmfbahciv@aol> wrote:
>>> does the name Edward Nilges ring a bell?
>
>> Nope.
>
> Ahh, you're missing... well.
'ey, Seebs. How are ya doing.
>
> Edward Nilges is this guy. He's spent the last couple of years railing
> against the Cruele And Unjust Turns Of Fate by which Herbert Schildt has
> acquired a negative reputation. For instance, because every competent
> programmer who's ever commented on his books says they're pants.
Ah...my brain mists are clearing a tad. I keep forgetting the kooks.
>
> He recently responded to my posting of a quick one-off solution to a problem
> (figure 10-15 lines of code) with a >100 line version which took him a couple
> of hours to write, and several hours to debug. To demonstrate by complete
> incompetence at choosing variable names, he had variables named ptrIndex0,
> ptrIndex1, ptrIndex2, and ptrIndex3.
>
> The amazing thing is that, so far as anyone can tell, he actually believes
> himself to be serious.
yea, I could tell that just from his self-evaluation.
> Never mind that he has repeatedly sworn to sue various
> people for defamation and never yet gotten to it.
>
> Here's a fairly representative example:
>> In particular, Stroustrup had learned about
>> object oriented programming using Simula in Denmark before coming to
>> the US, because in Denmark labor unions had real power and demanded
>> that factory automation be documented for union oversight.
>
> That was on one of his comparatively lucid days.
Oh, dear.
>
> (Posting in detail just because afc people might find this amusing.)
>
Thanks...I think ;-) I'll now be blamed for opening the
Spinzzie I/O channel.
/BAH
jmfbahciv
> On Mar 20, 1:24 am, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2010-03-19, jmfbahciv <jmfbahciv@aol> wrote:
>>
>>>> does the name Edward Nilges ring a bell?
>>> Nope.
>> Ahh, you're missing... well.
<snip snot>
>> (Posting in detail just because afc people might find this amusing.)
>
> We don't find your behavior amusing, Peter. It shall have serious
> consequences unless you change.
uh-oh.
>
> Note to afc: although I left programming in disgust after thirty years
> because of dweebs like Peter, my programming career spans the IBM
> 1401, supercomputing, and .Net object oriented coding. I am the author
> of "Build Your Own .Net Language and Compiler", published by Apress in
> 2004. Although I taught C at Princeton and was asked to assist John "A
> Beautiful Mind" Nash with C in 1991, I abandoned it as my code
> addressed GUI platforms as inadequate. I've debugged Fortran compilers
> with no source,
How did you cause the compiler to compile if you had no FORTRAN code
to feed it?
> and created a very successful hydrostatic stability
> monitor with a graphics library that may have saved lives. I have most
> of the work completed in the MSCS with a straight A average.
>
> Peter Seebach, although another Apress author who's written some sort
> of scripting book, the quality of which is unknown to me, has no
> academic preparation in computer science
Oh, that's why he's so good.
>and claims he has a learning
> disorder. His "day job" by his own admission, is a typically factored
> and rationalized clerical paraprogramming job in which he finds and
> reports compiler bugs, perhaps writing a lot of scripts.
Only a few people are able to do this kind of work well.
<snip>
> He's also, as we see above, a very ignorant and incurious person.
Seebs?!!! You must have a reading challengement.
>
<snip>
/BAH
Walter Bushell
wrote:
> Walter Bushell wrote:
> > In article <601.764T26...@kltpzyxm.invalid>,
> > "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
> >
> >> In article <hnt5b...@news4.newsguy.com>, jmfbahciv@aol (jmfbahciv)
> >> writes:
> >>
> >>> <grin> My language is MACRO-10. JMF was always tickled whenever
> >>> he assembled some code because MACRO would report a "successful"
> >>> assembly with the comment "No errors detected". Think about it. ;-)
> >> "As far as we know, the system has never had an undetected error."
> >
> >
> > That is true of *all* the code I have wrote.
> >
> Not mine. I always write an off by one bug.
>
> /BAH
But if the error is ever detected then it is no longer an undetected
error.
This method brought to you be the department of redundancy department
and Information Management Systems Systems (IMS Systems).
--
A computer without Microsoft is like a chocolate cake without mustard.