www.digitalmars.com         C & C++   DMDScript  

D - DMD 0.73 release

reply "Walter" <walter digitalmars.com> writes:
Some long awaited features.

http://www.digitalmars.com/d/changelog.html
Sep 19 2003
next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
Walter, you ROCK!

"Walter" <walter digitalmars.com> wrote in message
news:bked8d$2pe5$1 digitaldaemon.com...

 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html
Sep 19 2003
prev sibling next sibling parent "Riccardo De Agostini" <riccardo.de.agostini email.it> writes:
You're my hero! :)

"Walter" <walter digitalmars.com> ha scritto nel messaggio
news:bked8d$2pe5$1 digitaldaemon.com...

 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html
Sep 19 2003
prev sibling next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Love your work, but have a gripe and a request.

Gripe: names of special methods as opIndex, opSlice etc are neither
sufficiently unambiguous, or sufficiently eye-catching. Can you explain why
you are not moved by something like __index__, __slice__ or such?

Request: The index operator is documented as taking an int. Can it also
take, say, a char[]? If so, you should put that in the doc. If not, consider
this a request for that?


"Walter" <walter digitalmars.com> wrote in message
news:bked8d$2pe5$1 digitaldaemon.com...

 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html
Sep 19 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkf0c3$145b$1 digitaldaemon.com...

 Love your work, but have a gripe and a request.

 Gripe: names of special methods as opIndex, opSlice etc are neither
 sufficiently unambiguous, or sufficiently eye-catching.


I put them in boldface in the documentation <g>.


 Can you explain why
 you are not moved by something like __index__, __slice__ or such?


That's what python does. While it does stand out, it kinda doesn't look
right to me, because whenever I see _ _ it looks like some kludgy internal
compiler feature is being accessed.


 Request: The index operator is documented as taking an int. Can it also
 take, say, a char[]? If so, you should put that in the doc. If not,


consider

 this a request for that?


It can take any type - the usual overloading rules apply. The documentation
just gives an example where it uses an int. There can be multiple property
setters, and setters can have a return value.
Sep 19 2003
parent reply "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
 That's what python does. While it does stand out, it kinda doesn't look
 right to me, because whenever I see _ _ it looks like some kludgy internal
 compiler feature is being accessed.


That's exactly what it is: some (not kludgy but...) internal compiler
feature. At least would you consider using the "operator/reverse operator"
keyword as was sugested before? Also name mangling for operators would be
nice so they don't colide with normal methods when linking.




 Request: The index operator is documented as taking an int. Can it also
 take, say, a char[]? If so, you should put that in the doc. If not,


 consider

 this a request for that?


 It can take any type - the usual overloading rules apply. The


documentation

 just gives an example where it uses an int. There can be multiple property
 setters, and setters can have a return value.


Nice :).
Sep 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
news:bkfcg0$2275$1 digitaldaemon.com...

 That's what python does. While it does stand out, it kinda doesn't look
 right to me, because whenever I see _ _ it looks like some kludgy




internal

 compiler feature is being accessed.


 That's exactly what it is: some (not kludgy but...) internal compiler
 feature.


I disagree that they are some internal compiler feature. They are an
up-front language feature!


 At least would you consider using the "operator/reverse operator"
 keyword as was sugested before? Also name mangling for operators would be
 nice so they don't colide with normal methods when linking.


I am open to a better naming convention. "operator >", for example, does not
work too well because cmp() replaces all the <, <=, >, >= operators.
Sep 19 2003
parent reply "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
 That's exactly what it is: some (not kludgy but...) internal compiler
 feature.


 I disagree that they are some internal compiler feature. They are an
 up-front language feature!



Obviously we have diferent opinions :).



 I am open to a better naming convention. "operator >", for example, does


not

 work too well because cmp() replaces all the <, <=, >, >= operators.


They could be the short names that we have right now:

operator cmp()
operaror add()
operator addass()
...

The thing is that they should not collide with regular user-defined methods
(Hence the name mangling). The new "operator" keyword should stand out
suficiently and probably will be easier for syntax highlighting algorithms
than using regular methods with special names.
Sep 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
news:bkgc6t$1rdg$1 digitaldaemon.com...

 They could be the short names that we have right now:

 operator cmp()
 operaror add()
 operator addass()
 ...

 The thing is that they should not collide with regular user-defined


methods

 (Hence the name mangling). The new "operator" keyword should stand out
 suficiently and probably will be easier for syntax highlighting algorithms
 than using regular methods with special names.


Hmm. I do like that better than __xxx__ !
Sep 19 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
I'm equally happy with __add__ and operator add(). Just not opAdd

In fact I think I like operator add() more.

However, it begs the question why we just don't have operator +() ?

"Walter" <walter digitalmars.com> wrote in message
news:bkgdgr$1vnq$1 digitaldaemon.com...

 "Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
 news:bkgc6t$1rdg$1 digitaldaemon.com...

 They could be the short names that we have right now:

 operator cmp()
 operaror add()
 operator addass()
 ...

 The thing is that they should not collide with regular user-defined


 methods

 (Hence the name mangling). The new "operator" keyword should stand out
 suficiently and probably will be easier for syntax highlighting




algorithms

 than using regular methods with special names.


 Hmm. I do like that better than __xxx__ !
