Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Compiler-generated functions and operators: A pain?

Reply
Thread Tools

Compiler-generated functions and operators: A pain?

 
 
JohnQ
Guest
Posts: n/a
 
      02-13-2007
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


 
Reply With Quote
 
 
 
 
Andre Kostur
Guest
Posts: n/a
 
      02-13-2007
"JohnQ" <(E-Mail Removed)> wrote in
news:1lpAh.18458$(E-Mail Removed) 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!
 
Reply With Quote
 
 
 
 
John Harrison
Guest
Posts: n/a
 
      02-13-2007
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
 
Reply With Quote
 
Grizlyk
Guest
Posts: n/a
 
      02-13-2007

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/


 
Reply With Quote
 
Piyo
Guest
Posts: n/a
 
      02-13-2007
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!
 
Reply With Quote
 
JohnQ
Guest
Posts: n/a
 
      02-14-2007

"Piyo" <(E-Mail Removed)> wrote in message
news:zuqAh.76225$(E-Mail Removed) 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


 
Reply With Quote
 
JohnQ
Guest
Posts: n/a
 
      02-14-2007

"John Harrison" <(E-Mail Removed)> wrote in message
news:MzpAh.9608$(E-Mail Removed)...
> 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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Static functions and C++ member functions mafiQ C++ 0 04-22-2009 08:33 PM
Does ruby have a similar functions to the Python dir and help functions? py Ruby 5 03-24-2007 08:54 AM
private virtual functions and pure virtual functions with bodies John Goche C++ 10 12-08-2006 04:00 PM
Shared functions vs Non-Shared Functions tshad ASP .Net 11 05-27-2005 05:53 PM
please help me in distinguish redefining functions, overloading functions and overriding functions. Xiangliang Meng C++ 1 06-21-2004 03:11 AM



Advertisments