literals

[so]

I don't think it is that complex, if it is please point me.
It is simple math.

"3" the number belongs to many number systems.
Making default int (actually "signed int") is the source of complexity,  
same goes for "0.3".

For function overload case:

foo(float)
foo(double)
foo(real)

If i call the overloaded functions above with foo(0.3),
since i haven't explicitly stated (in C world, i explicitly stated it is  
double) which function i refer,
it is my fault, compiler should warn/error or give me the highest  
precision available, you name it.
The reason might be compatibility but i am unable to see any efficiency  
there.

What i want is simple, in a generic code, which in this case a template,
i should be able to write the code below with "zero" implicit casts.

T inv(T m)() {
	return 1.0 / m;
}

What do you see in this code? What the user wants?
User explicitly stated that he wants "1.0" in the type of T.
So when "T" is float, give the float version of "1.0".
If i am not mistaken, this is actually how constant folding actually  
works, see the page.

Thanks.

On Sun, 28 Mar 2010 17:20:41 +0400, Fawzi Mohamed <fawzi at gmx.ch> wrote:

> no the answer is more complex:
> for integers normally the smallest possible integral type is used (but  
> not exactly int wins in some occasions, check the exact rules) and then  
> implicit conversion can take place.
> The rules are such that it should do what one means most times (so  
> conversion to long or uint is ok), but there are some pitfalls, often  
> associated to conversion to unsigned (that I find useful though, even if  
> it can lead to bugs in some occasions, and there are some reasons to  
> like infinite integers as some languages have).
> Still if you write a very large number it is a long for example.
>
> floating point numbers are a bit different (because they are always  
> approximated), but the philosophy is similar.
>
> The absence polysemus literals is not a problem in my opinion, you can  
> avoid that having good implicit casting rules.
>
> unexpected results normally happen just when you have something very  
> ambiguous.
> For example if you have an overloaded function and you call it with a  
> literal then in *any* language you need to decide which default value  
> has the literal (to decide with which type to start before looking at  
> implicit conversions).
> D (like C) chooses int for for 3, and double for 0.3 (the latter I  
> suppose for C compatibility and efficiency reasons, because one could  
> argue that real would be a "safer" choice).
>
> Yes there are some dark corners, but I don't see things that make  
> generic programming impossible.
> Maybe if you would say what you try to do you would receive more  
> meaningful answers.
>
> Fawzi
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/