Mon, 21 May 2001 18:52:01 GMT Christopher Eltschka wrote:
>> >If your compiler translates
>> >
>> >for_each(myvec.begin(), myvec.end(), foo)
>> >
>> >to something slower than
>> >
>> >for(T* ptr = myarray, ptr < myarray+N, ++ptr)
>> >  foo(*ptr);
>> >
>> >then you might complain about the bad optimizer of your compiler.
>>
>> So what to do then? Compiler isn't always an option.
>
>What about:
>
>  for (std::vector<T>::iterator first = myvec.begin(),
>                                last = myvec.end();
>       first != last;
>       ++first)
>    foo(*first);

It's ok. My comment was about for_each vs for(;;){...}.


>> >If one wants ref counting for some reason, there's still the
>> >possibility to use a reference counted pointer to string.
>>
>> You can't recommend ref-counted ptrs until they are not in std library.
>> By the way, they must to present - but now they are not there.
>
>You don't want to argue that C++ programmers generally cannot write
>reference counted pointers, do you?

They can; they also could write their_own::string :) But smart pointer is very
common pattern now, and it must be in standard library.

>But then, it would have been much better to have a non-counted
>string and a ref-counted pointer in the standard library than to
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That's it, "and". Yes, I tend to agree. But, for me, it is much better to have
just _immutable_ strings - no mutable version at all. All mutations should
return new object, and RC is not problem anymore. (I guess it is impossible
now.)

>Moreover, you cannot even be sure _that_ it is ref-counted, i.e.
>you might have all the problems with iterator/reference invalidation,
>and then you may find out that your compiler doesn't really do
>ref-counting, and therefore you have the worst of both worlds!

Yes.

--
jk

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Scott Robert Ladd wrote:

[...]

> Take, for example, sort<>. Some applications require a stable sort, others
> do not.

So some people use std::stable_sort, others use std::sort.
Or maybe you use a sorted container (std::set, std::multiset)
from the beginning. Or you implement heapsort by just calling
first make_heap, then sort_heap.

> Some sorts result in small code; others perform quickly; some fall
> into a middle ground of size and performance.

And if none of the sort methods are what is required, one can still
write an STL conforming special_sort. And be sure that it works with
the STL conforming wonderful_container which someone else he doesn't
even know will write tomorrow.

Moreover, for most other sorting algorithms, the parts are already
in the STL (partial_sort, partition, stable_partition).

> Sometimes we're merging data
> form multiple sources;

std::merge, std::set_union

> sometimes, we're sorting via indirection.

Any sort method with appropriate comparision argument.

> How can C++
> possible expect to provide one sort<> template that solves all those
> problems?

It doesn't. It provides a _whole set of_ functions, which solve _most_
of the problems. Moreover, by making the functions customizable (through
the sort order argument), it solves not only the fact that your order
may be different from "from least to greatest", but also solves problems
like indirect ordering.

> By providing a sanctified "standard" sort<> C++ implies that one
> algorithm fits all.

No.

You might not have noticed that the main advantage of the STL is in
that part which is _not_ found in any header (because there is no
way to directly express it in the language). It's in the concepts
it's built on.

[...]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Eugene Karpachov wrote:
>=20
> Wed, 16 May 2001 15:38:31 GMT Christopher Eltschka =CE=C1=D0=C9=D3=C1=CC=
:
> >If your compiler translates
> >
> >for_each(myvec.begin(), myvec.end(), foo)
> >
> >to something slower than
> >
> >for(T* ptr =3D myarray, ptr < myarray+N, ++ptr)
> >  foo(*ptr);
> >
> >then you might complain about the bad optimizer of your compiler.
>=20
> So what to do then? Compiler isn't always an option.

What about:

  for (std::vector<T>::iterator first =3D myvec.begin(),
                                last =3D myvec.end();
       first !=3D last;
       ++first)
    foo(*first);

On almost all compilers this will result in code which operates with
the same speed as the pointer version. That's because generally
std::vector<T>::iterator _is_ just T*.