Sep 19 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Also, all this merry nomenclatural banter masks the deeper issue of concern
that operators are member functions. :(


"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgh89$2d4f$1 digitaldaemon.com...

 I'm equally happy with __add__ and operator add(). Just not opAdd

 In fact I think I like operator add() more.

 However, it begs the question why we just don't have operator +() ?

 "Walter" <walter digitalmars.com> wrote in message
 news:bkgdgr$1vnq$1 digitaldaemon.com...

 "Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
 news:bkgc6t$1rdg$1 digitaldaemon.com...

 They could be the short names that we have right now:

 operator cmp()
 operaror add()
 operator addass()
 ...

 The thing is that they should not collide with regular user-defined


 methods

 (Hence the name mangling). The new "operator" keyword should stand out
 suficiently and probably will be easier for syntax highlighting




 algorithms

 than using regular methods with special names.


 Hmm. I do like that better than __xxx__ !
Sep 19 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Hear!

In many cases it is not possible to determine which of two classes should
have the operator.

What if two different classes both overload operators on the other class?
Is that a conflict?

class A { operator_cmp(B b) { return -b.cmp(this); } }
class B { operator_cmp(A a) { return -a.cmp(this); } }

It would be best if you just put it in the global namespace

operator A a cmp B b noncommutative
{
    return a.member < b.member ? -1 : a.member == b.member ? 0 : 1;
}

Sean

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkghmm$2eu1$1 digitaldaemon.com...

 Also, all this merry nomenclatural banter masks the deeper issue of


concern

 that operators are member functions. :(
Sep 19 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Koenig lookup next stop. He he


them defined as class members, but it's simply wrong.

Having said that, I can probably live with them as such, if only they were
static.

Don't get me wrong: you're completely right about it. I'm just being a
pragmatist as usual.


"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bkgl1k$2rbe$1 digitaldaemon.com...

 Hear!

 In many cases it is not possible to determine which of two classes should
 have the operator.

 What if two different classes both overload operators on the other class?
 Is that a conflict?

 class A { operator_cmp(B b) { return -b.cmp(this); } }
 class B { operator_cmp(A a) { return -a.cmp(this); } }

 It would be best if you just put it in the global namespace

 operator A a cmp B b noncommutative
 {
     return a.member < b.member ? -1 : a.member == b.member ? 0 : 1;
 }

 Sean

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkghmm$2eu1$1 digitaldaemon.com...

 Also, all this merry nomenclatural banter masks the deeper issue of


 concern

 that operators are member functions. :(
Sep 19 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgldj$2slf$1 digitaldaemon.com...

 Koenig lookup next stop. He he


You're funny!!  ;)



 them defined as class members, but it's simply wrong.


yes


 Having said that, I can probably live with them as such, if only they were
 static.


I don't understand.


 Don't get me wrong: you're completely right about it. I'm just being a
 pragmatist as usual.


Don't worry about it.

Sean


 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bkgl1k$2rbe$1 digitaldaemon.com...

 Hear!

 In many cases it is not possible to determine which of two classes




should

 have the operator.

 What if two different classes both overload operators on the other




class?

 Is that a conflict?

 class A { operator_cmp(B b) { return -b.cmp(this); } }
 class B { operator_cmp(A a) { return -a.cmp(this); } }

 It would be best if you just put it in the global namespace

 operator A a cmp B b noncommutative
 {
     return a.member < b.member ? -1 : a.member == b.member ? 0 : 1;
 }

 Sean

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkghmm$2eu1$1 digitaldaemon.com...

 Also, all this merry nomenclatural banter masks the deeper issue of


 concern

 that operators are member functions. :(
Sep 19 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 Having said that, I can probably live with them as such, if only they




were

 static.


 I don't understand.


Even though your assertion that they should be in the global namespace is
correct I, as a pragmatic fellow, will be content (at least to the point of
ceasing my whingeing) if they are implement as *static* member functions. I
can't live with the status quo, of them as non-static member functions, and
I don't plan to stop campaigning against them (see this month's CUJ!)
Sep 19 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgn1s$30ng$1 digitaldaemon.com...

 Having said that, I can probably live with them as such, if only they




 were

 static.


 I don't understand.


 Even though your assertion that they should be in the global namespace is
 correct I, as a pragmatic fellow, will be content (at least to the point


of

 ceasing my whingeing) if they are implement as *static* member functions.


I

 can't live with the status quo, of them as non-static member functions,


and

 I don't plan to stop campaigning against them (see this month's CUJ!)


Ok, I still don't understand how you would want them declared.  If static,
they don't automatically take any arguments, and what you get is essentially
the same thing as a global function, only it's somehow hidden in the class
namespace?  How would you use it then?

It wouldn't resolve the issue of which class should it be a static member
function of!  And you'd still need "friend" capability, though not for both
classes, just for one of them.

Sean
Sep 20 2003
parent Mike Wynn <mike l8night.co.uk> writes:
Sean L. Palmer wrote:

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkgn1s$30ng$1 digitaldaemon.com...
 

Having said that, I can probably live with them as such, if only they




were


static.


I don't understand.


Even though your assertion that they should be in the global namespace is
correct I, as a pragmatic fellow, will be content (at least to the point


 
 of
 

ceasing my whingeing) if they are implement as *static* member functions.


 
 I
 

can't live with the status quo, of them as non-static member functions,


 
 and
 

I don't plan to stop campaigning against them (see this month's CUJ!)


 
 
 Ok, I still don't understand how you would want them declared.  If static,
 they don't automatically take any arguments, and what you get is essentially
 the same thing as a global function, only it's somehow hidden in the class
 namespace?  How would you use it then?
 
 It wouldn't resolve the issue of which class should it be a static member
 function of!  And you'd still need "friend" capability, though not for both
 classes, just for one of them.
 
 Sean
 
 


operators should be in the form

binary/op= : RT operator ( LHS, RHS ) { .... }
where ever declared should be a "friend" or the types RT, LHS, RHS

unary/++   : RT operator ( T ) { .... }
where ever declared should be a "friend" or the types RT, T

e.g.
int operator_add( A a, B b ) { ... }
A   operator_add( A a, B b ) { ... }
B   operator_add( A a, B b ) { ... }

class A {}; class B : A {}
A b, a;
int i;
b = new B();
a = new A();
i = a+b;   // should call int operator_add( A, B );
b = a+b;   // should call B   operator_add( A, B );

a more complex example say `i = a+b+b`; is
i = ((a + b) + b);
the first (a + b) would be expected to be evaluated in the same context 
as the RHS unless cast so
would be
B t1 = a+b; B op_add( A, B)
i = t1 + b; int op_add( B, B );

to force the first a+b to be evaluated in A context it would have to be 
rewritten as
i = (cast(A)(a + b) + b);
would now become
A t1 = a+b; A op_add( A, B )
i = t1 + b; int op_add( A, B );

I've attached some example code I've been playing with to try to get 
this behaviour from D classes, but currently am stummped on how to get 
the operators to "evaluate" into context
(so far my chose is lazy eval )
i = a+b would be written
i = (a+b).eval(int.classinfo);
(all operators return "LazyEvaluators")
so a+b+b
=> (a+b)
=>LazyEval["+" : A, B => Unknown] + B
=> LazyEval( "+" : LazyEval, B => Unknown )
eval( int.classinfo) would then process A,B=>B; B+B=>int
throwing runtime exceptions along the way if operators where missing.

I also do not believe in r_sub;
instead
B operator_sub( B, A );
and
B operator_sub( A, B );
should be written (if required)
Sep 20 2003
prev sibling parent "Julio César Carrascal Urquijo" <adnoctum phreaker.net> writes:
 However, it begs the question why we just don't have operator +() ?


Because of the issue that Walter just bring up:

operator <()
operator =()
operator >()

are really implemented by

operator cmp()




 Also, all this merry nomenclatural banter masks the deeper issue of


concern

 that operators are member functions. :(


That's why I'm asking for name mangling, so we can have: "operator add()"
and "void add()" in the same class (Not sure for what will we need it,
though)
Sep 19 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
If you want to have it be easier to parse, require an underscore between
them.  Or whatever the preferred language multi-word-naming style is.
InitialCaps?

operator_cmp()
operator_add()

Sean

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgh89$2d4f$1 digitaldaemon.com...

 I'm equally happy with __add__ and operator add(). Just not opAdd

 In fact I think I like operator add() more.

 However, it begs the question why we just don't have operator +() ?

 "Walter" <walter digitalmars.com> wrote in message
 news:bkgdgr$1vnq$1 digitaldaemon.com...

 "Julio César Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
 news:bkgc6t$1rdg$1 digitaldaemon.com...

 They could be the short names that we have right now:

 operator cmp()
 operaror add()
 operator addass()
 ...

 The thing is that they should not collide with regular user-defined


 methods

 (Hence the name mangling). The new "operator" keyword should stand out
 suficiently and probably will be easier for syntax highlighting




 algorithms

 than using regular methods with special names.


 Hmm. I do like that better than __xxx__ !
Sep 19 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Why not __op__op__op__op__index___________ ?

Is that sufficiently eye-catching for you?  What do you think adding these
underscores is helping?  It's just going to confuse these operators with
everything else that is supposed to stand out visually and someone decides
to add underscores to.  It's not like they're keywords.

It's really just requesting that everybody have to type more.

Sean

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkf0c3$145b$1 digitaldaemon.com...

 Love your work, but have a gripe and a request.

 Gripe: names of special methods as opIndex, opSlice etc are neither
 sufficiently unambiguous, or sufficiently eye-catching. Can you explain


why

 you are not moved by something like __index__, __slice__ or such?
Sep 19 2003
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Walter wrote:

 Some long awaited features.
 
 http://www.digitalmars.com/d/changelog.html


woohoo!

I'm a bit worried about the interface for defining properties.  The way 
it is, you could do weird things like document.save="filename"; whether 
or not it was intended to be used that way.

Is an opIndex overload to handle slice assignment out of the question? 
opIndex(start, end, newValue) or somesuch.

Also a tiny note: the opCall and opIndex examples don't use new to 
allocate an object. (this has tripped people up in the past, if I recall)

  -- andy
Sep 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:bkf0qv$15vh$1 digitaldaemon.com...

 Walter wrote:

 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html


 woohoo!

 I'm a bit worried about the interface for defining properties.  The way
 it is, you could do weird things like document.save="filename"; whether
 or not it was intended to be used that way.


Yes, you can do that. Whether you want to or not is a style issue.


 Is an opIndex overload to handle slice assignment out of the question?
 opIndex(start, end, newValue) or somesuch.


I'm a little unsure about that.


 Also a tiny note: the opCall and opIndex examples don't use new to
 allocate an object. (this has tripped people up in the past, if I recall)


That's because they are structs and don't need it (!). I used both struct
and class examples just to show that operator overloading works with each.
Sep 19 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 I'm a bit worried about the interface for defining properties.  The way
 it is, you could do weird things like document.save="filename"; whether
 or not it was intended to be used that way.


 Yes, you can do that. Whether you want to or not is a style issue.


I would prefer that properties attributes would be required in the
declaration to allows the uses of a function as a property.

Otherwise, this could lead to code obfuscation...  Function call
syntax make the code more clear that an action will occurs.

Also, if properties are explicitly documented as such, this would
be usefull when D will be used for COM or .NET programming
or for visual editing of an UI (the inspector will display public
(or published) methods (as in Delphi) but not arbitrary method
that happen to have the proper number of argument (0 or 1).

Also having a keyword would allows support for array properties.
Sep 20 2003
parent reply Mike Wynn <mike l8night.co.uk> writes:
Philippe Mori wrote:

I'm a bit worried about the interface for defining properties.  The way
it is, you could do weird things like document.save="filename"; whether
or not it was intended to be used that way.


Yes, you can do that. Whether you want to or not is a style issue.


 
 
 I would prefer that properties attributes would be required in the
 declaration to allows the uses of a function as a property.
 
 Otherwise, this could lead to code obfuscation...  Function call
 syntax make the code more clear that an action will occurs.
 
 Also, if properties are explicitly documented as such, this would
 be usefull when D will be used for COM or .NET programming
 or for visual editing of an UI (the inspector will display public
 (or published) methods (as in Delphi) but not arbitrary method
 that happen to have the proper number of argument (0 or 1).
 
 Also having a keyword would allows support for array properties.
 
 


without proper property syntax,
what happens with a property or function that returns a class that 
overloads opCall ?
Sep 20 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bkj2q9$g5u$1 digitaldaemon.com...

 without proper property syntax,
 what happens with a property or function that returns a class that
 overloads opCall ?


You'll need to have an extra ().
Sep 21 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 without proper property syntax,
 what happens with a property or function that returns a class that
 overloads opCall ?


 You'll need to have an extra ().


This is a reason why IMHO it would be better to have a property
keyword. That way it would be possible to forward call to an inner
class with changing the class interface in the same way that in C++
we can chain operator->.

An example:

class A {
    void opCall(int i);
}

class B {
    property A prop_name() { return a }

    A a;
}

// used that way:

B b;
b.prop_name(5);

// instead of

B b;
b.prop_name()(5);

This make it possible to replace a function by
a class without needing the client code to be
aware of it...

But thinking of it, it would probably caused ambiguities
if we allows both syntax (function call vs property)
Sep 21 2003
parent reply Felix <Felix_member pathlink.com> writes:

good idea.


Just an ideea...






In article <bklb95$1kcj$1 digitaldaemon.com>, Philippe Mori says...

 without proper property syntax,
 what happens with a property or function that returns a class that
 overloads opCall ?


 You'll need to have an extra ().


This is a reason why IMHO it would be better to have a property
keyword. That way it would be possible to forward call to an inner
class with changing the class interface in the same way that in C++
we can chain operator->.

An example:

class A {
    void opCall(int i);
}

class B {
    property A prop_name() { return a }

    A a;
}

// used that way:

B b;
b.prop_name(5);

// instead of

B b;
b.prop_name()(5);

This make it possible to replace a function by
a class without needing the client code to be
aware of it...

But thinking of it, it would probably caused ambiguities
if we allows both syntax (function call vs property)
Sep 21 2003
parent "Walter" <walter digitalmars.com> writes:
"Felix" <Felix_member pathlink.com> wrote in message
news:bkm066$2jer$1 digitaldaemon.com...




I think that's correct. The same fellow who did the original Turbo Pascal.
Sep 22 2003
prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Cool beans!  We can now make proper matrix and vector and container classes.

the names of the overloading aliases should all be made consistent.  If you
use opXxxx for the new ones, they should all be opXxxx.


I just noticed this snippet of docs:

Overloading ++e and --e
Since ++e is defined to be semantically equivalent to (e += 1), the
expression ++e is rewritten as (e += 1), and then checking for operator
overloading is done. The situation is analogous for --e.

I can tell you that ++e is definitely not semantically equivalent to e += 1,
because many things can be incremented but not necessarily by an arbitrary
integer amount (not to mention += negative number).

To really support this you'd need to define

E add(E lop, int rop)
{
    if (rop > 0)
    {
        for (int i = rop; --i >= 0; )
            lop++;
    }
}


Excellent work!

Sean

"Walter" <walter digitalmars.com> wrote in message
news:bked8d$2pe5$1 digitaldaemon.com...

 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html
Sep 19 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bkfc91$21qc$1 digitaldaemon.com...

 the names of the overloading aliases should all be made consistent.  If


you

 use opXxxx for the new ones, they should all be opXxxx.


Yes. They'll get changed.


 Overloading ++e and --e
 Since ++e is defined to be semantically equivalent to (e += 1), the
 expression ++e is rewritten as (e += 1), and then checking for operator
 overloading is done. The situation is analogous for --e.

 I can tell you that ++e is definitely not semantically equivalent to e +=


1,

 because many things can be incremented but not necessarily by an arbitrary
 integer amount (not to mention += negative number).


In those cases, an assert(i == 1) in the addass(int i) operator should
handle it.


 Excellent work!


Thanks!
Sep 19 2003
next sibling parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 I can tell you that ++e is definitely not semantically equivalent to e




+=

 1,

 because many things can be incremented but not necessarily by an




arbitrary

 integer amount (not to mention += negative number).


 In those cases, an assert(i == 1) in the addass(int i) operator should
 handle it.


I don't want run-time check when a compile-time could have detect
the error easily...

I would prefer that if would be possible to define opPlusPlus and/or
opLessLess if addass is not defined...

For operator naming, I would like a syntax similar to the one used
in C++ (with some exceptions for cmp for example where operator
cmp would be used).

For that latter operator, I would say that I would like to have
the possibility to be able to define one or two operator among
<, <¸=, > and >= and have the compiler generate the others
so that the compiler could generate more efficient code in
some cases (one comparison instead of 2) except if you can
tell me that the compiler is smart enough to do the optimisation
itself...
Sep 19 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Philippe Mori" <philippe_mori hotmail.com> wrote in message
news:bkgg88$28ta$1 digitaldaemon.com...

 I can tell you that ++e is definitely not semantically equivalent to e




 +=

 1,

 because many things can be incremented but not necessarily by an




 arbitrary

 integer amount (not to mention += negative number).


 In those cases, an assert(i == 1) in the addass(int i) operator should
 handle it.


 I don't want run-time check when a compile-time could have detect
 the error easily...


Good reason!


 I would prefer that if would be possible to define opPlusPlus and/or
 opLessLess if addass is not defined...


Even if it is defined!


 For operator naming, I would like a syntax similar to the one used
 in C++ (with some exceptions for cmp for example where operator
 cmp would be used).


I don't mind C++ syntax for operators.  Though heck you could just override
 + or --  or  [].  Maybe `+.  Maybe this would make everybody else happy,
some standard prefix for operators that is in fact a hopefully easy to type
symbol that is otherwise unused in D.  You could maybe force people to call
an overloaded operator by also using the symbol, such as x `+ y or list [3].
But in this case make all the standard operators also be accessible by using
the same symbol so templates will be able to differentiate them.

Operator overloading is, also, one of the few ways that you can extend one
of the builtin types.


 For that latter operator, I would say that I would like to have
 the possibility to be able to define one or two operator among
 <, <¸=, > and >= and have the compiler generate the others
 so that the compiler could generate more efficient code in
 some cases (one comparison instead of 2) except if you can
 tell me that the compiler is smart enough to do the optimisation
 itself...


The compiler if given enough information can eliminate double-negatives or
even single negatives in the generated code when it comes to comparisons and
branching.  Most compilers routinely do this.  If the compiler can't
optimize through cmp it may have to do extra work at runtime.

Yeah, all you need is one of < and one of =, or one of <=.  I wouldn't be
surprised if any one of the six can be used to generate all the others.
From < you can derive a form of =.

But I'd allow explicit specification of any or all of them.  Some very
complicated comparison (probably bending the rules) might need it.

In fact you could represent inexact types by starting off by defining
operator <=.  Well, > means it's not <=.  If a <= b and b <= a, it's
probably ==.  If not a <= b and not b <= a, it's unordered.
I see a logic table forming here.

And if you can figure out all 6, you can automatically generate a cmp()
function from that.

BTW cmp() really only needs to be able to return 3 'bits' of data...  ==
(Z), < (S), ? (O).  You can build jae out of !jb, etc.

Ideally cmp wouldn't be a member function, so you could specify the operands
in either order... currently you'd have to invert the logic when you swap
operands.

void cmp(in T a, in T b,
               out bit Z, out bit S, out bit O);

I bet Walter is grinning.

Sean
Sep 19 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bkfejj$27cl$2 digitaldaemon.com...

 I can tell you that ++e is definitely not semantically equivalent to e




+=

 1,

 because many things can be incremented but not necessarily by an




arbitrary

 integer amount (not to mention += negative number).


 In those cases, an assert(i == 1) in the addass(int i) operator should
 handle it.


So can you ++ floats then?  ;)

What if I want my class to be able to add, but not ++?  For instance if
there is no well defined "next" to go to, but you can "add" some arbitrary
amount.  For instance, maybe a set.  Yeah this example is probably an abuse
of operator overloading (you'd probably overload ~=).  You can add items to
a set but can't increment a set.

Sean
Sep 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bkgj6v$2k11$1 digitaldaemon.com...

 So can you ++ floats then?  ;)


Yes.


 What if I want my class to be able to add, but not ++?  For instance if
 there is no well defined "next" to go to, but you can "add" some arbitrary
 amount.  For instance, maybe a set.  Yeah this example is probably an


abuse

 of operator overloading (you'd probably overload ~=).  You can add items


to

 a set but can't increment a set.


This goes back to what I think operator overloading should be for. It should
be for adding (!) arithmetic to user defined data types. I think it is not
appropriate to overload << to be anything but a shift operation, i.e. using
it as 'insert' is just not right. I don't agree with the notion that, for
example, ++ could be overloaded to mean 'get the next item in the list'.

This is reflected in the design of the operator overloading in D, such as +
is commutative and / is not. It is not meant to support the notion that ++
is fundamentally different from +=. I think operator overloading should be
used much more conservatively than how it is popularly used in C++. People
shouldn't have to look for an operator overload of += to find out that what
it is doing has nothing at all to do with adding.
Sep 19 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 This goes back to what I think operator overloading should be for. It


should

 be for adding (!) arithmetic to user defined data types. I think it is not
 appropriate to overload << to be anything but a shift operation, i.e.


using

 it as 'insert' is just not right. I don't agree with the notion that, for
 example, ++ could be overloaded to mean 'get the next item in the list'.

 This is reflected in the design of the operator overloading in D, such as


+

 is commutative and / is not. It is not meant to support the notion that ++
 is fundamentally different from +=. I think operator overloading should be
 used much more conservatively than how it is popularly used in C++. People
 shouldn't have to look for an operator overload of += to find out that


what

 it is doing has nothing at all to do with adding.


Quite right. Transgressors should be weeded out and forced to 3yrs hard
VB.NET before they're allowed back on parole
Sep 19 2003
next sibling parent "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgocr$3j7$1 digitaldaemon.com...

 Quite right. Transgressors should be weeded out and forced to 3yrs hard
 VB.NET before they're allowed back on parole


I never knew you were so cruel <g>.
Sep 20 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgocr$3j7$1 digitaldaemon.com...

 is fundamentally different from +=. I think operator overloading should




be

 used much more conservatively than how it is popularly used in C++.




People

 shouldn't have to look for an operator overload of += to find out that




what

 it is doing has nothing at all to do with adding.


 Quite right. Transgressors should be weeded out and forced to 3yrs hard
 VB.NET before they're allowed back on parole


In my own module, I should be able to do whatever I please, whatever makes
solving the task at hand easier.  Who are you to dictate to me how I should
program?  Who the hell do you think you are?

If I expose this stuff to you, and you don't like it, feel free to not use
my library.

Sean
Sep 20 2003
parent reply Mike Wynn <mike l8night.co.uk> writes:
Sean L. Palmer wrote:

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkgocr$3j7$1 digitaldaemon.com...
 

is fundamentally different from +=. I think operator overloading should




 
 be
 

used much more conservatively than how it is popularly used in C++.




 
 People
 

shouldn't have to look for an operator overload of += to find out that




 
 what
 

it is doing has nothing at all to do with adding.


Quite right. Transgressors should be weeded out and forced to 3yrs hard
VB.NET before they're allowed back on parole


 
 
 In my own module, I should be able to do whatever I please, whatever makes
 solving the task at hand easier.  Who are you to dictate to me how I should
 program?  Who the hell do you think you are?
 


you have already allowed Walter to dictated to you how you program, by 
chosing his language to use.

what you write in your own module is upto you, but if you are making it 
public, then you might want to listen to what those who might be using 
it are saying.

are you that well intune with D to understand the effects and 
implications of operator overloading
for instance, although virtual, which "virtual" method to call is 
statically determined

and have you made your users aware of the side effects of your use of 
overloading.



 If I expose this stuff to you, and you don't like it, feel free to not use
 my library.
Sep 20 2003
parent "Pizaz" <me here.com> writes:
"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bkib7u$2ilb$1 digitaldaemon.com...

 Sean L. Palmer wrote:

<snip>
 In my own module, I should be able to do whatever I please, whatever




makes

 solving the task at hand easier.  Who are you to dictate to me how I




should

 program?  Who the hell do you think you are?





/me steps inbetween Mike and Sean and says:   "SO HOW ABOUT THEM SEATTLE
SEAHAWKS?"
:)


 you have already allowed Walter to dictated to you how you program, by
 chosing his language to use.

 what you write in your own module is upto you, but if you are making it
 public, then you might want to listen to what those who might be using
 it are saying.


<snip>
Sep 20 2003
prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bkgnd1$cd$1 digitaldaemon.com...

 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bkgj6v$2k11$1 digitaldaemon.com...

 So can you ++ floats then?  ;)


 Yes.


 What if I want my class to be able to add, but not ++?  For instance if
 there is no well defined "next" to go to, but you can "add" some




arbitrary

 amount.  For instance, maybe a set.  Yeah this example is probably an


 abuse

 of operator overloading (you'd probably overload ~=).  You can add items


 to

 a set but can't increment a set.


 This goes back to what I think operator overloading should be for. It


should

 be for adding (!) arithmetic to user defined data types. I think it is not
 appropriate to overload << to be anything but a shift operation, i.e.


using

 it as 'insert' is just not right. I don't agree with the notion that, for
 example, ++ could be overloaded to mean 'get the next item in the list'.


That's your prerogative.  But despite what *you* think operator overloading
*should* be for, people will see it as a tool, and if the tool allows them
to do what they want to do, they'll use it.  People have found all kinds of
inventive uses for operator overloading in C++, and though you and your camp
cringe when they see this, and curse them, the other camp sees this as
innovative and stylish and concise.  ;)

Fact is, people are always taught programming of named functions, but
operators are just as much functions as ones with names.  Many many problems
are better solved symbolically than with longwinded names.  The problem in
C++ is that there aren't enough operators available for overloading and so
people have to abuse the ones that *are* provided.

That said, you are the designer of D, and you are free to do as you wish.


 This is reflected in the design of the operator overloading in D, such as


+

 is commutative and / is not. It is not meant to support the notion that ++
 is fundamentally different from +=. I think operator overloading should be
 used much more conservatively than how it is popularly used in C++. People
 shouldn't have to look for an operator overload of += to find out that


what

 it is doing has nothing at all to do with adding.


You could say this about any function call.  Functions are just a little
easier to search for, is all.  People need to RTFM and not just assume they
can look at something and understand it.  There is often more than meets the
eye, even in normal functional or OO programs.

If ++x is converted to x += 1 automatically, then what if you overload
operator + to take something besides int type?

And if you do mapp ++x to x += 1, then you should also automatically map x++
to temp = x, x += 1, temp, and similarly for x--

99% of the time what I do want to use overloading for IS a mathematical
type.  But I've seen some really neat stuff done with operator overloading,
things that the inventors would never have considered.

Perhaps you could allow a bunch of other operators available for overloading
that people could do with as they pleased?  Maybe `+` or `,`?  Nah, looks
too much like a character literal.  Maybe any normal D operator surrounded
by periods, or colons?

Sean
Sep 20 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bki5gj$2apn$1 digitaldaemon.com...

 If ++x is converted to x += 1 automatically, then what if you overload
 operator + to take something besides int type?

 And if you do mapp ++x to x += 1, then you should also automatically map


x++

 to temp = x, x += 1, temp, and similarly for x--

 99% of the time what I do want to use overloading for IS a mathematical
 type.  But I've seen some really neat stuff done with operator


overloading,

 things that the inventors would never have considered.


There is always that risk that perhaps this shuts the door on something. But
although I don't agree with using arithmetic operator overloading for
non-arithmetic purposes, that's a purely stylistic issue. Sorry if my
opinions come on a little strong about it sometimes. What the arithmetic
operator overloading rules do, however, is make it much easier to make a
user-defined arithmetic type and integrate it into the language. For
example, only one comparison operator needs to be written, rather than the 8
in C++.
Sep 20 2003
next sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 There is always that risk that perhaps this shuts the door on something.


But

 although I don't agree with using arithmetic operator overloading for
 non-arithmetic purposes, that's a purely stylistic issue. Sorry if my
 opinions come on a little strong about it sometimes. What the arithmetic
 operator overloading rules do, however, is make it much easier to make a
 user-defined arithmetic type and integrate it into the language. For
 example, only one comparison operator needs to be written, rather than the


8

 in C++.


IMHO, how the operators works is a property of the class (this include
assignment, creation,...) and we either tag the class with an attribute
when we want something different than the default (which should be
conservative and safe) or it should be expressed by the functions
(and their attibutes) that are prent in the class.

We should be able to detect if a class support a concept without
requiring an interface (and a virtual table). We do not necessarily need
MI but we should be able to associate some characteristics to a class
(or the compiler should be able to tell us from the definition).

I want to be able to know if a class is comparable (and if so, which
king of comparison are allowed, equality only, fully ordered or
partly ordered), copyable (if so, if bitwise for struct, deeep, shalow,...),
createable on stack (auto) or dynamically, assignable, if it might be null,
...

For the operator, it is true that in C++, not enough operators are
defined in terms of others but I think we should have some control
of what we allows and which operators are always or sometimes
defined in term of others... I think the best solution would be to do
almost nothing by default but provide an easy way to get many things
done by the compiler...

This could be done in a few ways. Here are some possibilities:

a) We have some class attributes (or the possibility to inherit from
some special "capability declaration classes" that would tell how
some operators (and other functions) are handled:

class A : fully_ordered, deep_copy, standard_arithmetic { }

where theses bases classes would give constraints or capabilities
or behaviors of the classes. A constraint class cannot have virtual
member nor data member (i.e always a empty-base) but would
only have declarations and template style definitions. We would
provide a few such constraint classes in the standard library. Here
an example (the syntax may have some errors but it should give
the idea) :

constraint class fully_ordered {
    // derived indicate that the type must be a derived class...
    template (T:derived)
    int cmp(T t1, T t2);    // declaration only

    // Here is is a sample on how we could prevent (we might
    // also simply uses private access) but exactly what we
    // give might vary a bit (we could in particular have
    // one safe class and another one that do more thing
    // automatically.
    template (T:derived, U:derived)
    prohibited int cmp(T t, U u); // declaration -- prevent mixed derived
classes

    template (T:derived)
    bool operator < (T t1, T t2) { return cmp(t1, t2) < 0; }

    template (T:derived)
    bool operator <= (T t1, T t2) { return cmp(t1, t2) <= 0; }

    template (T:derived)
    bool operator > (T t1, T t2) { return cmp(t1, t2) > 0; }

    template (T:derived)
    bool operator >= (T t1, T t2) { return cmp(t1, t2) >= 0; }

    // Have a way to check if a type has a member (or free) function
    // and if so, uses that specialisation...
    // The syntax need reworking -- I uses plain english to give the
    // concept. The idae is simply to be able to specialize on something
    // more than T* or MyClass* or something similar
    template (T : derived where T has (eq))
    bool operator==(T t1, T t2) { return eq(t1, t2); }

    // This is the normal definition uses when the specialisation
    // do not apply.
    template (T : derived )
    bool operator==(T t1, T t2) { return cmp(t1, t2); }

    template (T: derived)
    bool operator!=(T t1, T t2) { return !(t1 == t2); }
}

constraint_class fully_ordered_less {
    // Similar to above but uses a member function less
    // to implement all operators.

    // In fact, we could merge that constraint class with the
    // previous and check for the presence of members
    // eq(), cmp() and less() to decide what we do (and
    // we could even prohibit having both operator less and
    // cmp defined if we want by making a specialisation
    // when both are defined and prohibiting it...

    // In fact, it be usefull in that case to prohibit class instanciation
    // even if no comparison are ever done..

    // Maybe we would also like to be able to put contraints
    // that make the class abstract is something is not defined...
}

The advantage of doing is that way is clear... We can provide a class
with the most usefull rules so that it would be very easy to uses them
but it is possible to define our owns constraint classes (for example
one that would works with partial order).

Also, it is possible to group those class:

constraint class fully_ordered_with_deep_copy : fully_ordered, deeep_copy
{ }

and when we want to uses a class, we simply specify those classes
as if we inherit from them.

class A : fully_ordered {
    int cmp(...) { definition here... }
};


With such a concept of constraint classes, we add lot of power to the
language as those classes would be used to:

a) automatically implement some operations in term of others
b) verify that a class define something (similar to an abstract method)
c) verify some other constraint on a type...

