Re: New release of the Dynace OO extension to C

In article <h4t0kr$iul$1@news.albasani.net>, cr88192@hotmail.com
says...

[ ... ]


The API in question was one for allocating memory. The rest of your
comments simply don't apply for such a thing.

[ ... ]
 


That certainly sounds good -- at least in a world where hand-waving
generalizations cure real problems.

[ ... ]
  


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.


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.


Rather the contrary -- it's substantiated with a couple of decades of
writing code myself, and looking at code other people have written.
 


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.


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.
 


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.

[ ... ]


I've already pointed out that this is just plain wrong. Repeating
your falsehood is NOT going to make it true.

[ ... ]


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)).
 


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.
 


It looks to me like you haven't seen enough about the subject mater
for your opinion on it to mean a whole lot. It's certainly true that
exception handling makes a difference (and that there's a very nice
synergy between exception handling and RAII) but it still seems to me
that you're missing most of the picture here.
 


Not a chance. While I've used both, I'm not particularly enthused
about either one, and I while I think completely manual memory
management is a poor idea, I don't think the GC in C# or (especially)
Java is all that much of an improvement.

At the risk of being accused of inappropriate similes again, I'd
liken memory management to being a bit like mowing a lawn.

In C, it's a bit like being forced to mow the lawn by crawling around
on your hands and knees, cutting each individual blade of grass to
the correct height with a hand clipper. It works all right for a
little while, and certainly gives you all the control you could
possibly want, but it's tedious and error prone at very best.

In C# or Java, they've gone to the opposite extreme -- a state-run
landscaping service that's going to landscape your yard as they see
fit, mow it exactly the way they want to as often (or rarely) as they
want to, leave you with no ability to do any of it, or even have the
slightest influence of what will be done.

C++ lets you hire a lawn mowing service (garbage collector) if you
want, or you can use your own lawn mower (RAII), or in those places
you really want to, you can clip individual blades by hand (manual
management).

[ ... ]


IOW, you're quite explicitly putting words in my mouth instead of
even making any real attempt at honesty at all.

--
    Later,
    Jerry.