Happy New Year!

[Ioannis Vranos]

Thus Victor is right, however since #include <ostream> together with
<iostream> all the time is tiring, I will include it whenever I get
errors.

However on second thought we should stick with correct coding, and thus
I will be including <ostream> whenever I use endl.

 

[Mike Wahler]

Right. There are two issues here. One is about the conformance of
a C++ implementation that accepts

#include <iostream>
int main() {
std::cout << std::endl;
}

and, apparently, it's OK if including <iostream> causes the inclusion
of <ostream> which makes 'std::endl' hence defined. I.e. if such
an implementation does not complain, it is still a conforming one.

Yes, the implementation can be conforming, that code can be
considered 'well formed', by such an implementation, but the
above code is not portable.

I think perhaps this issue of 'portability' should be more
thoroughly treated by the standard. (The standard contains
exactly one instance of the word 'portable', in the section

The other issue is whether the code is standard.

In the standard I saw no concept of 'standard code', 'standard
conforming code', etc. Only 'well formed program'.

And I think (and you
seem to agree) that it isn't [necessarily] because implementations
are not required to include <ostream> into <iostream> thus making it
_possible_ to have both operator<< and std::endl _undefined_ here.
IOW, an implementation that says that the above code is ill-formed due
to the fact that operator<< and std::endl are undefined is also
a conforming one.

Yes, I agree.

My position is to make a differentiation between a conforming C++
implementation and a _strictly_ conforming implementation. But that
is probably just wishful thinking on my part...

Yes, I think it is. I just now did several searches on 14882 for
one of my replies to Rolf, and there is no concept of "strictly
conforming" described at all. Only "conforming implementation". Most
notably, there's no "conforming program" described. See my reply
for more details if interested.

I think because of all that, we should probably take "conforming"
to mean "strictly conforming", i.e. the implementation conforms
or it does not. No 'levels of conformance', 'partial conformance',
etc.

Happy new[] Years.

-Mike

 

[Rolf Magnus]

Yes, it does seem 'natural', and is the strategy used by
many implementations. But the point is, this strategy is
*not* required, thus the programmer should not depend upon
it (unless he doesn't care about portability).

I wasn't saying anything about what the programmer should do, but only about
the fact that a conforming implemenation is allowed to accept the code
without <ostream> being included explicitly, in reply to Victor's claim:
"a strictly conforming implementation has to complain about 'endl' being
undefined".
I just wanted to clarify that neither there is such a thing as a "strictly
conforming implemenation", nor is an implemenation required to complain.

Actually, the term "strictly conforming" does not appear in
the standard at all. Nor does the word "strictly".

In the 1998 version, the word "strictly" does appear, though in other
context.

The term used is "well formed C++ program".
However there is one reference to a "conforming C program" (18.7/5):

Yes, I was confusing it with the C standard, which does define the two terms
"conforming program" and "strictly conforming program".

 

[Mike Wahler]

I have to admit that strictly speaking Victor is right. An
implementation may use some exotic third implementation headers in the
style:

ostream1.h containing the definition of ostream and its operators.

ostream2.h containing the definition of endl!


// <ostream>

#include <ostream1.h>
#include <ostream2.h>
// ...



// <iostream>
#include <ostream1.h>
// ...


and thus omit endl definition in <iostream>. Or there may be no headers
at all, and those #includes to act as compiler switches and <iostream>
"switch" to not activate endl.


Thus Victor is right, however since #include <ostream> together with
<iostream> all the time is tiring,

I find that hard to believe.

Write the <iostream> line.

Copy amd paste it to another line.
Delete one character. (typically
about three or four keystrokes).

I will include it whenever I get
errors.

I include it whenever I refer to what it declares, and
want my code to be portable.

-Mike

 

[Mike Wahler]

However on second thought we should stick with correct coding, and thus
I will be including <ostream> whenever I use endl.

Great. Now I feel all warm and fuzzy inside.

-Mike

 

[Rolf Magnus]

I find that hard to believe.

Write the <iostream> line.

Copy amd paste it to another line.
Delete one character. (typically
about three or four keystrokes).

Including moving the cursor to the character to be deleted?
Maybe I'll write a script for my editor that - whenever I dare to #include
<iostream> - automatically adds an #include <ostream> after it.

 

[Mike Wahler]

Including moving the cursor to the character to be deleted?

Well, that might add a couple more, but with my GUI
system, it's just a mouse click. Anyway, even if one
needs to type it out completely, I don't think "too
much typing" is a valid objection. It's only one,
very short line.

Maybe I'll write a script for my editor that - whenever I dare to #include
<iostream> - automatically adds an #include <ostream> after it.

But <ostream> is not always needed (but of course it won't
harm anything to always #include it).


-Mike