Also, it would be easy if one want operator ++ to means += 1 to have
one such class and one other if we don't want it...

By default, I would say that classes would be relatively restricted
if the do not inherited from such a class (to be the safest by default).
We might even prohibit some kind of operations if we do not inherit
from a class that enable it... (for ex. no operator cmp if we do not
have a constraint class that define its behavior)

We would have a language that would allows to express lot of things
directly in the code...
Sep 20 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bkim0p$30sm$1 digitaldaemon.com...

 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bki5gj$2apn$1 digitaldaemon.com...

 If ++x is converted to x += 1 automatically, then what if you overload
 operator + to take something besides int type?

 And if you do mapp ++x to x += 1, then you should also automatically map


 x++

 to temp = x, x += 1, temp, and similarly for x--

 99% of the time what I do want to use overloading for IS a mathematical
 type.  But I've seen some really neat stuff done with operator


 overloading,

 things that the inventors would never have considered.


 There is always that risk that perhaps this shuts the door on something.


But

 although I don't agree with using arithmetic operator overloading for
 non-arithmetic purposes, that's a purely stylistic issue. Sorry if my
 opinions come on a little strong about it sometimes. What the arithmetic
 operator overloading rules do, however, is make it much easier to make a
 user-defined arithmetic type and integrate it into the language. For
 example, only one comparison operator needs to be written, rather than the


