"Both C and Lisp will be available as system programming languages."
- From the GNU manifesto
Maybe just implement GCC in Lisp? Or am I just nitpicking?
GCC starts move towards implementation in C++
11–20 of 37 posts
Re: GCC starts move towards implementation in C++
#12Yes, they just allowed it. They're not going to rewrite gcc in C++. But still, why, oh why? Eventhough C++ allows, in some cases, the possibility to use easier syntax for certain constructs, it's not particularly more expressive language than C. I don't know gcc codebase but if they decided to actually reimplement something in C++, it would take a lot of time just to make it comparable to the current C implementation…
...because large-scale C projects end up reinventing C++ features in a more complicated, error-prone way.
C++ is much more expressive than C. It can compete on equal terms with other high-level OO languages, it has some functional features and it contains all of C. On the downside, it's difficult to learn and takes much time to become proficient in.
Once you become proficient there's no contest.
Re: GCC starts move towards implementation in C++
#13I find this statement particularly interesting: For example, I think constructors and destructors are pretty easy and hard to misuse. Now, I am aware that the competence of the average GCC committer probably exceeds that of the average programmer, but still, constructors and destructors are easy to misuse: throwing an exception in the constructor comes to mind, in which case the destructor isn't called. Anything abou…
Interesting indeed. It's good that GCC people start eating their own dog food and allow the use of C++. I'm sure this move will bring improvements to g++.
Re: GCC starts move towards implementation in C++
#14When I read this stuff, like what to ban, what to allow and so forth, it's impossible for me to avoid thinking that actually C++, Objective-C, and D, are not enough. We are still in a world where a "better C" is needed as the available choices are not good enough.
Re: GCC starts move towards implementation in C++
#15Yes, they just allowed it. They're not going to rewrite gcc in C++. But still, why, oh why? Eventhough C++ allows, in some cases, the possibility to use easier syntax for certain constructs, it's not particularly more expressive language than C. I don't know gcc codebase but if they decided to actually reimplement something in C++, it would take a lot of time just to make it comparable to the current C implementation…
While something like a Haskell/OCaml implementation would probably be too cutting-edge, considering the conservative inertia of such a big project, I wonder why they didn't consider some high-level language better suited for compiler writing.
I imagine bootstrapping could be a problem. If GHC needs a C compiler to build itself, and the C compiler needs GHC to build itself, you'll need a good, very portable C compiler to get started - that's GCC. Cross-compiling could perhaps be an option, although GHC doesn't support it for the moment.
Re: GCC starts move towards implementation in C++
#16I find this statement particularly interesting: For example, I think constructors and destructors are pretty easy and hard to misuse. Now, I am aware that the competence of the average GCC committer probably exceeds that of the average programmer, but still, constructors and destructors are easy to misuse: throwing an exception in the constructor comes to mind, in which case the destructor isn't called. Anything abou…
throwing an exception in the constructor comes to mind, in which case the destructor isn't called
Of course it is not called -- the object has failed to construct. There is no object. You cannot call a destructor on nothing. Now if some data member has been constructed but the call constructor failed, destructors for such members will be called.
Re: GCC starts move towards implementation in C++
#17Yes, they just allowed it. They're not going to rewrite gcc in C++. But still, why, oh why? Eventhough C++ allows, in some cases, the possibility to use easier syntax for certain constructs, it's not particularly more expressive language than C. I don't know gcc codebase but if they decided to actually reimplement something in C++, it would take a lot of time just to make it comparable to the current C implementation…
...because large-scale C projects end up reinventing C++ features in a more complicated, error-prone way. C++ is much more expressive than C. It can compete on equal terms with other high-level OO languages, it has some functional features and it contains all of C. On the downside, it's difficult to learn and takes much time to become proficient in. Once you become proficient there's no contest.
because large-scale C projects end up reinventing C++ features in a more complicated, error-prone way
You are spot on. Here is an excerpt from a blog post on writing a GCC plugin:
The GCC AST itself is a curious data structure in that it is an implementation of the polymorphic data type idea in C (next time someone tells you that polymorphism works perfectly in C and they don’t need “bloated” C++ for that, show them the GCC AST). The base “handle” for all the AST nodes is the tree pointer type. Because the actual nodes can be of some “extended” types, access to the data stored in the AST nodes is done via macros. All such macros are spelled in capital letters and normally perform two operations: they check that the actual node type is compatible with the request and, if so, they return the data requested.
http://www.codesynthesis.com/~boris/blog/2010/05/10/parsing-...
Re: GCC starts move towards implementation in C++
#18I find this statement particularly interesting: For example, I think constructors and destructors are pretty easy and hard to misuse. Now, I am aware that the competence of the average GCC committer probably exceeds that of the average programmer, but still, constructors and destructors are easy to misuse: throwing an exception in the constructor comes to mind, in which case the destructor isn't called. Anything abou…
So don't use exceptions. They're not needed and definitely make C++ code far more complicated, not less.
Re: GCC starts move towards implementation in C++
#19I find this statement particularly interesting: For example, I think constructors and destructors are pretty easy and hard to misuse. Now, I am aware that the competence of the average GCC committer probably exceeds that of the average programmer, but still, constructors and destructors are easy to misuse: throwing an exception in the constructor comes to mind, in which case the destructor isn't called. Anything abou…
throwing an exception in the constructor comes to mind, in which case the destructor isn't called Of course it is not called -- the object has failed to construct. There is no object. You cannot call a destructor on nothing. Now if some data member has been constructed but the call constructor failed, destructors for such members will be called.
The constructor might be partially executed before the exception is thrown (for example, allocated memory or locked resources), in which case those things don't get cleaned up.
I'm not arguing it isn't correct behavior, it's just that things don't always seem as easy and straightforward as they look on first sight.
Re: GCC starts move towards implementation in C++
#20When I read this stuff, like what to ban, what to allow and so forth, it's impossible for me to avoid thinking that actually C++, Objective-C, and D, are not enough. We are still in a world where a "better C" is needed as the available choices are not good enough.
Out of curiosity, how did you lump Objective-C and D into this. I haven't heard of people banning the use features of Objective-C and D like they do with C++.
//well, except where the platform doesn't support the feature (e.g. iPhone::Garbage Collection).