From: "Steve Ball" Newsgroups: comp.os.msdos.djgpp References: <8hrrqc$21c$1 AT tron DOT sci DOT fi> Subject: Re: NO MORE ACCESS FUNCTIONS (Well, almost...) Lines: 109 X-Newsreader: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Message-ID: Date: Mon, 12 Jun 2000 08:41:08 +1200 NNTP-Posting-Host: 210.55.35.135 X-Complaints-To: newsadmin AT xtra DOT co DOT nz X-Trace: news.xtra.co.nz 960756119 210.55.35.135 (Mon, 12 Jun 2000 08:41:59 NZST) NNTP-Posting-Date: Mon, 12 Jun 2000 08:41:59 NZST Organization: Xtra 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. :-) - 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). - 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. - 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. - 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. 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. The classes in the STL are a good pattern for how accessors and mutators should look. It is always a good idea to get to know the standard libraries well. I think you would enjoy it--the STL is a masterpiece of good design. Steve Ball Traveler wrote in message news:8hrrqc$21c$1 AT tron DOT sci DOT fi... > Hello to everyone ! > > When designing classes I have always be annoyed to make different kinds of > "get this", "get that" access functions. > > Now, with associative array I can make more compact classes. > So for example, instead of this: > Circle circle(160,100,50); > cout << circle.getx() << endl; > cout << circle.gety() << endl; > cout << circle.getradius << endl; > I can do this: > Circle circle(160,100,50); > cout << circle["x"] << endl; > cout << circle["y"] << endl; > cout << circle["radius"] << endl; > circle["radius"] = 30; > cout << circle["radius"] << endl; > > This is great becourse I do not need to remember all access functions. Only > class "attributes". > (If you do not see this as a problem then try to program something very > simple with Java or Win32 API without looking a single time from your source > book :=)). > Code will become shorter and save coding time and decreasing the chance of > errors. > > I will include few files that contains the above trivial main program and > Associative array class implemented as a single linked list. NOTE however > that this class IS NOT COMPLETE (example: there is no sorting function > implemented). > > When I finally have time to complete this I will continue my work with the > heterogeneous array class (that is, Array where all elements do not need to > be same type). It´s almost working (inserting and inspecting elements > implemented, removing one single element poses a problem). > > > Thanks for your time and sorry if my english is poor > Stefan Fröberg alias Traveler2000AD > traveler AT netti DOT fi > > > > > > > > >