And in the rare case where it isn't, and where even this version is
too slow, you can still do (assuming a non-empty vector)

  for (T* first =3D &*myvec.begin(), last =3D first + myvec.size();
       first !=3D last;
       ++first_
    foo(*first);

BTW, if a new compiler is not an option, a new container in a new
version of the standard will not help either: You'll have to change
the compiler to get a compiler conforming to the new standard.

>=20
> >reference counting is far too complex. The right thing would
> >IMHO have been to just make it non-counted, given that most
> >copies can be avoided either by passing by reference, or through
> >the return value optimizations done by the compiler.
>=20
> This statement is very common but unreasonable. Not all compilers are g=
ood, it
> is just reality. Moreover, not all passing-by-value cases are optimizab=
le. I
> just want to have cheap passing *by value* - just that. If you need exp=
ensive
> and simple string-like class - feel free to develop it, implement it, a=
nd name
> it as you wish - but not std::string.

Of course *I* cannot name it std::string. But I also canot use it as
drop-in replacement for std::string.

>=20
> >If one wants ref counting for some reason, there's still the
> >possibility to use a reference counted pointer to string.
>=20
> You can't recommend ref-counted ptrs until they are not in std library.
> By the way, they must to present - but now they are not there.

You don't want to argue that C++ programmers generally cannot write
reference counted pointers, do you?
It's hard to make a good _generic_ ref counted pointer. But that's
not the problem if you just want to pass strings.

But then, it would have been much better to have a non-counted
string and a ref-counted pointer in the standard library than to
be stuck with a ref-counted string where it's not even obvious
that a simple assignment like s[2]=3Ds[3] works (I don't remember
the outcome of the discussion: Is it guaranteed to work?)

After all, if you can get X from Y, but cannot get Y from X,
then the standard should give you Y, not X.
In this case, X is the ref-counted string, Y is the "simple"
string.

Moreover, you cannot even be sure _that_ it is ref-counted, i.e.
you might have all the problems with iterator/reference invalidation,
and then you may find out that your compiler doesn't really do
ref-counting, and therefore you have the worst of both worlds!

Indeed, if you are writing portable programs, and you are concerned
about speed, you have to assume that all ref-counting restrictions
apply (because some implementations will use RC), but also that you
have the timing behaviour of the non-RC version (because some
implementations will not use RC).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Wed, 16 May 2001 15:38:31 GMT Christopher Eltschka =CE=C1=D0=C9=D3=C1=CC:
>If your compiler translates
>
>for_each(myvec.begin(), myvec.end(), foo)
>
>to something slower than
>
>for(T* ptr =3D myarray, ptr < myarray+N, ++ptr)
>  foo(*ptr);
>
>then you might complain about the bad optimizer of your compiler.

So what to do then? Compiler isn't always an option.

>reference counting is far too complex. The right thing would
>IMHO have been to just make it non-counted, given that most
>copies can be avoided either by passing by reference, or through
>the return value optimizations done by the compiler.

This statement is very common but unreasonable. Not all compilers are goo=
d, it
is just reality. Moreover, not all passing-by-value cases are optimizable=
. I
just want to have cheap passing *by value* - just that. If you need expen=
sive
and simple string-like class - feel free to develop it, implement it, and=
 name
it as you wish - but not std::string.

>If one wants ref counting for some reason, there's still the
>possibility to use a reference counted pointer to string.

You can't recommend ref-counted ptrs until they are not in std library.
By the way, they must to present - but now they are not there.

--=20
jk

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

AA> For what I know, everybody and their sister wants more
AA> standard library components.

And that is why we need to be very careful about satisfying everyone's
needs. Or do you consider every request equal? Should the committee have
including resumable exceptions because some people wanted them?

If anything, a STRENGTH of a democratic committee is its ability to weed out
fringe ideas and undesirable components, while looking to the better good.
Yes, we can ignore any part of the library that is inappropriate for a given
task -- however, the more we pack into the standard, the more difficult it
becomes for vendors to implement the language completely and correctly.

Or, to use an old engineer's adage: "The more you complicate the plumbing,
the easier it is to stop up the works."

AA> This is a shallow generalization. Hiding complexity is a must for
AA> every project I've ever worked on, and I firmly believe is a tenet
AA> for building large projects.

There is a fine line between "hiding" complexity and obfuscating it. From my
perspective, the current set of containers is designed for heavy
applications. What about people who write embedded systems? Or folks who
need lightning fast code? The question arises as to whether or not complex
containers fits the overall philosophy of the language.

Right now, the library is tilted toward "heavy" types like string. How many
of us really *need* the complete power of string in our work? Most of my
code uses fewer than 10% of the methods defined by string: the concatenation
operators, assignment, .c_str(), length().

Beyond issues of program efficiency; we also face the need for *clarity*.
Good class interface design requires a minimalist approach; you only expose
the properties and methods required by a given user. If most people are only
using a subset of string, perhaps a better template hierarchy would
implement a true "basic string" type, with additional functionality in
derived templates.

You are, of course, quite welcome to politely disagree; the committee
process will determine the direction the language takes.

We also have many inconsistencies in the existing library. Why, for example,
for so many methods (stream.open(), for one) use C-style character arrays
for text arguments? Why don't such methods use string? Shouldn't the
standard reflect good programming practice by showing example of
consistency?

I wouldn't use C++ if I didn't respect the efforts of its designers and
implementers. I am not criticizing the work of the committee -- I'm trying
to open a discussion about how we can improve the existing standard in the
next revision, before we add new "stuff". The standard library should
exemplified the best C++ programming techniques -- including reuse,
encapsulation, functional inheritance, and precision of thought.

What, pray tell, is objectionable in that goal?

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
http://www.coyotegulch.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Scott Robert Ladd wrote:

[...]

> AA> This is a shallow generalization. Hiding complexity is a must for
> AA> every project I've ever worked on, and I firmly believe is a tenet
> AA> for building large projects.
>
> There is a fine line between "hiding" complexity and obfuscating it. From my
> perspective, the current set of containers is designed for heavy
> applications. What about people who write embedded systems? Or folks who
> need lightning fast code? The question arises as to whether or not complex
> containers fits the overall philosophy of the language.

OK, then let's get concrete: In which way is std::vector a "heavy"
or "slow" type?

If your compiler translates

for_each(myvec.begin(), myvec.end(), foo)

to something slower than

for(T* ptr = myarray, ptr < myarray+N, ++ptr)
  foo(*ptr);

then you might complain about the bad optimizer of your compiler.

> Right now, the library is tilted toward "heavy" types like string. How many
> of us really *need* the complete power of string in our work? Most of my
> code uses fewer than 10% of the methods defined by string: the concatenation
> operators, assignment, .c_str(), length().

OK, string is an exception. But AFAICS the only one.
But the problem is IMHO not that it offers too many functions
(if you don't needa function, just don't use it), but that it
- duplicates some STL algorithms (f.ex. find), just with indices
  instead of iterators
- contains some functions which would make sense as generic
  STL algorithm instead (f.ex. searching substrings)

Also, the referece/iterator invalidation stuff needed to allow
reference counting is far too complex. The right thing would
IMHO have been to just make it non-counted, given that most
copies can be avoided either by passing by reference, or through
the return value optimizations done by the compiler.

If one wants ref counting for some reason, there's still the
possibility to use a reference counted pointer to string.

>
> Beyond issues of program efficiency; we also face the need for *clarity*.
> Good class interface design requires a minimalist approach; you only expose
> the properties and methods required by a given user. If most people are only
> using a subset of string, perhaps a better template hierarchy would
> implement a true "basic string" type, with additional functionality in
> derived templates.

No, not in derived templates, but in global templates -> STL!
Then we could not only search substrings in strings, but also
f.ex. certain sequences of numbers in a vector<int>.

>
> You are, of course, quite welcome to politely disagree; the committee
> process will determine the direction the language takes.

It's far too late to clean up string. But as I said, string is
AFAICS the one big exception.

> We also have many inconsistencies in the existing library. Why, for example,
> for so many methods (stream.open(), for one) use C-style character arrays
> for text arguments? Why don't such methods use string? Shouldn't the
> standard reflect good programming practice by showing example of
> consistency?

That's another point: Yes, IMHO there should be members added(!)
which take strings instead of char const*.

> I wouldn't use C++ if I didn't respect the efforts of its designers and
> implementers. I am not criticizing the work of the committee -- I'm trying
> to open a discussion about how we can improve the existing standard in the
> next revision, before we add new "stuff". The standard library should
> exemplified the best C++ programming techniques -- including reuse,
> encapsulation, functional inheritance, and precision of thought.

Especially the STL part mainly does exactly this. (Note that
std::string isn't part of the STL, although it got "STLified"
afterwards, and SGI STL now also contains it).

- reuse:
  * You can use every algorithm with every container, including
    new STL compatible algorithms programmer A writes, with new STL
    compatible containers programmer B writes, even if programmer A
    and programmer B don't know of each other (and only programmer C
    get's A's algorithms and B's containers).
  * The same container code can be reused for containers to int,
    containers to double, or containers to MyNewFancyType, without
    loosing a single bit of type safety.
- encapsulation:
  The implementation of the container is hidden. You have a std::map,
  not a std::red_black_tree. The iterator has a pointer-like interface;
  whatever it really does is hidden.
- functional inheritance:
  OK, I don't know what you mean here.
- precision of thought:
  Can you point me to a piece of software with _more_ precision of
  thought than the STL?

> What, pray tell, is objectionable in that goal?

Possibly "functional inheritance", since I don't know what you
mean with that ;-)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Wed, 16 May 2001 15:38:31 GMT, Christopher Eltschka
<celtschk@dollywood.itp.tuwien.ac.at> wrote:

