#define XXXType const char* ----> #define XXXType char* ?

[Lisandro Dalcin]

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