From: "Traveler" Newsgroups: comp.os.msdos.djgpp Subject: Re: NO MORE ACCESS FUNCTIONS (Well, almost...) Date: Tue, 13 Jun 2000 02:40:00 +0300 Organization: SAUNALAHDEN asiakas Lines: 108 Message-ID: <8i3r7n$i4k$1@tron.sci.fi> References: <8hrrqc$21c$1 AT tron DOT sci DOT fi> NNTP-Posting-Host: mmmcd.hdyn.saunalahti.fi X-Trace: tron.sci.fi 960852024 18580 195.197.47.100 (12 Jun 2000 23:20:24 GMT) X-Complaints-To: newsmaster AT saunalahti DOT fi NNTP-Posting-Date: 12 Jun 2000 23:20:24 GMT X-Newsreader: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com >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 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