Passing NULL to a pointer parameter

[DevFellow]

Here is an example:

Public:
double firstCall(void *a, int *b)
{
return internalCall(a, b, NULL, NULL)
}

double secondCall(void *a, int *b, void *c, int *d)
{
return internalCall(a, b, c, d)
}

Private:
double internalCall(void *a, int *b, void *c, int *d)
{
.....
if (NULL != c)
work with c and d
}

I want to call firstCall(...) and secondCall(...) randomaly about 500 times.

I tested this code and seems it works. Is it a good idea to pass NULL as shown above? If not, what would be a good way to get expected outcome? I am just trying to reduce duplicate codes and kind of afraid if that gives a memory or program problem.

I am new to c++ and wanted to make sure this does not create a problem. I would appreciate if someone help me out.

[VictorN]

Public:
          double firstCall(void *a, int *b)
          {
               return internalCall(a, b, NULL, NULL)
           }
          ...

Private:
         double internalCall(void *a, int *b, void *c, int *d)
         {
              .....
              if (NULL != c)
                     work with c and d
          }

... Is it a good idea to pass NULL as shown above?

Why not?
You also could declare your internalCall as

double internalCall(void *a, int *b, void *c = NULL, int *d = NULL);

PS: please, use Code tags while posting code snippets!

[DevFellow]

Thanks VictorN

[cilu]

Your parameters can have any value including NULL. What you have to do is make sure you don't use NULL pointers to access objects. That would crash your application.

[TubularX]

It's recommended to pass nullptr instead of NULL macro.

[VictorN]

It's recommended to pass nullptr instead of NULL macro.

nullptr in Visual C++? In native code?
Note that nullptr can be used in VS2005 and VS2008 only when compiled with /clr option which in not used for the most of the project types discussed of this Forum.

And nullptr should not be used for native code in VS2010. There is a __nullptr instead (Microsoft-specific keyword)

[laserlight]

And nullptr should not be used for native code in VS2010. There is a __nullptr instead (Microsoft-specific keyword)

Hmm... that is somewhat troublesome for native code that is intended to be portable though since nullptr is now a standard C++ keyword.

[VictorN]

Hmm... that is somewhat troublesome for native code that is intended to be portable though since nullptr is now a standard C++ keyword.

Well, I'm not a guru in the modern C++ features, but it is what and how I've understood it from MSDN:

The __nullptr keyword is a Microsoft-specific keyword that has the same meaning as nullptr, but applies to only native code. If you use nullptr with native C/C++ code and then compile with the /clr compiler option, the compiler cannot determine whether nullptr indicates a native or managed null pointer value. To make your intention clear to the compiler, use nullptr to specify a managed value or __nullptr to specify a native value.

[laserlight]

Well, I'm not a guru in the modern C++ features, but it is what and how I've understood it from MSDN:

Yeah, I read that MSDN entry before coming to my conclusion. That said, reading it again, I think that the way out is to simply use nullptr, but take care not to compile with /clr, which makes sense in my scenario since the code is intended to also be compiled by say, g++. Of course, in that case, your objection to TubularX's suggestion no longer holds.

[cilu]

nullptr is only available from VS2010.