In article <741svp$a4r$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
writes
>If nothing else, I hope that I have convinced you that I was not
>being sarcastic.

My apologies if you thought that I refering to your posting, the sarcasm
was exactly the sentence that followed (just in case anyone chose to
read it literally)


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
>
>
> Pete Becker's words [which you omitted] may or may not have been
> sarcastic. My reply was not intended to be sarcastic at all. Please
> re-read what Pete Becker posted, and then consider my words in that
> light. What I wrote was a direct response to his comments.

Let me state my position clearly: I absolutely disagree with the
assertion in one message that "any code that is posted should be 100%
correct according to the standard." When I write code to post here I
intend it to illustrate the point under discussion and only that point.
This is a forum for discussion of standardization of the C++ language.
That is not a subject for beginners, and people who post here should not
feel constrained to post only code that won't confuse beginners. Doing
so would severely inhibit discussions of standardization.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker wrote:
 >
 >AllanW@my-dejanews.com wrote:
 >
 >> In article <366098A4.18B6B7D5@acm.org>,
 >>   Pete Becker <petebecker@acm.org> wrote:
 >
 >> > Siemel Naran wrote:
 >
 >> > > No, I think in general it is a good idea to point out technical
 >> > > mistakes.  Of course, it does not detract from your original
 >> > > point.  But it's nice, just for completeness.  Especially if
 >> > > some beginner is reading this thread and takes us very literally.
 >> > > Because beginners, and sometimes even experts, learn by looking
 >> > > at specific, technical details and then graduating to the general
 >> > > concept.
 >
 >> > Then all the proposed "corrections" are also wrong, because it's not
 >> > legal to write expressions like that in global scope. And, of course,
 >> > nobody added a #include directive to get a definition of cout, and
 >> > nobody added a main function. I feel so sorry for all those beginners
 >> > out there, who are now thoroughly confused.
 >
 >> By their second day in programming class, students understand what a
 >> code "snippet" is.
 >
 >Then you agree with me that it is not appropriate to "point out techical
 >mistakes" in order to protect beginners.

There's a difference between leaving out unimportant details, and
getting the part you leave in wrong. Of course, if the part that's wrong
is unimportant (as it was in this case), there's not much point in
correcting it, but there's also nothing wrong with correcting it.

You're overreacting to this. You shouldn't be taking it so personally.


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36636613.F7A9FE9A@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
>
> AllanW@my-dejanews.com wrote:
>
> > In article <366098A4.18B6B7D5@acm.org>,
> >   Pete Becker <petebecker@acm.org> wrote:
>
> > > Siemel Naran wrote:
>
> > > > No, I think in general it is a good idea to point out technical
> > > > mistakes.  Of course, it does not detract from your original
> > > > point.  But it's nice, just for completeness.  Especially if
> > > > some beginner is reading this thread and takes us very literally.
> > > > Because beginners, and sometimes even experts, learn by looking
> > > > at specific, technical details and then graduating to the general
> > > > concept.
>
> > > Then all the proposed "corrections" are also wrong, because it's not
> > > legal to write expressions like that in global scope. And, of course,
> > > nobody added a #include directive to get a definition of cout, and
> > > nobody added a main function. I feel so sorry for all those beginners
> > > out there, who are now thoroughly confused.
>
> > By their second day in programming class, students understand what a
> > code "snippet" is.
>
> Then you agree with me that it is not appropriate to "point out techical
> mistakes" in order to protect beginners.

Sometimes this is essential. But this doesn't come up everyday in a
newsgroup about language standards, because usually beginners don't
post here (unless they get us confused with some other newsgroup).

Part of the reason that I point out a mistake is pure knee-jerk habit.
I'm a programmer, and I don't like to see code with errors. God knows
that I've been on the other end of that often enough, posting a
question about some language feature only to get 25 responses that
point out I missed a semicolen.

But the main reason why I don't try to break that habit, is that
sometimes these errors can make it difficult to see what the real
question is. The error I pointed out is a good example.

> rado42@my-dejanews.com wrote:
[two preprocessor-based iterator loops, one using present language features
 and the other one more convenient, using the proposed "typeof" keyword]

In article <36531242.9E1747B9@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
> Hiding control constructs
[in a macro]
> is rarely a good thing to do. It makes it
> difficult to understand what the code is doing. I would have grave
> doubts about hiring someone who presented a code sample written this
> way.
[snip]
> This is simpler, more readable, and less error-prone, in large part
> because it's idiomatic, and all experienced STL programmers will
> recognize it:
>
> template<class II>
> void show(II begin, II end)
> {
> while (begin != end)
>    cout << *begin++;
> }
>
> Usage:
> show(my_list.begin(), my_list.end());
>
> And, unlike your macro, it works with C-style arrays:
>
> char a[] = "Hello, world!"
> show(a, a + sizeof(a));

First, you expressed "GRAVE DOUBTS" (emphasis mine) about
rado42's methods, and implied that he wasn't a good programmer.
Then you posted an alternative which you claimed was "simpler,
more readable, and LESS ERROR PRONE" (emphasis mine). Finally,
you posted an example usage which HAD AN ERROR.

i*rony n. Speech in which meaning is opposite of that actually
expressed [Source: Collins English Gem Dictionary, 1954]

In article <73ho51$dih$1@nnrp1.dejanews.com>,
  AllanW@my-dejanews.com replied:
> Actually that's either
>     show(a, a+strlen(a));
> or
>     show(a, a+sizeof(a)-1);
> unless you intend to write the null byte to cout for some reason.
> This is a common bug in production programs because it's usually
> invisible and therefore rarely tested for.

That's me pointing out the error. Not exactly biting criticism, is
it? I didn't say "you had an error and therefore your ideas are all
wrong." I didn't imply anything about your abilities in general.
I was DIPLOMATIC! All I did was explain what was wrong and give
some correct examples.

You are free to feel offended by this, of course. But I don't
think that would be reasonable.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[ Additional context restored -- AllanW ]

In article <73vfd3$8ob$1@nnrp1.dejanews.com>,
  AllanW@my-dejanews.com wrote:
