<br><br><div class="gmail_quote">On Wed, Nov 9, 2011 at 2:51 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
To summarize:<br>
<br>
In C we could do #define PETSC_NULL ((void*) 0) and every thing would be fine<br>
<br>
In C++ this won't work and there is no alternative except a standard that is 2 months old (but for those programming in C++ this is not really a problem because there is really no need for varargs in proper C++ code).<br>
<br>
Questions:<br>
1) Why won't it work in C++? Note that PETSC_NULL truly is suppose to always be used as a null pointer and should never be used as 0; if int 0 is intended then int 0 should be used.<br>
<br>
2) Can we at least fix it for C by using #define PETSC_NULL ((void*) 0) in C and using 0 in C++. After all nobody really uses PETSc from C++ :-)<br></blockquote><div><br></div><div>libMesh and MOOSE use PETSc from C++. If PETSc is compiled with a C compiler, then there should be no problem, unless the C++ code makes a call to one of PETSc's variadic functions, right?</div>
<div><br></div><div>Dmitry. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<span class="HOEnZb"><font color="#888888"><br>
Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Nov 9, 2011, at 2:26 PM, Jed Brown wrote:<br>
<br>
> #define PETSC_NULL 0<br>
><br>
> This is an "int" value, though it's special in that it will be implicitly converted to a null pointer (not even necessary bitwise 0, according to the standard) if its value is assigned to a pointer. If we pass it to a function with unspecified arguments (e.g. variadic), then it will be passed as an int.<br>
><br>
> We usually use PETSC_NULL in place of a pointer value. It is common for an entire pointer-length integer register to be used when passing an "int". Most architectures pass the first few arguments in registers before passing on the stack. We seem to be getting lucky so far in that we haven't used functions like DMCompositeGetAccess() on systems where sizeof(void*) != sizeof(int), with more arguments than are passed in registers.<br>
><br>
> C99 has stddef.h define NULL to be a null pointer constant ((void*)0). This is not compatible with C++ and I don't see a simple resolution.<br>
><br>
> It doesn't work in C++ because there is no implicit pointer conversion from void*. So instead of having a pointer-valued NULL like in C, they define NULL to be 0 or 0L, which is just an integer (unless assigned to a pointer in which case 0 is special and is converted implicitly).<br>
><br>
> Since it was 2011 and there was still no way to define a null pointer in C++, the new standard C++11 introduces a new keyword nullptr. Considering that we are still not allowed to use C99 in PETSc, it seems unlikely that we would be allowed to rely on C++11 which is less than two months old.<br>
><br>
><br>
> We could pass a "format string" indicating which entries we were actually requesting. Other ideas?<br>
<br>
</div></div></blockquote></div><br>