[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