On Tuesday, 21 January 2014 at 12:32:43 UTC, bearophile wrote:
terchestor:
https://github.com/Terchestor/dlang/tree/Tausworthe-class
/++
§§§ Tausworthe
What's the purpose of those §? They add noise. If they aren't
necessary I suggest to remove them.
Well, a fantasy, but I wont keep it!
class Tausworthe ( I, F ) if ( __traits(isIntegral, I ) &&
__traits(isFloating, F ) )
I suggest to not put spaces around ( ). And if you want also
remove the space after the class/functions name.
That's an old usage of mine.
Perhaps you want to use a struct? The decision is important.
Are your methods all virtual?
Not a struc, I need a class.
{
alias I integral_t;
alias F floating_t;
Today the syntax "alias Name = Foo;" is preferred.
I knew not. Do ypu mean: alias integral_t = I;
In D code the use of "_t" as suffix for types is less common.
And perhaps it's better to use a starting upper case letter for
their name.
I forgot the Capital letter, but I like the trailing _t, like
size_t.
enum tauswortheConstFloat : floating_t
{
tau0 = 4294967296.0f
Class/struct/Enum/Union names should start with an upper case
letter.
tau1 = 4294967294,
Perhaps that literal can end with a U.
~this( )
{ }
No need for this.
Of course!
void seed( integral_t seed_=1 )
...
auto s = seed_;
In general annotate with enum/const/immutable all variables
that don't need to mutate.
I'd better put an assertion (or enforce?) to be sure seed won't
be null, and give constantness to seed.
integral_t fseed( const integral_t s_ )
{
return ( tauswortheConst.lgc * s_ ) &
tauswortheConst.mask;
}
That's probably better annotated as pure nothrow.
OK.
}//§§==========END_CLASS::Tausworthe==========
I suggest to reduce the amount of === in this code.
OK.
auto ?tausworthe0 = new Tausworthe!(ulong, double);
While D supports Unicode identifiers, they are a often a pain
in the ass (this is a personal opinion), so perhaps you want to
kill them all.
Not sure. I'm experimenting a kind of tagging to easily
distinguish nested functions (with greek phi) or temporaries.
Perhaps not a so good idea, but i'll see if enhances the
readability later.
//§§ __COPYRIGHT_NOTICE__
I think there's a ddoc field syntax for the copyright in the
module ddoc.
Yes, but it's a work on progress...
Thank you so much for your invaluable help.