These are some weird error messages I've gotten that could probably make more sense if changed, and also a few things that could possibly use tweaking (and issues with calling overloaded functions, apparently):

'yearStr.length' is not an lvalue

Got that one from trying to do somearray.length+=1; (or -=, etc)
So I had to do somearray.length=somearray.length+1; instead, which is not too much of a hassle, but is weird. Also note that there was no filename or line # given in that error message, and it doesn't exactly make sense to someone who doesn't know what an lvalue is (AFAIK it's something that can be on the left hand side of an =, which somearray.length SHOULD be, I would think) or thinks it IS an lvalue and the compiler is wrong. So it's not exactly easy to track down and figure out (the first time you get it anyways, after that you know what to look for).

spacesim.d(205): Array operations not implemented

I got that one when I tried doing someString+someOtherString. I had momentarily forgotten I was supposed to use ~, and it took me a few seconds to figure out what the problem was, because the error message looked like something totally different. A clearer message, such as "Use the ~ operator to concatenate strings, not +" would help when (inevitably) people try to use + with strings.

Also, toString(someNumberTypeHere) doesn't work when trying to use it from a class which has a toString() method.
webinterface.d(110): function toString () does not match argument types (uint)

As a temporary solution I declared the following:
char[] toAString(int i) {
	return toString(i);
}
char[] realToString(real i) {
	return toString(i);
}

and used those instead, but IMHO the compiler should still look at global symbols if a local symbol matches the name but not the arguments.

By the way, the reason those have different names is because DMD gets confused if they're the same...

char[] toAString(int i) {
	return toString(i);
}
char[] toAString(real i) {
	return toString(i);
}
real mass;
toAString(mass);

webinterface.d(110): function toAString overloads char[](int i) and char[](real i) both match argument list for toAString

I'd think it would go for toAString(real) since the argument is actually a real, but it doesn't! It just refuses to compile, heh.

Also, something similar...

real mass;
int orbit;
real sunHU;
this.getHE=mass*sunHU*(1/(pow(pow(1.9,orbit),2)));
Doesn't work.

spacesim.d(206): function pow overloads real(real x,uint n) and real(real x,real y) both match argument list for pow

So I figured, hey, I'll just cast orbit to a uint and it should know what to do.

this.getHE=mass*sunHU*(1/(pow(pow(1.9,(uint)orbit),2)));

But it still doesn't work (and gives the same error message).

So I tried casting it to a real.
this.getHE=mass*sunHU*(1/(pow(pow(1.9,(real)orbit),2)));

That one worked (Go figure), but the thing is, I really wanted it to call the uint one, because if it's calling the real one, it's not checking for the special-cases that can be done faster (0, 1, and 2).

Oddly, the outer pow doesn't get confused. Its first parameter is still a real and the outer one is some form of int - but maybe it works because it's a constant. Hm.

Well, that's all for now.

-SL

Comments embedded.

In article <c3s7nd$2kvs$1@digitaldaemon.com>, SL says...
>
>These are some weird error messages I've gotten that could probably make more sense if changed, and also a few things that could possibly use tweaking (and issues with calling overloaded functions, apparently):
>
>'yearStr.length' is not an lvalue
>
>Got that one from trying to do somearray.length+=1; (or -=, etc)
>So I had to do somearray.length=somearray.length+1; instead, which is
>not too much of a hassle, but is weird. Also note that there was no
>filename or line # given in that error message, and it doesn't exactly
>make sense to someone who doesn't know what an lvalue is (AFAIK it's
>something that can be on the left hand side of an =, which
>somearray.length SHOULD be, I would think) or thinks it IS an lvalue and
>the compiler is wrong. So it's not exactly easy to track down and figure
>out (the first time you get it anyways, after that you know what to look
>for).
>

This is on purpose. You can't change the length of an array that way.
About the error messages, you're right. But I believe Walter is trying to make
improvements there.

> ...
>Also, toString(someNumberTypeHere) doesn't work when trying to use it
>from a class which has a toString() method.
>webinterface.d(110): function toString () does not match argument types
>(uint)
>
>As a temporary solution I declared the following:
>char[] toAString(int i) {
>	return toString(i);
>}
>char[] realToString(real i) {
>	return toString(i);
>}
>
>and used those instead, but IMHO the compiler should still look at global symbols if a local symbol matches the name but not the arguments.
>

Use .toString(someNumberTypeHere) instead (notice the dot).

>...

-------------------
Carlos Santander B.

SL wrote:

> These are some weird error messages I've gotten that could probably make more sense if changed, and also a few things that could possibly use tweaking (and issues with calling overloaded functions, apparently):
>
> 'yearStr.length' is not an lvalue
>
> Got that one from trying to do somearray.length+=1; (or -=, etc)


