"Dave" <Dave_member@pathlink.com> wrote in message news:ch033f$2u7u$1@digitaldaemon.com...
> UTF-16 used everywhere is probably one reason why heavy-use Java server
apps.
> have the reputation as 'memory-thrashers'. And those runtimes have the
benefit
> of many man-years of development, use-cases and experimentation behind
them.

Many of Java's problems have gradually declined over time due to massive research and development efforts by a lot of very, very smart people. For example, Andy King has just pointed me to some research done by several people that focussed on improving some minor aspects of the Java garbage collector. D doesn't have a billion dollar budget <g>, and simply cannot afford to have problems that need such budgets to find solutions for.

> IMO, D really needs to be a general performance winner in order to get a toe-hold in the current market.

Right. And if D acquires an early reputation for being 'slow', it will never have a chance. Currently, D is *faster* than C++ on string benchmarks (see www.digitalmars.com/d/cppstrings.html), and it must be that way, as that seriously blunts criticisms aimed at D for the way it does strings relative to C++.

"Walter" <newshound@digitalmars.com> wrote in message news:ch0ce4$11t$1@digitaldaemon.com...
>
> "Juanjo Álvarez" <juanjuxNO@SPAMyahoo.es> wrote in message news:ch0ajb$4d$1@digitaldaemon.com...
> > Walter wrote:
> > >> Seriously, is performance a concern for D?  If it truly is, this
should
> > >> be able to be turned off, if I take ownership of the potential consequences, no?
> > > You can allocate them with std.c.stdlib.malloc() or
> std.c.stdlib.alloca(),
> > > neither of which will do the initialization. Furthermore, std.c.stdlib.alloca(n), where n is a constant, is handled as a special optimization case, and will generate storage as part of the stack
frame
> > > setup (so it's zero cost).
> > And will they be garbage-collected? (just asking, I don't know.)
>
> malloc()? No, that will need an explicit call to free().

But this would be a good way to get back to good old memory leaks
from forgetting to free something. This is something that a high level
language
like D should try to help with. Isn't there a way to extend the syntax
to enable us to allocate uninitialised arrays when someone explicitly
wants to do that?

> alloca()? No, that gets deallocated anyway when the function exits
>
> > Anyway it's
> > an ugly interface to do it, maybe as has been suggested more standard
> > allocators could be included for this case.
>
> You can also overload operators new and delete on a per-class basis, and provide a custom allocator.

But not for arrays. This would mean too much wraping.

In article <ch0ce4$11t$1@digitaldaemon.com>, Walter says...

>> And will they be garbage-collected? (just asking, I don't know.)
>
>malloc()? No, that will need an explicit call to free().
>alloca()? No, that gets deallocated anyway when the function exits

..but is forbidden from having a destructor (even if you use alloca() via a
custom allocator) because you can't have destructable objects on the stack.


>> Anyway it's
>> an ugly interface to do it, maybe as has been suggested more standard
>> allocators could be included for this case.
>
>You can also overload operators new and delete on a per-class basis, and provide a custom allocator.

..which of course will /also/ not be garbage collected. (I've been down this
road before).

Arcane Jill

In article <ch1ulm$ori$1@digitaldaemon.com>, Ivan Senji says...
>
>"Walter" <newshound@digitalmars.com> wrote in message news:ch0ce4$11t$1@digitaldaemon.com...
>
>> malloc()? No, that will need an explicit call to free().
>
>But this would be a good way to get back to good old memory leaks
>from forgetting to free something. This is something that a high level
>language
>like D should try to help with. Isn't there a way to extend the syntax
>to enable us to allocate uninitialised arrays when someone explicitly
>wants to do that?

How about a smart pointer?  I admit that the syntax wouldn't be quite as nice as in C++, but the basic implementation should be the same.


Sean

In article <ch22nn$qtf$1@digitaldaemon.com>, Arcane Jill says...
>
>In article <ch0ce4$11t$1@digitaldaemon.com>, Walter says...
>
>>> And will they be garbage-collected? (just asking, I don't know.)
>>
>>malloc()? No, that will need an explicit call to free().
>>alloca()? No, that gets deallocated anyway when the function exits
>
>..but is forbidden from having a destructor (even if you use alloca() via a
>custom allocator) because you can't have destructable objects on the stack.

You can't?  Why not?

>>> Anyway it's
>>> an ugly interface to do it, maybe as has been suggested more standard
>>> allocators could be included for this case.
>>
>>You can also overload operators new and delete on a per-class basis, and provide a custom allocator.
>
>..which of course will /also/ not be garbage collected. (I've been down this
>road before).

I'm not sure if it would work, but could you use gc.malloc to allocate heap memory in operator new and then not provide an operator delete?


Sean

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:ch22nn$qtf$1@digitaldaemon.com...
> In article <ch0ce4$11t$1@digitaldaemon.com>, Walter says...
>
> >> And will they be garbage-collected? (just asking, I don't know.)
> >
> >malloc()? No, that will need an explicit call to free().
> >alloca()? No, that gets deallocated anyway when the function exits
>
> ..but is forbidden from having a destructor (even if you use alloca() via
a
> custom allocator) because you can't have destructable objects on the
stack.

If you make it an auto class, you can.

In article <ch2a1j$uqi$1@digitaldaemon.com>, Sean Kelly says...

>>> malloc()? No, that will need an explicit call to free().
>>
>>But this would be a good way to get back to good old memory leaks
>>from forgetting to free something. This is something that a high level
>>language
>>like D should try to help with.
>
>How about a smart pointer?  I admit that the syntax wouldn't be quite as nice as in C++, but the basic implementation should be the same.

How about just using a buffer class that clears up it's mess when collected? Seems to me like a simple solution that would cover most uses for uninitialized buffers.

I have written an example here: http://folk.uio.no/mortennk/d/array/membuffer.d

and used it here: http://folk.uio.no/mortennk/d/array/uninitarray.d

Nick