On Jun 18, 2010, at 8:13 PM, Michael Jennings wrote:
> On Friday, 18 June 2010, at 14:01:05 (-0400),
> Jeff Johnson wrote:
>
>> Should I go to the effort of a run-time "features" acquisition API?
>
> IMHO, no. Any time you add fluff, you get further away from the meat,
> and there's room for error. The least error-prone approach is to
> check for X when you use X, check for Y when you use Y, etc., or at
> least check for the most recently-added of X, Y, and Z. But the
> moment you start checking for symbol Q which is supposed to indicate
> the presence of X but isn't actually X, gratuitous abstraction and
> potential for mistakes are introduce for no (again, IMHO) gain.
>
But note run-time, where its not always possible to do the test,
particularly if popt was built by vendors differently, or different
versions or feature sets.
What I was envisioning is merely a Bloom filter with an API like
bool poptHasFeature(const char * s)
Then during build the strings/aliases are pumped into a Bloom
filter, and the resultant bitsset is just stashed into octets
and fed to (already exists in popt-1.16)
int poptBitsChk(/*...@null@*/poptBits bits, /*...@null@*/const char * s)
/*...@*/;
It would be quite a simple API, and reasonably general/extensible
(depending on how the bitset was generated during build) without
all the usuall "fluff" of tables of arrays of ptrs of ...
... but since POPT is unlikely to accumulate 32 "features" this century,
well, it could just be a simple enum of "features" returned as an int32.
Hmmm ... I suspect I'll be lazy and do nothing until I'm forced.
> Of course, in reality, whatever the documentation examples show as the
> "right way to check for POPT 2.0" is precisely what will be
> copied-and-pasted into code for the next half-century. But you know
> this better than I.
>
Thanks for opinions.
73 de Jeff
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
