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.
You're being paranoid, or sensationalising the effect of simple
optimisation.
Strong words...
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?
Can you describe the 'costs'?
See my previous posts in today's discussions.
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).
