Chris Newton wrote:
[...]
> It seems to me that srand (a universal seeding function, affecting an
> entire program) is a little too greedy for C++ philosophy. Two
> different parts of a program cannot have independent random number
> generators using the provided mechanism, because there is no way to
> seed them independently.
[...]
>
> I will note in passing that a similar argument could apply to strtok,
> also inherited from C.
[...]
>
> I am sure there must be other examples of this situation, where
> universal C library functionality is inherited by C++ but not really
> provided in a C++ style. I would welcome background information from
> those in the know. Surely these issues must have been considered, but
> I have found no particular information in this group's history, D&E,
> etc., about why these areas were left unchanged in C++.

There have been a few discussions on news:comp.std.c about the
subject of "thread-safe standard library functions", which talks
about the behavior of several of the standard C library functions,
like rand() and strtok(), that rely on global data between calls.

I proposed adding new functions to the standard C library (which
included relacements for rand(), strtok(), and others) that didn't
exhibit this kind of behavior, but my proposal was rejected.
See <http://david.tribble.com/text/c9xthr.txt>.  I think part of
my problem was the fact that I used the term "multithreaded", when
no such concept exists in the ISO C (or ISO C++) standard.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Chris Newton wrote:

> Out of curiosity, has the C++ standards committee ever discussed the
> facilities to generate random numbers inherited from C (srand/rand), and
> the possibility of including a more friendly version in C++?

You might want to check out Jens Maurer's new Random Number Library.  It
provides an extensible framework of random number generators,
distributions, and adapters.  See http://www.boost.org

> ...
>
> I am sure there must be other examples of this situation, where
> universal C library functionality is inherited by C++ but not really
> provided in a C++ style. I would welcome background information from
> those in the know. Surely these issues must have been considered, but I
> have found no particular information in this group's history, D&E, etc.,
> about why these areas were left unchanged in C++.

Please understand that the C++ standards committee is made up of
volunteers.  If no one volunteers to do something, it doesn't happen.

One of the motivations behind the boost web site was to develop possible
future standard library extensions. You might want to join that mailing
list if you are interested in providing such a set of C++ wrappers.

--Beman Dawes

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

Dear all,

Out of curiosity, has the C++ standards committee ever discussed the
facilities to generate random numbers inherited from C (srand/rand), and
the possibility of including a more friendly version in C++?

It seems to me that srand (a universal seeding function, affecting an
entire program) is a little too greedy for C++ philosophy. Two different
parts of a program cannot have independent random number generators
using the provided mechanism, because there is no way to seed them
independently.

Generating random numbers from an initial seed seems a natural candidate
for encapsulation in a random_generator class. It need only provide a
constructor which accepts a seed value and a method to return a random
number, and possibly a reseeding method. I cannot see any convenient way
of providing such functionality using the standard library as it stands.

I will note in passing that a similar argument could apply to strtok,
also inherited from C. Again, this function has a universal effect, and
a tokenizer class would be a relatively straightforward addition. It
need only accept a string in its constructor, and provide a method to
return the next token. Perhaps it would make sense to provide a template
tokenizer instead; this seems a prime candidate for generic programming.

I am sure there must be other examples of this situation, where
universal C library functionality is inherited by C++ but not really
provided in a C++ style. I would welcome background information from
those in the know. Surely these issues must have been considered, but I
have found no particular information in this group's history, D&E, etc.,
about why these areas were left unchanged in C++.

Thanks,
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              ]