This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
> 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
Attachment:
p.20071221-1
Description: Binary data
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |