Class objects work like built-in types, but is it worth it?

**Cupu** · Oct 23 '08, 01:25 PM

Re: Class objects work like built-in types, but is it worth it?

On Oct 23, 2:41 pm, tonytech08 <tonytec...@gma il.comwrote:

How valuable is it that class objects behave like built-in types? I
appears that the whole "constructo r doesn't return a value because
they are called by the compiler" thing is to enable built-in-like
behavior for objects of class type. That leads to the "necessity" for
the exception machinery so that errors from constructors can be
handled. Is all that complexity worth it just to get built-in-like
behavior from class objects? Maybe a better architecture would be for
built-in types and class object types to be accepted as fundamentally
different animals and forego the extensive machinery required to
shoehorn class objects into being something they are not!

If I understand your question correctly I'd like to ask what values
would you like to get returned from a constructor?
Obviously since the constructor constructs an object you can receive
either a success or a failure?
Following that logic what happens to the object if the constructor
fails?
The answer to that should be that there is no object ... it couldn't
be constructed thus you have no object which a situation where an
exception looks like exactly the thing you'd want have.
That is, if there's no object force the user to treat that error
(rather than him forgetting to check the return value and segfault
sometime later for no apparent reason).

**=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=** · Oct 23 '08, 05:15 PM

Re: Class objects work like built-in types, but is it worth it?

On 2008-10-23 13:41, tonytech08 wrote:

How valuable is it that class objects behave like built-in types? I
appears that the whole "constructo r doesn't return a value because
they are called by the compiler" thing is to enable built-in-like
behavior for objects of class type. That leads to the "necessity" for
the exception machinery so that errors from constructors can be
handled. Is all that complexity worth it just to get built-in-like
behavior from class objects? Maybe a better architecture would be for
built-in types and class object types to be accepted as fundamentally
different animals and forego the extensive machinery required to
shoehorn class objects into being something they are not!

And what would you like "new MyClass()" to return?

--
Erik WikstrÃ¶m

**tonytech08** · Oct 23 '08, 05:45 PM

Re: Class objects work like built-in types, but is it worth it?

On Oct 23, 12:13 pm, Erik Wikström <Erik-wikst...@telia. comwrote:

On 2008-10-23 13:41, tonytech08 wrote:
>

How valuable is it that class objects behave like built-in types? I
appears that the whole "constructo r doesn't return a value because
they are called by the compiler" thing is to enable built-in-like
behavior for objects of class type. That leads to the "necessity" for
the exception machinery so that errors from constructors can be
handled. Is all that complexity worth it just to get built-in-like
behavior from class objects? Maybe a better architecture would be for
built-in types and class object types to be accepted as fundamentally
different animals and forego the extensive machinery required to
shoehorn class objects into being something they are not!

>
And what would you like "new MyClass()" to return?

OK, 2 responses and both are missing my question so I'll try to
rephrase and clarify. The question is about the value of class objects
behaving like built-in types: How valuable/beneficial/desireable is
that? Or more specifically, was it worth introducing all that
ancillary machinery (exceptions) to get that feature?

**acehreli@gmail.com** · Oct 23 '08, 05:45 PM

Re: Class objects work like built-in types, but is it worth it?

On Oct 23, 10:38 am, tonytech08 <tonytec...@gma il.comwrote:

The question is about the value of class objects
behaving like built-in types: How valuable/beneficial/desireable is
that? Or more specifically, was it worth introducing all that
ancillary machinery (exceptions) to get that feature?

I am not convinced that exceptions were introduced so that we could
say

MyType m;

I read the Design and Evolution of C++ a long time ago but don't
remember registering anything like that. Perhaps all objects could be
pointers and NULL could be returned?

MyType * m = new MyType();

**acehreli@gmail.com** · Oct 23 '08, 05:55 PM

Re: Class objects work like built-in types, but is it worth it?

Fat fingers! :) The post went out incomplete.

On Oct 23, 10:44 am, acehr...@gmail. com wrote:

On Oct 23, 10:38 am, tonytech08 <tonytec...@gma il.comwrote:
>

The question is about the value of class objects
behaving like built-in types: How valuable/beneficial/desireable is
that? Or more specifically, was it worth introducing all that
ancillary machinery (exceptions) to get that feature?

