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