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

[Barry Smith]

On Jun 23, 2008, at 5:50 PM, Lisandro Dalcin wrote:

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