June 2008 - petsc-dev - mailman3.cels.anl.gov

Re: change to petsc-dev
by Satish Balay 24 Jun '08

24 Jun '08

On Tue, 24 Jun 2008, Barry Smith wrote: > > I have pushed the change to PETSc-dev that eliminates the const from the > definition of XXXType (for example VecType). > In theory this should have minimal affects on your codes. The only change I > think you may need are changing, for example, > > VecType mt = MPIVEC; > > to > > const VecType mt = MPIVEC. I think we can avoid this change to user-code - if we do the following: #define VECMPI (char *)"mpi" [I guess the tradeoff is slightly less rigorous const check by the compiler] I tried this change with MatType - and looks like it requires a corresponding change of MatGetType() from: MatGetType(Mat mat,const MatType *type) to MatGetType(Mat mat,MatType *type) Satish

1 0

change to petsc-dev
by Barry Smith 24 Jun '08

24 Jun '08

I have pushed the change to PETSc-dev that eliminates the const from the definition of XXXType (for example VecType). In theory this should have minimal affects on your codes. The only change I think you may need are changing, for example, VecType mt = MPIVEC; to const VecType mt = MPIVEC. Please let me know immediately if you have trouble compiling PETSc after this change. If you are frantically writing your code for a midnight deadline you may want to forgo pulling PETSc until after your deadline on the tiny chance that this change breaks something and drives you insane. Thanks, Barry

1 0

Re: #define XXXType const char* ----> #define XXXType char* ?
by Lisandro Dalcin 24 Jun '08

24 Jun '08

