On Tuesday, June 18, 2013 10:27:11 Joseph Rushton Wakeling wrote: > On 06/18/2013 08:06 AM, Jonathan M Davis wrote: > > It would probably be a pretty easy sell though, since it can probably > > stay > > mostly the same aside from the struct -> class change (though at that > > point, we might as well take the opportunity to make sure that anything > > else that should be redesigned about it gets redesigned appropriately). > > Yea, this is also my feeling, which is part of why I'm pushing this concept > of "random ranges" -- I want to ensure that the related issues are properly > understood and discussed and some well-thought-out design patterns are > prepared in order to ensure good and statistically reliable functionality > in std.random2. > > One small note -- I'd have thought that a struct with an internal > pointer-to-payload (allocated using manual memory management, not GC) would > have been a superior design for pseudo-random number generators compared to > making them final classes. The latter is just the easiest thing to do for > simple tests of PRNG-as-reference-type.
An internal payload might make more sense, but it probably needs to be done in a way that it can be controlled (which may require custom allocators), because even allocating with malloc all the time might be a problem for the guys who are really picky about memory stuff - though maybe that level of customization could be added later. I don't know. I also don't work in that kind of environment, so I don't know exactly what such programmers find acceptable. - Jonathan M Davis