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,
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
For each new low-level program or library I write on POSIX systems, I always have to start out with the initial decision: do I write it in vanilla C, or do I go with C++? I like to think that each time I'm making a relatively informed decision, but I wonder if there's something I'm missing.
This isn't a which is better question, but rather, what aspects of each are better? Presumably, each has compelling strengths. In which cases should I chose the one instead of the other?
For example, below are some of the points I consider. What else am I missing?
Favoring C
Compatibility: Virtually every language and framework has some mechanism for interfacing with code written in C.
Simplicity: Debugging template code makes you age faster
Popularity: Think of all your favorite applications, servers, interpreters, and other tools. Chances are most of them are written in C, even though C++ was available when they started. All the cool kids use C.
Favoring C++
The STL: You certainly could implement your own RB-tree, quicksort algorithm, or double-linked list. But it probably won't be as good.
Templates: Sure, it's a pre-processor function masquerading as a language feature, but it sure is convenient.
Classes: C++ isn't exactly smalltalk, but at least it's not fancy assembly language either.
Compatibility: You can still use C in a C++ project.
I think you're making it more complicated than it really is. Which language are you better at in expressing your idea? If neither, and if you're a beginner at both, use C; otherwise if you're good at both pick what you feel like. Otherwise it doesn't matter nearly as much as just starting.
Alice: Would you tell me, please, which way I ought to go from here?
The Cat: That depends a good deal on where you want to get to
Alice: I don't much care where.
The Cat: Then it doesn't much matter which way you go.
Alice: so long as I get somewhere.
The Cat: Oh, you're sure to do that, if only you walk long enough.
C++ simply has many more features than C. That makes it a more complex language. But the benefit of using these features is that you will have to write (and maintian) less code.
You're not required to use templates, stl, exceptions, function overloads, or whatever C++ feature. But if your problem needs just one of these features, your program will be more readable if you do it in C++, rather than emulating the missing functionality in C.
You forgot to mention that in C++ there are destructors that are called automatically, so when used correctly (RAII) you don't need to worry about resource deallocation. Another good feature are exceptions that could make the error handling easier and more maintainable.
For myself, there is only two reasons to use C. First is if you need the code to be extremely portable (going to be used as a library in different languages and/or operating systems), and second if you need raw speed, which usually isn't a big deal as C++ typically performs only slightly slower than c (not including OO features).
I really enjoy the OO features of C++, which if used properly can make life a lot easier when developing applications.
It sounds like you favor C over C++. I do too. However, ease of use is the most important factor in programming. C++ has better string support and more libraries, so for non-trivial projects, such as database access and stuff like that, go with C++. If you are aiming to be cross platform and maybe want to work on a lower level, use C. Besides, they're both the same anyway.
C++ is better in almost every way: safer, more efficient, works better in large projects... The only exception is that you can't use it when you interface with other languages. But in that case you still use C++ and add a small C layer for the interfacing part.
C has some advantages above C++ in the early phase of a project, it's simpler, easier and requires less design decisions. However, as the project grows so do the advantages of C++ and Object Oriented Code, which are essentially: Encapsulation, Abstraction and Information Hiding. The drawback is usually slightly slower code unless you break encapsulation.
Yes, it's possible to write like C++ in C, too, but it is far more complex and a hell to maintain.
When I have a choice, I go with a subset of C++.
compatibility - not a problem, you can use extern "C" for linking with C libraries
simplicity - avoid templates, overloading operators, and other C++ feature that obfuscate code
You still get the advantages of classes and RAII.
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 7 years ago.
Improve this question
Let's say you have a company running a lot of C/C++, and you want to start planning migration to new technologies so you don't end up like COBOL companies 15 years ago.
For now, C/C++ runs more than fine and there is plenty dev on the market for it.
But you want to start thinking about it now, because given the huge running code base and the data sensitivity, you feel it can take 5-10 years to move to the next step without overloading the budget and the dev teams.
You have heard about D, starting to be quite mature, and Go, promising to be quite popular.
What would be your choice and why?
D and Go will probably just become as popular as Python and Ruby are today. They each fill a niche, and even though D was supposed to be a full-fledged replacement of C++, it probably will never acquire enough mass to push C++ away. Not to mention that they both aren't stable/mature enough, and it's unknown whether you'll have support for these languages in 10-20 years for the then-current hardware and operating systems. Considering that C/C++ is pretty much the compiled language and is used in the great majority of operating systems and native-code applications, it's very unlikely that it'll go away in the foreseeable future.
C and C++ are a pretty much unbeatable combo when it comes to native/unmanaged/"lowlevel" languages.
Not because they're the best languages, far from it, but because they're there, they do the job, and they're good enough. There's little doubt that D, for example, is better than C++ in most respects. But it fails in the most important one: Compatibility with all the existing C++ code. Without that requirement, most of that code would be written in a managed language today anyway. The only reason so many codebases use C++ today is because they used it last year, and it'd be too much of a pain to switch to something else. But if and when they switch, they typically don't switch to D. They switch to C# or Java or Python.
The problem for D and other "upcoming" languages competing for the same niches, is that while they're better, they're not groundbreaking enough to motivate people to actually switch to them.
So C and C++ are here to stay. C is unlikely to evolve much further. It is as it is, and one of the niches it has to fill is "simplicity, even for compiler writers". No other language is likely to beat it in that niche, even if they never revise the standard again.
C++ is evolving much more dramatically, with C++0x getting nearer, and they've already got a huge list of features they want to do afterwards. C++ isn't a dead end in any way.
Both languages are here to stay. Perhaps in 50 years other languages will have replaced them, but it won't happen this decade.
I currently use D regularly. I wouldn't recommend it yet for people writing production code because it's too bleeding edge. I get away with it because most of my code is research prototypes in bioinformatics. However, the language is starting to stabilize. Andrei Alexandrescu is releasing a book titled "The D Programming Language" next March, and right now there is a push to stabilize the spec for version 2 of the language in time for the book.
While D is not a formal superset of C, it is what I'd call an idiomatic superset except for the lack of a preprocessor. In other words, any code written in C proper (ignoring the preprocessor), can be trivially translated to D without a redesign, because C concepts like pointers and inline ASM are there and work the same in D as in C. D also supports direct linking to C code and the D standard library includes the entire C standard library.
Also, despite D's lack of libraries because it is still a bleeding edge language, it's a library writer's dream because of its metaprogramming capabilities. If it takes off, it will probably have some pretty impressive libs. For a preview of this, see std.range or std.algorithm in the D2 standard library (Phobos). As another example, I implemented an OpenMP-like parallelism model (parallel foreach, parallel map, parallel reduce, futures) as a pure library in D, without any special compiler support. (See http://cis.jhu.edu/~dsimcha/parallelFuture.html)
Given that you're mostly interested in the long term, I'd say give D 6 months to stabilize (given Andrei's book and the current push to stabilize the language, version 2 should be stable by then) and then take a hard look at it.
Edit: Now that the core language spec is relatively stable and the focus has turned to toolchain and library development, I would recommend D for small production projects unless you are in a very risk-averse environment. Larger projects that absolutely must have good toolchain and library support should still wait, though.
If you believe in the lean manufacturing principles, you should strive to "decide as late as possible". The moment should be the last responsible moment, meaning the moment at which failing to make a decision eliminates an important alternative.
I think this principle can be applied to your situation. Instead of committing now to a language (that you don't even know will be around in 10 years), you should keep your options open. Maybe refactor some of your code so it is a bit more generic or is built on more abstractions, so that when it is indeed required to migrate, the process will be easier.
Stick with C and C++. I don't see it going the way of COBOL, it runs as well as anything, and you'll have no problem finding people to code in C and C++.
C++ -- it is relatively young and updated... It has a big number of compiler vendors and got
improved all the time.
C -- it would live for a long time filling the gap between assembler and higher level languages. It is also very simple and easy to implement language, so it would remain the
first language for various "strange" architectures like embedded or extremely new ones.
D is promising but still very new and unstable specifications and libraries.
Go was born few weeks ago... Never use anything of version 0 for big important projects. Also it is significantly more limited the C++ or D.
2019 update: C++ will stay around for the next 10 years... (if not, I will correct this answer, when it will not be relevant any more....)
the reason companies works with COBOL today is b/c they already have millions of COBOL code written. if the could throw it - they will do it at once, on the other hand - companies work with C/C++ as part of their needs and new projects using this language b/c they can't / don't want to use java/c# any other framework based language - so COBOL is not the analogy here.
Like dsimcha said the D way is currently risky. Yet the language has a huge potential, it is low-level and i've experienced drastically better productivity with D (instead of C++). Perhaps what people feel with dynamic languages.
Go is so much blog-marketed it seems like a joke to me.
Dispatching an interface method is not trivial, and actually slower than dispatching a regular single-inheritance method.
If you'd have a huge codebase the decision is of course more difficult, I would advise only to switch for new projects, not for existing ones.
I wouldn't concentrate on a language but more on the libraries surrounding it. C++ in combination with the boost libraries are an excellent choice. People who develop in C++ tend to have a better understanding of computing, I myself started of with Java which made my life easier by hiding a lot of fundamental stuff, which is good, however I only really started to understand programming once I learned C/C++ (pointers etc).
I do recognise that C++ can be hard (e.g. memory management) so I think it's good to have a 'add on' language where performance is not essential and readability (==maintainability) scores high: I recommend Python for this.
There are countless machines running C++ software, I don't see them shutting down all at once. If C++ will go in the way of COBOL there will be a huge market for application migration. There will be specialized tools developed to translate C++ applications to the popular language of the time (Z++ ???).
So I guess the best advice is to cross that bridge when you come to it.
Check out Intel® Cilk++ Software Development Kit if you want to spark your interest in C++/Multi-Core development. I don't see C or C++ going away anytime soon either.
Comparing C* to Cobol is questionable
Comparing C* to Cobol may lead to the wrong conclusion. C was perfect for its day, a huge leap forward on its introduction, and it still gets the job done today.
I would sum up Cobol on my most charitable day with "nice try".
C and C++ will survive for a long time because they fit the bill well as implementation languages. This won't ever really change.
Also, consider that the main negative issue with C/C++ is the lack of memory safety. This tends to be less and less of a problem as codes mature. This means there will not be a serious reason to replace the old codes.
I expect that software systems will grow outwards from C. Look at the hierarchy today:
application written in a framework such as Rails
application back-end written in Ruby, PHP, Python, C#, whatever
Ruby, PHP, Python, or C# run-time implementation (written in C*)
OS kernel (written in C89)
I don't think the old layers will vanish, and I think legacy higher layers written in C and C++ will simply be supported that way for an indefinite period of time, eventually being phased out for their replacements written in Ruby, Python, C#, or a future development.
We have no idea if Go will find acceptance. Just being by Google is probably not going to be enough.
D? Well, some nice things are being said about it but it won't be taking off either. No user base to speak of. D is #20 in popularity on the TIOBE Index, and dropping fast.
You may say that a language's popularity has little to do with how well it's suited for your company's work. But it has a lot to do with how easy it will be to find people qualified to program in it.
Java is on top and I would be surprised if it went far away in the next 20 years. It's not considered a systems programming language but performs well enough that there are few tasks you'd do in C++ that you couldn't in Java. Certainly these days nobody is willing to task human programmers with the job done (flawlessly and often more effectively) by the garbage collector. I for one considered Java a significant step up from C++ in terms of programming effectivity.
I'm quite impressed by Ruby. It's an elegant, expressive language: You can accomplish a lot with not too much code, yet that code is still mostly legible. One of Ruby's main principles is to be consistent and not hold surprises for the developer. This is an extremely good idea, IMO, and boosts productivity. At the time of the big Rails hype (which may still be ongoing), I made a wide berth around Ruby because its reference implementation is abysmally slow. However, the JRuby folks at Sun have made it blazingly fast on a JVM, so now it's definitely worth some consideration. Ruby provides closures and a good handful of functional programming capabilities (see below for why this important), though it's not really considered a FP language. TIOBE index: 10 and rising.
Something to consider for the future is the fact that CPU makers have run up against a performance limit imposed by physics. No longer is there a 30% faster CPU available every Christmas, as it was in the past. So now to get more performance you need more cores. Software development will need all the help it can get in supporting multi-core concurrent programming. C++ leaves you mostly alone with this, and Java's solutions are horrible by modern standards.
In view of this, there's a certain trend toward functional programming (which eliminates much of the hassle associated with concurrency) as well as languages with better concurrency support. Erlang was written specifically for this and for the ability to swap code in a running program (Ericsson wanted incredible uptimes). Scala is similar to Java but with much stronger support for functional programming and concurrency. Clojure, ditto, but it's a Lisp and it's not even in the top 50 (yet!!).
Scala was developed academics, and shows it: It's sophisticated and downright pedantic about data types; it tries to be the Swiss Army Knife of programming languages. I believe a lot of medium-smart programmers will have trouble getting a grip on Scala. Ruby is less FP and doesn't do so much about concurrency, but it's pragmatic, and fun and easy to get stuff done in. Also, running on the JVM, there is an enormous amount of code readily available in Java libraries, which Ruby can interface with. So:
My bet would be on Ruby, with an outside chance on Scala. But there are plenty of alternatives!
Java. For most low level things Java is fine these days. Why go with a partial solution to C/C++ such as D or Go when you can have something as safe and easy to develop with as Java? If you are looking for a real time solution, D and Go are definitely not it, not to mention they are probably even less supported than Java.
Java is now a system programming language. I don't see how you can consider anything with unsafe constructs such as pointers "next gen". The only reason those insecure constructs ever existed is because it was the pragmatic approach to building a turing complete language. There was no concern of representing the memory in discrete objects, because they just wanted to build something that worked. There are already hard and soft realtime applications in Java, a variety of hardware bytecode processors, and over 2 billion mobile devices running Java. At most all you would have to do is add some constructs for interoperability with devices, which wouldn't be that much code; even in C/C++ you'd still have to add these constructs...
What are you programming? 8-bit microcontrollers with 1KB ram? In that case, it would be pointless to use anything other than the assembler for that platform...
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 9 years ago.
I ran into this supposed interview of Bjarne Stroustrup, the inventor of C++.
http://artlung.com/smorgasborg/Invention_of_Cplusplus.shtml
Stroustrup: Well, it's been long enough, now, and I believe most people have figured out for themselves that C++ is a waste of time but, I must say, it's taken them a lot longer than I thought it would...
Interviewer: Yes, but C++ is basically a sound language.
Stroustrup: You really believe that, don't you? Have you ever sat down and worked on a C++ project? Here's what happens: First, I've put in enough pitfalls to make sure that only the most trivial projects will work first time. Take operator overloading. At the end of the project, almost every module has it, usually, because guys feel they really should do it, as it was in their training course. The same operator then means something totally different in every module. Try pulling that lot together, when you have a hundred or so modules. And as for data hiding, God, I sometimes can't help laughing when I hear about the problems companies have making their modules talk to each other.
Is this a hoax? Do any of these points seem true for any of the veteran C++ programmers out there?
You just have to check the Stroustrup's website (the FAQ part) to find that it's wrong - a well known hoax as Judah Himango already pointed :
Did you really give an interview to IEEE?
in which you confessed that C++ was
deliberately created as an awful
language for writing unmaintainable
code to increase programmers'
salaries? Of course not. Read the
real IEEE interview.
It's a well-known hoax.
And no, learning C++ isn't a waste of your time, something that's been discussed on StackOverflow many times.
As mentioned, this is a well-known hoax.
But it does provoke some interesting points. These days C++ is a waste of time, except for when you can't afford to waste time. Less opaquely: C++ is a waste of development time, except for when you can't afford to waste execution time.
From the article titled "The Real Stroustrup Interview" in IEEE Computer Magazine Vol. 31 Issue 6 pp.110-114 (June 1998):
For the past few months, a hoax interview between Stroustrup and Computer has been making the rounds in cyberspace. While we regret the incident, it offers us a welcome opportunity to have the father of C++ share his insights on Standard C++ and software development in general. We can also attest to his continued sense of proportion and humor—he suggests that the fictitious interview would have been a much funnier parody had he written it himself.
As others mentioned, this Interview is hoax.
Well, I am one of the persons who hate C++ and normally doesnt use it, but learning it was definitely not a waste of time. At least now I know why I hate C++ and I understand why other persons use this language and think it is good.
If you want to learn this language to know about its concepts, its benefits and its drawbacks, to be able to read code written in it, and in general to be able to "talk about" it, it is never a waste of time. Same for any other programming language. It will increase your expierience. For example, C++ shows one common way of OOP - a way I dont like, but a way many other people use.
But if you want to learn it because "the people say that it is the best" (as I sometimes read), then it is really a waste of time. Same for any other programming language.
Programmers that feel attracted to higher level languages that take care of memory management and other tasks for them, could feel that C++ is a waste of time.
It certainly is if you can achieve the same goal with another language in less time and with less bug fixing and don't mind the downsides as efficiency.
But I don't regret having learned and spent so many hours coding in C/C++ for it's such a beautiful language and allows you to produce things that not many other languages can.
I mean, don't you want to use the language with which operating systems and compilers are written? that's not a waste of time at all from my perspective.
C++ is far from being a waste of your time. You'll understand valuable concepts that will help you understand many other concepts in different programming languages. I.E.: VTABLE.
There is not a single framework which uses all language features of C++. This introduces a huge inconsistency to the language's ecosystem.
QT is one of the few APIs which I would call a framework (or API for a lot of things):
But it defines own string, own array, ...
What's the point of a "standard" library when no one can use it in a portable and compatible way (from the aspect of interaction with other APIs)?
I know, there is boost, but what is boost compared to an API such as QT? Nothing.
Look at Java: The is the standard Java API, and every "foreign" API uses it, it's all perfectly compatible.
C++ (and Java) probably the best language to learn to understand concepts of OOP.
I remember learning it in college benefited me a lot.
Stroustrup is not that stupid to say that! It is definitely a hoax!
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. :)
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 9 years ago.
I know that C++ is a very complex language that takes many years of practice to master.
Taking that into account do you know of a small project (around a 1k of loc) that tests all of C++ major features (inheritance, pointers, memory management, etc).
The thing is I'm a Java/Python programmer and I really want to learn C++ so I've been studying C++ for a while but haven't tested anything of what I've learned beyond small exercises.
I want to take all of that knowledge and put into practice.
Doing this alone you will obtain many harmful habits. It's much better to get an internship with a company that has high competence in C++ development and train under guidance.
C++ is like a grenade without a safety pin – looks cool and you've heard that all "real professionals" use it, but you don't know when it is to explode. A tremendous amount of features that can be used for good or for evil without knowing whether it's really good or evil. That's why guidance is a must here.
A memory manager. That should get you thinking about:
free store management
pointers (of course!)
inheritance (you will want your driver code to use this)
templates (another way to pass the manager around -- driver #2)
designing user defined data structures (a memory block)
efficient use of standard container(s)
algorithms (to move around, figure out empty blocks, defragment)
Effective C++ and More Effective C++
Other than that, pick a (small?) personal project you want to write and do it in C++. You are not going to learn C++ by reading a 1000 line project.
I'm not sure about anything that tests all major features. There are a lot of them, and some are rarely used together (templates and virtual functions come to mind. Both achieve a form of polymorphism, so you often use one or the other depending on your needs.)
A suitable project in that it'd touch on all the important features might be something apparently simple like writing a correct container class, similar to std::vector or std::list. Ensure exception safety, iterator validity, the appropriate time complexity on all operations and every other requirement specified in the standard.
The problem with this, as well as most other projects, is that you won't really know when you're done. Making a resizable array might take 50 lines of code, and 20 minutes of your time. And then a beginner would think he's done. Making it exception-safe requires you to be able to spot all the places where the class might be thrown into an inconsistent state by an exception.
That's a kind of general problem with C++. It's easy enough to think you get it, and the compiler certainly won't notify you of aspects you've forgotten to handle. So you might think your code is perfect, and yet it'll crash for all sorts of odd special cases.
As sharptooth said, for a language as messy as C++, writing code on your own is risky. It is easy to fall into the trap of "I've written some code, it compiles and it seems to run. Therefore it is correct".
Of course you could post your code here or on other sites for review, or maybe just supplement your coding with reading the docs for actual high quality C++ code (most boost libraries tend to have comprehensive documentation, specifying both the rationale for various design decisions, and how it safely handles all the weird special cases that tend to crop up in C++. The C++ standard itself would be another excellent resource, of course. In either case, these might help you determine what problems to look out for)
When I was learning C++, I used it to write my own language for writing Colossal Cave style adventures. Like most computer languages it never saw the light of day, but it did teach me a lot about C++.
Whatever you choose the thing to avoid when learning C++ is GUI programming, which is a trap which will drain all your gumption and probably teach you bad C++ habits in the process.
I'd recommend creating a text based game. That really helped me firm up my C++. Doesn't take too long and you can exercise all the features you want. Come up with the game yourself. It is more fun that way.
Another great idea is to write a simple mathematics library, supporting Vectors Matrices etc.
But with todays libraries, that is only of academic use.
In order to learn C++ it is useful to look at a lot of well written C++ code.
I think the Qt library is quite nice for this so I suggest: Write an Qt application.
Look how they use C++ and create your own graphical components in a similar fashion.
Ideas:
- Stock chart viewer widget that connects to one of the financial websites and scrapes history data.
- Simple Excel like spreadsheet widget.
Depends on what area you want to work in. But nothing worth doing correctly comes in at less than 1000 lines of code.
If you are going to be writing games then try writing a Tetris clone.
If you think you will be using sockets etc then writing a simple chat/irc client would help.
Do you have a specific itch that needs to be scratched? When was the last time you thought "this sucks, I could do better?". Can you do better?
I would recomend writing a Tetris clone.
You can learn a lot of c++ concepts with this and learn a 2d library like SDL or maybe even OpenGL throgh SDL.
It is always good to have a project with visual results and at the end of it you can play it.
There seem to be two themes coming from the answers:
You need to pick a project that might involve more than 1K LOC in order to get the true experience of the project.
You need to also pair up with an experienced C++ developer, who can help you think through problems and avoid pitfalls associated with the language.
You can get around both of these by swing by sourceforge.net and signing up to help with an existing C++ project. As long as you don't mind your code being open source, you should be able to find an existing project to learn from plus experienced developers who can help by reviewing your code and offering guidance.
An interactive world:
A matrix where each position can be a Void or a Being.
A Being is something with a few attributes: age, Time left, gender, neigbor connections, etc. Capable a few interactions: fights, having sex and kids, friendships, etc. Some have special Skills, depending on their fathers (inherited trades)... like ability to kill, ability to make food,, etc...
Possible outcomes of those interactions and skills are changes on the self attributes, or creating offspring (when possible), or change neigbor attributes.
At each iteration, print the matrix as symbols/numbers on the console (depending on the attributes, etc), starting from a Biblical iteration 0 (initial conditions of your choice... you're God here).
Now you got some real-life pattern simulator, and learned something about inheritance, polimorfism, virtual functions, instantiation of classes, etc.
I would suggest a simple text editor would be a reasonable goal.
It's a problem domain that you have a good grasp of.
You have memory management issues, library class reuse issues (stl/curses?), pointer issues, and lots of options where derived classes can be used.
For polymorphism, perhaps, you can have the editor read from a keyboard, or suck commands in from a text file.
There is another good one.... dealing with files.
You don't have to cross platform it. You don't have to open source it. You don't have to show it to anyone. You don't even have to finish it. It can be an exercise just for you.
If you're learning fron a book, it must have plenty of well-thought-out exercises you can implement and learn from. Also check out the university sites and their C++ labs / assignments.