"Sometimes GCC emits something that can be described as Haiku poems - and you have no clue as to what it really is complaining about. This page is a collection of such gems, their meaning in English and how to solve the problem."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-06
Member since:2005-07-06
It's not the degree of reflection in the language, but rather the syntax and semantics of the language. Java is explicitly designed to be parseable with an LALR(1) grammar. Parsing C++ is nearly impossible with conventional parser generators that are designed for LALR grammars. Also, the template syntax is very poorly suited for use in meta-programming, because it wasn't originally designed for that. It "evolved" from a simple generic programming facility into a meta-programming facility. When you combine all this with the fact that C++ tries very hard to maintain compatibility with the extremely primitive C linking model, you end up with the mess you have now.
It is entirely possible to design a macro (meta-programming) system that is powerful, simple, and relatively easy to implement. Between Scheme, Lisp, and Dylan, there are probably a couple of dozen good macro implementations in existence. In comparison, there are all of three C++ parsers that even come close to standards compliance, even despite the fact that there is probably a couple of orders of magnitude more effort put into C++ implementations than into implementations for those languages combined.
I'm going to use Dylan's macro system as a point of comparison, since the prefix syntax of Scheme and Lisp make macros much simpler to implement and easier to understand. However, it should be noted that these points apply almost universally to macro systems in all of these languages. The first thing the Dylan designers did right with the macro system is make the language LALR(1) parseable, including the macro sub-language. This means that you don't need to hand-write a complicated parser for the language, but you can instead use one of the array of tools that exist for dealing with LALR grammars. Second, they designed it explicitly for meta-programming, specified that basic syntactic constructs in the language (things like "for" loops) should be implemented as macros over more primitive constructs. This gave compiler writers a very strong incentive to make macro-expansion error messages really easy to understand, otherwise even simple syntax errors in loops would be incomprehensible. Third, Dylan compilers treat macros as first-class compile-time objects, and store a representation of the macro in the compiled output. Not only does this buy you the ability to export macros from shared libraries, but it gives the compiler a very clear separation between the single definition of the macro and uses of the macro. Fourth, and this is a point that ties back to the ease of implementation point, Dylan IDEs give you a way to see the code after macro-expansion. Almost all compile-time errors that result from calling a macro happen because the macro is used improperly in a way that causes invalid code to be generated. Looking at the expanded code usually makes it immediately obvious what you did wrong.
Member since:2005-07-20
Member since:
2005-07-06
Write some moderately complex code using Boost.Lambda, then make a typo. Just one, in an innocuous a place as you can find. G++ will just barf all over your shoes, and you won't be able to get the smell out for a week.
The complete illegibility of template expansion errors has killed any enthusiasm I had for Boost, or "modern C++" in general. Its not really the fault of the compilers, C++ templates are just a fundamentally crappy feature from an ease-of-use and ease-of-implementation point of view.
Edited 2007-03-09 21:36