CT Inheritence structures
I am trying to get Timon Gehr's code working, with some
modifications:
public template TypeParent(P)
{
import std.traits;
alias T = TemplateArgsOf!P;
alias Seq(T...) = T;
static if (T.length == 0 || is(typeof(T[0]) == typeof(null)))
{
alias TypeParent = Seq!();
}
else
{
alias TypeParent = Seq!(P!(T[0..T.length-1]));
}
}
class Type(T...) : TypeParent!(Type!T)
{
int x;
static if (T.length >= 1 && T[0] is "Animal")
{
int y;
static if (T.length >= 2 && T[1] is "Dog")
{
int z;
static if (T.length >= 3&& T[2] is "Pug")
{
int s;
}
}
}
}
void main()
{
import std.traits;
auto a = new Type!("Animal", "Dog", "Pug")();
Type!("Animal", "Dog") b = a;
Type!("Animal") c = b;
a.s = 1;
b.z = 2;
c.y = 3;
}
The problem is that b and c are of type P!
Type!("Animal", "Dog", "Pug")
P!("Animal", "Dog")
P!"Animal"
Of course, P should be Type and b.z and c.y should change a's
variables.
I don't know why
alias TypeParent = Seq!(P!(T[0..T.length-1]));
is returning P but I guess I'm doing it wrong. What I want is for
it to return Type!(T[0],...,T[n-1]);
Any ideas?
Re: MurmurHash3 behaviour
On Friday, 19 August 2016 at 21:03:22 UTC, Seb wrote: http://dlang.org/phobos-prerelease/std_digest_murmurhash.html Ah great, I just finished writing my own murmurhash digest module ( https://github.com/Cauterite/phobos/blob/murmur/std/digest/murmur.d ), and now I discover someone's already done it. Glad I wasted the last 3 hours of my life ;_;
Re: MurmurHash3 behaviour
On Friday, 19 August 2016 at 20:28:13 UTC, Cauterite wrote:
Regarding the MurmurHash3 implementation in core.internal.hash,
it is my understanding that:
// assuming a and b are uints
bytesHash([a, b], 0) == bytesHash([b], bytesHash([a], 0))
Is this correct?
I'm just not quite certain of this property when I try to read
the code myself, and I don't know much about hash algorithms.
Phobos nightly contains MurmurHash3 in std.digest (I don't know
why there are two implementations though), but I think this one
will be easier to use ;-)
http://dlang.org/phobos-prerelease/std_digest_murmurhash.html
The API for bytesHash is
size_t bytesHash(const(void)* buf, size_t len, size_t seed)
so shouldn't be?
auto arr = [a,b];
bytesHash(, arr.length, 42);
I'm just not quite certain of this property when I try to read
AFAIK the output of a hash isn't generally equal to the its
upcoming seed as pre & postpreprocessing may apply. In the case
of Murmurhash3 its post-processing (h1 ^= len):
void main() {
import std.stdio;
import core.internal.hash;
uint a = 4, b = 23;
auto arr = [a, b];
auto b1 = bytesHash(, arr.length, 42);
auto l = arr[0..1], r = arr[1..$];
auto b2a = bytesHash(, 1, 42);
auto b2b= bytesHash(, 1, b2a);
assert(b1 == b2b);
}
However with std.digest you can "save" the current state of a
hash function and continue to give new items to the hasher:
void main()
{
import std.digest.murmurhash; // required Phobos nightly
uint a = 4, b = 23;
auto arr = [a, b];
auto l = arr[0..1], r = arr[1..$];
MurmurHash3!32 hasher;
hasher.put(cast(ubyte[]) l);
hasher.put(cast(ubyte[]) r);
auto v1 = hasher.finish();
hasher = MurmurHash3!32();
hasher.put(cast(ubyte[]) arr);
auto v2 = hasher.finish();
assert(v1 == v2);
}
MurmurHash3 behaviour
Regarding the MurmurHash3 implementation in core.internal.hash, it is my understanding that: // assuming a and b are uints bytesHash([a, b], 0) == bytesHash([b], bytesHash([a], 0)) Is this correct? I'm just not quite certain of this property when I try to read the code myself, and I don't know much about hash algorithms.
Re: typeof.stringof wrong type
On Friday, 19 August 2016 at 18:52:02 UTC, Jonathan M Davis wrote: Unfortunately, once you start doing stuff with things like __traits(allMembers, ...), you're dealing with strings You should immediately go back into symbol land by passing that string into __traits(getMember). I agree that stringof is almost always a bug, if not ALWAYS a bug, when seen in code generator. There's better ways.
Re: typeof.stringof wrong type
On Friday, 19 August 2016 at 15:47:00 UTC, ag0aep6g wrote: https://dlang.org/spec/property.html#stringof Someone should edit that, if fullyQualifiedName is no good either. Indeed. I'm sure the change was well-intentioned, but symbol visibility/import concerns and Voldemort types should make it abundantly clear that this can't work ever work in the general case. — David
Re: typeof.stringof wrong type
On 08/19/2016 05:36 PM, David Nadlinger wrote: This is a misconception. Neither .stringof nor fullyQualifiedName should *ever* be used in code generation. The spec itself recommends fullyQualifiedName for code generation: Note: Using .stringof for code generation is not recommended, as the internal representation of a type or expression can change between different compiler versions. Instead you should prefer to use the identifier trait, or one of the Phobos helper functions such as fullyQualifiedName. https://dlang.org/spec/property.html#stringof Someone should edit that, if fullyQualifiedName is no good either.
Re: typeof.stringof wrong type
On Friday, 19 August 2016 at 15:15:55 UTC, ag0aep6g wrote:
I think that qualifies as a bug, because fullyQualifiedName is
supposed to be usable in code generation.
This is a misconception. Neither .stringof nor fullyQualifiedName
should *ever* be used in code generation. There is a myriad of
things that make strings unsuitable in the general case. The most
obvious reason are imports: think a type coming via an alias
parameter from a second module, which is not even important at
the point of the mixin.
Instead of trying to make .stringof work do things it will never
be able to, you need to use the type just as you would at the
point of the mixin. In this example, you would write
`mixin("typeof(a) d");`.
— David
Re: typeof.stringof wrong type
fullyQualifiedName doesn't work with BitFlags for example:
import std.stdio;
import std.typecons;
import std.traits;
enum Stuff
{
asdf
}
void main()
{
BitFlags!Stuff a;
typeof(a) b;
mixin(fullyQualifiedName!(typeof(a)) ~ " c;");
mixin(typeof(a).stringof ~ " d;");
}
Both mixins fail. fullyQualifiedName!(typeof(a)) becomes:
std.typecons.BitFlags!(test.Stuff, cast(Flag)false)
"cast(Flag)false" should be "cast(Flag!"unsafe")false". So string
template parameter "unsafe" is missing. The same problem as I
described before ("Flag" is an enum template like in my first
example).
Re: Serialize/Deserialize Tuple
On Friday, 19 August 2016 at 09:55:32 UTC, Steve Biedermann wrote: I'm trying to send data over the network. On the receiving side, I need a tuple of the sent values. Is there any way to achieve this? Depends on the format the data is send in. There are a number of serialization/deserialization libraries: binary: https://github.com/atilaneves/cerealed Others: http://code.dlang.org/search?q=serial+painlessjson+cerealed
Re: RSA library
On Thursday, 18 August 2016 at 17:56:54 UTC, Andre wrote: I will try the windows api, from the description it seems exactly what i need. CNG was introduced in Vista if it matters.
Serialize/Deserialize Tuple
I'm trying to send data over the network. On the receiving side, I need a tuple of the sent values. Is there any way to achieve this?