> No, not in derived templates, but in global templates -> STL!
> Then we could not only search substrings in strings, but also
> f.ex. certain sequences of numbers in a vector<int>.

Please don't fix it, it's not broken :)  See search (25.1.9).

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <9dq4a0$87g$1@kilmer.bain.oz.au>, Nick Thurn
<nickt@kipling.aus.deuba.com> writes
>The templates everywhere experiment is not a success IMHO
>and should be scrapped for iostreams and string/wstring or
>alternatively std concrete classes should be provided for
>string/wstring

One of the problems is that, currently, the only way you can guarantee
that an executable does not include unused member functions is to use a
template class. A great deal of the problem goes away if we can come up
with a formula that requires that the implementation of a full
specialisation is linked be the same rules as a library. Now when I
write:

template<>
basic_class<X> {
// specialisation
};

typedef basic_class<X> classX;

I should be able to get the efficiency of a separately compiled ordinary
class coupled with the link time benefits of a template.

Note that the above is just an outline and is probably riddled with
error.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

BS> I think you are too harsh with the committee. The committee process is
BS> not perfect, but it is better than all alternatives that I know of.

Where did I say anything "harsh" about the committee or its potential
members? As Francis pointed out:

FG> Actually it is an example of design by democracy:) I will vote for your
FG> favourite if you will vote for mine. This is not the only example of the
FG> fundamental flaw of democracy:)

