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>