On 6/24/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > I'll try to repeat why I do not want the const in MatType. (It's got > nothing to do with > a particular compiler). OK, now your use case is completelly clear to me. > MatType t; > > PetscMalloc(256*sizeof(char),&t); > PetscStrcpy(t,"mytypenamepart1"); > PetscStrcat(t,"someadditionalpart"); > MatSetType(mat,t); > > if MatType is defined as const char* or char const * (doesn't matter) > I cannot make the calls PetscStr.... because they change the values in t. But you can just declare 't' as: char *t; Of course, is this is not as explicit as 'MatType t;' , but I believe that the code you showed is going to appear inside PETSc internals, but not so much in user code. > I don't understand why you and Matt are so hung up on having the const > inside MatType. Can you explain? > (1) I think having to declare 'const XXXType t;' could be a bit ugly for end-users. Anyway, I do not expect user codes are going to call 'XXXGetType(obj, &t)' too much. (2) Backward compatibility. Of course, I know this is irrelevant. Then, go ahead with the change. > > > > > > > > > > > Barry, I do not understand what's going on with your compiler. > Perhaps > > > > > > my GCC is too old? (even when -Wwrite-strings is being passed ??) > > > > > > > > > > > > I've just changed the '#define' and used the 'typedef', and PETSc > > > > > > compile (configure.py ... && make) just passed without any > warning... > > > > > > Furthermore, 'make test' 'make testexamples' also passed just > fine. > > > > > > > > > > > > Perhaps my brain is not working well, but I do not see why all > this is > > > > > > an issue as long as the base PetscObject structure says 'char* > > > > > > type_name'. > > > > > > > > > > > > You can always build on a 'char*' (note: non-const) buffer what > you > > > > > > want, and pass it to VecSetType(), or perhaps just replace > 'type_name' > > > > > > in internal PETSc code. > > > > > > > > > > > > IMHO, user-level PETSc interface should be simple, even if that > iff > > > > > > internally PETSc has to relax a bit the rules (ie. using a 'char*' > > > > > > variable instead of a 'MatType' variable to build something like > the > > > > > > "seqsbaij" string from its pieces "seq", "s", "b", "aij"). > > > > > > > > > > > > Am I missing something? What do you actually want to do with > > > > > > > > > > > > > > > > > > 'type_name'? > > > > > > > > > > > > > > > > > > > > > > > > On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Mmm, just a bit ugly you have to add the 'const' keyword. I > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > insist: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > What would be the problem with ... ?? > > > > > > > > > > > > > > > > typedef const char* VecType; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Two problems. > > > > > > > > > > > > > > The VecType is a const which means one cannot build them on the > fly > > > > > > > > > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > > > > > > > > copy into them etc > > > > > > > > > > > > > > Second with the typedef one cannot do all the string > manipulation on > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > them. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > For example even the > > > > > > > PetscStrcpy() in PetscHeaderCreate_Private() of type_name does > not > > > > > > > > > > > > > > > > > > > > > > > > > work. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It would be nice to use a typedef instead of a define to build > it > > > > > > > > > > > > > > > > > > > > > > > > > but > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > it > > > > > > > > > > > > > > > > > > > > > > > > > > > > > looks impossible. (Try it, > > > > > > > just change one of them and try to compile PETSc, the screaming > is > > > > > > > relentless.) > > > > > > > > > > > > > > Barry > > > > > > > > > > > > > > > > > > > > > On Jun 23, 2008, at 2:38 PM, Lisandro Dalcin wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A while ago I made XXType (MatType, VecType etc) const char* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Well, you actually did > > > > > > > > > > > > > > > > #define VecType const char* > > > > > > > > > > > > > > > > instead of > > > > > > > > > > > > > > > > typedef const char* VecType; > > > > > > > > > > > > > > > > which IMHO is the right way. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I now think that was a mistake. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yep, the '#define' way can cause problems ;-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'd like to change them to just char* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But why not the 'typedef' way ?? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Can anyone suggest a technical reason why this is a bad idea > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > before > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > push > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the code? > > > > > > > > > > > > > > > > > > Note this means if you have code like > > > > > > > > > > > > > > > > > > VecType t = VECMPI; > > > > > > > > > > > > > > > > > > you would need to change it to > > > > > > > > > > > > > > > > > > const VecType t = VECMPI; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Lisandro Dalcï¿½n > > > > > > > > --------------- > > > > > > > > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (CIMEC) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (INTEC) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > (CONICET) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > > > > > > > > Tel/Fax: +54-(0)342-451.1594 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Lisandro Dalcï¿½n > > > > > > --------------- > > > > > > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a > (CIMEC) > > > > > > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica > (INTEC) > > > > > > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas > (CONICET) > > > > > > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > > > > > > Tel/Fax: +54-(0)342-451.1594 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Lisandro Dalcï¿½n > > > > --------------- > > > > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > > > > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > > > > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > > > > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > > > > Tel/Fax: +54-(0)342-451.1594 > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Lisandro Dalcï¿½n > > --------------- > > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > > Tel/Fax: +54-(0)342-451.1594 > > > > > > -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: #define XXXType const char* ----> #define XXXType char* ?
by Matthew Knepley 24 Jun '08

24 Jun '08

1) I have no problem with the changes since I think its not a big deal 2) Here is why I want const in the MatType, or others: If the purpose of giving the designation MatType is more than just a comment, then we would expect the program to 'type check' in some sense. This to me means that we do not allow invalid values in that type, meaning invalid type names. I wanted a service that would provide only valid type names or NULL. This does not seem easy so I am not pushing hard. Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener

1 0

Re: #define XXXType const char* ----> #define XXXType char* ?
by Barry Smith 24 Jun '08

24 Jun '08