8

 in C++.


I'm not really against it in some cases.  I'm just not sure ++ == +1 is a
good one.  It seems unbalanced.

Sean
Sep 20 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 I'm not really against it in some cases.  I'm just not sure ++ == +1 is a
 good one.  It seems unbalanced.

 Sean


I would say that it should be possible to define ++ or -- if += or -= is not
defined for a type (like it would be the case for an iterator in C++ STL
that is not a random iterator). In those case, we might prefer to have
only ++ and/or -- defined.

OTOH, always defining ++ from += (if that one is defined), is not a good
idea either... For example, the following will loop infinitly and it might
not
be desirable that the code compile than way:

for (double d = 1e16; d < 1.01e16; ++d)
{
    // Do something with d...
}

Also for some type like an enum (or a class that would emulate it if it
does not apply), it is simpler to implement increment by one that by an
arbitrary number...

IMO, if we support both eq and cmp for a class at the same time, why
for ++ and +=, they must always be defined one in the term of the
other ?

On that issues, if cmp is implemented for a type but not eq, will
eq, == and != be implemented in terms of cmp ?
Sep 21 2003
prev sibling parent reply J Anderson <anderson badmama.com.au.REMOVE> writes:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>

Walter wrote:<br>
<blockquote type="cite" cite="midbkgnd1$cd$1 digitaldaemon.com">
  <pre wrap="">"Sean L. Palmer" <a class="moz-txt-link-rfc2396E"
