On 13 April 2013 00:19, Vladimir Panteleev <vladi...@thecybershadow.net>wrote:
> On Friday, 12 April 2013 at 13:39:38 UTC, Manu wrote:
>
>> If allocating a string on the stack makes it buggy, then there is
>> something
>> really wrong. It should be no less convenient if appropriate helpers are
>> available.
>>
>
> Please see my reply to your other post.
>
>
> With consideration to the string[string] argument, surely instances like
>> that can be reconsidered? How is string[] going to produce more bugs than
>> string[string]?
>>
>
> env ~= "FOO=BAR";
>
> This will probably not do what you want if there was already a line
> starting with "FOO=" in env.
>
> An array of strings is a less direct representation of the environment
> than a string map. Certain common operations, such as finding the value of
> a variable, or setting / overwriting a variable, become more difficult.
I didn't see any attempt to index the array by key in this case. That's
what an AA is for, and it's not being used here, so it's not a job for an
AA.
I wouldn't use env ~= "FOO=BAR";
I would use env ~= EnvVar("FOO", "BAR");
Or whatever key/value pair structure you like.
You're being paranoid, or sensationalising the effect of simple
>> optimisation.
>>
>
> Strong words...
Well it seemed appropriate. I can't understand what's so wildly complex
that it would make code utterly unmaintainable, and error prone.
And
>> again, speed is not my concern here, it's inconsiderate the allocation
>> policy.
>>
>
> I'm interested in eliminating allocations. It's just another function that
>> can't be called in a no-gc area. If it used the stack for its temporaries,
>> no problem.
>>
>
> Why allocations, specifically, if not for the performance costs of
> allocation and garbage collection?
That's one aspect, but it's also about having control over the allocation
patterns of your program in general. Lots of small allocations fragment the
heap, and they also push the memory barrier.
I couldn't disable the GC and call into phobos functions for very long,
micro-allocations of temporaries not being freed would quickly eat all the
system memory.
Reducing allocations is always better where possible.
As much is convenient without causing you to start obscuring your code?
>>
> That's my personal rule.
>> But I make it a habit to consider efficiency when designing code, I never
>> retrofit it. I tend to choose designs that are both simple and efficient
>> at
>> the start.
>>
>
> OK, so if I understand you correctly: you would like Phobos to adopt a
> policy of avoiding heap allocations whenever possible, and this argument
> applies to std.process not because doing so would result in a tangible
> improvement of its performance or other metric, but for the purpose of
> being consistent across Phobos. Assuming that the language can provide or
> allow implementing suitably safe abstractions for doing so without
> complicating the code much, I think that's a goal worth looking forward,
> and we have been doing so for some time (hence the pending allocator
> design).
>
It starts as soon as the majority agree it's important enough to enforce.
Although I think a tool like: char[len] stackString; would be a
super-useful tool to make this considerably more painless. Some C compilers
support this.
