On 6/24/08, Barry Smith <bsmith at 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 at 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 at 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