href="mailto:palmer.sean verizon.net">&lt;palmer.sean verizon.net&gt;</a> wrote
in message
<a class="moz-txt-link-freetext"
href="news:bkgj6v$2k11$1 digitaldaemon.com">news:bkgj6v$2k11$1 digitaldaemon.com</a>...
  </pre>
  <blockquote type="cite">
    <pre wrap="">So can you ++ floats then?  ;)
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Yes.

  </pre>
  <blockquote type="cite">
    <pre wrap="">What if I want my class to be able to add, but not ++?  For
instance if
there is no well defined "next" to go to, but you can "add" some arbitrary
amount.  For instance, maybe a set.  Yeah this example is probably an
    </pre>
  </blockquote>
  <pre wrap=""><!---->abuse
  </pre>
  <blockquote type="cite">
    <pre wrap="">of operator overloading (you'd probably overload ~=).  You can
add items
    </pre>
  </blockquote>
  <pre wrap=""><!---->to
  </pre>
  <blockquote type="cite">
    <pre wrap="">a set but can't increment a set.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
This goes back to what I think operator overloading should be for. It should
be for adding (!) arithmetic to user defined data types. I think it is not
appropriate to overload &lt;&lt; to be anything but a shift operation, i.e.
using
it as 'insert' is just not right. I don't agree with the notion that, for
example, ++ could be overloaded to mean 'get the next item in the list'.

This is reflected in the design of the operator overloading in D, such as +
is commutative and / is not. It is not meant to support the notion that ++
is fundamentally different from +=. I think operator overloading should be
used much more conservatively than how it is popularly used in C++. People
shouldn't have to look for an operator overload of += to find out that what
it is doing has nothing at all to do with adding.

  </pre>
</blockquote>
I agree, you shouldn't need to have to look at to much documentation to
realize what some operator does.&nbsp; By restricting how each operator
interacts, they each develop their own behavior which can be quickly
recognized by the average coder.&nbsp; <br>
<br>
Of course there are always are situations where&nbsp; you run out of symbols
for the particular behavior needed.&nbsp; In these cases the programmer
generally falls back to, methods, or proxy objects.<br>
<br>
Parhaps allowing extended operators, in array form, or using colon...<br>
<br>
x = x +[2] y; //Powerful but ugly<br>
x = x +[LIST_OPS_2] y; //Then they'd want to use variables, with them
(why not use methods in the first place).<br>
<br>
or<br>
x = (x + y)[2];<br>
or<br>
x = x :+: y; //Probably the neatest form<br>
or<br>
x = x .+ y; //Mixed up with float point?<br>
or<br>
x = x plus[2] y; //Don't use symbols at all.<br>
<br>
...nar IMHO, that'd make D begin to look like ugly machine code.<br>
<br>
I think it's best to stick with how it works now&nbsp;<span
 class="moz-smiley-s3"><span> ;-) </span></span>
</body>
</html>
Sep 20 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

x =3D x :+: y; //Probably the neatest form

I like the idea of being able to define our own operators. This could be =

done by using :something: as youi suggest or we might also uses

