Compiler-generated functions and operators: A pain?

[JohnQ]

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

 

[Andre Kostur]

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!

 

[John Harrison]

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

 

[Grizlyk]

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.

 

[Piyo]

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!

 

[JohnQ]

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]

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