Happy New Year!

M

Mike Wahler

KPB said:
Someone wondered if using the -Wall switch in gcc would generate a
warning. I told him no after trying it out. I knew it would'nt but there
was no harm in making sure.

That question and answer are not topical for comp.lang.c++.
Still don't think so? Ok, whatever.

Perhaps I did. But the context of clc++ here is C++, not gcc
or any other particular implementation.
I read other people's code all the time.

All the more reason to know at least most of the language rules.
I have Stroustrup's book if I need to deal with anything like this.

Yes, a reference book is often needed, but I find it faster to
peruse code if I already have a good grasp of the rules, and
only go to the books for 'arcana'.
This
is just one thing that isn't important for me to remember because:

1. I don't see it enough in code to have to

See what? Definitions of objects?
2. Like I said.. I have reference materials if I do.

I have many reference materials too (including ISO 14882).

But sure, use whatever works for you. I find that a good
grasp of the rules makes the work go much more quickly.


-Mike
 
K

KPB

Mike said:
That question and answer are not topical for comp.lang.c++.


I was just joking with the guy. I see no reason to get into a pissing
contest over this.
Perhaps I did. But the context of clc++ here is C++, not gcc
or any other particular implementation.

Ok boss.




All the more reason to know at least most of the language rules.

I don't need a lecture about this. I make my living doing writing,
reading, debugging, bitching at C++ just like many others here do.

Have a happy new year.

KPB
 
D

David Harmon

On Fri, 31 Dec 2004 22:36:38 +0200 in comp.lang.c++, Ioannis Vranos
It is redundant, however I do not think it is wasteful. :)

It is a very tiny thing, but it is still spending CPU cycles for no
benefit.
 
V

Victor Bazarov

Ioannis Vranos said:
I just checked the 2003 standard about endl. In all examples where it is
used, no <ostream> is included.

Examples are not normative part of the Standard.
 
E

E. Robert Tisdale

David said:
Jon Wilson wrote,



The compiler may give any warning it wants,
but it shouldn't for that. main() has a special exemption
and is allowed to have no return statement.

The output line should be
cout<<"Best wishes for a Great Happy New Year to all!\n";

It is useless and wasteful to use endl to flush the stream,
immediately before the program is going to end and flush it anyway.

Thank you.

I was looking for the perfect example
of anal retentuve behavior. ;-)
 
I

Ioannis Vranos

Victor said:
Examples are not normative part of the Standard.


I do not know what you say, but I consider anything in the Standard as
standard compliant. Otherwise we are talking about defects, however I do
not think this is the case here.


After all, cout is an *ostream* object.



Check this:

http://www.cplusplus.com/ref/iostream/ostream



Also check this:

http://www.cplusplus.com/ref/iostream/ostream/operatorltlt.html


The operator << of ostream is used when we use cout.operator<<, etc.


All these mean that ostream is included in <iostream>.


And finally:

http://www.cplusplus.com/ref/iostream/ostream/_endl.html


I just discovered we could use endl this way!
 
R

Rob Williscroft

Ioannis Vranos wrote in in comp.lang.c++:
I do not know what you say, but I consider anything in the Standard as
standard compliant. Otherwise we are talking about defects, however I
do not think this is the case here.

The Standard is itself writen to a Standard. If you go to section 1
and then back 3 pages you find:

International Standards are drafted in accordance with the rules
given in the ISO/IEC Directives, Part 2.


Examples and Notes add /illustration/ to what the *normative* text
says, but it is what the text says that is important.


If you think about it this is just common sense:

- If a piece of text says on thing and an example or note contradicts,
or appears to contradict it, which should be taken as gosspel ?

Common sense (and the Standard by which the C++ Standard is writen
by) says the text, as it (logicaly) comes first.

- If every example was required to be authorative then the examples
would grow out of proportion to the text that they illustrate.

Examples would in some cases fail to illustrate anything as they
would be full of so mutch cruft [1], as too leave the reader
befuddled [2] as to what the point of the example actually is.

IOW an example illustrating point (A) shouldn't (unnessaseraly)
also illustrate points (B) through (Z) as (this being a standard)
points (B) though (Z) are described (and possibly illustrated)
elswhere.


[1] http://www.cruftbox.com/cruft/docs/cruftdef.html
[2] http://www.hyperdictionary.com/dictionary/befuddled


To understand what a programmer needs to do inorder to use std::endl,
it nessasery to read the text that describes where it is declared,
After all, cout is an *ostream* object.

class A;

extern A b;

b is an *A* object, this doesn't mean we can use it (other than
to take its address).

namespace std
{
template < typename Ch > class char_traits;

template < typename Ch, typename Tr = char_traits< Ch > >
class basic_ostream;

typedef basic_ostream< char > ostream;

extern ostream cout;

} /* std:: */

Rob.
 
R

