Comments on: Fast Development http://www.airs.com/blog/archives/206 Ian Lance Taylor Wed, 7 Jan 2009 09:44:32 +0000 http://wordpress.org/?v=1.5.2 Comment on Fast Development by: Ian Lance Taylor http://www.airs.com/blog/archives/206#comment-14250 Thu, 12 Jun 2008 01:09:52 +0000 http://www.airs.com/blog/archives/206#comment-14250 During the development cycle, there is no need for optimized code, so it should be possible to compile much faster than gcc does today. And checking for dubious constructs doesn't have to be part of the compilation process proper, it can be done separately. So I think we really can make things faster. As jldugger says, look at what Eclipse can do with Java. I'm not sure what a C++ module system would look like, but anything which saves us from reading and parsing tens of thousands of lines of header files would help a lot. During the development cycle, there is no need for optimized code, so it should be possible to compile much faster than gcc does today. And checking for dubious constructs doesn’t have to be part of the compilation process proper, it can be done separately. So I think we really can make things faster. As jldugger says, look at what Eclipse can do with Java.

I’m not sure what a C++ module system would look like, but anything which saves us from reading and parsing tens of thousands of lines of header files would help a lot.

]]> Comment on Fast Development by: ncm http://www.airs.com/blog/archives/206#comment-14249 Wed, 11 Jun 2008 22:06:18 +0000 http://www.airs.com/blog/archives/206#comment-14249 Sorry, doesn't fly. A huge fraction of the instructions executed in Gcc are concerned not with making the program run faster, but with ensuring that both the source code you wrote, and the object code it emits, are correct. Of course those instructions make the compiler itself slower, and thank goodness for them. A faster compiler that welcomes or emits bad code, and a faster program that produces wrong results, would both be much, much easier to write than what we do choose to spend our time on. What you're really talking about is minimizing the final cost of software, which is what we make tools for in the first place. The more things they do faster than we can, the better off we are. Tom: The next C++ (i.e. after C++0x) may well have a proper module system, and be better-suited for incremental compilation. Sorry, doesn’t fly. A huge fraction of the instructions executed in Gcc are concerned not with making the program run faster, but with ensuring that both the source code you wrote, and the object code it emits, are correct. Of course those instructions make the compiler itself slower, and thank goodness for them. A faster compiler that welcomes or emits bad code, and a faster program that produces wrong results, would both be much, much easier to write than what we do choose to spend our time on.

What you’re really talking about is minimizing the final cost of software, which is what we make tools for in the first place. The more things they do faster than we can, the better off we are.

Tom: The next C++ (i.e. after C++0x) may well have a proper module system, and be better-suited for incremental compilation.

]]> Comment on Fast Development by: jldugger http://www.airs.com/blog/archives/206#comment-14248 Wed, 11 Jun 2008 22:06:07 +0000 http://www.airs.com/blog/archives/206#comment-14248 I don't spend a lot of time writing a single piece of software, rather I tend to flit from program to program to fix bugs etc. I prefer emacs as a text editor, mostly because I'm slightly familiar with it. Eclipse JDT is fantastic, really. I used it in my compiler design class, and it's got some compelling arguments. There's an integrated tutorial showing you how to start a new project with JDT. It tells you what to do and recognizes when you've done it. do not underestimate the value of a steep learning curve. Its autocomplete also is well done and is handy for debugging complicated exceptions. I also found JUnit handy when writing a parser in ANTLR. With 80 or so test cases, you can do a pretty good job exercising the grammar (at least a simple one) and get a good idea of how much progress you're making. Eclipse CDT however, is not your guy. Speed of writing is why I don't use Eclipse. CDT is terribly slow still on autocomplete, which triggers by default on several annoying conditions. I've found no Many students ask me about visual debuggers on UNIX, and many end up using DDD. I've been meaning to learn more about the eclipse debugger in CDT, but the CDT is so bad I can't bear to write any code to debug in it. I don’t spend a lot of time writing a single piece of software, rather I tend to flit from program to program to fix bugs etc. I prefer emacs as a text editor, mostly because I’m slightly familiar with it.

Eclipse JDT is fantastic, really. I used it in my compiler design class, and it’s got some compelling arguments. There’s an integrated tutorial showing you how to start a new project with JDT. It tells you what to do and recognizes when you’ve done it. do not underestimate the value of a steep learning curve. Its autocomplete also is well done and is handy for debugging complicated exceptions. I also found JUnit handy when writing a parser in ANTLR. With 80 or so test cases, you can do a pretty good job exercising the grammar (at least a simple one) and get a good idea of how much progress you’re making.

Eclipse CDT however, is not your guy.

Speed of writing is why I don’t use Eclipse. CDT is terribly slow still on autocomplete, which triggers by default on several annoying conditions. I’ve found no

Many students ask me about visual debuggers on UNIX, and many end up using DDD. I’ve been meaning to learn more about the eclipse debugger in CDT, but the CDT is so bad I can’t bear to write any code to debug in it.

]]> Comment on Fast Development by: tromey http://www.airs.com/blog/archives/206#comment-14247 Wed, 11 Jun 2008 16:49:27 +0000 http://www.airs.com/blog/archives/206#comment-14247 >> In emacs I turn off font-lock mode because it is slow. Wow! If you like font-lock at all, you might want to try again. Recent versions of Emacs do JIT font-locking. The old pauses are basically gone. My ideal recompile time is "faster than I can notice". I don't think we can achieve that, at least not with gcc and the realities of C and C++. >> In emacs I turn off font-lock mode because it is slow.

Wow!

If you like font-lock at all, you might want to try again.
Recent versions of Emacs do JIT font-locking.
The old pauses are basically gone.

My ideal recompile time is “faster than I can notice”.
I don’t think we can achieve that, at least not with gcc and the realities of C and C++.

]]>