cout printing and function tracing

Discussion in 'C++' started by Jacopo, Feb 10, 2011.

  1. Jacopo

    Jacopo Guest

    Hi, I'm running this code:

    class C {
    private:
    int d;
    public:
    C(string s=""): d(s.size()) {}
    explicit C(int n): d(n) { cout<<"*1*"; } // 1
    operator int() { cout<<"*2*";return d; } // 2
    C operator+(C x) { cout<<"*3*";return C(d+x.d); } // 3
    };

    main() {
    C a, b("pippo"), c(3); cout<<std::endl;
    cout << a << ' ' << 1+b << ' ' << c+4 << ' ' << c+b;
    }


    It prints:
    *1*
    *3**1**2**2**2**2*0 6 7 8
    Look at the second line: ok for the last four numbers, but output
    produced from function calls seems to start from the end (c+b
    evaluation), in reverse order.
    I'm not sure why, so could someone clarify this behaviour ?

    Thanks.
     
    Jacopo, Feb 10, 2011
    #1
    1. Advertising

  2. Jacopo

    James Kanze Guest

    On Feb 10, 4:45 pm, Jacopo <> wrote:
    > Hi, I'm running this code:


    > class C {
    > private:
    > int d;
    > public:
    > C(string s=""): d(s.size()) {}
    > explicit C(int n): d(n) { cout<<"*1*"; } // 1
    > operator int() { cout<<"*2*";return d; } // 2
    > C operator+(C x) { cout<<"*3*";return C(d+x.d); } // 3
    > };


    > main() {
    > C a, b("pippo"), c(3); cout<<std::endl;
    > cout << a << ' ' << 1+b << ' ' << c+4 << ' ' << c+b;
    > }


    > It prints:
    > *1*
    > *3**1**2**2**2**2*0 6 7 8
    > Look at the second line: ok for the last four numbers, but output
    > produced from function calls seems to start from the end (c+b
    > evaluation), in reverse order.


    The order function arguments are evaluated is unspecified. The
    only order guaranteed in your output is that the characters
    "0 6 7 8" appear in that order. The *n* can appear in
    practically any order, and in almost any place within or before
    these characters.

    --
    James Kanze
     
    James Kanze, Feb 10, 2011
    #2
    1. Advertising

  3. Jacopo

    Jacopo Guest

    On 10 Feb, 19:51, James Kanze <> wrote:
    >
    > The order function arguments are evaluated is unspecified.  The
    > only order guaranteed in your output is that the characters
    > "0 6 7 8" appear in that order.  The *n* can appear in
    > practically any order, and in almost any place within or before
    > these characters.
    >
    > --
    > James Kanze



    Ok, thanks.
    I've another question: nearly the same code, without "explicit"
    keyword on C(int).

    class C {
    private:
    int d;
    public:
    C(string s=""): d(s.size()) {}
    C(int n): d(n)
    operator int() {return d;}
    C operator+(C x) {return C(d+x.d);}
    };

    main() {
    C a, b("pippo"), c(3);
    cout<<c+4;
    }

    It does not compile, giving an error of "ambiguous overload for
    ‘operator+’ in ‘c + 4’ ". I'm thinking that:
    - the c+4 expression calls C operator+(C x)
    - the "4" integer gets implicitly converted in a temporary C object
    and then passed to x parameter
    - and so the body executed
    Where is the ambiguity ? Perhaps, with standard + operator ?
     
    Jacopo, Feb 10, 2011
    #3
  4. Jacopo

    Ian Collins Guest

    On 02/11/11 11:00 AM, Jacopo wrote:
    > On 10 Feb, 19:51, James Kanze<> wrote:
    >>
    >> The order function arguments are evaluated is unspecified. The
    >> only order guaranteed in your output is that the characters
    >> "0 6 7 8" appear in that order. The *n* can appear in
    >> practically any order, and in almost any place within or before
    >> these characters.

    >
    > Ok, thanks.
    > I've another question: nearly the same code, without "explicit"
    > keyword on C(int).
    >
    > class C {
    > private:
    > int d;
    > public:
    > C(string s=""): d(s.size()) {}
    > C(int n): d(n)


    Missing {}?

    > operator int() {return d;}
    > C operator+(C x) {return C(d+x.d);}
    > };
    >
    > main() {


    missing int.

    > C a, b("pippo"), c(3);
    > cout<<c+4;
    > }
    >
    > It does not compile, giving an error of "ambiguous overload for
    > ‘operator+’ in ‘c + 4’ ". I'm thinking that:
    > - the c+4 expression calls C operator+(C x)
    > - the "4" integer gets implicitly converted in a temporary C object
    > and then passed to x parameter
    > - and so the body executed
    > Where is the ambiguity ? Perhaps, with standard + operator ?


    Yes, c can be converted to int, so you could have

    c.operator int() + 4;

    or

    c + C(4)

    Now you can see why conversion operators are a pain!

    --
    Ian Collins
     
    Ian Collins, Feb 10, 2011
    #4
  5. Jacopo

    Jacopo Guest

    On 10 Feb, 23:18, Ian Collins <> wrote:
    >
    > Missing {}?
    >


    Yeah sorry, it was the copy/paste fault.

    > Yes, c can be converted to int, so you could have
    >
    > c.operator int() + 4;
    >
    > or
    >
    > c + C(4)
    >
    > Now you can see why conversion operators are a pain!
    >


    ....I see.
    From what I've understood, it's a matter of overload resolution. The
    compiler creates a set of candidates function and selects the most
    viable...but in the above case standard operator+ and redefined member
    operator+ have the same "rank", so basically it cannot choose. Right ?
     
    Jacopo, Feb 11, 2011
    #5
  6. Jacopo

    Paul Guest

    "Jacopo" <> wrote in message
    news:...
    > On 10 Feb, 23:18, Ian Collins <> wrote:
    >>
    >> Missing {}?
    >>

    >
    > Yeah sorry, it was the copy/paste fault.
    >
    >> Yes, c can be converted to int, so you could have
    >>
    >> c.operator int() + 4;
    >>
    >> or
    >>
    >> c + C(4)
    >>
    >> Now you can see why conversion operators are a pain!
    >>

    >
    > ...I see.
    > From what I've understood, it's a matter of overload resolution. The
    > compiler creates a set of candidates function and selects the most
    > viable...but in the above case standard operator+ and redefined member
    > operator+ have the same "rank", so basically it cannot choose. Right ?
    >
    >

    Hi I don't have a clue what this thread is about but I notiice Ian Collins
    has commented on it. I cannot resist this opportunity to have a poke at Ian
    so I say please be carefull about what Ian has to say. He appears to be a
    typical example of an *average* programmer trying to pretend he is an
    expert.
    Thus my interest in this thread is only to analyze Ians competence.
     
    Paul, Feb 11, 2011
    #6
  7. Jacopo

    Jacopo Guest

    On 11 Feb, 23:27, "Paul" <> wrote:
    > Hi I don't have a clue what this thread is about but I notiice Ian Collins
    > has commented on it. I cannot resist this opportunity to have a poke at Ian
    > so I say please be carefull about what Ian has to say. He appears to be a
    > typical example of an *average* programmer trying to pretend he is an
    > expert.
    > Thus my interest in this thread is only to analyze Ians competence.


    Nice.
    But if you want to check Ian's competence in this thread, I think you
    should know the answer to my question.
    So please, make me aware. :)
     
    Jacopo, Feb 11, 2011
    #7
  8. Jacopo

    Ian Collins Guest

    On 02/11/11 01:02 PM, Jacopo wrote:
    > On 10 Feb, 23:18, Ian Collins<> wrote:
    >>
    >> Missing {}?
    >>

    >
    > Yeah sorry, it was the copy/paste fault.
    >
    >> Yes, c can be converted to int, so you could have
    >>
    >> c.operator int() + 4;
    >>
    >> or
    >>
    >> c + C(4)
    >>
    >> Now you can see why conversion operators are a pain!
    >>

    >
    > ....I see.
    > From what I've understood, it's a matter of overload resolution. The
    > compiler creates a set of candidates function and selects the most
    > viable...but in the above case standard operator+ and redefined member
    > operator+ have the same "rank", so basically it cannot choose. Right ?


    The ambiguity comes from the conversion operator and constructor; c can
    be converted to an int or 4 can be converted to a C.

    If you make the constructor explicit, only the conversion operator can
    be used and the ambiguity is removed.

    --
    Ian Collins
     
    Ian Collins, Feb 12, 2011
    #8
  9. Jacopo

    Paul Guest

    "Jacopo" <> wrote in message
    news:...
    > On 11 Feb, 23:27, "Paul" <> wrote:
    >> Hi I don't have a clue what this thread is about but I notiice Ian
    >> Collins
    >> has commented on it. I cannot resist this opportunity to have a poke at
    >> Ian
    >> so I say please be carefull about what Ian has to say. He appears to be a
    >> typical example of an *average* programmer trying to pretend he is an
    >> expert.
    >> Thus my interest in this thread is only to analyze Ians competence.

    >
    > Nice.
    > But if you want to check Ian's competence in this thread, I think you
    > should know the answer to my question.
    > So please, make me aware. :)
    >

    Don't want to get too tuned into C++ atm, I'm swtiching to Java.

    GL.
     
    Paul, Feb 13, 2011
    #9
    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. abi

    man cout or info cout

    abi, Jun 27, 2003, in forum: C++
    Replies:
    2
    Views:
    1,660
  2. Pmb

    std::cout vs cout

    Pmb, Jun 2, 2004, in forum: C++
    Replies:
    2
    Views:
    4,427
    Leor Zolman
    Jun 2, 2004
  3. Replies:
    4
    Views:
    327
    Howard
    Sep 15, 2005
  4. Stefan Ram

    Re: cout vs std::cout

    Stefan Ram, Sep 28, 2008, in forum: C++
    Replies:
    7
    Views:
    500
  5. Hendrik Schober

    Re: cout vs std::cout

    Hendrik Schober, Sep 28, 2008, in forum: C++
    Replies:
    7
    Views:
    451
    Jerry Coffin
    Oct 7, 2008
Loading...

Share This Page