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