Re: Preannounce and vote on the CRM114 library...

 On Fri, Mar 5, 2010 at 8:16 PM, <[email protected]> wrote:

> Do people prefer:
>
>   libcrm_... ?  ... which is what's there now.
>
>   libcrm114_... ?  (avoids confusion with other CRMs like SugarCRM, which
>                is a Customer Relationship Management system)
>
>   crm114_... ? makes it clear what the library is, but doesn't
>                make it clear that this is NOT the language.
>
> Wisdom, please?
>


+1 for crm114_

Reasoning:

1) shortest prefix which is very very probably unambiguous, worldwide.
(Those that use crm114 for its language instead of its classifiers know who
they are so no confusion there, I'd say. ;-) )

2) anyone who doesn't like it can always do the equivalent of classic yacc
prefix redef, given that 'C' lacks namespaces. C++ folks can wrap it up as
static methods in an interface class and tack namespace to it for extra
kuddos.
(For the less geeked and the young ones, that yacc'd be

#define my_preffed_prefix_parse yyparse
i.e. for libcrm114-->
#define my_preffed_prefix_learn  crm114_learn
#define my_preffed_prefix_classify  crm114_classify

I.e. anyone can have any of the prefix choices listed and then some. It's a
couple of #define's away.



What's more important IMO: get rid of that stderr/FILE I/O dependency. It's
simple, it's easy. Just either

a) require a couple of functions a.k.a. methods provided by the app

or the classic (and much more programmer-friendly in regard of libcrm114 as
dynamically loadable lib) thing:

b) have the libcrm 'user' a.k.a. app or system programmer register a couple
of callbacks which are those methods, at startup/init or class instantiation
phase of the lib.

If you can't 'trust' your 'user' (== app/sys programmer) to take care of
such a little thing, you're assuming a risk level that is not fit for a
library any which way.


This 'no stderr / FILE I/O dependency' thing has nothing to do with the
Embedded Boys Only Club (ties off limit(?)) but addresses the need of a huge
number of app programmers who have embraced the GUI age, be it Win32 or X or
whatchamacallit. Deep embedded just benefits from the side effects. Real GUI
environments do not have stdout/stdin/stderr, and that includes X. (And yes,
I know, glibc has those on offer always. Guess where those end up dumping
their content when you're doing X apps (GTK=Qt=Wx=...=X). <face palm />
Bloody 'backwards compat' feature for those porting command line code the
q&d way.)

Hm. Feels like I'm starting to rehash old conversation. Not going there.
Over and out.


-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
       http://www.hebbut.net/
mail:   [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

_______________________________________________
Crm114-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crm114-general