By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,898 Members | 2,012 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,898 IT Pros & Developers. It's quick & easy.

"Accelerated C++" beginner question.

P: n/a
Great book - I like the way that unlike other books, AC++ explains as
much as possible about every piece of code discussed, so I'm not left
thinking, "well...OK... I get line 12, but I wonder what the rest of
it means...".

Still, I have some questions, that are frustrating me:-
Grateful for any comments.

1. What is the difference between
#include <iostream> // (or any include file) which is used in this
book, and
#include <iostream.h> // which is used in other books I've looked at.

2. Does the absence of the '.h' have something to do with the need
for std:: before cout ?

3. std, the book esplains, is a namesace. But what is a namespace,
particularly in this case?. Is it something I can open and look at in
Notepad?

.....................................
I'm up to chapter 4, and relativaly comfortable with it, but these
early questions are still nagging me.

Thanks
Jul 23 '05 #1
Share this Question
Share on Google+
39 Replies


P: n/a
TonyJeffs skrev:
Great book - I like the way that unlike other books, AC++ explains as
much as possible about every piece of code discussed, so I'm not left
thinking, "well...OK... I get line 12, but I wonder what the rest of
it means...".

Still, I have some questions, that are frustrating me:-
Grateful for any comments.

1. What is the difference between
#include <iostream> // (or any include file) which is used in this
book, and
#include <iostream.h> // which is used in other books I've looked at. #include <iostream> is the suggested way of including files
in c++ (at least for standard libraries)
#include <iostream.h> is just about the same, except most
compilers will give you a warning telling you its deprecated.
When writing your own header files - select what suits you the best.
Personally, I like .h or .hpp

2. Does the absence of the '.h' have something to do with the need
for std:: before cout ?
No.
3. std, the book esplains, is a namesace. But what is a namespace,
particularly in this case?. Is it something I can open and look at in
Notepad?

A namespace is a concept of grouping things - like functions, classes
and constants - that belong together.
Using namespaces makes your code more readable and more easily
maintained.
The standard libraries, such as iostream, use a namespace called
std - that's why you see things like 'std::cout << "blah" << std::endl;'
or 'using namespace std;'

Google it.

-- Pelle
Jul 23 '05 #2

P: n/a

"TonyJeffs" <to*******@aol.com> wrote in message
Great book - I like the way that unlike other books, AC++ explains as
much as possible about every piece of code discussed, so I'm not left
I haven't read anyone saying otherwise about the book :-)
thinking, "well...OK... I get line 12, but I wonder what the rest of
it means...".

Still, I have some questions, that are frustrating me:-
Grateful for any comments.

1. What is the difference between
#include <iostream> // (or any include file) which is used in this
book, and
#include <iostream.h> // which is used in other books I've looked at.
The other books you have looked at are outdated. Standard headers are
extensionless.

2. Does the absence of the '.h' have something to do with the need
for std:: before cout ?
Yes, everything inside standard headers is wrapped inside std namespace. So
cout needs to be addressed as std::cout.
3. std, the book esplains, is a namesace. But what is a namespace,
particularly in this case?. Is it something I can open and look at in
Notepad?


What have namespaces to do with Notepad ?? Namespaces allow us to group a
set of global classes, objects and/or functions under a name. This helps in
avoiding name conflicts, and redefinition errors.

namespace a {
int i; // OK
}

namespace b {
int i; // OK
}

Sharad


Jul 23 '05 #3

P: n/a

"Pelle Beckman" <he******@chello.se> wrote in message
1. What is the difference between
#include <iostream> // (or any include file) which is used in this
book, and
#include <iostream.h> // which is used in other books I've looked at. #include <iostream> is the suggested way of including files


Not suggested, but correct way of including files in ISO C++.
in c++ (at least for standard libraries)
#include <iostream.h> is just about the same, except most
compilers will give you a warning telling you its deprecated.
When writing your own header files - select what suits you the best.
Personally, I like .h or .hpp

2. Does the absence of the '.h' have something to do with the need
for std:: before cout ?

No.


Why ?

3. std, the book esplains, is a namesace. But what is a namespace,
particularly in this case?. Is it something I can open and look at in
Notepad?

A namespace is a concept of grouping things - like functions, classes
and constants - that belong together.
Using namespaces makes your code more readable and more easily
maintained.


Is that the only goal of namespaces ?

Sharad
Jul 23 '05 #4

P: n/a
"TonyJeffs" <to*******@aol.com> wrote in message
news:8e**************************@posting.google.c om...
1. What is the difference between
#include <iostream> // (or any include file) which is used in this
book, and
#include <iostream.h> // which is used in other books I've looked at.
<iostream.h> is not part of standard C++, although many implementations
include it for compatibility with earlier usage.
2. Does the absence of the '.h' have something to do with the need
for std:: before cout ?
Yes.
3. std, the book esplains, is a namesace. But what is a namespace,
particularly in this case?. Is it something I can open and look at in
Notepad?


A namespace is something that is part of the C++ language. It is not a data
structure that you can access directly. A namespace has a name and contains
a (possibly empty) collection of names. When you want to use one of the
names that a namespace contains, you can refer to it as x::y, where x is the
name of the namespace and y is the name that it contains.

So when you say

#include <vector>

the compiler puts the name "vector" into the namespace named "std", after
which you can refer to std::vector. Alternatively, by saying "using
std::vector;" you can cause the name "vector" to be brought into the global
namespace, after which you can refer to vector without the "std::" in front
of it.
Jul 23 '05 #5

P: n/a
TonyJeffs wrote:
Great book - I like the way that unlike other books, AC++ explains as
much as possible about every piece of code discussed, so I'm not left
thinking, "well...OK... I get line 12, but I wonder what the rest of
it means...".

