www.digitalmars.com         C & C++   DMDScript  

D - calling overloaded functions

reply "Dario" <supdar yahoo.com> writes:
Look at the following:

typedef ubyte AAA;

class CLASS
{
 void func(AAA a, ubyte b) {}
 void func(byte a, ubyte b) {}

 void wrapper(AAA a) { func(a, 0); }
 void wrapper(byte a) { func(a, 0); }
}

It is quite clear to me, but it results in an ambiguity error.
If the func()s don't take a second argument, it is no longer ambiguous.
Maybe I'm missing something... or it is a bug in the compiler?
_________________________________

I'm going to suggest some new sintax to make overloading easier:
we have 'l' (long) and 'u' (unsigned) suffix to get long and unsigned
integers (e.g. '10ul').
Why not to have 's' (short) and 'b' (byte)?
I fear that they'll be misunderstood ('s' can mean signed and 'b' is binary,
according to assembly sintax).
They'll be useful though.
Sep 05 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Dario" <supdar yahoo.com> wrote in message
news:al7lnu$48m$1 digitaldaemon.com...
 Look at the following:

 typedef ubyte AAA;

 class CLASS
 {
  void func(AAA a, ubyte b) {}
  void func(byte a, ubyte b) {}

  void wrapper(AAA a) { func(a, 0); }
  void wrapper(byte a) { func(a, 0); }
 }

 It is quite clear to me, but it results in an ambiguity error.
 If the func()s don't take a second argument, it is no longer ambiguous.
 Maybe I'm missing something... or it is a bug in the compiler?

With overloading, D deliberately dispenses with the C++ idea of some type conversions being better than others. In D, there are 3 results from an overload compare: exact match, match with conversions, and no match. This is a reaction to C++'s rules being pages to express, and can get difficult to figure out when looking at multiple arguments.
 I'm going to suggest some new sintax to make overloading easier:
 we have 'l' (long) and 'u' (unsigned) suffix to get long and unsigned
 integers (e.g. '10ul').
 Why not to have 's' (short) and 'b' (byte)?
 I fear that they'll be misunderstood ('s' can mean signed and 'b' is

 according to assembly sintax).
 They'll be useful though.

The same result can be achieved with (short)s and (byte)b.
Sep 06 2002
parent reply "Dario" <supdar yahoo.com> writes:
 Look at the following:

 typedef ubyte AAA;

 class CLASS
 {
  void func(AAA a, ubyte b) {}
  void func(byte a, ubyte b) {}

  void wrapper(AAA a) { func(a, 0); }
  void wrapper(byte a) { func(a, 0); }
 }

 It is quite clear to me, but it results in an ambiguity error.
 If the func()s don't take a second argument, it is no longer ambiguous.
 Maybe I'm missing something... or it is a bug in the compiler?

With overloading, D deliberately dispenses with the C++ idea of some type conversions being better than others. In D, there are 3 results from an overload compare: exact match, match with conversions, and no match. This

 a reaction to C++'s rules being pages to express, and can get difficult to
 figure out when looking at multiple arguments.

I don't understand, are rules different when dealing with multiple arguments? In the example above, see the function void wrapper(AAA a) { func(a, 0); } It calls func(AAA,ubyte), and the arguments match exactly. So, there is no need to look for matches with conversions. So no ambiguity. Isn't this straightforward enough? Should the language rules say it's ambiguous?
 I'm going to suggest some new sintax to make overloading easier:
 we have 'l' (long) and 'u' (unsigned) suffix to get long and unsigned
 integers (e.g. '10ul').
 Why not to have 's' (short) and 'b' (byte)?
 I fear that they'll be misunderstood ('s' can mean signed and 'b' is

 according to assembly sintax).
 They'll be useful though.

The same result can be achieved with (short)s and (byte)b.

Yep, but 10b is shorter and sometimes prettier. I hate to be forced to write 'write(cast(byte) 0x66);' Doesn't 'write(0x66b);' look better. Maybe it's less visible but it doesn't need to be visible: in fact, when I write 0x66 I expect it to be 1 byte long since it has 2 digits. Anyway, we have 'l' and 'u', but we can also write (long)l and (uint)u. I think that casts to bytes are more frequent than casts to longs, aren't they? Just my humble opinions...
Sep 06 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Dario" <supdar yahoo.com> wrote in message
news:alb3r5$19uh$1 digitaldaemon.com...
 I don't understand, are rules different when dealing with multiple
 arguments?

