View mode: basic / threaded / horizontal-split · Log in · Help
September 20, 2003
Re: DMD 0.73 release
"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)
September 20, 2003
Re: operator overloading philosophy
"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>.
September 20, 2003
Re: DMD 0.73 release
> 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)
September 20, 2003
Re: DMD 0.73 release
> 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)
September 20, 2003
Re: DMD 0.73 release (Internal error: e2ir.c 721)
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;
}
September 20, 2003
Re: DMD 0.73 release
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_negateFC5test211BaseOperandZC5test211BaseOperand+0x8): 
In function 
`_D5test21B15operator_negateFC5test211BaseOperandZC5test211BaseOperand':
: multiple definition of 
`_D5test21B15operator_negateFC5test211BaseOperandZC5test211BaseOperand'
test2.o(.gnu.linkonce.t_D5test21B15operator_negateFC5test211BaseOperandZC5test211BaseOperand+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;
}
September 20, 2003
Re: DMD 0.73 release (incorrect ClassInfo)
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;
}
September 20, 2003
Re: DMD 0.73 release
"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
September 20, 2003
Re: operator overloading philosophy
"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
September 20, 2003
Re: operator overloading philosophy
"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
1 2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home