What I Wish I Had Known About Developing C/C++ From Linux Before I Started
derwiki.tumblr.com
derwiki.tumblr.com
Ctags is great, especially for navigating someone else's code. What does this function do? Just ctrl-] and suddenly I'm at its definition. Something in there I don't recognize, same thing. Ctrl-t to go back up the tag stack. Ive become so used to navigating my code this way I have trouble without it.
Completion is just the way that Vim will give you completion matches in insert mode if you hit ctrl-n or ctrl-p. With C it's very smart about it and will automatically search included files. It's great for not having to worry about exact spellings on things. If you really like this sort of stuff there are a few plugins that do Textmate-like snippets.
The biggest plus you get when using CScope is the ability to do a "reference" search. You can find all references to a given symbol in your project quickly and easily which I find invaluable for refactoring (what's going to be affected when I change this?).
One thing to realize is that vim IS an IDE of sorts. Only, it's far more extensible for the same effort. (although, from my brief forays with emacs, emacs certainly beats vim for extensibility)
Cscope, as commented on the article's website, sounds quite interesting too.
ctags -R --c++-kinds=+p --fields=+iaS --extra=+q .
export CTAGS='-R --c++-kinds=+p --fields=+iaS --extra=+q'
And what about tokens created using the token pasting operator ## from include files that are included multiple times (e.g. code generation hackery)? Visual Studio will at least locate the include file which introduced the token, and of course will be able to complete on the token, aware of its type etc.
Here's a tip that has saved me once or twice. If you start a long-running process, but forgot to use screen or nohup, bash lets you 'disown -h' its jobspec.
# Set up my status line at the bottom of every frame
caption always "%{gb} %{ck}%m-%d %C %{gb} %{gb}%?%-Lw%?%{ck}%n*%f %t%?(%u)%?%{gb}%?%+Lw%?"
Binding ! @ # etc. to select 10, 11, 12, ... is handy, too.
hardstatus alwayslastline
hardstatus string "%n: %H (%h) %t"
From http://www4.informatik.uni-erlangen.de/~jnweiger/screen-faq....
Q: My xterm scrollbar does not work with screen.
A: The problem is that xterm will not allow scrolling if the
alternate text buffer is selected. The standard
definitions of the termcap initialize capabilities ti and
te switch to and from the alternate text buffer. (The
scrollbar also does not work when you start e.g. 'vi').
You can tell screen not to use these initialisations by
adding the line termcapinfo xterm ti@:te@ to your
~/.screenrc file.I would not complain, if I knew such an easy way to make it work, really. :-)
I can see it being useful in ssh through : you can have it emulate tabs through a single ssh connection.
Debugging C in Linux is a dream with gdb. Debugging (heavily templated) C++ in gdb is a nightmare.
I therefore have one additional tip, though it doesn't work in console: Run Visual Studio in wine. It's debugger can pick up running Linux processes and is awesome to work with.
However, I really think that increasing speed of development with better tools is a cornerstone of being one of those elite programmers, and vim<<eclipse, at least for Java!
For every other language that I have encountered, the utilities listed by the OP (especially vim/emacs) are the better tools, as far as I'm concerned. Firstly, they were written by hackers for hackers, and because of that, they generalize just about all the functionality a programmer is likely to need when coding in any language. Even supposing there were eclipse-like IDEs for every language out there, it is more than likely that there will necessarily be differences between them (since they were written for different languages) which will be jarring for the power user. One would have to learn an IDE for every language. With vim and the assorted tools mentioned in the OP, one just needs to learn one set of tools and can use them for every language. If you foresee that you will only code in one language for the rest of your life, then sure, find the best IDE for that language. In my job, however, I have to code in C++, Python, Perl, PHP and shell (most times editing source files in more than one language at the same time), so to increase speed of development, (though I am no elite programmer) I use vim.
I don't develop using an IDE, but I still have access to the same kind of functionality. It's just not integrated into my editor.
You're absolutely right about their development environment; it's adapted for one set of tools. It doesn't necessarily mean other tools are inferior in general, as the author seems to conclude.
I will admit to not having tried devc++ or visualc. I would imagine that visualc might be able to solve the problem, since they can control the build system, and can hook into their compiler directly (last I checked, GCC made this very hard).
I'm also going to go out on a limb and suggest that you may be overestimating the pain points other people experience /not/ using an IDE.
Another trick in this vein is/was to use 'pstack' to pull a C backtrace from a looping process. If you do that every second for 10 secs, you'll probably find where the process is looping. As a bonus, it also acts as a poor-man's-retroactive profiler (process X intermittently takes 30s to handle it's job instead of 2s - watch for one and when it happens, strobe the process with pstack to see what it's up to). Can be used in production, no need to deploy profiling build and run for ever to catch problem, etc.
(And a variant of this trick for interpreted languages is to hook an unused signal (SIGUSR2?) in your language to say "dump me a perl/python/etc backtrace to the log file". Assuming the loop is in your app code this will give you a language-level backtrace if you strobe the process with the signal)
NB1: pstack doesn't do anything which scripted gdb couldn't do, it's just more convenient
NB2: pstack is unavailable on 64-bit arches?
NB3: pstack needs some symbols to work with in the binary, which probably won't be the case with your system apache+mod_xxx
The better designed a language the better its development process feels. You can get immersed in a lowly Lisp, J, or Forth listener. Just a little black xterm with nothing else to it, and you feel productive already (never mind the amazing environments there are for Lisp.) BADLY designed and malignant languages have 3rd party tools to augment its functionality. There are things to bolt on, hammer in and stuff to bake into the scaffolding before you stuff in boxes. The C and C++ equivalent of a listener is `cat` or maybe the system-shipped vi or nano or pico. Can you seriously feel yourself getting something done?*
* (I will answer myself and say yes; I learned Unix programming over a serial line, but it was not an immersive experience; I had books on my desk and lap and was flipping back and forth to get anything done; a masochistic sort of fun, fueled by the mischievous possibility of breaking into another account ;-)
Even if you program in a safe language, you still want assert(), and when that assert fails, you don't want an exception: once the exception has torn down a single frame it's too late, since you lose the precious "can't happen" program state.
Sure, C is a low-level language, but I think the YC consensus insufficiently weights the quality of tools supporting this ecosystem. Debuggers and profilers are indispensable, high-leverage tools for saving developer time, and the hip languages these days have followed perl's lead in just sticking -d and -p flags in the reference implementation and pretending the problem is solved.
Lisp doesn't dump core, it will drop you in a debugger prompt where you can Frankenstein your programmer to life as you wish. Forget Lisp, Scheme and other languages with full continuations will give you the entire run trace of your program in a video tape, where you rewind and fast-forward as you wish. C is not a language whose control semantics you want to brag about.
But back to Lisp, here how you "dump core" in Common Lisp: write a handler for the error condition and call SAVE-LISP from there. One line of code, left optional to the programmer.
"you still want assert(), and when that assert fails, you don't want an exception"
Yeah, it's called by the exact same name in Common Lisp.
"Debuggers and profilers are indispensable"
My Common Lisp has both a deterministic and an statical profiler. Standard Common Lisp has GC, TRACE, ROOM, DESCRIBE, APROPOS, ED, DISASSEMBLE and TIME among others. Those correspond to malloc/free, gprof, ltrace, man, apropos, vim and objdump; in the friken LANGUAGE :-) Everything is tied together with function called semantics and a memory visible to all; not with brittle "shell" languages and text parsing. The vendor and community extensions will make you weep.
There is really no point of comparing Lisp to C; you should compare Lisp to Unix.
Still, I meant what I said.
"Lisp doesn't dump core, it will drop you in a debugger prompt..."
What if the user isn't a developer, but, y'know, a user? On the other side of the country, who doesn't care why your code is broken? Will you fly to their site? Hope they let you ssh in and not restart the application while you personally debug it? Hmm, if only it were possible to somehow serialize the state of the broken program, so that someone else could debug it in a different time and place ;).
(handler-bind ((error #'(lambda (e)
(save-lisp-and-die "lisp.core"))))
(YOUR-PROGRAM-ENTRY-POINT))
When I wrote kernel modules I used C; today I'm writing an in-memory cache for a mulithreaded webserver. It has to maintain user-sesions in memory across several load-balancing servers. It has a multi-stage storage system. It has a queue manager that maintains a private queue for all concurrent users of the system; everything dynamically scheduled in realtime with a bunch of matrix munching algorithms. Allot of intricate stuff that I would have written in C when I didn't know better.
I would still write C code though, but only if I absolutely must, as in your case.
Regards.
NOOOOOOooooooo. That implies he is using ad-hoc version control (uniquely named files or directories with non-revisioned copies).
Tracking and finding changes is what git is for. Commit early and often! If you mess up, it's got your back! If your compatriots use SVN, that works, but not nearly as well (when I used SVN, I would still revision control my local copies with RCS in between SVN commits). If you are developing by yourself, rcs is the minimum acceptable alternative.
awk '{print $2}'
Is there a way to achieve this that's easier to type?
I'm currently dev'ing for QT under QT Creator, and everything is nicely integrated, with some really neat features you can't reproduce in vim, and it even has an (incomplete) vim emulation mode !
I used to be an hardcore vim / cli fan, but i'd go back to that for nothing in the world now, at least for this current dev setup. Also i hate having to mess with makefiles.
Also, he should have just pointed out that all IDEs are ass for C++. Java is simple enough that an IDE can be a big help, but C++ is too complicated and too slow to compile. (The remote access thing is just a matter of the work environment being adapted to one set of tools and not another -- the real issue is that text editors beat IDEs for C++.)
Otherwise, an excellent list.
Languages that are easier to throw together a reasonable parser for (Lisps, Smalltalk, Lua, or even C) have a much lower barrier to entry for development tools. Keeping the language syntax simple enough means that somebody scratching an itch can write something useful in an afternoon or a weekend, rather than taking a team and months.
For an example of a less accidentally complex way to do what C++ templates do, look at ML's functors.
Heck, even Java.
People (rightfully) complain a lot about how verbose some parts of java are (like how instead of anonymous functions or functions that can be passed as a parameter you have anonymous classes), but ignore the fact that the designers intentionally made that sacrifice to maintain consistency.
I'm working on a tool to help maintenance coders undo the damage from copy-and-paste programming on huge legacy code bases. One approach it uses is language-specific, but requires a bit of configuration (via Lua's wonderful LPEG), and the other is language agnostic. It's searingly obvious how much worse C++ is in this regard.
My ideal user interface for programming? A brilliant group of younger smarter coders with better memory.
How did you do refactorings? Or you just don't?
I honestly don't understand how regexps and strong bookmarking skills could help you - the editor needs true knowledge of the language to carry out this task.
And not to troll, but anyone who honestly believes vim is a better development environment than one of the mature Linux IDEs (Eclipse, Code::Blocks, KDevelop) is an idiot.
Anybody who thinks that a text editor is better than an IDE is an idiot? I think not.
One good thing about ed is that it's always on even the most minimal system recovery disks (which often lack vi, even). I've been stuck using it a couple times while fixing dying systems. No fun, but better than nothing.
ssh me@mysite.com
$ screen -x
Even the cursor stays where it was between sessions.
How can I do that with ${IDE}?
And not to respond to your troll, but a lot of the more senior devs on my project (10, 15+ years) as just as efficient in vim/emacs as they would be in Eclipse. I don't think there's a one-IDE-fits all solution. Vim is certainly capable if you're willing to learn it.
And this is coming from an emacs user ;)