Member is @disable this(this), parent uncopyable
Alex
sascha.orlov at gmail.com
Fri Mar 22 13:24:35 UTC 2019
On Friday, 22 March 2019 at 12:08:39 UTC, James Blachly wrote:
> I have a struct S with member containers.UnrolledList [1].
> UnrolledList is @disable this(this), but this unfortunately
> makes my struct S also un-copyable, which now breaks some of my
> debugging statements which rely on toString, as writeln,
> format, etc. all copy the object. This leaves me in the
> unfortunate situation that my release builds work, but debug
> builds do not.
>
> First, how do we deal with toString, std.format, writeln, etc.
> with un-copyable objects, when it is only a member that is
> uncopyable? In my case I got around this by creating a pointer
> and moving the initialization to the constructor, but I wonder
> if there are other ways?
You could (and should) define your custom toString() method
inside the struct S, where un-copyable (or other strange kinds)
members are part of.
In such a way, you could
S s;
s.toString(), without any harm, possibly omitting the members,
which you are sure of (such as UnrolledList?).
https://wiki.dlang.org/Defining_custom_print_format_specifiers
And, as a joke: Why are you debugging via printing and not by
writing asserts, heh? ;)
>
> Second, why must an object in its entirety be copy-able for
> these functions to call toString() ?
If you pass your struct S to toString of std, how should it know,
which members can be omitted? And well... S is copied because std
assumes, structures are cheap.
>
> Finally, the error message gave no clue that it was a member
> (UnrolledList in my case) that was @disable 'd and it took some
> digging back through several commits to figure out what was
> happening -- how could we improve the error messaging?
>
> Thanks as always in advance
>
> [1] https://github.com/dlang-community/containers
More information about the Digitalmars-d-learn
mailing list