Nathan Ingersoll wrote:
If it's something people are concerned about, we can namespace them.
That being said, these have been exported in some form for about 5 years
without a single complaint.
On 9/6/05, *Tilman Sauerbeck* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
On Tue, 06 Sep 2005 21:44:40 +0200 Kim Woelders <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
> > diff -u -3 -r1.24 -r1.25
> > --- Ecore.h 5 Sep 2005 10:17:08 -0000 1.24
> > +++ Ecore.h 6 Sep 2005 19:26:19 -0000 1.25
> > @@ -43,6 +43,14 @@
> > #include <sys/types.h>
> > #include <signal.h>
> >
> > +#ifndef TRUE
> > +#define TRUE 1
> > +#endif
> > +
> > +#ifndef FALSE
> > +#define FALSE 0
> > +#endif
> > +
> > #ifdef __cplusplus
> > extern "C" {
> > #endif
>
> Is this really a good idea? I have over the years seen way too many
> cases of clashing definitions of TRUE/True/true, FALSE/False/false.
true/false are a very different story, since they are defined by C99.
Defining FALSE to zero is alright from my experience. Would you be
happier if we defined TRUE to !FALSE?
Regards,
Tilman
I suggest splitting all commonly used macros to a Ecore_Macros.h file,
and the just defining them there without checking, or put a warning if
the name is already defined. Then a user can include the file or not. I
can go through all of cvs and fix it :)
Or make such a file and include it in Ecore.h by default, and make it
possible to remove it with a define (#define ECORE_NO_MACROS 1) or similar.
Sebastian
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