I believe, Walter's main reason against banning (++,--,+=,-=) is that it's inefficient to increment one value at a time (although the += could be used for more then once value :( ).  Generally when you adding one value you might as well use ~=.  It's also the same with pointers.  If you need to add a lot of elements it should be done outside the loop or in blocks as nessary.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:
> I believe, Walter's main reason against banning (++,--,+=,-=) is that it's inefficient to increment one value at a time (although the += could be used for more then once value :( ).  Generally when you adding one value you might as well use ~=.  It's also the same with pointers.  If you need to add a lot of elements it should be done outside the loop or in blocks as nessary.
> 

If that was the goal, it didn't really stop me from doing it inefficiently. Heh. In any case, I wanted to prototype it fast, so I didn't bother with having a separate int numReports and resizing the array by large amounts only rarely, which is what I'd normally do.

I thought ~ and ~= only worked with strings? (This is an array of strings (char[][]) and I'm resizing the array, not individual strings)

SL wrote:

> J Anderson wrote:
>
>> I believe, Walter's main reason against banning (++,--,+=,-=) is that it's inefficient to increment one value at a time (although the += could be used for more then once value :( ).  Generally when you adding one value you might as well use ~=.  It's also the same with pointers.  If you need to add a lot of elements it should be done outside the loop or in blocks as nessary.
>>
>
> If that was the goal, it didn't really stop me from doing it inefficiently. 

It does not stop you but It's kinda like a warning.  I think it mostly applies to ++ which only ever increments by one.

> Heh. In any case, I wanted to prototype it fast, so I didn't bother with having a separate int numReports and resizing the array by large amounts only rarely, which is what I'd normally do.
>
> I thought ~ and ~= only worked with strings? (This is an array of strings (char[][]) and I'm resizing the array, not individual strings)

There is nothing different from char arrays to any other array, except that char arrays are treated as strings by convention.

-- 
-Anderson: http://badmama.com.au/~anderson/

SL wrote:
> These are some weird error messages I've gotten that could probably make more sense if changed, and also a few things that could possibly use tweaking (and issues with calling overloaded functions, apparently):
> 
> 'yearStr.length' is not an lvalue

I'm not a big fan of this error message either (maybe it should say "Can't '++' length"), but what really slowed me down was the lack of a line number. (That's why I posted an error report on it: http://www.digitalmars.com/drn-bin/wwwnews?D/25540.)

-- 
Justin
http://jcc_7.tripod.com/d/

SL wrote:

> These are some weird error messages I've gotten that could probably make more sense if changed, and also a few things that could possibly use tweaking (and issues with calling overloaded functions, apparently):
> 
> 'yearStr.length' is not an lvalue
> 
> Got that one from trying to do somearray.length+=1; (or -=, etc)
> So I had to do somearray.length=somearray.length+1; instead, which is not too much of a hassle, but is weird. Also note that there was no filename or line # given in that error message, and it doesn't exactly make sense to someone who doesn't know what an lvalue is (AFAIK it's something that can be on the left hand side of an =, which somearray.length SHOULD be, I would think)
<snip>

I think DMD has redefined it to mean something that can be on the LHS of a ++, -- or op=.  Of course, that's before you get to classes that may have none, some or all of them defined....

> spacesim.d(205): Array operations not implemented
> 
> I got that one when I tried doing someString+someOtherString. I had momentarily forgotten I was supposed to use ~, and it took me a few seconds to figure out what the problem was, because the error message looked like something totally different. A clearer message, such as "Use the ~ operator to concatenate strings, not +" would help when (inevitably) people try to use + with strings.

What if someone really is trying to do vector arithmetic on strings, e.g. when implementing a Vigenère cipher?

> Also, toString(someNumberTypeHere) doesn't work when trying to use it from a class which has a toString() method.
> webinterface.d(110): function toString () does not match argument types (uint)

You need to override the scope inference by either the fully qualified name (std.string.toString) or simply a dot prefix (.toString).

Presumably it assumes that you're trying to access a method within the class, but have misremembered or mistyped the argument list.

<snip>
> char[] toAString(int i) {
>     return toString(i);
> }
> char[] toAString(real i) {
>     return toString(i);
> }
> real mass;
> toAString(mass);
> 
> webinterface.d(110): function toAString overloads char[](int i) and char[](real i) both match argument list for toAString
> 
> I'd think it would go for toAString(real) since the argument is actually a real, but it doesn't! It just refuses to compile, heh.

You're right, there does seem to be a bug there.

> Also, something similar...
> 
> real mass;
> int orbit;
> real sunHU;
> this.getHE=mass*sunHU*(1/(pow(pow(1.9,orbit),2)));
> Doesn't work.
> 
> spacesim.d(206): function pow overloads real(real x,uint n) and real(real x,real y) both match argument list for pow

That's in the spec:

"In D, function overloading is simple. It matches exactly, it matches with implicit conversions, or it does not match. If there is more than one match, it is an error."

Matches are (real, uint) and (real, real).  You call it by (double, uint).  Neither matches exactly, so it tries to match by implicit conversions.  But since both match, it fails.

<snip>
> So I tried casting it to a real.
> this.getHE=mass*sunHU*(1/(pow(pow(1.9,(real)orbit),2)));
> 
> That one worked (Go figure), but the thing is, I really wanted it to call the uint one, because if it's calling the real one, it's not checking for the special-cases that can be done faster (0, 1, and 2).

	pow(1.9L, cast(uint) orbit)

IINM, the L creates a real literal.

> Oddly, the outer pow doesn't get confused. Its first parameter is still a real and the outer one is some form of int - but maybe it works because it's a constant. Hm.

Good question.  Maybe there's a bug here, or maybe there's an undocumented feature meaning that an int literal can be treated as a uint if it disambiguates.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.