Still, I have some questions, that are frustrating me:-
Grateful for any comments.

1. What is the difference between
#include <iostream> // (or any include file) which is used in this

This is valid C++.

book, and
#include <iostream.h> // which is used in other books I've looked at.

This is not valid C++. It was used before the final C++ standard.
2. Does the absence of the '.h' have something to do with the need
for std:: before cout ?
No.
3. std, the book esplains, is a namesace. But what is a namespace,
particularly in this case?. Is it something I can open and look at in
Notepad?

We can say that namespace is a scope for grouping facilities.

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #6

P: n/a
* Pelle Beckman:
TonyJeffs skrev:
Great book - I like the way that unlike other books, AC++ explains as
much as possible about every piece of code discussed, so I'm not left
thinking, "well...OK... I get line 12, but I wonder what the rest of
it means...".

Still, I have some questions, that are frustrating me:-
Grateful for any comments.

1. What is the difference between
#include <iostream> // (or any include file) which is used in this
book, and
#include <iostream.h> // which is used in other books I've looked at. #include <iostream> is the suggested way of including files
in c++ (at least for standard libraries)


No suggestion.

<iostream> is a standard header.

<iostream.h> is not, and is only available with certain compilers.

#include <iostream.h> is just about the same, except most
compilers will give you a warning telling you its deprecated.


_No_ compiler will tell you that.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 23 '05 #7

P: n/a
Thanks for all the advice. As well as helping me know what's going on,
any interaction on the topic will be a big help in keeping me going
and on track!

My next Question (sec 4.1.2 in case anyone wants to look at the
book):

const vector<double>& hw =homework)

I follow that hw is a synonym for homework.
But it seems to me that '&' does not mean 'the address of' in this
case. It means something a bit different. Am I correct? What phrase
could I use to explain the &?
Does this & mean 'by reference'?

(You'll see my brain's a bit cluttered with things I've half read and
half understood in the past!!)

Thanks again,

Tony
Jul 23 '05 #8

P: n/a
tony_jeffs wrote:
My next Question (sec 4.1.2 in case anyone wants to look at the
book):

const vector<double>& hw =homework)

I follow that hw is a synonym for homework.
But it seems to me that '&' does not mean 'the address of' in this
case. It means something a bit different. Am I correct? What phrase
could I use to explain the &?
Does this & mean 'by reference'?


Not quite. In this context & means that hw is a reference. Look up
references in your book.

To quote another great C++ book (C++ Primer, Lippman & Lajoie): "A
reference, sometimes referred to as an alias, serves as an alternative
name for an object. A reference allows for the indirect manipulation of
an object in a manner similar to the use of a pointer but without
requiring use of pointer syntax".

But what does that mean in real life? Lets look at an example:

Using a pointer:

void GetName(std::string* name)
{
// Check if name is valid
if(!name)
{
throw std::runtime_error("Invalid name pointer");
}

// Do something to get a name
...

*name = "something";
}

Using a reference:

void GetName(std::string& name)
{
// Do something to get a name
...

name = "something";
}

By using a reference parameter instead of a pointer parameter, the
compiler will make sure that you get a valid object you can use
(although there are pitfalls!). If you use a pointer you need to do the
checking by yourself.

There are other ways of using a reference type. Compare these two functions:

void OutputName(std::string name)
{
....
}

void OutputName(const std::string& name)
{
....
}

What's the difference? Calling the first function will pass a copy of
the name (which of course means that a copy will be made). Calling the
second function will only pass a reference to the name (much cheaper,
especially when dealing with long strings, vectors, etc.).

HTH.

--
Peter
Jul 23 '05 #9

P: n/a
Are you realy the guy who wrote those C++ books?
How is Bjarne?

Jul 23 '05 #10

P: n/a
"Alf P. Steinbach" <al***@start.no> wrote in message
news:42***************@news.individual.net...
#include <iostream.h> is just about the same, except most
compilers will give you a warning telling you its deprecated.


_No_ compiler will tell you that.


Not true. If under gcc 3.3.3 I compile

#include <iostream.h>

I get the following diagnostic message:

In file included from /usr/include/c++/3.3.3/backward/iostream.h:31,
from xx.c:1:
/usr/include/c++/3.3.3/backward/backward_warning.h:32:2: warning: #warning
This file includes at least one deprecated or antiquated header. Please
consider using one of the 32 headers found in section 17.4.1.2 of the C++
standard. Examples include substituting the <X> header for the <X.h> header
for C++ includes, or <sstream> instead of the deprecated header
<strstream.h>. To disable this warning use -Wno-deprecated.
Jul 23 '05 #11

P: n/a
"enki" <en*****@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
Are you realy the guy who wrote those C++ books?
Yes I am.
How is Bjarne?


Fine so far as I know. We've been getting together less frequently since he
moved to Texas, but I got email from him a few days ago.
Jul 23 '05 #12

P: n/a
* Andrew Koenig:
"Alf P. Steinbach" <al***@start.no> wrote in message
news:42***************@news.individual.net...
#include <iostream.h> is just about the same, except most
compilers will give you a warning telling you its deprecated.
_No_ compiler will tell you that.


Not true.


Heyah, that's not true! ;-)

If under gcc 3.3.3 I compile

#include <iostream.h>

I get the following diagnostic message:

In file included from /usr/include/c++/3.3.3/backward/iostream.h:31,
from xx.c:1:
/usr/include/c++/3.3.3/backward/backward_warning.h:32:2: warning: #warning
This file includes at least one deprecated or antiquated header.


Note: "deprecated or antiquated".

gcc doesn't incorrectly tell you that it's deprecated.

It correctly tells you that it's deprecated or antiquated, and in this case,
it's antiquated.

The logic error is: special case -> generalization -> some other special
case, incompatible with the first, where the last specialization is invalid.

Cheers,

- Alf

(Sorry I missed out on Bjarne's lecture here in Oslo on Friday, I couldn't
attend, otherwise I'd been there and if enough committee people were around
I'd collect all the beers they've pledged to buy me... ;-))

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 23 '05 #13

P: n/a
I have to say it is a real treat to know that you take the time help
the rest of us out.

I wish I could learn all the lessons of Accelerated C++. I learned
more in in the first 3 chapters of that book than I have from massive
C++ tomes.

I am getting into win32 programming but I hope to apply the lessons of
the book to my projects. I am trying to accuire the skills to get
hired working with code.

Jul 23 '05 #14

P: n/a
"Andrew Koenig" <ar*@acm.org> wrote in message news:<qK******************@bgtnsc04-news.ops.worldnet.att.net>...
<....>
So when you say

#include <vector>

the compiler puts the name "vector" into the namespace named "std", after
which you can refer to std::vector. Alternatively, by saying "using
std::vector;" you can cause the name "vector" to be brought into the global
namespace, after which you can refer to vector without the "std::" in front
of it.


Hi Andrew,
I'm honoured to meet the author!

So...
Any with any #include<...> header, the compiler automatically creates
the std namespace and puts things in it.
With #include <vector>, it puts "vector" in the std namespace, but
with some, eg #include<iostream> it will put more in the std
namespace - eg "cout". Am I right on the last part?

................

Thanks Peter, I'll work on your examples.
Thanks all.
Tony
Jul 23 '05 #15

P: n/a
"tony_jeffs" <8u*****@tonyjeffs.com> wrote in message
news:68**************************@posting.google.c om...
Hi Andrew,
I'm honoured to meet the author!
Thanks!
Any with any #include<...> header, the compiler automatically creates
the std namespace and puts things in it.
With #include <vector>, it puts "vector" in the std namespace, but
with some, eg #include<iostream> it will put more in the std
namespace - eg "cout". Am I right on the last part?


Right you are.
Jul 23 '05 #16

P: n/a

Alf P. Steinbach wrote:
* Pelle Beckman:
TonyJeffs skrev:
Great book - I like the way that unlike other books, AC++ explains as much as possible about every piece of code discussed, so I'm not left thinking, "well...OK... I get line 12, but I wonder what the rest of it means...".

Still, I have some questions, that are frustrating me:-
Grateful for any comments.

1. What is the difference between
#include <iostream> // (or any include file) which is used in this book, and
#include <iostream.h> // which is used in other books I've
looked at. #include <iostream> is the suggested way of including files
in c++ (at least for standard libraries)


No suggestion.

<iostream> is a standard header.

<iostream.h> is not, and is only available with certain compilers.

#include <iostream.h> is just about the same, except most
compilers will give you a warning telling you its deprecated.


_No_ compiler will tell you that.


Not quite true.
Some compilers do tell you that it's deprecated, however, I believe
they're referring to it being deprecated by the compiler, and not by
the standards.
In other words, it's an implementation extended feature that the
implementation considers deprecated.

Since *.h STD headers where never part of the official C++ standard,
the implementation can say anything it want about it or nothing at all.

Jul 23 '05 #17

P: n/a
//references

I now understand the ampersands, -which was my main aim with this-
But I don't understand what's happening in the line labelled "#Line 23".
I thought myFun would incr x to 8, and "+=1" would incr myFun to 9.
What increments x to 9?

thanks
Tony

int& myFun(int& a, int& b) //int& myFun(~~~) makes it an lvalue!
{
a = a+1;
return a;
}

int main()
{
int x;
int y;
x=6;
y=1;

std::cout <<x; //x==6
myFun(x,y);
std::cout <<x; //x==7 -incr'd by myFun
int& z=myFun(x,y)+=1; // #Line 23
//x==8(No!), myFun==8, then myFun==9
std::cout <<x; //NO x==9. why?

return 0;
}
Jul 23 '05 #18

P: n/a
* Axter:
* Alf P. Steinbach:
* Pelle Beckman:
#include <iostream.h> is just about the same, except most
compilers will give you a warning telling you its deprecated.


_No_ compiler will tell you that.


Not quite true.
Some compilers do tell you that it's deprecated


Example?

(Note that g++ has already been discussed and dismissed as example.)

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 23 '05 #19

P: n/a
On Sat, 16 Apr 2005 14:46:09 GMT, Alf P. Steinbach
<al***@start.no> wrote:
* Pelle Beckman:
TonyJeffs skrev:
> Great book - I like the way that unlike other books, AC++ explains as
> much as possible about every piece of code discussed, so I'm not left
> thinking, "well...OK... I get line 12, but I wonder what the rest of
> it means...".
>
> Still, I have some questions, that are frustrating me:-
> Grateful for any comments.
>
> 1. What is the difference between
> #include <iostream> // (or any include file) which is used in this
> book, and
> #include <iostream.h> // which is used in other books I've looked at.

#include <iostream> is the suggested way of including files
in c++ (at least for standard libraries)


No suggestion.

<iostream> is a standard header.

<iostream.h> is not, and is only available with certain compilers.


iostream.h was the old (pre-standard) name for it.
#include <iostream.h> is just about the same, except most
compilers will give you a warning telling you its deprecated.


_No_ compiler will tell you that.


You are provably wrong:

