Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I currently program professionally in C#, and since I started in 2008 I've been curious about what unmanaged, C++ programming is like. I've looked at the obvious answer -to look at the job descriptions online - but they're high-level descriptions and job requirements that don't really go into the details of what professional programming in C++ is like. If you're a Windows programmer, does this usually involve working with CLI, MFC, or ATL? How many jobs are about maintaining legacy code vs. innovating something new? Is the extra attention to memory management an interesting challenge or a tedious task? Are the standard and Windows/UNIX libraries enjoyable to work with?

How often do you see a programmer go from a more "high-level" language background like C# or Java to C++, and how often do you see programmers move in the other direction?

What do you think will drive demand for future generations of C++ programmers (e.g. game development or maintaining legacy systems)?

share|improve this question

closed as not constructive by Mark Trapp Jan 30 '12 at 12:15

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.If this question can be reworded to fit the rules in the help center, please edit the question.

3  
I don't think there is an answer to this question - it should be "what professional C++ programming is like for you". Some people like managing memory explicitly, others don't. Some people love the well-known Windows/UNIX libraries, some hate them. Etc. I don't think we can tell how you would enjoy C++, neither that any experiences by others would be directly applicable to you personally. Your best bet is to try and see for yourself. –  Péter Török Jul 12 '11 at 15:02

3 Answers 3

up vote 11 down vote accepted

If CLI is involved, then it's not C++, it's C++/CLI. Despite the similarity in names, and even the fact that a C++/CLI compiler will accept a lot of legal C++, the two languages are still effectively entirely different.

As far as memory management goes, most of us use RAII (aka SBRM) so we not only get automatic management of memory but of (nearly all) other resources as well. Resource management in something like C# tends to be relatively ad hoc. In (well written) C++ it's much more systematic. The bottom line is that resource management typically intrudes much less on day to day coding than when you're stuck working around the problems caused by garbage collectors and their non-deterministic destruction.

C++ has almost never been used for things like basic CRUD applications. Even old code (or, perhaps I should say, "especially older code") was often right on the cutting edge when it was written. If it's still being supported, chances are pretty good that it's because it's still right on the cutting edge. Some of it may be ugly, hard to understand or maintain (e.g., was originally optimized to the hilt -- for a 486) but boredom is rarely a problem. Most brand new C# is dull and dreary compared to most 20 year-old C++.

The C++ standard library (once you understand it) will probably make you wonder how you ever put up with something like the CLI. At the same time, if you really want to work with something like the CLI or Java standard library (a giant class hierarchy with everything derived from Object) you can do that too -- you'll just have to find some really ancient C++ code that uses (for one example) Keith Gorlen's NIH class library (but you'll probably have to look hard -- C++ moved beyond this model a long time ago). The containers/algorithms/iterators in the C++ standard library are (at least) as much of an improvement on that as the CLI is over GW BASIC.

When you're comfortable with that, the next step is Boost. Boost is something of a two-edged sword though: on one hand, it can be a huge help in getting things done. At the same time, looking through Boost code can be one of the most humbling experiences possible. Imagine how you'd feel if you had direct access to all of Eric Lippert's C# code. Take that, multiply the quantity by 50 and the quality by 3, and you're getting close to the Boost league (though here, "quality" is referring less to things like fast, compact or bug-free, and more to doing things you'd have sworn were impossible, and/or really stretching your mind to view problems in entirely new and different ways that quickly start you wondering how you could have been so dense for so long).

share|improve this answer
1  
+1 Really on the point. About the last paragraph, the first time I really took the time to read calmly a boost library I left the office with a really sad feeling: I didn't know C++ at all :( The Alexandrescu book was very nice in this respect, it's probably the greatest reference on how to write contemporary C++ code. –  Vitor Jul 12 '11 at 16:59
    
NIH - does this possibly stand for "Not Invented Here"? –  mathStudent Jul 13 '11 at 4:32
    
@T. Webster: No, in this case it's the National Institute of Health (if memory serves -- something close to that anyway). –  Jerry Coffin Jul 13 '11 at 4:35
    
Thanks, that was my other guess, I guess I just didn't see how NIH and the class library would be related. –  mathStudent Jul 13 '11 at 13:14
    
@T. Webster: they apparently employ quite a few programmers. Regardless of the subject matter, a lot of government agencies mostly end up doing IT, tracking what the civilians in their sector are doing, checking that they comply with regs, etc. –  Jerry Coffin Jul 13 '11 at 14:51

I think there's no good answer to your question. The C++ market varies a lot. From people doing embedded work, to trading systems to mainline desktop applications.

I've used both GTKmm and Qt to create GUI applications on Windows. I haven't touched MFC except for a single legacy application.

I worked on a legacy application for a few years: both solving old bugs and extending it. Does this count as maintenance or as developing new code?

Right now I'm creating entirely new code using Ocilib (C, actually), Winsocks and Boost.

Standard libraries are fine in my opinion. Boost is also handy.

Memory management is hardly a challenge using modern techniques, I believe. I had more problems memory/resource problems back when I was using C# (and the incredibly bad IDisposable pattern) because resource management wasn't explicit. With RAII, reference counting and well defined object ownership semantics things are usually clear and nice to work with.

I've seen few programmers coming from a C# or Java background altough I met a lot of Java or C# programmers with a C++ background. I don't really know why.

share|improve this answer
2  
+1 for your point on memory management. I also find very little difference in mental effort on memory between C++ and so called managed languages. I don't think programmers in those languages realize how much time they spend concerning themselves with memory issues. They are just using different techniques to solve them. –  Karl Bielefeldt Jul 12 '11 at 16:47

There are pretty much two C++ markets.

One is, we have an ancient Windows app in MFC and we need it maintained, simply avoid any job ad that mentions MFC!

The other is, we have a real problem beyond; get field from data base put on screen, accept changes write to database. So we need to do it in a high performance language with a lot of libraries available.

ps. before the trolls come out. Yes you can make C# and Java high performance (some of the time, for certain tasks) and there are lots of C# libs (it's just that they only do what MSFT needed them to do).

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.