On Jun 24, 2008, at 9:03 AM, Lisandro Dalcin wrote: > On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > >>> typedef char const* VecType; >>> >> No, because I do not want the const in the VecType!!!!! > > I believe you did not get it ;-). The const is not on the VecType, but > in the buffer, 'const' is places before the asterisk !! I understand this. It is totally irrelevant. > In short, > > typedef char const* VecType; (1) > > is NOT the same as > > typedef char* const VecType; (2) > > In particular (1) should be completelly equivalent to > > typedef const char* VecType; > > and then is what you want. Try it yourserlf, please... > >> The entire reason for this discussion is to remove the const from >> VecType. >> > > Granted, but having to push such a change just because a compiler > behaves extrangely is not the best thing to do IMHO. This has NOTHING to do with any compiler behaving strangely! > If we can just > find a way that make your compiler happy, then that would be the best > thing to do. > > Anyway, if you decide to push the fix, at leat let me know if the > option (1) works with your compiler, just because I'll have to manage > this change in the compatibility layers of petsc4py supporting > previous PETSc releases... I'll try to repeat why I do not want the const in MatType. (It's got nothing to do with a particular compiler). MatType t; PetscMalloc(256*sizeof(char),&t); PetscStrcpy(t,"mytypenamepart1"); PetscStrcat(t,"someadditionalpart"); MatSetType(mat,t); if MatType is defined as const char* or char const * (doesn't matter) I cannot make the calls PetscStr.... because they change the values in t. I don't understand why you and Matt are so hung up on having the const inside MatType. Can you explain? Barry > > > >>>> >>>>> Barry, I do not understand what's going on with your compiler. >>>>> Perhaps >>>>> my GCC is too old? (even when -Wwrite-strings is being passed ??) >>>>> >>>>> I've just changed the '#define' and used the 'typedef', and PETSc >>>>> compile (configure.py ... && make) just passed without any >>>>> warning... >>>>> Furthermore, 'make test' 'make testexamples' also passed just >>>>> fine. >>>>> >>>>> Perhaps my brain is not working well, but I do not see why all >>>>> this is >>>>> an issue as long as the base PetscObject structure says 'char* >>>>> type_name'. >>>>> >>>>> You can always build on a 'char*' (note: non-const) buffer what >>>>> you >>>>> want, and pass it to VecSetType(), or perhaps just replace >>>>> 'type_name' >>>>> in internal PETSc code. >>>>> >>>>> IMHO, user-level PETSc interface should be simple, even if that >>>>> iff >>>>> internally PETSc has to relax a bit the rules (ie. using a 'char*' >>>>> variable instead of a 'MatType' variable to build something like >>>>> the >>>>> "seqsbaij" string from its pieces "seq", "s", "b", "aij"). >>>>> >>>>> Am I missing something? What do you actually want to do with >> 'type_name'? >>>>> >>>>> On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >>>>> >>>>> >>>>>> >>>>>> >>>>>>> Mmm, just a bit ugly you have to add the 'const' keyword. I >> insist: >>>>>>> What would be the problem with ... ?? >>>>>>> >>>>>>> typedef const char* VecType; >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> Two problems. >>>>>> >>>>>> The VecType is a const which means one cannot build them on the >>>>>> fly >> and >>>>>> copy into them etc >>>>>> >>>>>> Second with the typedef one cannot do all the string >>>>>> manipulation on >>>>>> >>>>> >>>> them. >>>> >>>>> >>>>>> For example even the >>>>>> PetscStrcpy() in PetscHeaderCreate_Private() of type_name does >>>>>> not >> work. >>>>>> >>>>>> It would be nice to use a typedef instead of a define to build it >> but >>>>>> >>>>> >>>> it >>>> >>>>> >>>>>> looks impossible. (Try it, >>>>>> just change one of them and try to compile PETSc, the screaming >>>>>> is >>>>>> relentless.) >>>>>> >>>>>> Barry >>>>>> >>>>>> >>>>>> On Jun 23, 2008, at 2:38 PM, Lisandro Dalcin wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> A while ago I made XXType (MatType, VecType etc) const char* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Well, you actually did >>>>>>> >>>>>>> #define VecType const char* >>>>>>> >>>>>>> instead of >>>>>>> >>>>>>> typedef const char* VecType; >>>>>>> >>>>>>> which IMHO is the right way. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I now think that was a mistake. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Yep, the '#define' way can cause problems ;-) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I'd like to change them to just char* >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> But why not the 'typedef' way ?? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Can anyone suggest a technical reason why this is a bad idea >> before >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> I >>>> >>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> push >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> the code? >>>>>>>> >>>>>>>> Note this means if you have code like >>>>>>>> >>>>>>>> VecType t = VECMPI; >>>>>>>> >>>>>>>> you would need to change it to >>>>>>>> >>>>>>>> const VecType t = VECMPI; >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Lisandro Dalcï¿½n >>>>>>> --------------- >>>>>>> Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a >> (CIMEC) >>>>>>> Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica >> (INTEC) >>>>>>> Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas >> (CONICET) >>>>>>> PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina >>>>>>> Tel/Fax: +54-(0)342-451.1594 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Lisandro Dalcï¿½n >>>>> --------------- >>>>> Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a >>>>> (CIMEC) >>>>> Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica >>>>> (INTEC) >>>>> Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas >>>>> (CONICET) >>>>> PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina >>>>> Tel/Fax: +54-(0)342-451.1594 >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Lisandro Dalcï¿½n >>> --------------- >>> Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a >>> (CIMEC) >>> Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica >>> (INTEC) >>> Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) >>> PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina >>> Tel/Fax: +54-(0)342-451.1594 >>> >>> >> >> > > > -- > Lisandro Dalcï¿½n > --------------- > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 >

