In article <8idn71$ht4$1@plutonium.btinternet.com>,
chrisnewton@no.junk.please.btinternet.com says...

> I certainly feel that the iterators, etc., mentioned by Jean-Daniel are
> unnecessary for such a simple concept. As with my initial reseeding
> suggestion, these are things which could be added if necessary, but are
> likely to be used so infrequently compared to the generator itself that
> they seem overweight to me.

I think an input iterator class for a random number generator would be
quite useful (think about copying random numbers into a container, etc).
In any event, I don't think the issue of deciding on the functionality
of such classes should prevent them from being considered as additions
to the C++ library. Such decisions need to be made for every library
component. Just as with the rest of the library, a standard random
number generator class need not be the last word on the subject. The
simple interface provided by the C library would be a good place to
start.

The issue with srand/rand, as I see it, is that it involves static
storage and that it doesn't integrate particularly well with the rest of
C++. If one needs several independent random number generators, perhaps
of different types, srand/rand isn't very useful. In my own programming,
I've defined a random number generator base class from which I derived
various classes for different types of generators. Yet because what I've
done isn't standard, I can't easily pass my random number generator
objects to third party functions that need a source of random numbers.
It does seem like this is an area where standardization would be useful.
Perhaps the standard could define a simple base class and one generator
type (say, a linear congruential generator) just to provide a framework.
Standardizing the interface to some functionality is as important... and
maybe even more important than providing that functionality.

Peter

---
[ 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              ]

FYI: http://www.boost.org/libs/random/index.html

---
[ 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              ]

Jean-Daniel Nicolet <jdn@llinkvest.ch> wrote...
> > Chris Newton wrote...
> >
> <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. [...]

I was actually thinking of this from a very simplistic point of view. C
provides a straightforward way to generate pseudo-random numbers in
srand/rand. It isn't really very specific about what these do, but for
many practical purposes, they're good enough. If you're into serious
numerical analysis, probability, etc., then you probably use your own
algorithms already. I was simply wondering whether C++ couldn't provide
(as standard) a similar level of functionality within a library class.

Perhaps even a reseeding method would be over-complicated for these
purposes. The class really need only have a constructor which seeds the
generator and a random number generation method. As a convenient
side-effect, if it doesn't have a default constructor, then a seed must
be specified; contrast this with the ability to forget to call srand in
C.

I certainly feel that the iterators, etc., mentioned by Jean-Daniel are
unnecessary for such a simple concept. As with my initial reseeding
suggestion, these are things which could be added if necessary, but are
likely to be used so infrequently compared to the generator itself that
they seem overweight to me.

By the way, this actually arose because I found myself needing a random
number in a large-scale project. I had no idea whether the srand/rand
system was in use elsewhere in the program, and any action I took
locally using srand/rand had the potential to interfere with other areas
of the code. As it happens, I had a workaround available at the time,
but had I not done so, this would have been a serious inconvenience.

> 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.

The tokenizer example is certainly more involved than the random number
one, although I feel tokenizing is common enough an operation to merit
some consideration (as, apparently, did those who specified the standard
C library). As with random numbers, however, I was envisaging a very
straightforward set-up.

Having thought about it a little more, perhaps a small change to the
standard library streams would be sufficient. After all, basic_istream
already supports a similar concept in its use of operator>>. It is
slightly surprising that the functionality was not extended to allow an
arbitrary set of termination characters rather than just, e.g.,
whitespace. Given the generic nature of the library elsewhere, a boolean
"stop at white space" flag seems somewhat out-of-place, but this seems
to be all we have without significant customization.

> 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.

I agree that it would be good to integrate any new functionality with
the existing library as well as possible. However, in the random number
case that is my main concern here, I feel this is unduly complicated.
It's a simple idea, which I humbly suggest is worthy of a simple
extension to the standard library.

Regards,
Chris


---
[ 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              ]