Re: Class objects work like built-in types, but is it worth it?
On 2008-10-28 21:29, tonytech08 wrote:
On Oct 28, 1:55 pm, Erik Wikstr??m <Erik-wikst...@telia.com> wrote:
On 2008-10-28 16:00, tonytech08 wrote:
On Oct 26, 2:49 pm, Erik Wikstr??m <Erik-wikst...@telia.com> wrote:
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:
(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.
Pushing complexity to another area is just pushing it around rather
than finding an elegant solution. And yes, sometimes the elegant
solution has some amount of compromise to avoid that complexity. If
one is real anal about it, well, C++ the language may be what you end
up with? "Refactoring" the language may be in order (on alternative).
To me it seems like we pushed the complexity all the way out of existence.
Ha! C++ is complexity incarnate! Pushing stuff into the compiler is
not reducing complexity, it's just moving it elsewhere.
First of all I do not agree that the complexity for the compiler is
increased by any significan amount (after all, every abstraction that
takes you away from assembly-language is added complexity) but
constructors and such are relatively simple.
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.
So, how many linked lists of integer values have you used in code? It
appears that not supporting built-in types for some containers would
encourage better programming practice (going by just that one
example).
Linked lists? None in any non-trivial program, but I've used vectors
(lots of them), heaps, stacks, and queues with integers.
Probably because you were more interested in "objects" being in
contiguous memory and performance. That's why I said built-in arrays
are different from "containers". Sure you can slap an interface on
anything, but the implementation issues are what this thread is
about, rather than just abstractions.
No, I was interested in storing a variable number of values and
accessing them in various ways. Sure, I could have used arrays instead
but then I would have to do all the book-keeping myself. By using pre-
existing containers I reduced the complexity of my code significantly,
and probably got better performance too.
The one who said "it means you need two sets of code" above someone
with the paradigm that containers are value-based things, probably
because of some kind of derivation of what a container is based upon
built-in arrays, which leads to "hence, class objects need to behave
like built-in types to be used by value-based containers", was why I
posed the "how many linked lists of integers..." question and
"theory" that value-based containers aren't even desireable mostly.
I will not speculate about his reasoning but I can say this: The fact
that the container can also handle class-types have been useful in some
situations (for example I can switch to debugging by just changing a
#define/typedef).
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.
Array is a tricky one because there are built-in arrays which are
fundamentally different from a array "container". So to not muddle the
discussion with "corner cases", a different container abstraction,
such as linked list, would probably be better to use as an example.
Sorry, but no.
No what?
No, using linked list would not be a better example.
I use neither array or linked list as the definition of
what a container is,
I would hope not.
I think that both arrays and lists (as used in
functional languages) are containers.
Built in arrays are different beasts. It would probably not be
prudent to make the "raw materials of composition" (built-ins), class
objects. One can wrap those for more specific purposes.
Not sure what you mean here.
My original
question is still open. Maybe there are 2 (or more) types of classes:
those that behave like built-ins and those that are something else.
That "something else" being lightweight and not nearly as complex as
requiring compiler-called constructors and then exceptions to solve
the "problem" with constructors.
In my experience its the classes that do not behave as built-in types
that are the more complex ones (singletons, non-value semantics, etc.).
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").
No, definitely not a definition of a container interface. 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.
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. As pointed out there are other ways of doing it,
such as using boxing and typecasting (generics can hide some of this
from the user but that is all).
--
Erik Wikstr??m