Re: Class objects work like built-in types, but is it worth it?
On 2008-10-26 05:07, tonytech08 wrote:
On Oct 24, 4:25 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
tonytech08 wrote:
On Oct 23, 5:42 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
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.
That of course is not correct.
Exactly how would you create code which can handle both builtin types
and user-defined classes if they don't behave in the same way? For
example, if user-defined classes couldn't support assignment (like
built-in types do), it would be rather difficult to create a generic
container which can handle them.
It's up to you what you define "container" as. If you want to do "the
container owns the objects it contains" thing, that's fine. There's
more than one way to skin a cat and why is it so important to make
people boarding an airplane the same as cattle going to slaughter?
Meaning what? I see no connection between your proverbs and what Juha
Nieminen wrote.
The only way would be to make generic containers only support
references/pointers and nothing else (which is the case in Java), in
which case you basically lose the ability to store built-in types
directly into the data container (you could only store pointers to
built-in values, not the values themselves).
So? The latter is probably "bad".
Which latter? The is only one.
Java people will tell you that Java generics do support built-in
types, but that's just a lie. They only support classes, period.
But since user-defined classes can be made to behave like built-in
types, that simplifies generic programming a great deal.
Maybe, if you adhere to one specific way of designing containers (?).
I want containers which can store built-in types without overhead. Of
course you can create other types of containers if you don't care about
the overhead.
"Overhead"? You are programming F15 realtime software? "General
purpose programming language" is obsolete?
If you can not program F15 realtime software (whatever that means) *and*
business software interfaces (and a lot of other types of software) in
the same language it is *not* a general purpose language. Performance
always matters.
Without this feature there would be only two possible choices:
1) Generic containers cannot support built-in types, only user-defined
classes.
The way STL containers are designed is not the only possibility. You
seem to be fixated on STL container designs/architecture. (?)
Well, tell me how you would implement a generic data container which
efficiently supports both built-in types and user-defined classes.
Why is that important?
Because we use use such containers every day and have found them really
useful.
and are dynamically bound
I don't know what that means or what you mean by it.
Maybe you should study a bit of object-oriented programming then?
Slam noted. (Not nice, btw).
(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.
It wouldn't change built-in efficiency in the least or in any way.
Exactly how would you create a generic data container which supports
both built-in types in the most efficient way possible *and*
user-defined classes if, as you suggest, the latter do not behave like
built-in types?
Why is that important?
Consistency is very important when writing software, we do not need the
additional complexity of having different containers for different
types. If you need to different containers (one for built-in types and
one for others) it means you need two sets of code, which meant you
double the amount of bugs, double the maintenance const, double the
things to keep track of, etc.
Did
you mean using those things from containers? Perhaps you are thinking
built-in arrays and not containers at all?
Built-in arrays *are* containers. The only difference is that they are
not dynamic, but that's irrelevant.
Ah, the "built-in type" arrays ARE containers. Well if you have a
paradigm about what a container is, then all thing will look like a
nail I guess.
Again the messed up proverbs. Yes, we have a definition of what a
container is. In short it is something which can contain one or more
other things and there are ways of accessing these things. Such as an array.
Anyways, I was not talking about arrays exclusively (nor did I have
them in mind at all when I wrote my post).
(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.)
Whoa, I think you are overscoping the the original topic by a mile by
bringing in dynamic binding and loadable libraries!
I brought the issue because there are some programming languages where
built-in types behave exactly like classes: They are dynamically
allocated and dynamically bound, they can be specialized, and you can
perform delegation on them.
To me it sounds like you are saying that there are languages that
don't have ANY built-in types (which may not be a bad idea, I dunno).
Yes, that is what he is saying. Ruby is one such language (I think, I
have not studied it in detail), C# is another (it has value-types and
reference-types, but not built-in types).
--
Erik Wikstr??m