RE: a nifty feature for c preprocessor
i don't know if you're trying to be funny... but what's between the definition of N1 and the undef of A may be a very complex. it's just simplified for demonstration. > Date: Sun, 1 Jan 2012 00:42:16 -0500 > From: de...@adacore.com > To: ren_zokuke...@hotmail.com > CC: gcc@gcc.gnu.org > Subject: Re: a nifty feature for c preprocessor > > On 12/31/2011 4:44 AM, R A wrote: > > > > alright, here's another example why eval is a good idea: > > > > #define A 17 > > #define B 153 > > #define N1 ((A + B)/2) /* intended was (17 + 153)/2 */ > > > > #undef A > > #define A 230 > > #define N2 ((A + B)/2) /* intended was (230 + 153)/2 */ > > Bad example, this is a misuse of the preprocessor in any case!
RE: a nifty feature for c preprocessor
> i don't know if you're trying to be funny... > > but what's between the definition of N1 and the undef of A may be a very > complex. it's just simplified for demonstration. It's not good programming practice to have a macro (in this case A) have two different values, with an #undef between then.There are very few good reasons to use #undef, but that's not one of them. The reason is that when you look at the usage of the macro and want to find how it's defined, a search for the definition may come up with the wrong one.
Re: a nifty feature for c preprocessor
On 31/12/11 10:44, R A wrote:
alright, here's another example why eval is a good idea:
#define A 17 #define B 153 #define N1
((A + B)/2) /* intended was (17 + 153)/2 */
#undef A #define A 230 #define N2 ((A + B)/2) /*
intended was (230 + 153)/2 */
printf("%u %u", N1, N2);
sure, you can assign N1 to a static const, say N1_var, then invoke
that in when printf is finally called. or simply print N1, then after
the undef print N2. but what if we have to use both N1 and N2 in the
same conditional expression?? everybody should be aware by now that
there's a lot of ugly dependencies in cpp.
The best idea for something like this would be to use a static const (I
don't know why you dismissed that). Undefining and redefining your
macros like this is almost always a bad idea - it is far easier to
understand your program, and to write correct code, if macros mean one
thing and one thing only.
but for a *fairly complex*(1) conditional directives, spanning
several files, you have to call the macros all at the same time and
not one one-by-one. to get around it (if possible) is to employ an
even more complex system of defs and conditionals... or you can use
external scripts to generate the codes. but like i said, these could
just be small snippets of codes, where having scripts is
un-minimalistic. eval takes away all the ugliness.
(1) by fairly complex, i mean one that doesn't really merit a
script/macro processors to be written.
alright, if i can't convince the developers, would a maintainer (or
anybody that knosw their way around libcpp) please help me out on how
to get started my port for the feature... i actually don't like the
idea of writing a plugin.
Re: a nifty feature for c preprocessor
On 01/01/2012 12:42 AM, Robert Dewar wrote: On 12/31/2011 4:44 AM, R A wrote: alright, here's another example why eval is a good idea: #define A 17 #define B 153 #define N1 ((A + B)/2) /* intended was (17 + 153)/2 */ #undef A #define A 230 #define N2 ((A + B)/2) /* intended was (230 + 153)/2 */ Bad example, this is a misuse of the preprocessor in any case! why?
Re: LTO multiple definition failures
Sandra Loosemore writes: > > I'm still finding my way around LTO; can anyone who's more familiar > with this help narrow down where to look for the cause of this? I > don't even know if this is a compiler or ld bug at this point. I'm I would look into the interaction between the LTO plugin and your ld (and also try gold if you can) Generally there are still various issues in these areas which need workarounds in the LTOed programs, for some things (like ld -r and some ar) you also need the latest version of HJ Lu's binutils which implement http://gcc.gnu.org/ml/gcc/2010-12/msg00229.html A lot of older binutils lds also tended to mishandle mixed LTOed ar archives. -Andi -- a...@linux.intel.com -- Speaking for myself only