>
I am not convinced that exceptions were introduced so that we could
say
>
MyType m;
>
I read the Design and Evolution of C++ a long time ago but don't
remember registering anything like that. Perhaps all objects could be
pointers and NULL could be returned?
>
MyType * m = new MyType();

[I was going to add...]

Then we would have to check every object creation:

if (!m) // cannot continue

We wouldn't be able to chain function calls:

calculate(make_ first(), make_second());

It should be done noisily:

FirstType * f = make_first();
if (!f) goto bail;

SecondType * s = make_second();
if (!s) goto bail;

calculate(f, s);

That would be C-like in a bad way. :)

Can you think of a better way without exceptions from constructors?

Ali

**=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=** · Oct 23 '08, 06:15 PM

Re: Class objects work like built-in types, but is it worth it?

On 2008-10-23 19:38, tonytech08 wrote:

On Oct 23, 12:13 pm, Erik WikstrÃ¶m <Erik-wikst...@telia. comwrote:

>On 2008-10-23 13:41, tonytech08 wrote:
>>

How valuable is it that class objects behave like built-in types? I
appears that the whole "constructo r doesn't return a value because
they are called by the compiler" thing is to enable built-in-like
behavior for objects of class type. That leads to the "necessity" for
the exception machinery so that errors from constructors can be
handled. Is all that complexity worth it just to get built-in-like
behavior from class objects? Maybe a better architecture would be for
built-in types and class object types to be accepted as fundamentally
different animals and forego the extensive machinery required to
shoehorn class objects into being something they are not!

>>
>And what would you like "new MyClass()" to return?

>
OK, 2 responses and both are missing my question so I'll try to
rephrase and clarify. The question is about the value of class objects
behaving like built-in types: How valuable/beneficial/desireable is
that? Or more specifically, was it worth introducing all that
ancillary machinery (exceptions) to get that feature?

Yes, it is desirable to have objects look like built-in types. But you
do not have to have exceptions to do this, you could instead requiring a
failing constructor to construct the object into a failed state which
can be checked after construction:

MyObject obj;
if (obj.invalid())
{
// Handle situation
}

The reason for exceptions is that they allow for a much better and
simpler error handling than to old way of return-codes. In fact even
languages which does not have object might have exceptions (such as ML,
a functional language).

--
Erik WikstrÃ¶m

**peter koch** · Oct 23 '08, 07:15 PM

Re: Class objects work like built-in types, but is it worth it?

On 23 Okt., 19:38, tonytech08 <tonytec...@gma il.comwrote:

On Oct 23, 12:13 pm, Erik Wikström <Erik-wikst...@telia. comwrote:
>

On 2008-10-23 13:41, tonytech08 wrote:

>

How valuable is it that class objects behave like built-in types? I
appears that the whole "constructo r doesn't return a value because
they are called by the compiler" thing is to enable built-in-like
behavior for objects of class type. That leads to the "necessity" for
the exception machinery so that errors from constructors can be
handled. Is all that complexity worth it just to get built-in-like
behavior from class objects? Maybe a better architecture would be for
built-in types and class object types to be accepted as fundamentally
different animals and forego the extensive machinery required to
shoehorn class objects into being something they are not!

>

And what would you like "new MyClass()" to return?

>
OK, 2 responses and both are missing my question so I'll try to
rephrase and clarify. The question is about the value of class objects
behaving like built-in types: How valuable/beneficial/desireable is
that? Or more specifically, was it worth introducing all that
ancillary machinery (exceptions) to get that feature?

What makes you believe that exceptions are useful only for catching
errors in constructors? On the contrary, exceptions are a general and
useful error-handling mechanism.
As for your original question, classes behaving like ordinary built-in
types are quite useful. Imagine not being able to have all the many
useful types available that naturally are perceived as value-types:
std::string, complex and the many containers such as std::vector.

/Peter

**Hendrik Schober** · Oct 23 '08, 09:05 PM

Re: Class objects work like built-in types, but is it worth it?

tonytech08 wrote:

How valuable is it that class objects behave like built-in types? [...]

How valuable do you consider 'std::string'? 'std::ofstream?
'std::complex'? All those container types? Function objects?
Iterators? Thread classes? Automatic locks? ...?

Schobi

**tonytech08** · Oct 23 '08, 09:15 PM

Re: Class objects work like built-in types, but is it worth it?

