On 12/17/2013 08:24 PM, Sieghard wrote:
What's so special about abs? Nothing at all. It's simply a comparison ..
abs() looks like a function but in fact it isn't. So it's a very special
kind of function (at least it is similar to a set of overloaded
function or a kind of generic).
In Pascal
On 12/17/2013 08:24 PM, Sieghard wrote:
BUT: Does anybody _really_ think that type casting _does_ something?
In fact it does stuff like zero or sign extend or cut away high order bits.
-Michael
--
Rapidly troubleshoot
On 12/17/2013 06:52 PM, Martin Schreiber wrote:
integervar:= abs(integer(cardinalvalue));
but
for cardinalvalue = $
cardinalvalue = chard32 (abs(integer(cardinalvalue)));
would result in 1, while
cardinalvalue = abs (cardinalvalue) in fpc
would result in $
-Michel
abs() does not exist in C (you can of course do a simple #define macro
for that).
Not true. You can find it in stdlib.h
--
Julio Jiménez Borreguero
--
Rapidly troubleshoot problems before they affect your business.
On 12/17/2013 07:23 PM, Martin Schreiber wrote:
BTW, Free Pascal has no unsigned abs().
http://www.freepascal.org/docs-html/rtl/system/abs.html
Did anybody test what fpc really does for
cardinalvalue = abs (cardinalvalue); with cardinalvalue = $ ?
-Michael
On 12/18/2013 10:26 AM, Julio Jiménez wrote:
Not true. You can find it in stdlib.h
This is not C (language) but a library.
-Michael
--
Rapidly troubleshoot problems before they affect your business. Most IT
Yes.. of course ;) almost everything is in a library.. but it's standard
library. Abs in pascal is also in a library (System unit) is not part of
the language.. like almost every thing.
I'm not sure but probably stdlib.h is in every C implementation out there.
2013/12/18 Michael Schnell
On 12/18/2013 10:36 AM, Julio Jiménez wrote:
Abs in pascal is also in a library (System unit) is not part of the
language
Really ?
I had the impression that it is a compiler builtin.
-Michael
--
Rapidly
Really ?
I had the impression that it is a compiler builtin.
Probably I'm wrong in the concept. Compiled by default doesn't mean is part
of the language IMHO, you also can apply the same to abs in C language
stdlib.h
curious.. you can read http://www.freepascal.org/docs-html/rtl/system/
On 12/18/2013 10:52 AM, Julio Jiménez wrote:
You don't need to define abs in C, just use stdlib.h, this is what I
wanted to say.. :)
OK. But right now we are discussing concepts, not ease of use :-) .
-Michael
--
On 12/16/2013 03:58 PM, Martin Schreiber wrote:
unsigned:= card32(abs(signed));
This suggests that the result of abs is signed and need an explicit
conversion to unsigned.
I'm not sure that this is beneficial.
OTHO what is abs anyway ?
Is it some kind of builtin overloaded function that
On 12/16/2013 04:44 PM, Ivanko B wrote:
Then typecasts ABS should be inline-d.
Typecast is not only inlined but even builtin (in C source code it not
even looks like a function; this is PASCAL specific stuff.)
abs() is a special beast, anyway...
-Michael
On 12/17/2013 09:30 AM, Michael Schnell wrote:
OTHO what is abs anyway ?
Is it some kind of builtin overloaded function that works differently
for different argument types ?
BTW.: Funny stuff:
Is the argument of abs() would be fixed to signed, and we would have
automatic type conversion
On Tuesday 17 December 2013 09:30:52 Michael Schnell wrote:
On 12/16/2013 03:58 PM, Martin Schreiber wrote:
unsigned:= card32(abs(signed));
This suggests that the result of abs is signed and need an explicit
conversion to unsigned.
Correct. There is no abs() for unsigned types.
I'm not
Correct. There is no abs() for unsigned types
==
Do You want to disable these (100% compatible) types as arguments ?
Looks a bit revolutionary :)
--
Rapidly troubleshoot problems before they affect your
On Tuesday 17 December 2013 18:38:39 Ivanko B wrote:
Correct. There is no abs() for unsigned types
==
Do You want to disable these (100% compatible) types as arguments ?
Looks a bit revolutionary :)
One can always use explicit type conversions. MSElang principle is to make
This may be considered as a joke by non-devoted people :)
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their
On Tuesday 17 December 2013 19:14:24 Ivanko B wrote:
This may be considered as a joke by non-devoted people :)
Why? What about Delphi
cardinalvar:= $;
integervar:= abs(cardinalvar);
?
BTW, Free Pascal has no unsigned abs().
http://www.freepascal.org/docs-html/rtl/system/abs.html
Hallo Michael,
Du schriebst am Tue, 17 Dec 2013 09:33:34 +0100:
Typecast is not only inlined but even builtin (in C source code it not
even looks like a function; this is PASCAL specific stuff.)
Sorry for stepping in, I promise I won't any more...
BUT: Does anybody _really_ think that type
unsigned = signed = doing_smth = unsigned instead of
doing_smth(unsigned)
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
On Tuesday 17 December 2013 19:31:21 Ivanko B wrote:
unsigned = signed = doing_smth = unsigned instead of
doing_smth(unsigned)
There is no abs() for unsigned - one can not do doing_smth(unsigned) with
abs().
--
On Tuesday 17 December 2013 20:24:27 Sieghard wrote:
BUT: Does anybody _really_ think that type casting _does_ something?
A type cast, CPU wise, is a no-op, quite simply.
Correct, if the sizes of the types are the same a type conversion says to the
compiler I know what I do.
For the
*no* implicit type conversions
===
that's with side (unexpected/unwanted) effects.
But what for to disable :
unsigned := signed ?
Here, user know what he/she wants to get (absolute value of the signed).
--
On 12/16/2013 02:29 PM, Ivanko B wrote:
unsigned := signed ?
Here, user know what he/she wants to get
No he does not.
(absolute value of the signed).
Even you don't :-) .
If you do unsigned := signed; you get the correct positive value if
positive. But if it is negative you'll get
But if it is negative you'll get maxunsigned + value + 1, as
===
Really it should do internally smth like :
unsigned:= ABS(signed)
--
Rapidly troubleshoot problems before they affect your business. Most IT
On 12/16/2013 02:52 PM, Ivanko B wrote:
But if it is negative you'll get maxunsigned + value + 1, as
===
Really it should do internally smth like :
unsigned:= ABS(signed)
-1
This would be different to any known language and much slower.
-Michael
On Monday 16 December 2013 14:29:05 Ivanko B wrote:
*no* implicit type conversions
===
that's with side (unexpected/unwanted) effects.
But what for to disable :
unsigned := signed ?
var
unsigned: card32;
signed: int32;
...
unsigned:= card32(signed);
Assigns the binary value
Then typecasts ABS should be inline-d.
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With
On Monday 16 December 2013 16:44:24 Ivanko B wrote:
Then typecasts ABS should be inline-d.
Sure.
Martin
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear
Then 'Error: Icompatible types: got cardinal expected integer
without explicit typecast' ?
PS: personally me hate these laconic FPC error message-jokes more
fearing misleadind than helping.
--
Rapidly troubleshoot
I think there should be no implicit type conversions in MSElang.
===
Maybe no UNSAFE (unsigned -2-signed etc with possible range/precision
loss,..) implicit type conversion ?
--
Rapidly
On Saturday 14 December 2013 18:24:20 Ivanko B wrote:
I think there should be no implicit type conversions in MSElang.
===
Maybe no UNSAFE (unsigned -2-signed etc with possible range/precision
loss,..) implicit type conversion ?
Yes.
var
i1,i2: integer;
c1:
On Saturday 14 December 2013 18:47:22 Martin Schreiber wrote:
var
i1,i2: integer;
c1: cardinal;
begin
f1:= 1.0; //ok
f1:= float(1); //ok
i1:= 1; //ok
c1:= 1; //ok
i2:= i1 + c1;//error
end;
Correction:
var
i1,i2: integer;
On Saturday 14 December 2013 19:59:34 Ivanko B wrote:
With easy-to-get descriptive error messages, correct ?
Yes, 'Error: Icompatible types: got cardinal expected integer'.
Martin
--
Rapidly troubleshoot problems
Or avoiding boring investigations: denying to assign unsigned to
signed because of possible value truncation - use explicit typecast if
sure what You're doing.
--
Rapidly troubleshoot problems before they affect your
On Saturday 14 December 2013 21:09:38 Ivanko B wrote:
Or avoiding boring investigations: denying to assign unsigned to
signed because of possible value truncation - use explicit typecast if
sure what You're doing.
Rejected. ;-)
Martin
Hi,
I think there should be no implicit type conversions in MSElang.
var
f1: float;
i1: integer;
c1: cardinal;
by1: byte;
begin
f1:= 1; //error
f1:= 1.0;//ok
f1:= float(1); //ok
i1:= 1; //ok
by1:= 1; //ok
i1:= by1;
+1
(even seemingly not a very common language restriction)
-Michael
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
38 matches
Mail list logo