Re: New release of the Dynace OO extension to C
"Jerry Coffin" <jerryvcoffin@yahoo.com> wrote in message
news:MPG.24dbe07c70205633989717@news.sunsite.dk...
In article <h4t0kr$iul$1@news.albasani.net>, cr88192@hotmail.com
says...
[ ... ]
simple solution:
don't design API's this way...
each side of the API manages its own memory, and no memory or resource
ownership should be passed across this border.
The API in question was one for allocating memory. The rest of your
comments simply don't apply for such a thing.
using 'malloc' in the first place is its own set of issues...
as such, the general rule of thumb:
avoid (directly) using malloc...
it is possible to do so...
[ ... ]
the usual alternatives:
know what you are doing;
don't pass around resource ownership all over the place (there ARE ways
to
move data from place to place, without directly transporting resource
ownership);
...
virtualize the resources, and virtualize their access and transport, and
many of these management issues either lessen or go away.
That certainly sounds good -- at least in a world where hand-waving
generalizations cure real problems.
virtualizing things is a real, and workable, practice...
granted, garbage collection, and "allocate then bulk free", are typically
more convinient practices.
alloc then bulk free is a simple strategy:
any objects allocated are, firstly, done in a specialized heap;
allocations are kept track of;
when done, destroy any objects within this heap.
ownership does not transfer from this heap.
typically, when exiting the region of code for which this heap was created,
the whole thing is torn down...
Quake is a well known app which used a variation of this strategy (not true
of Doom 1/2 though, which used a different strategy, AKA, a custom allocator
they called Z_Malloc(), which had its role changed in Quake...).
[ ... ]
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".
by extension, this would be the case of C++ as well...
Not true, for the simple reason that the basis isn't true in C++.
Quite a bit of software developed in C++ doesn't appear to have any
memory management problems at all.
but, as stated, this would contridict the logic in play:
a C++ app necessarily contains dependencies on C code (in the form of
runtime libraries, the OS, ...).
for your claims to be correct, either:
a C++ app would have to contain leaks, due to the C code;
it is possible that C code does not contain leaks.
either way, the argument doesn't hold...
after all, Java was written in part with the intent to address these
sorts
of problems, in C++...
Certainly Sun has claimed they designed Java to cure problems in C++.
A large number of the problems they cited, however, are either
obviously imaginary, or not cured by Java at all. Somebody with a
vested interest in one product saying less than complimentary things
about a (perceived) competitor hardly qualifies as proof of anything.
now, you see the irony here?...
2) The improvement is hardly "incremental" -- in typical cases, it's
a lot _more_ than one order of magnitude improvement.
as you claim...
this claim, however, is not substantiated with any more than straw-men...
Rather the contrary -- it's substantiated with a couple of decades of
writing code myself, and looking at code other people have written.
but, yet, you write your code in C++, hmm...
just because you can accuse people of using generally horrid coding
practices, does not mean they actually do so by definition.
Oh calm down and try to deal with reality!
The basic problem being dealt with is pretty simple. In C, you run
into two problems. First of all, about the only thing C provides for
dealing with dynamic data is malloc/calloc/realloc/free. Second, it
makes it essentially impossible to centralize the use of those tools.
you don't particularly have to use them in the first place...
it is convinient to use them in some cases, but other options exist:
use a garbage collector, which typically gets memory from mmap or
VirtualAlloc;
write your own MM or GC, and use mmap or VirtualAlloc...
granted, one "can" leak with mmap or VA, but typically it is a very
different sort of leak (assuming the GC works correctly, it takes the form
of not releasing the space when the process exits, which is typically
handled by the OS).
once an app gets beyond a trivial scale, it is typical to largely forsake
malloc.
now, this does leave "other" resources, but luckily these tend to be much
easier to localize and isolate.
"well, you use C++, that means by default you like making hugely
tangled class heirarchies and #includ'ing your entire source tree
into a single file...", "don't deny it, we KNOW this is how people
write C++...", "that and with all the operator overloading on damn
near every class, and use of recursive templates...", ...
see the point?...
If "the point" is that you realize you've lost the argument based on
facts, and prefer to spout nonsense rather than admit you're wrong,
then yes. If there was supposed to be another point, you've failed to
make it.
who is pointing fingers here?...
firstly, what am I claiming?...
I am not claiming C is as convinient to use as C++, or that it provides all
the same niceties.
I am saying here, a person can use it, AND know what they are doing...
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.
but, is this actually necessary?...
or is it, rather, the case that one CAN get by without using it?...
In theory, you can also get by on simply being the world's greatest
genius, and always doing things perfectly with no help from the
language at all.
In reality, experience has shown that that approach just doesn't
work.
so says you...
one does not have to be a "genius", rather, there is a very different
strategy:
anality...
if one has rules which, if followed, will eliminate a problem, and they
follow them without fail, then the problem largely goes away...
it is much like how people can avoid the problems associated with
promiscuous behavior through a simple and effective stategy: abstinence...
abstinence works, for those who care to use it...
[ ... ]
partial reason:
because, at its core, C++ is based on C, and, essentially, manages the
resources in the same basic ways, and with the same basic issues.
I've already pointed out that this is just plain wrong. Repeating
your falsehood is NOT going to make it true.
[ ... ]
a task which can be done in one can, thus, be done in the other,
typically with only a modest difference in overall code size.
Oh what a load of horse hockey! Let's look at a truly trivial
example:
#include <string>
#include <set>
#include <algorithm>
#include <iterator>
#include <iostream>
int main() {
std::string line;
std::set<std::string> lines;
while (std::getline(std::cin, line))
lines.insert(line);
std::copy(lines.begin(), lines.end(),
std::ostream_iterator<std::string>(std::cout, "\n"));
return 0;
}
The problem statement is pretty simple: you need to read lines from
standard input, and then write the unique lines in sorted order to
standard output. The maximum line length and maximum number of lines
should be limited only by available memory.
Now, as shown above in C++, even if we include blank lines,
#include's, and so on, it's trivial to do that in less than 20 lines.
C just doesn't provide the tools to make this trivial at all. For
example, here's code just to read in a string of arbitrary size:
char *getstring(void) {
int ch;
size_t i;
static size_t bufsize = 0;
static char *buffer = NULL;
for (i = 0;((ch=getchar())!= EOF) && (ch!='\n')&&(ch!='\r'); ++i)
{
if (i + 1 > bufsize)
{
/* If buffer is full, resize it. */
char *temp = realloc(buffer, bufsize+BLOCKSIZ);
if (NULL==temp) {
puts("\agetstrng() - Insufficient memory");
/* Add terminator to partial string */
buffer[i] = '\0';
return buffer;
}
buffer = temp;
bufsize += BLOCKSIZ;
}
buffer[i] = (char)ch;
}
buffer[i] = '\0'; /* Tack on a null-terminator. */
return buffer;
}
All by itself, this is larger and more complex than the complete
program in C++. Then we need to write another very similar routine to
manage a dynamic array to hold the lines we read. Alternatively, we
could do like the C++ code does, and use a balanced tree of some sort
(R-B tree, AVL tree, etc.), but that's going to expand the code a LOT
more -- plan on around 100 lines of fairly tricky code just to do an
insertion in a balanced tree. As yet another alternative, you could
use a tree that doesn't attempt to keep itself balanced -- this will
keep the code a lot simpler at the expense of worst case performance
being roughly O(n*n) instead of O(n*log(n)).
if you don't know how to use C in the first place, it will bite you...
the bite goes away IF someone knows what they are doing...
once again, it comes down to a matter of badly written and badly designed
code.
the actual differences then, are not significant, rather, they are
modest...
See the example above -- the difference qualifies as at least
significant, and probably closer to "dramatic". Looked at from
another perspective, it's simply average -- about what we can expect
to see in a typical case.
straw men don't make your "facts" real either...
<snip>
not going to bother with the rest...