On Sun, May 02, 2010 at 12:54:42PM -0700, patrick keshishian wrote:
quoted text
> On Sun, May 2, 2010 at 3:59 AM, Christopher Zimmermann
> <madroach@zakweb.de> wrote:
> > On Sat, 1 May 2010 14:11:22 +0200 Marc Espie wrote:
> >
> >> On Sat, May 01, 2010 at 11:39:00AM +0200, Christopher Zimmermann wrote:
> >> > Hi,
> >> >
> >> > the following piece of code compiles fine using g++ 4.2.4, but
> >> > fails using g++ 3.3.5 in the base system:
> >> >
> >> > error: operands to ?: have different types
> >> >
> >> > It is part of ptlib, which is the base library for opal, which in
> >> > turn is needed for ekiga, which I'm trying to port.
> >> >
> >> > What is your suggestion? Can anyone think of a workaround for
> >> > this or should I just compile it using eg++ 4.2.4 ?
> >> >
> >> >
> >> > Christopher
> >> >
> >> >
> >> > #include<err.h>
> >> >
> >> > #define WarnIfNULL(x) ((x) ? (x) : (warn("blub"),(x)))
> >> >
> >> > class A
> >> > {
> >> >   protected:
> >> >     int a;
> >> > };
> >> >
> >> > class B : A
> >> > {
> >> >   public:
> >> >     void blub()
> >> >     {
> >> >          WarnIfNULL(A::a);
> >> >     }
> >> > };
> >>
> >> Why do some C++ programmer still use macros where they're not needed ?
> >> bunch of idiots, let them stay with C.
> >>
> >> #include<err.h>
> >>
> >> template<typename T>
> >> inline T WarnIfNULL(T x)
> >> {
> >>       if (!x)
> >>               warn("blub");
> >>       return x;
> >> }
> >>
> >> class A
> >> {
> >>   protected:
> >>     int a;
> >> };
> >>
> >> class B : A
> >> {
> >>   public:
> >>     void blub()
> >>     {
> >>          WarnIfNULL(A::a);
> >>     }
> >> };
> >>
> >
> > ok, thanks. That seems to be the solution, still I have to wrap it in a macro, because I need __LINE__, __FILE__, __CLASS__...
> 
> 
> You example obviously isn't showing the exact usage you require. I
> imagine the macro is being used in assignments, not just in the blub()
> method as you display.
> 

Doesn't change a lot.
It's still a very good idea to stay away from macros for most things in C++,
and if you require __LINE__, __FILE__, __func__, *then* you write a proper
inline function (or a template if it needs to be polymorphic), and only wrap
the most external call into a macro that inserts __LINE__... where needed.

That way, you get actual parameter type checking that you can understand,
and the macros themselves.

Everyone sane does things that way, and has used similar tricks even on
C compiler (check a proper getc definition on most any reasonable library,
the macro just inlines the buffer check, and defers the actual complicated
code to an out-of-line function).