>> oh no - here we go... readonly arrays again. ;-)
>
> Nope ... but then, do you find it acceptable the D library returns access to shared internals? ;-)

My opinions were expressed in the previous threads.

In case other people are wondering what threads those are check out the archives during June/July with titles involving words like COW, immutable, readonly and the Round I to VII threads.

I also found the thread I started about passing optional scratch buffers to toString: http://www.digitalmars.com/d/archives/digitalmars/D/28249.html There were no replies so I assumed people were happy with the GC impact of std.string and friends.

Ben Hinkle wrote:
>>  Still, Mango is quite a bit more flexible than writef and that it doesn't allocate memory is a huge bonus.  Personally, I'd like to have both options available.
> 
> I can't see where writef allocates memory - though I haven't looked all that hard. Can someone point out what use cases allocate?
> Also what flexibility are you referring to? 

I don't think writef does allocate memory, though Object.toString() is likely to do so, which is how writef prints objects.  So far as flexibility is concerned, writef is great for writing formatted data to the console, to a file, or to another string, but it's fairly common in large applications that I will want to control formatting of objects based on stream characteristics, handle parsing of input data in a similar fashion, make writing to a socket the same as writing to a file (which I suppose it is in Unix), etc.  While this can all be accomplished via writef/readf, it's not really what they were designed for IMO.  But writef is my tool of choice for console IO and such.  You just can't beat the usability of a one-line function call, which Mango doesn't allow out of the box (though wrappers could do this easily enough).


Sean

"Sean Kelly" <sean@f4.ca> wrote in...
[snip]
> for IMO.  But writef is my tool of choice for console IO and such.  You just can't beat the usability of a one-line function call, which Mango doesn't allow out of the box (though wrappers could do this easily enough).

That's a small misconception, since mango.io does have out-of-the-box one-line functions for console support. There's were a number of examples earlier, though they likely were lost amid the sea of unrest :-)

Kris wrote:
> "Sean Kelly" <sean@f4.ca> wrote in...
> [snip]
>> for IMO.  But writef is my tool of choice for console IO and such.  You just can't beat the usability of a one-line function call, which Mango doesn't allow out of the box (though wrappers could do this easily enough).
> 
> That's a small misconception, since mango.io does have out-of-the-box one-line functions for console support. There's were a number of examples earlier, though they likely were lost amid the sea of unrest :-)

Ah nice.  I only read a few of the posts in the last thread :-)


Sean

"Sean Kelly" <sean@f4.ca> wrote ...
> Ah nice.  I only read a few of the posts in the last thread :-)

(* splutter *)

:-)

"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:Xns9727D45B325B1svv1999hotmailcom@63.105.9.61...
> Moreover the behaviour of the whisper notation is undefined according to the specs, which clearly state that the order of all expression evaluations are undefined if not explicitely defined---and no definition for the whisper notation is given.

I've been intending for a while now to revise that to make the order of evaluation explicit. The undefined order of evaluation does not offer many benefits, and causes a lot of headaches.

But there are two different things here: order of evaluation, and operator precedence. D operator precedence is clearly defined. For example:

    a + b + c

is defined to be:

    (a + b) + c

There is no ambiguity. The order of evaluation ambiguity comes from the order a, b, and c are evaluated. For example, for:

void a() { writefln("a"); }
void b() { writefln("b"); }
void c() { writefln("c"); }
...
a() + b() + c()

may output one of:

abc
acb
bac
bca
cab
cba

"BCS" <BCS_member@pathlink.com> wrote in message news:dnctp1$k9k$1@digitaldaemon.com...
> In article <gf10ceogj4nu.1k0swchr1kpfj.dlg@40tude.net>, Derek Parnell
says...
> >I guess that a statement such as
> >
> >    b + c + d;
> >
> >could evaluate to
> >
> >    b.opAdd(c).opAdd(d)

Operator precedence requires this evaluation.

> >or
> >
> >    d.opAdd(c).opAdd(b)

No.

> >but once the evaluation was set, the execution would proceed in left to right order.

No, *that* is currently undefined. It is currently undefined whether b, c, or d is evaluated first. The operator precedence, however, *is* nailed down.

> the order of evaluation can make a difference even without side effects
> Example (contrived):
>
> class A { B opAdd(C);   A opAdd(A) };
> class C { C opAdd(C);   A opAdd(B) };
> class B {  };
>
> A a;
> B b;
> C c;
>
> auto a2 = a + (b + c);  // a2 is A

Correct.

> auto c2 = (a + b) + c;  // c2 is C

This will fail, as there is no match for (a + b).

> auto q  = a + b + c;    // q is A or C??

It will fail, because it parses as (a+b)+c which has no match for (a+b).

Walter Bright wrote:
> "BCS" <BCS_member@pathlink.com> wrote in message
> news:dnctp1$k9k$1@digitaldaemon.com...
> 
>>In article <gf10ceogj4nu.1k0swchr1kpfj.dlg@40tude.net>, Derek Parnell
> 
> says...
> 
>>>I guess that a statement such as
>>>
>>>   b + c + d;
>>>
>>>could evaluate to
>>>
>>>   b.opAdd(c).opAdd(d)
> 
> 
> Operator precedence requires this evaluation.
> 
> 
>>>or
>>>
>>>   d.opAdd(c).opAdd(b)
> 
> 
> No.
> 
> 
>>>but once the evaluation was set, the execution would proceed in left to
>>>right order.
> 
> 
> No, *that* is currently undefined. It is currently undefined whether b, c,
> or d is evaluated first. The operator precedence, however, *is* nailed down.
> 
> 
>>the order of evaluation can make a difference even without side effects
>>Example (contrived):
>>
>>class A { B opAdd(C);   A opAdd(A) };
>>class C { C opAdd(C);   A opAdd(B) };
>>class B {  };
>>
>>A a;
>>B b;
>>C c;
>>
>>auto a2 = a + (b + c);  // a2 is A
> 
> 
> Correct.
> 
> 
>>auto c2 = (a + b) + c;  // c2 is C
> 
> 
> This will fail, as there is no match for (a + b).
> 
> 
>>auto q  = a + b + c;    // q is A or C??
> 
> 
> It will fail, because it parses as (a+b)+c which has no match for (a+b).
> 
> 
oops, my bad, it was supposed to be:

class A { A opAdd(A);   C opAdd(B);   B opAdd(C); };
class B { C opAdd(A);   B opAdd(B);   A opAdd(C); };
class C { B opAdd(A);   A opAdd(B);   C opAdd(C); };

(I got lazy and didn't want to type all of them out)

As to a+b+c being unambiguous, I can't find the rules that make that true. Could you please point me to them?

"BCS" <BCS_member@pathlink.com> wrote in message news:dnn794$1psk$1@digitaldaemon.com...
> As to a+b+c being unambiguous, I can't find the rules that make that true. Could you please point me to them?

It's implicit in the grammar for AddExpression's.

Walter Bright wrote:
> "BCS" <BCS_member@pathlink.com> wrote in message
> news:dnn794$1psk$1@digitaldaemon.com...
> 
>>As to a+b+c being unambiguous, I can't find the rules that make that
>>true. Could you please point me to them?
> 
> 
> It's implicit in the grammar for AddExpression's.
> 
> 

I just reread that, and I don't see it.

(I'm looking at http://www.digitalmars.com/d/expression.html#AddExpression , is this the right place )