Why You Should Know C++(unknownprogrammer.com)
unknownprogrammer.com
Why You Should Know C++
http://www.unknownprogrammer.com/2009/10-reasons-you-should-know-cpp/
62 comments
I'd phrase the C / C++ rift a little more carefully --
To do low-level C++ you'll have to learn low-level C anyway and learning C in and out is a far easier endeavor than learning C++ in and out. So if you're wanting to dip into low-level stuff, you need to learn at least C and may want to learn C++ as well.
(More generally the above does not hold -- the way you approach and solve problems in C and C++ does vary a good deal in higher-level stuff, but if you're doing bit-wrangling, you do tend to end up with something that approximates C bunched into classes.)
To do low-level C++ you'll have to learn low-level C anyway and learning C in and out is a far easier endeavor than learning C++ in and out. So if you're wanting to dip into low-level stuff, you need to learn at least C and may want to learn C++ as well.
(More generally the above does not hold -- the way you approach and solve problems in C and C++ does vary a good deal in higher-level stuff, but if you're doing bit-wrangling, you do tend to end up with something that approximates C bunched into classes.)
What's the point of using C when most modern programs on modern operating systems are written using frameworks that are a form of objectified C?
All serious development frameworks nowadays for desktop applications are either C++ or Objective C. Most native libraries are one of the two. Even the driver SDKs are mostly build on an object oriented approach.
And learning C++, you will know C. Your opinion is a popular opinion among web developers and people who do not do desktop development, but in the real world, it has a lot more advantages to learn C++ instead of C.
All serious development frameworks nowadays for desktop applications are either C++ or Objective C. Most native libraries are one of the two. Even the driver SDKs are mostly build on an object oriented approach.
And learning C++, you will know C. Your opinion is a popular opinion among web developers and people who do not do desktop development, but in the real world, it has a lot more advantages to learn C++ instead of C.
C is the lingua franca of computer languages. You can create bindings for almost any language if you have a c library. A lot of system libraries are in fact C, not C++: think of stuff like zlib, curl, openssl, libxml, iconv..
Sure, if you know C++ well, you'll be able to do C, but learning C++ is that much harder than C, that it's often not worth the effort. You'll be able to interface with most libraries once you know C, even if you use any other language as your primary tool. Learning C++ won't give you that much extra.
Sure, if you know C++ well, you'll be able to do C, but learning C++ is that much harder than C, that it's often not worth the effort. You'll be able to interface with most libraries once you know C, even if you use any other language as your primary tool. Learning C++ won't give you that much extra.
Learning C++ is not much harder than learning C. The difficulty in both languages lies in pointer manipulation and understanding the system below, it does not lie in using classes or templates. If you are a web developer who wants to interface with libraries then your approach is right, but if you are trying to develop a complete piece of software, then what you are saying is just wrong.
You seem to be locked down by a particular perspective on software development, and this is unfortunate.
You seem to be locked down by a particular perspective on software development, and this is unfortunate.
The difficulty in both languages lies in pointer manipulation and understanding the system below, it does not lie in using classes or templates.
That's utterly untrue. The low-level details of C++ are mostly the same as C's, unless you want to write a shared library in C++ and thus need to extern the C++ symbols, or need to worry about the details of the object-system implementation like vtables, or need to mess with streams and layer them over some communication medium.
What makes C++ fucking hard is the syntax explosion that feels like cleaning up a New Year's Eve confetti with your bare sweaty hands, the template voodoo, and the design patterns that they have tacked on the language to make it more palatable to Satan.
To make it worse, the language is both broad and deep. You can't learn C++ by reading the standard. You have to dip into the culture of one of the big vendors, or schools of programming, to find out what subset of the language is to your liking. Are you writing Bjarne's C++ or GoF's or Alexandrescu's? or perhaps you would prefer to old HP/STL/Meyer C++ to the new kitchen-sink BOOST C++?
Contrast this to Common Lisp, which is a very broad but relatively shallow language; you can read the first few sections of every chapter of the manual and come off a good Lisper, go back and dig deeper and you only get better. OO, functional and procedural Lisp looks relatively the same. If you don't understand a construct, you look up the documentation of the symbol, see its evaluation model and presto. C++? You don't see what's being implemented because higher-level designs are being kludged and modeled with dickish, brittle and contrived tools -- they have no way out of this, as the language insists on C pseudo-similarity and refuses to adopt any kind of clean macro system; they're running out of syntax and CPP is unforgiving. Understanding C++ code then becomes a matter of psychological profiling of the author and even scholarly exegesis and deconstruction ("What did he intend to say?", etc.) requiring a level of empathy hard to muster when you're, in fact, wishing ill and misfortune on the bastard who forced you to look at this mess.
That's utterly untrue. The low-level details of C++ are mostly the same as C's, unless you want to write a shared library in C++ and thus need to extern the C++ symbols, or need to worry about the details of the object-system implementation like vtables, or need to mess with streams and layer them over some communication medium.
What makes C++ fucking hard is the syntax explosion that feels like cleaning up a New Year's Eve confetti with your bare sweaty hands, the template voodoo, and the design patterns that they have tacked on the language to make it more palatable to Satan.
To make it worse, the language is both broad and deep. You can't learn C++ by reading the standard. You have to dip into the culture of one of the big vendors, or schools of programming, to find out what subset of the language is to your liking. Are you writing Bjarne's C++ or GoF's or Alexandrescu's? or perhaps you would prefer to old HP/STL/Meyer C++ to the new kitchen-sink BOOST C++?
Contrast this to Common Lisp, which is a very broad but relatively shallow language; you can read the first few sections of every chapter of the manual and come off a good Lisper, go back and dig deeper and you only get better. OO, functional and procedural Lisp looks relatively the same. If you don't understand a construct, you look up the documentation of the symbol, see its evaluation model and presto. C++? You don't see what's being implemented because higher-level designs are being kludged and modeled with dickish, brittle and contrived tools -- they have no way out of this, as the language insists on C pseudo-similarity and refuses to adopt any kind of clean macro system; they're running out of syntax and CPP is unforgiving. Understanding C++ code then becomes a matter of psychological profiling of the author and even scholarly exegesis and deconstruction ("What did he intend to say?", etc.) requiring a level of empathy hard to muster when you're, in fact, wishing ill and misfortune on the bastard who forced you to look at this mess.
If I were to extend C by adding python style classes on top of it, I would end up with roughly the same number of keywords. I don't think it's true that C++ has a lot of new concepts in the language itself.
I agree that C++ is very library oriented, and it changes your approach to the language, but this is not a fault of the language itself, this is a side-effect of its very wide popularity.
If you have a pattern used by a library, then that is the fault of the library, but not a fault of the language. The language does not come with any patterns.
Templates in C++ are not good, but they are not widely used in the real world. Most people ignore them, and that's good so.
I agree that C++ is very library oriented, and it changes your approach to the language, but this is not a fault of the language itself, this is a side-effect of its very wide popularity.
If you have a pattern used by a library, then that is the fault of the library, but not a fault of the language. The language does not come with any patterns.
Templates in C++ are not good, but they are not widely used in the real world. Most people ignore them, and that's good so.
"Templates are not used"? Do you mean that you code C++ without the standard library?
The STL is optional. Templates are widely used in container formats, but in real world programming, for example when people model shopping carts or so, most of the code out there does not use templates. Let's get real here and look at a code repository like codeproject or codeguru - those sites hold diverse examples of real world code - and template usage is minimal.
Templates in C++ are not good, but they are not widely used in the real world.
Depends on where your "real world" is. C++ usages are vendor and library dependent. My C++ code looked different in MFC/COM/ATL than in FLTK and that too was different than Qt. Choosing the right C++ becomes a matter of choosing the right vendor, and if that choice isn't up to you, well, tough luck.
Depends on where your "real world" is. C++ usages are vendor and library dependent. My C++ code looked different in MFC/COM/ATL than in FLTK and that too was different than Qt. Choosing the right C++ becomes a matter of choosing the right vendor, and if that choice isn't up to you, well, tough luck.
If I were to extend C by adding python style classes on top of it, I would end up with roughly the same number of keywords.
You can use Objective-C as a datapoint here. That's Smalltalk on top of C. You can use the same sort of trick (delimiting the dynamic sends) to recycle the C keywords in the dynamic context, and end up with a language with just a few more keywords than C.
You can use Objective-C as a datapoint here. That's Smalltalk on top of C. You can use the same sort of trick (delimiting the dynamic sends) to recycle the C keywords in the dynamic context, and end up with a language with just a few more keywords than C.
Learning C++ you will not know C. At least, not in the time it could have taken you to learn C by itself. There are a few core differences, and with C++ you'll spend a lot of time learning things that will distract you from the core language. If you want to learn C and understand it's advantages don't assume you'll pick up what you need by learning C++.
Yes you will. It's better to learn C++ straight up, because the things you learn there will help you become a better modern developer compared to just C. The core differences between C and C++ (apart from the entire object oriented thing) are easy for any competent developer to pick up. Were they difficult for you to understand?
The stylistic differences are wide. Learning to for instance do C style APIs using opaque types, extended macro-fu, broader use of function pointers, etc. are the sorts of non-obvious things that good C developers do that you'll mostly miss working just on C++ code-bases.
I don't think that non-obvious and "good developers" should be joined together in one sentence. It's possible to do a lot of macro magic, it's possible to do a lot of function manipulation, but this is not good development. This is efficient development when you are working with projects or systems that require that sort of thing (maybe large dataset manipulation or embedded systems), but in my opinion, doing those things is bad programming.
The reason is simple: They are difficult to understand. Code is communication, and there are two listeners - and when you are pushing function pointers around using macros, the human is going to have huge problems understanding what you are trying to achieve.
So I don't think exploiting particular features of a language to extreme levels when it is unneccesary makes you a good programmer in that language - I actually think it makes you worse.
It's like writing a book - you have a certain vocabulary at your disposal, and you can say almost anything you want with that vocabulary. There are different levels of obscurity in the words you use you can reach - you gain in expressiveness, but you narrow your audience. When you write a book for molecular biologists, then the particular terms you use should not be the same as when you write a biology textbook.
That's why I think that one can be a good C programmer without going much deeper than the C subset commonly used in C++.
This is part of my general philosophy in programming - clarity, simplicity and structure first, efficiency second. The machines will catch sooner or later, anyways.
The reason is simple: They are difficult to understand. Code is communication, and there are two listeners - and when you are pushing function pointers around using macros, the human is going to have huge problems understanding what you are trying to achieve.
So I don't think exploiting particular features of a language to extreme levels when it is unneccesary makes you a good programmer in that language - I actually think it makes you worse.
It's like writing a book - you have a certain vocabulary at your disposal, and you can say almost anything you want with that vocabulary. There are different levels of obscurity in the words you use you can reach - you gain in expressiveness, but you narrow your audience. When you write a book for molecular biologists, then the particular terms you use should not be the same as when you write a biology textbook.
That's why I think that one can be a good C programmer without going much deeper than the C subset commonly used in C++.
This is part of my general philosophy in programming - clarity, simplicity and structure first, efficiency second. The machines will catch sooner or later, anyways.
It's not that those features aren't exposed in C++, it's that C++ has different (more modern) mechanisms for doing the same thing.
C++ has templates, so you don't need to do as much with macros. C++ has virtual functions and overloaded operators (allowing for functors), so you don't need to do as much with function pointers. Structures can have methods in C++, so the way that you'd set up an opaque type is quite different in C++.
C++ also has about 10000 other features as well though, which is what makes it unwieldy to learn. The patterns mentioned above aren't about efficiency; they're about encapsulation.
Just to give an example -- in C++ if you want to set up a callback, for example with an observer pattern, you'd use a pure virtual function (and then pass in a concrete instance of that class) or a functor. You can't do that in C, so you use a function pointer. You learn to work with function pointers more because they're a necessary part of designing C APIs, whereas they're not in C++.
(Note that it's the language I'm best at, followed by C, so this isn't random C++ hating.)
C++ has templates, so you don't need to do as much with macros. C++ has virtual functions and overloaded operators (allowing for functors), so you don't need to do as much with function pointers. Structures can have methods in C++, so the way that you'd set up an opaque type is quite different in C++.
C++ also has about 10000 other features as well though, which is what makes it unwieldy to learn. The patterns mentioned above aren't about efficiency; they're about encapsulation.
Just to give an example -- in C++ if you want to set up a callback, for example with an observer pattern, you'd use a pure virtual function (and then pass in a concrete instance of that class) or a functor. You can't do that in C, so you use a function pointer. You learn to work with function pointers more because they're a necessary part of designing C APIs, whereas they're not in C++.
(Note that it's the language I'm best at, followed by C, so this isn't random C++ hating.)
It's not about knowing the core differences, it's that the actual practice of writing a lot of C makes one familiar with its advantages. It's difficult to appreciate the value of C's small size if you are only coding in C++. Without doing a lot of coding in straight C, it'll be a lot harder to understand and recognize the various tricks and techniques other C programmers use to make the most of the small language.
I'm not saying there are no good reasons to learn C++. Just don't think that you'll really appreciate C until you've actually used it all by itself (with maybe a few C++isms here and there like //comments).
I'm not saying there are no good reasons to learn C++. Just don't think that you'll really appreciate C until you've actually used it all by itself (with maybe a few C++isms here and there like //comments).
Windows API is pure C. GTK is pure C. And these are quite serious (and not exactly obscure) development frameworks.
Have you subclassed any GObjects lately? Or otherwise implemented custom GTK widgets? If so, you might know why GTKmm exists (nevermind that PyGTK, GTK# etc are arguably the intended ways to use GTK.) There is a good reason everyone in the Linux world screamed with glee when Nokia LGPLed Qt, and C++ (even the basic stuff) is a big part of that reason.
No qt is the reason. qt is well designed and thought, contrary to gtk. And it's not because qt was written in C++.
I'll second that. Qt is a beautiful toolkit. It's just enough C++ to be useful, and avoids all the templates and obnoxious flotsam that makes that language such a horror. Signals and slots work great, and other tools (qmake for example) are a pleasure to use.
And, uh ... POSIX. The weapon of choice for UNIX black-belts.
The Windows API is an array of functions that can be called the same from C as from C++. Microsoft provides several object oriented wrappers for this API, and it's very rare that any significantly large application is not calling the API over some kind of wrapper.
No, I think it's C. It's written in C and was (at least initially) designed to be called from C code. I think #ifdef __cplusplus followed by extern "C" doesn't make a C API C/C++. Also the fact that there are several Microsoft and third-party wrappers out there doesn't make it any less C, at least in my opinion.
I did not say it's C++. It's C, but it's rare that it's used directly as C.
Yes but the C++ based MFC wrappers for Win32 make Windows development much easier.
The points a useless. "Knowing C++ you will not be immediately seen as a hacker, but the inverse applies here."
Learn it if you are curious, but don't learn it just to get a job.
If you take those points one by one, none of them is a reason to switch to C++. But for some kind of larger projects where efficiency is important, C++ is still one of the best choices.
I went from C++ to C# and wouldn't want to go back, but C++ is still a strong and lively language with many active projects and a good future. If I would be forced to implement something outside the .net framework, I would not hesitate to pick it up again.
I went from C++ to C# and wouldn't want to go back, but C++ is still a strong and lively language with many active projects and a good future. If I would be forced to implement something outside the .net framework, I would not hesitate to pick it up again.
I'll go for a point-by-point critique.
Point 1 tacitly assumes that learning C++ not only teaches you a common subset of many other popular languages, but also is the easiest way to learn said subset. This is wrong: a lot of simpler languages can teach you the same, e.g. JavaScript or pre-1.5 Java.
Point 3 says a given code sample in the wild has higher probability of being in C++ than any other language. This clashes with my impressions.
Point 4 assumes that the main difficulty of C++ is due to pointers and manual memory management, and that knowing your way around those issues will help you in other programming areas anyway. This sounds wrong to me: C shares those "difficulties" with C++ and isn't generally regarded as a hard language. The difficulty of C++ mostly stems from design decisions unique to C++ and useless elsewhere, like template metaprogramming or the dangerous combination of manual memory management with exception handling.
Point 5 implies that C++ invented parametric polymorphism and that this facility is essential to make algorithms work on a variety of data types. Wrong on both counts: ML and Ada generics predate C++, and Smalltalk-like dynamically typed languages solve the same problem without type parameterization.
Point 6 assumes more libraries have C++ interfaces than C interfaces, which is wrong by an order of magnitude at least.
Point 9 assumes most programmers are more interested in performance-oriented and algorithmically complex projects. Can't give statistics here, but I'm a data point to the contrary: I love UI and frontend work.
Point 10 is valid.
My own reasons for knowing C++ are a combination of point 10 and the need to muck around with http://mapnik.org - the only C++ library I ever found useful. And its code sucks, I'd kill for a C/Python alternative.
Point 1 tacitly assumes that learning C++ not only teaches you a common subset of many other popular languages, but also is the easiest way to learn said subset. This is wrong: a lot of simpler languages can teach you the same, e.g. JavaScript or pre-1.5 Java.
Point 3 says a given code sample in the wild has higher probability of being in C++ than any other language. This clashes with my impressions.
Point 4 assumes that the main difficulty of C++ is due to pointers and manual memory management, and that knowing your way around those issues will help you in other programming areas anyway. This sounds wrong to me: C shares those "difficulties" with C++ and isn't generally regarded as a hard language. The difficulty of C++ mostly stems from design decisions unique to C++ and useless elsewhere, like template metaprogramming or the dangerous combination of manual memory management with exception handling.
Point 5 implies that C++ invented parametric polymorphism and that this facility is essential to make algorithms work on a variety of data types. Wrong on both counts: ML and Ada generics predate C++, and Smalltalk-like dynamically typed languages solve the same problem without type parameterization.
Point 6 assumes more libraries have C++ interfaces than C interfaces, which is wrong by an order of magnitude at least.
Point 9 assumes most programmers are more interested in performance-oriented and algorithmically complex projects. Can't give statistics here, but I'm a data point to the contrary: I love UI and frontend work.
Point 10 is valid.
My own reasons for knowing C++ are a combination of point 10 and the need to muck around with http://mapnik.org - the only C++ library I ever found useful. And its code sucks, I'd kill for a C/Python alternative.
My reason not to learn C++: There are so many things one should know, that it is not rational to learn all the arcane details of C++. Every decision to learn something is an implicit decision not learn everything else.
If you know any other object-oriented language, it's easy to make the case that you should learn C and skip C++.
No discussion of C++ should go without mentioning the C++ FQA (Frequently Questioned Answers). It carefully explains every single thing wrong with the language, and there's a LOT to explain.
http://yosefk.com/c++fqa/
Skip to http://yosefk.com/c++fqa/defective.html for a great overview. And if anyone ever mentions "templates" again I'm gonna smack them hard.
http://yosefk.com/c++fqa/
Skip to http://yosefk.com/c++fqa/defective.html for a great overview. And if anyone ever mentions "templates" again I'm gonna smack them hard.
3. Code samples in books are more likely to be in Java or Python than C++.
6. Libraries are more likely to have native C bindings than native C++ bindings.
6. Libraries are more likely to have native C bindings than native C++ bindings.
I agree, most of the points seem to apply more on C than on C++.
Also this:
and this:
Also this:
10. You will hardly be seen as a hacker if you don’t know C++
and this:
8. There will always (or, at least, for a very long time) be a niche for C++
Just keep in mind that making a career out of maintaining other peoples' C++ legacy code is a highly optimized way to become the bitterest person in the world.
[deleted]
Life is too short for c++. That's what I always say (even at job interviews..)
There are indeed so many things to learn, but as a developer or someone who would be in the development world (be it building tech startups, developing software, etc) there is a must-know set of tools. C/C++ happens to be very high on the list. And learning more really doesn't hurt.
Not just C++, but also learn C, Java, Perl, Python, Erlang, Lisp, PHP, Shell Scripting, Assembly, Ruby, along with their most used libraries/frameworks. The more diversify your skillets, the better you can use the right tool for the moment, improving performance of that, lower development time. (Eg. A spoon can be used to build a house, but it's hardly the best tool out there).
This way, want to hack up a quick content management or low computational front end system, whip out your php/python/ruby with your favourite framework out. Got a bottleneck at high cpu or memory bound place, rewrite that piece in C/C++. Need to deploy a cross platform app really quickly, Java. Want to bind or write a test for a bunch of tools, use Python or Perl. The list goes on.
Summary: Learn More, use the right tool, do less, get more accomplished.
Not just C++, but also learn C, Java, Perl, Python, Erlang, Lisp, PHP, Shell Scripting, Assembly, Ruby, along with their most used libraries/frameworks. The more diversify your skillets, the better you can use the right tool for the moment, improving performance of that, lower development time. (Eg. A spoon can be used to build a house, but it's hardly the best tool out there).
This way, want to hack up a quick content management or low computational front end system, whip out your php/python/ruby with your favourite framework out. Got a bottleneck at high cpu or memory bound place, rewrite that piece in C/C++. Need to deploy a cross platform app really quickly, Java. Want to bind or write a test for a bunch of tools, use Python or Perl. The list goes on.
Summary: Learn More, use the right tool, do less, get more accomplished.
"C/C++" is not a single language, by all means learn C.
One should learn both. If you spend the time to learn C, might as well spend a tiny bit more and learn the C++ concepts as well. There are ton of pure C libraries, but a lot of algorithmic stuff in C++ STL/Boost kinds, knowing both C and C++ is essential, each by them selves wouldn't necessarily help one too much.
[deleted]
I agree with everything but (1), (5), and (10).
(1) Other languages may be influenced by C++ (especially at a syntactic level, and, superficially, in their object models). But those other languages are far easier to learn and become facile with than C++ is. Point (1) advocates for learning languages in the wrong order.
(5) Templates and generic programming are just tools to mitigate the badness of C++.
(10) Though a majority of the smartest hackers I've worked with know C, a minority of them are C++ developers. And that still leaves plenty of room for smart people who know neither language.
(1) Other languages may be influenced by C++ (especially at a syntactic level, and, superficially, in their object models). But those other languages are far easier to learn and become facile with than C++ is. Point (1) advocates for learning languages in the wrong order.
(5) Templates and generic programming are just tools to mitigate the badness of C++.
(10) Though a majority of the smartest hackers I've worked with know C, a minority of them are C++ developers. And that still leaves plenty of room for smart people who know neither language.
"You will hardly be seen as a hacker if you don’t know C++"
Yeah right! You are "seen as a hacker" if you write code that is useful to others and/or is brilliant in some respect. Nothing to do with knowing a particular language.
If knowledge of a specific language is a criterion, I'd rather have someone be an expert in C/lisp/smalltalk/haskell/prolog.... C++ originates or embodies no concepts that weren't discovered or done better elsewhere.
e.g: An expert smalltalker is more likely to understand OO than a C++ programmer.
Yeah right! You are "seen as a hacker" if you write code that is useful to others and/or is brilliant in some respect. Nothing to do with knowing a particular language.
If knowledge of a specific language is a criterion, I'd rather have someone be an expert in C/lisp/smalltalk/haskell/prolog.... C++ originates or embodies no concepts that weren't discovered or done better elsewhere.
e.g: An expert smalltalker is more likely to understand OO than a C++ programmer.
> your reputation as a programmer will be lower if you don’t know it
I could learn C++, or I could learn Smalltalk, Scheme and Haskell in the same time and mental space.
I could learn C++, or I could learn Smalltalk, Scheme and Haskell in the same time and mental space.
[deleted]
I like to use C++ just as a better C.
Things like single line // comments and not having to declare all your variables at the top of your functions is really useful.
STL is also really useful in that you don't have to (badly) reinvent basic data structures like vectors and maps. Of course, STL also means reading compiler errors that are pages long... :-/
Things like single line // comments and not having to declare all your variables at the top of your functions is really useful.
STL is also really useful in that you don't have to (badly) reinvent basic data structures like vectors and maps. Of course, STL also means reading compiler errors that are pages long... :-/
C99 has single line // comments. It also has the restrict tag.
About the idea of C++ as a better C, See "C++ - The Forgotten Trojan Horse". (http://ejohnson.blogs.com/software/2004/11/i_find_c_intere.h...)
If you're using C++ for the STL, keep in mind that the ML languages (OCaml, SML) also have compile-time parametric data structures, and they infer and check their usage for you.
They also have a proper module system, so when you change a private variable, you don't have to choose between linking errors or recompiling damn near every piece of C++ code in your source tree.
They're also pretty fast.
About the idea of C++ as a better C, See "C++ - The Forgotten Trojan Horse". (http://ejohnson.blogs.com/software/2004/11/i_find_c_intere.h...)
If you're using C++ for the STL, keep in mind that the ML languages (OCaml, SML) also have compile-time parametric data structures, and they infer and check their usage for you.
They also have a proper module system, so when you change a private variable, you don't have to choose between linking errors or recompiling damn near every piece of C++ code in your source tree.
They're also pretty fast.
The ML family of languages is my favorite (second only to C++, natch.) but their brand of parametric polymorphism is equivalent in C++ to MyTemplate<T*> (or, if you like boost, MyTemplate<reference_wrapper<T> > would be more accurate.) They are not the same as MyTemplate<T>. This is by choice of ML language implementors, as they see it as a defect of C++ that every template instantiation has to be compiled independently. Instead, they turn static compile-time polymorphism into run-time dynamism using indirection and function pointers. (Maybe MLton doesn't do this, but I know GHC does.)
It's the difference between C's qsort and C++'s std::sort. The latter blows the former out of the water when sorting small things. This brand of polymorphism is unique to C++ and until someone does it better (which no one seems to have any interest in, except maybe Walter Bright) then C++ will always be "the best C."
It's the difference between C's qsort and C++'s std::sort. The latter blows the former out of the water when sorting small things. This brand of polymorphism is unique to C++ and until someone does it better (which no one seems to have any interest in, except maybe Walter Bright) then C++ will always be "the best C."
This is why I said "pretty fast", not necessarily faster than C++. Using ML means trading a small percentage of C++'s raw speed for code that can be debugged, adapted, etc. with much less trouble. I have found this to be a more than reasonable trade-off in virtually all cases.
Not only are comment styles a horrible reason to pick one language over another, but you need to get a new C compiler. // is part of c99 and can be used without any special work in modern gcc.
Also on the data structures. Base C does not include them but there are libraries for such data structures if you want such as glib.
Also on the data structures. Base C does not include them but there are libraries for such data structures if you want such as glib.
[deleted]
STL is way out of the realm of "just better C". It's pretty much several new concepts: object-oriented programming and aspect-oriented programming.
Unfortunately, this also means that working with any real C++ code base will involve working with code written by people most familiar with a different 20% of the language than you.
I find my time is much better spent writing in a more flexible language that integrates well with C (I like Lua), and saving C for the small parts that actually need it. Also: I can think of few language that have worse object systems than C++. It's not exactly a shining example of OO done right.
Often, an efficiency issue is better remedied by a fundamentally different design, rather than just "pushing harder", and C++ makes it particularly easy to lose sight of this.
I find my time is much better spent writing in a more flexible language that integrates well with C (I like Lua), and saving C for the small parts that actually need it. Also: I can think of few language that have worse object systems than C++. It's not exactly a shining example of OO done right.
Often, an efficiency issue is better remedied by a fundamentally different design, rather than just "pushing harder", and C++ makes it particularly easy to lose sight of this.
[deleted]
In the context of code sampled, the difference between Java and C++ (and PHP and Javascript and a few others) is trivial and will hardly affect your understanding of the code. These are all part of a family of languages with C-style syntax.
When I first started programming, people would say the same kind of things for learning some form of assembly. 10 years from now people will probably be making an article like this for Java and C#.
really? with python/ruby/clojure/erlang/lua/js coming up in the world? ... i thought this was going to be a 1991 article.
I feel the most compelling reason to use C++ is that it is one of the de facto programming languages in competitions.
This is the same reason I drive a NASCAR stock car to work.
Seriously, the defining aspect of most programming competitions is that you're making a program as fast as possible, whatever it takes. C++ rewards this: if you keep sinking an order of magnitude more effort into it, you can seemingly always shave off another tenth of a percent of the time. There are some cases in which this is actually relevant (many involving graphic rendering, a niche I work in, PS), but they're really a tiny part of programming.
It makes sense to code them in C++ (or C), but it's really not the best fit for more general development, which usually places a higher priority on being able to deliver an adaptable and correct solution.
Seriously, the defining aspect of most programming competitions is that you're making a program as fast as possible, whatever it takes. C++ rewards this: if you keep sinking an order of magnitude more effort into it, you can seemingly always shave off another tenth of a percent of the time. There are some cases in which this is actually relevant (many involving graphic rendering, a niche I work in, PS), but they're really a tiny part of programming.
It makes sense to code them in C++ (or C), but it's really not the best fit for more general development, which usually places a higher priority on being able to deliver an adaptable and correct solution.
Didn't we do this discussion already when the last C++ article was posted?
Wall Street runs on C++.
If you want to be a master of the machine use C/C++; if you want to be a slave use Java; If you want to be a slave of a slave then its C# for you. Simple :)
( Disclaimer : My comments are limited to only the above 'popular' languages in discussion. Also I program purely on *nix, so I am not aware of your other dark or better worlds out there )
( Disclaimer : My comments are limited to only the above 'popular' languages in discussion. Also I program purely on *nix, so I am not aware of your other dark or better worlds out there )
In fact, I am sad to say that unless your job requires it, I can't really think of any reason to learn the language. It relies on a mixture of paradigms that are easier learned from other languages where they are isolated. And for lolevel stuff, you are better off learning C.