Boost logo

Boost :

From: dietmar_kuehl (dietmar_kuehl_at_[hidden])
Date: 2002-02-19 06:56:21

Vladimir Ciobanu <psycho_at_t...> wrote:
> I don't actually know what can be done to make const_iterator,
> const iterator, but it'd be quite a good idea. imho.

As I have pointed out several times in the past, the problem about
iterators is that they are two concepts bundled into one: An iterator
is a position and a property access strategy combined into one
concept. This causes lots of porblems and the difference between
'iterator' and 'const_iterator' is just one of them (restrictions on
the value type, eg. that it cannot be a proxy, and problems with
projections are others).

If we are to address this issue, it is a clean-up of the whole STL
basing it on finer grained concepts:
- An iterator would merely provide a position and no form of property
  access, at least not on a conceptual level.
- A property map (see Boost Graph Library) would provide the details
  how to access a property given a suitable iterator.

Although I think that STL is a brilliant approach at what problems it
addresses (generic implementation of algorihtms), I think that STL is
buggy (that is, the conceptual basis has some bugs; I'm not talking
about implementations having bugs). In particular I see the following
issues (at least; there are probably more which I will remember as
soon as I have sent this message :-)

- The iterator vs. property map problem mentioned above.
- Algorithms taking two input sequence (eg. 'std::mismatch()')
  typically take only a start iterator for the second sequence which
  effectively means that the second sequence has to be at least as
  long as the first one. This cannot be determined in all cases (eg.
  if both sequences are based on input iterators).
- 'begin()', 'end()', etc. should probably not be specified to be
  member functions: It would be more reasonable to use them either as
  functions at namespace scope or as members of traits classes. This
  would also allow generic implementations of certain functions based
  on a core minimal set of functions (eg. inserting a sequence can be
  implemented via individual insetions; just for optimizing things a
  special version would need to be implemented).

Other than this, I think that STL usage would become easier if
sequences could optionally be specified as something which looks
like a 'std::pair<>' of iterators (ie. has member 'first' and
'second' to represent the begin and [past] the end iterators,
respectively): This is rather handy if you have functions producing
sequences which are then in turn to be used as input to functions
taking sequence.

Not to mention, of course, all the missing features in STL like
various functors ("identity", "composition", ...), algorithms,
concepts, etc.

<mailto:dietmar_kuehl_at_[hidden]> <>
Phaidros eaSE - Easy Software Engineering: <>

Boost list run by bdawes at, gregod at, cpdaniel at, john at