1 0

Re: #define XXXType const char* ----> #define XXXType char* ?
by Lisandro Dalcin 24 Jun '08

24 Jun '08

On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > typedef char const* VecType; > > > No, because I do not want the const in the VecType!!!!! I believe you did not get it ;-). The const is not on the VecType, but in the buffer, 'const' is places before the asterisk !! In short, typedef char const* VecType; (1) is NOT the same as typedef char* const VecType; (2) In particular (1) should be completelly equivalent to typedef const char* VecType; and then is what you want. Try it yourserlf, please... > The entire reason for this discussion is to remove the const from VecType. > Granted, but having to push such a change just because a compiler behaves extrangely is not the best thing to do IMHO. If we can just find a way that make your compiler happy, then that would be the best thing to do. Anyway, if you decide to push the fix, at leat let me know if the option (1) works with your compiler, just because I'll have to manage this change in the compatibility layers of petsc4py supporting previous PETSc releases... > > > > > > > Barry, I do not understand what's going on with your compiler. Perhaps > > > > my GCC is too old? (even when -Wwrite-strings is being passed ??) > > > > > > > > I've just changed the '#define' and used the 'typedef', and PETSc > > > > compile (configure.py ... && make) just passed without any warning... > > > > Furthermore, 'make test' 'make testexamples' also passed just fine. > > > > > > > > Perhaps my brain is not working well, but I do not see why all this is > > > > an issue as long as the base PetscObject structure says 'char* > > > > type_name'. > > > > > > > > You can always build on a 'char*' (note: non-const) buffer what you > > > > want, and pass it to VecSetType(), or perhaps just replace 'type_name' > > > > in internal PETSc code. > > > > > > > > IMHO, user-level PETSc interface should be simple, even if that iff > > > > internally PETSc has to relax a bit the rules (ie. using a 'char*' > > > > variable instead of a 'MatType' variable to build something like the > > > > "seqsbaij" string from its pieces "seq", "s", "b", "aij"). > > > > > > > > Am I missing something? What do you actually want to do with > 'type_name'? > > > > > > > > On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > > > > > > > > > > > > > > > > > > > Mmm, just a bit ugly you have to add the 'const' keyword. I > insist: > > > > > > What would be the problem with ... ?? > > > > > > > > > > > > typedef const char* VecType; > > > > > > > > > > > > > > > > > > > > > > > > > > > > Two problems. > > > > > > > > > > The VecType is a const which means one cannot build them on the fly > and > > > > > copy into them etc > > > > > > > > > > Second with the typedef one cannot do all the string manipulation on > > > > > > > > > > > > them. > > > > > > > > > > > > For example even the > > > > > PetscStrcpy() in PetscHeaderCreate_Private() of type_name does not > work. > > > > > > > > > > It would be nice to use a typedef instead of a define to build it > but > > > > > > > > > > > > it > > > > > > > > > > > > looks impossible. (Try it, > > > > > just change one of them and try to compile PETSc, the screaming is > > > > > relentless.) > > > > > > > > > > Barry > > > > > > > > > > > > > > > On Jun 23, 2008, at 2:38 PM, Lisandro Dalcin wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > A while ago I made XXType (MatType, VecType etc) const char* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Well, you actually did > > > > > > > > > > > > #define VecType const char* > > > > > > > > > > > > instead of > > > > > > > > > > > > typedef const char* VecType; > > > > > > > > > > > > which IMHO is the right way. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I now think that was a mistake. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yep, the '#define' way can cause problems ;-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'd like to change them to just char* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But why not the 'typedef' way ?? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Can anyone suggest a technical reason why this is a bad idea > before > > > > > > > > > > > > > > > > > > > > > > > > > I > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > push > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the code? > > > > > > > > > > > > > > Note this means if you have code like > > > > > > > > > > > > > > VecType t = VECMPI; > > > > > > > > > > > > > > you would need to change it to > > > > > > > > > > > > > > const VecType t = VECMPI; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Lisandro Dalcï¿½n > > > > > > --------------- > > > > > > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a > (CIMEC) > > > > > > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica > (INTEC) > > > > > > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas > (CONICET) > > > > > > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > > > > > > Tel/Fax: +54-(0)342-451.1594 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Lisandro Dalcï¿½n > > > > --------------- > > > > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > > > > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > > > > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > > > > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > > > > Tel/Fax: +54-(0)342-451.1594 > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Lisandro Dalcï¿½n > > --------------- > > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > > Tel/Fax: +54-(0)342-451.1594 > > > > > > -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: #define XXXType const char* ----> #define XXXType char* ?
by Barry Smith 23 Jun '08

