<br><div class="gmail_quote">On Thu, Sep 2, 2010 at 5:23 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;">
<div style="word-wrap: break-word;"><br><div><div class="im"><div>On Sep 2, 2010, at 3:50 PM, Kai Germaschewski wrote:</div><br><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></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></blockquote><div class="im"><br>I know that bool is not standard (in plain old C). However, as you say, it is in C++ and C99, and in as extension in some older compilers. I have no doubt there was a good reason to introduce the type at the time, but that doesn't necessarily mean you have to keep carrying it along forever, in particular if you're changing the wording anyway. The one issue I do see is if an existing application has, e.g., typedef int bool; while the petsc header says typedef enum { false, true } bool; I'm not sure what the chances are of that happening -- and it wouldn't be hard to fix the application (unless they did something insane, like #define false 1).<br>
<br><blockquote type="cite">
<br>There is PETSC_FLOAT and PETSC_DOUBLE, after all, but not PetscFloat,...<br></blockquote><div><br></div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div style="word-wrap: break-word;"><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></blockquote><div><br>PetscScalar and PetscReal are there for very good reasons, they're not just a new name for a standard type. I think PETSC_FLOAT etc are also the right thing to do, I just wanted to say, you could do PETSC_BOOL just like them, you are not abstracting every type, just those where there's a need.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div class="im"><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></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></blockquote><div><br>I can imagine that, but I think, in particular with the involved config system, it would be easier to #define NULL ((void *)0) or whatever in a petsc header if it's really nowhere to be found (NULL is ANSI C, so I'm not sure you'll still find a system like that). Again, I think there may have been good reasons for it, but is it still required? I'm a big fan of libraries which make my life easier, but I like them to be non-intrusive. I see the point about PetscErrorCode, though I'd rather use int ierr; [many lines later] ierr = VecCreate(...), that is put that info into the variable name (btw, I've never been into Fortran, somehow I still call it ierr... ;)<br>
<br>Since we're at it, PetscInt I think has another similar issue, though I can well imagine for historical reasons it was the only viable solution. But I'd say it'd be much clearer to use PetscIndexType in those places where you need to, rather than a blanket: all ints are now 64bit....<br>
<br> <br></div></div>-- <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>