<div dir="ltr">On 13 April 2013 00:19, Vladimir Panteleev <span dir="ltr"><<a href="mailto:vladimir@thecybershadow.net" target="_blank">vladimir@thecybershadow.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Friday, 12 April 2013 at 13:39:38 UTC, Manu wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If allocating a string on the stack makes it buggy, then there is something<br>
really wrong. It should be no less convenient if appropriate helpers are<br>
available.<br>
</blockquote>
<br></div>
Please see my reply to your other post.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
With consideration to the string[string] argument, surely instances like<br>
that can be reconsidered? How is string[] going to produce more bugs than<br>
string[string]?<br>
</blockquote>
<br></div>
env ~= "FOO=BAR";<br>
<br>
This will probably not do what you want if there was already a line starting with "FOO=" in env.<br>
<br>
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.</blockquote>
<div><br></div><div style>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.</div><div style><br></div><div style>
I wouldn't use env ~= "FOO=BAR";</div><div style>I would use env ~= EnvVar("FOO", "BAR");</div><div style>Or whatever key/value pair structure you like.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
You're being paranoid, or sensationalising the effect of simple<br>
optimisation.<br>
</blockquote>
<br></div>
Strong words...</blockquote><div><br></div><div style>Well it seemed appropriate. I can't understand what's so wildly complex that it would make code utterly unmaintainable, and error prone.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
And<br>
again, speed is not my concern here, it's inconsiderate the allocation<br>
policy.<br>
</blockquote>
<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'm interested in eliminating allocations. It's just another function that<br>
can't be called in a no-gc area. If it used the stack for its temporaries,<br>
no problem.<br>
</blockquote>
<br></div>
Why allocations, specifically, if not for the performance costs of allocation and garbage collection?</blockquote><div><br></div><div style>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.</div>
<div style>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.</div><div style>Reducing allocations is always better where possible.<br>
</div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">As much is convenient without causing you to start obscuring your code?<br>
</blockquote></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
That's my personal rule.<br>
But I make it a habit to consider efficiency when designing code, I never<br>
retrofit it. I tend to choose designs that are both simple and efficient at<br>
the start.<br>
</blockquote>
<br></div>
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).<br>

</blockquote></div></div><br><div style>It starts as soon as the majority agree it's important enough to enforce.</div><div style>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.</div>
</div>