Compiler-generated functions and operators: A pain?

Discussion in 'C++' started by JohnQ, Feb 13, 2007.

  1. JohnQ

    JohnQ Guest

    I like, non-copyable, non-assignable and, most often,
    non-default-constructable also, as a starting point for class design:

    class SomeClass
    {
    SomeClass(); // disallow default construction
    SomeClass(const SomeClass&); // disallow copy construction
    SomeClass& operator=(const SomeClass&); // disallow assignment

    public:
    // other allowed constructors, destructor, operators, functions
    } ;

    I'm swaying toward the thought that compiler-generated functions are a pain
    and go against logical language design: when not specified, a default
    constructor, a destructor, a copy constructor and an assignment operator are
    generated by the compiler. But to prevent them, you have to do typing as
    shown above, leaving out the implementation. Wouldn't it make more sense to
    say, "If it's not declared in the class declaration, then the class object
    instances will not have the behavior in the compiled code"? How
    counter-intuitive can one be?! To me, "what you see is what you get" seems
    better. Is there a good reason why it is like it is or could it have just as
    easily gone the other way? Which way would you prefer?

    John
    JohnQ, Feb 13, 2007
    #1
    1. Advertising

  2. JohnQ

    Andre Kostur Guest

    "JohnQ" <> wrote in
    news:1lpAh.18458$:

    > I like, non-copyable, non-assignable and, most often,
    > non-default-constructable also, as a starting point for class design:
    >
    > class SomeClass
    > {
    > SomeClass(); // disallow default construction
    > SomeClass(const SomeClass&); // disallow copy construction
    > SomeClass& operator=(const SomeClass&); // disallow assignment
    >
    > public:
    > // other allowed constructors, destructor, operators, functions
    > } ;
    >
    > I'm swaying toward the thought that compiler-generated functions are a
    > pain and go against logical language design: when not specified, a
    > default constructor, a destructor, a copy constructor and an
    > assignment operator are generated by the compiler. But to prevent
    > them, you have to do typing as shown above, leaving out the
    > implementation. Wouldn't it make more sense to say, "If it's not
    > declared in the class declaration, then the class object instances
    > will not have the behavior in the compiled code"? How
    > counter-intuitive can one be?! To me, "what you see is what you get"
    > seems better. Is there a good reason why it is like it is or could it
    > have just as easily gone the other way? Which way would you prefer?


    No. See:

    struct someStruct
    {
    int abc;
    };


    According to your description, this would cause vast amounts of C-
    originated code to break. And you forgot to mention the Destructor. If
    one is not supplied, then objects of that class are undestructable!
    Andre Kostur, Feb 13, 2007
    #2
    1. Advertising

  3. JohnQ wrote:
    > I like, non-copyable, non-assignable and, most often,
    > non-default-constructable also, as a starting point for class design:
    >
    > class SomeClass
    > {
    > SomeClass(); // disallow default construction
    > SomeClass(const SomeClass&); // disallow copy construction
    > SomeClass& operator=(const SomeClass&); // disallow assignment
    >
    > public:
    > // other allowed constructors, destructor, operators, functions
    > } ;
    >
    > I'm swaying toward the thought that compiler-generated functions are a pain
    > and go against logical language design: when not specified, a default
    > constructor, a destructor, a copy constructor and an assignment operator are
    > generated by the compiler. But to prevent them, you have to do typing as
    > shown above, leaving out the implementation. Wouldn't it make more sense to
    > say, "If it's not declared in the class declaration, then the class object
    > instances will not have the behavior in the compiled code"? How
    > counter-intuitive can one be?! To me, "what you see is what you get" seems
    > better. Is there a good reason why it is like it is or could it have just as
    > easily gone the other way? Which way would you prefer?
    >
    > John
    >
    >


    The reason is very simple, compatibility with C. It could have gone
    another way, BS could have decided to apply different rules to classes
    and structs. Default copy ctors etc. would only have applied to structs.
    I think this would be my preferred solution, but I don't think it's a
    huge deal.

    John
    John Harrison, Feb 13, 2007
    #3
  4. JohnQ

    Grizlyk Guest

    JohnQ wrote:
    >
    > I'm swaying toward the thought that compiler-generated functions are a
    > pain and go against logical language design: when not specified, a default
    > constructor, a destructor, a copy constructor and an assignment operator
    > are generated by the compiler.


    Well desined classes use small one, as "list" or "vector", and safe for
    copying. At least half of classes can be copied automatically, so it does
    not matter to do auto generation or not to do, but old code expect
    auto-copying.


    --
    Maksim A. Polyanin

    "In thi world of fairy tales rolls are liked olso"
    /Gnume/
    Grizlyk, Feb 13, 2007
    #4
  5. JohnQ

    Piyo Guest

    JohnQ wrote:
    > I like, non-copyable, non-assignable and, most often,
    > non-default-constructable also, as a starting point for class design:
    >
    > class SomeClass
    > {
    > SomeClass(); // disallow default construction
    > SomeClass(const SomeClass&); // disallow copy construction
    > SomeClass& operator=(const SomeClass&); // disallow assignment
    >
    > public:
    > // other allowed constructors, destructor, operators, functions
    > } ;
    >
    > I'm swaying toward the thought that compiler-generated functions are a pain
    > and go against logical language design: when not specified, a default
    > constructor, a destructor, a copy constructor and an assignment operator are
    > generated by the compiler. But to prevent them, you have to do typing as
    > shown above, leaving out the implementation. Wouldn't it make more sense to
    > say, "If it's not declared in the class declaration, then the class object
    > instances will not have the behavior in the compiled code"? How
    > counter-intuitive can one be?! To me, "what you see is what you get" seems
    > better. Is there a good reason why it is like it is or could it have just as
    > easily gone the other way? Which way would you prefer?
    >
    > John
    >
    >

    BTW, John, here is an idea. I think you can use templates to help
    create those concepts of non-copyable, etc. and derive from those
    templates to insure the concept.

    I hope this helps! BTW boost (www.boost.org) has some examples of this
    idea in practice.

    http://www.boost.org/libs/utility/utility.htm

    This shows the non-copyable concept.

    As for non-default constructable, I am not sure but I thought that if
    you only specify ctors that cannot be effectively reduced to a default
    constructor, it means that your class is non-default constructable. eg.
    Note: tested gcc3.4.3 and this class is non-default constructable.

    class A
    {
    public:
    A( int var );
    };

    This version can be default-constructable:
    class A
    {
    public:
    A( int var=0 );
    };

    Hope that helps!
    Piyo, Feb 13, 2007
    #5
  6. JohnQ

    JohnQ Guest

    "Piyo" <> wrote in message
    news:zuqAh.76225$...
    > JohnQ wrote:
    >> I like, non-copyable, non-assignable and, most often,
    >> non-default-constructable also, as a starting point for class design:
    >>
    >> class SomeClass
    >> {
    >> SomeClass(); // disallow default construction
    >> SomeClass(const SomeClass&); // disallow copy construction
    >> SomeClass& operator=(const SomeClass&); // disallow assignment
    >>
    >> public:
    >> // other allowed constructors, destructor, operators, functions
    >> } ;
    >>
    >> I'm swaying toward the thought that compiler-generated functions are a
    >> pain and go against logical language design: when not specified, a
    >> default constructor, a destructor, a copy constructor and an assignment
    >> operator are generated by the compiler. But to prevent them, you have to
    >> do typing as shown above, leaving out the implementation. Wouldn't it
    >> make more sense to say, "If it's not declared in the class declaration,
    >> then the class object instances will not have the behavior in the
    >> compiled code"? How counter-intuitive can one be?! To me, "what you see
    >> is what you get" seems better. Is there a good reason why it is like it
    >> is or could it have just as easily gone the other way? Which way would
    >> you prefer?
    >>
    >> John

    > BTW, John, here is an idea. I think you can use templates to help
    > create those concepts of non-copyable, etc. and derive from those
    > templates to insure the concept.
    >
    > I hope this helps! BTW boost (www.boost.org) has some examples of this
    > idea in practice.
    >
    > http://www.boost.org/libs/utility/utility.htm
    >
    > This shows the non-copyable concept.


    It's not a template, but rather just a base class that does the same as in
    my above example pretty much. I prefer not to create "class explosion" by
    using a base class such as in Boost. Right now I'm building very "course
    grained" classes so my thought that the compiler defined functions are a
    pain is based on that. When I get back to doing more "fine grained" work my
    opinion may change.

    John
    JohnQ, Feb 14, 2007
    #6
  7. JohnQ

    JohnQ Guest

    "John Harrison" <> wrote in message
    news:MzpAh.9608$...
    > JohnQ wrote:
    >> I like, non-copyable, non-assignable and, most often,
    >> non-default-constructable also, as a starting point for class design:
    >>
    >> class SomeClass
    >> {
    >> SomeClass(); // disallow default construction
    >> SomeClass(const SomeClass&); // disallow copy construction
    >> SomeClass& operator=(const SomeClass&); // disallow assignment
    >>
    >> public:
    >> // other allowed constructors, destructor, operators, functions
    >> } ;
    >>
    >> I'm swaying toward the thought that compiler-generated functions are a
    >> pain and go against logical language design: when not specified, a
    >> default constructor, a destructor, a copy constructor and an assignment
    >> operator are generated by the compiler. But to prevent them, you have to
    >> do typing as shown above, leaving out the implementation. Wouldn't it
    >> make more sense to say, "If it's not declared in the class declaration,
    >> then the class object instances will not have the behavior in the
    >> compiled code"? How counter-intuitive can one be?! To me, "what you see
    >> is what you get" seems better. Is there a good reason why it is like it
    >> is or could it have just as easily gone the other way? Which way would
    >> you prefer?
    >>
    >> John

    >
    > The reason is very simple, compatibility with C. It could have gone
    > another way, BS could have decided to apply different rules to classes and
    > structs. Default copy ctors etc. would only have applied to structs. I
    > think this would be my preferred solution, but I don't think it's a huge
    > deal.


    In "The Design and Evolution of C++" (1994) on pg. 76, Stroustrup gives his
    rationale for the concept of structs and classes being the same. Knowing
    that I consciously always use structs and classes as distinctly different
    animals, I would have not burdened classes with the C struct concept, I
    think. But then again, deriving from a struct and then being able to use the
    derived class as a struct may be enough to appreciate the way he chose to
    define it: making classes from Windows structures like POINT (tagPOINT?) for
    example, which makes it easy to manipulate point data while still being able
    to automagically pass the class object instance to a function requiring the
    POINT structure.

    John
    JohnQ, Feb 14, 2007
    #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. Replies:
    4
    Views:
    1,822
    Victor Bazarov
    Jul 26, 2006
  2. Replies:
    1
    Views:
    323
  3. Replies:
    5
    Views:
    372
    Steve Holden
    Feb 23, 2009
  4. Replies:
    0
    Views:
    724
  5. Replies:
    1
    Views:
    553
Loading...

Share This Page