Re: Cameleon: Stricter Alternative Implementation of VariantN
On Monday, 21 September 2015 at 13:42:14 UTC, Nordlöw wrote: The code is here: https://github.com/nordlow/justd/blob/master/cameleon.d Moved to https://github.com/nordlow/justd/blob/master/vary.d Templates are no called: - FastVariant - PackedVariant
Re: Cameleon: Stricter Alternative Implementation of VariantN
On Monday, 21 September 2015 at 13:42:14 UTC, Nordlöw wrote: Questions: - Is the logic of opAssign and get ok for string? - How does the inner workings of the GC harmonize with my calls to `memcpy` in `opAssign()` here https://github.com/nordlow/justd/blob/master/cameleon.d#L80 That line won't compile, so don't be afraid of its behavior. - Do I have to call some GC-logic in order to make the GC aware of the new string-reference in `opAssign`? Make sure your struct is always sizeof(void*)-aligned.
Re: Cameleon: Stricter Alternative Implementation of VariantN
You can generate a union from allowed types, it will make copies type safe too, sort of set!(staticIndexOf(T, AllowedTypes))(rhs)... hmm... can it be an overload?
Re: Cameleon: Stricter Alternative Implementation of VariantN
On Tuesday, 22 September 2015 at 12:47:31 UTC, Per Nordlöw wrote: How does the GC know if the data block contains a reference (pointer) or value type? Does it try to follow that pointer either way!? If so when does this memory scanning occurr?
Re: Cameleon: Stricter Alternative Implementation of VariantN
On Tuesday, 22 September 2015 at 09:57:58 UTC, Kagamin wrote: Make sure your struct is always sizeof(void*)-aligned. Could that be automatically enforced somehow based on the contents of AllowedTypes?
Re: Cameleon: Stricter Alternative Implementation of VariantN
On Tuesday, 22 September 2015 at 09:57:58 UTC, Kagamin wrote: - Do I have to call some GC-logic in order to make the GC aware of the new string-reference in `opAssign`? Make sure your struct is always sizeof(void*)-aligned. How does the GC know if the data block contains a reference (pointer) or value type? Does it try to follow that pointer either way!?
Re: Cameleon: Stricter Alternative Implementation of VariantN
On Tuesday, 22 September 2015 at 12:54:47 UTC, Kagamin wrote: You can generate a union from allowed types, it will make copies type safe too, sort of set!(staticIndexOf(T, AllowedTypes))(rhs)... hmm... can it be an overload? I believe there is a trait somewhere that figures out the maximum alignment needed for a set/union of types. I think Walter spoke about in a DConf lecture some time ago.
Cameleon: Stricter Alternative Implementation of VariantN
Because I'm not satisfied with the current state of memory-layout-flexibility/pureness/safeness/nogc/nothrow-ness of `VariantN` I've hacked together a lightweight version of `VariantN`, I currently call `Cameleon`. The code is here: https://github.com/nordlow/justd/blob/master/cameleon.d Its currently limited to my specific needs (strings and value-types) through https://github.com/nordlow/justd/blob/master/cameleon.d#L5 https://github.com/nordlow/justd/blob/master/cameleon.d#L35 because it's hard to decrypt the inner `OpID`-workings of `VariantN`. Questions: - Is the logic of opAssign and get ok for string? - How does the inner workings of the GC harmonize with my calls to `memcpy` in `opAssign()` here https://github.com/nordlow/justd/blob/master/cameleon.d#L80 https://github.com/nordlow/justd/blob/master/cameleon.d#L107 and my zeroing of the internal data buffer in `clear()` here https://github.com/nordlow/justd/blob/master/cameleon.d#L143 ? - Do I have to call some GC-logic in order to make the GC aware of the new string-reference in `opAssign`? - Is this logic for `char[]` different from `(immutable char)[]`? - And what do I need to think about if I allow classes as members?
