Happy New Year!

[Ioannis Vranos]

#include <iostream>
int main()
{
using namespace std;

cout<<"Best wishes for a Great Happy New Year to all!"<<endl;
}

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Jon Wilson]

Ioannis Vranos wrote:

#include <iostream>
int main()
{
using namespace std;

cout<<"Best wishes for a Great Happy New Year to all!"<<endl;
}

This should give a compiler warning. You declare int main(), but have
no return statement.

[Jonathan Mcdougall]

Jon Wilson wrote:

Ioannis Vranos wrote:

#include <iostream>
int main()
{
using namespace std;

cout<<"Best wishes for a Great Happy New Year to all!"<<endl;
}

This should give a compiler warning. You declare int main(), but have
no return statement.

Not on a conforming compiler.
Jonathan

[Mike Wahler]

"Jon Wilson" <js*@fnal.gov> wrote in message
news:YJeBd.667039$D%.153030@attbi_s51...

Ioannis Vranos wrote:

#include <iostream>
int main()
{
using namespace std;

cout<<"Best wishes for a Great Happy New Year to all!"<<endl;
}

This should give a compiler warning. You declare int main(), but have
no return statement.

No return statement is required. When it is not specified,
the program performs an implicit 'return 0'. This is the case
only for the 'main()' function.

-Mike

[Florian Quetting]

gcc without options wouldn't give a warning, but what about -Wall?

Jonathan Mcdougall wrote:

Jon Wilson wrote:

Ioannis Vranos wrote:

#include <iostream>
int main()
{
using namespace std;

cout<<"Best wishes for a Great Happy New Year to all!"<<endl;
}

This should give a compiler warning. You declare int main(), but have
no return statement.

Not on a conforming compiler.
Jonathan

[KPB]

Florian Quetting wrote:

gcc without options wouldn't give a warning, but what about -Wall?

No. As others have said, the return statement is not needed.

This was one of those weird facts that I didn't know about until
recently. I just include the return statement without thinking about it.
I think I read this fact in one of the Josuttis books.

Also, I did try out the -Wall just to make sure.

To me, this is similar to the variable initialization issue. Some are
init'd implicitly (if you don't initialize them explicitly) and some
aren't. I just explicitly initialize everything then I don't have to
remember which are and which aren't.

KPB

[Victor Bazarov]

"Jon Wilson" <js*@fnal.gov> wrote...

Ioannis Vranos wrote:

#include <iostream>
int main()
{
using namespace std;

cout<<"Best wishes for a Great Happy New Year to all!"<<endl;
}

This should give a compiler warning. You declare int main(), but have no
return statement.

Actually that's not a problem (see other replies). However, a strictly
conforming implementation has to complain about 'endl' being undefined.
To find it, include <ostream> as well.

Happy New Year!

Victor

[David Harmon]

On Fri, 31 Dec 2004 16:02:00 GMT in comp.lang.c++, Jon Wilson
<js*@fnal.gov> wrote,

Ioannis Vranos wrote:

#include <iostream>
int main()
{
using namespace std;

cout<<"Best wishes for a Great Happy New Year to all!"<<endl;
}

This should give a compiler warning. You declare int main(), but have
no return statement.

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.

[Mike Wahler]

"KPB" <[e-mail]> wrote in message news:3x**************@fe11.lga...

Florian Quetting wrote:

gcc without options wouldn't give a warning, but what about -Wall?
No. As others have said, the return statement is not needed.

Correct (this only applies to 'main()'

This was one of those weird facts that I didn't know about until
recently. I just include the return statement without thinking about it.
Actually, I and others feel that this constitutes 'good
practice' anyway. But it is incorrect to state that
omitting it is invalid.
I think I read this fact in one of the Josuttis books.
It's also cited in many others.

Also, I did try out the -Wall just to make sure.
That's the wrong way to determine how the language should
work.

To me, this is similar to the variable initialization issue. Some are
init'd implicitly (if you don't initialize them explicitly) and some
aren't. I just explicitly initialize everything then I don't have to
remember which are and which aren't.

Aa matter of 'habit', I will usually initialize every
object I define, regardless of its storage duration.
But the issue of which objects are automatically
initialized and which are not is straightforward:

1) Static storage duration objects are automatically default initialized.
2) Objects with any other storage duration are not automatically
initialized.
3) ("Special case") If one or more of an array's elements are explicitly
initialized, any elements for which there are no corresponding
initializers
are default inititalized.
-Mike

[adbarnet]