23 Jun '08

On Jun 23, 2008, at 5:50 PM, Lisandro Dalcin wrote: > On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >> >> Here is my problem: (happens all over the code) >> >> argument of type "const char *" is incompatible with parameter of >> type >> "const VecType={char *} > > So you ARE NOT using GCC, right? It is the gcc that comes with the Mac. > > >> The problem seems to be that once I have created the new type (with >> typedef) the const now effects >> the variable (not the array that the variable points to). const >> char * >> means I can change the variable (pointer) >> but I cannot change the data it points to, which is what I want. > > Well, I'm not a C lawyer, but such a behavior really surprises me. > > Could you try instead this (note the inversion of type specifier > (char) and type qualifier (const)): > > typedef char const* VecType; > > I'm almost sure this is valid C++ (and completelly equivalent to the > former 'typedef const char* VecType'), but not so sure if it is valid > C89 or even C99. > > With a bit of luck, your compiler will be happy with this. And with > more testing on other compilers (wich I do not have access to, sorry!) > perhaps that could be the way to go?? No, because I do not want the const in the VecType!!!!! I want VecType to be char* and then (sometimes) to be able to add the const qualifier to it (which I cannot do with the typedef version). Barry The entire reason for this discussion is to remove the const from VecType. Barry > > > >> >>> Barry, I do not understand what's going on with your compiler. >>> Perhaps >>> my GCC is too old? (even when -Wwrite-strings is being passed ??) >>> >>> I've just changed the '#define' and used the 'typedef', and PETSc >>> compile (configure.py ... && make) just passed without any >>> warning... >>> Furthermore, 'make test' 'make testexamples' also passed just fine. >>> >>> Perhaps my brain is not working well, but I do not see why all >>> this is >>> an issue as long as the base PetscObject structure says 'char* >>> type_name'. >>> >>> You can always build on a 'char*' (note: non-const) buffer what you >>> want, and pass it to VecSetType(), or perhaps just replace >>> 'type_name' >>> in internal PETSc code. >>> >>> IMHO, user-level PETSc interface should be simple, even if that iff >>> internally PETSc has to relax a bit the rules (ie. using a 'char*' >>> variable instead of a 'MatType' variable to build something like the >>> "seqsbaij" string from its pieces "seq", "s", "b", "aij"). >>> >>> Am I missing something? What do you actually want to do with >>> 'type_name'? >>> >>> On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >>> >>>> >>>>> Mmm, just a bit ugly you have to add the 'const' keyword. I >>>>> insist: >>>>> What would be the problem with ... ?? >>>>> >>>>> typedef const char* VecType; >>>>> >>>>> >>>> >>>> Two problems. >>>> >>>> The VecType is a const which means one cannot build them on the >>>> fly and >>>> copy into them etc >>>> >>>> Second with the typedef one cannot do all the string manipulation >>>> on >> them. >>>> For example even the >>>> PetscStrcpy() in PetscHeaderCreate_Private() of type_name does >>>> not work. >>>> >>>> It would be nice to use a typedef instead of a define to build it >>>> but >> it >>>> looks impossible. (Try it, >>>> just change one of them and try to compile PETSc, the screaming is >>>> relentless.) >>>> >>>> Barry >>>> >>>> >>>> On Jun 23, 2008, at 2:38 PM, Lisandro Dalcin wrote: >>>> >>>> >>>> >>>>> On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >>>>> >>>>> >>>>>> >>>>>> A while ago I made XXType (MatType, VecType etc) const char* >>>>>> >>>>>> >>>>>> >>>>> >>>>> Well, you actually did >>>>> >>>>> #define VecType const char* >>>>> >>>>> instead of >>>>> >>>>> typedef const char* VecType; >>>>> >>>>> which IMHO is the right way. >>>>> >>>>> >>>>> >>>>>> I now think that was a mistake. >>>>>> >>>>>> >>>>> >>>>> Yep, the '#define' way can cause problems ;-) >>>>> >>>>> >>>>> >>>>> >>>>>> I'd like to change them to just char* >>>>>> >>>>>> >>>>> >>>>> But why not the 'typedef' way ?? >>>>> >>>>> >>>>> >>>>>> Can anyone suggest a technical reason why this is a bad idea >>>>>> before >> I >>>>>> >>>>> >>>> push >>>> >>>>> >>>>>> the code? >>>>>> >>>>>> Note this means if you have code like >>>>>> >>>>>> VecType t = VECMPI; >>>>>> >>>>>> you would need to change it to >>>>>> >>>>>> const VecType t = VECMPI; >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Lisandro Dalcï¿½n >>>>> --------------- >>>>> Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a >>>>> (CIMEC) >>>>> Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica >>>>> (INTEC) >>>>> Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas >>>>> (CONICET) >>>>> PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina >>>>> Tel/Fax: +54-(0)342-451.1594 >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Lisandro Dalcï¿½n >>> --------------- >>> Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a >>> (CIMEC) >>> Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica >>> (INTEC) >>> Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) >>> PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina >>> Tel/Fax: +54-(0)342-451.1594 >>> >>> >> >> > > > -- > Lisandro Dalcï¿½n > --------------- > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 >