>
> In article <366098A4.18B6B7D5@acm.org>,
>   Pete Becker <petebecker@acm.org> wrote:
> >
> > Siemel Naran wrote:
> > >
> > > No, I think in general it is a good idea to point out technical
> > > mistakes.  Of course, it does not detract from your original
> > > point.  But it's nice, just for completeness.  Especially if
> > > some beginner is reading this thread and takes us very literally.
> > > Because beginners, and sometimes even experts, learn by looking
> > > at specific, technical details and then graduating to the general
> > > concept.
> >
> > Then all the proposed "corrections" are also wrong, because it's not
> > legal to write expressions like that in global scope. And, of course,
> > nobody added a #include directive to get a definition of cout, and
> > nobody added a main function. I feel so sorry for all those beginners
> > out there, who are now thoroughly confused.
>
> By their second day in programming class, students understand what a
> code "snippet" is.

In article <6OJ7fNAAg9Y2Ew3D@robinton.demon.co.uk>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <73vfd3$8ob$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
> writes
> >By their second day in programming class, students understand what a
> >code "snippet" is.
> [with tone of deep sarcasm]
> But of course.  And from day 1 all students must write industrial
> strength code.

Was this line
> [with tone of deep sarcasm]
intended to explain your next two sentences? Or were you trying to
imply that my words were sarcastic?

Pete Becker's words [which you omitted] may or may not have been
sarcastic. My reply was not intended to be sarcastic at all. Please
re-read what Pete Becker posted, and then consider my words in that
light. What I wrote was a direct response to his comments.

> Those who read my book reviews know that I am very condemnatory of books
> for novices where code is of poor quality (unnnecessary globals,
> undefined behaviour etc.)

I believe that of you.

> but where the text is aimed at experienced
> programmers I do not want the idea hidden behind  a miasma of tchnical
> correctness.

This makes sense too.

But you wouldn't take either position to extremes, would you?
For instance, I suspect that you wouldn't disapprove of a book for
novices which had 2,000 examples, and only one of them had an error.
Or a book for experienced programmers in which every example
was also a working program, but the authors somehow made it
easy to spot the sections relevant to the topic being discussed.

> As always we should understand who we are writing for, and
> the discerning reader knows that.  It is when code appears to be written
> with care that the errors are most reprehensible because the novice may
> not notice the them.

