[Harbour] SF.net SVN: harbour-project:[11023] trunk/harbour

[Szakáts Viktor]

Hi Przemek,

>> I can revert it although IMO we should rather think about a proper
>> alternative, these options were missing from default builds since
>> last year and no one reported them missing, which suggest it
>> isn't that important. I've since removed all HB_EXTENSION from
>> code, so readding this one looks a bit overkill.
>
> I stoped to use default builds when you disable some extensions so
> I cannot say much about it.

Which extensions do you miss? or what extra settings do you use?

>> One alternative is to readd all of them with HB_ prefix, but this is
>> quite ugly. The other ugly solution is to readd it under a different
>> macro like HB_MEMO_EOL_PARAM_EXTENSION.
>> What would be a proper solution here, another Set()?
>
> I do not like to use SETs because for structural code I have to
> set and restore them what in some cases has serious performance
> overhead. In some other it can be even killer.
> F.e. we have SET callback functions registered by ADS. It means
> that such simple Clipper code:
>
>   func ansidate( dDate )
>      local cFormat := set_( _SET_DATEFORMAT, "YYYY-MM-DD" ), cDate
>      cDate := dtoc( dDate )
>      set_( _SET_DATEFORMAT, cFormat )
>      return cDate
>
> Ported to Harbour activates callbacks and ACE function calls if user
> linked any of ADS based RDD.
> If you use ansidate() function to format some chosen columns in very
> long reports then you can imagine the cost.
> BTW This part is also not MT safe. I do not believe that ACE
> client keeps such sets in some thread local storage.

Most probably non-MT safe. In this case I can't really decide as
I'm not and RDDADS user and I have no idea why these callbacks
were added back then. If it's unsafe or kills performance we
should IMO disable it or find better solution. Fortunately with
HB_DTOC() this specific problem can be solved.

>> [ I personally wonder on the usefulness of this feature, as IMO
>> such text handling functions should automatically work on all
>> available EOLs on all system without any explicit help from the
>> user. ]
>
> I do not find it as good idea. Such extension will always break sth.
> F.e. code which tries to make visualization of some printer output and
> strongly depends on some strict CR and LF behavior which have to be
> compatible with external device he uses.

Can be, yes, however I still can't see a good solution without
adding a new "memo" API with such feature. If we readd it like it
was (but as default), we also readd a hidden parameter extension,
which may collide with other implementations and create usual
back-port problems.

Brgds,
Viktor