I'm currently trying to understand if it's possible to add more
move-optimizations in parameter passing for those parameters
whole symbols aren't used after the call or for `const` or
`immutable` parameters to `@safe pure` (strictly pure) functions.
This similar to function cal
On Mon, 08 Nov 2010 14:19:47 -0500, Pillsy wrote:
Steven Schveighoffer Wrote:
On Mon, 08 Nov 2010 13:46:52 -0500, Pillsy
wrote:
> Besides, isn't catenating or appending in place impossible with D's
> (immutable) strings anyway?
This is a misconception, a string is not immutable, the da
Pillsy Wrote:
[...]
> So, wait, if I have a program like this:
> void appendSailor (string s) {
>s ~= "Sailor";
> }
> void main () {
>auto s = "Hello World!";
>
>appendSailor(s[0 .. 6]);
>
>writefln(s);
> }
> I should expect to get "Hello Sailor" as output? Or is it just tha
Steven Schveighoffer Wrote:
> On Mon, 08 Nov 2010 13:46:52 -0500, Pillsy
> wrote:
> > Besides, isn't catenating or appending in place impossible with D's
> > (immutable) strings anyway?
> This is a misconception, a string is not immutable, the data it points
> to is immutable. You can appe
On Monday, November 08, 2010 10:46:52 Pillsy wrote:
> Jonathan M Davis wrote:
> > On Monday, November 08, 2010 08:43:20 Pillsy wrote:
> > > The length property of an array shouldn't be directly mutable,
> > > and you shouldn't be able to append onto the end of a dynamic
> > > array, because it can
On Mon, 08 Nov 2010 13:46:52 -0500, Pillsy wrote:
Besides, isn't catenating or appending in place impossible with D's
(immutable) strings anyway?
This is a misconception, a string is not immutable, the data it points to
is immutable. You can append to a string just like a mutable array.
Jonathan M Davis wrote:
> On Monday, November 08, 2010 08:43:20 Pillsy wrote:
> > The length property of an array shouldn't be directly mutable,
> > and you shouldn't be able to append onto the end of a dynamic
> > array, because it can cause some surprising behavior and adds a
> > lot of cruft
On Monday, November 08, 2010 08:43:20 Pillsy wrote:
> Jonathan M Davis Wrote:
> [...]
>
> > So, if you alter the elements of that array, it alters the elements of
> > the array that was passed in. However, if you alter the arrays size,
> > causing it to have to re-allocate memory, then that array
Jonathan M Davis Wrote:
[...]
> So, if you alter the elements of that array, it alters the elements of
> the array that was passed in. However, if you alter the arrays size,
> causing it to have to re-allocate memory, then that array is going to
> be pointing to a different block of memory, and
On Monday 08 November 2010 00:03:55 spir wrote:
> On Mon, 8 Nov 2010 18:13:54 +1000
>
> "Daniel Murphy" wrote:
> > "spir" wrote in message
> > news:mailman.157.1289146124.21107.digitalmar...@puremagic.com...
> > I'd like to know, aside user-side semantics, whether the compiler uses
> > the "in"
On Mon, 8 Nov 2010 18:13:54 +1000
"Daniel Murphy" wrote:
> "spir" wrote in message
> news:mailman.157.1289146124.21107.digitalmar...@puremagic.com...
> I'd like to know, aside user-side semantics, whether the compiler uses the
> "in" qualifier for efficiency (pass arrays & structs by ref under
"spir" wrote in message
news:mailman.157.1289146124.21107.digitalmar...@puremagic.com...
I'd like to know, aside user-side semantics, whether the compiler uses the
"in" qualifier for efficiency (pass arrays & structs by ref under the
hood?). Well, seems obvious, but there may be some hidden con
Hello,
I'd like to know, aside user-side semantics, whether the compiler uses the "in"
qualifier for efficiency (pass arrays & structs by ref under the hood?). Well,
seems obvious, but there may be some hidden constraint I'm unable to realise.
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spi
13 matches
Mail list logo
