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


binary,

 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


is

 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


 binary,

 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.


 Yep, but 10b is shorter and sometimes prettier.




 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.


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.


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




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!


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


float

 to single precision but the formula requires double precision.


Effectively the

 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


precision of

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


floating

 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


feedback on

 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