It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I've barely/rarely used C++ in the past decade, and now it looks like I'll be doing something in it again. I'm looking forward to it, but have to wonder how it's changed since I last used it.
Are there any good / brief web pages, blog posts, or even books on how C++ has changed in the past decade?
Please note this question is regarding the language as well as tools or any additional information about working in C++. Specifically I'm working in Windows, using VC++2008.
While the official standard hasn't changed much over the past decade or so, there are several things of importance that have happened:
while it's not an official standard yet, an upcoming new standard (commonly called C++0x) is 'around the corner'. GCC and MSVC 2010 have incorporated significant parts of that new standard, but I'm not sure how much is in common use.
the Boost library has become a major player in providing additional support for the language - to the point that it was a significant influence on the new standard
'template-based' programming techniques have become much more prevalent, probably overtaking the older 'inheritence-based' techniques of code reuse (this might have been well underway when you last looked at C++ depending on the practives your shop may have been using at the time).
compilers (and in particular Microsoft's) have come a long way in standards compliance
The biggest change is that C++ standard actually works in all major compilers now. Things like member templates used to be iffy.
The language itself has not changed much. However, the best practices and idioms did a lot.
I suggest you take a look at the book "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" by Herb Sutter and Andrei Alexandrescu to see how modern C++ looks like today.
I think one of the biggest changes is one of mindset: many people have (finally!) realised that templates are incredibly powerful and don't need to be slow, and use of the STL and boost is much more widespread than 10 years ago.
VS2008 comes with TR1, a large addition to std that contains things like static arrays, reference counting pointers, and suchlike. Apart from that, the biggest change is just that the compiler compiles how the Standard defines.
An interesting question as I'm coming up to my 10th anniversary of programming C++ for coins.
My personal view is that I'd be somewhat wary -- but only somewhat -- since I haven't seen it all (though I think I can guess what it's like) -- of paying strong attention to the internet echo chamber. It's true, some people have gone full bore for the modern style of C++, with everything fully template'd up and using modern techniques to get the compiler doing its Prolog thing to best effect. However this is certainly not universally true, and, in the main, the C++ code I see today is very similar in most ways to the C++ code I saw ten years ago.
It would be a good idea to brush up on modern fashions, because some stuff that was somewhat rare ten years ago (smart pointers, regular use of RAII, standard library containers and stuff) is now more common. But unless you are sure that the code you will be working with is festooned with templates and boost and so on, you stand a good chance of working with something that's at heart very much like what you used to work with.
It may be unfashionable to say it, but that doesn't make it any less true: regardless of skill level, lots of people don't care for modern C++. Some, because they don't understand it. Some, because they do understand it. And for some, perhaps "care" isn't even the right word -- they don't even know it exists. And as you might expect these people all code accordingly.
Perhaps I move in the wrong circles, but my experience has been people who don't or can't or won't code in the modern style outnumber those that might do by some vast margin. And those who might do, generally don't, because they're outnumbered. Their code gets rewritten, or ignored, until they start writing stuff that other people can understand. So maybe this is good, or maybe this is bad -- it's hardly relevant, in my view, because the outcome is the same: that if your experience turns out to be anything like mine, you have a good chance of encountering today code that's remarkably similar to what you would have seen in 1999.
P.S. Nicolai Josuttis has written a couple of books that my last employer's resident template expert seemed to like. Also try Modern C++ Design (Alexandrescu) -- probably a bit dated now, but it explains many of the principles. Herb Sutter's Exceptional C++ gives, as I recall from a skim of a work copy, a good overview of some modern techniques without going too nuts on the template front. And of course boost demonstrates all this sort of thing (and much, much more -- then some bonus material) put into practice over a range of compilers.
(Hopefully the above list is not too dated; as my answer might suggest, I have found much less of a need to keep up to date with the latest trends in C++ than I would ever have expected.)
Related
I know this sounds like an opinion-based question, but I think it's specific enough since it's a question about real-life C++ implementation.
I'm a Mathematics student at college and I've been trying to teach myself C++ and I want to get an entry-level programming job in an environment that uses it. I've been learning from the book C++ Primer Plus, Sixth Edition, which I think is a great book because it goes into a lot of details about what's happening at the machine level and goes into the history of C and all that nitty-gritty stuff that's helping me become a "real" programmer.
I've applied for some jobs that look perfect for me, such as Entry-Level C++ Programmer at Nintendo. It seems like a lot of gaming companies use C++.
Here's the thing: I've learned C++ in a pointer-based fashion because that's how my book teaches it. I'm well aware, from reading Stack Overflow and seeing code samples other places on the web, that C++11 has given the language high-level capabilities such as using auto to iterate through the elements of a data structure.
So I'm wondering, if I have an interview at Nintendo and I do something like
for (std::vector::iterator it1(V.begin()), it2(V.end()); it1 != it2; ++it1)
instead of
for (auto it : V)
will I thrown out of the interview and laughed at? Is using pointer-based code obsolete? My brain is trained to do things the C++ Primer way, which is iterators/pointers. I understand this is good to know, but for practicality sake, should I get used to doing C++11 stuff?
should I get used to doing C++11 stuff?
Certainly you should! It's the actual standard.
Though to work in practice (especially in legacy or embedded environments), you should know how to build and use workarounds for outdated toolchains that don't support the actual standard.
That said, your question is not opinion-based, the answer is pretty much steered by the current situation in the C++ field.
I don't think anyone would laugh at you. But you might gain extra points, when you present both answers.
Honestly:
The first thing I'm judging an interview answer about code is:
Does it answer the question as intended, and is everything syntactically and semantically correct.
Other major points are:
* Knowledge of the C++ standard library (in general)
* Creativity and ability to abstract out situations and patterns
You won't be thrown away for not using C++11, if that is the question. I know very few companies (and, well, C++ developers) that actually use it. It will take time before C++11 becomes the de facto standard.
Anyway, for a junior position, you shouldn't be worried about that all that much. Better focus on a working code than a fancy one.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I'm starting C++ programming in my first job. I'm a CS student and I have learn programming in Java. What advice would you tell me to watch out so I don't cause trouble in my new job?
Would you have any advice or references would be appreciated.
(example: I know C++ is more likely to have memory problem than Java)
Thank you very much!
Maybe you already know this, but one common mistake for folks used to Java and learning C++:
Don't use new unless you have to (and you probably don't really have to). In most cases where you want to create an object, you should just create it "on the stack", like ClassType obj;.
Two things:
Get yourself a copy of Effective C++ by Scott Meyers.
Lint your code. This will not only catch potential bugs early in the development process, but also teach you good coding habits (e.g. declaring a method's input arguments as const references). I use PC-Lint for this.
For me, the biggest difference between Java and C++ is pointers, so I would try to get pointers down. Just my opinion.
No two ways about it. You're going to be a menace until you've been bit enough by C++ gotchas to hate the language. I'd recommend trying to write functions and not classes. A lot of people think OOP is great, but really most users want your code to "do" something, not "be" something. Anyways, good luck. :-)
Definitely what Chance said. Memory management is explicit in C++. I had an excellent textbook in college called Deitel C++. It's a C++ Bible.
I would also learn up on the Standard Template Library and Boost.
This might give you some ideas.
Some important excerpts :
Researchers (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, telegraph operation, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again.
And here is how to do :
Get interested in programming, and do some because it is fun. Make
sure that it keeps being enough fun so that you will be willing to
put in your ten years/10,000 hours.
Program. The best kind of learning is learning by doing. To put it
more technically, "the maximal level of performance for individuals
in a given domain is not attained automatically as a function of
extended experience, but the level of performance can be increased
even by highly experienced individuals as a result of deliberate
efforts to improve." (p. 366) and "the most effective learning
requires a well-defined task with an appropriate difficulty level for
the particular individual, informative feedback, and opportunities
for repetition and corrections of errors." (p. 20-21) The book
Cognition in Practice: Mind, Mathematics, and Culture in Everyday
Life is an interesting reference for this viewpoint.
Talk with other programmers; read other programs. This is more
important than any book or training course.
If you want, put in four years at a college (or more at a graduate
school). This will give you access to some jobs that require
credentials, and it will give you a deeper understanding of the
field, but if you don't enjoy school, you can (with some dedication)
get similar experience on your own or on the job. In any case, book
learning alone won't be enough. "Computer science education cannot
make anybody an expert programmer any more than studying brushes and
pigment can make somebody an expert painter" says Eric Raymond,
author of The New Hacker's Dictionary. One of the best programmers I
ever hired had only a High School degree; he's produced a lot of
great software, has his own news group, and made enough in stock
options to buy his own nightclub.
Work on projects with other programmers. Be the best programmer on
some projects; be the worst on some others. When you're the best, you
get to test your abilities to lead a project, and to inspire others
with your vision. When you're the worst, you learn what the masters
do, and you learn what they don't like to do (because they make you
do it for them).
Work on projects after other programmers. Understand a program
written by someone else. See what it takes to understand and fix it
when the original programmers are not around. Think about how to
design your programs to make it easier for those who will maintain
them after you.
Learn at least a half dozen programming languages. Include one
language that supports class abstractions (like Java or C++), one
that supports functional abstraction (like Lisp or ML), one that
supports syntactic abstraction (like Lisp), one that supports
declarative specifications (like Prolog or C++ templates), one that
supports coroutines (like Icon or Scheme), and one that supports
parallelism (like Sisal).
Remember that there is a "computer" in "computer science". Know how
long it takes your computer to execute an instruction, fetch a word
from memory (with and without a cache miss), read consecutive words
from disk, and seek to a new location on disk. (Answers here.)
Get involved in a language standardization effort. It could be the
ANSI C++ committee, or it could be deciding if your local coding
style will have 2 or 4 space indentation levels. Either way, you
learn about what other people like in a language, how deeply they
feel so, and perhaps even a little about why they feel so.
Have the good sense to get off the language standardization effort as
quickly as possible.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
What does C++ add to C?
What features of the language are the Clang/LLVM projects, the parts of GCC that are being written in C++, chromium, and any others all taking advantage of? What features are they avoiding?
Like all sophisticated and powerful things there is a price to be paid to succeed in C++.
You have to be incredibly careful with memory management.
Multi-paradigm capability means you have to be really good at design to avoid making a mess.
Extreme performance requires careful planning and selection of features used.
The ability to circumvent most every language policy requires monumental self discipline.
So if you're sloppy with memory, poor at design, don't need fast programs, or have no self discipline, then please don't learn C++. There is always Java or C#.
meta programming? templates?
like with C you get performance, but the code looks horrible.
with the high level languages you get nice code but there is less flexibility to make the fastest possible code.
with c++ you can do both? you can freely make anything as fast as it could be made in C, but native object orientation, and templates/operator overloading ect makes it so you can write fairly nice looking code too. indeed, you can make it so it is neat and fast.
I have never really found it more of a pain to write stuff in c++ than in a higher level language. the trick is having good libraries.
Because despite academic efforts such as Singularity, there's not a single mainstream OS where drivers can be written in a high-level language.
Note that anything that can be done in C++ can also be done in C, but some things are a lot easier in C++.
Not? I would say it's not worth if you performance is not an issue for you. (Follow the double negatives.)
My two cents:
Although I don't program in Python, I would have to say that Python is probably the best programming language for getting real work done. It's an elegant language, and it has an enormous collection of libraries for doing various things. However, my experience as a user has shown me over and over again that Python is slow (take yum, for example).
I do know Haskell pretty well, and I have to say that it's a friggin' awesome language. Better yet, it is compiled, and its speed is competitive with Java and C++ (though you have to put forth extra effort to get this speed in some cases). However, libraries for things like database access don't always match the elegance of Haskell's base libraries (I'm probably way wrong about this), and they're harder to install on Ubuntu. In my opinion, that's why it's more challenging to get real work done in Haskell than in Python.
Ruby's good for web applications. Other than that, it's slow (though I speculate jRuby or something might be faster).
C++ is far from elegant, and in many cases, elegance is frowned apon. Anyone ever told you to use static_cast instead of C-style casting? Anyone ever told you not to use namespace std;? C++ has a lot of features, but doesn't tend to have many important language features (such as closures, which are formally proven to be the best thing since sliced bread).
Why do people use C++, then? Well, it's performance-focused, making it a good choice when you need speed. It has classes, namespaces, and templates, so it's a good choice when you want better code organization, but still need to use "C" for some reason. Also, it has the Boost library, which I've heard is really good for getting work done.
I started programming in C++. It was my first language, but I have not used it in many years.
What are the new developments in the C++ world? What are the BIG things - technologies, books, frameworks, libraries, etc?
Over the last 7-8 years what are the biggest influences on C++ programming?
Perhaps we could do one influence per post, and that way we can vote on them.
Boost:
free peer-reviewed portable C++ source libraries.
We emphasize libraries that work well with the C++ Standard Library...
We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are included in the C++ Standards Committee's Library Technical Report (TR1) and in the new C++11 Standard. C++11 also includes several more Boost libraries in addition to those from TR1. More Boost libraries are proposed for standardization in C++17...
"Modern C++", STL, template metaprogramming and Generic programming.
(And yes, they're one single answer, because they're pretty closely intertwined and together represent a complete paradigm shift in C++ development. While some of them are older than 8-9 years, it's pretty much in the last years that they've really gained traction and really left "C with classes" in the dust.
C++0x
Modern C++ is not only a OOP language. C++0x (the new standard) will include many new additions. It might take some time before it is applied thoroughly in every IDE/compilers but it will add a lot to an already excellent language.
Here is a list of new features of the new standard: C++0x
**Edit: C++0x is the result of the past 8-9 years (thank you jalf).
Qt is also pretty useful, 'pretty', well-documented, portable, and free (now under LGPL).
Developers who actually understand OO rather than C with Classes.
Though the field is still full of C programmers with think they know C++ (but don't they are just C with Classes people).
Although it started in 1998, but it really got going in the last 7-8 years, the boost libraries have added a huge amount of high quality code, which in many ways has helped keep c++ somewhat up to date with the capabilities of more modern languages.
Good books to help prospective C++ programmers learn how to use the language properly. Effective C++ by Scott Meyers was a massive help for me. There are other threads on C++ books.
Scott Meyers wrote about most important C++ people and the most important C++ books. These all had a major influence on how programmers write C++ today.
Commercially available whole-program and profile-guided optimization from various C++ compilers, notably Intel's and Microsoft's. In particular, cross-module inlining makes it easier to write well-factored code that blazes.
It’s usually not the first language
you learn at college or university
anymore. This makes prospective
learners appreciative of C++ and
eases them into it.
The internet, video editing sites,
and forums that help programmers of
all levels to get help and feedback
in a very timely fashion.
To me, besides the already mentioned boost, TMP, MC++D etc., the shift away from teaching C++ as "C plus some extras" towards "C++ is a very different language that's not to be used like C" is very important. That would make Koenig/Moo "Accelerated C++" is a huge influence, even though it's a beginners book and even though it's a beginners book that has (with only 250 pages) much too steep a learning curve.
Stroustrup had been saying things about a better language hidden within C++ and the need to teach it better, but I never really understood what he meant until, after 10 years of C++ programming and experience in TMP, I read the book and was enlighted. :^> It's not that I learned any new technical facts from the book. It just taught me a better way to look at (and teach) C++.
And, yes, I have been programming different since then.
Over the last 7-8 years what are the biggest influences on C++ programming?
Boost was already mentioned and I second that.
The importance of Boost is not just its efficiency and spectrum, but also the promotion of concept-based methods.
Stepanov's famous statement at http://www.stlport.org/resources/StepanovUSA.html
I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all.
still holds, the concept of "everything" is still every thing and not "object" - if it was "object", what would "class" then be?
And promoting those concept-based methods is in order, because contrary to common wisdom OOADP is often amazingly concept-less:
OOA is nice for reformulating problems the fancy way but we're not paid for talking fancy but for realizing machine support for workflow concepts users have for their problem domain.
OOD has more value in it if it used as a means to achieve a proper decomposition of large systems and as means to express thinking in patterns (which is quite natural for us), but it is never to be taken as a self purpose. I still recall OO "designs" from ~2000 which were presented with great ado and OO babble and featurism but were not even self-consistent.
The concept behind that method should be finding appropriate and useful abstractions, not finding every possible abstraction. Also in ~2000 I've once seen a (even multi)-inheritance hierarchy of depth 7 from which just one leaf class and its possible descendants would ever be used in the system to be created.
Finally OOP, in the closest sense, naturally tends to create state which is then carefully, and, of course, by more OO, so "More of the Same" (Watzlawick), to be protected against concurrent access. In these situations often the concept needed would be doing something instead ot the OO assembly having something.
C++ coding was 10 years ago, especially due to its "competition" with Java, quite susceptible for the OO odds mentioned, so I think that concept-based methods were a great cure.
Boost libs are role models for successfully applying those methods.
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.
When I first learned C++ 6-7 years ago, what I learned was basically "C with Classes". std::vector was definitely an advanced topic, something you could learn about if you really wanted to. And there was certainly no one telling me that destructors could be harnessed to help manage memory.
Today, everywhere I look I see RAII and SFINAE and STL and Boost and, well, Modern C++. Even people who are just getting started with the language seem to be taught these concepts almost from day 1.
My question is, is this simply because I'm only seeing the "best", that is, the questions here on SO, and on other programming sites that tend to attract beginners (gamedev.net), or is this actually representative of the C++ community as a whole?
Is modern C++ really becoming the default? Rather than being some fancy thing the experts write about, is it becoming "the way C++ just is"?
Or am I just unable to see the thousands of people who still learn "C with classes" and write their own dynamic arrays instead of using std::vector, and do memory management by manually calling new/delete from their top-level code?
As much as I want to believe it, it seems incredible if the C++ community as a whole has evolved so much in basically a few years.
What are your experiences and impressions?
(disclaimer: Someone not familiar with C++ might misinterpret the title as asking whether C++ is gaining popularity versus other languages. That's not my question. "Modern C++" is a common name for a dialect or programming style within C++, named after the book "Modern C++ Design: Generic Programming and Design Patterns Applied", and I'm solely interested in this versus "old C++". So no need to tell me that C++'s time is past, and we should all use Python ;))
Here's how I think things have evolved.
The first generation of C++ programmers were C programmers, who were in fact using C++ as C with classes. Plus, the STL wasn't in place yet, so that's what C++ essentially was.
When the STL came out, that advanced things, but most of the people writing books, putting together curricula, and teaching classes had learned C first, then that extra C++ stuff, so the second generation learned from that perspective. As another answer noted, if you're comfortable writing regular for loops, changing to use std::for_each doesn't buy you much except the warm fuzzy feeling that you're doing things the "modern" way.
Now, we have instructors and book writers who have been using the whole of C++, and getting their instructions from that perspective, such as Koenig & Moo's Accelerated C++ and Stroustrup's new textbook. So we don't learn char* then std::strings.
It's an interesting lesson in how long it takes for "legacy" methods to be replaced, especially when they have a track record of effectiveness.
Absolutely yes. To me if you're not programming C++ in this "Modern C++" style as you term, then there's no point using C++! You might as well just use C. "Modern C++" should be the only way C++ is ever programmed in my opinion, and I would expect that everyone who uses C++ and has programmed in this "Modern" fashion would agree with me. In fact, I am always completely shocked when I hear of a C++ programmer who is unaware of things such as an auto_ptr or a ptr_vector. As far as I'm concerned, those ideas are basic and fundamental to C++, and so I couldn't imagine it any other way.
In the days of Windows 3.1, C was the standard. When C++ hit the developer market and later became ANSI standard, it was the new hotness. It popularized the OOP acronym and some of the basic design patterns using polymorphism.
Now, with the greater acceptance of low-barrier-to-entry managed platforms, like C#/.NET, there's less of a reason to use C++. So much of the developer base will have a choice and let's be honest: C++ is a bear to learn for a novice. With C#, you can just run with it.
That leaves really only the platforms that NEED C++ and the die-hard C++ evangelists to continue practicing the art. This is the community that needs and wants all the layers of abstraction that is considered "Modern C++".
So yes, I believe "Modern C++", as you state it, is becoming more prevalent. Albeit, it's prevalent with a different audience than has used it in the past.
I am one of these guys who learned how to work with the STL and heard a lot about RAII and good C++ programming practices from day 1. Looks like some of the most recommended books for learning C++ today (like Accelerated C++ and the Effective C++ series) focus on using STL tools instead of rolling up your own stuff, and also give lots of "rules" for effective (or "modern") programming.
But talking with friends I also noted some companies still work with "C with Classes", not "Modern C++". Maybe the culture proposed by the authors and users of the "Modern C++" will prevail someday :)
I think you just had a bad experience starting off.
You need to get yourself Scott Meyers Effective C++ books. I started on C++ in anger in 1999, my team lead made me sit and read Effective C++ and More Effective C++ before I was allowed to check in ANY code.
Most of his advice is on the lines of "Don't use this feature, but if you must, keep this in mind"
If you follow his advice you'll write good or "Modern" C++.
He has a book on STL now too, but that I haven't read.
In my C++ jobs, I've found the modern features to be increasingly used, and more people asked me about them in phone screenings and interviews. As far as I can tell, they're catching on.
I learned C++ originally as something like C with Classes; although the language had advanced far beyond that, the books I read and people I worked with were firmly stuck on "old C++". RAII something people would think about, rather than automatically do, and I remember reading some of the early articles on the problems of exception safety.
As pointed out, there's new books out now. Many of the old ones are still relevant, but they increasingly seem to be full of explaining why obviously bad ideas are bad. (Similarly, it's hard for modern readers to understand how revolutionary Freud's ideas of an unconscious mind were, since it's now conventional wisdom.)
Stroustrup just came out with a textbook, Programming: Principles and Practice Using C++. I bought it because I haven't yet failed to learn good stuff from a book of Stroustrup's, but haven't gotten past the first few chapters. So far, all I can say is that I approve of the way he's starting out, and it's at least a good introduction to how C++ should be used.
While working on the project I am presently involved with, there's a lot of C++ code which has evolved over a significant period of time (over 10 years now). The evolution you speak of is clearly visible there: the older code is often "C with classes" - raw pointers, char* strings and use of associated C functions, arrays etc; newer code uses ATL smart pointers and such to manage resources, but still sticks to hand-coded loops most of the time, and iterator is a rare sight; and the newest one is chock-full of STL containers, algorithms, shared_ptr (including custom deleters to manage handles etc), heavily genericized function and class templates, and so on. Most traditional "C with classes" coding techniques, such as raw unencapsulated pointers with manual lifetime management, are very much frowned upon in code reviews these days. Judging by this, it seems that your observation is accurate.
The most recent development seems to be a fad for C++0x lambdas - which has a positive side in that it also tilts the balance in favor of using standard algorithms over hand-coded loops, since now you can have all your code inline with algorithms as well.
I wouldn't say that std::vector qualifies as "modern" these days. It is really basic.
Generally my impression is that people have gained some experience with modern C++ style and sobered up a little. Just to take a simple example, STL for_each was interesting but in practice it does not add a terrible lot of value over a plain C loop. It is harder to debug and sometimes does not provide the best performance. Also the constructs for functional programming in current STL are generally very cumbersome, especially if you got experience from a real functional language like ML.
In my experience (Spanish University), unfortunately, the norm is to not to consider languages in itself. They use the easiest languages to teach programming (i.e. Java), because it is supposed to be easy for teachers and students, and then they use C for the OS classes and such.
C++ is introduced very slightly (at any rate at any course), just to provide a C with classes. They don't get into boost or even STL. I think keeping up with all the characteristics and way of thinking of C++ is costly for both teachers and students. How many of C++ programmers here know enough of all the Boost libraries to use them to give a better solution or to design it? One has to have an interest in keeping up with all the new libraries and idioms.
However, as I said, it seems that programming in general (and programming languages in particular) are not taken too seriously, as it seems to be a temporal assignment when they start a job, then forget how to program as they go up in the enterprise tree. Many enterprises here, and the University itself, have the feel that programming can be done by anybody.
If you follow this philosophy, then for most people I know, C++ will always be "C with classes".
Regards,
In my experience it vastly depends on the age of the software product/project. Most new projects that I am aware of do use modern C++ (RAII, STL, Boost). However, there are many C++ projects that are more than 10 years old, and you don't see modern C++ there.
Also, keep in mind that some of the most popular STL implementations were pretty much broken until maybe 5 years ago (MSVC < 7.0 and GNU < 3.00)
I think the biggest barrier I've encountered is toolchain support, especially on cross-platform projects. Until a few years ago, it was common to see build notes saying "x platform needs STLport to work because their compiler is borked". Even now, I see issues with people trying to use multiple third-party dependencies tied to different versions of BOOST. This makes linking impossible, meaning you have to go back and rebuild your deps from scratch.
Now that just about everyone has stopped using MSVC++ 6, the STLport mess is behind us. But as soon as TR1 is out the door, we're back to "which versions of which environments support it and get it right" and once again this will slow adoption.
I work on a project begun in C (not C++) in 1992. Deploying modern practices across the legacy codebase would be impossible. Likewise I work on another project that is much closer to the cutting edge of C++ language.
Many teams I've been on and heard about consider the big "are we using exceptions?" question. This is code for "are we using modern C++?"
Once you aren't using exceptions, you are precluded from using the full power of the language and its libraries.
But many older codebases are exception-less, and it is perceived to be difficult to shoehorn exceptions into a codebase that doesn't expect them, or into a team that doesn't know how to use them, so the answer in such cases is often 'no.'
In my experience, modern C++ needs someone who is passionate about it on the team, who can't stand the sight of anything less, to push for it. It also needs to overcome the objections of those who want it to be more like the legacy code.
While I don't think that old-C++ codebases are going away very quickly, I do believe there are more of these passionate people in the world than there were five years ago. They face the same uphill battle they faced five years ago, but they are more likely to find kindred spirits.
Before answering such a question, you'd have to agree on what "Modern" is. This not likely to happen, since "Modern" is a poorly defined word, and means different things to different people. The title of Alexandrescu's book (Modern C++ Design) doesn't really help either, since it is largely a book on Template Metaprogramming, which is a specific area of C++ but by no means the only one.
For me, "Modern C++" != "Template Metaprogramming". I would say C++'s features on top of C would fall into these categories:
Classes (Constructors, Destructors, RAII, Dynamic Casting and RTTI)
Exceptions
References
Data Structures and Algorithms in the standard library (STL)
iostreams
Simple class and function templates
Template metaprogramming
None of these are particularly modern, since they've all been around nearly 10 years or more. Most of these features are useful and will allow you to be more productive than straight C for many use cases. A good programmer should and will use all of them in a decent sized project, but one of these things is not like the other:
Template Metaprogramming.
The short answer to template metaprogramming is just say no. Unfortunately to some people it's synonymous to "Modern C++ programming", due to the book, but in the end it creates more problems than it solves. Unless C++ develops better generic programming mechanisms like reflection, it will be ill suited for generic programming, and higher level languages like Python will be a better fit for those use cases. For that and many other reasons, see the C++ FQA
The best book for learning C++. "Accelerated C++" by Koenig & Moo, teaches what you describe as modern C++, so I guess most people these days are using it. For those of us that have been using C++ for quite a while (since the mid 80s in my case), modern C++ is a great relief from the tedious tasks of writing our own arrays, strings, hash tables (repeat ad nauseam).
I have looked at C++ Jobs on indeed and "modern" libraries are more and more used in job descriptions, MFC which is quite an "old-style" c++ library is less used.
The standardization of the language in the late 1990s was the first step, it allowed the compiler makers to focus on the "standard" set of features, also allowed the language to fix some of the rough edges, which appeared trough the standardization process.
This in turn allowed development of frameworks based on standard features of the language, and not on features provided by a particular compiler implementation. The Boost library is notably in this regard. Also this permitted that new development is based on previous work, thus making possible solutions to more complex problems.
A notable change here is how previously frameworks were based on the notion of base classes and derivated classes (a run time feature). But now most advanced features often are heavily based on "recursive" templates (a compile time feature).
The STL has its pros and cons but it survived the test of time, if you want something that works and is simple STL surely has something to help you start. There's no point in reinventing the wheel (unless for didactic reasons).
Computer hardware has also made great leaps from the 1990s, then the memory and CPU are no longer a constraint for the compiler. So most of the theoretical optimizations from books are now possible.
The next steps of the language is the support of multi-core programming, which is part of 0x standard effort.
Yes and no. Certainly for new projects it is increasingly popular. However, there are still barriers to adoption that are practical, not political, that others haven't mentioned. There are a lot of commercial C++ libraries that use ABIs from ancient compilers that don't properly support the features seen in Modern C++, and a lot of companies rely on these libraries. Sun Studio on Solaris for example can't work with Boost without the use of STLport, but any 3rd party commercial library you want to use will require Sun's version of the STL. Same story with GCC 2.95 and Redhat Enterprise Linux.
It's amaizing how little effort goes into making c++ more stable. The warning system is in place, but it's not evolving much. It's even easier to shoot yourself in a foot than it was 10 years ago. Dont know why, but c++ is still my favorite language. :)