Re: New release of the Dynace OO extension to C
"Brian Wood" <coal@mailvault.com> wrote in message
news:fbe99bda-74a8-40ee-a697-608812365516@v36g2000yqv.googlegroups.com...
On Jul 30, 2:21 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
In article <Podcm.46508$vp.1...@newsfe12.iad>, tec...@nospam.hia
says...
<snip>
That's not impossible in C and not hardly "an order of magnitude" better
in
C++ just because of RAII. It's just incrementatlly better in a number of
scenarios. But again, if C++ isn't an option, then it behooves one to
R&D
something(s) consistent for use in C.
1) Decades of experience has shown that while it's _theoretically_
possible to get it right in C, that in the entire history of C,
there's probably never been even one nontrivial program that didn't
have at least one memory management problem. For any practical
purpose, that qualifies as "impossible".
2) The improvement is hardly "incremental" -- in typical cases, it's
a lot _more_ than one order of magnitude improvement.
3) The number of scenarios where it provides a nontrivial improvement
is extremely large -- I'd say well over 90% of all typical code can
use RAII to manage the lifetime of most objects.
<--
I agree with the above except for the 90% figure. I don't
have anything to go on other than my opinion that RAII is
not as helpful in servers as in programs that run once and
exit. In run once programs I wouldn't argue with that
figure, but I don't consider those programs to be as
interesting as servers.
-->
yep, in the main cases it will help with, it is the cases where manual MM is
relatively trivial, thus serving as essentially a shortcut (not having to
manually free resources or invoke destructors).
OTOH, for the cases where manual MM becomes non-trivial (AKA: when one no
longer knows who owns an object, or where or how many references there are),
RAII wouldn't really help much either.
then, once again, it amounts to the same issue and solution as before:
don't transfer ownership.
it is like arguing the "fundamental" differences between, say:
class Foo {
public:
Foo(int x, double y);
virtual int foo(int x);
virtual int bar(double y);
private:
int x;
double y;
};
and:
typedef struct Foo_s Foo;
struct Foo_fs {
int (*foo)(Foo *ctx, int x);
int (*bar)(Foo *ctx, double y);
};
struct Foo_s {
struct Foo_fs *fcn;
int x;
double y;
};
there is a difference, but it is modest.
side by side, one would see endless minor differences in the code, but that
is the issue here:
minor...
Foo *foo;
foo=new Foo(3, 4);
vs:
foo=FooAlloc(3, 4);
delete foo;
vs:
FooDestroy(foo);
foo->foo(5);
vs:
foo->fcn->foo(foo, 5);
or:
FooFoo(foo, 5); //basically, it is common to wrap "vtable" calls as
well...
....
but, then again, the proir poster may well claim that the above would not
really be C, unless one directly uses malloc and stupidly loses the pointer
somewhere, but oh well...
part of the (apparently much despised) power of C, is that it becomes common
to wrap the language to some extent... (and, no, not with huge amounts of
macros or a custom preprocessor...).
the differences in language tend more to lead to a "different" set of
styles, where something approached one way in one language may be approached
a little differently in another.
it is like the differences between using function calls and operator
overloading:
without operator overloading, it is typical to use function calls instead.
one can note that a function call is not as terse as an operator, but both
accomplish essentially the same purpose...
and, yes, I really have built 1/2 of Common Lisp in C...