If we admit that (in your words) the "committee process is not perfect",
then we should plan for those imperfections to avoid any pitfalls they might
entail. As you said in your Slashdot interview: "New major facilities have
to be added with care." Right now, we're in laundry list mode; people are
tossing out new ideas, without considering the existing foundation in ISO
C++.

I see the development of a new standard in light of my experience in
software development. My current work, for example, involves replacement of
an existing application suite with new code. Planning this project began by
looking at the existing product, analyzing how it works, where it is
inadequate, and what our customer base needs. Using that same philosophy, it
seems very logical to look closely at the current C++ standard before
embarking on additions and revisions.

I don't see this as "pre-judgment" -- I see it as planning ahead.

BS> We should worry about feature creep - or it will surely happen. However,
BS> we should not be paralysed by that worry - or we'll get stagnation
rather
BS> than stability.

I completely agree -- the above is the point of my original article and
subsequent follow-ups. We need a considered and moderated approach to
extending C++, based on a clear analysis of the strengths and weaknesses in
the 1998 standard. If we proceed from the assumption that the 1998 standard
is perfect, I'm afraid C++ will suffer as a tool.

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
http://www.coyotegulch.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Scott Robert Ladd" <scott@coyotegulch.com> wrote in message
news:aTwL6.213678$fs3.35448482@typhoon.tampabay.rr.com...
> So I'll buck the trend and suggest things we *don't* want to put in the
next
> C++: More containers, and more algorithms.

For what I know, everybody and their sister wants more standard
library components.

> C++ iterators, algorithms, and containers are inefficient and
unnecessarily
> complex.

Hmmm... is this a backed-up statement? Where does the inefficiency come
from? What exactly is "unnecessarily" complex?

> The actual source code doesn't look terribly complex -- it's the
> underlying mechanisms that obscure function with too much form. We heap
> template upon template, giving the compiler nightmares while obscuring
what
> is really happening "under the hood."