$ c++ -c /tmp/1.cc
In file included from /usr/local/gcc/lib/.../iostream.h:31,
from /tmp/1.cc:1:
/usr/local/gcc/lib/gcc/.../include/c++/3.4.3/backward/backward_warning.h:32:2:
warning: #warning This file includes at least one deprecated or antiquated
header. Please consider using one of the 32 headers found in section 17.4.1.2
of the C++ standard. Examples include substituting the <X> header for the
<X.h> header for C++ includes, or <iostream> instead of the deprecated header
<iostream.h>. To disable this warning use -Wno-deprecated.

$ c++ --version
c++ (GCC) 3.4.3
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

(Lines wrapped and paths truncated using ... to fit in a post.)

Chris C
Jul 23 '05 #20

P: n/a
* Chris Croughton:
On Sat, 16 Apr 2005 14:46:09 GMT, Alf P. Steinbach
<al***@start.no> wrote:
* Pelle Beckman:
TonyJeffs skrev:
> Great book - I like the way that unlike other books, AC++ explains as
> much as possible about every piece of code discussed, so I'm not left
> thinking, "well...OK... I get line 12, but I wonder what the rest of
> it means...".
>
> Still, I have some questions, that are frustrating me:-
> Grateful for any comments.
>
> 1. What is the difference between
> #include <iostream> // (or any include file) which is used in this
> book, and
> #include <iostream.h> // which is used in other books I've looked at.
#include <iostream> is the suggested way of including files
in c++ (at least for standard libraries)


No suggestion.

<iostream> is a standard header.

<iostream.h> is not, and is only available with certain compilers.


iostream.h was the old (pre-standard) name for it.


Nope.

<iostream.h> from pre-standard days was not standardized
(it could contain anything), and did not provide the modern iostreams.

The standard <iostream> header has never had another name.

#include <iostream.h> is just about the same, except most
compilers will give you a warning telling you its deprecated.


_No_ compiler will tell you that.


You are provably wrong:

$ c++ -c /tmp/1.cc
In file included from /usr/local/gcc/lib/.../iostream.h:31,
from /tmp/1.cc:1:
/usr/local/gcc/lib/gcc/.../include/c++/3.4.3/backward/backward_warning.h:32:2:
[snip]
or <iostream> instead of the deprecated header <iostream.h>.


I stand corrected.

g++ 3.4.3 (and 3.4.2) is, in other words, incorrect in this regard.

Oh well...

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 23 '05 #21

P: n/a
tony_jeffs wrote:
int& myFun(int& a, int& b) //int& myFun(~~~) makes it an lvalue!
{
a = a+1;
return a;
1)
What do you return here?
}

int main()
{
int x;
int y;
x=6;
y=1;

std::cout <<x; //x==6
myFun(x,y);
std::cout <<x; //x==7 -incr'd by myFun
int& z=myFun(x,y)+=1; // #Line 23
//x==8(No!), myFun==8, then myFun==9
2)
What takes place here? What order?
std::cout <<x; //NO x==9. why?

return 0;
}


Try to answer question 2) first and then 1). Hint: a = x.

I think it would be a good exercise to figure this one out by yourself.
You may get some help by changing the myFun to:

int myFun(int&, int&)

Good luck. If you get stuck, write again.

BR,
Peter
Jul 23 '05 #22

P: n/a
Alf P. Steinbach wrote:
Nope.

<iostream.h> from pre-standard days was not standardized
(it could contain anything), and did not provide the modern iostreams.

The standard <iostream> header has never had another name.

These are unneeded technicalities, however as someone else mentioned in this thread, it is
about compiler-specific facilities that are deprecated and not ISO C++ facilities. The
compiler is free to consider some older of its own facilities as deprecated.

--
Ioannis Vranos

http://www23.brinkster.com/noicys
Jul 23 '05 #23

P: n/a
On Tue, 19 Apr 2005 11:30:13 GMT, Alf P. Steinbach
<al***@start.no> wrote:
* Chris Croughton:
On Sat, 16 Apr 2005 14:46:09 GMT, Alf P. Steinbach
<al***@start.no> wrote:
> <iostream> is a standard header.
>
> <iostream.h> is not, and is only available with certain compilers.
iostream.h was the old (pre-standard) name for it.


Nope.

<iostream.h> from pre-standard days was not standardized


Well, duh. Everything from pre-standard days was not standardised, by
definition. Did you know that water is wet?
(it could contain anything), and did not provide the modern iostreams.
It could "contain anything", but in practice it generally contained
something close to whatever a previous draft standard (or edition of
Stroustrup) said about iostreams. Some compilers provided iostreams.h
as the implementation of iostream (in other words iostream just included
iostream.h).
The standard <iostream> header has never had another name.


Since there is no standard header published, only specifications for
what must appear in a header of that name, it obviously didn't have
another (or any) name. Indeed, the standard has no requirement that
there be any physical standard header at all, only that using #include
with that name behaves as if the header was included.
>> #include <iostream.h> is just about the same, except most
>> compilers will give you a warning telling you its deprecated.
>
> _No_ compiler will tell you that.


You are provably wrong:

$ c++ -c /tmp/1.cc
In file included from /usr/local/gcc/lib/.../iostream.h:31,
from /tmp/1.cc:1:
/usr/local/gcc/lib/gcc/.../include/c++/3.4.3/backward/backward_warning.h:32:2:
[snip]
or <iostream> instead of the deprecated header <iostream.h>.


I stand corrected.

g++ 3.4.3 (and 3.4.2) is, in other words, incorrect in this regard.


How is it incorrect to warn that including a non-standard header is now
deprecated? If it's a non-standard header then it can, as you point
out, do anything it likes. Including warning that using it is
deprecated and a different (and standard) header now provides the
required functionality.