...and - without some kind of <stdheader> include the compiler doesn't know
anything about the namespace 'std' in any case - so the using statement
should blow!

Indeed - Happy New Year!
"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:2JgBd.667542$D%.148039@attbi_s51...

"Jon Wilson" <js*@fnal.gov> wrote...

Ioannis Vranos wrote:

#include <iostream>
int main()
{
using namespace std;

cout<<"Best wishes for a Great Happy New Year to all!"<<endl;
}

This should give a compiler warning. You declare int main(), but have no
return statement.

Actually that's not a problem (see other replies). However, a strictly
conforming implementation has to complain about 'endl' being undefined.
To find it, include <ostream> as well.

Happy New Year!

Victor

[Ioannis Vranos]

Victor Bazarov wrote:

Actually that's not a problem (see other replies). However, a strictly
conforming implementation has to complain about 'endl' being undefined.
To find it, include <ostream> as well.

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


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[KPB]

Mike Wahler wrote:

"KPB" <[e-mail]> wrote in message news:3x**************@fe11.lga...

Florian Quetting wrote:

gcc without options wouldn't give a warning, but what about -Wall?
No. As others have said, the return statement is not needed.

Correct (this only applies to 'main()'

Yes. That's what we're talking about here, right?

This was one of those weird facts that I didn't know about until
recently. I just include the return statement without thinking about it.

Actually, I and others feel that this constitutes 'good
practice' anyway. But it is incorrect to state that
omitting it is invalid.

Where did I state that it was incorrect to omit this?

I think I read this fact in one of the Josuttis books.

It's also cited in many others.

Ok. I'm just telling you where I found it.

Also, I did try out the -Wall just to make sure.

That's the wrong way to determine how the language should
work.

Yes but it answered a question from a previous poster. You took this out
of context as you seem to have done to the rest of my post.

To me, this is similar to the variable initialization issue. Some are
init'd implicitly (if you don't initialize them explicitly) and some
aren't. I just explicitly initialize everything then I don't have to
remember which are and which aren't.

Aa matter of 'habit', I will usually initialize every
object I define, regardless of its storage duration.
But the issue of which objects are automatically
initialized and which are not is straightforward:

1) Static storage duration objects are automatically default initialized.
2) Objects with any other storage duration are not automatically
initialized.
3) ("Special case") If one or more of an array's elements are explicitly
initialized, any elements for which there are no corresponding
initializers
are default inititalized.

Ok. You remember your rules and I'll just keep initializing everything.

KPB

[Ioannis Vranos]

David Harmon wrote:

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.

It is redundant, however I do not think it is wasteful. :-)


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Mike Wahler]

"KPB" <[e-mail]> wrote in message news:SU***************@fe11.lga...

Mike Wahler wrote:

"KPB" <[e-mail]> wrote in message news:3x**************@fe11.lga...

Florian Quetting wrote:

gcc without options wouldn't give a warning, but what about -Wall?

No. As others have said, the return statement is not needed.

Correct (this only applies to 'main()'

Yes. That's what we're talking about here, right?

This was one of those weird facts that I didn't know about until
recently. I just include the return statement without thinking about it.

Actually, I and others feel that this constitutes 'good
practice' anyway. But it is incorrect to state that
omitting it is invalid.

Where did I state that it was incorrect to omit this?

I think I read this fact in one of the Josuttis books.

It's also cited in many others.

Ok. I'm just telling you where I found it.

Also, I did try out the -Wall just to make sure.

That's the wrong way to determine how the language should
work.

Yes but it answered a question from a previous poster.

Which question?
You took this out
of context as you seem to have done to the rest of my post.
I don't think so. Whatever.

To me, this is similar to the variable initialization issue. Some are
init'd implicitly (if you don't initialize them explicitly) and some
aren't. I just explicitly initialize everything then I don't have to
remember which are and which aren't.

Aa matter of 'habit', I will usually initialize every
object I define, regardless of its storage duration.
But the issue of which objects are automatically
initialized and which are not is straightforward:

1) Static storage duration objects are automatically default initialized. 2) Objects with any other storage duration are not automatically
initialized.
3) ("Special case") If one or more of an array's elements are explicitly
initialized, any elements for which there are no corresponding
initializers
are default inititalized.

Ok. You remember your rules and I'll just keep initializing everything.

I also usually initialize everything. But imo it is good to
know the rules, especially when reading others' code.

-Mike

[Mike Wahler]

