> Chris Newton wrote in message <8i8l7j$ka7$1@neptunium.btinternet.com>...
>
<about ++isation of various C features like random numbers, tokenizers, etc>

I agree in theory with the expressed wishes, tough a lot of questions very
quickly arise when thinking about that subject.

Random numbers: the first question is: how much functionality should such a
class provide ? Chris Newton already mentioned the possibility of a
reseeding method, but there are other features that come to mind. If
reseeding is possible, it should also be possible to extract the current
seed, to be able to re-sart the generator at the same point later in time.
What about integer-rounding (whole random numbers within a given range, e.g.
to implement a dice) ? Should we be happy with uniform-distribution random
numbers or should the standard also offer other distributions as well ?
(exponential, poisson, normal, and, and...). More fundamentally should such
a class not be implemented as an input iterator, to allow better integration
with STL algorithms ? Why not a bidirectional iterator ? or should only an
iterator wrapper be provided around a more conventional class ?

Tokenizers: It seems to me that conformance with iterator interface is yet
more important for a tokenizer class than for random numbers, but which kind
of iterator ? input ? forward ? bidirectional ? or even random ? each could
be useful, but the implementation complexity and efficiency is clearly very
different, so the choice may be tough for people involved in the
standardization process.

Having experimented a little with the wrapping of C features in C++ classes,
I've found the STL conformance a real bonus, but found it difficult to
implement it properly and efficiently. There is for example the problem that
such iterators faking an absent container, although perfectly usable and
conform, are usually not light-weight objects anymore, so given the
frequency with which they are copied in the standard algorithms, a
reference-counted implementation may be necessary, but this has an
additional price in code size and efficiency.

Producing an implementation universal enough to please to the vast majority
of users will be still more difficult.

Summarizing it: I would be very pleased to find such classes in a future
standard, but there is still a long way to go.

Jean-Daniel Nicolet
Software Consultant
Geneva
Switzerland


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]