On Monday, 30 December 2013 at 18:32:05 UTC, Ola Fosheim Grøstad wrote:
> Ok. :) as long as I don't have to pass the allocator around,mwhich is tedious.

See this thread for some perspective/info: http://forum.dlang.org/thread/l4btsk$5u8$1@digitalmars.com

On 12/30/2013 9:36 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> I hoped for solution that is a bit more transparent than creating my own new
> syntax though, a solution which makes replacing allocators across projects less
> work. *shrug*

Having overloaded global operator new in C++ myself across many projects, I eventually concluded that feature is a bug.

On Monday, 30 December 2013 at 18:39:08 UTC, John Colvin wrote:
> See this thread for some perspective/info: http://forum.dlang.org/thread/l4btsk$5u8$1@digitalmars.com

Thanks! That looks promising!

Looks like a stack of allocators for new. If it is possible to use them explicitly too, then most of my concerns are covered. I think?

On Monday, 30 December 2013 at 19:12:16 UTC, Walter Bright wrote::
> Having overloaded global operator new in C++ myself across many projects, I eventually concluded that feature is a bug.

I guess it can go wrong if you end up using the wrong pool in different parts of your code when making calls across compilation units (or inlined functions), but if you stay within an encapsulated framework I would think it is safe?

On 12/30/13 11:12 AM, Walter Bright wrote:
> On 12/30/2013 9:36 AM, "Ola Fosheim Grøstad"
> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> I hoped for solution that is a bit more transparent than creating my
>> own new
>> syntax though, a solution which makes replacing allocators across
>> projects less
>> work. *shrug*
>
> Having overloaded global operator new in C++ myself across many
> projects, I eventually concluded that feature is a bug.

Agreed. Class-level, too.

Andrei

Broad statements with no explanation are not very enlightening.

On Monday, 30 December 2013 at 12:20:36 UTC, bearophile wrote:
> But the Oracle JVM has a GC (more than one) way better then the current D one :-)

Of course. But Java requires a world class GC and state-of-the-art escape analysis to achieve excellent performance. These would be nice to have in D, especially the super duper GC, but D will be fine IMO once it has a decent precise GC since it won't be pounding the GC as hard as Java would.

I hope that after the ICE removal release coming up soon that there will be a 'get the precise GC working' release.

As far as escape analysis goes, I rather wish D had stolen some ideas from Ada (>95) like 'aliased' and restrictions on address-taking and pointers, but I suppose that will have to wait for D2++.

-- Brian

On 12/30/2013 11:39 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Monday, 30 December 2013 at 19:12:16 UTC, Walter Bright wrote::
>> Having overloaded global operator new in C++ myself across many projects, I
>> eventually concluded that feature is a bug.
>
> I guess it can go wrong if you end up using the wrong pool in different parts of
> your code when making calls across compilation units (or inlined functions), but
> if you stay within an encapsulated framework I would think it is safe?

It causes problems when linking in code developed elsewhere that makes assumptions about new's behavior.

Even if you wrote all the code, it suffers from the usual problems of using global variables to set global state that various parts of the code rely on, i.e. encapsulation failure.

This is why D does not support the notion.

On Monday, 30 December 2013 at 21:21:06 UTC, Walter Bright wrote:
> It causes problems when linking in code developed elsewhere that makes assumptions about new's behavior.

Yes, if you don't do new/delete pairs under the same circumstances you risk having problems.

> Even if you wrote all the code, it suffers from the usual problems of using global variables to set global state that various parts of the code rely on, i.e. encapsulation failure.

But isn't this exactly what the proposed allocation system linked above enables?

On 12/30/2013 1:39 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Monday, 30 December 2013 at 21:21:06 UTC, Walter Bright wrote:
>> It causes problems when linking in code developed elsewhere that makes
>> assumptions about new's behavior.
>
> Yes, if you don't do new/delete pairs under the same circumstances you risk
> having problems.

And people don't do that with C++. That's the whole problem with GLOBAL state.


>> Even if you wrote all the code, it suffers from the usual problems of using
>> global variables to set global state that various parts of the code rely on,
>> i.e. encapsulation failure.
>
> But isn't this exactly what the proposed allocation system linked above enables?

??