1 0

Re: #define XXXType const char* ----> #define XXXType char* ?
by Lisandro Dalcin 23 Jun '08

23 Jun '08

On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Here is my problem: (happens all over the code) > > argument of type "const char *" is incompatible with parameter of type > "const VecType={char *} So you ARE NOT using GCC, righ? > The problem seems to be that once I have created the new type (with > typedef) the const now effects > the variable (not the array that the variable points to). const char * > means I can change the variable (pointer) > but I cannot change the data it points to, which is what I want. Well, I'm not a C lawyer, but such a behavior really surprises me. Could you try instead this (note the inversion of type specifier (char) and type qualifier (const)): typedef char const* VecType; I'm almost sure this is valid C++ (and completelly equivalent to the former 'typedef const char* VecType'), but not so sure if it is valid C89 or even C99. With a bit of luck, your compiler will be happy with this. And with more testing on other compilers (wich I do not have access to, sorry!) perhaps that could be the way to go?? > > > Barry, I do not understand what's going on with your compiler. Perhaps > > my GCC is too old? (even when -Wwrite-strings is being passed ??) > > > > I've just changed the '#define' and used the 'typedef', and PETSc > > compile (configure.py ... && make) just passed without any warning... > > Furthermore, 'make test' 'make testexamples' also passed just fine. > > > > Perhaps my brain is not working well, but I do not see why all this is > > an issue as long as the base PetscObject structure says 'char* > > type_name'. > > > > You can always build on a 'char*' (note: non-const) buffer what you > > want, and pass it to VecSetType(), or perhaps just replace 'type_name' > > in internal PETSc code. > > > > IMHO, user-level PETSc interface should be simple, even if that iff > > internally PETSc has to relax a bit the rules (ie. using a 'char*' > > variable instead of a 'MatType' variable to build something like the > > "seqsbaij" string from its pieces "seq", "s", "b", "aij"). > > > > Am I missing something? What do you actually want to do with 'type_name'? > > > > On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > > > > Mmm, just a bit ugly you have to add the 'const' keyword. I insist: > > > > What would be the problem with ... ?? > > > > > > > > typedef const char* VecType; > > > > > > > > > > > > > > Two problems. > > > > > > The VecType is a const which means one cannot build them on the fly and > > > copy into them etc > > > > > > Second with the typedef one cannot do all the string manipulation on > them. > > > For example even the > > > PetscStrcpy() in PetscHeaderCreate_Private() of type_name does not work. > > > > > > It would be nice to use a typedef instead of a define to build it but > it > > > looks impossible. (Try it, > > > just change one of them and try to compile PETSc, the screaming is > > > relentless.) > > > > > > Barry > > > > > > > > > On Jun 23, 2008, at 2:38 PM, Lisandro Dalcin wrote: > > > > > > > > > > > > > On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > > > > > > > > > > > > > A while ago I made XXType (MatType, VecType etc) const char* > > > > > > > > > > > > > > > > > > > > > > > Well, you actually did > > > > > > > > #define VecType const char* > > > > > > > > instead of > > > > > > > > typedef const char* VecType; > > > > > > > > which IMHO is the right way. > > > > > > > > > > > > > > > > > I now think that was a mistake. > > > > > > > > > > > > > > > > > > Yep, the '#define' way can cause problems ;-) > > > > > > > > > > > > > > > > > > > > > I'd like to change them to just char* > > > > > > > > > > > > > > > > > > But why not the 'typedef' way ?? > > > > > > > > > > > > > > > > > Can anyone suggest a technical reason why this is a bad idea before > I > > > > > > > > > > > > push > > > > > > > > > > > > the code? > > > > > > > > > > Note this means if you have code like > > > > > > > > > > VecType t = VECMPI; > > > > > > > > > > you would need to change it to > > > > > > > > > > const VecType t = VECMPI; > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Lisandro Dalcï¿½n > > > > --------------- > > > > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > > > > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > > > > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > > > > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > > > > Tel/Fax: +54-(0)342-451.1594 > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Lisandro Dalcï¿½n > > --------------- > > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > > Tel/Fax: +54-(0)342-451.1594 > > > > > > -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0