allows most characters that are used in operators and any valid=20
name (we migth have some restrictions on what symbols are
allowed and not allowing mixing symbol (like +, <) with names.

Using a trailing symbol does have an advantage of limiting possible=20
ambiguities if we want to allows no space after the operator.

For example, I would be able to define an exponent operator

5.1  pow 2    // 5.1 ^ 2 (i.e. 5.1 * 5.1)

Matrix m;

 det m;    // determinant of the matrix m
    // where  det is defined as a prefix operator of class Matrix


When a user defined operator is found, the compiler would=20
suppose binary operator if there is an expression on both side
a prefix operator if there is an expression on the right and a a=20
postfix operator if there is an expression on the left.

a +  my_op b;     my_op is a prefix op for object of type b
a  my_op b;     my_op is a binary op
a  my_op + b;     my_op is a postfix op for object of type a
Sep 20 2003
prev sibling parent reply John Boucher <John_member pathlink.com> writes:
In article <bkfc91$21qc$1 digitaldaemon.com>, Sean L. Palmer says...

Cool beans!  We can now make proper matrix and vector and container classes.

the names of the overloading aliases should all be made consistent.  If you
use opXxxx for the new ones, they should all be opXxxx.


I just noticed this snippet of docs:

Overloading ++e and --e
Since ++e is defined to be semantically equivalent to (e += 1), the
expression ++e is rewritten as (e += 1), and then checking for operator
overloading is done. The situation is analogous for --e.



I can tell you that ++e is definitely not semantically equivalent to e += 1,
because many things can be incremented but not necessarily by an arbitrary
integer amount (not to mention += negative number).

To really support this you'd need to define

E add(E lop, int rop)
{
    if (rop > 0)
    {
        for (int i = rop; --i >= 0; )
            lop++;
    }
}


Excellent work!

Sean

"Walter" <walter digitalmars.com> wrote in message
news:bked8d$2pe5$1 digitaldaemon.com...

 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html




This again brings to mind what I was thinking about for strings...
I was considering the benefit of overloading the ++ and -- operators for
strings... They could be toUpper() and toLower() operators!!

John Boucher -- Quite contrary
The King had Humpty pushed.
Sep 19 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
That is an interesting idea!  It's a very common operation.

Sean

"John Boucher" <John_member pathlink.com> wrote in message
news:bkfh2j$2dd4$1 digitaldaemon.com...

 This again brings to mind what I was thinking about for strings...
 I was considering the benefit of overloading the ++ and -- operators for
 strings... They could be toUpper() and toLower() operators!!
Sep 19 2003
prev sibling next sibling parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
Walter,

In http://www.digitalmars.com/d/operatoroverloading.html surely the boolean
comparison operators <, >, <= and >= are not commutative?


"Walter" <walter digitalmars.com> wrote in message
news:bked8d$2pe5$1 digitaldaemon.com...

 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html
Sep 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:bkfcts$238q$1 digitaldaemon.com...

 Walter,

 In http://www.digitalmars.com/d/operatoroverloading.html surely the


boolean

 comparison operators <, >, <= and >= are not commutative?


Sure they are!
    a < b
and
    b > a
Sep 19 2003
next sibling parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
 Sure they are!
     a < b
 and
     b > a


No, commutative means "a op b == b op a" where op is the same operator in
both cases. (a<b) != (b<a), so the '<' operator is not commutative, just
like '-' is not
Sep 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:bkfmsn$2ubl$1 digitaldaemon.com...

 Sure they are!
     a < b
 and
     b > a


 No, commutative means "a op b == b op a" where op is the same operator in
 both cases. (a<b) != (b<a), so the '<' operator is not commutative, just
 like '-' is not


In a mathematical sense you're right, but I just turn < into > to swap the
operands, and >= into <=.
Sep 19 2003
parent reply "Jeroen van Bemmel" <someone somewhere.com> writes:
 In a mathematical sense you're right, but I just turn < into > to swap the
 operands, and >= into <=.


OK, so they are like 'commutable'. Isn't this confusing in the context of
overloading? When do you do this implicit transformation, in the optimizer?
I noticed all these operators map to 'cmp', so 'cmp' should return -1,0,+1
or something?

I must say this new operator overloading feature doesn't really appeal to
me. It seems like there is more complexity and caveats being added than
benefits (syntactic sugar)
Sep 20 2003
parent "Walter" <walter digitalmars.com> writes:
"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:bkh5rd$1269$1 digitaldaemon.com...

 In a mathematical sense you're right, but I just turn < into > to swap




the

 operands, and >= into <=.


 OK, so they are like 'commutable'. Isn't this confusing in the context of
 overloading? When do you do this implicit transformation, in the


optimizer?

No, in the semantic phase.


 I noticed all these operators map to 'cmp', so 'cmp' should return -1,0,+1
 or something?


All it needs to return is an int less than 0, 0, or greater than 0. Think of
it like the strcmp() function in C.


 I must say this new operator overloading feature doesn't really appeal to
 me. It seems like there is more complexity and caveats being added than
 benefits (syntactic sugar)


One benefit is only one cmp function needs to be written instead of the 8 in
C++ <g>. Remember, though, that == and != are handled by eq(), not cmp().
This is because it is common for a type to have an equality characteristic,
but a relational characteristic would make no sense.
Sep 20 2003
prev sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bkfejk$27cl$3 digitaldaemon.com>, Walter wrote:

 
 "Jeroen van Bemmel" <someone somewhere.com> wrote in message
 news:bkfcts$238q$1 digitaldaemon.com...

 Walter,

 In http://www.digitalmars.com/d/operatoroverloading.html surely the


 boolean

 comparison operators <, >, <= and >= are not commutative?


 
 Sure they are!
     a < b
 and
     b > a


The mathematical term would be "anticommutative".

"An operator * for which

a * b = -b * a

is said to be anticommutative"

http://mathworld.wolfram.com/Anticommutative.html

-Antti
Sep 21 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnbmr5a2.qqp.jsykari pulu.hut.fi...

 The mathematical term would be "anticommutative".

 "An operator * for which

 a * b = -b * a

 is said to be anticommutative"

 http://mathworld.wolfram.com/Anticommutative.html


I didn't know that! Thanks for the pointer.
Sep 21 2003
next sibling parent reply Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:

 "Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
 news:slrnbmr5a2.qqp.jsykari pulu.hut.fi...
 

The mathematical term would be "anticommutative".

"An operator * for which

a * b = -b * a

is said to be anticommutative"

http://mathworld.wolfram.com/Anticommutative.html


 
 
 I didn't know that! Thanks for the pointer.
 
 


isn't that -... realy the inverse of ... for op *

and is it
a * b = inv(b) * a
or is it  a * b = inv (b*a)
(the latter is true for subtraction and division)
Sep 21 2003
parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bkkt1b$112p$1 digitaldaemon.com>, Mike Wynn wrote:

 Walter wrote:

 "Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
 news:slrnbmr5a2.qqp.jsykari pulu.hut.fi...
 

The mathematical term would be "anticommutative".

"An operator * for which

a * b = -b * a

is said to be anticommutative"

http://mathworld.wolfram.com/Anticommutative.html






It seems I was kind of tired when I posted that (not that the
situationis much better now). On the second thought, the term does not
apply. I recall We were having a < b == b > a and here < and > are
different operators (relations, actually) but the anticommutativity only
talks about one. And still it wouldn't work, except in some weird
boolean algebra where "-" means not and where "a = b" never holds.  What
is anticommutative, though, is the cmp() function.


 I didn't know that! Thanks for the pointer.
 
 


 
 isn't that -... realy the inverse of ... for op *
 
 and is it
 a * b = inv(b) * a
 or is it  a * b = inv (b*a)
 (the latter is true for subtraction and division)


With subtraction and division, the operator just makes its right side
into its inverse under the operation and then does the normal operation
(addition for -, multiplication for /). So at least the latter identity
is true (at least as long if the normal operation commutes). But I think
we're talking about a pretty thin abstraction here, if you can use the
term in mathematics. Something that can be derived from the ring axioms
(or was it something less than that? Semi-ring? Group? Too tired for
that..)

(Anticommutativity might be more interesting... interestingly, the
keyword finds only two pages in MathWorld, Lagrange Brackets and Poisson
Brackets.  Stuff that I recall having studied once at the theoretical
physics course)

-Antti
Sep 21 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bkkqg3$tjd$2 digitaldaemon.com...

 "Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
 news:slrnbmr5a2.qqp.jsykari pulu.hut.fi...

 The mathematical term would be "anticommutative".

 "An operator * for which

 a * b = -b * a

 is said to be anticommutative"

 http://mathworld.wolfram.com/Anticommutative.html


 I didn't know that! Thanks for the pointer.


There is actually some really important cool stuff that depends on
anticommutativity.  Geometric algebra is based on it.  So any optimizations
you do on operator * like swapping the inputs is going to cause problems
with people trying to use operator * to implement say, geometric product,
which is anticommutative.  We either need another operator or even better
would be the ability to specify the behavior of the operators as we overload
them.  precedence, associativity, fixity, commutativity, etc.

Sean
Sep 22 2003
prev sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Antti Sykäri" <jsykari gamma.hut.fi> escreveu na mensagem
news:slrnbmr5a2.qqp.jsykari pulu.hut.fi...

 In article <bkfejk$27cl$3 digitaldaemon.com>, Walter wrote:

 "Jeroen van Bemmel" <someone somewhere.com> wrote in message
 news:bkfcts$238q$1 digitaldaemon.com...

 Walter,

 In http://www.digitalmars.com/d/operatoroverloading.html surely the


 boolean

 comparison operators <, >, <= and >= are not commutative?


 Sure they are!
     a < b
 and
     b > a


 The mathematical term would be "anticommutative".

 "An operator * for which

 a * b = -b * a

 is said to be anticommutative"

 http://mathworld.wolfram.com/Anticommutative.html

 -Antti



Hmmm, I think the correct definition would be "antisymmetric", for the cmp
operation. We can just assume cmp behaving as a infinite matrix and the
parameters are the possible indices (or something like that ;)

http://mathworld.wolfram.com/Antisymmetric.html


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 18/9/2003
Sep 21 2003
parent Felix <Felix_member pathlink.com> writes:
AFAIK:

< and > are not ordinal operators, are strict ordinal operators.

The right term for <= and >= is "antisimetric" ( OK, with bad english )
i.e.:

a<=b AND b<=a => a=b (necessarily).

So, an op is antisimetric if "a OP b" and "b OP a" involves "a=b"



In article <bklaa0$1iue$1 digitaldaemon.com>, Daniel Yokomiso says...

"Antti Sykäri" <jsykari gamma.hut.fi> escreveu na mensagem
news:slrnbmr5a2.qqp.jsykari pulu.hut.fi...

 In article <bkfejk$27cl$3 digitaldaemon.com>, Walter wrote:

 "Jeroen van Bemmel" <someone somewhere.com> wrote in message
 news:bkfcts$238q$1 digitaldaemon.com...

 Walter,

 In http://www.digitalmars.com/d/operatoroverloading.html surely the


 boolean

 comparison operators <, >, <= and >= are not commutative?


 Sure they are!
     a < b
 and
     b > a


 The mathematical term would be "anticommutative".

 "An operator * for which

 a * b = -b * a

 is said to be anticommutative"

 http://mathworld.wolfram.com/Anticommutative.html

 -Antti



Hmmm, I think the correct definition would be "antisymmetric", for the cmp
operation. We can just assume cmp behaving as a infinite matrix and the
parameters are the possible indices (or something like that ;)

http://mathworld.wolfram.com/Antisymmetric.html


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.520 / Virus Database: 318 - Release Date: 18/9/2003
Sep 21 2003
prev sibling next sibling parent Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:

 Some long awaited features.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 


switch to wchar still has this bug on linux.
/usr/lib/libphobos.a and /etc/dmd.conf updated to those in the 0.73 zip

[mike localhost tests]$ ~/dmd/bin/dmd
Digital Mars D Compiler v0.73
Copyright (c) 1999-2003 by Digital Mars written by Walter Bright
.....
[mike localhost tests]$ ~/dmd/bin/dmd -I~/dmd/src/phobos/ wcharswitch.d
gcc wcharswitch.o -o wcharswitch -lphobos -lpthread -lm
[mike localhost tests]$ ./wcharswitch
switch to default(not afoo or name)
tmp[0..4]:
tmp[0] = 'n'(110)
tmp[1] = 'a'(97)
tmp[2] = 'm'(109)
tmp[3] = 'e'(101)
[mike localhost tests]$ cat wcharswitch.d
import c.stdio;

wchar[] getName() {
         return "name";
}

int main(char[][] args ) {
         wchar[] tmp = getName(); //getFoo().value;
         switch( tmp ) {
         case "name":
                 printf("switch to name\n");
                 break;
         case "afoo": printf("switch to afoo\n"); break;
         default:
                 printf("switch to default(not afoo or name)\n");
                 printf("tmp[0..%d]:\n", tmp.length);
                 for( int i = 0; i < tmp.length; i++ ) {
                         printf("tmp[%d] = '%c'(%d)\n", i, 
cast(char)tmp[i], cast(int)tmp[i] );
                 }
                 break;
         }
         return 0;
}
[mike localhost tests]$
Sep 19 2003
prev sibling next sibling parent Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:

 Some long awaited features.
 
 http://www.digitalmars.com/d/changelog.html
 


is this the "correct" responce from D ?

class A {
	int tag;
	this( int tag0 ) { tag = tag0; }
	void dump() { printf("A:%d\n", tag); }
}
class C : A {
	int tagw;
	this( int tag0 ) { super( tag0+100);tagw = tag0; }
	void dump() { printf("C:%d\n", tagw); }
}

class B {
	 this() { }
	 A add( B b ) { return new A(3); }
	 A add( D b ) { return new A(2); }
}

class D : B {
	 this() { }
	 C add( B b ) { return new C(4); }
	 C add( D b ) { return new C(5); }
}


int main( char[][] argv ) {
	D d = new D();
	B b = d;
	A a;
	a = b + b;
	a.dump();
	a = b + d;
	a.dump();
	a = d + d;
	a.dump();
	a = d + b;
	a.dump();
	
	return 1;
}
---- output ----
C:4
C:5
C:5
C:4

------------------ test 2 -----------------

class A {
	int tag;
	this( int tag0 ) { tag = tag0; }
	void dump() { printf("A:%d\n", tag); }
}
class C : A {
	int tagw;
	this( int tag0 ) { super( tag0+100);tagw = tag0; }
	void dump() { printf("C:%d\n", tagw); }
}

class B {
	 this() { }
	 A add( B b ) { return new A(3); }
//	 A add( D b ) { return new A(2); }
}

class D : B {
	 this() { }
	 C add( B b ) { return new C(4); }
	 C add( D b ) { return new C(5); }
}


int main( char[][] argv ) {
	D d = new D();
	B b = d;
	A a;
	a = b + b;
	a.dump();
	a = b + d;
	a.dump();
	a = d + d;
	a.dump();
	a = d + b;
	a.dump();
	
	return 1;
}
-------------- op -----------------
C:4
C:4
C:5
C:4
---------------- test 3 --------------
class B {
	 this() { }
	 A add( B b ) { return new A(3); }
//	 A add( D b ) { return new A(2); }
}

class D : B {
	 this() { }
//	 C add( B b ) { return new C(4); }
	 C add( D b ) { return new C(5); }
}

will not compile all +'s :

 opvl.d(36): function add (D b) does not match argument types (B )


that is the line a = d + b;
----------------- test 3a ---------------

class A {
	int tag;
	this( int tag0 ) { tag = tag0; }
	void dump() { printf("A:%d\n", tag); }
}
class C : A {
	int tagw;
	this( int tag0 ) { super( tag0+100);tagw = tag0; }
	void dump() { printf("C:%d\n", tagw); }
}

class B {
	 this() { }
	 A add( B b ) { return new A(3); }
//	 A add( D b ) { return new A(2); }
}

class D : B {
	 this() { }
//	 C add( B b ) { return new C(4); }
	 C add( D b ) { return new C(5); }
}


int main( char[][] argv ) {
	D d = new D();
	B b = d;
	A a;
	a = b + b;
	a.dump();
	a = b + d;
	a.dump();
	a = d + d;
	a.dump();
//	a = d + b;
//	a.dump();
	
	return 1;
}
-------op----

 A:3
 A:3
 C:5
Sep 19 2003
prev sibling next sibling parent Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:

 Some long awaited features.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 


why is opIndex( T idx ) only?

Basic uses () for array indexing .... you can fake it all with
opCall ....
and by returning a T* allow read/write
as in this simple 2d array class ...

not sure if opIndex is redundant or if it should allow multipul indexors

import c.stdio;

class B {
	int[] data;
	int lw;
	 this( int xw, int yw ) { lw = xw; data=new int[xw*yw]; }
	 int[] opCall( int y ) { return this[y]; }
	 int *  opCall( int x, int y ) { return &data[(y*lw)+x]; }
	 int[] opIndex( int y ) { return data[(y*lw)..((y*lw)+lw)]; }
	void dump() {
		printf( "data [" ); foreach( int v; data ) { printf( "%d, ", v ); }
		printf( "]\n" );
	}
}

int main( char[][] argv ) {
	B b = new B( 2, 2 );
	int[] ar = b[0];
	printf("ar.length:%d\n", ar.length);
	ar[0] = 1; ar[1] = 2;
	*(b(1,1)) =3;
	*(b(0,1)) =-4;
	b.dump();
	
	return 1;
}

--------- however the old slice append overrunn bug/feature occurs ---
int main( char[][] argv ) {
	B b = new B( 2, 2 );
	int[] ar = b[0];
	printf("ar.length:%d\n", ar.length);
	ar[0] = 1; ar[1] = 2;
	*(b(1,1)) =3;
	*(b(0,1)) =-4;
	b.dump();
	ar ~= 100;
	b.dump();
	
	return 1;
}

outputs

 ar.length:2
 data [1, 2, -4, 3, ]
 data [1, 2, 100, 3, ]
Sep 19 2003
prev sibling next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
Bug:

What was

    foreach(Value value; key.propget_Values())

is now

    foreach(Value value; key.Values)

Looks nice. Doesn't compile. :(

    "win32_reg_test.d(15): foreach: ValueSequence () is not an aggregate
type"

It works ok if I change the code to

    ValueSequence values = key.Values;

    foreach(Value value; values)

but that spoils the fun a little. :)

