In C++, since the compiler sees the entire class structure, making a
virtual function call is basically reading a function address from a
fixed offset in the virtual table, and jumping to that address. If,
however, the compiler would not see the class structure, it has no way
of knowing from the opaque pointer what this offset might be, without
doing more elaborate operations to resolve it.

Look, you seem to be hostile to Dynace. Don't use it.

All languages have trade offs. Dyance solves many
issues commonly known in the C++ world at the expense of, essentially,
causing all method calls to be virtual.

Blake McBride wrote:

sucks, C rules, and Dynace rules even more"? Your views about C vs. C++
may be shared among prejudiced C hackers, but they are not shared by me
(and many other C++ programmers, I'm sure).

Juha Nieminen wrote:
Blake McBride wrote:

snip

sucks, C rules, and Dynace rules even more"? Your views about C vs. C++
may be shared among prejudiced C hackers, but they are not shared by me
(and many other C++ programmers, I'm sure).

snip

Please take your prejudice against C programmers

to an advocacy group
somewhere. I doubt that the attitudes and opinions of Blake are any more
representative of C programmers than they are of C++ programmers. In
fact, many of us who program in C program in many other languages as
well, so we are no more C programmers than we are Java, Perl, XSLT or
anything else programmers.

ld wrote:
  You can simulate object-oriented programming in C to an extent, but
since the language has basically no support, it will inevitably be
rather "hacky" and complicated.

Wrong.

  I have yet to see a clean solution.

Do you _really_ know what is doable with C macros?

  I'm pretty sure you cannot resolve the proper format string to use
with printf() to print something you got as a macro parameter
(especially if that something is eg. a struct instantiation). I'm also
pretty sure you cannot eg. resolve whether a parameter is of an integral
or a non-integral type.

But this not OOP.

  So?

Brian Wood wrote:
Me too.  And for about the same reason I like the Boost Intrusive
containers as they give the option of not having a data member
that is incremented/decremented every time elements are added or
removed.

  As if one data member was that much of overhead...

On 15 juil, 21:04, Juha Nieminen <nos... at (no spam) thanks.invalid> wrote:

ld wrote:
  You can simulate object-oriented programming in C to an extent, but
since the language has basically no support, it will inevitably be
rather "hacky" and complicated.

Wrong.

  I have yet to see a clean solution.

Did you read the paper I mentioned?

http://cos.cvs.sourceforge.net/viewvc/cos/doc/cos_draft-dls09.pdf.gz

Do you _really_ know what is doable with C macros?

  I'm pretty sure you cannot resolve the proper format string to use
with printf() to print something you got as a macro parameter
(especially if that something is eg. a struct instantiation). I'm also
pretty sure you cannot eg. resolve whether a parameter is of an integral
or a non-integral type.

But this not OOP.

  So?

this thread is about OOP in/for C in the way of Dynace, not about C++
non-OOP features like generic (generative) programming. I have never
said that C macros can do the same as C++ template. My statement is
that they can do enough to implement clean _OOP_ in C.

BGB / cr88192 wrote:
I say, the "pixel" class does not need to exist in the first place.

  I don't want to sound rude, but it just sounds to me that you are
basing your design on the limitations of the programming language and
then rationalizing that it's "better" that way.

  I disagree with your statement. A "pixel" is a concept, and in OOP a
class is precisely what is used to describe a concept. You usually want
to abstract away the concept of "pixel" (because you don't want to eg.
fix the amount of color channels, bits-per-pixel, color channel
ordering, and so on, and instead you usually want to use an abstract
"pixel" concept where those details are hidden so that the outside code
won't depend on any single representation). There's certainly no harm in
defining a "pixel" as a class (well, not in C++ at least).

  Besides, the "pixel" class was just a simple example. I'm sure that
you can think of other similar examples where humongous amounts of small
objects are needed. Things like rational or complex numbers in some
math-heavy application comes to mind as another example.

Brian Wood wrote:
The part about each object having at least one pointer
pointing to it is not correct at least for the way I
use the Boost Intrusive containers.  The objects stored
in the containers are deleted by taking their addresses.

  You need *some* pointer to the object if you want to destroy it. If
you have dropped all pointers to it, then it's an orphan object which
you can't access anymore from anywhere (the only mechanism which can
still access it is a garbage collection engine).

  Even if you use an intrusive container, you are using pointers to the
objects, and they naturally take space.

Brian Wood wrote:
I'm disagreeing with your statement that "each object
has at least one pointer pointing to it."  Initially there
is a pointer pointing to the object, but then that pointer
is reused for another object.  The objects are stored in
intrusive containers. So for the most part (except
initially) there aren't any pointers to the object around.
When you're ready to delete the object, you take the
address of it.

  Exactly how do you take the address of a dynamically allocated object
you don't have a pointer to? Care to show some code?

  Rather obviously the intrusive container needs to store a pointer to
the object *somewhere*. It can't just drop the pointer and expect later
to be able to re-retrieve it by magic. That's just impossible.

  Even if you use an intrusive container, you are using pointers to the
objects, and they naturally take space.

Not pointers, but one pointer that points to each of the objects
for a little while.

  As long as the object lives, at least one pointer must point to it. If
no pointer pointed to the object, the object becomes unretrievable and
thus has been leaked (except by some garbage collection mechanism).

I'm not familiar with "intrusive containers", but if the object is
physically contained within the container (perhaps within an array),
the container wouldn't need to keep a pointer to it; it could
recompute the object's address at any time.

You can do surprising things with template metaprogramming (all at
compile time), such as linked lists (with many operations familiar from
lisp, such as getting the first element and the list tail, etc), binary
trees, resolving whether a given integer is prime or not...

but, there is another overlooked possibility:
a flat linear array of bytes...

as another has noted:
we can have an "image" class, not a "pixel" class...

Sure, but there is the run time aspect as well. If an
application adds a billion elements to a container and
then goes through them and eliminates all but 200,000
and you don't need to know the size of the container,
that's a lot of incrementing and decrementing that adds
nothing of value to the application. The point is that
if you don't need to know the size, having the option
to not have a member yields a slightly better application.
I use quite a few containers so as they say, "Every little
bit helps."