www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Member is disable this(this), parent uncopyable

reply James Blachly <james.blachly gmail.com> writes:
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?

Second, why  must an object in its entirety be copy-able for these 
functions to call toString() ?

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
Mar 22 2019
parent reply Alex <sascha.orlov gmail.com> writes:
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
Mar 22 2019
parent James Blachly <james.blachly gmail.com> writes:
On 3/22/19 9:24 AM, Alex wrote:

 On Friday, 22 March 2019 at 12:08:39 UTC, James Blachly wrote:

 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?).


Hi Alex,

Thanks for replying. I attribute the lack of sensibleness in my post to 
lack of sleep.

I actually am defining toString as member function of S, but it only now 
occurred to me that structs are always passed by value, not by 
reference. Of course then it cannot be copied.

Thanks again =)
Mar 22 2019