On Monday, January 09, 2012 19:37:47 Gábor Lehel wrote:
> ...and apologies for the email spam but yet another complication is
> that if the header defining the macro is included later than the one
> which does the poisoning, that'll also result in an error. Probably
> that's also solvable by #ifdef
2012/1/9 Gábor Lehel :
> 2012/1/9 Stephen Kelly :
>> On Monday, January 09, 2012 18:00:29 Gábor Lehel wrote:
>>
>>> 2012/1/9 Gábor Lehel :
>>
>>> > Perhaps we could use GCC's poison pragma[1] to make sure that no one
>>
>>> > uses them? In some cases it would just be replacing one error message
>>
2012/1/9 Stephen Kelly :
> On Monday, January 09, 2012 18:00:29 Gábor Lehel wrote:
>
>> 2012/1/9 Gábor Lehel :
>
>> > Perhaps we could use GCC's poison pragma[1] to make sure that no one
>
>> > uses them? In some cases it would just be replacing one error message
>
>> > with another (though perhaps
On Monday, January 09, 2012 18:00:29 Gábor Lehel wrote:
> 2012/1/9 Gábor Lehel :
> > Perhaps we could use GCC's poison pragma[1] to make sure that no one
> > uses them? In some cases it would just be replacing one error message
> > with another (though perhaps a more user-friendly one), but in othe
2012/1/9 Gábor Lehel :
> Perhaps we could use GCC's poison pragma[1] to make sure that no one
> uses them? In some cases it would just be replacing one error message
> with another (though perhaps a more user-friendly one), but in other
> cases it would substitute an error for no error. Of course,
Perhaps we could use GCC's poison pragma[1] to make sure that no one
uses them? In some cases it would just be replacing one error message
with another (though perhaps a more user-friendly one), but in other
cases it would substitute an error for no error. Of course, it only
works with GCC. (TBF I
On Monday, 9 de January de 2012 14.46.54, =?ISO-8859-1?Q?Gábor?= Lehel
wrote:
> Yet more:
> - major
> - minor
>
> These are defined to gnu_dev_major and gnu_dev_minor, I'm not quite
> sure by what (GCC? glibc?).
/usr/include/sys/sysmacros.h:# define major(dev) gnu_dev_major (dev)
$ grep include.*
2012/1/9 Charley Bay :
>> Stephen Kelly spaketh:
>>
>> > http://boost.2283326.n4.nabble.com/Boost-with-Darwin-Mac-gcc-4-0-1-
>> > td2580330.html
>> >
>> > So, keep in mind - for portability treat 'check' as an out of bounds
>> > name
>> > for a method or variable.
>
>
> Thiago Macieira respondeth:
>
> Stephen Kelly spaketh:
> > http://boost.2283326.n4.nabble.com/Boost-with-Darwin-Mac-gcc-4-0-1-
> > td2580330.html
> >
> > So, keep in mind - for portability treat 'check' as an out of bounds name
> > for a method or variable.
>
Thiago Macieira respondeth:
> Also to avoid:
>sun
>
On Monday, 9 de January de 2012 13.43.52, Stephen Kelly wrote:
> On Monday, January 09, 2012 10:36:11 Thiago Macieira wrote:
> > And a hint: whenever you get an error from the compiler that doesn't make
> > sense at all, check the preprocessed output.
>
> And if you don't have enough access to do t
On Monday, January 09, 2012 10:36:11 Thiago Macieira wrote:
> And a hint: whenever you get an error from the compiler that doesn't make
> sense at all, check the preprocessed output.
And if you don't have enough access to do that, start googling for whatever is
on the problem lines together with
On Monday, 9 de January de 2012 13.25.47, Stephen Kelly wrote:
> http://boost.2283326.n4.nabble.com/Boost-with-Darwin-Mac-gcc-4-0-1-
> td2580330.html
>
> So, keep in mind - for portability treat 'check' as an out of bounds name
> for a method or variable.
Also to avoid:
sun
m_volum
Hi,
I've just solved a problem with a method called check() on Mac OSX. It was
quite a head scratcher, so I thought I'd throw some light on it so others are
aware.
Mac OSX defines an assert header called check() so I was getting error like:
../../../../include/QtCore/../../src/corelib/kernel/
13 matches
Mail list logo