Ok. Let's go back to void* :o).

> Is container abstraction akin to the hiding a car's pistons from its
driver?
> No, because I'm not driving the car, I'm *building* it. And as any good
> engineer can tell you, hidden complexity and obfuscated parts will be the
> death of many software projects.

This is a shallow generalization. Hiding complexity is a must for every
project I've ever worked on, and I firmly believe is a tenet for building
large projects.

> The current template library is much too heavy, prone to the "feature
creep"
> inherent in a committee-based standards process.

This is an untrue statement.

> And when the standard
> includes an inconsistency, (list<>.sort() comes to mind), we're stuck with
> it.

The alternative would be to shy away from creating libraries? Where are you
driving at?

> Now for another, related topic: The concept embodied in <algorithms> is
> sound in principle, but not practice.
>
> Take, for example, sort<>. Some applications require a stable sort, others
> do not. Some sorts result in small code; others perform quickly; some fall
> into a middle ground of size and performance. Sometimes we're merging data
> form multiple sources; sometimes, we're sorting via indirection. How can
C++
> possible expect to provide one sort<> template that solves all those
> problems? By providing a sanctified "standard" sort<> C++ implies that one
> algorithm fits all.

First of all, it's not sort, it's std::sort. Which means you can use it or
you can define your own in the global namespace or wherever you want. The
standard sort algorithm is good in most cases, has guaranteed complexity,
and is built by top professional library writers. For my money, std::sort
was good every time I needed to sort something. Your argument leads
ultimately to "reuse is bad".

> And, of course, we have the entire realm of garbage collection and "smart"
> pointers, which is a nasty tangle of divergent opinions. The auto_ptr<>
type
> has problems, as does the Boost smart_ptr<>. I don't believe one type of
> smart pointer makes sense for all applications -- and C++'s experience
with
> auto_ptr<> should teach us to avoid providing specific solutions to
general
> problems.

But of course there is one smart pointer that makes sense for all
applications. It's Loki::SmartPtr :o).

> I've always preached that code should be no more complicated than
> necessary -- and that *includes* the code I obtain from language
libraries.
> The C++ container types are heavy and detailed, when what we need is a
> simple set of light, fast containers, with hooks for adding algorithms
that
> fit individual application needs.

You might want to propose something. For me, STL is that set of light and
fast containers.

There is something I'd like to emphasize. Library design is very different
from application design and few people realize just how big the difference
is. In particular, there are amazingly few people who are good at doing
library design, though many might be brilliant at application design. I look
at this nice project built by bright developers; however, they were utterly
unable to sense the repeating coding patterns that, properly encapsulated,
would have slashed the source code size and development time by significant
factors. They just don't have the eye for it, call it "reuse pattern
blindness" or whatever. They don't realize what little things don't matter,
and what little things will grow into big bloated warts.

It is unrealistic to assert that developers using simplistic, primitive
tools can achieve the same productivity as those benefitting from libraries
built by specialized, exceptionally talented professionals. The latter are
rare, and Stepanov is one of the best.


Andrei


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

SRL> The current template library is much too heavy, prone to the
SRL>  "feature creep" inherent in a committee-based standards process.
SRL>

PB> The standards committee made very few changes to the contents of the
PB> STL as it was proposed by Stepanov and Lee. That one, in turn, had
PB> been cut back to about a third of what they had on hand. There's been
PB> no feature creep to date.

My comment is about the *future* of C++... note that I said "prone to
'feature creep'". A big one-size-fits-all class library must, of course, fit
everyone's needs -- and the more people in "everyone" (i.e., a committee),
the more likely we are to see feature creep.

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
http://www.coyotegulch.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Pete Becker wrote:
>
> Scott Robert Ladd wrote:
> >
> > The current template library is much too heavy, prone to the "feature creep"
> > inherent in a committee-based standards process.
> >
>
> The standards committee made very few changes to the contents of the STL
> as it was proposed by Stepanov and Lee. That one, in turn, had been cut
> back to about a third of what they had on hand. There's been no feature
> creep to date.
>

Except for allocators. Sorry about that...

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <VhTL6.241656$o9.35474635@typhoon.tampabay.rr.com>, Scott
Robert Ladd <scott@coyotegulch.com> writes
>My comment is about the *future* of C++... note that I said "prone to
>'feature creep'". A big one-size-fits-all class library must, of course, fit
>everyone's needs -- and the more people in "everyone" (i.e., a committee),
>the more likely we are to see feature creep.

