Re: NULL in include/RefCount.h?

From: Kinkie <gkinkie_at_gmail.com>
Date: Wed, 16 Feb 2011 12:03:36 +0100

On Wed, Feb 16, 2011 at 11:37 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On 16/02/11 22:55, Kinkie wrote:
>>
>> On Wed, Feb 16, 2011 at 10:46 AM, Amos Jeffries<squid3_at_treenet.co.nz>
>>  wrote:
>>>
>>> On 16/02/11 04:17, Kinkie wrote:
>>>>
>>>> Hi all,
>>>>   RefCount is a pure c++ artifact, and at least on my Ubuntu system it
>>>> breaks the build. On the hudson nodes this doesn't seem to happen,
>>>> probably due to indirect include from<iostream>.
>>>
>>>  From stdio.h is that route most likely then. Or any number of other
>>> system
>>> includes which define it.
>>>
>>>> How to deal with it? Should we use the c++ "0" construct or try to
>>>> define the NULL symbol somehow?
>>>>
>>>
>>> Alex brought removal up a while ago. My arguments about portability have
>>> since been proven obsolete (yay).
>>>
>>> So we are left with the opinions (me, Robert, Henrik IIRC) that use of
>>> NULL
>>> makes it absolutely clear that the thing being tested is a pointer and
>>> not
>>> an integer, no C++ magic conversion mistakes.
>>>
>>> If need be we can add this to compat/compat_shared.h:
>>>  #if !defined(NULL)
>>>  #define NULL ((void*)0)
>>>  #endif
>>
>> Stroustrup's take on the issue
>> (http://www2.research.att.com/~bs/bs_faq2.html#null).
>> It seems reasonable to me.
>>
>
> Well if you want to erase NULL we can probably cope.
> It's an aesthetic thing more than a problem fix now.

For RefCount the problem is probably that it doesn't include anything
(except for <iostream> which may or may not define NULL indirectly).
Simply including "config.h" seems to do the trick; if it builds I'll commit it.

-- 
    /kinkie
Received on Wed Feb 16 2011 - 11:03:43 MST

This archive was generated by hypermail 2.2.0 : Wed Feb 16 2011 - 12:00:06 MST