Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins Newsgroups: comp.lang.c++ Subject: Re: STL list or map? Date: Tue, 07 Jun 2011 09:53:32 +1200 Lines: 60 Message-ID: <9550itFbncU2@mid.individual.net> References: <953jn6Fbn8U1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net xw5xOtCBf7aEtqDQ1uQuhg0Vqj8zEJ1IvHyD1qAmBJ2KANy7/R Cancel-Lock: sha1:Q/KVfJSkMjXWjbrnodD/SSZoQpU= User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.9) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.4 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.c++:6317 On 06/ 6/11 10:36 PM, MikeP wrote: > Ian Collins wrote: >> On 06/ 6/11 08:52 PM, MikeP wrote: >>> Kai-Uwe Bux wrote: >>> >>>> Elsethread, the suggestion was made to hide this decision as an >>>> implementation detail of some class. That is a good idea. >>> >>> I don't think that it is. This is the perfect opportunity for the OP >>> to learn about applying the correct container/algo by taking the >>> required amount of time to do so. Unnecessary abstraction just >>> delays the decision and gives the application unnatural semantics >>> and stifles the programmer's level of capability. Use the right tool >>> for the job. >> >> Requirements aren't always invariant. If we lived in a perfect world, >> your observations would be correct. But we don't! > > You seem to be trying to make the exception the rule. No I'm not I'm simply agreeing with the suggestion to hide this decision as an implementation detail of some class. The standard doesn't define how standard containers are implemented, it defines how they behave. > The rule is to only > code the exceptional case only in the exceptional case and not aberrate > the common case with the exceptional. If you extrapolate further from > your suggestion, you will see it is not practical nor is it good > engineering. Do what? > In the OP's case shown above, doing the abstraction of the container/algo > could be R&D but the final product should be devoid of test harnesses. Eh? You completely snipped the OP. >>>> As the influencing factors are hard to predict, you should write >>>> your program so that it will be easy to change the data structure. >>>> Then, implement one that you can easily prove correct. Create unit >>>> tests. When you change the data structure, those tests will catch >>>> bugs. Once the other data structure is up and running, you can >>>> compare performance. >>> >>> Again, I disagree (see above). >> >> Again, we don't all live in a world of unchanging requirements. > > Non-sequitor at best, strawman at worst. Your "case" is moot. (You are > welcome to try again though but I am not into have overly-general or > philosophical discussion about it, for it is a well-defined area, at > least to me it is). Well good for you. Yesterday I had to change an object cache from a set to a map to facilitate exporting the data to a new external application. Because the choice of container was "an implementation detail of some class" only that class had to be modified. -- Ian Collins