[petsc-dev] PETSC_TRUE and PETSC_TRUTH

[Kai Germaschewski]

On Thu, Sep 2, 2010 at 5:23 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

>
> On Sep 2, 2010, at 3:50 PM, Kai Germaschewski wrote:
>
> 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?
>
>
>    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.
>

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).


There is PETSC_FLOAT and PETSC_DOUBLE, after all, but not PetscFloat,...


   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.
>

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.


>
>
> 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.
>
>
>     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.
>

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... ;)

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....


-- 
Kai Germaschewski
Assistant Professor, Dept of Physics / Space Science Center
University of New Hampshire, Durham, NH 03824
office: Morse Hall 245E
phone:  +1-603-862-2912
fax: +1-603-862-2771
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100902/4a7ea16b/attachment.html>