another strange output?

Discussion in 'C++' started by RB, Jul 30, 2010.

  1. RB

    RB Guest

    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 ???
    -------------*/
     
    RB, Jul 30, 2010
    #1
    1. Advertising

  2. RB <NoMail@NoSpam>, on 30/07/2010 08:43:13, wrote:

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

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
     
    Francesco S. Carta, Jul 30, 2010
    #2
    1. Advertising

  3. RB

    Ron AF Greve Guest

    Hi,

    #include <iomanip>

    "RB" <NoMail@NoSpam> wrote in message news:...
    | 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 ???
    | -------------*/

    --
    Regards, Ron AF Greve

    http://informationsuperhighway.eu
     
    Ron AF Greve, Jul 30, 2010
    #3
  4. RB wrote:
    > 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
     
    James Lothian, Jul 30, 2010
    #4
  5. Ron AF Greve <me@localhost>, on 30/07/2010 15:37:09, wrote:

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

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

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
     
    Francesco S. Carta, Jul 30, 2010
    #5
  6. RB

    RB Guest

    > 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, Jul 30, 2010
    #6
  7. RB

    RB Guest


    > #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, Jul 30, 2010
    #7
  8. RB

    RB Guest

    > 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.
     
    RB, Jul 30, 2010
    #8
  9. RB wrote:
    >> 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.

    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
     
    James Lothian, Jul 30, 2010
    #9
  10. James Lothian <>, on 30/07/2010
    15:27:11, wrote:

    > RB wrote:
    >>> 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.

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

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
     
    Francesco S. Carta, Jul 30, 2010
    #10
  11. Francesco S. Carta <>, on 30/07/2010 16:38:58, wrote:

    > James Lothian <>, on 30/07/2010
    > 15:27:11, wrote:
    >
    >> RB wrote:
    >>>> 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.

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


    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.

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
     
    Francesco S. Carta, Jul 30, 2010
    #11
  12. RB

    RB Guest

    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, Jul 30, 2010
    #12
  13. RB

    RB Guest

    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.
     
    RB, Jul 30, 2010
    #13
  14. RB

    James Kanze Guest

    On Jul 30, 3:15 pm, "Francesco S. Carta" <> wrote:
    > Ron AF Greve <me@localhost>, on 30/07/2010 15:37:09, wrote:


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


    > > #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 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
     
    James Kanze, Jul 31, 2010
    #14
  15. RB

    James Kanze Guest

    On Jul 30, 3:10 pm, James Lothian
    <> wrote:
    > RB wrote:
    > > 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.


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

    --
    James Kanze
     
    James Kanze, Jul 31, 2010
    #15
  16. James Kanze <>, on 31/07/2010 05:08:28, wrote:

    > On Jul 30, 3:15 pm, "Francesco S. Carta"<> wrote:
    >> Ron AF Greve<me@localhost>, on 30/07/2010 15:37:09, wrote:

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

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


    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.

    --
    FSC - http://userscripts.org/scripts/show/59948
    http://fscode.altervista.org - http://sardinias.com
     
    Francesco S. Carta, Jul 31, 2010
    #16
  17. RB

    Ian Collins Guest

    On 08/ 1/10 07:44 AM, TheGunslinger wrote:
    > On Fri, 30 Jul 2010 08:43:13 -0400, "RB"<NoMail@NoSpam> wrote:
    >
    >> 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
    >> <SNIP>

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

    --
    Ian Collins
     
    Ian Collins, Jul 31, 2010
    #17
  18. RB

    James Kanze Guest

    On Jul 31, 8:44 pm, TheGunslinger <>
    wrote:
    > 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>


    There was never an <iostream.h> in C.

    > 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
    <iostream.h> cannot be ported without significant work.

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

    --
    James Kanze
     
    James Kanze, Aug 1, 2010
    #18
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nikk & Jak Anderson

    GZIP output and input strange behaviour

    Nikk & Jak Anderson, Apr 26, 2004, in forum: Java
    Replies:
    2
    Views:
    1,168
    Roedy Green
    Apr 26, 2004
  2. Miroslaw Osys

    very strange gcc output

    Miroslaw Osys, Sep 7, 2003, in forum: C Programming
    Replies:
    4
    Views:
    465
    Emmanuel Delahaye
    Sep 7, 2003
  3. Harvey Twyman
    Replies:
    8
    Views:
    578
    August Derleth
    Oct 25, 2003
  4. Paul
    Replies:
    1
    Views:
    438
  5. jmr
    Replies:
    2
    Views:
    345
Loading...

Share This Page