Actually it is an example of design by democracy:) I will vote for your
favourite if you will vote for mine. This is not the only example of the
fundamental flaw of democracy:)


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Scott Robert Ladd wrote:
> Everyone has a laundry list of features they'd like to see added in the next
> revision of C++.
>
> So I'll buck the trend and suggest things we *don't* want to put in the next
> C++: More containers, and more algorithms.
>
Agree and disagree.

IMO there are two areas lumped into one std.
1. the language
2. the library

Extension of or changes to the language are only appropriate if:
- they make it more broadly useful
- they make it easier to use
- they make it easier to implement
- they make it more consistent (reprise easier to use)

My laundry list for the language is simply remove the tricky
stuff that has leaked out (eg some exceptions workarounds)
and fix the inconsistent stuff (example type_info::name()).

With respect to the library - IMO standardisation is the
only hope (for any OO system) due to the issue of "taking a view"
implicit in identifying classes and their relationships.

The templates everywhere experiment is not a success IMHO
and should be scrapped for iostreams and string/wstring or
alternatively std concrete classes should be provided for
string/wstring and base istream ostream fstream sstream
and wchar variantsetc

As "the library" is too broad a bucket to hold everyones needs
it may be better to partition it into std::libraries. These should
be added *after* the fact not invented by the comittee.

On your points:
 disagree we do need hash based associative containers
 agree we don't need new algorithms (we're not using what we have!!)

cheers
Nick



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Everyone has a laundry list of features they'd like to see added in the next
revision of C++.

So I'll buck the trend and suggest things we *don't* want to put in the next
C++: More containers, and more algorithms.

C++ iterators, algorithms, and containers are inefficient and unnecessarily
complex. The actual source code doesn't look terribly complex -- it's the
underlying mechanisms that obscure function with too much form. We heap
template upon template, giving the compiler nightmares while obscuring what
is really happening "under the hood."

Is container abstraction akin to the hiding a car's pistons from its driver?
No, because I'm not driving the car, I'm *building* it. And as any good
engineer can tell you, hidden complexity and obfuscated parts will be the
death of many software projects.

Some people argue that, for the sake of completeness, we should add
hash-based containers to the standard library. But "completeness" means
different things to different people; someone might want balanced binary
tree containers, while others would prefer to have B-Trees or r-trees
implemented. And then we get into the whole issue of graphical
development -- and you end up with Java, that tries to be everything to
everyone but does few things particularly well.

The current template library is much too heavy, prone to the "feature creep"
inherent in a committee-based standards process. And when the standard
includes an inconsistency, (list<>.sort() comes to mind), we're stuck with
it.

Now for another, related topic: The concept embodied in <algorithms> is
sound in principle, but not practice.

Take, for example, sort<>. Some applications require a stable sort, others
do not. Some sorts result in small code; others perform quickly; some fall
into a middle ground of size and performance. Sometimes we're merging data
form multiple sources; sometimes, we're sorting via indirection. How can C++
possible expect to provide one sort<> template that solves all those
problems? By providing a sanctified "standard" sort<> C++ implies that one
algorithm fits all.

And, of course, we have the entire realm of garbage collection and "smart"
pointers, which is a nasty tangle of divergent opinions. The auto_ptr<> type
has problems, as does the Boost smart_ptr<>. I don't believe one type of
smart pointer makes sense for all applications -- and C++'s experience with
auto_ptr<> should teach us to avoid providing specific solutions to general
problems.

I've always preached that code should be no more complicated than
necessary -- and that *includes* the code I obtain from language libraries.
The C++ container types are heavy and detailed, when what we need is a
simple set of light, fast containers, with hooks for adding algorithms that
fit individual application needs.

Anything else is trying to be Java. ;)

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
http://www.coyotegulch.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Scott Robert Ladd wrote:
>
> The current template library is much too heavy, prone to the "feature creep"
> inherent in a committee-based standards process.
>

The standards committee made very few changes to the contents of the STL
as it was proposed by Stepanov and Lee. That one, in turn, had been cut
back to about a third of what they had on hand. There's been no feature
creep to date.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]