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: a nifty feature for c preprocessor
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. 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 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
On Thu, 29 Dec 2011 13:12:19 -0800
Ian Lance Taylor i...@google.com 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 agree with Ian, but with a small caveat. I feel that the (current GCC 4.6 or
trunk)
preprocessor has not enough plugin hooks. I think that adding enough plugin
hooks into the
preprocessor so that someone could (if he really wanted) develop a GCC plugin
which e.g.
interfaces some interpreter (e.g. Guile) to the preprocessor would be good.
I don't find R.A's proposal (eval in the preprocessor) interesting to me, but I
would like
GCC to offer enough plugin hooks so that we could reply: just make a GCC plugin
(and I
would add just make a MELT extension) to satisfy your dreams.
I would believe we cannot reply that to R.A today for GCC 4.6 (perhaps I am
wrong), and it
would be better if we could suggest him to make a GCC plugin, that is if a
future GCC
provided enough plugin hooks for that.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: a nifty feature for c preprocessor
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 tables and other pre-calculated values for inclusion in C code. though there are things that i will not disclose, i've never had to invent any tools for the project i'm working on everything is legit. this is the only time that i've had to. so believe me if i said i've considered all *conventional* solutions No, you haven't considered all conventional solutions. I've given you a couple of pointers. You are not the first person who wanted to include pre-calculated values in portable C code. Most modern compilers will do a pretty reasonable job of constant propagation and calculating expressions using constant values. And most will apply inline as you would expect, unless you intentionally hamper the compiler by not enabling optimisations. Using macros, incidentally, does not FORCE the compiler to do anything - I know at least one compiler that will take common sections of code (from macros or normal text) and refactor it artificial functions, expending stack space and run time speed to reduce code size. And immediate addressing is not necessarily a good optimisation - beware making generalisations like that. Let the compiler do what it is good at doing - generating optimal code for the target in question - and don't try to second-guess it. You will end up with bigger and slower code. i'm not one to share techniques/methodologies, 1) but if it's the case for more than, say 70%, of systems/processors and 2) it takes very little penalty; then i'd write it that way. if it's not optimized, just let the compiler (if it's as good as you say it is) re-optimize it. if the compiler ain't good enough to do that, well it's not a good compiler anyway. but the code will still work. I really don't want to discourage someone from wanting to contribute to gcc development, but this is very much a dead-end idea. I applaud your enthusiasm, but keep a check on reality - you are an amateur just starting C programming. C has been used for the last forty years - with gcc coming up for its 25th birthday this spring. If this idea were that simple, and that good, it would already be implemented. As you gain experience and knowledge with C (and possibly C++), you will quickly find that a preprocessor like you describe is neither necessary nor desirable. you know there's no way i can't answer that without invoking the wrath of the community. You are not expected to answer it - you are expected to accept it as reality. 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. Good luck with your project, but I strongly encourage you to find a different way to cope with your issues here. Work /with/ your tools, not against them.
RE: a nifty feature for c preprocessor
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 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'. computing science (may i call it a science??), is all about objectivity and examining the theories and evidence. it should be prepared re-examine everything when a new idea is introduced or challenged. so if it's a bad idea, explain to me exactly why; not go about human politics.
Re: a nifty feature for c preprocessor
R A ren_zokuke...@hotmail.com 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 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'. computing science (may i call it a science??), is all about objectivity and examining the theories and evidence. it should be prepared re-examine everything when a new idea is introduced or challenged. so if it's a bad idea, explain to me exactly why; not go about human politics. 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. The benefit of building a more powerful macro processor into the language proper seems minimal. This particular extension seems problematic when cross-compiling. In what environment should the expressions be evaluated? Ian
Re: a nifty feature for c preprocessor
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 i...@google.com wrote: R A ren_zokuke...@hotmail.com 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 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'. computing science (may i call it a science??), is all about objectivity and examining the theories and evidence. it should be prepared re-examine everything when a new idea is introduced or challenged. so if it's a bad idea, explain to me exactly why; not go about human politics. 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. The benefit of building a more powerful macro processor into the language proper seems minimal. This particular extension seems problematic when cross-compiling. In what environment should the expressions be evaluated? Ian
RE: a nifty feature for c preprocessor
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 take a high-level view of programming language design, including the role of the community. As Robert pointed out, proposals look a lot different when you get down into the details. One of the most complex issues in programming language design is the interaction between features. You can often have two features that seems quite simple individually, but have quite complex interactions. As Ian says in a later message, one issue with your proposal is that of how it interacts with cross-compilation. The hard part of programming language design isn't to come up with ideas for what to add to a programming language, since there are always dozens of them, but which ones make sense to add. For example, strict typing and built-in range checking are well-understood to be important language features, especially for safety-critical environments. But nobody would suggest adding them to every programming language. Deciding which things to add to a language isn't generally done by looking at whether the thing is a good idea or even if it's useful to the community, but by looking at the effect that adding it would have on the language overall. A large part of that takes into account the complexity and culture of the language. A language like C is meant to be very simple, with very few features. That's why there have been so few new features added to it in recent decades. On the other side, a language like Ada has numerous features, so every five years or so, a number of new features get added. But even there, significant care has to be taken as to what makes it in: many good ideas don't. In order to consider adding a new feature to a programming language, especially one like C that's been so stable over recent decades, the threshold is FAR higher than that the feature be useful or nifty. What you're hearing, from some of the best people in the world to make such a statement, is that what you propose doesn't come close to that threshold. You need to accept that. computing science (may i call it a science??), is all about objectivity and examining the theories and evidence. it should be prepared re-examine everything when a new idea is introduced or challenged. You are confusing programming language design with CS research. There are hundreds (if not thousands) of ideas from other programming language which are quite well accepted as valuable. But that doesn't mean that it makes sense to add any of them to the C programming language.
RE: a nifty feature for c preprocessor
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-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 already mentioned in my very first email. alright, i'll repeat myself (in case you haven't read the whole thread)... say you have different macros, FUNC_MACRO1, FUNC_MACRO2, FUNC_MACRO3, ... whichever macro to be used can be indexed 1, 2, 3... so forth. the index is conveniently described in an arithmetic expression, as it usually arises even if just programming in plain c. #define CONCAT(a, b) a##b #define CONCAT_VAR(a, b) CONCAT(a, b) #define FUNC_MACRO(N) CONCAT_VAR(FUNC_MACRO_, N) invoking with FUNC_MACRO(1), FUNC_MACRO(2), so forth... will work. but like i said, it's usually described by an arithmetic macro expression. so if you have this: #define N a + b/c and use it later on: FUNC_MACRO(N), will expand to: FUNC_MACRO_a + b/c which is wrong. it alleviates the need to write external files in, say, m4, even if the macro is just a few lines long; and having to go back and forth with another language (for us novices).
Re: a nifty feature for c preprocessor
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 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'. computing science (may i call it a science??), is all about objectivity and examining the theories and evidence. it should be prepared re-examine everything when a new idea is introduced or challenged. so if it's a bad idea, explain to me exactly why; not go about human politics. I don't speak for the gcc community - either for the users or the developers. But occasionally I can help out on this mailing list, and let the real developers get on with their work. There are a number of reasons why you wouldn't want an evaluation system as part of the C preprocessor (disregarding any thoughts about it being hard to do, impossible to standardise, and redundant given all the other ways to achieve the same ends). There is no standard environment for C. Should calculations be done as 32-bit integer? What about targets that use 16-bit integers (or even 64-bit integers)? You want to call the function eval - what about existing code that uses the word eval, either as a pre-processor macro or as part of the C code? You want to allow recursive macros - that opens a wide range of problems for getting consistency and clear definitions (and typically requires being able to define macros in at least two different ways - one recursive, one literal). You want to allow the evaluation of symbols and expressions by the preprocessor - that means it has to understand the syntax and semantics of these expressions, rather than just doing simple text manipulation. And it leads to more questions when macros and expressions are mixed - when do you do evaluation, and when do you do simple text expansion? How do you write macros that have the eval function in them? I don't expect or want any answers here - I don't think anybody is looking for a discussion aiming to implement the eval idea. I just want to point out that there are many, many questions involved here before anyone could even think about implementing it. And I don't think they could be resolved in a way that is consistent, practical, and adds anything to C or the C pre-processor that is not better handled by an external code generator or an independent macro language. No one wants to re-invent the wheel.
Re: a nifty feature for c preprocessor
R A ren_zokuke...@hotmail.com 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 already mentioned in my very first email. You are proposing a scheme in which the preprocessor can evaluate expressions and convert them back to strings. What are the types of the numbers in the expressions? What happens when they overflow? If the expressions use floating point values, are the floating point values in the host format or the target format? When converting a floating point value back to a string, what technique is used? Do we want to ensure that all preprocessors will get the same result? Or do we want to use values appropriate for the host? Or do we want to use values appropriate for the target? We can invent answers for these questions but I don't see any obvious answers. Some of the answers would impose significant amounts of extra implementation work for any C compiler. Hence, the extension is problematic. Ian
Re: a nifty feature for c preprocessor
On Thu, Dec 29, 2011 at 1:50 PM, David Brown david.br...@hesbynett.no 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 outweighs yours. 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'. computing science (may i call it a science??), is all about objectivity and examining the theories and evidence. it should be prepared re-examine everything when a new idea is introduced or challenged. so if it's a bad idea, explain to me exactly why; not go about human politics. I don't speak for the gcc community - either for the users or the developers. But occasionally I can help out on this mailing list, and let the real developers get on with their work. There are a number of reasons why you wouldn't want an evaluation system as part of the C preprocessor (disregarding any thoughts about it being hard to do, impossible to standardise, and redundant given all the other ways to achieve the same ends). The C preprocessor already includes evaluation of expressions, for conditional inclusion... There is no standard environment for C. Should calculations be done as 32-bit integer? What about targets that use 16-bit integers (or even 64-bit integers)? They can use the same rules they use today, no? This is already standardized. You want to call the function eval - what about existing code that uses the word eval, either as a pre-processor macro or as part of the C code? You want to allow recursive macros - that opens a wide range of problems for getting consistency and clear definitions (and typically requires being able to define macros in at least two different ways - one recursive, one literal). You want to allow the evaluation of symbols and expressions by the preprocessor - that means it has to understand the syntax and semantics of these expressions, rather than just doing simple text manipulation. The C preprocessor mostly manipulates tokens, not plain text. And it leads to more questions when macros and expressions are mixed - when do you do evaluation, and when do you do simple text expansion? How do you write macros that have the eval function in them? I certainly see problems with the eval proposal, both technical and otherwise. Technically, we could deal with it in much the same way as the defined preprocessing operator. Non-technically, the preprocessor is the wrong place for this functionality. I don't expect or want any answers here - I don't think anybody is looking for a discussion aiming to implement the eval idea. I just want to point out that there are many, many questions involved here before anyone could even think about implementing it. And I don't think they could be resolved in a way that is consistent, practical, and adds anything to C or the C pre-processor that is not better handled by an external code generator or an independent macro language. No one wants to re-invent the wheel. I'd tend to agree; we ought to move functionality _out_ of the preprocessor, not into it. -- James
RE: a nifty feature for c preprocessor
--- 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 ought to move functionality _out_ of the preprocessor, not into it. -- James honestly, i'm not against the idea of mandating m4, or any macro processor, with every C compiler. if it improves compatibility with everyone, then i'm in... (but that would be TOO FAR ahead).
RE: a nifty feature for c preprocessor
i meant general purpose macro processor. sorry.
RE: a nifty feature for c preprocessor
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. copy the code and you can use it in any IDE or stand-alone compiler, it's as simple as that. i have considered using gnu make, writing scripts with m4 and other parsers or lexers, but sticking with the preprocessor's minimalism is still too attractive an idea. about the built in features in c and C++ to alleviate the extensive use for the preprocessor, like inline functions, static consts. the fact is NOT ALL compilers out there would optimize a function so that it will not have to use a return stack. simply using a macro FORCES the compiler to do so. the same goes for static const, if you use a precompiled value, you are forcing an immediate addressing, something of a good optimization. so it's still mostly an issue of portability of optimization. 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 think is very possible for C++'s library). but, of course, one has to ask if you're making your code portable to any C compiler, why do you want gcc to change (or modify it for your own use)? you should be persuading the c committee. well, that's the thing, it's harder to do the latter, so by doing this, i can demonstrate that it's a SIMPLE, but good idea. Date: Wed, 28 Dec 2011 10:57:28 +0100 From: da...@westcontrol.com To: ren_zokuke...@hotmail.com CC: gcc@gcc.gnu.org Subject: Re: FW: a nifty feature for c preprocessor On 28/12/2011 07:48, R A wrote: i'm an amateur programmer that just started learning C. i like most of the features, specially the c preprocessor that it comes packed with. it's an extremely portable way of implementing metaprogramming in C. though i've always thought it lacked a single feature -- an evaluation feature. I think you have missed the point about the C pre-processor. It is not a metaprogramming language - it is a simple text substitution macro processor. It does not have any understanding of the symbols (except for #) in the code, nor does it support recursion - it's pure text substitution. Your suggestion would therefore need a complete re-design of the C pre-processor. And the result is not a feature that people would want. Many uses of the C pre-processor are deprecated with modern use of C and C++. Where possible, it is usually better programming practice to use a static const instead of a simple numeric #define, and a static inline function instead of a function-like macro. With C++, even more pre-processor functionality can be replaced by language features - templates give you metaprogramming. There are plenty of exceptions, of course, but in general it is better to use a feature that is part of the language itself (C or C++) rather than the preprocessor. It looks like you are wanting to get the compiler to pre-calculate results rather than have them calculated at run-time. That's a good idea - so the gcc developers have worked hard to make the compiler do that in many cases. If your various expressions here boil down to constants that the compiler can see, and you have at least some optimisation enabled, then it will pre-calculate the results. If you have particular need of more complicated pre-processing, then what you want is generally some sort of code generator. C has a simple enough syntax - write code in any language you want (C itself, or anything else) that outputs a C file. I've done that a few times, such as for scripts to generate CRC tables. And if you really want to use a pre-processing macro style, then there are more powerful languages suited to that. You could use PHP, for example - while the output of a PHP script is usually HTML, there is no reason why it couldn't be used as a C pre-processor. say i have these definitions: #define MACRO_1 (x/y)*y #define MACRO_2 sqrt(a) #define MACRO_3 calc13() #define MACRO_15 (a + b)/c now, all throughout the codebase, whenever and whichever of MACRO_1, or MACRO_2 (or so forth) needs to be called, they are conveniently indexed by another macro expansion: #define CONCAT(a, b) a##b #define CONCAT_VAR(a, b) CONCAT(a, b) #define MASTER_MACRO(N) CONCAT_VAR(MACRO_, N) now, if we use MASTER_MACRO with a direct value: MASTER_MACRO(10) or #define N 10 MASTER_MACRO(10) both will work. but substitute this with: #define N ((5*a)/c + (10*b)/c + ((5*a) % c + (10*b) % c)/c) and MASTER_MACRO expands to: MACRO_((5*a)/c + (10*b)/c + ((5*a) % c + (10*b) % c)/c) which,
Re: a nifty feature for c preprocessor
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 think is very possible for C++'s library). What bloat? If you only use the subset of C++ that is compatible with C++ then you don't get any additional cost, you are not forced to use anything, or to get any mythical bloat but, of course, one has to ask if you're making your code portable to any C compiler, why do you want gcc to change (or modify it for your own use)? you should be persuading the c committee. well, that's the thing, it's harder to do the latter, so by doing this, i can demonstrate that it's a SIMPLE, but good idea. It's not simple, or IMHO a good idea.
Re: a nifty feature for c preprocessor
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 from it is extremely portable. copy the code and you can use it in any IDE or stand-alone compiler, it's as simple as that. i have considered using gnu make, writing scripts with m4 and other parsers or lexers, but sticking with the preprocessor's minimalism is still too attractive an idea. If you want portable, use features that already exist. Lots of people write lots of C code that is portable across huge ranges of compilers and target processors. 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-calculated values for inclusion in C code. about the built in features in c and C++ to alleviate the extensive use for the preprocessor, like inline functions, static consts. the fact is NOT ALL compilers out there would optimize a function so that it will not have to use a return stack. simply using a macro FORCES the compiler to do so. the same goes for static const, if you use a precompiled value, you are forcing an immediate addressing, something of a good optimization. so it's still mostly an issue of portability of optimization. Most modern compilers will do a pretty reasonable job of constant propagation and calculating expressions using constant values. And most will apply inline as you would expect, unless you intentionally hamper the compiler by not enabling optimisations. Using macros, incidentally, does not FORCE the compiler to do anything - I know at least one compiler that will take common sections of code (from macros or normal text) and refactor it artificial functions, expending stack space and run time speed to reduce code size. And immediate addressing is not necessarily a good optimisation - beware making generalisations like that. Let the compiler do what it is good at doing - generating optimal code for the target in question - and don't try to second-guess it. You will end up with bigger and slower code. 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 think is very possible for C++'s library). C++ does not have bloat. The only feature of C++ that can occasionally lead to larger or slower code, or fewer optimisations, than the same code in C is exceptions - if you don't need them, disable them with -fno-exceptions. Other than that C++ is zero cost compared to C - you only pay for the features you use. but, of course, one has to ask if you're making your code portable to any C compiler, why do you want gcc to change (or modify it for your own use)? you should be persuading the c committee. well, that's the thing, it's harder to do the latter, so by doing this, i can demonstrate that it's a SIMPLE, but good idea. It's not a good idea, and it would not be simple to implement. I really don't want to discourage someone from wanting to contribute to gcc development, but this is very much a dead-end idea. I applaud your enthusiasm, but keep a check on reality - you are an amateur just starting C programming. C has been used for the last forty years - with gcc coming up for its 25th birthday this spring. If this idea were that simple, and that good, it would already be implemented. As you gain experience and knowledge with C (and possibly C++), you will quickly find that a preprocessor like you describe is neither necessary nor desirable. mvh., David Date: Wed, 28 Dec 2011 10:57:28 +0100 From: da...@westcontrol.com To: ren_zokuke...@hotmail.com CC: gcc@gcc.gnu.org Subject: Re: FW: a nifty feature for c preprocessor On 28/12/2011 07:48, R A wrote: i'm an amateur programmer that just started learning C. i like most of the features, specially the c preprocessor that it comes packed with. it's an extremely portable way of implementing metaprogramming in C. though i've always thought it lacked a single feature -- an evaluation feature. I think you have missed the point about the C pre-processor. It is not a metaprogramming language - it is a simple text substitution macro processor. It does not have any understanding of the symbols (except for #) in the code, nor does it support recursion - it's pure text substitution. Your suggestion would therefore need a complete re-design of the C pre-processor. And the result is not a feature that people would want. Many
RE: a nifty feature for c preprocessor
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-calculated values for inclusion in C code. though there are things that i will not disclose, i've never had to invent any tools for the project i'm working on everything is legit. this is the only time that i've had to. so believe me if i said i've considered all *conventional* solutions Most modern compilers will do a pretty reasonable job of constant propagation and calculating expressions using constant values. And most will apply inline as you would expect, unless you intentionally hamper the compiler by not enabling optimisations. Using macros, incidentally, does not FORCE the compiler to do anything - I know at least one compiler that will take common sections of code (from macros or normal text) and refactor it artificial functions, expending stack space and run time speed to reduce code size. And immediate addressing is not necessarily a good optimisation - beware making generalisations like that. Let the compiler do what it is good at doing - generating optimal code for the target in question - and don't try to second-guess it. You will end up with bigger and slower code. i'm not one to share techniques/methodologies, 1) but if it's the case for more than, say 70%, of systems/processors and 2) it takes very little penalty; then i'd write it that way. if it's not optimized, just let the compiler (if it's as good as you say it is) re-optimize it. if the compiler ain't good enough to do that, well it's not a good compiler anyway. but the code will still work. I really don't want to discourage someone from wanting to contribute to gcc development, but this is very much a dead-end idea. I applaud your enthusiasm, but keep a check on reality - you are an amateur just starting C programming. C has been used for the last forty years - with gcc coming up for its 25th birthday this spring. If this idea were that simple, and that good, it would already be implemented. As you gain experience and knowledge with C (and possibly C++), you will quickly find that a preprocessor like you describe is neither necessary nor desirable. you know there's no way i can't answer that without invoking the wrath of the community.
