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. :)
Related
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
C++ tutorial for experienced C programmer.
I program in a number of languages frequently and have been using C++ lately. Basically my classes are just wrappers around pure C code. Almost like a struct with associated methods. This gives me the encapsulation and privacy that I want for my data. I have a small hierarchy of classes and am just barely using inheritance.
I am familiar with OO concepts and know what search terms to use when i need to find out about a particular concept in this regard. However, as I have discovered in my foray in the programming world, often the language features that are really helpful are hidden to the newcomer or novice, and the useful bits that I need have already been written and are in a library somewhere that is freely available (most times part of the framework - like in .NET).
What path would you suggest to gain this vital knowledge in C++ and stop myself reinventing the wheel (poorly).
This is the wrong way to use C++. You would be better served grabbing a copy of Accelerated C++ and reading it. Yes, it's a beginner book but unless you want to continue treating C++ as just C with objects then you need to focus on how C++ programmers do things instead of just sticking with what you already know. You need to start from the beginning and build a good foundation in C++.
Learn the STL if you're going to really plan to use C++ in the future. Though opinions will vary widely, particularly among the die-hards, I think there is absolutely no problem using C++ as "C with objects."
Boost is also pretty awesome.
EDIT: Note the downvotes already coming in from the die-hards. C++ acolytes really don't like to hear people advocate using the language as "C with objects." I stand by my statement. You can write quite shippable and commercially viable code without going crazy with an RTTI-enabled, templatized, multiply-inherited set of classes. Remember KISS.
Scott Meyers' books are a great place for C programer to begin with C++.
I recommend Thinking In C++ by Bruce Eckle. Normally it's available for free online, or as a book.
I suggest you read the books:
"C++ Coding Standards: 101 Rules, Guidelines and Best Practices" --Sutter & Alexandrescu
"Modern C++ Design: Generic Programming and Design Patterns Applied" --Alexandrescu
And probably anything else by Andrei Alexandrescu that you can get your hands on.
Then, there are a number of design patterns and programming idioms that make it very clear why "C with objects" is extremely reductionist. Just to name a few: RAII (Resource Allocation Is Initialization), PImpl (or Cheshire Cat), Factory functions, Smart Pointers, Singleton, Type Traits, Expression Templates, etc. When you know about these, you are no longer programming in C++, but in ++C (because you get a result that actually reflects the increment over C).
As for not reinventing the wheel, like many have said already, make sure to first explore the possibilities in the Standard Template Library (STL) (which is much richer than you might think) and then look at Boost (www.boost.org) which has libraries for a lot of diverse purposes and they are extremely high quality (and some are just works of art, like Spirit, Proto, Lambda and MPL). After that, there is of course a large amount of open-source software in C++ out there, but use it with caution: sometimes it is better to reinvent a wheel that fits perfectly to your application than to use one that might not be appropriate or powerful enough, or worse, full of bugs!
I suggest the book The C++ Programming Language for filling in the gaps in your basic C++ knowledge, and BOOST as the first place to look for existing libraries supporting your programming.
Have you thought about getting the C++ Primer Plus? It's a really good book.
The C++ Standard Library: A Tutorial and Reference
Read Meyers for specific tips, but also Stroustrup's Design and Evolution. The latter gets into the motivation as to why C++ is what it is, and very much comes from a "how to improve C" viewpoint.
As for "The C++ Programming Language", 3rd edition is very long. If you can find the 2nd edition, its much more digestible, although of course occasionally out of date (but mostly just less complete).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm something of a new, reluctant convert to C++ from a Pascal, Ruby, and PHP background. I haven't worked with Pascal since a few months of torture with "Delphi Turbo;" since then I've practically been eating and sleeping Ruby and PHP. I'm already well acquainted with object oriented programming and many various subjects.
My main trouble is that I already know the rudiments of C/C++ programming, less the actual experience of working with C++. I worked with C for long enough to realize that even without macros, etc, I didn't want to work with it. (Some of the disgust was from maintaining a CGI application in C, when accustomed to Pascal's automatic string management.) I know just enough C++ to be dangerous to myself and anyone else unwitting enough to use my "code."
I'd really like to work up to a good enough understanding of C++ to use libraries like Crypto++ and Boost without major problems or in-depth knowledge of the language's intricacies. I just need to figure out how to work with C++ without killing myself (either with C++, or with the long-standing dislike that I'm already battling).
What are effective resources that will teach me C++ without assuming that I must be retaught all basic programming? I'd rather not relearn concepts that I already know, unless the paradigm in C++ is significantly different. I'm also learning on my own time, so don't recommend me a book complex enough to need a guru to explain to me, please! And I have an effective budget of $0 for learning C++, so please keep suggestions to quality online resources or books common enough that I could likely find them at the library.
Read Effective C++ by Scott Meyers - it's a good guide for getting past the basics of C++ and showing how to write and use "correct" C++ code
The C++ FAQ Lite is a great resource.
I highly recommend Stroustrup: The C++ Programming Language (Third Edition). As the author of C++ he is the authority on the language, and the book is useful as a reference as much as it is for learning the language. It's common enough that most good general purpose libraries will have a copy. He goes into quite some depth on all the features of C++, including explanations of why certain design decisions were made in the language. Personally, I think this is the best book around for programmers to learn C++.
Once you have a good grip on core C++, David Abrahams and Aleksey Gurtovoy's book, C++ Template Metaprogramming, goes into further depth and provides many examples of how C++'s template system allows you to perform complex compile-time programming, a highly valuable skill these days. This one is a little less common but you can probably find it at a university library.
I can give you a couple of keywords you might want to research in more detail:
RAII (Is pretty much the technique that ensures you don't have to worry about memory leaks. Very convenient)
Generic Programming (The STL in particular. Experiment with iterators and the standard library algorithms, and see just how powerful these abstractions are. They're a key part of what I like about C++)
Functors (Perhaps too simple on their own, but the way they can be used instead of function pointers with the algorithms mentioned above is interesting)
And just get familiar with templates, and "mild" forms of template metaprogramming. (Traits classes, for example, and (partial) specializations.
And just keep an eye on the C++ questions here on SO. A lot of interesting topics are regularly brought up.
But the best advice is probably to keep it completely separate from C. Forget everything you learned about how to use C. It either doesn't apply in C++, or leads to inferior code that is harder to read and maintain.
It's an interesting language in its own right, and has a number of unique features. Leverage those, and it can actually be fun to work with C++. Treat it as an overengineered Java, PHP or C, and it'll just make you want to throw up.
You need to write code. A lot of code in C++. There is no substitute. You also need to read good code.
I agree with the suggestion for Scott Meyers' books though. Those are pretty good.
Part of your learning will be the leap from procedural programming to OO.
I would highly recommend the book "C++ Common Knowledge" by Stephen C. Dewhurst. Don't know if it's common enough to be found at the library (it's not at mine, but my library sucks for computer books that aren't 5-10 years out of date), but it does an excellent job of taking the complex aspects of C++ and making them easy to understand, without dumbing anything down for beginners. Definitely worth the investment.
To quote from the back of the book:
This book is for you if
You're no "dummy," and you need to get quickly up to speed in intermediate to advanced C++
You've had some experience in C++ programming, but reading intermediate and advanced C++ books is slow-going
You've had an introductory C++ course, but you've found that you still can't follow your colleagues when they're describing their C++ designs and code
You're an experienced C or Java programmer, but you don't yet have the experience to develop nuanced C++ code and designs
You're a C++ expert, and you're looking for an alternative to answering the same questions from your less-experienced colleagues over and over again
C++ Common Knowledge covers essential
but commonly misunderstood topics in
C++ programming and design while
filtering out needless complexity in
the discussion of each topic. What
remains is a clear distillation of the
essentials required for production C++
programming, presented in the author's
trademark incisive, engaging style.
Here is a link to a question with answers that should help you.
https://stackoverflow.com/questions/1227764/i-need-to-improve-my-c-skills-fast-is-this-realistically-possible/1227805#1227805
For effective stuff you can find online Cplusplus.com has a pretty good reference and information.
If you can find the book "C++ Common Knowledge" (Stephen Dewhurst) at the library or cheaply online, I would add that to the list posted on the StackOverflow link above as well as "The C++ Programming Language" (Stroustrup). Going through the questions under the C++ tag right here on SO should give you some good pointers and code examples to get you on your way.
Here's a list of good C++ books which teach you C++ rather than basics of programming.
Sit down and write some C++ code.
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.
I have tried to keep up with C++ since they introduced 1998 ANSI/ISO C++. I absorbed the new concepts and tried to understand them. I learned about exception handling, templates, and namespaces. I've read about the new cast mechanisms and worked with the STL library.
All of these concepts required a lot of energy. But now I am somewhat worried about the future of C++ when having a look at the new C++0x standard.
Things are getting more and more complicated. This language is becoming a monster.
I'm not sure that I want to keep up with the language anymore, since I don't do my day-to-day hacking in C++ anyway. I mostly use interpreted or bytecode languages.
So why should I bother to learn this difficult, yet exceptionally powerful, language? I can do 95% of my business with Python et al. With the remaining 5%, I can deal with plain old C++ or C without hassle.
What do you think?
Everyone uses a subset of C++. For almost all application programming in C++, whether server or client side, that subset is manageable. In my opinion, the only folks that need to stay on top of absolutely every nuance of the language are the library writers -- people implementing Boost, STL, Loki, etc.
But I would absolutely use the language that fits the task. If Python is more readable and more maintainable than C++ for your job, and you don't need what C++ offers, then certainly stick with Python.
Hear what Bruce Eckel { author of the two of the so-called best C++ books } commented on C++ a few weeks ago:
That said, I hardly ever use C++
anymore. When I do, it's either
examining legacy code, or to write
performance-critical sections,
typically as small as possible to be
called from other code (my preferred
approach is to quickly write an app in
Python, then profile it and if
necessary improve performance by
calling small portions of C++ using
Python's ctypes library).
Because I was on the C++ Standards
Committee, I saw these decisions being
made. They were all extremely
carefully considered, far more so than
many of the decisions made in Java.
However, as people have rightly
pointed out, the resulting language
was complicated and painful to use and
full of weird rules that I forget as
soon as I'm away from it for a little
while -- and I figured out those rules
from first principles while I wrote
books, not just by memorizing them.
Additionally, you should read this thread and Danny Kalev's predictions on C++.
However, the growing complexity of C++ will create pressure towards splitting the language into quasi-official dialects. We can already see this trend today; it will probably intensify in the future.
EDIT:
You should take a look at this discussion, too:
C++ - Anyone else feel like C++ is getting too complicated?
First, many features of C++0x are to make the language easier to use. More readable template compile errors, more consistent initialization syntax, support for threading, which would otherwise have to rely on platform-specific libraries and so on.
So if you do use C++, I feel learning the important parts of C++0x should be a manageable task. Remember that you don't need to learn all the new features to use the language. Some features are primarily added as an aid for library implementers, for example allowing the STL to be implemented more efficiently, but which shouldn't really affect the end-users usage of the language. And some are only really necessary in very rare cases. Ignore those parts of the language.
One of their stated goals with C++0x is to avoid it becoming harder to use.
But apart from that, do you need C++? If you do your coding in other languages, why bother keeping up with C++?
You're not forced to use every feature a language provides. I don't use setjmp/longjmp in C despite it being there. I also don't use every aspect of the Java collections.
If you think the new features will make your code delivery better (faster or higher quality or both), then use them. Otherwise ignore them.
It's useful to know at a high level what they all are, if only to get you through job interviews, but half the stuff they add to languages are unnecessary in my opinion.
I never even got around to using C++ templates before switching to Java, but I knew what they were for.
It's not always about learning the latest and greatest. Software (at least at your job) is about delivery of product. That can be done in COBOL or FORTRAN if you're proficient enough at it.
No one, except maybe Bjarne and Herb Sutter, know all of C++. As you've said it's an incredibly huge language. Expecting to be able to take the entire standard + the specific implementation details of your specific compiler or compilers is truthfully unrealistic.
But you don't need to know everything in order to use C++. Instead only learn the subset of C++ that is valuable to you and your projects. It doesn't hurt to keep expanding your knowledge but unless you're writing a C++ compiler, there's no reason to know the whole thing. Even if you accomplish it, all of the people you work with won't.
So why should I bother to learn this
difficult, yet exceptionally powerful,
language? I can do 95% of my business
with python et al. With the remaining
5%, I can deal with plain old C++ or C
without hassle.
Well, for the most part you answer your own question. There is no need for you to keep up with the bleeding edge of C++ at this time.
However, the language will keep marching on. In a few years, some of the concepts you consider a bleeding-edge waste of time today will be in common use. Someday you may find during your 5% of using "plain-old C++" that some example code or code you're collaborating on uses a construct you're not familiar with. At that point, you'll need to hit the net and brush up on the new "current" C++.
Is that going to be a problem? Of course not. You're a programmer. You keep abreast of the latest programming concepts in the context of your 95% language, which also changes over time. You will likely already be quite familiar with the concepts and need only familiarize yourself with its C++ syntax when the time comes that you must use them.
Personally I hope to continue keeping up with C++, even if my career moves more toward Java or another next-gen language. Why? I would like to say because it interests me the most and because I love the complexity and expressiveness of it all. More likely, though, is just because it was my first professional language; I consider it my "native tongue".
If it does not interest you, and does not concern your job or future job, don't bother. What's wrong with that? Nothing.
Good answers.
Computer makers compete for buyers, software competes for your disk space, and languages compete for users. They do this by trying to snag each other's features.
I'm wondering how long before we see Fortran come out with lambda expressions :-)
I am hard-pressed to find a single instance where C++0x has been made more complex than C++98. There are two things which really are complex:
Concepts.
the Memory Model
but the first one has been removed again (thankfully; standardizing unimplemented features has never worked out in C++, witness throw specifications, extern templates, auto_ptr, ...), and the second isn't really something that a modern programming language can escape. It's been externally induced by Intel & Co helpfully breaking your programs to make them run faster.
The rest is just fixing annoyances that every C++ programmer has been frequently hitting in the last decades.
As a side note: I find it ... amusing ... to see how languages such as C# get packed with a database query language (LINQ) and C++ is objurgated as being bloated.
You don't need to know every standard that comes out by heart. It does help to know about the big picture though. The 5% that you do code in may have you reinvent the occasional wheel. Depending on how much time, importance that 5% has (think Pareto) you need to take a call.
Also, any particular reason (like legacy code dependency) why you can't move that 5% to python?
First try attending a course on c++0x and make your firm pay for that :)
Our brains can fit amazing amounts of junk-knowledge. Instead of cursing and having programmer-wtf-moments we should first learn from program users and listen to other people's opinions/knowhows. Knowledge transfers much faster that way.
My suggestion would be to learn the new keywords of c++0x ( && FTW) but not bother trying to learn the entire lib. Use python for w/e you want, possibly C# for apps, then use C++(0x) when you need to do something powerful. and ask stackoverflow & google about the new container when prototyping.
You dont need to use a select few language,
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 visited a university CS department open day today and in the labs tour we sat down to play with a couple of final-year projects from undergraduate students. One was particularly good - a sort of FPS asteroids game. I decided to take a peek in the src directory to find it was done in C++ (most of the other projects were Java 3D apps).
I haven't done any C before but I have looked through some C code before. From what I saw in the .cpp code in this game it didn't look very different.
I'm interested in learning either C or C++ but will probably learn the other later on. Is there any advantage to me learning one before the other and if so, which one?
There is no need to learn C before learning C++.
They are different languages. It is a common misconception that C++ is in some way dependent on C and not a fully specified language on its own.
Just because C++ shares a lot of the same syntax and a lot of the same semantics, does not mean you need to learn C first.
If you learn C++ you will eventually learn most of C with some differences between the languages that you will learn over time. In fact its a very hard thing to write proper C++ because intermediate C++ programmers tend to write C/C++.That is true whether or not you started with C or started with C++.
If you know C first, then that is good plus to learning C++. You will start with knowing a chunk of the language. If you do not know C first then there is no point focusing on a different language. There are plenty of good books and tutorials available that start you from knowing nothing and will cover anything you would learn from C which applies to C++ as well.
Please see further reasoning in this answer.
I love this question - it's like asking "what should I learn first, snowboarding or skiing"?
I think it depends if you want to snowboard or to ski. If you want to do both, you have to learn both.
In both sports, you slide down a hill on snow using devices that are sufficiently similar to provoke this question. However, they are also sufficiently different so that learning one does not help you much with the other. Same thing with C and C++. While they appear to be languages sufficiently similar in syntax, the mind set that you need for writing OO code vs procedural code is sufficiently different so that you pretty much have to start from the beginning, whatever language you learn second.
I learned C first, and I took a course in data structures which used C, before I learned C++. This has worked well for me. A data structures course in C gave me a solid understanding of pointers and memory management. It also made obvious the benefits of the object oriented paradigm, once I had learned what it was.
On the flip side, by learning C first, I have developed some habits that initially caused me to write bad C++ code, such as excessive use of pointers (when C++ references would do) and the preprocessor.
C++ is really a very complex language with lots of features. It is not really a superset of C, though. Rather there is a subset of C++ consisting of the basic procedural programming constructs (loops, ifs, and functions), which is very similar to C. In your case, I would start with that, and then work my way up to more advanced concepts like classes and templates.
The most important thing, IMHO, is to be exposed to different programming paradigms, like procedural, object-oriented, functional, and logical, early on, before your brain freezes into one way of looking at the world. Incidentally, I would also strongly recommend that you learn a functional programming language, like Scheme. It would really expand your horizons.
If you decide to learn both (and as other people have mentioned, there's no explicit need to learn both), learn C first. Going from C to C++ feels like a natural progression; going the other way feels like deliberately tying one hand behind your back. :-)
I think you should learn C first, because I learned C first. C gave me a good grasp of the syntax and gotchas with things like pointers, all of which flow into C++.
I think C++ makes it easy to wrap up all those gotchas (need an array that won't overflow when you use the [] operator and a dodgy index? Sure, make an array class that does bounds checking) but you need to know what they are and get bitten by them before you understand why things are done in certain ways.
When all is said and done, the way C++ is usually taught is "C++ is C with objects, here's the C stuff and here's how all this OO stuff works", so you're likely to learn basic C before any real C++ if you follow most texts anyway.
I'm going to disagree with the majority here. I think you should learn C before learning C++. It's definitely not necessary, but I think it makes learning C++ a lot easier. C is at the heart of C++. Anything you learn about C is applicable to C++, but C is a lot smaller and easier to learn.
Pick up K&R and read through that. It is short and will give you a sufficient sense of the language. Once you have the basics of pointers and function calls down, you can move on to C++ a little easier.
In the process of learning C++ you will learn most of C as well. But keep in mind a lot of C++ code is not valid C. C++ was designed to be compatible with C code, so i'd say learn C++ first. Brian wrote a great answer regarding this.
Learning C forces you to think harder about some issues such as explicit and implicit memory management or storage sizes of basic data types at the time you write your code.
Once you have reached a point where you feel comfortable around C's features and misfeatures, you will probably have less trouble learning and writing in C++.
It is entirely possible that the C++ code you have seen did not look much different from standard C, but that may well be because it was not object oriented and did not use exceptions, object-orientation, templates or other advanced features.
Like the answers to many other questions in life, it depends. It depends on what your programming interests and goals are. If you want to program desktop applications, perhaps with a GUI, then C++ (and OOP) is probably a better way to go. If you're interested in hardware programming on something other than an x86 chipset, then C is often a better choice, usually for its speed. If you want to create a new media player or write a business app, I'd choose C++. If you want to do scientific simulations of galaxy collisions or fluid dynamics, behold the power of C.
I think learning C first is a good idea.
There's a reason comp sci courses still use C.
In my opinion its to avoid all the "crowding" of the subject matter the obligation to require OOP carries.
I think that procedural programming is the most natural way to first learn programming. I think that's true because at the end of the day its what you have: lines of code executing one after the other.
Many texts today are pushing an "objects first" approach and start talking about cars and gearshifts before they introduce arrays.
No.
It's generally more useful to learn C++ because it's closer to the most modern OO-based languages, like Eiffel or C#.
If your goal is to learn C++, learn modern, standard C++ in the first place. Leave the mallocs aside.
But Steve Rowe has a point...
Having observed people, who have learned Java first, struggle with the concepts of pointers and memory management in C++, I'd say that learning C first is a good idea, in order to grasp these two concepts, isolated from the complexities of other C++ features.
My two cents:
I suggest to learn C first, because :
it is a fundamental language - a lot of languages descended from C
more platforms supports C compiler than C++,- be it embedded systems, GPU chips, etc.
according to TIOBE index C is still about 2 times more popular than C++.
i think c is a really nice programming language, it's compact and somewhat easy to learn.
but if you only want to learn c++ start with c++. but i suggest you to learn both. and if you want to do that; i think it's better to start with c. as said before: it's small and somewhat easy to learn. might be a nice step-up to a more complex programming language as c++. (since c provides you with some basics)
good luck.