Eduardo,
Your are posting wrong information about the CHAR type. CHAR (as numeric)
type is ***ONLY*** acceptable in contexts where ONLY NUMERIC would be
acceptable, IOW only when an ERROR would result!!! Specifically,
ordSetFocus() and aScan() would never treat CHAR as NUMERIC because they do
NOT REQUIRE a NUMERIC!!!
Your proposal can't be accepted for the reasons I stated at least 3 times
now. xHarbour will never remove that feature.
Ron
--------------------------------------------------
From: "Eduardo Fernandes" <modals...@yahoo.com.br>
Sent: Tuesday, November 10, 2009 2:41 AM
To: "Ron Pinkas" <ron.pin...@xharbour.com>; "Miguel Angel Marchuet"
<miguelan...@marchuet.net>
Cc: "Xharbour-Developers List" <xharbour-developers@lists.sourceforge.net>
Subject: Re: [xHarbour-developers] Proposal for HB_IS_NUMERIC.
> Miguel,
>
> My proposal is justly enable RT error.
>
> 1) What return value you expect from substr('abcdef', '3' ) ?
> 'abcdef' string, 'cdef' string , null string or RT error ?
>
> 2) where, on core xharbour code, is used a char as numeric parameter ?
> like str('a',3) ?
>
> f.e. Inspecting cstr.prg, line 311, on valtoprgexp() function I found:
>
> 311 FOR EACH cChar IN xVal
> 312 cRet += " + Chr(" + Str( Asc( cChar ), 3 ) + ")"
> 313 NEXT
>
> It seems the correct way to do it.
>
> 3) From harbour "xhb-diff.txt" file:
> -----
> ### USING ONE CHARACTER LENGTH STRING AS NUMERIC VALUE ###
> ================================================================
> xHarbour uses one byte strings as numeric values corresponding to ASCII
> value of the byte in a string, f.e.:
> ? "A" * 10 // 650
> By default Harbour core code does not give such functionality but
> it has strong enough OOP API to allow adding such extension without
> touching core code even by user at .prg level. It was implemented
> in Harbour in XHB.LIB.
> This code can be compiled and executed by both compilers:
>
> #ifndef __XHARBOUR__
> #include "xhb.ch"
> #endif
> proc main()
> local c := "A"
> ? c * 10, c - 10, c + 10, c * " ", chr( 2 ) ^ "!"
> return
>
> and gives the same results.
> Anyhow the emulation is not full here. It works only for .prg code.
> In xHarbour standard C API functions/macros were modified to use
> one byte string items as numbers. It's potential source of very serious
> problems, f.e. ordSetFocus("1") should chose index called "1" or maybe
> index 49 or what should return ascan( {49,"1"}, "1" ) (1 or 2)? so
> Harbour developers decided to not add anything like that to core code
> so in Harbour functions written in C refuse to accept one byte string
> as number and code like
> ? str( "0" )
> generates runtime error instead of printing ' 48'.
>
> -----
>
> So, my proposal is isolate this feature like a number extension or other
> solution to give me a RT error when, inadvertently a char is passed as
> numeric parameter on string functions.
>
> IMO, this feature is dangerous.
>
> regards,
> Eduardo
>
>
>
> --- Em seg, 9/11/09, Miguel Angel Marchuet <miguelan...@marchuet.net>
> escreveu:
>
>> De: Miguel Angel Marchuet <miguelan...@marchuet.net>
>> Assunto: Re: [xHarbour-developers] Proposal for HB_IS_NUMERIC.
>> Para: "Ron Pinkas" <ron.pin...@xharbour.com>
>> Cc: "Eduardo Fernandes" <modals...@yahoo.com.br>, "Xharbour-Developers
>> List" <xharbour-developers@lists.sourceforge.net>
>> Data: Segunda-feira, 9 de Novembro de 2009, 8:05
>> I have read the conversation about
>> numerical consideration.
>>
>> I propose an alternative solution RT error. Eliminating
>> certain RT errors with pragmas
>> for example:
>>
>> # pragma NoTestError = BASE | 1340
>>
>> not emerge for the 1340 runtime error division by 0 and be
>> the default value 0
>> course may only be prepared as disabled those functions.
>> PADL, PADR.
>>
>> or when the key error exceeds 240 characters and thus
>> operate as C/52 instead of C/53.
>>
>> # pragma NoTestError = DBFCDX | 1054
>> [SPANISH]
>> He leido atentamente la cnversación acerca de la
>> consideración de numéricos.
>>
>> Propongo una solución alternativa, Eliminar ciertos RT
>> error usando pragmas
>> por ejemplo
>>
>> #pragma NoTestError=BASE|1340
>>
>> para que no emerja el runtime error 1340 division por 0 y
>> resulte el valor por defecto 0
>> evidentemente solo podran desactivarse aquellas funciones
>> preparadas como. PADL, PADR.
>>
>> o bien el error cuando la key excede los 240 caractereS y
>> asi actue como en CL52 en lugar de CL53.
>>
>> #pragma NoTestError=DBFCDX|1054
>>
>>
>> Best regards,
>> Miguel Angel Marchuet
>>
>> Ron Pinkas escribió:
>> > Eduardo,
>> >
>> >> So, we could review all string functions like
>> str(), strzero(), pad(),
>> >> etc, that call HB_IS_NUMERIC(), HB_IT_NUMERIC or
>> ISNUM() to maintain, at
>> >> least, expected results or run time error, if any
>> argument is inverted or
>> >> with any data type changed.
>> >>
>> >> f.e.:
>> >>
>> >> ? str("a",10,2)
>> >> ? strzero("b",10)
>> >> ? padl("9","*",10)
>> >> ? padr("9","*",10)
>> >> ? padc("9","*",10)
>> >
>> > Please note that it is absolutely VALID CODE to pass a
>> single char as a
>> > NUMERIC value. I have lot's of such code
>> intentionally. It would therefore
>> > be wrong to break a documented feature which has been
>> working for years.
>> >
>> > Ron
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Let Crystal Reports handle the reporting - Free
>> Crystal Reports 2008 30-Day
>> > trial. Simplify your report design, integration and
>> deployment - and focus on
>> > what you do best, core application coding. Discover
>> what's new with
>> > Crystal Reports now. http://p.sf.net/sfu/bobj-july
>> > _______________________________________________
>> > xHarbour-developers mailing list
>> > xHarbour-developers@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/xharbour-developers
>> >
>> > __________ Información de ESET NOD32 Antivirus,
>> versión de la base de firmas de virus 4578 (20091106)
>> __________
>>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
xHarbour-developers mailing list
xHarbour-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xharbour-developers
