Re: polymorphic structs with "methods"
- From: ymuntyan@xxxxxxxxx
- Date: Mon, 24 Mar 2008 07:18:36 -0700 (PDT)
On Mar 23, 5:32 pm, Eric Sosman <esos...@xxxxxxxxxxxxxxxxxxxx> wrote:
Peter Michaux wrote:
/*
I want to have heterogeneous lists but treat all nodes the same
without checking some sort of struct "type" member and then using a
switch statement to call the appropriate function for that type. This
is in an effort to make my code more modular. Updating the switch
statement when a new "type" is added is not appealing. I've been
working on an idea (surely not original) about having polymorphic
struct "objects" that have function pointer members for "methods". My
code example is below and I would like to know where it sits in the
range from "hideous worst practice ever" to "yep people do that sort
of thing". If there are known improvements I could make I would
appreciate any comments, a link to a web page or book title.
*/
"Yep, people do that sort of thing." But in the rather
bare form you've presented, I think you'll find that you've
just traded one maintenance headache for another. You no
longer need to revisit all the switch statements when adding
a new type, but you *do* have to revisit all the existing
types when adding a new method. Also, as the repertoire of
methods grows, so too will the size of the Object struct and
the tedium of initializing each instance's pointers.
Some people have attacked both these problems by adding
one level of indirection. Instead of dragging all the function
pointers around in every instance, they carry just one pointer
to a single struct that contains all the method pointers for
the "class." For example,
[snip example code]
It is possible to use more elaborate schemes, too, which
may make it easier to manage "inheritance," dynamic creation of
new "classes," and so on.
However, I'd recommend against it. It's a kludge -- I don't
think there's any way to escape a lot of `void*' pointers and/or
a lot of casts, both of which are detrimental to type safety.
It's a kludge that was necessary a few decades ago, when C++
was a mish-mash of mutually incompatible semi-implementations
and Java hadn't been invented. But the toolchains are a lot
better than in the bad old days: C++ implementations are more
widespread and have converged toward their Standard, Java may
have been over-hyped at first but turns out to be quite useful,
and there are probably other languages that would meet most
reasonable sets of requirements.
Doing O-O in C is not putting lipstick on a pig -- C is not
a pig -- but it's a lot like teaching a pig to play the violin:
Just barely possible, perhaps, but not pleasing.
Very possible and very effective, see http://gnome.org.
But is often hard and unpleasant to deal with, certainly.
Yevgen
.
- References:
- polymorphic structs with "methods"
- From: Peter Michaux
- Re: polymorphic structs with "methods"
- From: Eric Sosman
- polymorphic structs with "methods"
- Prev by Date: Re: Strange problem with linked list code on windows OS
- Next by Date: Re: half edge data structure
- Previous by thread: Re: polymorphic structs with "methods"
- Next by thread: Re: polymorphic structs with "methods"
- Index(es):
Relevant Pages
|