On Oct 23, 12:44 pm, acehr...@gmail. com wrote:

On Oct 23, 10:38 am, tonytech08 <tonytec...@gma il.comwrote:
>

The question is about the value of class objects
behaving like built-in types: How valuable/beneficial/desireable is
that? Or more specifically, was it worth introducing all that
ancillary machinery (exceptions) to get that feature?

>
I am not convinced that exceptions were introduced so that we could
say
>
MyType m;
>
I read the Design and Evolution of C++ a long time ago but don't
remember registering anything like that.

"Behaving like built-in type" means much more than "MyType m;"
example. Think about the following group of special "things" in a
class implemented to behave like a built-in type: default constructor,
copy constructor, assignment operator, destructor. Think about what
happens when you pass an object by value as a function argument.
Somehow, you have to handle potential errors from the copy
constructor. Solution: exceptions.

So more machinery than just exception to get built-in-type behavior:
default constructor, copy constructor, assignment operator,
destructor, compiler machinery to call these member functions. Is it
built-in-type behavior that lucrative to be worth all that?

Perhaps all objects could be
pointers and NULL could be returned?
>
MyType * m = new MyType();

(Aside/separate topic: That would be Simula then, right? That would
bring up the question of whether class objects can be of local (stack)
objects (which performance and convenience decidedly agree they should
be able to be)).

**acehreli@gmail.com** · Oct 23 '08, 09:45 PM

Re: Class objects work like built-in types, but is it worth it?

On Oct 23, 2:09 pm, tonytech08 <tonytec...@gma il.comwrote:

On Oct 23, 12:44 pm, acehr...@gmail. com wrote:On Oct 23, 10:38 am, tonytech08 <tonytec...@gma il.comwrote:

MyType m;

>

I read the Design and Evolution of C++ a long time ago but don't
remember registering anything like that.

>
"Behaving like built-in type" means much more than "MyType m;"
example. Think about the following group of special "things" in a
class implemented to behave like a built-in type: default constructor,
copy constructor, assignment operator, destructor.

Because of some of those, classes are better than built-in types.
That's part of the reasons why built-in types are referred to as
"second class" types:

- default constructor: missing for built-in types

- assignment operator: not always what we want for built-in types

- destructor: empty for built-in types; not always what we want

Think about what
happens when you pass an object by value as a function argument.
Somehow, you have to handle potential errors from the copy
constructor. Solution: exceptions.

Yes, exceptions are a mechanism of handling errors. The alternative of
handing error codes from layer to layer is not better.

They are not for built-in type behavior.

So more machinery than just exception to get built-in-type behavior:
default constructor, copy constructor, assignment operator,
destructor, compiler machinery to call these member functions. Is it
built-in-type behavior that lucrative to be worth all that?

They are all very important features without any connection to trying
to be like built-in types. Those are basic operations on types that we
need. The reason that built-in types have those operations is because
they are fundamental operations.

If those features are not important enough, one could always use C for
a while and come back to C++. ;)

Ali

**peter koch** · Oct 23 '08, 10:15 PM

Re: Class objects work like built-in types, but is it worth it?

On 23 Okt., 23:09, tonytech08 <tonytec...@gma il.comwrote:

On Oct 23, 12:44 pm, acehr...@gmail. com wrote:On Oct 23, 10:38 am, tonytech08 <tonytec...@gma il.comwrote:
>

The question is about the value of class objects
behaving like built-in types: How valuable/beneficial/desireable is
that? Or more specifically, was it worth introducing all that
ancillary machinery (exceptions) to get that feature?

>

I am not convinced that exceptions were introduced so that we could
say

>

MyType m;

>

I read the Design and Evolution of C++ a long time ago but don't
remember registering anything like that.

>
"Behaving like built-in type" means much more than "MyType m;"
example. Think about the following group of special "things" in a
class implemented to behave like a built-in type: default constructor,
copy constructor, assignment operator, destructor. Think about what
happens when you pass an object by value as a function argument.
Somehow, you have to handle potential errors from the copy
constructor. Solution: exceptions.
>
So more machinery than just exception to get built-in-type behavior:
default constructor, copy constructor, assignment operator,
destructor, compiler machinery to call these member functions. Is it
built-in-type behavior that lucrative to be worth all that?

