On Thursday, 17 July 2014 at 17:36:36 UTC, Vic wrote:
> On Thursday, 17 July 2014 at 13:02:22 UTC, Remo wrote:
> <snip>
>> The quality of GC implementation is probably more important.
>>
>
> I disagree, I am a burn victim and don't trust smoke.

Well it appears to be very hard to make proper GC.
So all the hate again GC could be because of suboptimal implementation?
Any way as written before memory is not only one resource that need to be managed. So a language need to offer solution not only for memory management but all other resources.
In C++ this is called RAII and work reasonable well.
Rust looks even more promising for me.

> Ideally it is optional.

Yes for me too.
GC must be optional.
I hope @nogc will allow this for D.

>
> Cheers,
> Vic

 I'm rather fond of RAII, I find that I rarely every need shared semantics.
 I use a custom object model that allows for weak_ptrs to unique_ptrs which I think removes some cases where people might otherwise be inclined to use shared_ptr.

 Shared semantics are so rare in fact I would say I hardly use it at all, I go for weeks of coding without creating a shared type, not because I'm trying to do so, but because it just isn't necessary.

 Which is why GC seems like such a waste, given my experience in C++, where I hardly need shared memory, I see little use for a GC(or even ARC etc), all it will do is decrease program performance, make deterministic destruction impossible, and prevent automatic cleanup of none memory resources.

 Rust seems to have caught on to what C++ has accomplished here.


 Oh, and Unreal? Yes they have a GC type "UObject", I worked on Unreal at one point, my impression was that this originated back with the original Unreal(circa 1998?), likely caused by the popularity of Java at the time. As for the Unreal code base? Pass on that.

On 7/17/14, 3:55 PM, Andrei Alexandrescu wrote:
> On 7/17/14, 11:11 AM, Ary Borenszweig wrote:
>> On 7/17/14, 2:32 PM, Right wrote:
>>>   I hate GC, so there.
>>>
>>>> I see no proof of this. And not everybody hates GCs.
>>>>
>>>> Bye,
>>>> bearophile
>>>
>>
>> Java is everywhere and it has a GC. Go is starting to be everywhere and
>> it has a GC. C# too has a GC, and I think they use it to make games too.
>> I don't think everyone hates GCs. :-)
>
> http://www.stroustrup.com/C++11FAQ.html#gc-abi
>
> Andrei

Sorry, but I don't understand your reply by just reading that link.

On 7/17/14, 12:26 PM, Ary Borenszweig wrote:
> On 7/17/14, 3:55 PM, Andrei Alexandrescu wrote:
>> On 7/17/14, 11:11 AM, Ary Borenszweig wrote:
>>> On 7/17/14, 2:32 PM, Right wrote:
>>>>   I hate GC, so there.
>>>>
>>>>> I see no proof of this. And not everybody hates GCs.
>>>>>
>>>>> Bye,
>>>>> bearophile
>>>>
>>>
>>> Java is everywhere and it has a GC. Go is starting to be everywhere and
>>> it has a GC. C# too has a GC, and I think they use it to make games too.
>>> I don't think everyone hates GCs. :-)
>>
>> http://www.stroustrup.com/C++11FAQ.html#gc-abi
>>
>> Andrei
>
> Sorry, but I don't understand your reply by just reading that link.

There's work on adding optional GC to C++ starting with C++11. -- Andrei

On Thursday, 17 July 2014 at 19:14:06 UTC, Right wrote:
>  I'm rather fond of RAII, I find that I rarely every need shared semantics.
>  I use a custom object model that allows for weak_ptrs to unique_ptrs which I think removes some cases where people might otherwise be inclined to use shared_ptr.
>
>  Shared semantics are so rare in fact I would say I hardly use it at all, I go for weeks of coding without creating a shared type, not because I'm trying to do so, but because it just isn't necessary.
>
>  Which is why GC seems like such a waste, given my experience in C++, where I hardly need shared memory, I see little use for a GC(or even ARC etc), all it will do is decrease program performance, make deterministic destruction impossible, and prevent automatic cleanup of none memory resources.
>
>  Rust seems to have caught on to what C++ has accomplished here.
>
>
>  Oh, and Unreal? Yes they have a GC type "UObject", I worked on Unreal at one point, my impression was that this originated back with the original Unreal(circa 1998?), likely caused by the popularity of Java at the time. As for the Unreal code base? Pass on that.

UEngine has been rewritten from scratch.
UnrealScript doesn't even exist anymore.
It is the new UEngine that depends on GC, and we're talking C++, not UnrealScript here (again, UnrealScript is gone).

