🚀 go-pugleaf

John Max Skaller (maxtal@suphys.physics.su.oz.au) wrote:
: dick@silicon.csci.csusb.edu (Dr. Richard Botting) wrote:
: >John Max Skaller (maxtal@suphys.physics.su.oz.au) wrote:
: >
: >: khan@xraylith.wisc.edu (Mumit Khan) wrote:
: >: >
: >: >2 people have already mentioned that they're dismayed by the fact
: >: >that some algorithms explicitly exclude certain containers; eg., Cay
: >: >Hosrtmann asks why the sort algorithm does not work with lists. 
: >
: >:     The reasons is that the performance guarrantees would not
: >: be met. I personally find that a bit weak: often performance
: >: is less an issue than utility. 
: >
: >The old argument that a programmer costs more per minute than
: >the CPU come in here I guess.

:      Yes. In fact, it is possible the requirements will be
: weakened, or a version that works with lists supplied.
[snip]
:      There is a serious threat that supplying too much
: "convenience" will break the fundamentals of STL.
: It has properties such as performance guarrantees,
: operations doing just one thing, etc which make it 
: predicatble and reliable as a _basis_ for a full
: blown library.

:      A half hearted attempted to extend that basis 
: _in_ the C++ Standard could be worse than leaving all
: these problems to programmers (all of whome have
: different requirements). [I.e. I'm arguing
: that some minimalism is a good thing here]

I've been thinking
that different needs demand different implementations.
	(sorting being Knuth's 1971 example)
I've been wondering whether a multilevel library might resolve
some of the conflicts between requirements.  
So perhaps, there might be common headers but multiple
implementations of the standard libraries.  
	For example: high speed vs low RAM vs safe'n'sure vs...

However this does not handle those cases where the
non-functional requirements force a change in the interface/header.

This makes me wonder whether standard libraries may need
to be, kind of, multiple level.  At the top a pure virtual
interface of common functionallity.  In the middle the more
specific (and "better for special needs") classes.  And at
the third level, the implementation.

Similar ideas have appeared in several research papers in software
engineeering recently.

--
	dick@csci.csusb.edu=rbotting@wiley.csusb.edu.
Find out what's new at http://www.csci.csusb.edu/doc/www.sites.html
Disclaimer:`CSUSB may or may not agree with this message`.
Copyright(1995):Copy this freely but include the following link to the
<a href="http://www.csci.csusb.edu/dick/signature.html">author's signature</a>

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]