V Fri, 12 Sep 2014 08:47:55 +0200
Jacob Carlborg via Digitalmars-d <digitalmars-d@puremagic.com> napsáno:

> On 11/09/14 21:02, eles wrote:
> 
> > Could you provide one or two short but illustrative examples in Tango and Phobos showing the howto and the why not in Phobos?
> 
> Tango:
> 
> import tango.text.Unicode;
> 
> void foo ()
> {
>      char[3] result; // pre-allocate buffer on the stack
>      auto b = "foo".toUpper(result);
> }
> 
> Phobos:
> 
> import std.uni;
> 
> void foo ()
> {
>      auto b = "foo".toUpper(); // no way to use a pre-allocated buffer
> }
> 
> > Will Andrei's allocators improve that with some rewrite of Phobos?
> 
> Yes, they could.
> 

toUpperInPlace could help little, but still not perfect

On Thursday, 11 September 2014 at 19:56:17 UTC, Paulo Pinto wrote:
> Am 11.09.2014 20:32, schrieb Daniel Alves:

> It is incredible how Objective-C's ARC became a symbol for reference counting, instead of the living proof of Apple's failure to produce
> a working GC for Objective-C that didn't crash every couple of seconds.

I think I fail to grasp something here. For me, ARC is something that is managed at runtime: you have a counter on a chunk of memory and you increase it with each new reference towards that memory, then you decrement it when memory is released. In the end, when the counter reaches 0, you drop the chunk.

OTOH, code analysis and automatically inserting free/delete where the programmers would/should have done it is not really that. Is a compile-time approach and not different of manual memory management.

Which one is, in the end, the approach took by Apple, and which one is the "true" ARC?...

On Thursday, 11 September 2014 at 20:11:45 UTC, deadalnix wrote:
> On Thursday, 11 September 2014 at 12:38:54 UTC, Andrey Lifanov
> wrote:

>   - Other memory management technique require bookkeeping. In a
> multicore environment, that mean expensive synchronization.

It is also true that when you start to really optimize the GC (precise, concurrent etc.), its complexity is not lesser than the complexity of that bookkeeping.

I think there is place for both, just allow taking one or the other path when the programmer decides it is the way to go.

Remember, what people like in C is inclusively the "shoot the foot" simplicity and availability. If you want it, you do it.

On Friday, 12 September 2014 at 06:47:56 UTC, Jacob Carlborg wrote:
> On 11/09/14 21:02, eles wrote:
>

Thank you. Basically, it is about a different interface of the functions, something like the difference between "new" and "placement new".

This could be added to Phobos too, through those allocators. I was afraid the issue is deeper.

On Friday, 12 September 2014 at 07:49:59 UTC, eles wrote:
> On Thursday, 11 September 2014 at 20:11:45 UTC, deadalnix wrote:
> >  - Other memory management technique require bookkeeping. In a
> > multicore environment, that mean expensive synchronization.
>
> It is also true that when you start to really optimize the GC (precise, concurrent etc.), its complexity is not lesser than the complexity of that bookkeeping.
>
May be, but this complexity is hidden, the programmer has not to take care about it - and the extra cost for synchronization is still speared. So I think D is well of if it provides GC and manual memory management. Additional supporting ARC is superflouos.

> programmers who really have this stuff down... how much of your code and your mental energy with C++ is spent on memory ownership rules?  Is it really a productive use of your time?  Does the program materially benefit from the design required to make it safe, correct, and self-documenting with respect to memory ownership and data lifetime?  Are smart pointers really that pleasant to work with?

 It just depends on the codebase.

 Yes old C++ codebases are terrible for multithreaded code. It would be nightmare to make sense of it and guarantee it doesn't have bugs.

 But using modern C++11/14 + TBB it really isn't hard at all. It is fairly trivial to scale to N cores using a task based approach. Smart pointers are rarely used, most C++ stuff is done by value.
  When dynamic lifetimes are required, again it is rarely based on "shared_ptr", far more often it is "unique_ptr" so there is no atomic ref counting that the GC crowd loves to cry about.
 C++ also has all kinds of parallel loop constructs(via TBB,  OpenMP, or MS Concurrency RT  etc). Again trivial to use.
  TBB has many parallel containers(priority queue, vector, unordered_map).


 For instance, I work on a game engine, almost everything is either by value or unique.

The only stuff that is "shared" and thus is requires ref counting are external assets(shaders,models,sounds, some gpu resources). These objects are also closed, and thus incapable of circular references. Their ref counts are also rarely modified, at most I'd expect just a few of them to dec/inc per frame as objects are added/removed.

On Friday, 12 September 2014 at 08:27:55 UTC, Dominikus Dittes Scherkl wrote:
> On Friday, 12 September 2014 at 07:49:59 UTC, eles wrote:
>> On Thursday, 11 September 2014 at 20:11:45 UTC, deadalnix wrote:

> May be, but this complexity is hidden

The old question: at what cost?
There is always a trade-off.
I do not defend one more point of view than the other, but I am awarethat sometimes you simply need manual control.

On Fri, 12 Sep 2014 07:49:57 +0000
eles via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Remember, what people like in C is inclusively the "shoot the foot" simplicity and availability. If you want it, you do it.
but you can shoot yourself in the foot in D! you can run around in circles shooting everything that moves (including yourself). even dead bodies, doors, walls, paintings, furniture and your neighbours' nasty dog.

On 12/09/14 08:59, Daniel Kozak via Digitalmars-d wrote:

> toUpperInPlace could help little, but still not perfect

Converting text to uppercase doesn't work in-place in some cases. For example the German double S will take two letters in uppercase form.

-- 
/Jacob Carlborg

On 12/09/14 09:58, eles wrote:
> On Friday, 12 September 2014 at 06:47:56 UTC, Jacob Carlborg wrote:
>> On 11/09/14 21:02, eles wrote:
>>
>
> Thank you. Basically, it is about a different interface of the
> functions, something like the difference between "new" and "placement new".
>
> This could be added to Phobos too, through those allocators. I was
> afraid the issue is deeper.

Yes, or output ranges. I think output ranges already has been added in some places.

-- 
/Jacob Carlborg