On Mon, 11 May 2009, Szak�ts Viktor wrote:
Hi,
> > Good question. There is no easy way to detect inheritance order. We do
> > not keep such information in general RDD structures so it will have to
> > be implemented in given GT.
> > In this case probably the easiest way is using new DBI_ or RDDI_ action.
> > To not cause additional overhead you can add action which will not operate
> > on given item value so you can pass NULL as parameter, f.e.:
> > add to dbinfo.ch:
> > #define RDDI_ADSBASED 45 /* check if given RDD inherits from ADS* ones
> > */
> Or even:
> dbInfo( RDDI_BASEDON, "ADS" ) -> .T./.F.
> This way we won't introduce 3rd party specific names and macros in
> core dbinfo.ch. Anyhow such constant as RDDI_ADSBASED should
> better be defined in ads.ch anyway.
I agree that it's nice solution but there are two problems with it:
1. it forces allocating new item for "ADS" string what in some cases can
cause noticeable performance overhead in C code and it's sth what I'd
like to eliminate when I proposed RDDI_ADSBASED.
2. We have few ADS based RDDs: "ADS" (old for historical reasons, kept
only for backward compatibility), "ADT", "ADSCDX", "ADSNTX", "ADSVFP".
Expect "ADS" non of them inherits from "ADS" RDD so we will have to
hard code that all of them accept such string as super RDD name so it
stops to be as nice as it should. Calling:
dbInfo( RDDI_BASEDON, "ADS" ) .or. ;
dbInfo( RDDI_BASEDON, "ADT" )
dbInfo( RDDI_BASEDON, "ADSCDX" )
[...]
to keep it clean will cause additional speed overhead.
The 2-nd one is not very important so we can ignore it and hard code
the "ADS" string as supper RDD name but the 1-st one can be in code
which has to very often call hb_adsGetWorkAreaPointer().
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