This is not a great emergency, since the above workaround is eminently
reasonable. However, it'd be good if it could be fixed in 0.74



"Walter" <walter digitalmars.com> wrote in message
news:bked8d$2pe5$1 digitaldaemon.com...

 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html
Sep 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgin8$2hs0$1 digitaldaemon.com...

 This is not a great emergency, since the above workaround is eminently
 reasonable. However, it'd be good if it could be fixed in 0.74


No problem. I expect problems like that to crop up on the first try at a
great new feature!
Sep 19 2003
parent "Matthew Wilson" <matthew stlsoft.org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bkgnd2$cd$2 digitaldaemon.com...

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkgin8$2hs0$1 digitaldaemon.com...

 This is not a great emergency, since the above workaround is eminently
 reasonable. However, it'd be good if it could be fixed in 0.74


 No problem. I expect problems like that to crop up on the first try at a
 great new feature!


Even if you do say so yourself, arf arf. :) (You're right, however)
Sep 19 2003
prev sibling next sibling parent reply Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:

 Some long awaited features.
 
 http://www.digitalmars.com/d/changelog.html
 


is it just me or is int opSlice() pointless ?
  I've written a copy on extend slice class but howcan I write the 
overloaded operator to allow
a[]=b[]; to work as it does for arrays
there is no operator =/assign

this simple addition would allow opIndex to return a "ref" class
(although does require operator toType/cast to allow
template lists(T) {
	class ref {
		T* ptr;
		this( T* ptr0 ) { ptr = ptr0; }
		operator T { return *ptr; }
		operator = ( T v ) { *ptr = v; }
	}
	class vector {
		T[] data;
		this( int len ) { data = new T[len]; }
		ref opIndex( int i ) { return new ref( &t[i] ); }
	}
	
}
instance lists(int).vector ar =
	new instance lists(int).vector(3);
int a = ar[2];
ar[1] = 33;

as overloading
int * opCall( int i ) { return &t[i]; }
does not allow detection of writes
Sep 19 2003
next sibling parent Mike Wynn <mike l8night.co.uk> writes:
Mike Wynn wrote:

 Walter wrote:
 

 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html


 
 is it just me or is int opSlice() pointless ?
  I've written a copy on extend slice class but howcan I write the 
 overloaded operator to allow
 a[]=b[]; to work as it does for arrays
 there is no operator =/assign
 
 this simple addition would allow opIndex to return a "ref" class
 (although does require operator toType/cast to allow
 template lists(T) {
     class ref {
         T* ptr;
         this( T* ptr0 ) { ptr = ptr0; }
         operator T { return *ptr; }
         operator = ( T v ) { *ptr = v; }
     }
     class vector {
         T[] data;
         this( int len ) { data = new T[len]; }
         ref opIndex( int i ) { return new ref( &t[i] ); }
     }
     
 }
 instance lists(int).vector ar =
     new instance lists(int).vector(3);
 int a = ar[2];
 ar[1] = 33;
 
 as overloading
 int * opCall( int i ) { return &t[i]; }
 does not allow detection of writes
 


forgot .. this was as far as my experiment went ...


import c.stdio;
template Coe( T ) {
	class Block {
		T[] slice;
		bit copyneeded;
		this( T[] from ) { slice = from; copyneeded = true; }
		T opCall( int i ) { return slice[i]; }
		T opIndex( int i ) { return slice[i]; }
		T opIndex( int i, T v ) { return (slice[i] = v); }
		void catass( T v ) {
			if ( copyneeded ) {
				slice = slice.dup;
				copyneeded = false;
			}
			slice ~= v;
		}
		int length() { return slice.length; }
		int apply( int delegate( inout T ) func ){
			foreach( inout T t; slice ) {
				int i;
				i = func( t );
				if ( i ) { return i; }
			}
			return 0;
		}
	}
}
class B {
	alias instance Coe( int ).Block BA;
	int[] data;
	int lw;
	 this( int xw, int yw ) { lw = xw; data=new int[xw*yw]; }
	 BA opCall( int y ) { return this[y]; }
//	 int   opCall( int x, int y ) { return this[y][x]; }
	 int *  opCall( int x, int y ) { return &data[(y*lw)+x]; }
	 BA opIndex( int y ) { return new BA(data[(y*lw)..((y*lw)+lw)]); }
	void dump() {
		printf( "data [" ); foreach( int v; data ) { printf( "%d, ", v ); }
		printf( "]\n" );
	}
}



int main( char[][] argv ) {
	B b = new B( 2, 2 );
	B.BA ar = b[0];
	printf("ar.length:%d\n", ar.length);
	ar[0] = 1; ar[1] = 2;
	*(b(1,1)) =3;
	*(b(0,1)) =-4;
	b.dump();
	ar ~= 100;
	b.dump();
	printf( "ar[" );
	foreach( int i; ar ) { printf( "%d, ", i ); }
	printf( "]\n" );
	
	return 1;
}
Sep 19 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bkgk91$2nvf$1 digitaldaemon.com...

 Walter wrote:

 Some long awaited features.

 http://www.digitalmars.com/d/changelog.html


 is it just me or is int opSlice() pointless ?
   I've written a copy on extend slice class but howcan I write the
 overloaded operator to allow
 a[]=b[]; to work as it does for arrays
 there is no operator =/assign


Looks like I need to add something for that here.
Sep 19 2003
prev sibling next sibling parent Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:

 Some long awaited features.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 


the following code will create
Internal error: e2ir.c 721
Linux (RH9) dmd 0.73

/*
  *
  */
import c.stdio;
import object;
import utf;

const char[] OP_NEGATE = "-";

class BaseOperand {
	alias BaseOperand function( BaseOperand ) unaryop;
	static void register_unary_operation( char[] op, unaryop unop, 
ClassInfo a_ci ) {
	}
}

class A : BaseOperand {
	int val;
	this( int v0 ) { val = v0; }
	static BaseOperand operator_negate( BaseOperand a ) {
		return null;
	}
	static this() {
		register_unary_operation( OP_NEGATE, &operator_negate, A.classinfo );
	}
}

class B : A {
	this( int v0 ) { super( v0 ); }
	static BaseOperand operator_negate( BaseOperand a ) {
		return null;
	}
	static this() {
		register_unary_operation( OP_NEGATE, &operator_negate, A.classinfo );
// compiles if the above line is changed		
//		register_unary_operation( OP_NEGATE, &operator_negate, B.classinfo );
	}
}

int main( char[][] args ) {
	BaseOperand a;
	a = new A(2);
	return 0;
}
Sep 20 2003
prev sibling next sibling parent Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:

 Some long awaited features.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 


Linux (RH9) dmd 0.73

multipul static function def's not detected until link time

-------------
[mike localhost oper]$ ~/dmd/bin/dmd -I~/dmd/src/phobos/ test2.d
gcc test2.o -o test2 -lphobos -lpthread -lm
test2.o(.gnu.linkonce.t_D5test21B15operator_negateFC5test211BaseOperandZC5test
11BaseOperand+0x8): 
In function 
`_D5test21B15operator_negateFC5test211BaseOperandZC5test211BaseOperand':
: multiple definition of 
`_D5test21B15operator_negateFC5test211BaseOperandZC5test211BaseOperand'
test2.o(.gnu.linkonce.t_D5test21B15operator_negateFC5test211BaseOperandZC5test
11BaseOperand+0x0): 
first defined here
collect2: ld returned 1 exit status
--- errorlevel 256

-------------

/*
  *
  */
import c.stdio;
import object;
import utf;

const char[] OP_NEGATE = "-";

class BaseOperand {
	alias BaseOperand function( BaseOperand ) unaryop;
	static void register_unary_operation( char[] op, unaryop unop, 
ClassInfo a_ci ) {
	}
}

class A : BaseOperand {
	int val;
	this( int v0 ) { val = v0; }
	static BaseOperand operator_negate( BaseOperand a ) {
		return null;
	}
	static this() {
		register_unary_operation( OP_NEGATE, &operator_negate, A.classinfo );
	}
}

class B : A {
	this( int v0 ) { super( v0 ); }
	static BaseOperand operator_negate( BaseOperand a ) {
		return null;
	}
	static BaseOperand operator_negate( BaseOperand a ) {
		return null;
	}
	static this() {
//		register_unary_operation( OP_NEGATE, &operator_negate, A.classinfo );
		register_unary_operation( OP_NEGATE, &operator_negate, B.classinfo );
	}
}

int main( char[][] args ) {
	BaseOperand a,b;
	a = new A(2);
	b = new B(3);
	return 0;
}
Sep 20 2003
prev sibling parent Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:

 Some long awaited features.
 
 http://www.digitalmars.com/d/changelog.html
 
 
 


(linux (RH9)) dmd 0.73
class A { }; class B : A {}
for some reason within B A.classinfo is B.classinfo (rather a problem ....)

--- result: ----------------
registering op[-]class[A]
registering op[-]class[B]
registering op[(a)]class[B]

--- code: ---
/*
  *
  */
import c.stdio;
import object;
import utf;

const char[] OP_NEGATE = "-";

class BaseOperand {
	alias BaseOperand function( BaseOperand ) unaryop;
	static void register_unary_operation( char[] op, unaryop unop, 
ClassInfo a_ci ) {
		printf("registering op[%.*s]class[%.*s]\n", op, a_ci.name );
	}
}

class A : BaseOperand {
	int val;
	this( int v0 ) { val = v0; }
	static BaseOperand operator_negate( BaseOperand a ) {
		return null;
	}
	static this() {
		register_unary_operation( OP_NEGATE, &operator_negate, A.classinfo );
	}
}

class B : A {
	this( int v0 ) { super( v0 ); }
	static BaseOperand operator_negate( BaseOperand a ) {
		return null;
	}
	static this() {
//		register_unary_operation( OP_NEGATE, &operator_negate, A.classinfo );
		register_unary_operation( OP_NEGATE, &operator_negate, B.classinfo );
		(new B(10)).bodge_it();
	}
	void bodge_it() {
		register_unary_operation( "(a)", &operator_negate, A.classinfo );
	}
}

int main( char[][] args ) {
	BaseOperand a,b;
	a = new A(2);
	b = new B(3);
	return 0;
}
Sep 20 2003