[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.c++

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

tonytech08

10/23/2008 11:41:00 AM

How valuable is it that class objects behave like built-in types? I
appears that the whole "constructor 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!
69 Answers

Cupu

10/23/2008 1:20:00 PM

0

On Oct 23, 2:41 pm, tonytech08 <tonytec...@gmail.com> wrote:
> How valuable is it that class objects behave like built-in types? I
> appears that the whole "constructor 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).

Erik Wikström

10/23/2008 5:13:00 PM

0

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 "constructor 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

10/23/2008 5:38:00 PM

0

On Oct 23, 12:13 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
> 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 "constructor 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

10/23/2008 5:44:00 PM

0

On Oct 23, 10:38 am, tonytech08 <tonytec...@gmail.com> wrote:
> 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

10/23/2008 5:50:00 PM

0

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...@gmail.com> wrote:
>
> > 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

Erik Wikström

10/23/2008 6:13:00 PM

0

On 2008-10-23 19:38, tonytech08 wrote:
> On Oct 23, 12:13 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
>> 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 "constructor 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

10/23/2008 7:14:00 PM

0

On 23 Okt., 19:38, tonytech08 <tonytec...@gmail.com> wrote:
> On Oct 23, 12:13 pm, Erik Wikström <Erik-wikst...@telia.com> wrote:
>
> > 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 "constructor 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

10/23/2008 9:01:00 PM

0

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

10/23/2008 9:09:00 PM

0

On Oct 23, 12:44 pm, acehr...@gmail.com wrote:
> On Oct 23, 10:38 am, tonytech08 <tonytec...@gmail.com> wrote:
>
> > 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

10/23/2008 9:35:00 PM

0

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

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