These features are there to enable you to write solid code. Without
these, there is no easy way to write readable, robust code. For one
thing, the assignment operators and constructors ensure that your
objects remain consistent.
Also note that none of these are really needed: you could remove e.g.
the assignment operator and exceptions and still write something that
would look like C++ code, but the prize you pay is the burden you put
on all users of your classes. They would e.g. have to remember that
objects of your class should not be assigned to but should use a
special assignment function call, and they would have to be aware that
a constructed object might not have a valid state and might be
unusable and so on. It is a very high prize to pay for nothing but
some saved time for the compiler developers.

>

Perhaps all objects could be
pointers and NULL could be returned?

>

MyType * m = new MyType();

>

They could. But why would you want to impose such a large overhead on
us poor programmers?

/Peter

**Juha Nieminen** · Oct 23 '08, 10:45 PM

Re: Class objects work like built-in types, but is it worth it?

tonytech08 wrote:

How valuable is it that class objects behave like built-in types?

Without that behavior you couldn't create, for example, generic data
containers which work with both built-in types and user-defined classes.
But since user-defined classes can be made to behave like built-in
types, that simplifies generic programming a great deal.

Without this feature there would be only two possible choices:

1) Generic containers cannot support built-in types, only user-defined
classes. This would not only seriously cripple the usefulness of such
containers, it would be a major setback in efficiency when you want to
use the container for built-in types. (Basically you would have to write
wrappers for all built-in types, with all of their drawbacks. AFAIK this
is the case in Java.)

2) Make built-in types work like classes. This means that all objects
are allocated dynamically and are dynamically bound (like they are in
some languages). While in some cases this would be a useful thing (which
is the reason why those some languages do it in the first place), this
would seriously hinder the efficiency of built-in types.
(And no, the compiler would not be able to optimize dynamic binding
etc. out of the built-in types in C++ because, among other things, it
must support precompiled and dynamically loadable libraries.)

Another somewhat related benefit is that it makes it easier to
abstract your code. For example:

typedef int MyIntegral;

If you use that type consistently for a specific role in your code,
and later you need to change it to something else, you can change just
that line and that's it. No need to change anything else.
If the type you need to change it to is too complex to be a built-in
type, you can replace it with a class, no problem.

**tonytech08** · Oct 23 '08, 11:25 PM

Re: Class objects work like built-in types, but is it worth it?

On Oct 23, 4:09 pm, tonytech08 <tonytec...@gma il.comwrote:

(Aside/separate topic: That would be Simula then, right? That would
bring up the question of whether class objects can be of local (stack)
objects (which performance and convenience decidedly agree they should
be able to be)).

Which is, of course, info direct from D&E.

**tonytech08** · Oct 23 '08, 11:35 PM

Re: Class objects work like built-in types, but is it worth it?

On Oct 23, 12:49 pm, acehr...@gmail. com wrote:

Fat fingers! :) The post went out incomplete.
>
On Oct 23, 10:44 am, acehr...@gmail. com wrote:
>
>
>
>
>

On Oct 23, 10:38 am, tonytech08 <tonytec...@gma il.comwrote:

>

The question is about the value of class objects
behaving like built-in types: How valuable/beneficial/desireable is
that? Or more specifically, was it worth introducing all that
ancillary machinery (exceptions) to get that feature?

>

I am not convinced that exceptions were introduced so that we could
say

>

MyType m;

>

I read the Design and Evolution of C++ a long time ago but don't
remember registering anything like that. Perhaps all objects could be
pointers and NULL could be returned?

>

MyType * m = new MyType();

>
[I was going to add...]
>
Then we would have to check every object creation:
>
if (!m) // cannot continue
>
We wouldn't be able to chain function calls:
>
calculate(make_ first(), make_second());
>
It should be done noisily:
>
FirstType * f = make_first();
if (!f) goto bail;
>
SecondType * s = make_second();
if (!s) goto bail;
>
calculate(f, s);
>
That would be C-like in a bad way. :)
>
Can you think of a better way without exceptions from constructors?
>
Ali- Hide quoted text -
>
- Show quoted text -

Surely you are not suggesting that constructors lack return values
other than because of the "ctors enable class objects to behave like
built-in types", are you? Because, I think, that is default
constructors main purpose (i.e., the reason they were implemented as
part of the language).

Class objects work like built-in types, but is it worth it?

Class objects work like built-in types, but is it worth it?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment