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

[tonytech08]

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!

[Juha Nieminen]

tonytech08 wrote:

> Too bad that's impossible.

For C++ it is, but not for some other language.

What language? Haskell? Haha.

[tonytech08]

On Oct 29, 4:00*pm, Erik Wikström <[e-mail]:

On 2008-10-28 23:21, tonytech08 wrote:

I think I've noted before or above that if you start with the thought
that "a built-in array is a container", a perverted definition of
"container" will result. A built-in array is a type rather than a
container (by "my" definition of container anyway).

Actually if we say that an array is a container we say that it fulfils
the requirements of a container, not the the requirements of a container
is to be like an array. Or in OO terms: an array implements the
interface container, but there might be many other implementations of
the same interface.

That's not topical though, and is paradigmical and a very
high-level/abstract "definition" (and even moreso, a definition of
"container interface" rather than "container").
It's a
definition of a container in terms of an interface, i.e. the interface
specifies what a container is and everything that implements the
interface is a container.

Nah, that's just a behavioral specification. A container interface is
not a container just like a remote control is not a television. The
remote just allows interaction with it.

In my work we design nodes in networks (some might call them servers but
I don't think that's a good description) which communicate with each
other and other nodes in networks. The requirements on these nodes are
specified by a standardisation organisation and the way they are
specified are in they way they interact with other nodes in the
networks. In other words the specification of a node is a description of
its interfaces. What I want to say with this is that a specification of
behaviour can be a sufficient definition of a thing. So an interface
description of a container can be a definition of a container.

But would be an incorrect definition given the context of this thread.
Context matters.

>

Containers were brought into the discussion when someone said that
built-in-type-behavior of class objects is required so that
containers can be implemented, which of course is wrong in the
general sense.

Of course, but he only said that it is necessary to implement practical
and useful containers.

Which also is not true.

Says you, but who should I believe?

I'm not here to convince you. I do things my own way and I have
containers that I use that are practical and useful. And obviously I
think they are more practical and useful than their STL equivalents.

A regular who's skills are
programming in general and C++ in particular I've witnessed, or you who
has so far only questioned what is more or less the collective opinion
among C++ programmers?

I just wanted to know what people though on the topic. I was hoping to
get some response from people who actually implement the language
rather than just users of it. And from people who are also good
inventors and have found other ways to skin the proverbial cat. (As in
"a better C++"). Surely if one just says "C++ is just fine" that
doesn't add anything toward discovery of anything new.

[Paavo Helde]

tonytech08 <to********@gmail.comkirjutas:

On Oct 29, 3:07*am, Paavo Helde <[e-mail]:

>tonytech08 <[e-mail]:

When would you _ever_ want to use containers with value semantics
other than
with pointers to objects?

Basically whenever when the objects are not polymorphic. Using

pointers

>instead of objects themselves adds a level of indirection with its own
complexity and problems, this should be avoided when not needed.

We'll have to agree to disagree on that.

>>

Well the container topic got backed into here. The issue of this
thread are
class objects. Using a container (STL) with value sematics for a
object of
class type imposes unnecessary requirements on the class.

Nah, you still have it backwards; if the class supports value

semantics

>one can have value-based containers of the objects (with simplified
semantics), *in addition* to pointer-based containers, which are still
there.

We'll have to agree to disagree on that also.

>>

A point is that exceptions and constructors are pretty much a

package

deal because the alternatives are ugly.

It appears you are claiming that if there are two good features

fitting

>nicely with each other, they should be both banned, for unfair
competition ;-)

Nothing like that.

One things I'd miss if there wasn't class objects that behave like
built-in types are those objects you can code up to do something like
release a lock no matter how the enclosing scope gets exited. What are
those things called? I'd probably be satisfied with only one of those
things though that I could wrap around other objects to get the same
effect.

It seems that what you want is some kind of scripting language. At least
the scripting language developed by our company fulfills almost all
criteria. It has no means for defining new data types, so all types are
built-in. The built-in types include things like Image, Table and
Container. There are no script-defined constructors or destructors. There
is no pointer type. In the script everything looks value-based, but under
the hood almost everything is accessed via pointers. There are exceptions
though, and try/catch. And recently I added exactly what appears to be
your last wish: a MakeDestructor operation which just prepares a function
to be launched when exiting the current scope.

Curiously enough, the script language is itself implemented by quite a
large amount of C++ code, making heavy use of constructors, destructors,
inheritance, exceptions, templates and whatever. I cannot imagine of
doing it in some other language, the full C++ is just a *bare minimum*
for implementing this kind of project.

Paavo

[Hendrik Schober]

tonytech08 wrote:

[...]
But after pondering the responses here, maybe built-in types are the
"problem" (!). "Everything is an object" (but not a cosmic one), may
be the way to go. I know enough "low level" programming to hinder my
own progress probably. Maybe my initial question was wrong. Maybe I
should have asked: "Why do we still need built-in types?". Which of
course brings in the "hardware" folks. Software that programs the
hardware has been the paradigm. Time for software to influence
hardware?

I haven't done any close-to-hardware programming. Yet I've come
across software that stressed very good desktop computers to their
limits. If "everything is an object" costs, I don't want to have
it. (And if it doesn't, why was there a need to invent C++?)

Schobi

[LR]

tonytech08 wrote:

On Oct 29, 10:31 am, Juha Nieminen <[e-mail]:

>tonytech08 wrote:

>>On Oct 28, 6:00 pm, Juha Nieminen <[e-mail]:
tonytech08 wrote:
Ha! C++ is complexity incarnate! Pushing stuff into the compiler is
not
reducing complexity, it's just moving it elsewhere.
It's better to have the complexity in the compiler than in the code
written by the programmer.
It's better to not have the complexity at all.

Too bad that's impossible.

For C++ it is, but not for some other language.

>Programming is a complex thing.

With C++ it is. It doesn't have to be nearly so though.

I'm pretty sure that I do not understand this. I think I may not
understand because I may not understand what you mean by complexity.
Could you please explain what you mean by complexity?

Also:

How might it be possible to not have any complexity? Is this limited to
either the programming language itself, or the problem domain?

Why, according to you, is programming more complex with C++?

Is complexity bad? Why? And under what circumstances? Always?

Which computer language would be simpler in your estimation?

1) A single instruction: Flip the bit at <address1and if the result is
zero branch to <address2(Note this doesn't require an opcode.)

2) Two instructions:
a) Flip the bit at <address>
b) If the bit at <address1is zero goto <address2>

If you had to program in one of the above languages, would you want to
add a macro language of some sort? Would this add or remove complexity
from the programs that you'd write?
Would you prefer to use a slide rule or an electronic calculator? Which
one is more complex? To implement? To use?

Is:
a += 3;
more complex or less than:
a = a + 3;
TIA
LR

[tonytech08]

On Oct 30, 4:17*pm, LR <[e-mail]:

tonytech08 wrote:

On Oct 29, 10:31 am, Juha Nieminen <[e-mail]:

tonytech08 wrote:
On Oct 28, 6:00 pm, Juha Nieminen <[e-mail]:
tonytech08 wrote:
Ha! C++ is complexity incarnate! Pushing stuff into the compiler is
not
reducing complexity, it's just moving it elsewhere.
* It's better to have the complexity in the compiler than in the code
written by the programmer.
It's better to not have the complexity at all.
* Too bad that's impossible.

For C++ it is, but not for some other language.

Programming is a complex thing.

With C++ it is. It doesn't have to be nearly so though.

I'm pretty sure that I do not understand this. *I think I may not
understand because I may not understand what you mean by complexity.
Could you please explain what you mean by complexity?

Also:

How might it be possible to not have any complexity? Is this limited to
either the programming language itself, or the problem domain?

Why, according to you, is programming more complex with C++?

Is complexity bad? Why? And under what circumstances? Always?

Which computer language would be simpler in your estimation?

1) A single instruction: Flip the bit at <address1and if the result is
zero branch to <address2(Note this doesn't require an opcode.)

2) Two instructions:
a) Flip the bit at <address>
b) If the bit at <address1is zero goto <address2>

If you had to program in one of the above languages, would you want to
add a macro language of some sort? *Would this add or remove complexity
from the programs that you'd write?

Would you prefer to use a slide rule or an electronic calculator? Which
one is more complex? To implement? To use?

Is:
* * * a += 3;
more complex or less than:
* * * a = a + 3;

As this thread is already more chaff than wheat, I suggest you start a
new thread on "the complexity of C++" if you want to.