another strange output?

[RB]

I just recently was educated that I should be using #include <iostream>
instead of using #include <iostream.h> as I had been doing.
However, even though the education cured one strange output issue, now
with the "correct" include spec I cannot get it to show the radix base like
it used to using the "incorrect" include spec.
Very much appreciate info as to what I am still missing. Code below
==============================================
#include <windows.h>
#include <iostream> // correct include spec
using namespace std;

// #include <iostream.h> // incorrect include spec

struct _Whatever
{
DWORD dw1;
DWORD dw2;
};

int main( )
{
_Whatever* pA = new _Whatever;
pA->dw1 = 0xAAAA;
pA->dw2 = 0xBBBB;

cout.flags ( ios::hex | ios::showbase ); // want to show radix

cout << "The allocated heap address that pA and/or pA->dw1 points is " << pA
<< "\nThe allocated address that pA->dw2 points is " << &pA->dw2
<< "\nThe address of the local pA pointer (on stack) " << &pA
<< endl;
delete pA;
return 0;
}

/*------------- program output if using correct include of
#include <iostream>
using namespace std;

The allocated heap address that pA and/or pA->dw1 points is 00331C48
The allocated address that pA->dw2 points is 00331C4C
The address of the local pA pointer (on stack) 0012FF7C

// Does not showbase ???
--------------*/

/*------------- program output if using incorrect include of
#include <iostream.h>

The allocated heap address that pA and/or pA->dw1 points is 0x003308C8
The allocated address that pA->dw2 points is 0x003308CC
The address of the local pA pointer (on stack) 0x0012FF7C

// Does showbase but include is incorrect ???
-------------*/

 

[Francesco S. Carta]

I just recently was educated that I should be using #include <iostream>
instead of using #include <iostream.h> as I had been doing.
However, even though the education cured one strange output issue, now
with the "correct" include spec I cannot get it to show the radix base like
it used to using the "incorrect" include spec.
Very much appreciate info as to what I am still missing. Code below
==============================================
#include <windows.h>
#include <iostream> // correct include spec
using namespace std;

// #include <iostream.h> // incorrect include spec

struct _Whatever { DWORD dw1; DWORD dw2; };
int main( ) {
_Whatever* pA = new _Whatever;
pA->dw1 = 0xAAAA;
pA->dw2 = 0xBBBB;

cout.flags ( ios::hex | ios::showbase ); // want to show radix

cout << "The allocated heap address that pA and/or pA->dw1 points is "
<< pA
<< "\nThe allocated address that pA->dw2 points is " << &pA->dw2
<< "\nThe address of the local pA pointer (on stack) " << &pA
<< endl;
delete pA; return 0; }

/*------------- program output if using correct include of #include
<iostream>
using namespace std;

The allocated heap address that pA and/or pA->dw1 points is 00331C48
The allocated address that pA->dw2 points is 00331C4C
The address of the local pA pointer (on stack) 0012FF7C

// Does not showbase ???
--------------*/

/*------------- program output if using incorrect include of #include
<iostream.h>

The allocated heap address that pA and/or pA->dw1 points is 0x003308C8
The allocated address that pA->dw2 points is 0x003308CC
The address of the local pA pointer (on stack) 0x0012FF7C

// Does showbase but include is incorrect ???
-------------*/

Works for me - MinGW 4.4.0 here - the leading 0x base gets correctly
printed by compiling and running the code with the _correct_ header
<iostream>.

I think you'll find tons of other mis-working features with that old
compiler you're using - VC 6.0 if I recall correctly... didn't you say
you have VS2005 under hands?

 

[Ron AF Greve]

Hi,

#include <iomanip>