Chris C
Jul 23 '05 #24

P: n/a
* Chris Croughton:

Some compilers provided iostreams.h
as the implementation of iostream (in other words iostream just included
iostream.h).
Although irrelevant that seems to be impossible: <iostream> is required to
provide 'extern' declarations of four objects of standard iostream types; the
pre-standard iostreams didn't have the same functionality for these objects.

The standard <iostream> header has never had another name.


Since there is no standard header published, only specifications for
what must appear in a header of that name


Note that those specifications are incompatible with the usual contents
of prestandard <iostream.h>; it would be remarkable if, as you maintain
above, some compiler vendor foresaw the standard and provided standard
<iostream> via <iostream.h> (yes, that's the implication), and then after the
standardization implemented <iostream> in terms of <iostream.h>.

Are you really sure?

How is it incorrect to warn that including a non-standard header is now
deprecated?


I don't know: _that_ is merely meaningless, a warning that sometime in
the future the compiler will stop being of practical value.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 23 '05 #25

P: n/a
Peter Kragh wrote:
<snip>


Try to answer question 2) first and then 1). Hint: a = x.

I think it would be a good exercise to figure this one out by yourself.
You may get some help by changing the myFun to:

int myFun(int&, int&)

Good luck. If you get stuck, write again.

BR,
Peter


I'd just like to add to Peter's remarks here.

Tony, try to think of how you pass things around in the program... And
think that one way isn't just a "fast way to move data around" but is
instead something different.

