On Monday, 12 October 2015 at 08:49:24 UTC, Jonathan M Davis wrote:
> On Monday, 12 October 2015 at 08:21:24 UTC, Kagamin wrote:
>> On Thursday, 8 October 2015 at 14:13:30 UTC, Jonathan M Davis wrote:
>>> I've programmed extensively in C++ with smart pointers, and in my experience, circular references are rarely a problem. There are some cases where it's obvious that you have one (e.g. where one object owns another and they need to talk to each other), in which case you either use a normal pointer or a weak reference, depending on which makes more sense. And in the cases that you don't catch, you find them in testing, figure out what should be a weak reference to get rid of the circular dependency, you fix it, and you move on. It really isn't a big deal in general, though I suppose that there could be certain ways of designing programs where it would be more problematic.
>>
>> That's all understandable. What's not understandable is when one insists that a necessity to figure out ownership for every non-resource object in C++ is superior to D.
>
> If you don't want to care about ownership, then use a GC. The only other memory management model that I can think of where you don't have to care about ownership is when everything is a value type on the stack, so there's nothing to own.
>
> There are pros and cons to using a GC, and there are pros and cons to use reference counting everything on the heap. I don't think that either is objectively superior. It all depends on what you're trying to do and what your requirements are.
>
> - Jonathan M Davis

Well technically, there is still ownership: the GC owns everything. But yeah, you don't need to care about for this very reason.

On Monday, 12 October 2015 at 08:21:24 UTC, Kagamin wrote:
> That's all understandable. What's not understandable is when one insists that a necessity to figure out ownership for every non-resource object in C++ is superior to D.

You don't have to, you can use a region allocator.

On Monday, 12 October 2015 at 08:59:55 UTC, deadalnix wrote:
> Well technically, there is still ownership: the GC owns everything. But yeah, you don't need to care about for this very reason.

Only if you have finalizers. Without finalization it is better to think of the GC as a memory optimization that is transparent to the semantics of the program. It basically recycles identities (addresses) allowing us to "pretend" that they are unique by checking all relevant used identities (pointers). In some distributed contexts recycling identities is not worth the trouble... so you just use a big space (e.g. 64 bits)...

But in most settings you get practically the same result with a region allocator at the entry point of an event loop as with a GC. It uses more memory than explicit management, but so does GC.

The GC is usually more robust, but a GC can tank too if we forget to null out pointers (by running out of memory...).

Tradeoffs across the board.

On Monday, 12 October 2015 at 08:00:59 UTC, Jonathan M Davis wrote:
> You can stick value types on the heap and pass around pointers or references to them, but then you're not dealing with polymorphism.

As soon as you choose to use value types you already get the first problem: pointers or references. Neither of these two work and there are two more options here, I've gone with the fourth.

> My point was entirely about polymorphism not applying to anything without using a pointer or reference.

My point was about structs not applying to anything that needs reference semantics (in current state of D). Your suggestion to do otherwise is a kludge and doesn't work well.

On Tuesday, 6 October 2015 at 20:43:42 UTC, bitwise wrote:
> For the THIRD time, I'll post my example:
>
> class Texture { }
> class Texture2D : Texture {
>     this() { /* load texture... */ }
>     ~this { /* free texture */ }     // OOPS, when, if ever, will this be called?
> }
>
> Now, does this really seem like a realistic use case to you?
>
> using(Texture tex = new Texture2D) {
>     // ...
> }
>

It does, entirely. I usually translate it to D this way:

{
    Texture tex = new Texture2D;
    scope(exit) tex.destroy;
    // ...
}

Of course, nothing protects you from passing the reference outside the scope and having a dangling ref after the scope ends, so it's by no means safe, but the destruction is deterministic.

On Monday, 12 October 2015 at 09:01:54 UTC, Ola Fosheim Grøstad wrote:
> You don't have to, you can use a region allocator.

I wrote one and use it in my code for everything. I guess the conclusion is that C++ programmers used to C++ way of resource management and don't want to change their habits. But if D is going to support all C++ idioms... hmm...

On Wednesday, 14 October 2015 at 16:12:59 UTC, Kagamin wrote:
> On Monday, 12 October 2015 at 09:01:54 UTC, Ola Fosheim Grøstad wrote:
>> You don't have to, you can use a region allocator.
>
> I wrote one and use it in my code for everything. I guess the conclusion is that C++ programmers used to C++ way of resource management and don't want to change their habits. But if D is going to support all C++ idioms... hmm...

Yeah, well, not even sure what C++ idioms are? The ones that a sold on slides at CppCon, or the ones we find at Github? :-)

The tricky bit is that D going to support interfacing with C++, that kind of locks D to C++'s memory model...

On Wednesday, 14 October 2015 at 16:24:25 UTC, Ola Fosheim Grøstad wrote:
> Yeah, well, not even sure what C++ idioms are? The ones that a sold on slides at CppCon, or the ones we find at Github? :-)

Off the top of my head:
1) polymorphic value types
2) references in fields
3) value type strings and stl containers
4) multiple inheritance

BTW how one does polymorphism and introspection with shared_ptr in C++?

On Friday, 9 October 2015 at 05:21:13 UTC, Andrei Alexandrescu wrote:
> On 10/9/15 4:47 AM, bitwise wrote:
>> On Thursday, 8 October 2015 at 17:21:52 UTC, Andrei Alexandrescu wrote:
>>> On 10/8/15 5:59 PM, bitwise wrote:
>>>> With DIP74, the ref counting is hard coded into the type itself.
>>>
>>> I think that should be the case. -- Andrei
>>
>> Can you comment on the status of the next vision document?
>
> The H1 vision document has had some effectiveness albeit limited. I'll discuss outlook with Walter during our road trip, and plan to update it when we get back. -- Andrei

Any news on this?

     Bit

On 10/18/15 1:57 AM, bitwise wrote:
> On Friday, 9 October 2015 at 05:21:13 UTC, Andrei Alexandrescu wrote:
>> On 10/9/15 4:47 AM, bitwise wrote:
>>> On Thursday, 8 October 2015 at 17:21:52 UTC, Andrei Alexandrescu wrote:
>>>> On 10/8/15 5:59 PM, bitwise wrote:
>>>>> With DIP74, the ref counting is hard coded into the type itself.
>>>>
>>>> I think that should be the case. -- Andrei
>>>
>>> Can you comment on the status of the next vision document?
>>
>> The H1 vision document has had some effectiveness albeit limited. I'll
>> discuss outlook with Walter during our road trip, and plan to update
>> it when we get back. -- Andrei
>
> Any news on this?
>
>       Bit

Still on the road! Thanks for the prod. -- Andrei