[Bf-committers] Casting arrays (matrices)

Ton Roosendaal bf-committers@blender.org
Thu, 3 Jul 2003 02:25:45 +0200


Hi,

Sorry, I got carried away with the topic too much! A difference between:

const float mat2[][3]
float const mat2[][3]

I was mixing up... :)

Anyhoo! My intention was to get the code compiled again without the  
warnings, and with valid prototypes in the code. Which is now the case  
(again!).

This was not a proposal for 'good' code, just a way to leave a part in  
Blender for what it is (warning free, simple readable code). It works,  
so move on to more important issues.

For the purists among us:

---------------
void blah( float *targ, const float src[][2])
{
   	printf("oh yeah baby\n");
}

void rtrt(void)
{
   float j[2][2];
   float t[3];

   blah(t, j);
}
-------------

Gives: warning: passing arg 2 of `blah' from incompatible pointer type.  
Removing the 'const' makes the compiler happy again. And me!

-Ton-



On Thursday, Jul 3, 2003, at 00:43 Europe/Amsterdam, Douglas Toltzman  
wrote:

> On Thu, 3 Jul 2003, Ton Roosendaal wrote:
>> Hi,
>>
>> So much passion over such a minor topic! :-)
>>
>> Of course I understand the advantage of a 'const char' string. I am
>> talking about something else here. Read this prototype for a function:
>>
>> void Mat3Invert(float mat1[][3], const float mat2[][3])
>>
>> Now here, some purist coder thought to be helpful. Instead he made an
>> error. The second matrix is not 'const' itself, but only the mat2
>> POINTER is! Well, is that interesting to know!
>>
>> I don't know why it gives warnings. Doesn't interest me. If you want  
>> to
>> add information to these calls, use a nice /* comment */
>>
>> And don't reply to this without checking every texbook you have on C!
>
> I take this as a personal challenge.  I have personally written over
> 1,000,000 lines of production C code in my 20 year career as a software
> developer.  I'm also a big user of the "const" modifier.  The prototype
> that you offered is saying that the contents of the mat2 array are not  
> to
> be modified, although I've had some trouble from the GNU compiler over
> this construct.  In order to say the pointer is not modifiable, one  
> would
> write "float const mat2[][3]".  If I am wrong it is only because I have
> managed to avoid the use of array constructs in prototype for most of  
> my
> life.  I would write the prototype as "const float *mat2" and document
> that mat2 pointed to an array of float triplets.  Personally, I find  
> the
> float pointer a lot easier to digest and manipulate.  Since C does  
> pointer
> arithmetic, it seems to me that the offset calculation is trivial.
>
> Alas, you can throw your book at me if you wish.  I taught C/C++
> programming at the university for long enough to discover that most of  
> the
> text books are seriously flawed because most authors are not seasoned
> programmers and good programmers don't have time to write books!
>
> I offer the following code for reference;
>
> #include <stddef.h>
>
> void move_floats( float *targ, const float *src, size_t numfloats )
> {
>   size_t i;
>   for (i=0; i < numfloats; i++) {
>     *targ++ = *src++;  /* note that the src pointer is being altered */
>   }
>   return;
> }
>
> int main()
> {
>   const float j[3]={1.5,2.3,4.6};
>   float t[3];
>
>   move_floats(t,j,sizeof(j)/sizeof(j[0]));
>
>   return 0;
> }
>
>
>>
>> -Ton-
>>
>>
>> On Wednesday, Jul 2, 2003, at 23:01 Europe/Amsterdam, Douglas Toltzman
>> wrote:
>>
>>> I'm with Maarten on this one.  If I gave you a prototype for a string
>>> copy
>>> function that read "strcyp(char *target,const char *source)" it would
>>> not
>>> only tell you that your source string wouldn't be modified, but it
>>> would
>>> allow the compiler to enforce that behavior.
>>>
>>> The "const" modifier is a great documentation feature, at the very
>>> minimum, and provides an additional level of protection from coding
>>> errors
>>> at best.  Incidentally, it also helps the optimizer.
>>>
>>> On Wed, 2 Jul 2003, Maarten Gribnau wrote:
>>>
>>>> Hi Ton
>>>>
>>>>> Reading the arithb.c code, I found that someone (NaN) has included  
>>>>> a
>>>>> lot of 'const' variables in the function declarations. I have
>>>>> absolutely no clue what it's good for. Originally, the code worked
>>>>> fine without, as still is in the MTC_matrixops.c version in
>>>>> source/blender/blenlib/
>>>>>
>>>>> I've removed the 'const' everywhere from arithb.c. The code  
>>>>> compiles
>>>>> quite a lot faster, with only a few and more useful warnings left.
>>>> How does the const cause trouble?
>>>> The const is actually useful. It tells you the function is not going
>>>> to
>>>> modify the variable (usually pointers and references in C++) passed  
>>>> to
>>>> it. It makes the variable an "in only" variable.
>>>>
>>>> Maarten
>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://www.blender.org/mailman/listinfo/bf-committers
>>>
>>>
>> ---------------------------------------------------------------------- 
>> --
>> --
>> Ton Roosendaal  Blender Foundation ton@blender.org
>> http://www.blender.org
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org  
http://www.blender.org