Re: New release of the Dynace OO extension to C
Blake McBride wrote:
Look, you seem to be hostile to Dynace. Don't use it.
I'm not hostile to Dynace. I'm hostile to your arguments in your
webpage badmouthing C++ for false reasons.
Exactly what do you expect when you come to a C++ group and promote
your own C extension and in your webpage you basically say that "C++
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).
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.
And, I assume, forcing each object to be allocated dynamically, making
the creation of objects slower and making them consume more memory.
Imagine you have something like this in C++:
class Pixel
{
unsigned char red, green, blue, alpha;
public:
// public methods here, none of which are virtual
};
Then you do something like this: std::vector<Pixel> image(10000000);
(and maybe initialize with some image data, or whatever).
In C++ that vector will consume about 40 megabytes of memory. How much
would the equivalent code in Dynace consume (using the same level of
abstraction, ie. no cheating by using a C struct as the Pixel type)?
Also, even with virtual methods, I don't see how you can have them as
fast as the ones in C++ given that, if I understood correctly, all
object pointers are completely opaque (as your webpage prominently
advertises, the entire class declaration is in the .c file rather than
in a header file, which would mean that object pointers must be
completely opaque, ie. the compiler does not see the class structure
when it makes a method call using that pointer).
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.