Re: #define XXXType const char* ----> #define XXXType char* ?
by Barry Smith 23 Jun '08

23 Jun '08

Here is my problem: (happens all over the code) argument of type "const char *" is incompatible with parameter of type "const VecType={char *} The problem seems to be that once I have created the new type (with typedef) the const now effects the variable (not the array that the variable points to). const char * means I can change the variable (pointer) but I cannot change the data it points to, which is what I want. Barry On Jun 23, 2008, at 3:51 PM, Lisandro Dalcin wrote: > Barry, I do not understand what's going on with your compiler. Perhaps > my GCC is too old? (even when -Wwrite-strings is being passed ??) > > I've just changed the '#define' and used the 'typedef', and PETSc > compile (configure.py ... && make) just passed without any warning... > Furthermore, 'make test' 'make testexamples' also passed just fine. > > Perhaps my brain is not working well, but I do not see why all this is > an issue as long as the base PetscObject structure says 'char* > type_name'. > > You can always build on a 'char*' (note: non-const) buffer what you > want, and pass it to VecSetType(), or perhaps just replace 'type_name' > in internal PETSc code. > > IMHO, user-level PETSc interface should be simple, even if that iff > internally PETSc has to relax a bit the rules (ie. using a 'char*' > variable instead of a 'MatType' variable to build something like the > "seqsbaij" string from its pieces "seq", "s", "b", "aij"). > > Am I missing something? What do you actually want to do with > 'type_name'? > > On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >>> Mmm, just a bit ugly you have to add the 'const' keyword. I insist: >>> What would be the problem with ... ?? >>> >>> typedef const char* VecType; >>> >> >> Two problems. >> >> The VecType is a const which means one cannot build them on the >> fly and >> copy into them etc >> >> Second with the typedef one cannot do all the string manipulation >> on them. >> For example even the >> PetscStrcpy() in PetscHeaderCreate_Private() of type_name does not >> work. >> >> It would be nice to use a typedef instead of a define to build it >> but it >> looks impossible. (Try it, >> just change one of them and try to compile PETSc, the screaming is >> relentless.) >> >> Barry >> >> >> On Jun 23, 2008, at 2:38 PM, Lisandro Dalcin wrote: >> >> >>> On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: >>> >>>> >>>> A while ago I made XXType (MatType, VecType etc) const char* >>>> >>>> >>> >>> Well, you actually did >>> >>> #define VecType const char* >>> >>> instead of >>> >>> typedef const char* VecType; >>> >>> which IMHO is the right way. >>> >>> >>>> I now think that was a mistake. >>>> >>> >>> Yep, the '#define' way can cause problems ;-) >>> >>> >>> >>>> I'd like to change them to just char* >>>> >>> >>> But why not the 'typedef' way ?? >>> >>> >>>> Can anyone suggest a technical reason why this is a bad idea >>>> before I >> push >>>> the code? >>>> >>>> Note this means if you have code like >>>> >>>> VecType t = VECMPI; >>>> >>>> you would need to change it to >>>> >>>> const VecType t = VECMPI; >>>> >>>> >>> >>> >>> >>> -- >>> Lisandro Dalcï¿½n >>> --------------- >>> Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a >>> (CIMEC) >>> Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica >>> (INTEC) >>> Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) >>> PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina >>> Tel/Fax: +54-(0)342-451.1594 >>> >>> >> >> > > > -- > Lisandro Dalcï¿½n > --------------- > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > Tel/Fax: +54-(0)342-451.1594 >

