Re: So You Think You Can Const?

Julio Di Egidio <julio@diegidio.name> writes:
 [...]
 

Say my program unit implements AVL trees, with (conceptually
speaking) constructors/destructors, navigation and retrieval, and
of course manipulation (inserting, deleting, etc.).
>
My idea (but I would think this is pretty "canonical" and, if it
isn't, I am missing the mark) is:  my public functions take/give
"sealed" instances (with const members to const data), as the user
is not supposed to directly manipulate/edit the data, OTOH of
course my implementation is all about in-place editing...

 A better choice is to put the AVL code in a separate .c file,
and give out only opaque types to clients.  For example (disclaimer:
not compiled):
    // in "avl.h"
   typedef struct avl_node_s *AVLTree;
   // note that the struct contents are not defined in the .h file
    ... declare interfaces that accept and return AVLTree values ...
    // in "avl.c"
   #include "avl.h"
   struct avl_node_s {
     // whatever members are needed
   };
    ... implementation of public interfaces and any supporting
   ... functions needed
  I might mention that some people don't like declaring a type name
that includes the pointerness ('*') as part of the type.  I think
doing that is okay (and in fact more than just okay; better) in the
specific case where the type name is being offered as an opaque
type.
 Of course you could also make the opaque type be a pointer to a
'const' struct type, if you wanted to, but the extra "protection" of
const-ness doesn't add much, and might actually cost more than it
buys you because of the additional casting that would be needed.