Rolf Magnus

Victor said:
Actually that's not a problem (see other replies). However, a strictly
conforming implementation has to complain about 'endl' being undefined.

No, it doesn't have to. A standard header is allowed to include other
standard headers.
 
V

Victor Bazarov

Rolf Magnus said:
No, it doesn't have to. A standard header is allowed to include other
standard headers.

Yes, a standard header is allowed to include other headers, but is not
required to. So, for a program to be truly compliant, all the headers
where objects used are declared need to be included.

So, a conforming implementation could include everything under the sun
into <iostream> (and any other header), but such program wouldn't be
portable, would it? Any other conforming implementation might not have
all the headers included into <iostream>. So, a _strictly_ conforming
implementation should _not_ include other headers, leaving it to the
programmer. That's IMO, anyway.

V
 
R

Rolf Magnus

Victor said:
Yes, a standard header is allowed to include other headers, but is not
required to. So, for a program to be truly compliant, all the headers
where objects used are declared need to be included.

So, a conforming implementation could include everything under the sun
into <iostream> (and any other header), but such program wouldn't be
portable, would it? Any other conforming implementation might not have
all the headers included into <iostream>. So, a _strictly_ conforming
implementation should _not_ include other headers, leaving it to the
programmer. That's IMO, anyway.

However, since std::eek:stream is defined in <ostream> and std::iosream is
defined in <iostream> and derived from that class, it just seems natural
that <iostream> includes <ostream>.
And AFAIK, the term "strictly conforming" is only defined for programs, not
for implementations.
 
M

Mike Wahler

Victor Bazarov said:
Yes, a standard header is allowed to include other headers, but is not
required to. So, for a program to be truly compliant, all the headers
where objects used are declared need to be included.

So, a conforming implementation could include everything under the sun
into <iostream> (and any other header), but such program wouldn't be
portable, would it? Any other conforming implementation might not have
all the headers included into <iostream>. So, a _strictly_ conforming
implementation should _not_ include other headers, leaving it to the
programmer. That's IMO, anyway.

This issue was discussed at length here (or perhaps it was
in a.c.l.c-c++, I'm not sure) recently. I don't think
it resulted in a consenus. But my position on this seems to
agree with yours. I.e. if I #include <ostream> I *know* I
can portably refer to 'endl'. If I don't, I have no such
guarantee (by the language), regardless of the behavior of
a particular implementation(s).


-Mike
 
V

Victor Bazarov

Mike Wahler said:
This issue was discussed at length here (or perhaps it was
in a.c.l.c-c++, I'm not sure) recently. I don't think
it resulted in a consenus. But my position on this seems to
agree with yours. I.e. if I #include <ostream> I *know* I
can portably refer to 'endl'. If I don't, I have no such
guarantee (by the language), regardless of the behavior of
a particular implementation(s).

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.

The other issue is whether the code is standard. 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.

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...

Victor
 
V

Victor Bazarov

Rolf Magnus said:
However, since std::eek:stream is defined in <ostream> and std::iosream is
defined in <iostream> and derived from that class, it just seems natural
that <iostream> includes <ostream>.
And AFAIK, the term "strictly conforming" is only defined for programs,
not
for implementations.

I am not going to argue any longer about this, Rolf. Natural or not, there
is an apparent discrepancy in the Standard, which may be eventually
resolved.
It may just as well never be resolved because it doesn't seem to cause
anybody any harm. So, let's just forget about it. I promise to never bring
it up again.

V
 
M

Mike Wahler

Rolf Magnus said:
However, since std::eek:stream is defined in <ostream> and std::iosream is
defined in <iostream> and derived from that class, it just seems natural
that <iostream> includes <ostream>.

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).
strict padding requirements
strict weak ordering
strict ownership
And AFAIK, the term "strictly conforming" is only defined for programs, not
for implementations.

Actually, the term "strictly conforming" does not appear in
the standard at all. Nor does the word "strictly". The word
"strict" only appears when describing or referring to:
- strict padding requirements
- strict weak ordering
- strict ownership

Nowhere in the standard are the terms:
- "strictly conforming program"
- "conforming program"
- "strictly conforming C++ program"
- "conforming C++ program"

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

"The common subset of the C and C++ languages consists of all
declarations, definitions, and expressions that may appear in
a well formed C++ program and also in a conforming C program."

17.4.4 has the title "Conforming implementations",
and contains about two pages describing the rules. Also, the
term "conforming implementation" is used throughout the standard.


So there. :)

-Mike
 
I

Ioannis Vranos

Rolf said:
However, since std::eek:stream is defined in <ostream> and std::iosream is
defined in <iostream> and derived from that class, it just seems natural
that <iostream> includes <ostream>.
And AFAIK, the term "strictly conforming" is only defined for programs, not
for implementations.


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 will include it whenever I get
errors. :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top