As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
As a big fan of Charles Petzold's books Code and The Annotated Turing I came across his book Programming Windows which teaches Win32 programming in C. I am a freshman computer science student who learned C first, but I use C# and .NET for Windows programming now, so I was wondering if Win32 is still relevant to professional Windows programs. Would it be worth it to me, as a student who wants to program Windows applications, to learn the Win32 API to the depth that the book covers?
It really depends on the kinds of applications you want to develop. For most purposes these days, C# and .NET are completely suitable. However, there are certain kinds of applications that need as few dependencies as possible (shell extensions come to mind) that are not practical to do as .NET applications. For those you would need Win32.
As always, it pays to have at least a basic understanding of Win32 even if you're using .NET for most of your work.
I completely agree with what Joel Spolsky writes in one of his many great articles. I think it is crucial to know the lower layers of the machine not only to be able to write quality code but to be able to solve problems that will inevitably appear.
So, YES, it is important to at least know the basics of WIN32 API maybe not in depths but at least to know it's there, at the base of everything you will code.
It's very relevant if you are writing C# on Windows. Not all the features of the Win32 have been exposed via the .Net libraries. A concrete example of this is the WM_SETREDRAW message technique I describe here: WM_SETREDRAW. It's also needed at other times for control focus issues.
Also, understanding how Win32 and Windows work will give you a better understanding of various aspects of C#/.Net such as:
What does Control.Invoke() actually do?
What is the difference between Control.BeginInvoke and Control.Invoke?
What actually causes my control's events to fire, e.g. OnClick etc and how can I debug that.
That said, WPF changes all this and if you are only writing .Net 3/3.5 code then my argument loses some its relevance.
In my opinion, no. I learned it a long time ago, so you wouldn't have to!
I think it's great that you learned C first, and I'd keep writing C programs now and then, but I don't see why the win32 API would be useful to dig into. Honestly, it was a big mess.
I think it's important to learn the basics. If you learned just enough to display a window with some fields, some buttons, and a menu. Maybe draw something in a separate window. It would help you learn the fundamentals of how Windows is really working. I believe understanding the message loop and the realization that almost everything you see is a window are fundamental things that everyone should know. My eyes were really opened the first time I realized that a button was it's own window. It then helps you understand that features of things can be turned on and off by sending these windows messages. Subclassing windows let's you get access to features not exposed to you in things like .NET or VB Classic and let's you enhance the window's functionality.
Definitely learn the basics as AlexDrenea mentions. Whilst .NET shields you from a lot of Win32 API Calls. Win32 API is so enormous you're bound to run into situations where .NET hasn't wrapped it for you.
A real life common situation sort arrows on ListViewColumns
I don't really think "learning Win32 API" is realistic for anyone. The APIs (yeah, there's more than one) are huge, and you will hardly ever need to know all of them in detail. I would recommend reading up on some basics (i.e. Window creation, window messaging, window procedures, maybe some GDI, etc.) and using MSDN to look up the rest whenever you need it.
As per Greg's comment, it is to some extent domain dependent. I do a lot of Windows CE / mobile programming, where .NET is too hoggish for many devices and other frameworks such as MFC aren't fully implemented. In this context, much of Win32 is still very relevent.
That said, I wouldn't go learning it all upfront, I'd simply go through the basics, and dig out the rest as and when I needed it. The documentation and examples out there are good enough for this approach, as is the online help available from communities such as this.
Unless you need some functionality that is not in the .NET Framework (such as getting detailed info on printer drivers), no. That's about 99% (of course, an arbitrary value I just made up) of what you'll do.
Even if you were using Win32 and not .NET, is there really a need to learn the same depth as the book? Browse thru the sections, learn that if you encounter some problem in the future you know where to look for it. Then stop. Go in depth when you need it or have the free time.
I think it's already been answered but if you do .NET 2.0 development or anything winforms in .NET, you're bound to run into a lot of problems with how some parts of the framework is wrapping win32 and mfc and you'll need to dig into that to actually get stuff working as intended.
If you're trying to solve Business Problems, then there's better tools out there than C for programming Win32 systems. Clarion. Delphi. And others I have no doubt.
But I guess for learning how things work you're in good stead with C.
Some stuff can not be done without win api calls but with each version of .net those things become less and less so no i would not learn the win api if i where you..
You have to know it exists, since most of the native functions of more "advanced" managed language end up calling them.
Plus it can be encapsulated in script languages like Autoit with DllCall
I'm still earning part of my money using it. We do have a C IDE which is based on the WinAPI. It's now around for 15 years or so, and still running ;-). The complete download of it is around 5 MB for that you do not get anything in the .NET world. So for us it's still a valuable thing....
This has been discussed many times on Professional Win32 api Newsgroup (
news://comp.os.ms-windows.programmer.win32)
(by the greatest gurus and best-sellers authors (Petzold, Russinovich, etc) in the world...)
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I always find good tutorials on the subject, but it almost always is C++. Is it hard or just doesn't make sense to make GUI applications with C?
A good book, guide or a tutorial is fine.
Platform: Linux
Use GTK+. It's written in C and exposes a well-designed C API. Their tutorial is quite excellent.
GTK+ is the toolkit for GNOME, so your applications will fit right in with many Linux desktops.
If you are programming in C on Windows - Petzold's programming windows used to be the bible for C based ui work.
EDIT:
Since I answered my question the post has been updated to be on Linux. I will leave the post here for anybody looking, but it really does not apply to Linux.
Many high quality GUI were written in C with, for example, Windows API. There's no particular reason why not, but object oriented programming was very successful in modeling interactive graphics. GUI elements somehow map naturally into C++ objects that can encapsulate complex behavior behind a simple interface.
It's hard enough (or, mostly, verbose enough) that most people figure it just doesn't make sense. The GUI part of an application (mostly) reacts to user input, so in this area speed is rarely critical -- a difference of a few microseconds (or even milliseconds) rarely makes much difference. As long as responses appear within 100 ms (or so), they're pretty much perceived as "instant".
Dynamic typing also tends to work quite nicely for a lot of GUI programming. C uses only static typing.
Don't.
Use python and then bind the computationally expensive calls written in C.
What is the best way to design GUI Applications with C?
don't, if you don't have to :-)
Is it hard or just doesn't make sense to make GUI applications with C?
It is not necessarily that hard, but a pretty redundant and verbose task (like writing high level programs in assembly language), with lots of repeated boilerplate code.
Personally, I find it more rewarding to simply embed a scripting interpreter (e.g. Lua, Nasal) with bindings for a GUI library and then code the UI in a high level scripting language and code only the core of the application itself in C. Python was previously mentioned, but I think that a dedicated extension language like Lua would be a better fit, because it doesn't bloat your source code and because it does not create any additional requirements (like library dependencies or architectural).
In other words, embedding something like Python, Perl or Ruby may be relatively straight forward (because of good documentation and community momentum), but often these languages are more complex than the host application itself.
This is also the approach taken by the AlgoScore software, which uses an embedded Nasal interpreter with GTK bindings.
If you're on a *nix system, you can use Xlib. But you're probably better off programming in C++ and calling out to your C code.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
This is a question I have had rattling around in my head for some time. I had a chat with a guy the other night who told me he would not be using the navigational framework because he could not figure out how it works with MVVM. As much as I tried to explain that patterns should be taken with a pinch of salt he would not listen.
My point is this, patterns are great when they solve some problem. Sometimes only part of the pattern solves a particular problem while the other parts of it cause different problems. The goal of any developer is to build a solid application using a combination of patterns know how and foresight.
I feel MVVM is becoming the one pattern to rule them all. As it is not directly supported by .Net some fancy business is needed to make it work. I feel that people are missing the point of the pattern, which is loosely coupled, testable code and instead jumping through hoops and missing out on great experiences trying to follow MVVM to the letter.
MVVM is great but I wish it came with a warning or disclaimer for newbies as my fear is people will shy away from silverlight development for fear of being smacked with the mvvm stick.
EDIT:
Can I just add as an edit, I use and agree with MVVM as a pattern I know when it is and isn't feasible in my projects. My issue is with the encompassing nature it is taking, as if it HAS to be used as part of development. It is being used as an integral feature and not a pattern, which it is.
EDIT 2: Thanks for all the comments so far, one issue that is surfacing from this is something I have not thought about until now. Is the introduction of richer more advanced frameworks for GUI/RIA development showing a weakness in RAD development for this generation. That is, is there a lack of code design and pattern knowledge being taught along with these frameworks? I once asked for a book on just C# (Before Pro C# & the .Net framework was popular) and was told why would I want to know C# minus winforms/asp.
Sure there are plenty of books/KB on these subjects but are people using them, beyond the superstars and very good programmers?
So, here's something that I think a lot of new MVVM developers forget - the pattern is there to help you, not the other way around. Building software in this manner tends to make your life easier as your project gets larger, but if it's completely getting in your way for a specific task, take a step back and ask, "In this specific scenario, is MVVM helping me here?" You're allowed to "cheat" a bit from time to time if it makes your life easier.
Actually I've used MVVM quite effectively with Navigation Applications with the Windows Phone 7 framework using commands and messaging. But if someone tells you that you can use every feature of Silverlight without adding some code to the code-behind, then they are fooling themselves. Use the pattern where it helps and make sense, and go "off-pattern" when a particular feature requires something custom.
Assuming your question applies to WPF as well, I sort of wonder if the problem isn't just the massive learning curve of WPF/Silverlight, before it even occurs to you to try out MVVM. Think about all the new things that need to be learned with WPF (and I assume Silverlight): XAML, dependency properties, attached properties, routed events, routed commands, static resources, dynamic resources, styles, data templates, control templates, databinding, etc., etc. etc. Then take the fact that Microsoft released this technology with an incomplete set of, at least with WPF, badly skinned controls, and you have a recipe for frustration and the inescapable feeling that you are dealing with a technology that is "not ready for prime time". I mean, before the WPF Toolkit came out, there wasn't even a proper DataGrid control.
Once you understand all these things, MVVM is yet another hurdle, but I don't think it's the main impediment to people jumping on the WPF/Silverlight bandwagon. That said, it would be nice if Microsoft would get behind it the way it has gotten behind ASP.NET MVC. As it stands today, you have to download and use third-party tools, like MVVM Foundation and MVVM Toolkit (which, incidentally, have a lot of overlap and should be combined into a single project).
So, I agree with you to a point, but I think most of the challenges involved with MVVM are probably due to the lack of support from Microsoft, and the inherent complexity of WPF/Silverlight, not due to any flaw in the MVVM pattern itself.
Great answers here, by the way. Good discussion and an important one to have. There is no doubt that learning Silverlight can be intimidating for new developers, and the MVVM framework will no doubt compound that.
However, I do agree that someone not understanding it isn't a dig against the framework. I still have developers who tell me that inversion of control/dependency injection is too confusing to learn, but does that make these invalid patterns? The fact the so much proven, "in the field" software relies on those concepts tells me they are sound even if complicated to grasp at first or understand.
Then again, learning a foreign was tough when I started, but once I pushed through, now I can speak it comfortable and wonder why it was so hard to begin with.
I guess the trend that scares me the most is this notion that for some reason complicated, enterprise applications should be easily built by beginner developers who either can't or won't grasp complex concepts. That's what it really boils down to. You don't have doctors saying, "Help, make this brain surgery easier so any one can do it." It's specialized. Building great software is also specialized, that's why consultants command good payment for their services: it's the value they provide in understanding the right way to architect and develop solutions.
If you are making an asteroids game, a fantasy game, a media site, a YouTube knock-off, etc, then you probably don't need MVVM and it is overkill. If you are building a small site with a few forms and graphs then build it how you are comfortable and be done with it.
If you are building a large, complex site that is composed of multiple, dynamic modules, moves thousands or millions of records and requires scaling to massive concurrent users, then you can't expect the design to just pop out after thumbing a few pages of a book or skimming a few sites. Software like that is complicated, with a lot of moving parts, and rqeuires a firm grasp of architecture.
What amazes me is people presumably building these more complex applications who still don't get building these more complex applications. Is there someone experienced on the team? Do you have an architect to stub out the framework that you can consume?
I mean really, the example just tells me the problem isn't MVVM, it's the developer. "Avoiding Navigation because of MVVM?" REALLY? What's MVVM got to do with it? Write the navigation pieces, and let the view models live inside the pages. Why does my navigation have to drive from a view model?
Come one. If it's that complicated I think it has nothing to do with the pattern, and everything to do with the developer just not understanding development. Don't blame the pattern. Maybe they need to stick to simpler applications. In my experience, people who come to understand the pattern understand software well enough that they know when and when not to use the pattern.
I know there are many movements to boil it down and make it simple for the "average consumer" but I think this is like trying to say, "Calculus is the wrong way to find the area under a curve because it's too tough to learn." While MVVM isn't as complex as Calculus, building complex software is a complex endeavor and I don't think you are ever going to simplify it or boil it down to a simple formula (nor should you). If you struggle with MVVM, please, don't use it - find something simpler and easier. If your project is complex enough to use it and you still don't grasp it, please hire someone who does, have them plumb it out and learn from them.
No, I don't want Microsoft telling me what pattern to use nor do I feel it is their responsibility. I'm a professional and it's on my shoulders to invest the time to learn and understand what I'm building so I can build it the best way for the customer. Microsoft doesn't necessarily know what my customer does or needs, so how can they possibly tell me what pattern to use? Projects like Prism are great because they are a compromise: they provide guidance and share "best practices" of how something can be done, without forcing that implementation on the developer.
I'm using MVVM for a Windows Phone 7 app. I really like the idea of it but there's too many hacks, wordarounds and 3rd party tools needed to get it running.
Things are getting better with every release of Silverlight but I still think the technology is "bleeding edge".
Why can't you?
And no, MVVM is just one of many patterns and frankly, not even amongst the most popular ones. What is hurting Silverlight's development is a) Flash b) not being Flash c) being Microsoft centric d) learning curve.
Plus the fact WPF doesn't really seem to have caught on doesn't much help.
Someone has problems figuring out how to use navigational framework with MVVM => Someone doesn't use navigational framework => MVVM is killing navigational framework => MVVM is killing Silverlight development.
Would you say there are few flaws with this chain of reasoning?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm very new to programming, and I'd like to write a Windows Application. So far I've read Teach Yourself C in 24 Hours, what should I do (tutorial to read) next to accomplish my goal? Thanks
When I first started developing applications for Windows (about 15 years ago) I recall reading some very useful stuff by Charles Petzold. His more recent books are about C#, but his older books are still relevant because the Win32 API has not changed that much when it comes to the basics.
Hello, World!
Write the famous "Hello, World" program (Google it if unsure):
To output text to the console.
To output text to a dialog window.
To make the dialog appear after selecting a menu item.
Then, if you are still keen:
Write a program that allows a person to type in text into a text field. Display that text in a dialog window after clicking a button.
Save the text to a file.
Write a program to read the file and display its contents in a window.
That should get you started learning the fundamentals of what is happening when writing a Windows application.
Also, read all the links that people recommend you read, in this thread and others.
Old vs. New
Advice for learning .NET, C#, and C++ is great. Those technologies hide a lot of the boring "grunt" work for you. I still feel it is good to have an understanding of what is happening at a lower level for various reasons, including:
Learning C is applicable to more than Windows-based applications (some would argue .NET and C# are portable, which is true in theory, whereas ANSI C and Java are portable in practice).
Understanding what is hidden will allow you to avoid technical blunders and diagnose deep technical issues.
At this point it really depends on your goals. If all you want to do is write a Windows application, then use modern technologies that are better suited to such a task. If you want to write a Windows application with an understanding of how to write applications in general (not necessarily just for Windows), then keep pursuing the C path for now, and branch into other technologies as you expand your knowledge.
Depends on the application. But what you need now is to familiarize yourself with an API. APIs are basically premade functions that you use as tools to do... whatever it is the API was designed to help you do. You're looking for a graphical user interface API. Windows has its own but I recommend you use something crossplatform so your application will work on multiple platforms.
Look these up on wikipedia:
GTK+
Trolltech's QT4
They can pretty much do anything the windows API can do with the added benefit of working on multiple platforms like windows, linux, mac, etc.
http://winprog.org/tutorial/
These are pretty good for learning Win32. Charles Petzold is good resource if you can get your hands on a copy but The Forger's are free and you can have them in your hot little hands right now.
In general though you should spend some time just writting C/C++ apps that use the standard libraries first. Opening files, writing output, writing files, reading/writing stdio and get a good handle on the basics of the language first.
Looking up books on data structures, and analysis of algorithms are fundemental to any type of programming you want to do as well.
Read this.
Are you suggesting that you'd like to write a Windows desktop app in C? That's reaching back a long way. You're back in 2002, according to this.
Most people writing on Windows are using .NET, which means C++ or C#.
If you need some GUI or complex features,
You need some oriented object programming skills...
You can read some of this book serie : Head first... from O'Reilly
Head first Object-Oriented Analysis and Design
Head First Software Development
Head first C# or Java (It doesn't matter which language...)
Trolltech Qt4, it's a must, too ! Thanks CptAJ
They are very nice books for beginners... and advanced programmers too ;-)
Nice reading !
I disagree with a lot of the answers here... learning from the ground up is not a bad thing.
I wouldn't go out and make a whole app in C, but certainly making a little app in C is a good way to both learn the language and to appreciate (or more likely, detest) the win32 API.
Besides, you can't really appreciate what the newer languages/frameworks do for you if you don't experience the old painful way of doing things.
That said, recognize that there are newer languages and frameworks out there and learn them as well; particularly if you're trying to land a job.
I highly recommend theForger's Win32 API Programming Tutorial. It's very concise and easy to follow, and it's free.
While I won't say you've wasted your time learning some C, I'm guessing it's not where you're going to end up either.
If you really want to get rolling, without too much trouble, I'd highly suggest getting:
Visual Studio C# Express (it's free, and it's a great development environment)
A book on C#...Petzold is great, so a book like Programming Microsoft Windows with C# is perfect.
This should get you pretty much exactly what you want. You'll have everything you need, and Petzold starts you out very simply, and ramps you up to making interesting apps without losing you.
(You may wonder why I, and many other people are directing you to C# or other languages after you specifically said that you've already read and learned about C. This is because programming in windows using the old Win32 API is much more tedious. It is easy to quickly become overwhelmed by the sheer amount of extra chaff that has to go into it.)
At Microsoft, we have been working hard to come up with some great resources for simply creating Windows applications. Our page, Start Programming with Windows 7, will be sourced with tons of new resources for intermediate and advanced programmers.
There are two really important new learning series that we have been working on:
The Hilo Project: An application built from the ground up to show how you can develop programs that are specifically taylored to Windows 7 features using the most modern programming and application design methodologies.
The Learn to Program for Windows Module: An introduction to Windows programming written by a developer education expert at Microsoft. This module sounds more like what you are looking for, I recommend you check it out.
We're working on ways to surface learning resources as best we can on the Windows Developer Center - a collection of developer learning resources for people new to developing Windows or new to developing using the latest Windows features.
Additional guidance is coming through the new Home and Hub resources for client / Desktop applications on the MSDN homepage.
Try Ramp Up's Developer Basics, a microsoft learning road that shows stpe by stpe how to start windows programming. You can use the Visual C# Express version of Visual Studio as a development enviroment.
Read this book, Learn to Program with C#.
Then, make small projects in WPF; the best WPF book is Windows Presentation Foundation Unleashed; try that after reading the C# / beginning-programming book.
C#, the .NET Framework and WPF were created to move beyond the C Win32 API, to make it easier to create Windows applications.
If you want to make a standard Windows application, follow that path.
I would suggest using VB rather than C#. The syntax is a little friendlier, and it has all equivalent features and performance.
Why not follow the MSDN tutorials? If you don't like them try googling "VB tutorial".
http://msdn.microsoft.com/en-ca/library/hewcw458.aspx
Either VB or C# has a zillion examples of everything that can be googled. I would stick to either of these languages, if only for the "google support" alone.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So far, most of my GUI programming has been done in C++ with the Qt Framework, I'd like to branch out a little bit and do some C# with WPF. Originally, I wanted to write something like Adium for Windows, but that seems a tad...ambitious for a starting project. I'm not even sure if you can call libpurple stuff from C#, but I'd like to find out.
However, it seems my imagination is rather lacking and I'm having trouble thinking of something that isn't either completely trivial (a text editor! a calculator! wee!) or rather hard (something with libpurple).
So, any suggestions?
I don't want to write a calculator (even if it seems a rather fitting starting project for a GUI framework)!
A long time ago I started the "Quest for the Perfect Project" with a few colleagues - the idea was that we'd try to do everything as well as we possibly could, fully test-driven etc, while learning WPF, WCF etc. We reckoned that Battleships would be a really good game. You can start off relatively simply, but there are lots of ways to extend it over time.
We never actually got anywhere with the project, mostly because we all ended up at different companies and I started writing C# in Depth, but I still think Battleships was a good game to use for learning.
Start off with a two player, single screen, local-only game, and then work out network play, AI, variations for more than two players, leagues, chat etc.
(When running as a single screen it would be seriously non-ideal as an actual game - each player would have to look away while setting up the ships to start with, and if any player wanted to see their own ships later on to get an idea of how close the other player was, that other player would have to look away. It would be great for making sure you've got a working game engine though.)
My favorite open source WPF application I've seen so far is Family.Show, a simple genealogy application that seems to use WPF really well. The source code is available on CodePlex.
(source: vertigo.com)
Try taking a look at Coding4Fun. There are a few WPF projects on there that might be of use to you, including a version of Sudoku. You can either use the articles to sow some seeds and try to develop the apps yourself, or just grab the code and pull it apart to see how it all works.
My usual starting point for these kinds of expeditions is to write a simple accounting program; money in/Money out with scheduling and graphing.
It turned out to be a pretty useful exercise when i started out with WPF because it gives you the scope for some pretty advanced stuff when you get around to visualizing the data (if you want to get fancy!) and also has a LOB edge to it meaning you're more likely to gain some commercially viable skills with it. I also used IsolatedStorage in mine which was fairly useful.
Anywho, that's my suggestion.
Make a game. Or have a look at the Silverlight Showcase and find something interesting and make it, but better.
Quite another interesting game is what Tess Ferrandez (she an escalation engineer in the ASP.NET team at Microsoft) wrote on her blog, it's a game called "Traffic Jam", similar to "Parking Lot" on the iPhone. It's written in Silverlight, but you could easily make it a Windows WPF application.
Write a spreadsheet program.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
so as per one of my previous questions, I'm brushing up on my C skills.
My question is, what do people use for developing C?
Lots of people use Emacs, and have done so for years, but is it better to learn emacs than just use an IDE such as Geany or KDevelop?
Would also be interested to hear from those still using emacs, and why they use it over other apps?
Please note that I'm only really interested in the free IDEs / editors.
EDIT:
Thanks for posting links which answer some of my questions, but I guess what I'm really wondering about is:
Whether learning to edit using emacs / vim and compiling / debugging using the gcc-toolchain is worth it instead of just using an IDE, and why?
What are peoples reasons for not migrating to an IDE?
Has anyone moved from terminal-centric development to IDE development, and why did they move?
I started off by using IDEs, Microsoft or not. Then, while working on QNX some long time ago, I was forced to do with a text editor + compiler/linker. Now I prefer this simple combination––a syntax highlighting editor + C compiler and linker cli + make––to any IDEs, even if environment allows for them.
The reasons are, for me:
it's everywhere. If you program in C, you do have the compiler, and usually you can get yourself an editor. The first thing I do––I get myself nedit on Linux or Notepad++ on Windows. I would go with vi, but GUI editors provide for a better fonts, and that is important when you look at code all day
you can program remotely, via ssh, when you need to. And it does help a lot sometimes to be able to ssh into the target and do some quick things there
it keeps me close to CLI, preferably UNIX/Linux CLI. So all the commands are on my fingertips, and when I need them I don't have to go read a reference book. And UNIX CLI can do things IDEs often can't––because their developers didn't think you'd need them
most importantly, it is very much like seeing the Matrix in raw code. I operate files, so I'm forced to keep them manageable. I'm finding things in my code manually, which makes me keep it simple and organized. I do Config Management explicitly, so I know when I'm synced and how. I know my Makefiles because I write them, and they only do what I tell them to
(if you wonder if that works in "really big projects"––it does work, and the bigger the project the more performance it gains me)
when people ask me to look at their code, I don't have to learn the IDE they use
I've moved from a terminal text-editor+make environment to Eclipse for most of my projects. Spanning from C and C++, to Java and Python to name few languages I am currently working with.
The reason was simply productivity. I could not afford spending time and effort on keeping all projects "in my head" as other things got more important.
There are benefits of using the "hardcore" approach (terminal) - such as that you have a much thinner layer between yourself and the code which allows you to be a bit more productive when you're all "inside" the project and everything is on the top of your head. But I don't think it is possible to defend that way of working just for it's own sake when your mind is needed elsewhere.
Usually when you work with command line tools you will frequently have to solve a lot of boilerplate problems that will keep you from being productive. You will need to know the tools in detail to fully leverage their potentials. Also maintaining a project will take a lot more effort. Refactoring will lead to updates in make-files, etc.
To summarize: If you only work on one or two projects, preferably full-time without too much distractions, "terminal based coding" can be more productive than a full blown IDE. However, if you need to spend your thinking energy on something more important an IDE is definitely the way to go in order to keep productivity.
Make your choice accordingly.
Emacs is an IDE.
edit: OK, I'll elaborate. What is an IDE?
As a starting point, let's expand the acronym: Integrated Development Environment. To analyze this, I start from the end.
An environment is, generally speaking, the part of the world that surrounds the point of view. In this case, it is what we see on our monitor (perhaps hear from our speakers) and manipulate through our keyboard (and perhaps a mouse).
Development is what we want to do in this environment, its purpose, if you want. We use the environment to develop software. This defines what subparts we need: an editor, an interface to the REPL, resp. the compiler, an interface to the debugger, and access to online documentation (this list may not be exhaustive).
Integrated means that all parts of the environment are somehow under a uniform surface. In an IDE, we can access and use the different subparts with a minimum of switching; we don't have to leave our defined environment. This integration lets the different subparts interact better. For example, the editor can know about what language we write in, and give us symbol autocompletion, jump-to-definition, auto-indentation, syntax highlighting, etc.. It can get information from the compiler, automatically jump to errors, and highlight them. In most, if not all IDEs, the editor is naturally at the heart of the development process.
Emacs does all this, it does it with a wide range of languages and tasks, and it does it with excellence, since it is seamlessly expandable by the user wherever he misses anything.
Counterexample: you could develop using something like Notepad, access documentation through Firefox and XPdf, and steer the compiler and debugger from a shell. This would be a Development Environment, but it would not be integrated.
I have used Eclipse with the CDT plug in quite successfully.
Emacs would be better if it had a text editor in it... :-)
Use Code::Blocks. It has everything you need and a very clean GUI.
Netbeans has great C and C++ support. Some people complain that it's bloated and slow, but I've been using it almost exclusively for personal projects and love it. The code assistance feature is one of the best I've seen.
How come nobody mentions Bloodshed Devc++? Havent used it in a while, but i learnt c/c++ on it. very similar to MS Visual c++.
If you are looking for a free, nice looking, cross-platform editor, try Komodo Edit. It is not as powerful as Komodo IDE, however that isn't free. See feature chart.
Another free, extensible editor is jEdit. Crossplatform as it is 100% pure Java. Not the fastest IDE on earth, but for Java actually very fast, very flexible, not that nice looking though.
Both have very sophisticated code folding, syntax highlighting (for all languages you can think of!) and are very flexible regarding configuring it for you personal needs. jEdit is BTW very easy to extend to add whatever feature you may need there (it has an ultra simple scripting language, that looks like Java, but is actually "scripted").
If you're on Windows then it's a total no-brainer: Get Visual C++ Express.