J
Jorgen Grahn
I'm mostly a C person, and I agree you have a point.
Whenever I have a nontrivial data structure, let's
call it struct bigmess, it's always accompanied by
"methods" struct bigmess *new_bigmess(), and
int delete_bigmess(), that I write myself and that
do all the ugly mallocing and freeing necessary,
hiding all that housekeeping from the rest of the
application. Lots of useful C++ ideas can be
incorporated into C design
But that's partly the thing I complain about above! If all you have is
struct bigmess *new_bigmess();
then every single struct bigmess in your program is individually
malloc()ed. Not much fun, especially if you have many small structs
and structs-within-structs rather than few big ones.
You can of course complement new_bigmess() with a
int init_bigmess(struct bigmess*);
so you can create them on the stack, in arrays or as parts of bigger
structs. This still doesn't solve the container problem though.
(but I don't want to
get into the naive argument, "then why use C?").
It's not naive (it's a good question) but it's something I try not to
bring up here. People who read c.l.c presumably want to read about C,
not about how some other language is better. (Knowing the shortcomings
of C compared to other languages is useful, though.)
/Jorgen