Re: New release of the Dynace OO extension to C
On 21 July, 15:18, "BGB / cr88192" <cr88...@hotmail.com> wrote:
"Nick Keighley" <nick_keighley_nos...@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.co=
m
<snip>
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 pat=
h
of execution is taken, or what exceptional case you're trying to han=
dle.
<snip>
The difference is that in C++ you don't generally see any explicit c=
ode
to
_call_ the destructor. The runtime system does it for you whenever
dynamically-allocated objects are deleted or automatic ones go out o=
f
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
in other words even without exceptions you can get yourself into
trouble.
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...
really? why?
but, yeah, one option to help with all this stuff, is to break up any lar=
ge
functions such that,
I don't think that's large. I could have illustrated the point with
slightly less code.
typically, there is only a single return point (so that
most operations are performed via function calls, and a single return poi=
nt
is sufficient).
you may write with a single return point but it doesn't alone
solve the problem. If you are going to allocate multiple resources
then when things go wrong you've got to do cleanup. You *can* do
these things in C but it isn't always trivial.
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."
you're trying to say its too deeply nested aren't you?
I don't see it.
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.
like mine was...
IMO, goto should be avoided unless there is good reason to use it...
and this isn't one?
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);
return isn't a function call. You've picked an example with no
resaource allocation.
char *read_data (const char *data_file, size_t data_size)
{
FILE *dataf;
char *data;
int i;
dataf = fopen (data_file, "r");
data = malloc (data_size);
for (i = 0; i < data_size; i++)
data[i] = getc (dataf);
fclose(dataf);
return data;
}
how would you rewrite that?
}