[petsc-dev] PETSC_TRUE and PETSC_TRUTH

[Barry Smith]

On Sep 2, 2010, at 5:08 PM, Kai Germaschewski wrote:

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

   What if a library some user uses does insane things like #define false 1, they can change their applications but they can't change all the libraries they use.  The bool in C99 and C++ are not the same. Like with NULL I submit you could get something to work almost all the time but we need all the time hence we have to do something special. I agree it would be better if bool just works but I cannot get it to always work.
> 
>> 
>> 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).

  What happens if some user includes the include that defines NULL after they include the PETSc includes, then you get a no-compile. Plus there are more combinations of trouble. I agree it would definitely be ideal to use NULL instead of PETSC_NULL but NULL has never been properly standardized and I submit that it is essentially impossible to always get the work arounds to work. Yes you could get a work around that worked almost always but I submit that only PETSC_NULL always works and that is what we need.

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

   It is pretty much everywhere you would need to put PetscIndexType and that is too cumbersome to use. 

   Barry

> 
>  
> -- 
> 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/3adb904f/attachment.html>