Allocatoin policy in Phobos - Was: Vote for std.process

Regan Heath regan at netmail.co.nz
Fri Apr 12 08:14:07 PDT 2013


On Fri, 12 Apr 2013 15:56:54 +0100, Dmitry Olshansky  
<dmitry.olsh at gmail.com> wrote:

> 12-Apr-2013 18:40, Manu пишет:
>> On 13 April 2013 00:18, Dmitry Olshansky <dmitry.olsh at gmail.com
>> <mailto:dmitry.olsh at gmail.com>> wrote:
>>         Believe it or not, I'm not actually a fan of over-complexity.
>>         And I'm
>>         focusing here on totally unnecessary allocations.
>>         Isn't using the stack where applicable just a whole low easier?
>>         That's
>>         what it's there for.
>>
>>
>>     'cause nobody can tell you how big it is. This knowledge is only
>>     available to end user and there is still no easy way to "tell" that
>>     to the library. The end result is utterly useless as library can't
>>     reliably use stack space.
>>
>>
>> Filenames, strings, etc have a fairly predictable size. Allocate
>> slightly above that, and fallback to the heap upon overflow.
>> I think it's safe to assume the stack is 'big enough' if you apply some
>> common sense.
>
> Up to 32K on WinNT. Hence the 32K reference.

Sure, but that upper limit is practically never reached.  I work for a  
backup/archive company and we have to allow for paths of 32K length but I  
can fairly confidently tell you that 80-90% are less than 1000 characters  
long.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/


More information about the Digitalmars-d mailing list