I also think Peter should have made more of a point over the way you put
3 things (an assignment(?), a function call and a variable alteration
(+=1 alters by adding one - doesn't "increase" like ++)).

I hope this gives you something to think about...

--
Tr0nČ
--
Jul 23 '05 #26

P: n/a
On Tue, 19 Apr 2005 17:50:59 GMT, Alf P. Steinbach
<al***@start.no> wrote:
* Chris Croughton:

Some compilers provided iostreams.h
as the implementation of iostream (in other words iostream just included
iostream.h).
Although irrelevant that seems to be impossible: <iostream> is required


NOW
to
provide 'extern' declarations of four objects of standard iostream types; the
pre-standard iostreams didn't have the same functionality for these objects.
What part of "pre-standard" do you not understand? They might not have
had exactly the same functionality (in particular they didn't generally
support stream buffers) but the main functionality used by programmers
was the same (istream, ostream; cin, cout, cerr, clog; input and output
operators; formatting; etc.).
> The standard <iostream> header has never had another name.


Since there is no standard header published, only specifications for
what must appear in a header of that name


Note that those specifications are incompatible with the usual contents
of prestandard <iostream.h>; it would be remarkable if, as you maintain
above, some compiler vendor foresaw the standard and provided standard
<iostream> via <iostream.h> (yes, that's the implication),


Did you not see the drafts? iostream didn't just appear full-blown in
the final standard, it was in at least two of the drafts before then
(N843, for instance, issued a year before the standard was ratified).
and then after the
standardization implemented <iostream> in terms of <iostream.h>.
When the standard came out, they re-implemented iostream.h with the new
functionality (much of which had been flagged as probable in
pre-standard drafts anyway) and had iostream just include iostream.h (or
the other way round, it makes no difference), because most of the
functionality was not all that different.
Are you really sure?


Yes.
How is it incorrect to warn that including a non-standard header is now
deprecated?


I don't know: _that_ is merely meaningless, a warning that sometime in
the future the compiler will stop being of practical value.


How? Or do you think that the non-standard header iostream.h has
practical value after all?

A feature being deprecated means that it is still supported for old code
but new code should not use it. It doesn't mean the same as obsolescent
or obsolete (although it may get to that stage eventually, but the same
is true of anything in the standard, it could change in future
standards).

The point is that older code often used the .h versions of header files
to provide the functionality now provided by the ones without .h. In
most cases the functionality was not noticably different, and in
particular the versions just before the standard were often very close
to the ones after it.

Chris C
Jul 23 '05 #27

P: n/a
* Chris Croughton:
[snip personal attacks]
When the standard came out, they re-implemented iostream.h with the new
functionality (much of which had been flagged as probable in
pre-standard drafts anyway) and had iostream just include iostream.h (or
the other way round, it makes no difference), because most of the
functionality was not all that different.
Are you really sure?


Yes.


In that case a concrete example would be great.

An <iostream.h> that implemented standard iostreams could break a lot of
code.

How is it incorrect to warn that including a non-standard header is now
deprecated?


I don't know: _that_ is merely meaningless, a warning that sometime in
the future the compiler will stop being of practical value.


How? Or do you think that the non-standard header iostream.h has
practical value after all?

A feature being deprecated means that it is still supported for old code
but new code should not use it. It doesn't mean the same as obsolescent
or obsolete (although it may get to that stage eventually, but the same
is true of anything in the standard, it could change in future
standards).


These two paragraphs seem to be inconsistent -- "non-standard" versus
"in the standard" -- please elaborate.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 23 '05 #28

P: n/a
Thanks Peter
It's making a lot of sense now!
myFun()+=1
actually runs myFun() twice, since it is equivalent to
myFun()= myFun()+1

And int& myFun has to be an lvalue, because myFun()+=1 has to refer to
something that is not transient.

What I was trying to prove to myself is that, since myFun() is an
lvalue, I should be able to increment it, but having it re-base itself
on the value of a ==x each time it is called made it difficult to
demonstrate, so I'm pleased to get around this with the following.
...........................
int& myFun(int& a)
{
if (a<8) //Once x reaches 8, myFun becomes an independant entity.
a = a+1;
return a;
}

int main()
{
int x;
x=6;
cout<<"x at beginning= 6 = " <<x<<endl; //
myFun(x); //
cout<<"x, incrd by myFun()= 7 = " <<x<<endl; //x==7
int& z=myFun(x);
cout<<"myFun after being run again = 8 = " <<z<<endl;
cout<<" and again x having itself been incrd by myfun =8= "<<x<<endl;

cout <<"(myFun+=MyFun)==(myFun + myFun), ==8+8 == "<<(myFun(x)
+=myFun
//now that the if clause in myFun() is FALSE, I can prove that

(x))<<endl;
return 0;
}
Jul 23 '05 #29

P: n/a
Darn - I somehow posted that before I'd finished.
so...
I have a==x==8 so the 'if' in myFun() is not actioned.
So myFun() ==8
myFun()+=myFun()
is the same as myFun()= MyFun()+MyFun()
and it equals 8+8
.........................
Before I wrote this, I thought that that proves myFun() (as in my
previous post) is an lvalue, but now I'm not so sure that it does!

Still, I do feel I'm makin' progress :-)
Tony
Jul 23 '05 #30

P: n/a
tony_jeffs wrote:
Thanks Peter
It's making a lot of sense now!
myFun()+=1
actually runs myFun() twice, since it is equivalent to
myFun()= myFun()+1


No! ... I better explain: The original myFun returned a reference (which
is just another name for something else). It returned a, which is itself
a reference to x.

When you write a (very peculiar) statement like this:

int& z=myFun(x,y)+=1; // #Line 23

, you increment x (a) in myFun, returns a reference to it and increment
it again using operator+=. OK, a bit cryptic explanation to a bit
cryptic statement :-)

BTW: "myFun() += 1" is NOT the same as "myFun() = myFun() + 1". The
latter involves two operators (operator+ and operator=). The former only
one.

--
Peter
Jul 23 '05 #31

P: n/a
On Wed, 20 Apr 2005 11:40:22 GMT, Alf P. Steinbach
<al***@start.no> wrote:
* Chris Croughton:

When the standard came out, they re-implemented iostream.h with the new
functionality (much of which had been flagged as probable in
pre-standard drafts anyway) and had iostream just include iostream.h (or
the other way round, it makes no difference), because most of the
functionality was not all that different.
> Are you really sure?
Yes.


In that case a concrete example would be great.


$ cat /usr/include/g++/iostream
// -*- C++ -*- forwarding header.
// This file is part of the GNU ANSI C++ Library.

#ifndef __IOSTREAM__
#define __IOSTREAM__
#include <iostream.h>
#endif
An <iostream.h> that implemented standard iostreams could break a lot of
code.


Only if that code was using some odd features. Basic stream usage
didn't change much, it was the extra functionality like streambuf which
was the main addition. Things like

cerr << "Fatal error: " << errnum << endl;

have worked since the early versions using iostream.h.
>> How is it incorrect to warn that including a non-standard header is now
>> deprecated?
>
> I don't know: _that_ is merely meaningless, a warning that sometime in
> the future the compiler will stop being of practical value.


How? Or do you think that the non-standard header iostream.h has
practical value after all?

A feature being deprecated means that it is still supported for old code
but new code should not use it. It doesn't mean the same as obsolescent
or obsolete (although it may get to that stage eventually, but the same
is true of anything in the standard, it could change in future
standards).


These two paragraphs seem to be inconsistent -- "non-standard" versus
"in the standard" -- please elaborate.


First paragraph:

You said that a warning that a non-standard header is deprecated meant
that at some time the compiler would "stop being of practical value."
That implies that you think that the compiler with the deprecated
feature is now "of practical value."

Second paragraph (not related directly to the preceding paragraph):

You seem to misunderstand the meaning of 'deprecated'. It means
"should not now be used" (for instance, the use of malloc/free in C++
is deprecated), it does not mean that it is intended to disappear.

Parenthetical comment to the last point in the second paragraph:

Everything is subject to change, so a deprecated feature may become
obsolescent, obsolete and eventually disappear. This is true for
things in the standard as well, they can become deprecated,
obsolescent and eventually obsolete and be removed..

Chris C
Jul 23 '05 #32

P: n/a
* Chris Croughton:
On Wed, 20 Apr 2005 11:40:22 GMT, Alf P. Steinbach
<al***@start.no> wrote:
* Chris Croughton:

When the standard came out, they re-implemented iostream.h with the new
functionality (much of which had been flagged as probable in
pre-standard drafts anyway) and had iostream just include iostream.h (or
the other way round, it makes no difference), because most of the
functionality was not all that different.

> Are you really sure?

Yes.
In that case a concrete example would be great.


$ cat /usr/include/g++/iostream
// -*- C++ -*- forwarding header.
// This file is part of the GNU ANSI C++ Library.

#ifndef __IOSTREAM__
#define __IOSTREAM__
#include <iostream.h>
#endif


It would help knowing which compiler this is, but I assume g++ 2.95 or
earlier.

g++ 2.91 (which was the oldest version I found on this computer) did not
implement standard iostreams at all, so you probably need some other example.

$ cat hello.cpp
#include <iostream> // std::wcout
//#include <istream> // <<, std::endl
int main()
{
std::wcout << L"Hello, Chris" << std::endl;
}
$ g++ --version
egcs-2.91.57
$ g++ hello.cpp
hello.cpp: In function `int main()':
hello.cpp:7: undeclared variable `wcout' (first use here)
$

An <iostream.h> that implemented standard iostreams could break a lot of
code.


Only if that code was using some odd features. Basic stream usage
didn't change much, it was the extra functionality like streambuf which
was the main addition. Things like

cerr << "Fatal error: " << errnum << endl;

have worked since the early versions using iostream.h.


See above; and no, AFAIK there were no early versions using <iostream.h>.

>> How is it incorrect to warn that including a non-standard header is now
>> deprecated?
>
> I don't know: _that_ is merely meaningless, a warning that sometime in
> the future the compiler will stop being of practical value.

How? Or do you think that the non-standard header iostream.h has
practical value after all?

A feature being deprecated means that it is still supported for old code
but new code should not use it. It doesn't mean the same as obsolescent
or obsolete (although it may get to that stage eventually, but the same
is true of anything in the standard, it could change in future
standards).


These two paragraphs seem to be inconsistent -- "non-standard" versus
"in the standard" -- please elaborate.


First paragraph:

You said that a warning that a non-standard header is deprecated meant


No, I did not say that; you have the full exchange between us above.

that at some time the compiler would "stop being of practical value."
That implies that you think that the compiler with the deprecated
feature is now "of practical value."

Second paragraph (not related directly to the preceding paragraph):

You seem to misunderstand the meaning of 'deprecated'. It means
"should not now be used" (for instance, the use of malloc/free in C++
is deprecated), it does not mean that it is intended to disappear.


<iostream.h> is not a deprecated header.

It's not part of the standard.

At all.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 23 '05 #33

P: n/a
Peter Kragh <nowhere@no_server.xxx> wrote in message news:<42***********************@dread15.news.tele. dk>...
tony_jeffs wrote:
Thanks Peter
It's making a lot of sense now!
myFun()+=1
actually runs myFun() twice, since it is equivalent to
myFun()= myFun()+1
No! ... I better explain: The original myFun returned a reference (which
is just another name for something else). It returned a, which is itself
a reference to x.


Yes, got that :-)

