Eduardo,
I tried to explain a number of times, that this extension has nothing to do
with Str() in specific. As I explained, xHarbour has an additional (SUB)TYPE
called CHAR. That type CHAR, is NUMERIC compatible, period!
Please THINK what this RULE means.
Because Str() function accept a NUMERIC argument, than ANY NUMERIC is
accepted. Although it's NOT LIKELY that anyone will use a CHAR type as an
argument to the Str() function, it would not be acceptable for us to program
a SPECIFIC EXCEPTION to the general rule.
Not that it has any importance, but here is an example of intended usage of
Str() with CHAR argument.
//-------------------------------------------//
PROCEDURE Main()
LOCAL sString := "HELLO"
LOCAL sAscii := ""
LOCAL cChar
FOR EACH cChar IN sString
sAscii += Str(cChar, 2 ) + ","
NEXT
sAscii[-1] := 0
? sAscii
RETURN
//-------------------------------------------//
For further consideration, please review this C sample:
//------------------------------------------//
#include <stdlib.h>
#include <stdio.h>
int main( int argc, char *argv[] )
{
char szString[3];
_itoa( 'a', szString, 10 );
printf( "%s\n", szString );
return 0;
}
//------------------------------------------//
Would you like to convince anyone to program exceptions into C, that would
DISCRIMINATE against the char type, in _itoa() "because it has no use in
real application"?
You just can't break general type rules, only because they don't look
reasonable in some usage.
IAE, if you are not convinced, I'm sorry to be blunt, but I must advise you
that when I created the xHarbour project, I made it perfectly clear, that
this project values extended functionality over "Clipper ERROR
COMPATIBILITY". So I'm very sorry, but I will not continue arguing this
matter.
Ron
--------------------------------------------------
From: "Eduardo Fernandes" <[email protected]>
Sent: Thursday, April 02, 2009 5:23 PM
To: "xHarbour Developers Mailing List"
<[email protected]>; " xHarbour.Patrick Mast"
<[email protected]>
Subject: Re: [xHarbour-developers] Str() function.
>
> Patrick,
>
> IMO, all functions inhirited from Clipper, should at least, behaves like
> this.
>
> For example:
>
> Val(1) returns an error/base, as expected.
> If str('1',2) extension is very important, so hb_str() should be created,
> instead implement it in str().
>
> I would like know what use of str('1',2) in real application.
>
> regards,
> Eduardo
>
>
> --- Em qui, 2/4/09, Patrick Mast, xHarbour. <[email protected]>
> escreveu:
>
>> De: Patrick Mast, xHarbour. <[email protected]>
>> Assunto: Re: [xHarbour-developers] Str() function.
>> Para: "xHarbour Developers Mailing List"
>> <[email protected]>
>> Data: Quinta-feira, 2 de Abril de 2009, 8:39
>> Hello,
>>
>> > I would like error/base instead these results:
>> >
>> > ? str('1') // null char
>> > ? str('1',0) // 49
>> > ? str('1',1) // *
>> > ? str('1',2) // 49
>>
>> I agree. Str("a",1,0) should produce an error.
>>
>> Patrick
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> xHarbour-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/xharbour-developers
>>
>
>
> Veja quais são os assuntos do momento no Yahoo! +Buscados
> http://br.maisbuscados.yahoo.com
>
> ------------------------------------------------------------------------------
> _______________________________________________
> xHarbour-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xharbour-developers
>
------------------------------------------------------------------------------
_______________________________________________
xHarbour-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