"adbarnet" <ad******@barnet.com> wrote in message
news:41**********@127.0.0.1...

..and - without some kind of <stdheader> include the compiler doesn't know
anything about the namespace 'std' in any case
But the code did #include a standard header -- <iostream>,
so namespace 'std' is indeed accessible.
- so the using statement
should blow!

It's fine.

BTW please do not top-post.

-Mike

[Ioannis Vranos]

Jon Wilson wrote:

#include <iostream>
int main()
{
using namespace std;

cout<<"Best wishes for a Great Happy New Year to all!"<<endl;
}

This should give a compiler warning. You declare int main(), but have
no return statement.

As others said, this is valid code, and thus no warning should be provided.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[KPB]

Mike Wahler wrote:

"KPB" <[e-mail]> wrote in message news:SU***************@fe11.lga...

Mike Wahler wrote:

"KPB" <[e-mail]> wrote in message news:3x**************@fe11.lga...
Florian Quetting wrote:
>gcc without options wouldn't give a warning, but what about -Wall?

No. As others have said, the return statement is not needed.
Correct (this only applies to 'main()'
Yes. That's what we're talking about here, right?

This was one of those weird facts that I didn't know about until
recently. I just include the return statement without thinking about it.
Actually, I and others feel that this constitutes 'good
practice' anyway. But it is incorrect to state that
omitting it is invalid.

Where did I state that it was incorrect to omit this?

I think I read this fact in one of the Josuttis books.
It's also cited in many others.

Ok. I'm just telling you where I found it.

Also, I did try out the -Wall just to make sure.
That's the wrong way to determine how the language should
work.

Yes but it answered a question from a previous poster.

Which question?

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.

You took this out
of context as you seem to have done to the rest of my post.

I don't think so. Whatever.

Still don't think so? Ok, whatever.

To me, this is similar to the variable initialization issue. Some are
init'd implicitly (if you don't initialize them explicitly) and some
aren't. I just explicitly initialize everything then I don't have to
remember which are and which aren't.
Aa matter of 'habit', I will usually initialize every
object I define, regardless of its storage duration.
But the issue of which objects are automatically
initialized and which are not is straightforward:

1) Static storage duration objects are automatically default
initialized.
2) Objects with any other storage duration are not automatically
initialized.
3) ("Special case") If one or more of an array's elements are explicitly
initialized, any elements for which there are no corresponding
initializers
are default inititalized.

Ok. You remember your rules and I'll just keep initializing everything.

I also usually initialize everything. But imo it is good to
know the rules, especially when reading others' code.

-Mike

I read other people's code all the time.

I have Stroustrup's book if I need to deal with anything like this. 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
2. Like I said.. I have reference materials if I do.

KPB

[Ioannis Vranos]

KPB wrote:

This was one of those weird facts that I didn't know about until
recently. I just include the return statement without thinking about it.
I think I read this fact in one of the Josuttis books.

As I had read in some newsgroup, this implicit return 0; statement has
its roots in K&R 2.

In K&R2 the programs were in the style:
main()
{
/* ... */
}
which was not a valid C90 code anyway, but Kernighan used this style.

The C90 valid code was
// But not valid C++ and C99.
main()
{
/* ... */

return 0;
}
or
int main()
{
/* ... */

return 0;
}
Someday (probably in the C99 committee) one suggested, wouldn't it be
nice K&R 2 programs to become valid C99 programs?

Everyone agreed, making the return 0; implicit if no return statement is
provided.
However later, they decided that return types should be explicitly
provided (while in C90 const x; was equivalent to const int x; for
example), and thus we are today with int main() and no return statement
in both C99 and C++98.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Mike Wahler]

"KPB" <[e-mail]> wrote in message news:va***************@fe11.lga...

Mike Wahler wrote:

>Also, I did try out the -Wall just to make sure.
That's the wrong way to determine how the language should
work.

Yes but it answered a question from a previous poster.

Which question?

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

You took this out
of context as you seem to have done to the rest of my post.

I don't think so. Whatever.

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.

>To me, this is similar to the variable initialization issue. Some are
>init'd implicitly (if you don't initialize them explicitly) and some
>aren't. I just explicitly initialize everything then I don't have to
>remember which are and which aren't.
Aa matter of 'habit', I will usually initialize every
object I define, regardless of its storage duration.
But the issue of which objects are automatically
initialized and which are not is straightforward:

1) Static storage duration objects are automatically default
initialized.

2) Objects with any other storage duration are not automatically
initialized.
3) ("Special case") If one or more of an array's elements are explicitly initialized, any elements for which there are no corresponding
initializers
are default inititalized.

Ok. You remember your rules and I'll just keep initializing everything.

I also usually initialize everything. But imo it is good to
know the rules, especially when reading others' code.

-Mike

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

[KPB]

Ioannis Vranos wrote:

KPB wrote:

This was one of those weird facts that I didn't know about until
recently. I just include the return statement without thinking about
it. I think I read this fact in one of the Josuttis books.

As I had read in some newsgroup, this implicit return 0; statement has
its roots in K&R 2.

In K&R2 the programs were in the style:
main()
{
/* ... */
}
which was not a valid C90 code anyway, but Kernighan used this style.

The C90 valid code was
// But not valid C++ and C99.
main()
{
/* ... */

return 0;
}

Yes, I've seen these in some old C code and even some old C++ code
(old.. bad... code.. that I've corrected).

I've also seen the void main(). Have you?

Thanks,
KPB

[KPB]

Mike Wahler wrote:

"KPB" <[e-mail]> wrote in message news:va***************@fe11.lga...

Mike Wahler wrote:

>>Also, I did try out the -Wall just to make sure.
>
>
>That's the wrong way to determine how the language should
>work.

Yes but it answered a question from a previous poster.
Which question?

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

I was just joking with the guy. I see no reason to get into a pissing
contest over this.

You took this out
of context as you seem to have done to the rest of my post.
I don't think so. Whatever.

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.

Ok boss.

>>To me, this is similar to the variable initialization issue. Some are
>>init'd implicitly (if you don't initialize them explicitly) and some
>>aren't. I just explicitly initialize everything then I don't have to
>>remember which are and which aren't.
>
>
>Aa matter of 'habit', I will usually initialize every
>object I define, regardless of its storage duration.
>But the issue of which objects are automatically
>initialized and which are not is straightforward:
>
>1) Static storage duration objects are automatically default

initialized.
>2) Objects with any other storage duration are not automatically
>initialized.
>3) ("Special case") If one or more of an array's elements are
explicitly
initialized, any elements for which there are no corresponding
>initializers
> are default inititalized.

Ok. You remember your rules and I'll just keep initializing everything.
I also usually initialize everything. But imo it is good to
know the rules, especially when reading others' code.

-Mike

I read other people's code all the time.

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

[Ioannis Vranos]

KPB wrote:

I've also seen the void main(). Have you?

void main() has never been valid C++98 or C90, but invokes undefined
behaviour.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[KPB]

Ioannis Vranos wrote:

KPB wrote:

I've also seen the void main(). Have you?

void main() has never been valid C++98 or C90, but invokes undefined
behaviour.

I didn't say it was valid. I just said I've seen it.

[E. Robert Tisdale]

Ioannis Vranos wrote:

#include <iostream>

int main()
{
using namespace std;

cout<<"Best wishes for a Great Happy New Year to all!"<<endl;
} cat main.cc #include <iostream>

int main(int argc, char* argv[]) {

std::cout << "And Happy New Year to you too Ioannis."
<< std::endl;

return 0;
}
g++ -Wall -ansi -pedantic -o main main.cc
./main

And Happy New Year to you too Ioannis.

[KPB]

E. Robert Tisdale wrote:

> g++ -Wall -ansi -pedantic -o main main.cc
> ./main

And Happy New Year to you too Ioannis.

AWESOME! :-)

[Ioannis Vranos]

E. Robert Tisdale wrote:

> cat main.cc

#include <iostream>

int main(int argc, char* argv[]) {

std::cout << "And Happy New Year to you too Ioannis."
<< std::endl;

return 0;
}

> g++ -Wall -ansi -pedantic -o main main.cc
> ./main

And Happy New Year to you too Ioannis.

Cheers Robert!


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[David Harmon]

On Fri, 31 Dec 2004 22:36:38 +0200 in comp.lang.c++, Ioannis Vranos
<iv*@remove.this.grad.com> wrote,

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.

[Victor Bazarov]

"Ioannis Vranos" <iv*@remove.this.grad.com> wrote...

Victor Bazarov wrote:

Actually that's not a problem (see other replies). However, a strictly
conforming implementation has to complain about 'endl' being undefined.
To find it, include <ostream> as well.

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. Robert Tisdale]

David Harmon wrote:

Jon Wilson wrote,

Ioannis Vranos wrote:

#include <iostream>

int main()
{
using namespace std;

cout<<"Best wishes for a Great Happy New Year to all!"<<endl;
}