When you write a (very peculiar) statement like this:

int& z=myFun(x,y)+=1; // #Line 23

, you increment x (a) in myFun, returns a reference to it and increment
it again using operator+=. OK, a bit cryptic explanation to a bit
cryptic statement :-)
OK, I originally expected += to increment myFun, but not x, but I take
your point. It's something I cant easily conceptualise in English, but
can remember!
I think that myFun must be itself kinda a reference to x, so just as
changing x changes the value of myFun, so too changing myFun changes
x, because they're both stored as whatever's in the same address.

BTW: "myFun() += 1" is NOT the same as "myFun() = myFun() + 1". The
latter involves two operators (operator+ and operator=). The former only
one.


You've convinced me. I've managed to write something where the two
give different results.

I think maybe I'm digging too deep into this - but nevertheless, the
following is curious.

x=1;
// Inserting one of these lines at a time into main() gives curious
results

cout<<(myFun(x)=myFun(x)-1); // 2
cout<<(myFun(x)=myFun(x)+0); // 4 (not 3 !!!)
cout<<(myFun(x)=myFun(x)+1); // 4
cout<<(myFun(x)=myFun(x)+2); // 5
cout<<(myFun(x)=myFun(x)+3); // 6
Tony
Jul 23 '05 #34

P: n/a
tony_jeffs wrote:
x=1;
// Inserting one of these lines at a time into main() gives curious
results

cout<<(myFun(x)=myFun(x)-1); // 2
cout<<(myFun(x)=myFun(x)+0); // 4 (not 3 !!!)
cout<<(myFun(x)=myFun(x)+1); // 4
cout<<(myFun(x)=myFun(x)+2); // 5
cout<<(myFun(x)=myFun(x)+3); // 6


I'm not sure what you're doing here. I get different results (using the
myFun function from your previous post - with a small modification):

#include <iostream>

using namespace std;

int& myFun(int& a)
{
a = a+1;
return a;
}

int main()
{
int x=1;

cout << "\n" << (myFun(x)=myFun(x)-1); // 2
cout << "\n" << (myFun(x)=myFun(x)+0); // 4 (not 3 !!!)
cout << "\n" << (myFun(x)=myFun(x)+1); // 4
cout << "\n" << (myFun(x)=myFun(x)+2); // 5
cout << "\n" << (myFun(x)=myFun(x)+3); // 6
}

I get the following result:

2
4
7
11
16

Lets try to figure out why. Lets take the first statement (you can work
your way through the rest) and break it into steps: myFun(x)=myFun(x)-1

1) myFun(x) // The right one
2) myFun(x) // The left one
3) operator=

The value of x after the above steps (x = 1 to begin with):

1) 2
2) 3
3) 2 (-1)

For the second statement:

1) 3
2) 4
3) 4 (+0)

You do the rest. I don't see anything curious in this. Remember, myFun
returns x.

--
Peter
Jul 23 '05 #35

P: n/a
Peter Kragh <pe***************@mensa.dk> wrote in message news:<42***********************@news.sunsite.dk>.. .
tony_jeffs wrote:
x=1;
// Inserting one of these lines at a time into main() gives curious
results

cout<<(myFun(x)=myFun(x)-1); // 2
cout<<(myFun(x)=myFun(x)+0); // 4 (not 3 !!!)
cout<<(myFun(x)=myFun(x)+1); // 4
cout<<(myFun(x)=myFun(x)+2); // 5
cout<<(myFun(x)=myFun(x)+3); // 6
I'm not sure what you're doing here. I get different results (using the
myFun function from your previous post - with a small modification):

#include <iostream>

using namespace std;

int& myFun(int& a)
{
a = a+1;
return a;
}

int main()
{
int x=1;

cout << "\n" << (myFun(x)=myFun(x)-1); // 2
cout << "\n" << (myFun(x)=myFun(x)+0); // 4 (not 3 !!!)
cout << "\n" << (myFun(x)=myFun(x)+1); // 4
cout << "\n" << (myFun(x)=myFun(x)+2); // 5
cout << "\n" << (myFun(x)=myFun(x)+3); // 6
}

