It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
What does C++ add to C?
What features of the language are the Clang/LLVM projects, the parts of GCC that are being written in C++, chromium, and any others all taking advantage of? What features are they avoiding?
Like all sophisticated and powerful things there is a price to be paid to succeed in C++.
You have to be incredibly careful with memory management.
Multi-paradigm capability means you have to be really good at design to avoid making a mess.
Extreme performance requires careful planning and selection of features used.
The ability to circumvent most every language policy requires monumental self discipline.
So if you're sloppy with memory, poor at design, don't need fast programs, or have no self discipline, then please don't learn C++. There is always Java or C#.
meta programming? templates?
like with C you get performance, but the code looks horrible.
with the high level languages you get nice code but there is less flexibility to make the fastest possible code.
with c++ you can do both? you can freely make anything as fast as it could be made in C, but native object orientation, and templates/operator overloading ect makes it so you can write fairly nice looking code too. indeed, you can make it so it is neat and fast.
I have never really found it more of a pain to write stuff in c++ than in a higher level language. the trick is having good libraries.
Because despite academic efforts such as Singularity, there's not a single mainstream OS where drivers can be written in a high-level language.
Note that anything that can be done in C++ can also be done in C, but some things are a lot easier in C++.
Not? I would say it's not worth if you performance is not an issue for you. (Follow the double negatives.)
My two cents:
Although I don't program in Python, I would have to say that Python is probably the best programming language for getting real work done. It's an elegant language, and it has an enormous collection of libraries for doing various things. However, my experience as a user has shown me over and over again that Python is slow (take yum, for example).
I do know Haskell pretty well, and I have to say that it's a friggin' awesome language. Better yet, it is compiled, and its speed is competitive with Java and C++ (though you have to put forth extra effort to get this speed in some cases). However, libraries for things like database access don't always match the elegance of Haskell's base libraries (I'm probably way wrong about this), and they're harder to install on Ubuntu. In my opinion, that's why it's more challenging to get real work done in Haskell than in Python.
Ruby's good for web applications. Other than that, it's slow (though I speculate jRuby or something might be faster).
C++ is far from elegant, and in many cases, elegance is frowned apon. Anyone ever told you to use static_cast instead of C-style casting? Anyone ever told you not to use namespace std;? C++ has a lot of features, but doesn't tend to have many important language features (such as closures, which are formally proven to be the best thing since sliced bread).
Why do people use C++, then? Well, it's performance-focused, making it a good choice when you need speed. It has classes, namespaces, and templates, so it's a good choice when you want better code organization, but still need to use "C" for some reason. Also, it has the Boost library, which I've heard is really good for getting work done.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I'm not really convinced about how C/C++ performs under certain circumstances, especially when it comes to keeping the approach to the math world simple and efficient, I don't know how to explain this since i have skilled my self on only other 2 languages: Python and Java ( and other languages for the www world like html, js, php, etc etc ... ) and they are all really different from C++ because the way they are designed.
What I don't like it's probably a mix between syntax and performances, for example C++ doesn't offer a support for matrices or vectors natively, all boils down to doubles and floats and you need to always keep an eye on what you are presuming you are doing because of the binary arithmetic that sometimes can give you unexpected results, and since your matrix it's not a primitive type it's treated like any other custom class without any particular optimization on the math, even if it's "math" and sometimes it can be optimized.
I will probably repeat myself but since C++ it's the only compiled languages that i know, that is right for some kind of performances, I can't really compare what it's offering to something else, but some aspects of the C++ world are cumbersome and not really shaped in a way that they can fit my needs, it's probably the best language to build an engine and the biggest part of my application, but i would appreciate some suggestions about what language can be the perfect companion in a 3D application and basically, an application with a lot of math.
I am not convinced about your line of thought.
About the math part: Doing it with native C++ is cumbersome, I believe that. However, there are many libraries available that help you do your maths in a way that is efficient both in development and runtime performance.
For example, have a look at the Eigen library. Eigen heavily uses templates and compiler optimization to get the most out of your maths. I have yet to find great optimization potential (well, you can always get a bit by using processor specific optimization such as BLAS, but that could be done using Eigen as well).
I'm no expert on the 3D-part, though.
No language offers all features that you might ever need on it's own. That is what libraries are for. You should be able to find a suitable library for most problems you will encounter in C++.
About the syntactic difficulties: I do not know how far you have dug into C++. I learn something new every day - things that used to take me 10 lines of code when I started learning now can be done in one - without loosing performance or readability, on the contrary, usually gaining more clarity of the code. Thus: It is all about experience.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I've been programming C++ and Java for quite a while now and have some questions about common C++ architecure.
When I program in Java I try to mimic the standard library, that is using interfaces such as Iterable and Serializable and having similar naming conventions and functionality. With C++ however, I hesitate when trying to mimic the STL conventions (with the exception of iterators).
I've boiled it down to the following questions (are the following common convention to implement):
Allocators
Interfaces (classes with only pure virtual methods)
Templates instead of abstract base classes
Restricting exception throwing...
... or having a class optionally throw exceptions (such as in std streams)
Using typedefs for, more or less, obvious types (reference_type, pointer_type, value_type, ...)
Or is the std of C++ not worth mimicing at all?
Thank you for your opinions / answeres!
The more I've used C++, the less fond I am of mimicking the best of libraries I find. The problem comes in when we get a junior developer on the team. They'll understand the basics, but not the subtleties of the language. They may know how to create a map or list using the template syntax, but be unable to understand it when it's applied to another object. The added complexities of debugging and doing code read-throughs also take valuable time away from solving problems or advancing your product.
I have grown to lean towards using the most basic features of the language, which typically leaves the code in a more naturally readable state. I've regretted deviations from this path when I go back 8-12 months later to hunt down an obscure bug with the code.
Java, on the other hand, has more simplistic library implementations that is very well understood by more junior Java developers. I do find that junior Java developers tend to have a greater understanding of the language then junior C++ developers. The being said, C++ developers have more opportunity to become truly competent owing to the lower level of thought needed to become an intermediate C++ programmer.
It greatly depends on your project. The general advice seems to be: Don't bother having a concrete standard for C++.
E.g. with typedefs there are multiple opinions both "for" and "against".
The reason why a concrete coding style for C++ is less important in C++ is because the language does not provide the ways to enforce and check those styles.
I.e. the grammar isn't easily parsable and therefore there are pretty much no tools to meaningfully style-check / refactor C++ code.
Which means that the weight of the style-check falls on the programmer's shoulders. I.e. it makes less sense to enfore style guides, because then much of the time saved by them is wasted in manual style checks.
So just use whatever your project / company uses or decides to use.
Here are my personal preferences:
Allocators: No opinion. If you need a custom allocator, chances are you'll know better than me what to do with it.
Interfaces: If you're doing any performance-sensitive work - don't. They make things noticeably slower in a realtime application. Both abstract virtual classes and the pImpl pattern.
Templates instead of abstract base classes: It depends. But the general opinion seems to be that templates should be used for container-like functionality and a few other simple cases. Otherwise, it's a decent pattern. Debugging these is still a serious pain and will be in the next few years.
Restricting exception throwing: Yeah, do that. Try not to use exceptions, because believe it or not, in 2012 they are still not universally supported.
Using typedefs:: Just try to use c++11's std::auto. Otherwise, they kind of make your life harder because they're halfway to #define macros. I'd personally use an IDE (or Vim) to ease the typing stress of longs names and write the long names.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I'm starting C++ programming in my first job. I'm a CS student and I have learn programming in Java. What advice would you tell me to watch out so I don't cause trouble in my new job?
Would you have any advice or references would be appreciated.
(example: I know C++ is more likely to have memory problem than Java)
Thank you very much!
Maybe you already know this, but one common mistake for folks used to Java and learning C++:
Don't use new unless you have to (and you probably don't really have to). In most cases where you want to create an object, you should just create it "on the stack", like ClassType obj;.
Two things:
Get yourself a copy of Effective C++ by Scott Meyers.
Lint your code. This will not only catch potential bugs early in the development process, but also teach you good coding habits (e.g. declaring a method's input arguments as const references). I use PC-Lint for this.
For me, the biggest difference between Java and C++ is pointers, so I would try to get pointers down. Just my opinion.
No two ways about it. You're going to be a menace until you've been bit enough by C++ gotchas to hate the language. I'd recommend trying to write functions and not classes. A lot of people think OOP is great, but really most users want your code to "do" something, not "be" something. Anyways, good luck. :-)
Definitely what Chance said. Memory management is explicit in C++. I had an excellent textbook in college called Deitel C++. It's a C++ Bible.
I would also learn up on the Standard Template Library and Boost.
This might give you some ideas.
Some important excerpts :
Researchers (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, telegraph operation, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again.
And here is how to do :
Get interested in programming, and do some because it is fun. Make
sure that it keeps being enough fun so that you will be willing to
put in your ten years/10,000 hours.
Program. The best kind of learning is learning by doing. To put it
more technically, "the maximal level of performance for individuals
in a given domain is not attained automatically as a function of
extended experience, but the level of performance can be increased
even by highly experienced individuals as a result of deliberate
efforts to improve." (p. 366) and "the most effective learning
requires a well-defined task with an appropriate difficulty level for
the particular individual, informative feedback, and opportunities
for repetition and corrections of errors." (p. 20-21) The book
Cognition in Practice: Mind, Mathematics, and Culture in Everyday
Life is an interesting reference for this viewpoint.
Talk with other programmers; read other programs. This is more
important than any book or training course.
If you want, put in four years at a college (or more at a graduate
school). This will give you access to some jobs that require
credentials, and it will give you a deeper understanding of the
field, but if you don't enjoy school, you can (with some dedication)
get similar experience on your own or on the job. In any case, book
learning alone won't be enough. "Computer science education cannot
make anybody an expert programmer any more than studying brushes and
pigment can make somebody an expert painter" says Eric Raymond,
author of The New Hacker's Dictionary. One of the best programmers I
ever hired had only a High School degree; he's produced a lot of
great software, has his own news group, and made enough in stock
options to buy his own nightclub.
Work on projects with other programmers. Be the best programmer on
some projects; be the worst on some others. When you're the best, you
get to test your abilities to lead a project, and to inspire others
with your vision. When you're the worst, you learn what the masters
do, and you learn what they don't like to do (because they make you
do it for them).
Work on projects after other programmers. Understand a program
written by someone else. See what it takes to understand and fix it
when the original programmers are not around. Think about how to
design your programs to make it easier for those who will maintain
them after you.
Learn at least a half dozen programming languages. Include one
language that supports class abstractions (like Java or C++), one
that supports functional abstraction (like Lisp or ML), one that
supports syntactic abstraction (like Lisp), one that supports
declarative specifications (like Prolog or C++ templates), one that
supports coroutines (like Icon or Scheme), and one that supports
parallelism (like Sisal).
Remember that there is a "computer" in "computer science". Know how
long it takes your computer to execute an instruction, fetch a word
from memory (with and without a cache miss), read consecutive words
from disk, and seek to a new location on disk. (Answers here.)
Get involved in a language standardization effort. It could be the
ANSI C++ committee, or it could be deciding if your local coding
style will have 2 or 4 space indentation levels. Either way, you
learn about what other people like in a language, how deeply they
feel so, and perhaps even a little about why they feel so.
Have the good sense to get off the language standardization effort as
quickly as possible.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I've barely/rarely used C++ in the past decade, and now it looks like I'll be doing something in it again. I'm looking forward to it, but have to wonder how it's changed since I last used it.
Are there any good / brief web pages, blog posts, or even books on how C++ has changed in the past decade?
Please note this question is regarding the language as well as tools or any additional information about working in C++. Specifically I'm working in Windows, using VC++2008.
While the official standard hasn't changed much over the past decade or so, there are several things of importance that have happened:
while it's not an official standard yet, an upcoming new standard (commonly called C++0x) is 'around the corner'. GCC and MSVC 2010 have incorporated significant parts of that new standard, but I'm not sure how much is in common use.
the Boost library has become a major player in providing additional support for the language - to the point that it was a significant influence on the new standard
'template-based' programming techniques have become much more prevalent, probably overtaking the older 'inheritence-based' techniques of code reuse (this might have been well underway when you last looked at C++ depending on the practives your shop may have been using at the time).
compilers (and in particular Microsoft's) have come a long way in standards compliance
The biggest change is that C++ standard actually works in all major compilers now. Things like member templates used to be iffy.
The language itself has not changed much. However, the best practices and idioms did a lot.
I suggest you take a look at the book "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" by Herb Sutter and Andrei Alexandrescu to see how modern C++ looks like today.
I think one of the biggest changes is one of mindset: many people have (finally!) realised that templates are incredibly powerful and don't need to be slow, and use of the STL and boost is much more widespread than 10 years ago.
VS2008 comes with TR1, a large addition to std that contains things like static arrays, reference counting pointers, and suchlike. Apart from that, the biggest change is just that the compiler compiles how the Standard defines.
An interesting question as I'm coming up to my 10th anniversary of programming C++ for coins.
My personal view is that I'd be somewhat wary -- but only somewhat -- since I haven't seen it all (though I think I can guess what it's like) -- of paying strong attention to the internet echo chamber. It's true, some people have gone full bore for the modern style of C++, with everything fully template'd up and using modern techniques to get the compiler doing its Prolog thing to best effect. However this is certainly not universally true, and, in the main, the C++ code I see today is very similar in most ways to the C++ code I saw ten years ago.
It would be a good idea to brush up on modern fashions, because some stuff that was somewhat rare ten years ago (smart pointers, regular use of RAII, standard library containers and stuff) is now more common. But unless you are sure that the code you will be working with is festooned with templates and boost and so on, you stand a good chance of working with something that's at heart very much like what you used to work with.
It may be unfashionable to say it, but that doesn't make it any less true: regardless of skill level, lots of people don't care for modern C++. Some, because they don't understand it. Some, because they do understand it. And for some, perhaps "care" isn't even the right word -- they don't even know it exists. And as you might expect these people all code accordingly.
Perhaps I move in the wrong circles, but my experience has been people who don't or can't or won't code in the modern style outnumber those that might do by some vast margin. And those who might do, generally don't, because they're outnumbered. Their code gets rewritten, or ignored, until they start writing stuff that other people can understand. So maybe this is good, or maybe this is bad -- it's hardly relevant, in my view, because the outcome is the same: that if your experience turns out to be anything like mine, you have a good chance of encountering today code that's remarkably similar to what you would have seen in 1999.
P.S. Nicolai Josuttis has written a couple of books that my last employer's resident template expert seemed to like. Also try Modern C++ Design (Alexandrescu) -- probably a bit dated now, but it explains many of the principles. Herb Sutter's Exceptional C++ gives, as I recall from a skim of a work copy, a good overview of some modern techniques without going too nuts on the template front. And of course boost demonstrates all this sort of thing (and much, much more -- then some bonus material) put into practice over a range of compilers.
(Hopefully the above list is not too dated; as my answer might suggest, I have found much less of a need to keep up to date with the latest trends in C++ than I would ever have expected.)
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,