Need to work around g++ 'NULL' warning



 DEVELOP > c-Plus-Plus > Need to work around g++ 'NULL' warning

LINK TO THIS PAGE  


rating :  0   |  0


  Page 1 of 1

1

 
Topic: DEVELOP > c-Plus-Plus
User: "Neil"
Date: 25 Jan 2008 06:08:45 AM
Object: Need to work around g++ 'NULL' warning
I've constructed a custom smart pointer, and for various reasons I'm
in the situation where I'd like to make the raw-pointer ctor for it
explicit.
However, this then disallows assignment from NULL (and implicit
creation, e.g., for 'return NULL' returning a smart pointer). I've
gone out of my way to try to make this smart pointer as drop-in-
replacement friendly as possible, so losing the ability to easily
assign NULL is a bit of a blow.
I *thought* I had a nice work-around by defining an implicit (int)
ctor, and while VS accepts this, g++ (-Wall -pedantic; probably quite
rightly for most cases) reports a warning:
warning: passing NULL to non-pointer argument ...
Can anyone think of a clever way of working around this (even if
it's g++-specific)?
A point of interest may be that '#pragma GCC system_header' can
disable that warning, but only if the actual conversion from NULL to
smart-ptr is in a header with the pragma, and I couldn't figure out
how to wangle that.
Here's a really basic example:
#include <iostream>
template <typename T>
struct Ptr
{
Ptr( const Ptr & ) {} // copy ctor
explicit Ptr( T * ) {} // only explicit from c-ptr
Ptr( int ) {} // to catch NULL (don't care about non 0)
};
int main()
{
float f1 = 0.0;
Ptr<float> p1(&f1); // OK
Ptr<float> p2(NULL); // warning :-(
return 0;
}
.

User: "Alf P. Steinbach"

Title: Re: Need to work around g++ 'NULL' warning 25 Jan 2008 06:44:18 AM
* Neil:

I've constructed a custom smart pointer, and for various reasons I'm
in the situation where I'd like to make the raw-pointer ctor for it
explicit.

However, this then disallows assignment from NULL (and implicit
creation, e.g., for 'return NULL' returning a smart pointer). I've
gone out of my way to try to make this smart pointer as drop-in-
replacement friendly as possible, so losing the ability to easily
assign NULL is a bit of a blow.


I *thought* I had a nice work-around by defining an implicit (int)
ctor, and while VS accepts this, g++ (-Wall -pedantic; probably quite
rightly for most cases) reports a warning:

warning: passing NULL to non-pointer argument ...


Can anyone think of a clever way of working around this (even if
it's g++-specific)?

A point of interest may be that '#pragma GCC system_header' can
disable that warning, but only if the actual conversion from NULL to
smart-ptr is in a header with the pragma, and I couldn't figure out
how to wangle that.


Here's a really basic example:

#include <iostream>

template <typename T>
struct Ptr
{
Ptr( const Ptr & ) {} // copy ctor
explicit Ptr( T * ) {} // only explicit from c-ptr
Ptr( int ) {} // to catch NULL (don't care about non 0)
};

int main()
{
float f1 = 0.0;

Ptr<float> p1(&f1); // OK
Ptr<float> p2(NULL); // warning :-(

return 0;
}

struct NullPtr
{
template< typename T >
operator T* () const { return 0; }
// More stuff if you want it.
};
NullPtr const nullPtr = NullPtr();
template< typename T >
struct Ptr
{
Ptr( Ptr const& ) {}
explicit Ptr( T* ) {}
};
int main()
{
float f1 = 0;
Ptr<float> p1( &f1 );
Ptr<float> p2( nullPtr );
// Ignore g++ warning of non-usage, or use.
}
Note: C++0x will introduce some support for typed nullpointers, and it
might be an idea to try to be forward-compatible. If possible.
However, I don't have time to look up the details.
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
.
User: "FNX"

Title: Re: Need to work around g++ 'NULL' warning 25 Jan 2008 10:18:11 AM
Around about 25/01/08 12:44, Alf P. Steinbach scribbled ...

NullPtr const nullPtr =3D NullPtr();
Ptr<float> p2( nullPtr );

As it happens, after failing to figure out a solution initially, I=20
(a) tried to redefine NULL (effective C++, 2nd, edition [dropped from=20
3rd!]) which would've solved it in a similar fashion=E2=80=A0 then (b) de=
cided=20
to go down your route and define a global 'null'.
But I started hitting *so* much code that needed NULL changing to=20
null I got scared off it (we have a no. of next-level users with code=20
based on ours that would *not* have been happy with having to ripple=20
through that mod.).
Although I might have to go back to it if my current possible=20
solution (prior post) falls over in the real thing.

Note: C++0x will introduce some support for typed nullpointers, and it =
might be an idea to try to be forward-compatible. If possible. However=

,=20

I don't have time to look up the details.

That's interesting; I'll have to remember to look into that.=20
Certainly, my smart pointer code is due to go through a couple of=20
further revisions in the future and it's certainly worth bearing c++0x=20
in mind as a probable end target. Thanks.
--=20
[~]# sed -e 's/\.no\.junk\.please//g' .signature > .signature+
[~]# rm -f .signature
[~]# ls -l .signature
ls: .signature: No such file or directory
.


User: "Ron Natalie"

Title: Re: Need to work around g++ 'NULL' warning 25 Jan 2008 06:17:23 AM
You cranked up the G++ warning level and you gripe about valid warnings?
If G++ doesn't have a pragma to disable warnings on a specific line like
VC++ does, then you'll have to live with it.
One option is to have an IMPLICIT conversion from some UNLIKLEY type
that you can convert NULL to that won't interfere.
For example:
template <class T> struct Ptr {
class ThisIsNeverUsed;
explicit Ptr(T*);
Ptr(ThisIsNeverUsed*);
};
.
User: "FNX"

Title: Re: Need to work around g++ 'NULL' warning 25 Jan 2008 10:10:04 AM
Around about 25/01/08 12:17, Ron Natalie scribbled ...

You cranked up the G++ warning level and you gripe about valid warnings?

Yeah, we're awkward like that :)

One option is to have an IMPLICIT conversion from some UNLIKLEY type
that you can convert NULL to that won't interfere.
explicit Ptr(T*);
Ptr(ThisIsNeverUsed*);

Ah! That was what I was getting wrong in all my tests. I'd tried a
number of interim class solutions, but all my Ptr members took
const-refs; making them take const pointers to the interim class does
the trick!
The only loss is that I can't 'Ptr p(NULL)', but that's no great loss
as NULL's the default.
I think I can breath easy now! That's been bugging me; I can try it
out with the full s/w first thing Monday. Certainly my test case (now
extended to more match the real thing) is happy.
I *knew* there was going to be some straightforward solution I was
missing.
Thanks!
--
[~]# sed -e 's/\.no\.junk\.please//g' .signature > .signature+
[~]# rm -f .signature
[~]# ls -l .signature
ls: .signature: No such file or directory
.

User: "James Kanze"

Title: Re: Need to work around g++ 'NULL' warning 27 Jan 2008 05:50:23 AM
On Jan 25, 1:17 pm, Ron Natalie <r...@spamcop.net> wrote:

You cranked up the G++ warning level and you gripe about valid
warnings? If G++ doesn't have a pragma to disable warnings on
a specific line like VC++ does, then you'll have to live with
it.
One option is to have an IMPLICIT conversion from some
UNLIKLEY type that you can convert NULL to that won't
interfere.

You can do better than just "unlikely".

For example:

template <class T> struct Ptr {
class ThisIsNeverUsed;
explicit Ptr(T*);
Ptr(ThisIsNeverUsed*);
};

Make the class type private, and user code can't possibly create
a pointer to it, other than through the implicit conversion of
0.
This solution has the added advantage that it only allows using
null pointer constants, and not any integral value---Ptr( NULL )
works, but Ptr( 43 ) fails to compile.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
.



  Page 1 of 1

1

 


Related Articles
 

NEWER

pg.1232     pg.940     pg.716     pg.544     pg.412     pg.311     pg.234     pg.175     pg.130     pg.96     pg.70     pg.50     pg.35     pg.24     pg.16     pg.10     pg.6     pg.3     pg.1

OLDER