On Thursday, 17 July 2014 at 12:37:10 UTC, w0rp wrote:
> The key to making D's GC acceptable lies in two factors I believe.
>
> 1. Improve the implementation enough so that you will only be impacted by GC in extermely low memory or real time environments.
> 2. Defer allocation more and more by using ranges and algorithms more, and trust that compiler optimisations will make these fast.
>
> The big, big offender I believe for extra allocations is functions which return objects, rather than functions which write to output ranges. The single most common occurence of this is something like this is toString. Instead of writing this...
>
> string toString() {
>     // Allocations the user of the library has no control over.
>     return foo.toString() ~ bar.toString() ~ " something else";
> }
>
> I believe you should always, always instead write this.
>
> // I left out the part with different character types.
> void writeString(OutputRange)(OutputRange outputRange)
> if (isOutputRange!(OutputRange, char)) {
>     // Allocations controlle by the user of the library,
>     // this template could appear in a @nogc function.
>     foo.writeString(outputRange);
>     bar.writeString(outputRange);
>
>     "something else".copy(outputRange);
> }
>

I agreed with this for awhile but following the conversation here <https://github.com/D-Programming-Language/phobos/pull/2149> I'm more inclined to think we should be adding lazy versions of functions where possible rather than versions with OutputRange parameters. It's more flexible that way and can result in even fewer allocations than even OutputRange parameters would have (i.e. you can have chains of lazy operations and only allocate on the final step, or not at all in some cases).

Laziness isn't appropriate or possible everywhere but it's much easier to go from lazy to eager than the other way around.

> [...]

On Thursday, 17 July 2014 at 22:06:01 UTC, Brad Anderson wrote:
> I agreed with this for awhile but following the conversation here <https://github.com/D-Programming-Language/phobos/pull/2149> I'm more inclined to think we should be adding lazy versions of functions where possible rather than versions with OutputRange parameters. It's more flexible that way and can result in even fewer allocations than even OutputRange parameters would have (i.e. you can have chains of lazy operations and only allocate on the final step, or not at all in some cases).
>
> Laziness isn't appropriate or possible everywhere but it's much easier to go from lazy to eager than the other way around.
>
>> [...]

This is not comparable. Lazy input range based solutions do not make it possible to change allocation strategy, they simply defer the allocation point. Ideally both are needed.

On Thursday, 17 July 2014 at 22:16:10 UTC, Dicebot wrote:
> On Thursday, 17 July 2014 at 22:06:01 UTC, Brad Anderson wrote:
>> I agreed with this for awhile but following the conversation here <https://github.com/D-Programming-Language/phobos/pull/2149> I'm more inclined to think we should be adding lazy versions of functions where possible rather than versions with OutputRange parameters. It's more flexible that way and can result in even fewer allocations than even OutputRange parameters would have (i.e. you can have chains of lazy operations and only allocate on the final step, or not at all in some cases).
>>
>> Laziness isn't appropriate or possible everywhere but it's much easier to go from lazy to eager than the other way around.
>>
>>> [...]
>
> This is not comparable. Lazy input range based solutions do not make it possible to change allocation strategy, they simply defer the allocation point. Ideally both are needed.

Well the idea is that you then copy into an output range with whatever allocation strategy you want at the end. There is quite a bit of overlap I think. Not complete overlap and OutputRange accepting functions will still be needed but I think we should prefer the lazy approach where possible.

On Thursday, 17 July 2014 at 22:21:54 UTC, Brad Anderson wrote:
> Well the idea is that you then copy into an output range with whatever allocation strategy you want at the end. There is quite a bit of overlap I think. Not complete overlap and OutputRange accepting functions will still be needed but I think we should prefer the lazy approach where possible.

It is not always possible - sometimes resulting range element must be already "cooked" object. I do agree it is a powerful default when feasible though. At the same time simple output range overloads is much faster to add.

 UE4 wasn't really rewritten from scratch, was more like, take UE3,  rewrite various parts and add new features, keep doing that for a few years--

 Code style isn't modern C++.
No lambda, r-value refs, unique types, algorithms(everyone just bangs out for loops), task implementation is laughable, code mostly single threaded.

Basically verbosity hell.

 The dependency on GC is the same as previous versions, they did not fundamentally change the object model in UE4. I think they did work on the GC, so perhaps it is faster /shrug. They only use the GC for certain objects(deriving UObject).

 Powerful engine? Yes for sure. If I needed to make a graphically AAA game ASAP I'd use UE4. Doesn't change the fact that the code is nothing impressive.

The Blueprint system technically compiles down to UnrealScript bytecode-- but yes Unrealscript is dead, thankfully.


> UEngine has been rewritten from scratch.
> UnrealScript doesn't even exist anymore.
> It is the new UEngine that depends on GC, and we're talking C++, not UnrealScript here (again, UnrealScript is gone).