Q for C++ guru

Status
Not open for further replies.
S

stevech

Well-known member
I'm struggling with this:
I have vendor-supplied C++ code that I don't want to alter. It fails to compile its code such as
void foo (int alpha, uint8_t *p = NULL); // func prototype in .h file, method of a class.
Mostly to set the default for a parameter while declaring a function prototype in the C++ .h.

But today's C++ conventions define NULL as _NULL via <stdio.h> This enables each compiler vendor to define _NULL to suit, rather than the old value of 0. Motivation seemed to be gross misuse of NULL as 0 in pointers. Some implementations just define _NULL as 0. Others define it as a pointer to 0. The latter is what I struggle with, as C++ conventions for 0 differ from a pointer to a 0 such that an error is thrown for the line of code, above.

And stdio.h is usually not #included by generic library code as above. So, the library code has an #ifndef NULL and then defines it as a pointer, not a 0.

I watched the order of compilation of .c and .c++ files in this large project, 2 files are mine. Luckily, one of my files is first to compile. So I put #include <stdio.h> in my file and errors go away. But it's a kludge.

I don't know by what rationale the IDE (not a Makefile) chooses which file compiles first.

What's the right way to deal with all this so the not-my-library code will compile without error?
And... what's the modern/proper way to give 0 as the default value for a pointer parameter in a C++ function? (as the None type is in other languages). Maybe people use nullptr, so I've read, and stopped using NULL. But I can't prudently change what's in this vendor's code - used by thousands.
 
Last edited:
I'm more of a C expert than a C++ expert, but I tend to just eliminate using NULL in my own code:

Code: 
void foo (int alpha, uint8_t *p = (uint8_t *)0);

That way it is portable to old and new styles of writing code.

<edit>
I believe part of the issue is sort of a philosophy between C and C++. In C, if you define NULL to be (void *)0, it will convert to any type of pointer to data (but not function) without warning. C++ requires that you have an explicit conversion from void pointers to other data pointers.

If you go the extremes of what C allows, NULL no matter what the definition has a problem. Some of the word based machines in the past had different sized pointers (typically the native pointer was a word pointer, and then a byte pointer was formed with a word pointer and a separate field that was an index to the byte within the word). The two machines I know about that did this were PR1ME and Dec-10. I know Univac, Burroughs, and the original Cray machine had various issues with C, but I don't recall if they had different pointer sizes. Each machine that sent representation to the original X3J11 C standards meeting had various problems with C, some due to OS features (IBM, DEC), some due to different memory models (at the time the x86 world was 16-bit and the various compilers had near/far keywords), the various word oriented machines, one's complement arithmetic (UNIVAC), sign magnitude arithmetic (Burroughs), EBCDIC (IBM), 7-bit ISO 646 with European extensions (Denmark rep.), etc. Sometimes it is surprising that a standard was produced at all. It did take about 10 years.

If you had code of the form:

Code: 
#include <stdarg.h>
extern void callee (int, ...);

/* ... */

callee (5, NULL, 6);

On a machine with different sizes of pointers, when you pass NULL, do you pass a byte pointer or a word pointer.

The machine I wrote a C compiler front end for (Data General MV/Eclipse) was also a word based machine, but fortunately, it avoided the problem since byte and word pointers were the same size, but they had different formats. Fortunately, 0 meant NULL in either representation. In the DG, the word size was 16 bits, and the word pointer had a bit that did an automatic indirection, so when they added pointers to bytes, they shifted the word pointer left one bit, losing the indirection bit, and using the bottom bit to point to the byte.
 
Last edited:
Status
Not open for further replies.
Back
Top