This should give a compiler warning.
You declare int main(), but have no return statement.

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

[Mike Hewson]

E. Robert Tisdale wrote:

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

No shortage of retuntive behaviour here. :-)

--

Cheers
--
Hewson::Mike
"This letter is longer than usual because I lack the time to make it
shorter" - Blaise Pascal

[Ioannis Vranos]

Victor Bazarov wrote:

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/iostrea...ratorltlt.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/iostrea...eam/_endl.html
I just discovered we could use endl this way!


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Rob Williscroft]

Ioannis Vranos wrote in news:1104574412.720775@athnrd02 in comp.lang.c++:

Victor Bazarov wrote:

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.

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,
its in the IO library section (27) and states that <ostream> provides
this declaration, 27.6.2/1, 27.6.2.7/1.

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.
--
http://www.victim-prime.dsl.pipex.com/

[Rolf Magnus]

Victor Bazarov wrote:

"Jon Wilson" <js*@fnal.gov> wrote...

Ioannis Vranos wrote:

#include <iostream>
int main()
{
using namespace std;

cout<<"Best wishes for a Great Happy New Year to all!"<<endl;
}

This should give a compiler warning. You declare int main(), but have no
return statement.

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.

[Victor Bazarov]

"Rolf Magnus" <ra******@t-online.de> wrote...

Victor Bazarov wrote:

"Jon Wilson" <js*@fnal.gov> wrote...

Ioannis Vranos wrote:
#include <iostream>
int main()
{
using namespace std;

cout<<"Best wishes for a Great Happy New Year to all!"<<endl;
}

This should give a compiler warning. You declare int main(), but have
no
return statement.

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.

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

[Mike Wahler]

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:WP********************@comcast.com...

"Rolf Magnus" <ra******@t-online.de> wrote...

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.

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

[Rolf Magnus]

Victor Bazarov wrote:

"Rolf Magnus" <ra******@t-online.de> wrote...

Victor Bazarov wrote:

"Jon Wilson" <js*@fnal.gov> wrote...
Ioannis Vranos wrote:
> #include <iostream>
>
>
> int main()
> {
> using namespace std;
>
> cout<<"Best wishes for a Great Happy New Year to all!"<<endl;
> }
>
>
>
This should give a compiler warning. You declare int main(), but have
no
return statement.

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.

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

[Victor Bazarov]

"Mike Wahler" <mk******@mkwahler.net> wrote...

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:WP********************@comcast.com...

"Rolf Magnus" <ra******@t-online.de> wrote...

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

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

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

[Victor Bazarov]

"Rolf Magnus" <ra******@t-online.de> wrote...

Victor Bazarov wrote:

"Rolf Magnus" <ra******@t-online.de> wrote...

Victor Bazarov wrote:

"Jon Wilson" <js*@fnal.gov> wrote...
> Ioannis Vranos wrote:
>> #include <iostream>
>>
>>
>> int main()
>> {
>> using namespace std;
>>
>> cout<<"Best wishes for a Great Happy New Year to all!"<<endl;
>> }
>>
>>
>>
>
>
> This should give a compiler warning. You declare int main(), but have
> no
> return statement.

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.

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::ostream 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

[Mike Wahler]

"Rolf Magnus" <ra******@t-online.de> wrote in message
news:cr************@news.t-online.com...

Victor Bazarov wrote:

"Rolf Magnus" <ra******@t-online.de> wrote...
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::ostream 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

[Mike Wahler]

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:su********************@comcast.com...

"Mike Wahler" <mk******@mkwahler.net> wrote...

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.

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
describing the <locale> stuff.
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

[Ioannis Vranos]

Rolf Magnus wrote:

However, since std::ostream 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. :-)


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Ioannis Vranos wrote:

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.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Rolf Magnus]

Mike Wahler wrote:

However, since std::ostream 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).

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.

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

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]

"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message
news:1104617208.103304@athnrd02...

Rolf Magnus wrote:

However, since std::ostream 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 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]

"Ioannis Vranos" <iv*@remove.this.grad.com> wrote in message
news:1104617502.870591@athnrd02...

Ioannis Vranos wrote:

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.

Great. Now I feel all warm and fuzzy inside. :-)

-Mike

[Rolf Magnus]

Mike Wahler wrote:

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

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]

"Rolf Magnus" <ra******@t-online.de> wrote in message
news:cr*************@news.t-online.com...

Mike Wahler wrote:

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

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