Hi all,
I'm implementing a deep-copy method for a tree of templated class
instances. As part of this, I need some way to copy each node.
I want to avoid code that does things like casting objects into
byte arrays and then copying raw bytes; I want all operations to
be memory safe things tha
On Wednesday, 26 September 2018 at 20:41:38 UTC, Chad Joan wrote:
I'm implementing a deep-copy method for a tree of templated
class instances. As part of this, I need some way to copy each
node.
[...]
that isn't already handled by their deepCopy method.
I would strongly suggest just using th
On 9/26/18 4:41 PM, Chad Joan wrote:
Hi all,
I'm implementing a deep-copy method for a tree of templated class
instances. As part of this, I need some way to copy each node. I want
to avoid code that does things like casting objects into byte arrays and
then copying raw bytes; I want all ope
On Wednesday, September 26, 2018 3:24:07 PM MDT Adam D. Ruppe via
Digitalmars-d-learn wrote:
> Object.factory kinda sux and I'd actually like to remove it
> (among other people). There's no plan to actually do that, but
> still, just on principle I want to turn people away.
While there may not cu
On Wednesday, 26 September 2018 at 23:32:36 UTC, Jonathan M Davis
wrote:
On Wednesday, September 26, 2018 3:24:07 PM MDT Adam D. Ruppe
via Digitalmars-d-learn wrote:
Object.factory kinda sux and I'd actually like to remove it
(among other people). There's no plan to actually do that, but
still,
On Wednesday, 26 September 2018 at 21:24:07 UTC, Adam D. Ruppe
wrote:
On Wednesday, 26 September 2018 at 20:41:38 UTC, Chad Joan
wrote:
I'm implementing a deep-copy method for a tree of templated
class instances. As part of this, I need some way to copy
each node.
[...]
that isn't already han
On Wednesday, September 26, 2018 10:20:58 PM MDT Chad Joan via Digitalmars-
d-learn wrote:
> On Wednesday, 26 September 2018 at 23:32:36 UTC, Jonathan M Davis
>
> wrote:
> > On Wednesday, September 26, 2018 3:24:07 PM MDT Adam D. Ruppe
> >
> > via Digitalmars-d-learn wrote:
> >> Object.factory kind
On Wednesday, 26 September 2018 at 21:25:07 UTC, Steven
Schveighoffer wrote:
...
Object.factory is a really old poorly supported type of
reflection. I would not depend on it for anything.
Roger that. Will avoid :)
You are better off using your own registration system.
As far as choosing
On Thursday, 27 September 2018 at 05:12:06 UTC, Jonathan M Davis
wrote:
On Wednesday, September 26, 2018 10:20:58 PM MDT Chad Joan via
Digitalmars- d-learn wrote:
...
That's interesting! Thanks for mentioning.
If you don't mind, what are the complaints regarding Object?
Or can you link me t
On Thursday, September 27, 2018 1:41:23 AM MDT Chad Joan via Digitalmars-d-
learn wrote:
> On Thursday, 27 September 2018 at 05:12:06 UTC, Jonathan M Davis
> This is also reminding me of how it's always bugged me that there
> isn't a way to operator overload opEquals with a static method
> (or eve
On Thursday, 27 September 2018 at 08:19:41 UTC, Jonathan M Davis
wrote:
On Thursday, September 27, 2018 1:41:23 AM MDT Chad Joan via
Digitalmars-d- learn wrote:
On Thursday, 27 September 2018 at 05:12:06 UTC, Jonathan M
Davis
This is also reminding me of how it's always bugged me that
there i
On Wednesday, 26 September 2018 at 20:41:38 UTC, Chad Joan wrote:
class Root(T)
{
T x;
}
class Extended(T) : Root!T
{
T y;
}
Sorry for a technical aside, but would this be something for you?
https://forum.dlang.org/post/vtaxcxpufrovwfrkb...@forum.dlang.org
I mean... In eithe
On Thursday, September 27, 2018 2:44:25 AM MDT Chad Joan via Digitalmars-d-
learn wrote:
> The spec seems to have the homogeneous cases covered: classes
> with classes or structs with structs. What I'm more worried
> about is stuff like when you have a class compared to a struct or
> builtin type,
On Thursday, 27 September 2018 at 05:18:14 UTC, Chad Joan wrote:
How does this work?
The language reference states that typeid(Type) returns "an
instance of class TypeInfo corresponding to Type".
(https://dlang.org/spec/expression.html#typeid_expressions)
But then the TypeInfo class doesn't s
On Thursday, 27 September 2018 at 05:04:09 UTC, Chad Joan wrote:
The tree nodes are potentially very diverse, but the tree
structure itself will be very homogeneous.
The virtual method can still handle that case!
But, if your child array of expressions is already accessible
through the base i
On 9/27/18 1:18 AM, Chad Joan wrote:
On Wednesday, 26 September 2018 at 21:25:07 UTC, Steven Schveighoffer
wrote:
...
Object.factory is a really old poorly supported type of reflection. I
would not depend on it for anything.
Roger that. Will avoid :)
You are better off using your own reg
On 9/27/18 10:20 AM, Steven Schveighoffer wrote:
typeid sometimes gives you a more derived type than TypeInfo. Including
for classes and structs.
In the past, .classinfo gave you a different thing than typeid(obj), but
now it is the same thing:
auto obj = new Object;
// classinfo
On Thursday, 27 September 2018 at 08:56:22 UTC, Alex wrote:
On Wednesday, 26 September 2018 at 20:41:38 UTC, Chad Joan
wrote:
class Root(T)
{
T x;
}
class Extended(T) : Root!T
{
T y;
}
Sorry for a technical aside, but would this be something for
you?
https://forum.dlang.o
On Thursday, 27 September 2018 at 18:37:27 UTC, Chad Joan wrote:
I will probably end up going with the latter suggestion and
have Extended use the Root's T. That would probably make sense
for what I'm doing. In my case, the T allows the caller to
configure what kind of output the thing prov
On Thursday, 27 September 2018 at 14:23:48 UTC, Steven
Schveighoffer wrote:
On 9/27/18 10:20 AM, Steven Schveighoffer wrote:
typeid sometimes gives you a more derived type than TypeInfo.
Including for classes and structs.
In the past, .classinfo gave you a different thing than
typeid(obj), bu
On Thursday, 27 September 2018 at 13:16:58 UTC, Adam D. Ruppe
wrote:
On Thursday, 27 September 2018 at 05:18:14 UTC, Chad Joan wrote:
How does this work?
The language reference states that typeid(Type) returns "an
instance of class TypeInfo corresponding to Type".
(https://dlang.org/spec/expr
On Thursday, 27 September 2018 at 13:23:15 UTC, Adam D. Ruppe
wrote:
On Thursday, 27 September 2018 at 05:04:09 UTC, Chad Joan wrote:
As above, I think this might be a very clean and effective
solution for a different class of use-cases :) I'll keep it
in mind though.
Yeah. And I did make on
On Thursday, 27 September 2018 at 09:58:25 UTC, Jonathan M Davis
wrote:
For two types to be compared, they must be the the same type -
or they must be implicitly convertible to the same type, in
which case, they're converted to that type and then compared.
So, as far as D's design of comparis
23 matches
Mail list logo
