gcc needs copy consturctor for inplace constructed object passed to func as reference, others not

Discussion in 'C++' started by nutty, Jun 15, 2006.

  1. nutty

    nutty Guest

    Hi all,

    I have the following problem ( explanation below code ):

    // main.cpp

    class noncopyable
    {
    protected:
    noncopyable() {}
    ~noncopyable() {}
    private: // emphasize the following members are private
    noncopyable( const noncopyable& );
    const noncopyable& operator=( const noncopyable& );
    };

    class MyClass: noncopyable
    {
    public:
    MyClass( ) { }
    };

    class IFormatter
    {
    public:
    void func( const MyClass& ) { }
    virtual ~IFormatter( ){}
    };
    int main()
    {
    MyClass mc;
    IFormatter f;
    f.func( MyClass( ) ); // doesn't work
    f.func( mc ); // works
    return 0;
    }

    This code is accepted by comeau in strict mode and by all MSVC that I
    had used 7.0 up to 8.0
    ..

    gcc 4.0.2 complains that the copy constructor of MyClass is private.

    Now I wannted to further simplify by removing the noncopyable base and
    instead making the copy and assignment private in MyClass.


    class MyClass
    {
    public:
    MyClass( ) { }
    private:
    MyClass( MyClass const& );
    MyClass const& operator=( MyClass const& );
    };

    class IFormatter
    {
    public:
    void func( MyClass const& ) { }
    virtual ~IFormatter( ){}
    };
    int main()
    {
    MyClass mc;
    IFormatter f;
    f.func( MyClass( ) );
    return 0;
    }


    surprisingly, now even comeau complains:

    Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
    Copyright 1988-2003 Comeau Computing. All rights reserved.
    MODE:strict errors C++

    "ComeauTest.c", line 35: error: "MyClass::MyClass(const MyClass &)",
    required for
    copy that was eliminated, is inaccessible
    f.func( MyClass( ) );
    ^


    Could it be possible that comeau is wrong for one or the other example?
    Or did I change something significantly in my simplification?

    Could someone try this with a gcc 4.1.x or 3.x.x ?

    I appreciate your help and thank you in advance.

    Ingo
     
    nutty, Jun 15, 2006
    #1
    1. Advertising

  2. nutty

    Butterfly Guest

    when you call f.func() like this

    f.func( MyClass( ) );

    compiler has to create tempolary object, that means copy contructor
    will be called. You declare copy constructor as a private, so that's
    why compiler complains you
     
    Butterfly, Jun 15, 2006
    #2
    1. Advertising

  3. Butterfly <> wrote:
    > when you call f.func() like this
    >
    > f.func( MyClass( ) );
    >
    > compiler has to create tempolary object, that means copy contructor
    > will be called. You declare copy constructor as a private, so that's
    > why compiler complains you


    I do not see why the copy ctor would have to be called. Afaik, the
    temporary is created using the ctor taking no arguments, and a const
    reference to this object is passed. No object copying involved.

    regards
    --
    jb

    (reply address in rot13, unscramble first)
     
    Jakob Bieling, Jun 15, 2006
    #3
  4. nutty wrote:
    > Hi all,
    >
    > I have the following problem ( explanation below code ):
    >
    > // main.cpp
    >
    > class noncopyable
    > {
    > protected:
    > noncopyable() {}
    > ~noncopyable() {}
    > private: // emphasize the following members are private
    > noncopyable( const noncopyable& );
    > const noncopyable& operator=( const noncopyable& );
    > };
    >
    > class MyClass: noncopyable
    > {
    > public:
    > MyClass( ) { }
    > };
    >
    > class IFormatter
    > {
    > public:
    > void func( const MyClass& ) { }
    > virtual ~IFormatter( ){}
    > };
    > int main()
    > {
    > MyClass mc;
    > IFormatter f;
    > f.func( MyClass( ) ); // doesn't work
    > f.func( mc ); // works
    > return 0;
    > }
    >
    > This code is accepted by comeau in strict mode and by all MSVC that I
    > had used 7.0 up to 8.0
    > .
    >
    > gcc 4.0.2 complains that the copy constructor of MyClass is private.
    >
    > Now I wannted to further simplify by removing the noncopyable base and
    > instead making the copy and assignment private in MyClass.
    >
    >
    > class MyClass
    > {
    > public:
    > MyClass( ) { }
    > private:
    > MyClass( MyClass const& );
    > MyClass const& operator=( MyClass const& );
    > };
    >
    > class IFormatter
    > {
    > public:
    > void func( MyClass const& ) { }
    > virtual ~IFormatter( ){}
    > };
    > int main()
    > {
    > MyClass mc;
    > IFormatter f;
    > f.func( MyClass( ) );
    > return 0;
    > }
    >
    >
    > surprisingly, now even comeau complains:
    >
    > Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
    > Copyright 1988-2003 Comeau Computing. All rights reserved.
    > MODE:strict errors C++
    >
    > "ComeauTest.c", line 35: error: "MyClass::MyClass(const MyClass &)",
    > required for
    > copy that was eliminated, is inaccessible
    > f.func( MyClass( ) );
    > ^
    >
    >
    > Could it be possible that comeau is wrong for one or the other example?
    > Or did I change something significantly in my simplification?


    Binding an rvalue to a const reference invokes implementation-defined
    behaviour. An implementation can bind directly to the object or copy
    construct a temporary object. Comeau obviously does one or the other
    depending on the context.

    In other words for your code to be portable the copy constructor must
    be accessible.

    > Could someone try this with a gcc 4.1.x or 3.x.x ?


    gcc 4.1.1 complains as well in both cases.
     
    Markus Schoder, Jun 15, 2006
    #4
  5. Markus Schoder wrote:
    > nutty wrote:
    > > Hi all,
    > >
    > > I have the following problem ( explanation below code ):
    > >
    > > // main.cpp
    > >
    > > class noncopyable
    > > {
    > > protected:
    > > noncopyable() {}
    > > ~noncopyable() {}
    > > private: // emphasize the following members are private
    > > noncopyable( const noncopyable& );
    > > const noncopyable& operator=( const noncopyable& );
    > > };
    > >
    > > class MyClass: noncopyable
    > > {
    > > public:
    > > MyClass( ) { }
    > > };
    > >
    > > class IFormatter
    > > {
    > > public:
    > > void func( const MyClass& ) { }
    > > virtual ~IFormatter( ){}
    > > };
    > > int main()
    > > {
    > > MyClass mc;
    > > IFormatter f;
    > > f.func( MyClass( ) ); // doesn't work
    > > f.func( mc ); // works
    > > return 0;
    > > }
    > >
    > > This code is accepted by comeau in strict mode and by all MSVC that I
    > > had used 7.0 up to 8.0
    > > .
    > >
    > > gcc 4.0.2 complains that the copy constructor of MyClass is private.
    > >
    > > Now I wannted to further simplify by removing the noncopyable base and
    > > instead making the copy and assignment private in MyClass.
    > >
    > >
    > > class MyClass
    > > {
    > > public:
    > > MyClass( ) { }
    > > private:
    > > MyClass( MyClass const& );
    > > MyClass const& operator=( MyClass const& );
    > > };
    > >
    > > class IFormatter
    > > {
    > > public:
    > > void func( MyClass const& ) { }
    > > virtual ~IFormatter( ){}
    > > };
    > > int main()
    > > {
    > > MyClass mc;
    > > IFormatter f;
    > > f.func( MyClass( ) );
    > > return 0;
    > > }
    > >
    > >
    > > surprisingly, now even comeau complains:
    > >
    > > Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
    > > Copyright 1988-2003 Comeau Computing. All rights reserved.
    > > MODE:strict errors C++
    > >
    > > "ComeauTest.c", line 35: error: "MyClass::MyClass(const MyClass &)",
    > > required for
    > > copy that was eliminated, is inaccessible
    > > f.func( MyClass( ) );
    > > ^
    > >
    > >
    > > Could it be possible that comeau is wrong for one or the other example?
    > > Or did I change something significantly in my simplification?

    >
    > Binding an rvalue to a const reference invokes implementation-defined
    > behaviour. An implementation can bind directly to the object or copy
    > construct a temporary object. Comeau obviously does one or the other
    > depending on the context.
    >
    > In other words for your code to be portable the copy constructor must
    > be accessible.


    Actually from the wording in the standard it looks like the copy
    constructor must be accessible in all cases even if the copy is not
    done which would mean that Comeau gets this wrong.
     
    Markus Schoder, Jun 15, 2006
    #5
  6. nutty

    nutty Guest

    Markus Schoder schrieb:


    >
    > Actually from the wording in the standard it looks like the copy
    > constructor must be accessible in all cases even if the copy is not
    > done which would mean that Comeau gets this wrong.


    Thank you,

    your answers, both, finally helped.

    So that means for me, either I need to avoid this syntax or I make the
    copy constructor available, knowing that at least in release mode no
    compiler would ever use it.

    Ingo
     
    nutty, Jun 15, 2006
    #6
  7. nutty

    Tom Widmer Guest

    Re: gcc needs copy consturctor for inplace constructed object passedto func as reference, others not

    Markus Schoder wrote:

    > Actually from the wording in the standard it looks like the copy
    > constructor must be accessible in all cases even if the copy is not
    > done which would mean that Comeau gets this wrong.


    Indeed, Daveed Vandevoorde admitted the bug in this post:

    http://groups.google.co.uk/group/comp.lang.c .moderated/msg/0bb0ffb131e94bea

    Tom
     
    Tom Widmer, Jun 15, 2006
    #7
    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. CRON
    Replies:
    24
    Views:
    203,710
    Adrienne Boswell
    Jun 20, 2006
  2. Johnny
    Replies:
    3
    Views:
    482
    Robert Kern
    Aug 23, 2005
  3. nagrik
    Replies:
    5
    Views:
    336
  4. dmitrey
    Replies:
    3
    Views:
    334
    dmitrey
    Apr 29, 2007
  5. Replies:
    0
    Views:
    183
Loading...

Share This Page