> > C. #if defined/undefined vs 0/1 issue
> >
> > I'm for ifdef/ifndef.
>
> For complex combinations of conditionals you have to write things like
>
> #if defined(A) || defined (B)
Sure. But I didn't precisely mean ifdef/ifndef. I was and am for
defined/undefined and used ifdef/ifndef there just as a shortcut.
I think I should clarify the problem.
The problem relates to the Configure script. Before running the script,
we could pass some configure options like --jitcapable=0 or --cgoto=1.
Plus we have some places in the script where we define compiler flags
like -DHAVE_COMPUTED_GOTO. And finally we set up some #defines
in config_h.in and feature_in.h like #define PARROT_HAS_MEMALIGN
However, as to source code, you have nothing to do to find disagreements
in there, like
in interpreter.c, line 27:
#ifdef HAVE_COMPUTED_GOTO
# include "parrot/oplib/core_ops_cg.h"
# include "parrot/oplib/core_ops_cgp.h"
#endif
in the same file, line 354
#if HAVE_COMPUTED_GOTO
oplib_init_f init_func = PARROT_CORE_CGP_OPLIB_INIT;
#else /* HAVE_COMPUTED_GOTO */
oplib_init_f init_func = PARROT_CORE_OPLIB_INIT;
#endif /* HAVE_COMPUTED_GOTO */
We aren't consistent and have got to fix that, anyhow, though we don't have
any design decision on that. We shall
replace -DHAS_JIT, -DHAVE_COMPUTED_GOTO,
-DGC_IS_MALLOC with something, but with what? Should it be either
#define PARROT_HAS_COMPUTED_GOTO
or
#define PARROT_HAS_COMPUTED_GOTO 0/1
? And so on. There is a pile of work. I don't argue that we have to make
those
alternations after P 010's been released, yeah it's so. But at first we
should
decide what we replace the disagreements with.
> > D. Function parametres in declarations.
> >
> > At the monent, pdd7 says that we mustn't omit them in declarations.
> > I propose to omit them. The advantage is: We wouldn't run the risk to
> > having a keyword of C++ as a parameter, we would have nothing
> > to coordinate with parameters in definitions. The drawback is: We would
> > lose a lot of helpful information that we could have obtained while
> > exploring
> > the headers.
>
> One solution is to put the parameters in /* comments */ in the
declarations.
So you propose the following
void internal_exception(int /* exitcode */, const char * /* format */, ...);
Hmm. I don't mind but still there are some shortcomings:
a) types like a pointer to something are mixing up with
comments.
b) It could punch a newbie in the stomach; so we would
be obliged to go and to add an expalanation into each header.
What's the other think?
Could I ask ya, Nicholas, a question that's out of place?
I ain't lurking about the p5p doings, so I am knida out of info,
anyway, has Ilya Zakharevich come back?