I agree completely. Are you suggesting that the error I pointed
out should have been ignored, because some (let's say most) of
the readers in this newsgroup are experienced professionals?

Siemel Naran suggested that example code posted should be correct.
Not, I would have thought, a controversial stand!

Mr. Becker responded defensively by stating [probably sarcastically]
that by Siemel's standard all code snippets must be incorrect
"because it's not legal to write expressions like that in global
scope." As he continues to write about #include directives and the
main function, it's obvious what he alludes to: the program will not
compile on it's own. He doesn't use that word, of course, but that's
clearly what he's talking about.

But this is taking Siemel's idea to absurd lengths. So I responded
with absolutely no sarcasm, writing:
> By their second day in programming class, students understand what a
> code "snippet" is.

I'm being very literal, now. The first day of class it's important
to teach students what it means to enter and execute a program,
what a compiler does for them, and so on. Typically this is done
by giving each student a piece of paper with a complete program
on it, something like the typical "Hello world" program we see
so often.

By the second day of class, the instructor should be talking about
what the program elements do. Typically this is done by writing
each statement on the board and analyzing it token by token. The
instructor doesn't spend time explaining what a "snippet" is.
Instead, the students recognize the line, both from the memory of
the program that they typed in and from the handout which they
probably still have. As the teacher explains the statement, it
becomes obvious that the statement won't work by itself, but
only in conjunction with the rest of the program.

We do seem to have drifted off the topic. We're no longer talking
about the new "typeof" keyword, or even about an alternative to
one suggested use which might or might not be less error-prone.
Instead, we're talking about who said what about who and when...
If anyone truely feels that they are incapable of EVER making a
mistake, then I can at least understand what offended them.
Otherwise, we have pointless bickering. That cannot be productive.

If nothing else, I hope that I have convinced you that I was not
being sarcastic.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <366098A4.18B6B7D5@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
>
> Siemel Naran wrote:
> >
> > No, I think in general it is a good idea to point out technical
> > mistakes.  Of course, it does not detract from your original
> > point.  But it's nice, just for completeness.  Especially if
> > some beginner is reading this thread and takes us very literally.
> > Because beginners, and sometimes even experts, learn by looking
> > at specific, technical details and then graduating to the general
> > concept.
>
> Then all the proposed "corrections" are also wrong, because it's not
> legal to write expressions like that in global scope. And, of course,
> nobody added a #include directive to get a definition of cout, and
> nobody added a main function. I feel so sorry for all those beginners
> out there, who are now thoroughly confused.

By their second day in programming class, students understand what a
code "snippet" is.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I think that I might have missed some posts on this thread. I do
remember pointing out an error in the sample code. My point was
that the proposed "solution" was no less error-prone than it's
alternatives. Then I was gone for the Thanksgiving weekend, and
now I see quite a storm of activity.

Since I missed some posts, I'm not sure quite what started this
storm. In case it was me, please let me point out that I didn't
mean to offend ANYONE. If anyone took offense at anything that I
said, please point it out to me so that I can clarify myself and
properly apologize for creating a misunderstanding. (In case it
was NOT me, please excuse my assumption that all storms surround
me... ;-)

> Siemel Naran wrote:
> > No, I think in general it is a good idea to point out technical
> > mistakes.

In article <3661D026.A05AA4FA@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
> Maybe. On the other hand, your claim that this code has a "technical
> error" is not justified. It's possible to make this assertion:
>
>  Assuming that the code was not supposed to write the value '\0' to
>  cout, then the code has an error.

Speaking for myself, not for Siemel Naran:

Nicely phrased. I agree 100%.

> Now, of course, the question is, why did you make such an assumption
> without stating it explicitly?

Because writing '\0' to cout is only rarely useful, and is an
extremely common error. If I saw this in real code I would be very
likely to "fix" it (and yes, I would test it to be sure that my fix
didn't break anything). Or, conversely, if I was in a code review
and saw code like this which wrote the '\0' intentionally, I would
ask the programmer to add a comment to that effect.

> How do you know that the assumption is
> valid?

Since the example was theoretical, how do you know it wasn't?

When dealing with reasonable people (and I hope I can include
you in that category), I will assume common and reasonable usage
if possible, unless something else is pointed out in comments or
in the text.

> There certainly are cases in which it is appropriate to write the
> value '\0' to cout.

I would agree that writing '\0' to a stream file is unusual but not
rare. If a program expects it's output to be "piped" to another
program for further processing (or redirected to a file which will
be input to another program), then it might treat cout as "just
another output stream" and do this. But in this case the data
stream is no longer strictly printable. It might make more sense
to open the data stream explicitly.

For programs that do NOT assume that their output is redirected,
writing '\0' to the standard output is rare nowadays. I used to do
it when I used 110-baud teletypes, since a worst-case carriage-
return could take 2-3 character times to execute but CR-LF-NUL-NUL
was always safe. If you agree that such equipment is obsolete, then
there's really no remaining reason to write '\0' to standard output
unless we assume that we're not really talking to just the end user.
However, there IS reason to NOT write '\0' to standard output -- it
makes the output appear more slowly, and thus the program appears to
be slower.

In any case, the example was a tiny snippet of code which directed a
printable string plus the trailing '\0' to cout. We must rely on
surrounding text to establish content, or else assume quite common
and mundane requirements. Writing '\0' to standard output on purpose
is neither common nor mundane.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:

> In article <366098A4.18B6B7D5@acm.org>,
>   Pete Becker <petebecker@acm.org> wrote:

> > Siemel Naran wrote:

> > > No, I think in general it is a good idea to point out technical
> > > mistakes.  Of course, it does not detract from your original
> > > point.  But it's nice, just for completeness.  Especially if
> > > some beginner is reading this thread and takes us very literally.
> > > Because beginners, and sometimes even experts, learn by looking
> > > at specific, technical details and then graduating to the general
> > > concept.

> > Then all the proposed "corrections" are also wrong, because it's not
> > legal to write expressions like that in global scope. And, of course,
> > nobody added a #include directive to get a definition of cout, and
> > nobody added a main function. I feel so sorry for all those beginners
> > out there, who are now thoroughly confused.

> By their second day in programming class, students understand what a
> code "snippet" is.

Then you agree with me that it is not appropriate to "point out techical
mistakes" in order to protect beginners.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <73vfd3$8ob$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
writes
>By their second day in programming class, students understand what a
>code "snippet" is.
[with tone of deep sarcasm]
But of course.  And from day 1 all students must write industrial
strength code.


Those who read my book reviews know that I am very condemnatory of books
for novices where code is of poor quality (unnnecessary globals,
undefined behaviour etc.) but where the text is aimed at experienced
programmers I do not want the idea hidden behind  a miasma of tchnical
correctness.  As always we should understand who we are writing for, and
the discerning reader knows that.  It is when code appears to be written
with care that the errors are most reprehensible because the novice may
not notice the them.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
>
> > Now, of course, the question is, why did you make such an assumption
> > without stating it explicitly?
>
> Because writing '\0' to cout is only rarely useful, and is an
> extremely common error. If I saw this in real code I would be very
> likely to "fix" it (and yes, I would test it to be sure that my fix
> didn't break anything).

Before you fix it and test it, find out whether it was deliberate.
Testing should never be a substitute for design. That's my objection to
this thread: there have been assertions (not by you) that the code which
I posted was INCORRECT when in fact there was no basis for such an
absolute statement.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker wrote:

> Siemel Naran wrote:
....
> > No, I think in general it is a good idea to point out technical
> > mistakes.

> Maybe. On the other hand, your claim that this code has a "technical
> error" is not justified. It's possible to make this assertion:

>         Assuming that the code was not supposed to write the value '\0' to
>         cout, then the code has an error.

> Now, of course, the question is, why did you make such an assumption
> without stating it explicitly? How do you know that the assumption is
> valid? There certainly are cases in which it is appropriate to write the
> value '\0' to cout.

Allen's original comment was:
<73ho51$dih$1@nnrp1.dejanews.com>...
>> char a[] = "Hello, world!"
>> show(a, a + sizeof(a));
>
>Actually that's either
>    show(a, a+strlen(a));
>or
>    show(a, a+sizeof(a)-1);
>unless you intend to write the null byte to cout for some reason.

So the assumption, and it's possible inapplicability, were both made
very clear from the beginning. I never objected to your original
message; I objected only when someone incorrectly stated that Allen was
wrong.


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
>
> 'a' will be 14 characters long. sizeof(a) will be 14. a[13]=='\0'.
> a+sizeof(a) will point just after a[13]. show(), as written, stops when
> begin==end, which won't happen until after begin==a[13]. Thus, the
> terminating null will be printed.

And what's your point? The purpose of the example was to illustrate the
loss of expressive power when that for-loop macro was used instead of a
template function. I'm going to have to start adding a disclaimer: "code
snippets contained in this message are for illustrative purposes only,
and are not intended to be complete or portable."

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 26 Nov 98 16:50:46 GMT, Pete Becker <petebecker@acm.org> wrote:
>James Kuyper wrote:

>> 'a' will be 14 characters long. sizeof(a) will be 14. a[13]=='\0'.
>> a+sizeof(a) will point just after a[13]. show(), as written, stops when
>> begin==end, which won't happen until after begin==a[13]. Thus, the
>> terminating null will be printed.

>And what's your point? The purpose of the example was to illustrate the
>loss of expressive power when that for-loop macro was used instead of a
>template function. I'm going to have to start adding a disclaimer: "code
>snippets contained in this message are for illustrative purposes only,
>and are not intended to be complete or portable."

No, I think in general it is a good idea to point out technical
mistakes.  Of course, it does not detract from your original
point.  But it's nice, just for completeness.  Especially if
some beginner is reading this thread and takes us very literally.
Because beginners, and sometimes even experts, learn by looking
at specific, technical details and then graduating to the general
concept.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker wrote:

> James Kuyper wrote:
> >
> > 'a' will be 14 characters long. sizeof(a) will be 14. a[13]=='\0'.
> > a+sizeof(a) will point just after a[13]. show(), as written, stops when
> > begin==end, which won't happen until after begin==a[13]. Thus, the
> > terminating null will be printed.

> And what's your point? The purpose of the example was to illustrate the
> loss of expressive power when that for-loop macro was used instead of a
> template function. I'm going to have to start adding a disclaimer: "code
> snippets contained in this message are for illustrative purposes only,
> and are not intended to be complete or portable."

Allen pointed out the almost certainly unintentional 'feature' of
printing the terminating null character; Andrei claimed he was mistaken.
I might not have bothered pointing out the original error had I been the
one to notice it, but the erroneous faulting of the error report needed
a response.



[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:
>
> No, I think in general it is a good idea to point out technical
> mistakes.  Of course, it does not detract from your original
> point.  But it's nice, just for completeness.  Especially if
> some beginner is reading this thread and takes us very literally.
> Because beginners, and sometimes even experts, learn by looking
> at specific, technical details and then graduating to the general
> concept.

Then all the proposed "corrections" are also wrong, because it's not
legal to write expressions like that in global scope. And, of course,
nobody added a #include directive to get a definition of cout, and
nobody added a main function. I feel so sorry for all those beginners
out there, who are now thoroughly confused.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

sbnaran@localhost.localdomain.COM (Siemel Naran) wrote:
>No, I think in general it is a good idea to point out technical
>mistakes.  [...]  Especially if
>some beginner is reading this thread and takes us very literally.
>Because beginners, and sometimes even experts, learn by looking
>at specific, technical details and then graduating to the general
>concept.

Hear, hear! I rank myself somewhere between "beginner" and "expert", and
I agree that it is helpful when an error in posted code is pointed out.

I think the goal is that any code that is posted should be 100% correct
according to the standard. Everybody's human, so everyone will goof
occasionally. But I would hope that everyone would be glad to see
corrections or improvements to posted code, even their own.

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                      http://www.concentric.net/%7eBrownsta/
"I'm not even supposed to BE here!"  -- the mantra from /Clerks/
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Stan Brown wrote:

> sbnaran@localhost.localdomain.COM (Siemel Naran) wrote:
> >No, I think in general it is a good idea to point out technical
> >mistakes.  [...]  Especially if
> >some beginner is reading this thread and takes us very literally.
> >Because beginners, and sometimes even experts, learn by looking
> >at specific, technical details and then graduating to the general
> >concept.

> Hear, hear! I rank myself somewhere between "beginner" and "expert", and
> I agree that it is helpful when an error in posted code is pointed out.

> I think the goal is that any code that is posted should be 100% correct
> according to the standard. Everybody's human, so everyone will goof
> occasionally. But I would hope that everyone would be glad to see
> corrections or improvements to posted code, even their own.

Then every code example must have all necessary #include directives,
must be a complete function,
and must include at least a prototype for every function that it calls.
I have rarely seen such an example posted here, and I expect the
correctness police will be very busy enforcing this rule.

[ moderator's note: First, we'll have to hire some police. :-)
  -sdc ]

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:

> On 26 Nov 98 16:50:46 GMT, Pete Becker <petebecker@acm.org> wrote:
> >James Kuyper wrote:

> >> 'a' will be 14 characters long. sizeof(a) will be 14. a[13]=='\0'.
> >> a+sizeof(a) will point just after a[13]. show(), as written, stops when
> >> begin==end, which won't happen until after begin==a[13]. Thus, the
> >> terminating null will be printed.

> >And what's your point? The purpose of the example was to illustrate the
> >loss of expressive power when that for-loop macro was used instead of a
> >template function. I'm going to have to start adding a disclaimer: "code
> >snippets contained in this message are for illustrative purposes only,
> >and are not intended to be complete or portable."

> No, I think in general it is a good idea to point out technical
> mistakes.

Maybe. On the other hand, your claim that this code has a "technical
error" is not justified. It's possible to make this assertion:

 Assuming that the code was not supposed to write the value '\0' to
 cout, then the code has an error.

Now, of course, the question is, why did you make such an assumption
without stating it explicitly? How do you know that the assumption is
valid? There certainly are cases in which it is appropriate to write the
value '\0' to cout.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36531242.9E1747B9@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
> template<class II>
> void show(II begin, II end)
> {
> while (begin != end)
>    cout << *begin++;
> }
>
> Usage:
> show(my_list.begin(), my_list.end());
>
> And, unlike your macro, it works with C-style arrays:
>
> char a[] = "Hello, world!"
> show(a, a + sizeof(a));

Actually that's either
    show(a, a+strlen(a));
or
    show(a, a+sizeof(a)-1);
unless you intend to write the null byte to cout for some reason.
This is a common bug in production programs because it's usually
invisible and therefore rarely tested for.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote in message <73ho51$dih$1@nnrp1.dejanews.com>...
>> char a[] = "Hello, world!"
>> show(a, a + sizeof(a));
>
>Actually that's either
>    show(a, a+strlen(a));
>or
>    show(a, a+sizeof(a)-1);
>unless you intend to write the null byte to cout for some reason.
>This is a common bug in production programs because it's usually
>invisible and therefore rarely tested for.


I'm affraid not. Pete is right. The compiler will allocate at compile time
exactly 14 bytes for the null-terminated string. The show method does not
output the upper bound.
So the story with the "common bug in production code..." doesn't apply,
hehehehehehe! (Just kidding.)

Pete's code is a bit fragile, though. If later one changes the
implementation of a[] (from char to wchar_t and/or making a a pointer) the
compiler won't signal an error.

An idiom I've seen effective for fixed-size arrays is:

template <class T, size_t S>
inline lengthof(const T (&)[S])
{
    return S;
}

template <class T, size_t S>
inline endof(const T (&Array)[S])
{
    return Array + S;
}

Now you can write:

char a[] = "Bye bye, cruel world!"
show(a, endof(a));

If you later switch to another implementation than fixed-size arrays, you'll
have a compiler error in endof(). Ask me for a workaround for Visual C++ -
it's scary!

Andrei



[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> Pete Becker wrote in message <36531242.9E1747B9@acm.org>...
> >This is simpler, more readable, and less error-prone, in large part
> >because it's idiomatic, and all experienced STL programmers will
> >recognize it:
> >
> >template<class II>
> >void show(II begin, II end)
> >{
> >while (begin != end)
> >   cout << *begin++;
> >}

In article <365848c6.0@10.1.1.65>,
  "Andrei Alexandrescu" <alexandrescua@micromodeling.com> wrote:
> Pete,
>
> You're right, but also Radoslav has a point: you just cannot afford
> going out and make a small function for each loop you have. It's
> impractical and clutters the code.
>
> The problem is not the lack of typeof here, but the lack of lambda
> functions instead. Stepanov got all the nice things from Scheme in

The STL concept is that the number of "small functions" is finite.
(The number of "functions" may be infinite, but at some point we
stop calling them "small".) Therefore, some STL functor (or
combination of functors) is likely to satisfy most programming
needs. Naturally, if you find yourself writing some other small
function frequently, you can extend the list of available functors.

I haven't had enough experience with functors to decide for myself
if this is true. But if it is true, then there is no need for
lambda functions, which (IMHO) are likely to make C++ programs
slower and fatter, possibly even if we don't use them. (Because
we're talking about changing the function-call mechanism.)

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> In article <36531242.9E1747B9@acm.org>,
>   Pete Becker <petebecker@acm.org> wrote:
> > template<class II>
> > void show(II begin, II end)
> > {
> > while (begin != end)
> >    cout << *begin++;
> > }

Andrei Alexandrescu wrote:
>
> AllanW@my-dejanews.com wrote in message <73ho51$dih$1@nnrp1.dejanews.com>...
> >> char a[] = "Hello, world!"
> >> show(a, a + sizeof(a));
> >
> >Actually that's either
> >    show(a, a+strlen(a));
> >or
> >    show(a, a+sizeof(a)-1);
> >unless you intend to write the null byte to cout for some reason.
> >This is a common bug in production programs because it's usually
> >invisible and therefore rarely tested for.
>
> I'm affraid not. Pete is right. The compiler will allocate at compile time
> exactly 14 bytes for the null-terminated string. The show method does not
> output the upper bound.
> So the story with the "common bug in production code..." doesn't apply,
> hehehehehehe! (Just kidding.)

'a' will be 14 characters long. sizeof(a) will be 14. a[13]=='\0'.
a+sizeof(a) will point just after a[13]. show(), as written, stops when
begin==end, which won't happen until after begin==a[13]. Thus, the
terminating null will be printed.
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker wrote in message <365A3F8C.74F0B8C6@acm.org>...
>Andrei Alexandrescu wrote:
>>
>>
>> Pete,
>>
>> You're right, but also Radoslav has a point: you just cannot afford
>> going out and make a small function for each loop you have. It's
>> impractical and clutters the code.
>
>Sure you can. Instead of calling it a "loop" call it an "algorithm" if
>it makes you feel better. Most of the standard algorithms are fairly
>simple loops. Try it.



Pete,

I am curious on your take on the "lambda functions proposal" thread.

Andrei




[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

| The problem is not the lack of typeof here, but the lack of lambda
| functions instead. Stepanov got all the nice things from Scheme in
| C++. Look at "Structure and Interpretation of Computer Programs" - a
| great book. You'll find there that for_each, accumulate, iteration,
| and many nice things brought by STL were in Scheme since a long time
| ago.
|
| But because Scheme does have lambda functions, it's so much more
| expressive. I bet many have proposed lambda functions for C++ and I
| wonder what was the response to such proposals.

This is one thing Java got right.  They started with an idea inherited
from Modula-3.  In Modula-3, you can write a new-expression like:

 NEW(T OBJECT OVERRIDES m := P END)

m is a method; P is a procedure variable (i.e., a pointer to a function)
of the appropriate type.  This, on its face, gives you a T object in
which m() is actually implemented by P().  In fact, it's a short-hand:
What it really does is create a new, anonymous subclass of T in which
m's definition is now given by P, and creates an instance of it.

Java doesn't have procedure variables, so it couldn't use quite the same
syntax.  Instead, you have to write P's definition write in the new
expression.  Rather than being a minus, this is a big plus - it
effectively gives you lambda expressions.  In C++ terms, an analogous
syntax might be:

 new classname { overriding definitions }

You'd do something like this:

struct function
{ virtual double operator()(double) = 0;
};

double integrate(double low_bound,double high_bound), function* f);

...
 integrate(low,high,new function { double operator()(double x)
      { return x*x + 1;
      }
     });
...

The call would act as if had been written:

 struct UniqueNameAssignedByCompiler : public function
 { double operator double()(double x)
  { return x*x + 1; }
 };
 integrate(low,high,new UniqueNameAssignedByCompiler);

This gives you exactly the effect of lambda expressions in an OO style.
What Scheme gets by lexical binding within closures, you get here by
using instance variables.  Really quite pretty when used appropriately.

This style works fine in Modula-3 and Java, but unfortunately doesn't
translate well to C++.  There are all kinds of silly syntactic issues -
you'd probably have to write "public" in each overriding definition, it
should probably be "new function public { ...", inside integrate() you
have to write (*f)(arg) - but the really fundamental problem is:  Who
deletes the functional object?  The thing that makes this syntax nice is
that you don't ever have to assign a name to the functional object.  But
without that, you don't have a handle on what new returned so that you
can delete it!  In Modula-3 and Java - and Scheme, of course - this
isn't an issue, since they all have garbage collectors.  For C++, the
lack of GC makes it hard to come up with a convenient way to do this.

       -- Jerry


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrei wrote

>Speaking of typeof, I felt the need for it in higher-order functions.
>For instance, if I want to write a compose template class, I need the
>return type of a function/functor. Now I have to put it (redundantly)
>in the template parameter list. Had I had typeof, I could have said
>typeof(f()) and simplify things.

I. Good for getting type of template deduced classes, as your above
comment seems to suggest:

Consider this template class:

namespace myspace
{
template <class T, class U>
struct list
{
     typedef T car;
     typedef U cdr;
};
}

To generate a list at namespace scope we have to do

typedef
   myspace::list<long, myspace::list<int, myspace::list<short,void> > >
   mylist;

We can use this list in template template functions like this one:

template <template <class> class Predicate, class list>
struct find;

However, if we had function to generate a list of 1 elements:

template <class T>
list<T,void> generate_list(T t)
{
     return list<T,void>();
}

and a function to generate lists of N+1 elements

template <class List, class T>
list<T,List> operator<<(List,T)
{
     return list<T,List>();
}

then we could write this:

typedef typeof(generate_list(0short) << 0int << 0long) mylist;


But template classes with variable arguments would be still better:

typedef myspace::list<short,int,long> mylist;



II. Can get underlying type of enum!

enum World { w, o, r, l, d };
typedef typeof(w+d) World_utype;

It is good to know the underlying type so that we can implement
op+ properly.  A field enum::utype would be better though.  Eg,

World operator+(World lhs, World rhs)
{
     typedef World::utype utype;
     return World(utype(lhs)+utype(rhs));
}


III.  But ...

We remark that it is still a good idea to put the necessary typedefs
into our class definitions.  We'd rather the programmer say
   container_type::iterator iter=d_container.find("hello");
than
   typename(d_container.find("hello")).find("hello");
The first version is easier to type and easier to read.

For classes with lots of variables (especially in numerical work),
typedefing every single variable is not only a nuisance but also
distracting as it makes the code harder to read.  It would lead to
so much code clutter that it is better to use typeof should we
want to get at the type of one of the variables.


>Yes, I'd like to have typeof() at the next revision of the language.
>It can have good usage. But I'd like lambda functions much more.

Typeof seems good, but I think it might be misused.


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker wrote in message <36531242.9E1747B9@acm.org>...
>This is simpler, more readable, and less error-prone, in large part
>because it's idiomatic, and all experienced STL programmers will
>recognize it:
>
>template<class II>
>void show(II begin, II end)
>{
>while (begin != end)
>   cout << *begin++;
>}
>
>Usage:
>show(my_list.begin(), my_list.end());
>
>And, unlike your macro, it works with C-style arrays:
>
>char a[] = "Hello, world!"
>show(a, a + sizeof(a));

Pete,

You're right, but also Radoslav has a point: you just cannot afford
going out and make a small function for each loop you have. It's
impractical and clutters the code.

The problem is not the lack of typeof here, but the lack of lambda
functions instead. Stepanov got all the nice things from Scheme in
C++. Look at "Structure and Interpretation of Computer Programs" - a
great book. You'll find there that for_each, accumulate, iteration,
and many nice things brought by STL were in Scheme since a long time
ago.

But because Scheme does have lambda functions, it's so much more
expressive. I bet many have proposed lambda functions for C++ and I
wonder what was the response to such proposals.

Speaking of typeof, I felt the need for it in higher-order functions.
For instance, if I want to write a compose template class, I need the
return type of a function/functor. Now I have to put it (redundantly)
in the template parameter list. Had I had typeof, I could have said
typeof(f()) and simplify things.

Yes, I'd like to have typeof() at the next revision of the language.
It can have good usage. But I'd like lambda functions much more.

Andrei
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrei Alexandrescu wrote:
>
>
> Pete,
>
> You're right, but also Radoslav has a point: you just cannot afford
> going out and make a small function for each loop you have. It's
> impractical and clutters the code.

Sure you can. Instead of calling it a "loop" call it an "algorithm" if
it makes you feel better. Most of the standard algorithms are fairly
simple loops. Try it.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

rado42@my-dejanews.com wrote:
>
> Do you REALLY think that writing a template function for any loop definition
> is THAT convenient? An even if so, you cannot parametrize the templates by
> the contents of the loop body. You could use macros, of course, but even so
> 'typeof' would help to have simpler (and safer) one. E.G.:
>
> ( --------- Current situation --------- )
>
> #define STL_FOR(ContainerType, container, loop_var)            \
> for (ContainerType::iterator loop_var = container::begin();    \
>      loop_var != container.end();                              \
>      loop_var++)
>    // loop body shold follow here
>
> Usage:
> STL_FOR(list<int>, my_list, i)
>   cout << *i;
>
> (------- typeof present situation --------)
>
> #define STL_FOR(container, loop_var, body)                      \
> for (typeof(container)::iterator loop_var = container::begin(); \
>      loop_var != container.end();                               \
>      loop_var++)                                                \
>    // loop body shold follow here
>
> Usage:
> STL_FOR(my_list, i)
>   cout << *i

Hiding control constructs is rarely a good thing to do. It makes it
difficult to understand what the code is doing. I would have grave
doubts about hiring someone who presented a code sample written this
way.

>
> Which one is simpler? And which one should be changed if you replace
> list<> with vector<>?

This is simpler, more readable, and less error-prone, in large part
because it's idiomatic, and all experienced STL programmers will
recognize it:

template<class II>
void show(II begin, II end)
{
while (begin != end)
   cout << *begin++;
}

Usage:
show(my_list.begin(), my_list.end());

And, unlike your macro, it works with C-style arrays:

char a[] = "Hello, world!"
show(a, a + sizeof(a));

STL uses iterators and templates to support generic programming. Work
with that idiom long enough that you really understand it and appreciate
its power. Then, if you find things that cannot be conveniently
expressed with it, think about other possible approaches.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 18 Nov 1998 17:09:31 GMT, rado42@my-dejanews.com

>....and now imagine that Container does not have the typedef 'iterator'.
>There is a workaround with 'typeof', e.g.:
>
>for (typeof (c.my_begin()) i = c.my_begin(); i != c.my_end(); ++i)
>   ;

>How about it?

(1) If it is reasonable to assume that the container does not define
    a trait "iterator", it is then also reasonable to assume that it
    doesn't define the member function "my_begin".  So the statement
    "c.my_begin()" should fail template instantiation.  So we're
    screwed either way: if we write a template function f(T) that
    assumes that T has a trait "iterator", we might be screwed if
    T does not define this trait.  And if we assume that T has a
    function "my_begin", then we also might be screwed because T
    might not define this function.

(2) The typedef/traits method is more stringent in that it requires
    us to define both the expected traits/typedefs/nested-classes
    as well as the expected member functions.  In the above,
    container "C" would be required to define both a trait
    "iterator" as well as a member func "my_begin()".  This
    stringency is probably good for program design.

(3) Which do we write
       typeof(c.my_begin())
       typeof(c.my_end  ())
    It doesn't matter much, but from parallel structure we should
    write both or neither.  If we write "typeof(c.my_begin())" then
    "typeof(c.my_end())" feels left out.

(4) Having to write "c.my_begin()" twice in the above is a nuisance,
    but is still not such a big deal.  Imagine if you had a function
    that takes many arguments -- this would be a real pain to write
    out, especially if 'a' 'b' 'c' are themselves long to write out:
       typeof(c(a,b,c))

(5) It is still a good idea for us to define the appropriate traits
    in every class we write.  Common trait names are value_type,
    reference, const_reference, argument_type, result_type.  We can
    have many functions that return a single trait name.  It is a
    nuisance if we have many traits for sure and that's one reason
    why typeof may be a good idea.


>Not in this particular case when you profit from the presence of'typedefs' in
>both your and the container class. As I already mentioned before: if typedefs
>were present everywhere, there would have been a little need of 'typeof';
>you could simply use the typedefs instead.

Ok.

>OTOH, defining the typedefs themselves requires extra coding, causes name
>poluting, etc. Sometimes it might be avoided by using 'typeof's.
>
>There are also cases where you even cannot add the desired typedef (e.g. in
>third party code). For instance look at MFC.

Good points.  However, as the traits technique becomes more well known,
we should see classes developed with all the traits in mind.  Older
code didn't use traits as the traits didn't seem to accomplish anything.


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn753c1k.25p.sbnaran@localhost.localdomain>,
Siemel Naran <sbnaran@KILL.uiuc.edu> wrote:
>
>On 17 Nov 98 13:06:07 GMT, Hans Olsson
>
>>You forgot to mention the biggest advantage and is related to STL.
>>Consider the usual:
>>
>>for(list<int>::iterator i=l.begin();i!=l.end();++i)
>
>IMHO, this is not so useful.  Consider two ways this happens.  First
>in a template function.
>
>template <class Container>
>void f(Container& c)
>{
>     for (typename Container::iterator i=c.begin(); i!=c.end(); ++i) ;
>}
>
>OK, we have to use the 'typename' keyword, but this is no big deal.
>And besides, it has a cool color on my editor :).

Or make it a template depending on Iterator as suggested by another
reply (or even better: use the existing for_each-template).

In either case typeof is hardly useful for determining the types
of template-paramaters.

>The other way is when a container is a member of a class.  Eg,
>
>class Thing
>{
>     private:
>          typedef std::vector<int> container_type;
>          container_type d_container;
>
>     public:
>          typedef container_type::value_type value_type;
>          //typedef typeof(d_container)::value_type value_type;
>
>          Thing();
>          void insert(value_type);
>          bool exists(value_type) const;
>};
>
>bool Thing::exists(value_type x) const
>{
>     typedef container_type::const_iterator iter;
>     //typedef typeof(d_container)::const_iterator iter;
>     iter i=find(d_container.begin(),d_container.end(),x);
>     if (iter==d_container.end()) return false;
>     return true;
>}
>
>
>The typeof method doesn't save us much typing.

It would also save you the 'typedef std::vector<int> container_type'
(I don't know if this is a benefit or not).

I still believe that code using templated-containers is the one
most likely to benefit from 'typeof', and lobbying to make g++ accept
'typeof(d_container)::const_iterator' would be a logical first step
to test if this is true.
Note: g++ already accepts typeof(d_container.begin()).

As soon as one compiler accepts it we can determine if it really
save us much typing (or make the code better in other ways). If it is
useful we can try to get it included in future revisions of the standard.

Searching the web and usenet found lots of man-pages explaining
'typeof' in gcc, but few (if any) examples using it.
It could be that 'typeof' is something that looks cool but isn't
_that_ useful.

There are also so many obscure template-hacks I wouldn't be amazed
if someone figured out how to write typeof in standard C++.



--
// Home page  http://www.dna.lth.se/home/Hans_Olsson/
// Email To..Hans.Olsson@dna.lth.se [Please no junk e-mail]
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36517C3A.338930DD@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
>
> Hans Olsson wrote:
> >
> > You forgot to mention the biggest advantage and is related to STL.
> > Consider the usual:
> >
> > for(list<int>::iterator i=l.begin();i!=l.end();++i)
> >
> > Using typeof would result in:
> >
> > for(typeof(l)::iterator i=l.begin();i!=l.end();++i)
> >
> > Which looks better, and protects the code from knowing which
> > container you are using. Similarly for using find etc.
>
> Both of these are non-idiomatic for STL. The way to "fix" this
> particular problem is to write STL code the way it's supposed to be
> written:
>
> template<class Iter>
> void f(Iter begin, Iter end)
> {
> while(begin != end)
>  {
>  // ...
>  ++begin;
>  }
> }
>

Do you REALLY think that writing a template function for any loop definition
is THAT convenient? An even if so, you cannot parametrize the templates by
the contents of the loop body. You could use macros, of course, but even so
'typeof' would help to have simpler (and safer) one. E.G.:

( --------- Current situation --------- )

#define STL_FOR(ContainerType, container, loop_var)            \
for (ContainerType::iterator loop_var = container::begin();    \
     loop_var != container.end();                              \
     loop_var++)
   // loop body shold follow here

Usage:
STL_FOR(list<int>, my_list, i)
  cout << *i;

(------- typeof present situation --------)

#define STL_FOR(container, loop_var, body)                      \
for (typeof(container)::iterator loop_var = container::begin(); \
     loop_var != container.end();                               \
     loop_var++)                                                \
   // loop body shold follow here

Usage:
STL_FOR(my_list, i)
  cout << *i

Which one is simpler? And which one should be changed if you replace
list<> with vector<>?

-----------------

What I mean is the following: the type of thing is an always present and
potentially usefull information (and the compiler uses it for type checks).
It cannot be conveniently used by us, though, due to the lack of a proper
language construct. In some situations it is also a reason of redundant code.
Can you, for instance, supply anything else but the right container type in
the above example? Even if so (e.g. base classes/implicit casts/etc.), is it
not potentially dangerous?

As I think about it now, it could be that the presence of 'typeof' would
even extend the possibilities of working with templates. A 'typeof' example:

template <class T>
void f (T t)
{
typeof (t.field) xxx = t.field;
.....
}

In the present' situation, it requires, for instance:

class MyClass  // to be used as argument for template below
{
public:
typedef int FieldType;
FieldType field;
};


void f (T t)
{
T::FieldType xxx = t.field;
.....
}


My opinion: More code, less clear, less applicable, less managable...
Any comments?

Radoslav Getov

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <slrn753c1k.25p.sbnaran@localhost.localdomain>,
  sbnaran@KILL.uiuc.edu wrote:
>
> On 17 Nov 98 13:06:07 GMT, Hans Olsson
>
> >You forgot to mention the biggest advantage and is related to STL.
> >Consider the usual:
> >
> >for(list<int>::iterator i=l.begin();i!=l.end();++i)
>
> IMHO, this is not so useful.  Consider two ways this happens.  First
> in a template function.
>
> template <class Container>
> void f(Container& c)
> {
>      for (typename Container::iterator i=c.begin(); i!=c.end(); ++i) ;
> }
>
> OK, we have to use the 'typename' keyword, but this is no big deal.
> And besides, it has a cool color on my editor :).

....and now imagine that Container does not have the typedef 'iterator'.
There is a workaround with 'typeof', e.g.:

for (typeof (c.my_begin()) i = c.my_begin(); i != c.my_end(); ++i)
   ;

How about it?


>
> The other way is when a container is a member of a class.  Eg,
>
> class Thing
> {
>      private:
>           typedef std::vector<int> container_type;
>           container_type d_container;
>
>      public:
>           typedef container_type::value_type value_type;
>           //typedef typeof(d_container)::value_type value_type;
>
>           Thing();
>           void insert(value_type);
>           bool exists(value_type) const;
> };
>
> bool Thing::exists(value_type x) const
> {
>      typedef container_type::const_iterator iter;
>      //typedef typeof(d_container)::const_iterator iter;
>      iter i=find(d_container.begin(),d_container.end(),x);
>      if (iter==d_container.end()) return false;
>      return true;
> }
>
> The typeof method doesn't save us much typing.
>

Not in this particular case when you profit from the presence of'typedefs' in
both your and the container class. As I already mentioned before: if typedefs
were present everywhere, there would have been a little need of 'typeof';
you could simply use the typedefs instead.

OTOH, defining the typedefs themselves requires extra coding, causes name
poluting, etc. Sometimes it might be avoided by using 'typeof's.

There are also cases where you even cannot add the desired typedef (e.g. in
third party code). For instance look at MFC.


And besides, the 'typename' color on my editor is not that cool :).


Radoslav Getov

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <72e2dt$8q6$1@nnrp1.dejanews.com>,  <rado42@my-dejanews.com> wrote:
>
>Hi, std Gurus,
>
>From very long time I dreamed about the presence in both C++ and C of a
>special keyword (say, typeinfo) which would give the type of it's
>argument (don't mess it with typeid). It would allow writing such code:
>
>int j;         // Or whatever type
>...
>typeof (j) k;  // Declare variable which is of the same type as 'k'.
>
>As far as the compiler has knowledge about each object's type, it looks to
>me that it is perfectly implementable.
>
>What are the advantages of such keyword?

You forgot to mention the biggest advantage and is related to STL.
Consider the usual:

for(list<int>::iterator i=l.begin();i!=l.end();++i)

Using typeof would result in:

for(typeof(l)::iterator i=l.begin();i!=l.end();++i)

Which looks better, and protects the code from knowing which
container you are using. Similarly for using find etc.

Similar effects could be achieved in other ways
(directly writing 'l::iterator i=' or 'l.iterator i='),
but I believe that typeof would be better.

However, even though g++ has a typeof-construct typeof(l)::iterator
will not work in egcs-1.0.3.
--
// Home page  http://www.dna.lth.se/home/Hans_Olsson/
// Email To..Hans.Olsson@dna.lth.se [Please no junk e-mail]
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hans Olsson wrote:
>
> You forgot to mention the biggest advantage and is related to STL.
> Consider the usual:
>
> for(list<int>::iterator i=l.begin();i!=l.end();++i)
>
> Using typeof would result in:
>
> for(typeof(l)::iterator i=l.begin();i!=l.end();++i)
>
> Which looks better, and protects the code from knowing which
> container you are using. Similarly for using find etc.

Both of these are non-idiomatic for STL. The way to "fix" this
particular problem is to write STL code the way it's supposed to be
written:

template<class Iter>
void f(Iter begin, Iter end)
{
while(begin != end)
 {
 // ...
 ++begin;
 }
}

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 17 Nov 98 13:06:07 GMT, Hans Olsson

>You forgot to mention the biggest advantage and is related to STL.
>Consider the usual:
>
>for(list<int>::iterator i=l.begin();i!=l.end();++i)

IMHO, this is not so useful.  Consider two ways this happens.  First
in a template function.

template <class Container>
void f(Container& c)
{
     for (typename Container::iterator i=c.begin(); i!=c.end(); ++i) ;
}

OK, we have to use the 'typename' keyword, but this is no big deal.
And besides, it has a cool color on my editor :).


The other way is when a container is a member of a class.  Eg,

class Thing
{
     private:
          typedef std::vector<int> container_type;
          container_type d_container;

     public:
          typedef container_type::value_type value_type;
          //typedef typeof(d_container)::value_type value_type;

          Thing();
          void insert(value_type);
          bool exists(value_type) const;
};

bool Thing::exists(value_type x) const
{
     typedef container_type::const_iterator iter;
     //typedef typeof(d_container)::const_iterator iter;
     iter i=find(d_container.begin(),d_container.end(),x);
     if (iter==d_container.end()) return false;
     return true;
}


The typeof method doesn't save us much typing.


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi, std Gurus,

On 12 Nov 1998 18:04:31 GMT, rado42@my-dejanews.com

>(Again: I know that you might have 'typedef int T;' in which case you will
>only change the typedef. On the other hand, I read somewhere at least one
>sugestion to restrict usage of typedefs (which looks very stupid to me,
>but this is just another story)).

The use of typedefs is very nice in class definitions.  This is
mainly because the typedef is localized to the class.  The typedef
should be private so that clients know as little as possible about
the implementation.

template <class T>
class matrix
{
     typedef std::vector<T> matrix_type;

     public:
          typedef matrix_type::value_type       value_type     ;
          typedef matrix_type::reference        reference      ;
          typedef matrix_type::const_reference  const_reference;
          typedef matrix_type::size_type        size_type      ;

     // stuff
};


>I know that template functions and classes solve such problems at big extend,
>as far as you can refer to the template's argument (if it was a type). And
>there are always workarounds (as shown above). Anyway, the presense of
>'typeof' would be just another possibility: I personally would use it.

'typeof' seems like a harmless extension.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]