No.
 In the example above, see the function
 void wrapper(AAA a) { func(a, 0); }
 It calls func(AAA,ubyte), and the arguments match exactly. So, there is no
 need to look for matches with conversions. So no ambiguity. Isn't this
 straightforward enough? Should the language rules say it's ambiguous?

No, they don't match exactly, as 0 is type int, not a byte.
 The same result can be achieved with (short)s and (byte)b.


 Anyway, we have 'l' and 'u', but we can also write (long)l and (uint)u.
 I think that casts to bytes are more frequent than casts to longs, aren't
 they?

I agree it's inconsistent, I never use those suffixes anyway <g>.
Sep 06 2002
parent reply Mark Evans <Mark_member pathlink.com> writes:
I agree it's inconsistent, I never use those suffixes anyway <g>.

Walter there should always be some way to specify the type of a constant. The 'L' suffix in certain C++ environments (to signify double-precision) is important in many applications. Define pi otherwise and you lose 6 significant digits in every computation. Maybe double{3.14159.....} or float(14) or some similar syntax? M.
Sep 06 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:albmkc$5j2$1 digitaldaemon.com...
 Walter there should always be some way to specify the type of a constant.

 'L' suffix in certain C++ environments (to signify double-precision) is
 important in many applications.  Define pi otherwise and you lose 6

 digits in every computation.

You're right, I forgot about that case.
 Maybe double{3.14159.....} or float(14) or some similar syntax?

It just seems unnecessary.
Sep 07 2002
parent reply Mark Evans <Mark_member pathlink.com> writes:
 Maybe double{3.14159.....} or float(14) or some similar syntax?

It just seems unnecessary.

Here's the necessity. In technical work one often writes code involving one-time conversion factors (that should be double precision or better). These factors depend heavily on the units involved and the particular formula expressed. They change often during development and sometimes disappear and reappear as the work proceeds. Consequently they should appear directly in the expression, not as stand-alone constants in some header file. This positioning localizes the issue of writing correct code and makes formulas easier to read. If I have a formula x = 123.4567890001 * y^2 + 9876.5432100001; That is much easier to read than x = my_special_one_time_conversion_factor_A34 * y^2 + my_special_one_time_constant_p54; The latter is the kind of monster created when the compiler defaults every float to single precision but the formula requires double precision. Effectively the user must work around the compiler's limitations. So in general it's a Good Thing to have some syntax to specify the precision of numeric constants. Lacking one, I would definitely argue that all floating point numeric constants should be double precision, not single. Perhaps some variation on the C-language 0x and 0b prefixes would work. I like the shorthand DBL and SGL myself. Thanks for listening Walter! I think it's great how you are getting feedback on the development of this new language...maybe a first in the history of computing. Mark
Sep 08 2002
next sibling parent reply Pavel Minayev <evilone omen.ru> writes:
Mark Evans wrote:

 So in general it's a Good Thing to have some syntax to specify the precision of
 numeric constants.  Lacking one, I would definitely argue that all floating
 point numeric constants should be double precision, not single.

AFAIK, both C++ and D treat no-suffix floating point constants as double!
Sep 08 2002
parent "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:alh5mc$18qv$1 digitaldaemon.com...
 Mark Evans wrote:

 So in general it's a Good Thing to have some syntax to specify the


 numeric constants.  Lacking one, I would definitely argue that all


 point numeric constants should be double precision, not single.

AFAIK, both C++ and D treat no-suffix floating point constants as double!

Yes, that's correct.
Sep 08 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:algcju$2l2m$1 digitaldaemon.com...
 The latter is the kind of monster created when the compiler defaults every

 to single precision but the formula requires double precision.

 user must work around the compiler's limitations.

What I do is cast one of the operands to double, that forces the whole expression to be done as a double.
 So in general it's a Good Thing to have some syntax to specify the

 numeric constants.  Lacking one, I would definitely argue that all

 point numeric constants should be double precision, not single.

The trouble is, the game programmers will object. They want the speed of all float computations.
 Thanks for listening Walter!  I think it's great how you are getting

 the development of this new language...maybe a first in the history of
 computing.

Actually, it's a lot of fun.
Sep 08 2002
prev sibling parent Pavel Minayev <evilone omen.ru> writes:
Dario wrote:

 I hate to be forced to write 'write(cast(byte) 0x66);'
 Doesn't 'write(0x66b);' look better.

Note that 0x66b is a valid hex number. "s" could be used for short, but "b" is already used...
Sep 07 2002