On Sat, Apr 16, 2011 at 23:50, Shiyuan <[email protected]> wrote:
It sounds reasonable to make the change but it's better to document it. I don't see the change in the change log and I am surprised that my code doesn't work any more.
I agree that it should be mentioned.
Or maybe handle the single character case specially so that there is no need to change the source code.
On the flip side, if someone writes some generic code that expects NULL termination and determines the buffer size based on some other criterion, they would have to write special code to handle the zero element case. I don't have much preference either way and would suggest PetscOptionsGetChar if the functionality was really important (I don't think it is because a character flag is almost certainly better represented using PetscOptionsGetEList).
Another question is that in the newer version, PetscTruth becomes PetscBool. I might need to switch between development version and current released version. But to change the source code back and forth is a headache. Is there any good way to handle this? Why don't do something like #define PetscTruth PetscBool in the petsc.h so that we do not need to change the source code. Any wrong with that approach?
You can certainly do that (typedef PetscBool PetscTruth; would be better), but there are often other more significant changes that make it awkward to support multiple versions at the same time. The reason for the change was confusion between PETSC_TRUE (the enum value of type PetscTruth) and PETSC_TRUTH (the enum value of type PetscDataType, indicates a value of type PetscTruth, this is not used by most users). If one of these was accidentally used in place of another, it would silently produce incorrect results which is the worst possible failure mode. Now there is PETSC_BOOL in PetscDataType so the problem goes away (you won't accidentally type PETSC_BOOL when you mean PETSC_TRUE).