Re: New release of the Dynace OO extension to C
"Nick Keighley" <nick_keighley_nospam@hotmail.com> wrote in message
news:4cf5346c-b48c-4b8f-a58d-ee7b3bfddc38@k19g2000yqn.googlegroups.com...
On 20 July, 18:24, "BGB / cr88192" <cr88...@hotmail.com> wrote:
"Richard Herring" <junk@[127.0.0.1]> wrote in message
news:8hHHVob6yJZKFwPM@baesystems.com...
In message <h4239d$2m...@news.albasani.net>, BGB / cr88192
<cr88...@hotmail.com> writes
"Jerry Coffin" <jerryvcof...@yahoo.com> wrote in message
news:MPG.24ce2fecee3a2ffd9896df@news.sunsite.dk...
In article <h40qt0$ac...@news.albasani.net>, cr88...@hotmail.com
says...
"Jerry Coffin" <jerryvcof...@yahoo.com> wrote in message
news:MPG.24cd80f124fbc9b39896de@news.sunsite.dk...
In article <h406la$h5...@news.albasani.net>, cr88...@hotmail.com
says...
[ ... ]
as I see it, malloc/free and new/delete are not "substantially"
different...
Then you're not seeing what's there.
what, in particular, are you pointing out?...
Constructors and destructors. Although they have no effect on the
internals of memory management, they completely change how you write
code that deals with dynamic structures (at least if you do the job
well at all).
and the question is this:
why not just do constructors and destructors in C?...
I do something analogous to this all the time...
there is an API call to create an object, and an API call to release an
object...
... which _you_ have the responsibility to call, no matter which path
of
execution is taken, or what exceptional case you're trying to handle.
that, or the object "can" be set to call the destructor from the garbage
collector, either way...
The difference is that in C++ you don't generally see any explicit code
to
_call_ the destructor. The runtime system does it for you whenever
dynamically-allocated objects are deleted or automatic ones go out of
scope, even if exceptions are thrown.
in C this is not so much an issue, since in C there are typically not
exceptions.
it has return though
Retval boggle (size_t chunk_size)
{
Environ *env = malloc(chunk_size);
if (env == NULL)
return MEMORY_ERROR;
if (!env_init (env, chunk_size))
return BAD_ENVIRON;
if (sleepy)
{
do_stuff(env);
if (grumpy)
{
do_more_stuff(env);
if (dopey (env))
{
/* no way! */
return BAIL_OUT;
}
sing (HI_HO_SONG);
cleanup(env, 2);
}
cleanup(env, 1);
}
free(env);
}
some clc-ers would put a goto in to ensure all the cleanup got done
properly. C++-ers don't have this problem 'cos env would be held
in a RAII object that would cleanup however the function was exited.
the above example is just sloppy...
but, yeah, one option to help with all this stuff, is to break up any large
functions such that, typically, there is only a single return point (so that
most operations are performed via function calls, and a single return point
is sufficient).
or, a paraphrased quote: "the tab spacing is 8 (and the line length is 80).
if a situation arises which makes it seem as if a smaller tab is needed,
then you should instead consider breaking up the function."
it also does good for code clenliness to break apart functions into small,
managable chunks. IMO, ideally, a typical individual function should not be
much more than 10-20 lines.
IMO, goto should be avoided unless there is good reason to use it...
there is, however, longjmp, but IME I have not had much real reason to
use
it...
never used it myself
I have used in a few rare cases, but usually it is much better to make
functions check, accept, and propagate error conditions.
int foo(...)
{
int i, j, k;
i=bar(...);
if(i<0)
{
//error state
}else
{
//good state
}
return(i);
}
<snip>