using tr1's random in parallel/random_number.h

[Benjamin Kosnik]

> I think we can use TR1 functionality for some or all of this file.
> Here's a patch to use TR1's mersenne_twister. The next step would be
> trying to replace __gnu_parallel::random_number with TR1 equivalents
> and change usage.

Hmmm.

Well, here's the evolution of this patch. It uses tr1/random and
tr1/cstdint for some of the types in parallel mode. It's more of a
"request for help" than a patch submission.

It's not done yet though.... I am having problems with random_shuffle.
I'm not quite sure how to work the templates in that file: in this
diff I think I confused random number generators with engines. Part
of this problem is the existing issues with this in the code....
also, why does  DRSSorterPU take a RandomNumberGenerator template
parameter if there is nothing dependent on this type in the class? 

With this patch I get two new failures that demonstrate the incomplete
nature of this transition.

FAIL:
25_algorithms/random_shuffle/requirements/explicit_instantiation/2.cc
(test for excess errors) FAIL:
25_algorithms/random_shuffle/requirements/explicit_instantiation/pod.cc
(test for excess errors)

In addition, these new fails (expected) for using tr1:

FAIL: 17_intro/using_namespace_std_tr1_neg.cc  (test for errors, line
64)

Anyway. 

I also have not checked the performance implications of this patch.

I do think that re-using more standard types for stuff in parallel mode
is a good idea. Thoughts?

-benjamin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p.20071221-1
Type: application/octet-stream
Size: 50557 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20071224/494353dd/attachment.obj>