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

[Barry Smith]

On Jun 24, 2008, at 9:03 AM, Lisandro Dalcin wrote:

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