I get the following result:

2
4
7
11
16

Lets try to figure out why. Lets take the first statement (you can work
your way through the rest) and break it into steps: myFun(x)=myFun(x)-1

1) myFun(x) // The right one
2) myFun(x) // The left one
3) operator=

The value of x after the above steps (x = 1 to begin with):

1) 2
2) 3
3) 2 (-1)

For the second statement:

1) 3
2) 4
3) 4 (+0)

You do the rest. I don't see anything curious in this. Remember, myFun
returns x.

Peter
I get the same result as you using MS Visual C++ 2005 Beta, and follow
your explanation.
But with the same code copied and pasted into MSVC++6, I get1
3
5
8
12

I think its an oddity in vc6
Here's the full code illustrating what I was trying to say yesterday,
better explained!

#include "stdafx.h"
#include <iostream>
using std::cout;

int& myFun(int& a)
{
a = a+1;
return a;
}

int main()
{
int x=1;
cout << "\n" << (myFun(x)=myFun(x)-1);
x=1;
cout << "\n" << (myFun(x)=myFun(x)+0);
x=1;
cout << "\n" << (myFun(x)=myFun(x)+1);
x=1;
cout << "\n" << (myFun(x)=myFun(x)+2);
x=1;
cout << "\n" << (myFun(x)=myFun(x)+3);
cout <<"\n";
return 0;
}
/*
Output1
3
3
4
5 in MS VC++6

Output2
3
4
5
6

in the new Beta

What compiler do you use/recommend?

Thanx
Tony
Jul 23 '05 #36

P: n/a
Peter Kragh <pe***************@mensa.dk> wrote in message news:<42***********************@news.sunsite.dk>.. .
I get the following result:

2
4
7
11
16
Peter
(I posted a long reply, but it must've vanished in the ether)
I get the same as you using MSVC++2005 beta, and I follow your logic,
but I get a different result with MSVC++6, even when I copy and paste.
i.e.1
3
5
8
12
I can't see how it does that.
My original code had x=1; before each cout<< operation
When I do that with your code in MSVC++6, I get1
3
3
4
5

....which makes no sense to me.
I guess it's something for a microsoft group, though, rather than
here.
I'm sailing through the next few chapters of this book now I got
chapter 4 out the way :-)
Tony
Jul 23 '05 #37

P: n/a
TonyJeffs wrote:
Peter Kragh <pe***************@mensa.dk> wrote in message news:<42***********************@news.sunsite.dk>.. .

I get the following result:

2
4
7
11
16

Peter
(I posted a long reply, but it must've vanished in the ether)
I get the same as you using MSVC++2005 beta, and I follow your logic,
but I get a different result with MSVC++6, even when I copy and paste.
i.e.
1
3
5
8
12

I can't see how it does that.


Sorry for the late reply. I have been busy...

Your question and results got me thinking... let's see what the standard
has to say:

Chapter 5, §4:
"Between the previous and next sequence point a scalar object shall have
its stored value modified at most once by the evaluation of an expression."

Note: A sequence point is either a ; or a , (comma).

With an example:

i = v[i++]; // the behavior is unspecified.

The way I see it, your compiler is free to decide what to do with a
statement like this:

cout << (myFun(x) = myFun(x) + 3);

Conclusion: This has been in interesting academic exercise, but don't do
this in real life.

I should have thought about this sooner. Soory.

--
Peter
Jul 23 '05 #38

P: n/a
Cheers Peter
I take your point.

I ve been racing ahead in the book, but a huge crevasse is appearing
in my knowledge, so I think I need to go back and REALLY understand
everything in CH4.

-I pretty much do, but it's hard to see the big picture.

Tony
Jul 23 '05 #39

P: n/a
Peter Kragh wrote:
Chapter 5, §4:
"Between the previous and next sequence point a scalar object
shall have its stored value modified at most once by the
evaluation of an expression."

Note: A sequence point is either a ; or a , (comma).
This is your note, not the standard text's note !
Actually a sequence point is more complicated than that.
For example, a comma in a function-call list is NOT
a sequence point.
With an example:

i = v[i++]; // the behavior is unspecified.
Actually the behaviour is undefined.
"Unspecified" means there is a finite set of possible outcomes.
"Undefined" means anything could happen, including the program
crashing.

Now, regarding the following function:

int &myFun(int &x)
{
++x;
return x;
}
The way I see it, your compiler is free to decide what to do with a
statement like this:

cout << (myFun(x) = myFun(x) + 3);


In this case, the behaviour is unspecified.

There is a sequence point immediately before and after a
function call, so the updating done by 'myFun' is "protected"
from causing undefined behaviour by those sequence points.

A fun exercise now would be to work out all the possible
values of 'x' ! Here is my rough attempt, assuming x starts
as 0:

1) The first myFun call is evaluated first, so the expression
is equivalent to:

++x;
x = myFun(x) + 3;

which is equivalent to:

++x;
++x;
x = x + 3;

because the second call to myFun() must occur before the assignment.
So x is 5, and the value printed is also 5.

2) The second myFun call is evaluated first, so the expression
is equivalent to:

++x;
myFun(x) = x + 3;

Now we have two choices:

2a) myFun is now evaluated, the original expression is now:

++x;
++x;
x = x + 3;

giving 5 again, and

2b) x is now evaluated:

++x;
myFun(x) = 4;

giving x = 4 and printing 4.

Jul 23 '05 #40

This discussion thread is closed

Replies have been disabled for this discussion.