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
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 */
prin
> 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
acore.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
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 + 15
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);
On Thu, 29 Dec 2011 13:12:19 -0800
Ian Lance Taylor wrote:
> Any gcc developer who feels that this proposal is a good idea, please
> chime in here.
>
> I personally do not feel it is worth the effort. It's easy to use a
> more powerful macro processor, such as m4, to generate your C code.
I a
i meant "general purpose" macro processor. sorry.
---
> Date: Thu, 29 Dec 2011 16:30:04 -0800
> Subject: Re: a nifty feature for c preprocessor
> From: james.denn...@gmail.com
> To: david.br...@hesbynett.no
> CC: ren_zokuke...@hotmail.com; gcc@gcc.gnu.org
.
>
> I'd tend to agree; we o
On Thu, Dec 29, 2011 at 1:50 PM, David Brown wrote:
> On 29/12/11 22:05, R A wrote:
>>
>>
>>> The gcc developers, and everyone else involved in the development
>>> of C as a language, are perhaps not superhuman - but I suspect
>>> their combined knowledge, experience and programming ability
>>> ou
R A writes:
>> This particular extension seems problematic when cross-compiling. In
>> what environment should the expressions be evaluated?
>
>
> why
> are you asking for a specific environment? it's coding convenience and
> elegance for coding in c itself. simplest case scenario is what i've
On 29/12/11 22:05, R A wrote:
The gcc developers, and everyone else involved in the development
of C as a language, are perhaps not superhuman - but I suspect
their combined knowledge, experience and programming ability
outweighs yours.
given. but do you have a consensus of the community that
> I personally do not feel it is worth the effort. It's easy to use a
> more powerful macro processor, such as m4, to generate your C code. The
> benefit of building a more powerful macro processor into the language
> proper seems minimal.
>
> This particular extension seems problematic when cross
> given. but do you have a consensus of the community that this
> feature is not worth including? i haven't even heard but from a few
> people saying that "it's not worth it because if it was, 'we're the
> ones to have thought about it'".
No, that's not what people are saying.
It's important to t
The idea sounds useful to me ..
Or perhaps introduce template into C :)
David
On Thu, Dec 29, 2011 at 1:12 PM, Ian Lance Taylor wrote:
> R A writes:
>
>>> The gcc developers, and everyone else involved in the development of C
>>> as a language, are perhaps not superhuman - but I suspect their
R A writes:
>> The gcc developers, and everyone else involved in the development of C
>> as a language, are perhaps not superhuman - but I suspect their combined
>> knowledge, experience and programming ability outweighs yours.
>
> given. but do you have a consensus of the community that this fea
> The gcc developers, and everyone else involved in the development of C
> as a language, are perhaps not superhuman - but I suspect their combined
> knowledge, experience and programming ability outweighs yours.
given. but do you have a consensus of the community that this feature is not
worth
On 29/12/2011 00:08, R A wrote:
And if you want portable pre-processing or code generation, use
something that generates the code rather than inventing tools and
features that don't exist, nor will ever exist. It is also quite
common to use scripts in languages like perl or python to generate
t
> And if you want portable pre-processing or code generation, use
> something that generates the code rather than inventing tools and
> features that don't exist, nor will ever exist. It is also quite common
> to use scripts in languages like perl or python to generate tables and
> other pre-calcu
On 28/12/11 21:57, R A wrote:
yes, i do realize that c preprocessor is but a text substitution tool
from days past when programmers where only starting to develop the
rudimentaries of high-level programming. but the reason i'm sticking
with the c preprocessor if the fact that code that i write f
On 28 December 2011 21:06, Jonathan Wakely wrote:
> On 28 December 2011 20:57, R A wrote:
>>
>> templates, i have no problem with, i wish there could be a C dialect that
>> can integrate it, so i wouldn't have to be forced to use C++ and all the
>> bloat that usually come from a lot of it's imple
On 28 December 2011 20:57, R A wrote:
>
> templates, i have no problem with, i wish there could be a C dialect that can
> integrate it, so i wouldn't have to be forced to use C++ and all the bloat
> that usually come from a lot of it's implementation (by that i mean a
> performance close to C i
yes, i do realize that c preprocessor is but a text substitution tool from days
past when programmers where only starting to develop the rudimentaries of
high-level programming. but the reason i'm sticking with the c preprocessor if
the fact that code that i write from it is extremely portable.
23 matches
Mail list logo