| I just recently was educated that I should be using #include <iostream>
| instead of using #include <iostream.h> as I had been doing.
| However, even though the education cured one strange output issue, now
| with the "correct" include spec I cannot get it to show the radix base
like
| it used to using the "incorrect" include spec.
| Very much appreciate info as to what I am still missing. Code below
| ==============================================
| #include <windows.h>
| #include <iostream> // correct include spec
| using namespace std;
|
| // #include <iostream.h> // incorrect include spec
|
| struct _Whatever
| {
| DWORD dw1;
| DWORD dw2;
| };
|
| int main( )
| {
| _Whatever* pA = new _Whatever;
| pA->dw1 = 0xAAAA;
| pA->dw2 = 0xBBBB;
|
| cout.flags ( ios::hex | ios::showbase ); // want to show radix
|
| cout << "The allocated heap address that pA and/or pA->dw1 points is "
<< pA
| << "\nThe allocated address that pA->dw2 points is
" << &pA->dw2
| << "\nThe address of the local pA pointer (on stack)
" << &pA
| << endl;
| delete pA;
| return 0;
| }
|
| /*------------- program output if using correct include of
| #include <iostream>
| using namespace std;
|
| The allocated heap address that pA and/or pA->dw1 points is 00331C48
| The allocated address that pA->dw2 points is
00331C4C
| The address of the local pA pointer (on stack)
0012FF7C
|
| // Does not showbase ???
| --------------*/
|
| /*------------- program output if using incorrect include of
| #include <iostream.h>
|
| The allocated heap address that pA and/or pA->dw1 points is 0x003308C8
| The allocated address that pA->dw2 points is
0x003308CC
| The address of the local pA pointer (on stack)
0x0012FF7C
|
| // Does showbase but include is incorrect ???
| -------------*/

 

[James Lothian]

I just recently was educated that I should be using #include <iostream>
instead of using #include <iostream.h> as I had been doing.
However, even though the education cured one strange output issue, now
with the "correct" include spec I cannot get it to show the radix base like
it used to using the "incorrect" include spec.
Very much appreciate info as to what I am still missing. Code below

As far as I can tell, the problem is that you're outputting pointers, not
integers. As far as I can tell (standard 27.4.2.1.4), ios::hex and
ios::showbase control output of integers only.

James

 

[Francesco S. Carta]

Hi,

#include<iomanip>

Those manipulators are defined in <ios> which gets included by
<iostream> via <istream> (at least on my implementation, but I think it
is the correct behaviour as
http://www.cppreference.com/wiki/io/io_flags
reports), hence, there is no real need for <iomanip>.

Although that could eventually solve the OP problem, this is not really
requested.

The issue at hand is that the OP uses an old compiler which messes up
otherwise perfectly correct code.

Besides, please avoid top posting.

 

[RB]

Works for me - MinGW 4.4.0 here - the leading 0x base gets correctly

printed by compiling and running the code with the _correct_ header
<iostream>.

I think you'll find tons of other mis-working features with that old
compiler you're using - VC 6.0 if I recall correctly... didn't you say
you have VS2005 under hands?

Yes, that must be it, although I will have to reinstall it on my laptop
since the machine I had 2005 on had a drive failure.
Thanks for the reply

 

[RB]

#include <iomanip>

I tried that but it did not work. I suspect it is my old compiler.
I need to reinstall 2005 on my laptop.
Thanks for the reply though.

 

[RB]

As far as I can tell, the problem is that you're outputting pointers, not

integers. As far as I can tell (standard 27.4.2.1.4), ios::hex and
ios::showbase control output of integers only.

I think it is my old compiler. However in the past I have noted that
pointers will output with their "own base added and lower case hex"
regardless of how I have my cout.flags set. But I have never seen
them ignore the base printout completely.
In any case thanks for the reply.

 

[James Lothian]

I think it is my old compiler. However in the past I have noted that
pointers will output with their "own base added and lower case hex"
regardless of how I have my cout.flags set. But I have never seen
them ignore the base printout completely.
In any case thanks for the reply.

I've tried your example on vs2008, both with and without the cout.flags()
call, and got exactly the same results you did. So, I wouldn't rely on
a compiler update to fix the problem. Your best bet is probably to
convert the pointers to integers before outputting them.

James

 

[Francesco S. Carta]

I've tried your example on vs2008, both with and without the cout.flags()
call, and got exactly the same results you did. So, I wouldn't rely on
a compiler update to fix the problem. Your best bet is probably to
convert the pointers to integers before outputting them.

For what is worth, here with MinGW 4.4.0 it's the other way around: the
OP code outputs the addresses in hex notation and with the leading 0x
base even without the cout.flags() instruction.

I wonder what is the default behaviour for outputting addresses on a
"clean" cout stream. It might well be that the standard does not specify it.

 

[Francesco S. Carta]

For what is worth, here with MinGW 4.4.0 it's the other way around: the
OP code outputs the addresses in hex notation and with the leading 0x
base even without the cout.flags() instruction.

I wonder what is the default behaviour for outputting addresses on a
"clean" cout stream. It might well be that the standard does not specify
it.

As a further addition, even my compiler seems to agree that ios::hex
(along with its companions) affects only the output of integral values,
as pointed out by James in a previous post, so I agree with him that
converting the addresses to some appropriate integral value is the only
way to ensure proper formatting regardless of the compiler at hand.

 

