<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 2, 2010, at 3:50 PM, Kai Germaschewski wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">What is the reason for PetscTruth in the first place? Couldn't one just use bool -- from stdbool.h if available, and otherwise have petsc define it? I guess you might argue that petsc shouldn't invade non petsc-prefixed namespace, which I guess is a valid argument, on the hand one might consider that to just be petsc providing pretty much a standard type which is missing from the current environment. Or are there any Fortran-glue issues that prevent this?<br></blockquote><div><br></div> bool is not standard. There is old C, there is C99 (plus we put in PetscTruth long before C99) and there is c++ and we needed something for all of them that always works the same.</div><div><br><blockquote type="cite">
<br>There is PETSC_FLOAT and PETSC_DOUBLE, after all, but not PetscFloat,...<br></blockquote><div><br></div> Actually there is PetscScalar and PetscReal that can become various things depending on how PETSc is built. The reason for PETSC_FLOAT and PETSC_DOUBLE is so that binary IO has names for all the basic data types.</div><div><br><blockquote type="cite"><br>In general, I don't like having specific versions of what's basically a standard type (I don't like PETSC_NULL, either). If you're using just one library, maybe it's not that bad, but then there's herr_t, PetscErrorCode, ... for no (obvious to me) benefit.<br></blockquote><div><br></div> The reason that PETSC_NULL exists is that in the bad old days NULL used to be defined in different include files on different machines, thus if you just stuck NULL in a routine it might not be portable on some other system (without sticking another include in), maybe this problem is gone. PetscErrorCode is for code clarity, I think it really helps that error variables are not just declared as ints, you can see immediately what purpose it serves, that is actually the reason for several things.</div><div><br></div><div> Barry</div><div><br><blockquote type="cite">
<br>Anyway, I'd be in favor of at least a change to PetscBool.<br><br>--Kai<br><br><br><div class="gmail_quote">On Thu, Sep 2, 2010 at 3:56 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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
We use truth consistently PetscTruth and PETSC_TRUTH, we cannot have one be bool.<br>
<br>
For a long time I've wanted to replace all our uses of truth with bool but was afraid to make a change that pisses people off. That would resolve the problem.<br>
<font color="#888888"><br>
Barry<br>
</font><div><div></div><div class="h5"><br>
On Sep 2, 2010, at 2:04 PM, Satish Balay wrote:<br>
<br>
> On Thu, 2 Sep 2010, Chetan Jhurani wrote:<br>
><br>
>> Hi petsc-dev,<br>
>><br>
>> This is a minor enhancement request.<br>
>><br>
>> Using PETSC_TRUTH instead of PETSC_TRUE unintentionally will lead to<br>
>> unexpected results and annoying bugs. Seems like PETSC_TRUTH is<br>
>> a different enum value for enumerating data types and currently equals 9.<br>
>><br>
>> g++ does warn on comparing different enum types, but gcc does not (v4.3.0).<br>
>><br>
>> Any possibility of changing the name of PETSC_TRUTH to something<br>
>> that is far away from PETSC_TRUE?<br>
><br>
><br>
> Perhaps we should use PETSC_BOOL instead of PETSC_TRUTH..<br>
><br>
> Satish<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Kai Germaschewski<br>Assistant Professor, Dept of Physics / Space Science Center<br>University of New Hampshire, Durham, NH 03824<br>office: Morse Hall 245E<br>
phone: +1-603-862-2912<br>fax: +1-603-862-2771<br><br>
</blockquote></div><br></body></html>