+---- JdeBP@jba.co.uk wrote (6 Sep 1996 16:06:42 GMT):
 | Most of section 5 of the comp.lang.C FAQ is devoted to common
 | misconceptions and incorrect "programmer lore"

The last standards language I saw, while technically correct,
does nothing to improve the situation.  Pointers are a pitfall
of many a beginner.  And professional.  The use of the word
'common' gives me hope that there is at least some awareness of
the problem.

I was making a point about _usability_, not technical accuracy.

My general experience is that anything requiring lawyers
(technical or otherwise) takes a hit in efficiency.

 | To summarise : the standards are not the problem.  The standards documents
 | define what is what when it comes to null pointers, and any misconceptions
 | that programmers may have can only be eradicated by showing them what the
 | standards do and do not say.  Altering the standards won't change the
 | erroneous beliefs that programmers may have.  Only educating the
 | programmers will do that.
 +----

Given the current access policies of ISO and ANSI that situation
probably won't improve either.

--
Gary Johnson                                                   "Rosebud . . ."
gjohnson@season.com <a href="http://www.epic.org/privacy/wiretap">Freedom?</a>
                             CAMPAIGN '96: Juck 'em if they can't fake a toke.



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article gjohnson@dream.season.com, gjohnson@dream.season.com (Reality is a point of view) writes:
> +---- JdeBP@jba.co.uk wrote (6 Sep 1996 16:06:42 GMT):
> | Most of section 5 of the comp.lang.C FAQ is devoted to common
> | misconceptions and incorrect "programmer lore"
>
>The last standards language I saw, while technically correct,
>does nothing to improve the situation.  Pointers are a pitfall
>of many a beginner.

A language standards document is not intended to teach the language.
It is intended to explain as completely, concisely, and
unambiguously as possible the language rules.

>My general experience is that anything requiring lawyers
>(technical or otherwise) takes a hit in efficiency.

What consitutes good pedagogy is different from what constitutes a good
language standard. A good tutorial explains things incompletely and in
different ways in different places, for example. A language standard
should specify things completely, just once, and in only one way.

If you find something inadequate about the draft standard, please
make a positive suggestion. If you don't say what you think is
wrong or poorly done, it's hard for us to find a way to improve it.

>Given the current access policies of ISO and ANSI that situation
>probably won't improve either.

Anyone who wants to contribute to working on the standard may do so,
getting copies of every document and email discussion, by joining
the committee.

Anyone who isn't willing to make that sort of commmitment, but who
wants to make comments may also do so, at designated times when
complete copies of the draft are made freely available. Such comments
will be addressed and answered by the committee.

If that still isn't good enough, you can get a paper copy of any current
draft, warts and all, from X3 for the cost of duplication and mailing.
What sort of access do you feel you are being denied?

---
Steve Clamage, stephen.clamage@eng.sun.com




[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

gjohnson@dream.season.com (Reality is a point of view) writes:

>  +---- JdeBP@jba.co.uk wrote (6 Sep 1996 16:06:42 GMT):
>  | Most of section 5 of the comp.lang.C FAQ is devoted to common
>  | misconceptions and incorrect "programmer lore"
>
> The last standards language I saw, while technically correct,
> does nothing to improve the situation.  Pointers are a pitfall
> of many a beginner.  And professional.  The use of the word
> 'common' gives me hope that there is at least some awareness of
> the problem.
>
> I was making a point about _usability_, not technical accuracy.
>
> My general experience is that anything requiring lawyers
> (technical or otherwise) takes a hit in efficiency.

I presume here that you mean programmer efficiency.  In which case, I
can only concur, and remind people that since the programmer is also the
most expensive part in the system, programmer efficiency should be the
dominating criteria (except, of course, for the exceptions which prove
the rule).

>  | To summarise : the standards are not the problem.  The standards documents
>  | define what is what when it comes to null pointers, and any misconceptions
>  | that programmers may have can only be eradicated by showing them what the
>  | standards do and do not say.  Altering the standards won't change the
>  | erroneous beliefs that programmers may have.  Only educating the
>  | programmers will do that.
>  +----
>
> Given the current access policies of ISO and ANSI that situation
> probably won't improve either.

While I would like to see more openess on the part of ISO and ANSI as
well (say, the final standard on a CD ROM, with good search machine), I
don't really consider it the job of the standardization committee to
educate programmers, either.  Uninformed programmers have no business
pushing the envelope of the language, and really shouldn't need a
standards document.  (If they are professional, they also have no
business staying uninformed, but that is another problem.)

--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Reality is a point of view (gjohnson@dream.season.com) wrote:
|  + clamage@eng.sun.com wrote (29 Aug 1996 22:45:53 GMT):
|  | It would help if you said what needed improving. I've
|  | always thought the wording was pretty clear and straightforward.
|
| Please see section 5 of the C FAQ.

Most of section 5 of the comp.lang.C FAQ is devoted to common
misconceptions and incorrect "programmer lore", such as the myth that a NULL
pointer has to have a bit pattern of all zeroes (it does not).  The actual
standards documents themselves (i.e. the C++ DWP) are pretty clear on
null pointers.  Null pointer constants and null pointer values are defined
in [conv.ptr.1], and the results of their use in various expressions are
defined in [expr].  Anything else is undefined.

Section 5 of the comp.lang.C FAQ mainly deals with misconceptions that
programmers have about what is and what isn't defined in the language
standards.  The misconception about the underlying representation of null
pointer values, the misconception that "if (p)" is not well-formed, and
the misconception that all pointers are implemented in the same way are
examples of this -- all of which are covered by the comp.lang.C FAQ.  However,
these misconceptions are not founded in what the standards actually *say*.
The standards documents *don't* define the underlying representation of
pointers, *do* define the meaning of "if (p)", and *don't* require all
pointer types to be implemented in the same way.

To summarise : the standards are not the problem.  The standards documents
define what is what when it comes to null pointers, and any misconceptions
that programmers may have can only be eradicated by showing them what the
standards do and do not say.  Altering the standards won't change the
erroneous beliefs that programmers may have.  Only educating the
programmers will do that.

Incidental note : The answer to FAQ 5.3 in the on-line version of the FAQ
is in fact only correct for the C language.  The C++ language has a boolean
type, a requirement that the expression in an if statement be of boolean
type, and a standard converson from pointer type fo boolean type.  So
although the end is the same, the route travelled to get there is somewhat
different.  Be careful when applying a C FAQ to the C++ language.


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]