Scope Containers

bitwise bitwise.pvt at gmail.com
Fri Mar 15 16:11:19 UTC 2019


On Wednesday, 13 March 2019 at 08:49:37 UTC, Atila Neves wrote:
> On Tuesday, 12 March 2019 at 21:06:17 UTC, bitwise wrote:
>> [...]
>>    Bit
>
> After thinking about what @bitwise said, I was actually going 
> to post back similar code.
>
> The code in the github issue is problematic, but it's a far cry 
> from how such errors are usually introduced in C++. Normally 
> it's because another thread has a reference to the now dangling 
> pointer, or calling a function with the slice means it gets 
> escaped somewhere.

I think that in C++, iterator validity is a hard concept to 
overlook. I would bet that even relatively new C++ programmers 
are familiar with the idea. I think most intro C++ classes teach 
this type of thing relatively early on. This awareness 
prevents/mitigates a lot of potential problems, resulting in the 
issue being underrepresented in peoples negative views of C++ (or 
so it would seem, I've seen no actual data on this). In any case, 
it would be great if callers could just ignore the issue 
completely.

> void oops(ref Vector!int vec, int[] slice);

Yeah, I remember Walter's post about how this will mess with 
ref-counted objects as well. IIRC, the solution was compiler 
support double-incrementing the ref-count when it finds this 
case. I wonder if this is actually necessary though, because in 
C++, shared_ptr has the aliasing constructor, and with D's 
templates, something like RefCounted could be modified to expose 
the members of it's contained type as properties that worked like 
shared_ptr's aliasing constructor, wrapping the returned field 
value in a ref-counted object that shares the ref-count of its 
parent object. If this was done, the member exposing that slice 
would do the extra increment without compiler support.

> Either way, thanks for pointing out the possible issue. I'm 
> going to have to think long and hard about whether it's 
> possible to fix it with the language we have now.

Thanks for exploring this issue with me. I agree its tough to 
build a proper container right now, but I do believe I have more 
options than when I started.

I just found this as well, which I'm pretty excited about:
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1014.md

The version of std::vector from Visual Studio makes use of this 
for iterator validation in debug mode. The vector heap-allocates 
a "proxy" object and stores it's own pointer in it. When the 
vector moves (and it's move ctor is called), it updates the 
pointer in the proxy object. It also gives this proxy out to 
iterators so they can track the original vector. Without any type 
of move callback in D, such an implementation would have been 
impossible, so this is awesome news.


More information about the Digitalmars-d mailing list