. c param's don't support all of c's datatypes,
but they do function records
and then there's malloc .
1.8: adda/translate/exceptions:
what is the ada exception
doing in terms of c code?
. according to expert c,
c++ orig'ly avoided exceptions
apparently because they couldn't be impl'd without
slowing down even code that
wouldn't be using the feature .
. non-tricky code for a failure exception
seems to require that every call be
wrapped in an if-stmt:
was the return normal ? ok;
else which exception?
is there a handler? ok;
else raise again and exit .
. if there's no handler
that means needing to check for exceptions
even when the called has not declared any;
since to be modular,
the called should be able to change its body
including variations of
the exceptions it gets exposed to
and doesn't handle .
[1.9:
. the subunit doesn't have to declare these exceptions
and could be imported from another system,
so that the library being shared between
this subunit and its users,
need not support the subunit's exception
meaning that it's recognized only generically
as a [component fail].exception .
. another view is that when a binary is exported,
it implicitly brings along
binary versions of all its dependencies
into the importing lib .
. name clashes would be avoided by
keeping the import's dependencies local to
the subunit's package .
. in essence then,
the subunit's package is a sort of interface
and that interface would include
all exceptions possible during exec of the subunit .
. even when subunits are allowed to change their body
and in a way that changes their exceptions
all that means is that a user who
thought ...
[ a user is not going to think that without a
contract that asserts that;
]
. one interface that would not interfere with modularity
is having a subunit describe what exceptions it will handle
[ with each compile of its body,
the compiler can see what exceptions it decided to catch]
[1.9:
. the exception interface needs something more,
since one way that a sub' can fail
is by not handling the unexpected .
. so then when the contract includes
exception identification,
there should implicitly be the Unknown;
ie, if the sub' is caught by surprise,
and doesn't get to raise an exception from it's list,
then the default is the Unknown .
. if that is the case,
the caller can then test for system exceptions .
. but what if only a sub.block catches an exception?
getting back to c-code that does this efficiently:
. if all code could raise exceptions by
affecting a global
then catchers could check as often as they like
while the default would be to
only check the failure.global when the
system was giving more resources;
eg, during a call there is an act'rec malloc
... but that could cause an infinite loop
if the call was exit loop on success?
...
lost sight of what can actually happen .
. perhaps no efficient, simple way
to translate exceptions
unless not translating to c simply
but letting addm control the stack .
. just get used to the inefficiency of
having a number of well-placed checkpoints
eg, at the top of every loop and block
assertions are asking:
"(is the failure.exception raised? );
if yes then exit or return .
. it gets less inefficient when adda knows
the smart balance between checking too often
and doing too much work on a flat tire .
. another place where adda needs to be smart
is knowing how to divide routines into
pieces that allow wise time-slicing .
. these could be the same checkpoint blocks that
exceptions are built with .
. each thread needs its own fail.exception
then the root of each thread
either handles its failure
or propagates it to the fail.exception of parent thread .
1.15: adda/translate/private headers:
re 5.19(2009):
"(
. to make c more modular
use separate headers for public and private use .
. private can be done by
preceeding the header filename with an underscore .
. you're creating headers per file
even if not sharing
to declare what's in the file
and as forward referencing for mutual recursion .
)
. what would the point of this be?
there is no reuse in the privates
. there are 2 cases of privates:
#: declarations of functions
should be placed at the top of the file
of the top of the function that needs them .
#: definitions of nested functions
and aggregate init's can be bulky
so these can be separately filed and #include'd
. these private include's don't need
matching header files;
also, their names are limited only by the filesystem
not by what the linker will tolerate,
so name them fully; eg:
the first part should be the parent file
(the file that will be including it)
and the name's 2nd part should indicate what's inside .
. the grave.char "(`) can separate the 2 names
(sci:
. can a system's pre-processor choke on that?
I'm sure it should tolerate anything the os`fs will .
)
1.15: mis.adda/translate/use std c:
. never use defines to change the C language;
the point of adda is to avoid using std c;
the adda translater should assume
either the readers have no trouble with std c
or they will use the adda translation instead .
. that position obviated these 2009 ideas:
"(
5.19:) .
. to make c more understandable use #defines
to replace static with private .
5.22:
. instead of using & and * directly,
use macro's that give intent:
* = {IN, OUT, INOUT}
& = {RO, RW, WO}
5.25:
. to emulate an ada loop with exit in the middle
use a macro:
#define LOOP while(1)
then use break and continue as usual .
1.21: adda/translate/c modularity mechanisms:
bk"c by dissection/modularity,
bk.dev.c" steele/sto class specifiers,
bk.dev.c`lib/hints on good lib design,
bk.dev.c{c`lib, steele},
bk.dev.c"k&r/modular design .
hierarchical {project, scope} headers:
. each file is a scope:
private sub's are typed static,
a program using sub's from other files
will use an enviro header
to be included by itself and its child files
to share vars, types, functions, and decl's .
. libunit headers are for sharing one unit with another .
bk" steele` sto class specifiers:
. at top level, "(static) is used on both
var's and fun's to localize .
[... although fun's are usually localized by file,
static will be good for adda's plan to impl'
{exceptions, multi-tasking} by
breaking functions up into sequenced blocks .]
No comments:
Post a Comment