[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
[XaraXtreme-dev] The _R macro and ctype.h
- From: "Ben Fowler" <ben.the.mole@xxxxxxxxx>
- Date: Wed, 29 Mar 2006 12:37:45 +0100
- Subject: [XaraXtreme-dev] The _R macro and ctype.h
_R macro, see
and camresource.h around line 124
// _R() is used 2860 times and so is non-trivial to change, but it is
// defined <in ctype.h>
// Are we right to use an _ macro, and if so, this one?
// Define _R() before we include other Camelot headers
// NOTE THIS MACRO IS EXPANDABLE IN A STATIC INITIALIZER
#define _R(x) ( CamResource::GetResourceID( _RESQUOTE(x)) )
In file included from ../Precomp/camtypes.h:115,
In file included from
/usr/include/ctype.h:103:1: warning: this is the location of
the previous definition
wxWidgets includes ctype.h (arguably wrong in a unicode build), but
only when building on
BSD systems such as Darwin, and of course FreeBSD.
Personally, I would not use a symbol starting with an underscore
unless I was working on an
implementation or a framework, particlarly a short symbol, without a
very good reason.
So one solution would be to make a major change now, and replace the
_R macro with an _xR one (an underscore symbol with a lowercase
letter is far less likely to cuase problems, and
adding the extra letter makes search and replace much easier if
problems/conflicts do arise later).
Alternatively, using the model that wxWidgets employs in '#undef _T'
at wxchar.h line 223, we
could '#undef _R' at say, line 113 of stdwx.h .
I am slightly surprised that Vasil Dimov from FreeBSD and Gerry Iles
(Xara) haven't come
across the same problem - or at least haven't commented on it, but it
is just conceivable that this
issue is Mac only.
Even so, if there is a common sense approach to avoiding name clashes
especially with the
pre-processor, I would be very tempted to adopt it, even if the
offered gain is small.