Mail Archives: djgpp/2000/06/13/03:33:24
>G'zikes, Stefan!
>
>This is a horrible idea. I know the accessor and mutator functions are
>tedious, but this is no improvement. In fact, it is a quantum leap
>*backwards*:
>
>- accessor and mutator functions can be made virtual, your scheme can only
>do something similar by having each derived class remove and reinsert items
>into the associative array object.
>- small accessor and mutator functions are typically inline and require
less
>time and space than any function call. Your scheme will bloat your programs
>and will incur an enormous runtime overhead.
>- all constructors are responsible for loading all attributes whether or
not
>those attributes will ever be accessed. The time overhead is great.
>Construction should be very cheap -- if you like high-cost construction, go
>to Java. :-)
There is only few percent difference in size between normal program and the
one using my map class
(I made a trivial program creating table of circle class objects(with 50 000
members) and another one using my stuff.
The size of the "Normal" program was 277 343 bytes while the "New" was
278 701 bytes, that´s less than 1% in size increase)
However, I agree that in bigger programs the execution speed can make a big
difference
>- accessors can report values that calculated not stored. For example, a
>Money class might store the value in a single long but have accessors for
>getDollarValue, getCentValue, getValueAsDouble, getNbMillions, etc. Just
>imagine how awful this makes your mutators if setting one value impacts all
>the others; you would have to do multiple replacements on the associative
>array. (See what Bertrand Meyers has to say on the Principle of Uniform
>Reference).
Yes, I agree that my suggestion cannot used for functions doing any
calculation.
However the main interest was to replace those trivial functions which only
reason to exist was to
get/set one single value (class,structure,build-in types). For these jobs my
suggestion will fit wonderfully.
>- there is already an associative array in the STL. It stores items in a
>balanced red-black tree. It is very efficient and likely to be orders of
>magnitude quicker than your own hand crafted associative array. It you must
>do this, at least use the map<> class.
>
What do you mean "at least use map<> class" ? I have implemented my
associative array as an template
haven´t I ?
>- the mechanism is not typesafe, so a misspelling of "radius" as "raidus"
is
>not caught at compile time but results in a run-time error. (STL)
>associative arrays self-insert so your program could work quite happily for
>a while between pieces of code that misspell the same way. You have no way
>to report that a get operation failed.
As far as letter case is considered the mechanism IS safe. Example It makes
no difference if you type
"cout << circle[radius] << endl" OR "cout << circle[RaDiuS] << endl"
becourse they both reference to same object. Otherwise the mechanism needs
some fine tuning.
>- the attributes cannot be of primitive types like int and double because
>you cannot create a heterogenous container to store them. Big runtime
>overhead here.
I suppose you mean this:
Circle
{
public:
Circle(int x,int y,int radius);
Map<int> table; // table stores 3 values of
int´s but cannot store int(x),int(y),double(radius) in
}; // the same array
If you read my original mail you see that I am making an array class that
CAN store ANY KIND of
object, no matter if it is a class,structure, build-in type or even a
pointer to function.
>It was a nice idea that might actually work well in other OO languages that
>depend on dynamic binding for everything (like Smalltalk). However, C++ is
>strictly statically type checked, so this scheme runs very much against the
>C++ paradigm and incurs space and time overheads as a result.
Yeah, sure. Maybe all this static binding and all else compiler time
desicion will be the languages
downfall. In the future there will be much more programs that will desice
what operations to perform to which object in the run-time.
Stefan Fröberg
traveler AT netti DOT fi
- Raw text -