[RB]

Wow, thanks to all of you guys, that did it. See code below
=======================================
#include <windows.h>
#include <iostream>
using namespace std;

struct _Whatever
{
DWORD dw1;
DWORD dw2;
};

int main()
{
_Whatever* pA = new _Whatever;
pA->dw1 = 0xAAAA;
pA->dw2 = 0xBBBB;
cout.flags ( ios::hex | ios::showbase );
cout << "The allocated heap address that pA and/or pA->dw1 points is " << DWORD(pA)
<< "\nThe allocated address that pA->dw2 points is " << DWORD(&pA->dw2)
<< "\nThe address of the local pA pointer (on stack) " << DWORD(&pA)
<< endl;
delete pA;
return 0;
}

/*------------- program output now
The allocated heap address that pA and/or pA->dw1 points is 0x331c48
The allocated address that pA->dw2 points is 0x331c4c
The address of the local pA pointer (on stack) 0x12ff7c
--------------*/
Would rather have uppercase hex letters but if I add in ios::uppercase
I also get an uppercase 0X radix and I like the 0x better. Course I guess
I could just stick with what I had before and just tack an "h" on the end of each.
Whatever thanks for replies.

 

[RB]

Thanks James you were correct, although I inadvertently posted my thanks
to the end of the thread. See there for complete reply.
And thanks again. I should have tried to convert them before I replied to you
the first time.

 

[James Kanze]

Ron AF Greve <me@localhost>, on 30/07/2010 15:37:09, wrote:

<edited, talking about including ios::hex and ios::showbase>

Those manipulators are defined in <ios> which gets included by
<iostream> via <istream> (at least on my implementation, but I think it
is the correct behaviour ashttp://www.cppreference.com/wiki/io/io_flags
reports), hence, there is no real need for <iomanip>.

Which manipulators? The posted code didn't have a single
manipulator in it. Generally, <iomanip> is necessary for the
manipulators which take a parameter (like std::setw), but not
for those which don't.

From a stylistic point of view: about the only standard
manipulator I use is std::setw. It's really just a personal
opinion, but I find something counter-intuitive about a
manipulator, buried deep in the output expression, permanently
changing global state.

Of course, in production code, you generally use project defined
manipulators, specifying logical markup. Correctly implemented,
these restore the initial state at the end of the full
expression.

 

[James Kanze]

As far as I can tell, the problem is that you're outputting
pointers, not integers. As far as I can tell (standard
27.4.2.1.4), ios::hex and ios::showbase control output of
integers only.

The format used to output pointers is very implementation
dependent. I think an implementation is allowed to take various
format flags into consideration, but it is certainly not
required to. (As far as I know, most implementations will
output pointers as hex, regardless of the base field value in
flags.)

 

[Francesco S. Carta]

Which manipulators? The posted code didn't have a single
manipulator in it. Generally,<iomanip> is necessary for the
manipulators which take a parameter (like std::setw), but not
for those which don't.

As I reported in the <edited> comment above, we were talking about
ios::hex and ios::showbase, that the OP put in a call to cout.flags().

Of course those are just integral values used as flags (as well as
manipulators) and of course I misnamed them, strictly speaking, but the
point should have gone through nonetheless.

 

[Ian Collins]

When C++ was standardized, C-compatibility was to be maintained as
much as reasonable for the porting of legacy programs.

As such, 2-libraries had to be standardized:

C : example> <iostream.h>
and
C++ : example> <iostream>

<iostream.h> has absolutely nothing to do with C or C compatibility.

It's simply a common pre-standard iostream library header.

 

[James Kanze]

When C++ was standardized, C-compatibility was to be
maintained as much as reasonable for the porting of legacy
programs.

As such, 2-libraries had to be standardized:

C : example > <iostream.h>

and
C++ : example > <iostream>

Historically, C++ had <iostream.h>, before standardization.
(You'll occasionally hear it refered to as the "classic
iostreams".) The standards committee chose to standardize
something different, putting it in <iostream>---there are subtle
differences in the two which means that code written with

I have not experimented using both libraries in the same
project myself, but I understand that that was the purpose
maintaining 2-separate, but compatible libraries.

Most vendors at the time did continue to support <iostream.h>,
to avoid breaking their client's code. The classical iostreams
are *not* compatible with the standard ones, however, and in
most implementations (but not all), mixing them will lead to
problems.