Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I Wish I Had Known About Developing C/C++ From Linux Before I Started

derwiki.tumblr.com

Post reply on HN
Print view View original

41–50 of 104 posts

Re: What I Wish I Had Known About Developing C/C++ From Linux Before I Started

#41

Post by ori_b »

kingkongrevenge wrote: post #39
ramchip wrote: post #28

Earlier quoted context omitted.

Emacs also supports ctags. I didn't find it very useful with C++ though, which is my usual language, since it didn't autocomplete member functions - I think it's supposed to work, though I couldn't be pushed to tweak it. Cscope, as commented on the article's website, sounds quite interesting too.

ctags on C++: ctags -R --c++-kinds=+p --fields=+iaS --extra=+q .

ctags takes an environment variable for it's options, too:

    export CTAGS='-R --c++-kinds=+p --fields=+iaS --extra=+q'
and then you can just run 'ctags .'

Re: What I Wish I Had Known About Developing C/C++ From Linux Before I Started

#42

Post by kingkongrevenge »

miloshh wrote: post #21
jballanc wrote: post #18

Earlier quoted context omitted.

In Vim, install ack, then put "set grepprg=ack" in your .vimrc. Then, open your project in Vim, do a ":grep ", and use ":cn", ":cnf", ":cp", ":cpf", ":cr", etc. to move about. Combined with strong knowledge of setting marks and using ":s/" substitutions, and I often wonder how people who use IDEs do refactorings! ;-)

I think you misunderstood what refactoring means in an IDE. Suppose you want to rename a method. There might be many other methods of the same name in different classes, local variables of that name in other methods, or even classes with that same name in differen packages. Eclipse automatically does all of this for you. I honestly don't understand how regexps and strong bookmarking skills could help you - the editor…

I doubt it's realistically possible for this to work reliably with C++. How could the parser deal with a predeclared type pointer in a header file that is resolved at link time? How about unions?

Re: What I Wish I Had Known About Developing C/C++ From Linux Before I Started

#44

Post by kmavm »

mahmud wrote: post #27

Worse is NOT Better; use a safe and high-performance programming language and learn its foreign-function interface to call out to C and C++. Life is too short for core-dumps and premature optimization, plus you only have two feet to shoot at. 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…

Since you mention core dumps, please take some unsolicited feedback from an old C programmer: the post-modern "developer productivity" family of languages' lack of core dumps is a bug, not a feature. You want core dumps. They're the right thing. They let you debug a broken program that has since been restarted, or on a different machine than the crash happened, six months afterwards.

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.

Re: What I Wish I Had Known About Developing C/C++ From Linux Before I Started

#45

Post by atypic »

There is one thing I feel have been neglected here: Debugging.

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.

Re: What I Wish I Had Known About Developing C/C++ From Linux Before I Started

#46

Post by mahmud »

kmavm wrote: post #44
mahmud wrote: post #27

Worse is NOT Better; use a safe and high-performance programming language and learn its foreign-function interface to call out to C and C++. Life is too short for core-dumps and premature optimization, plus you only have two feet to shoot at. 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…

Since you mention core dumps, please take some unsolicited feedback from an old C programmer: the post-modern "developer productivity" family of languages' lack of core dumps is a bug, not a feature. You want core dumps. They're the right thing. They let you debug a broken program that has since been restarted, or on a different machine than the crash happened, six months afterwards. Even if you program in a safe lan…

"the post-modern "developer productivity" family of languages' lack of core dumps is a bug"

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.

Re: What I Wish I Had Known About Developing C/C++ From Linux Before I Started

#47

Post by visitor4rmindia »

Periodic wrote: post #9

When I started developing in C in Vim there are two things I've gotten used to that I can't live without now: ctags and auto-complete (they help with eachother). 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…

If you like CTags give CScope a try. It's sort of like CTags on steriods. Also Vim can work with a combination of both (it loads both cTAGS and cscope.in) so you don't loose any functionality.

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?).

Re: What I Wish I Had Known About Developing C/C++ From Linux Before I Started

#48

Post by thingie »

mblakele wrote: post #3

I use "screen" a lot, but I wish it had a better name. It helps if you search for "gnu-screen", but not much. 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.

The biggest problem with screen is that it breaks ordinary virtual terminal scrollback, which is something that I can live with, but…

Re: What I Wish I Had Known About Developing C/C++ From Linux Before I Started

#49

Post by kmavm »

mahmud wrote: post #46
kmavm wrote: post #44

Earlier quoted context omitted.

Since you mention core dumps, please take some unsolicited feedback from an old C programmer: the post-modern "developer productivity" family of languages' lack of core dumps is a bug, not a feature. You want core dumps. They're the right thing. They let you debug a broken program that has since been restarted, or on a different machine than the crash happened, six months afterwards. Even if you program in a safe lan…

"the post-modern "developer productivity" family of languages' lack of core dumps is a bug" 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 who…

FWIW, I don't consider CL a member of the "developer productivity" gang of languages. In practice, it is much more like a better C than it is like python: you have C's relative poverty of libraries and richness of tools.

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 ;).

Re: What I Wish I Had Known About Developing C/C++ From Linux Before I Started

#50

Post by vorador »

donw wrote: post #32
bf wrote: post #26

Why are we taking C/C++ programming advice from somebody who has been doing it for just over a year? 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.

Linus Torvalds has pretty much always used an Emacs variant for his work on the kernel. Matz uses Emacs for his work on Ruby. DHH uses TextMate, a text editor. Pretty much every major piece of software that you can name on the Unix platform was and is developed in either Emacs or Vim. Anybody who thinks that a text editor is better than an IDE is an idiot? I think not.

Well, some people used ed.
Post reply on HN