literals

[Fawzi Mohamed]

On 28-mar-10, at 14:48, so wrote:

> 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.

or give you the "default" precision. And note that this problem is not  
what you pointed out initially, but something I gave.

I don't see the same problem with signed int...

> The reason might be compatibility but i am unable to see any  
> efficiency there.

double occupies less space and can use SSE instructions.

> 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?

invalid code?

> What the user wants?

probably

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

> 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".

Integers are the only values that can be represented without any  
approximation (unless you resort to rationals, or inefficient  
representations that are probably ok only at compile time or in very  
specific applications).
So generic code should use integers, not floating points.
You might argue that the way to get a floating point literal of type T  
is ugly:
	cast(T)1.0
for example fortran uses 1.0_T, but one can definitely live with it,  
anyway normally you should use integers, generic floating point  
literals is not really something that is so well defined...

> 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/