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
