«

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" <> wrote in
news:1lpAh.18458$ et:

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

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

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/

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" <> wrote in message
news:zuqAh.76225$ et...
> 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

"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