[Bf-committers] Casting arrays (matrices)

[Douglas Toltzman]

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