1 0

Re: #define XXXType const char* ----> #define XXXType char* ?
by Lisandro Dalcin 23 Jun '08

23 Jun '08

Barry, I do not understand what's going on with your compiler. Perhaps my GCC is too old? (even when -Wwrite-strings is being passed ??) I've just changed the '#define' and used the 'typedef', and PETSc compile (configure.py ... && make) just passed without any warning... Furthermore, 'make test' 'make testexamples' also passed just fine. Perhaps my brain is not working well, but I do not see why all this is an issue as long as the base PetscObject structure says 'char* type_name'. You can always build on a 'char*' (note: non-const) buffer what you want, and pass it to VecSetType(), or perhaps just replace 'type_name' in internal PETSc code. IMHO, user-level PETSc interface should be simple, even if that iff internally PETSc has to relax a bit the rules (ie. using a 'char*' variable instead of a 'MatType' variable to build something like the "seqsbaij" string from its pieces "seq", "s", "b", "aij"). Am I missing something? What do you actually want to do with 'type_name'? On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > Mmm, just a bit ugly you have to add the 'const' keyword. I insist: > > What would be the problem with ... ?? > > > > typedef const char* VecType; > > > > Two problems. > > The VecType is a const which means one cannot build them on the fly and > copy into them etc > > Second with the typedef one cannot do all the string manipulation on them. > For example even the > PetscStrcpy() in PetscHeaderCreate_Private() of type_name does not work. > > It would be nice to use a typedef instead of a define to build it but it > looks impossible. (Try it, > just change one of them and try to compile PETSc, the screaming is > relentless.) > > Barry > > > On Jun 23, 2008, at 2:38 PM, Lisandro Dalcin wrote: > > > > On 6/23/08, Barry Smith <bsmith(a)mcs.anl.gov> wrote: > > > > > > > > A while ago I made XXType (MatType, VecType etc) const char* > > > > > > > > > > Well, you actually did > > > > #define VecType const char* > > > > instead of > > > > typedef const char* VecType; > > > > which IMHO is the right way. > > > > > > > I now think that was a mistake. > > > > > > > Yep, the '#define' way can cause problems ;-) > > > > > > > > > I'd like to change them to just char* > > > > > > > But why not the 'typedef' way ?? > > > > > > > Can anyone suggest a technical reason why this is a bad idea before I > push > > > the code? > > > > > > Note this means if you have code like > > > > > > VecType t = VECMPI; > > > > > > you would need to change it to > > > > > > const VecType t = VECMPI; > > > > > > > > > > > > > > -- > > Lisandro Dalcï¿½n > > --------------- > > Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) > > Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) > > Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) > > PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina > > Tel/Fax: +54-(0)342-451.1594 > > > > > > -- Lisandro Dalcï¿½n --------------- Centro Internacional de Mï¿½todos Computacionales en Ingenierï¿½a (CIMEC) Instituto de Desarrollo Tecnolï¿½gico para la Industria Quï¿½mica (INTEC) Consejo Nacional de Investigaciones Cientï¿½ficas y Tï¿½cnicas (CONICET) PTLC - Gï¿½emes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

1 0