Re: Class objects work like built-in types, but is it worth it?
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.
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).
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.
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.
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?
(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?
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.
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. Yet in most cases if you use built-in types
exclusively, without inheritance/delegation/whatever, the compiler is
able to optimize all that away and generate code which works with pure
built-in types. However, that kind of optimization is not possible in
C++ because of precompiled libraries, which is why it would be so
difficult to have builtins working like classes in C++ (while keeping
them efficient).