If you need to do systems level programming (eg. write a database), and you want to go beyond C's code organization capabilities, and you can select a sensible subset of C++, it's a great language, and you get to control all aspects of memory and CPU.
We're writing our database(s) in C++, and we're pretty much loving every minute of it, and would not switch to C, Java, Erlang or whatever.
Of course we're a startup, so we got to select our own subset, write our own containers, etc:
One downside is it's hard to find good C/C++ programmers on the market. The vast majority of applicants cannot complete our first interview filter (removing a characters from a C string and writing an instrusive stack in C++):
Looking at your code a bit, it seems you are not using templates, operator overloading, exceptions, STL or std::string. Your test framework also looks custom built (aside: IMO UnitTest++ would have fit you style). I think if you just changed class data to structure and member functions to accept structure pointer, you would get a nice C representation (almost every class I looked at had an Init method). In effect you are using C++ to avoid very small boilerplate code in equivalent C program.
No wonder you find C++ pleasurable, you are using it as C with classes! However, if you are working on an existing code base with mix of STL, boost and bunch of other libraries, you would start feeling pain of using C++. In my experience, every library author uses a different subset of C++ and as an application writer, you often have to grapple with the glaringly different idoms in your program. I find boost pleasurable to use; however looking at boost source is enough to melt my mind.
Almost everywhere C++ (language and libraries) try to satisfy every corner case and sacrifice usability of common case. e. g. STL iterators (at least I have BOOST_FOREACH to soften them). Ah well this is probably contributing very little to the discussion but I feel better now :) So let me redirect to [C++ FQA](http://yosefk.com/c++fqa/) and let yourself decide whether the points in FQA make sense to you.
I think C++'s popularity comes from the fact that it is essentially a better C. Which parts of it are better than C happen to be a matter of taste and for what you need it. I don't think anyone loves all of C++. But I think there isn't a viable competitor in the "C, but better" space at the moment. Go is probably too high level to be a complete replacement. D is... a weird case. I don't think it stands much of a chance in the market because it's not sufficiently better than C++. Overcoming C++'s momentum is extremely difficult at this point.
EDIT: downvoters: if you think I'm trolling, please note that I've written more code in C++ than any other language. I would love a "better C" that's universally better than C++. If you disagree with my points, please elaborate.
I'm curious as to why you wrote your own containers instead of using the C++ Standard Library, Boost, EASTL or any of the other existing container libraries. Care to elaborate? Eg, if performance or fine-grained control over memory is an issue, take a look at EASTL, which EA use in their games (and is designed to be suitable for both PC's and consoles). They are also extremely stable and well tested.
I've never tried to find C++ programmers on the market, but I do seem to come accross fewer and fewer C++ programmers now. I use a lot of C++ myself (amongst other languages, including Clojure, Java, Python and recently SML). I think having learnt it long before becoming a professional programmer may have given me a kind of attachment to it, but I actually enjoy using it (most of the time, I do often wish it did things differently or supported features I see in languages like ML or Lisp derivitives).
As for your interview question, the first seems almost trivial. The second, an intrusive stack, isn't very hard either [1]. I'm surprised that most applicants have trouble with them!
[1] Heres one I slapped together in ~5 minutes (no comments, only tested by running that code, etc etc): https://gist.github.com/827619
So I guess I'd say it requires more discipline than, say, Java. (One could similarly argue that writing good Perl requires more discipline that writing good Python.)
There's also John Carmack's quip:
IMO, good C++ code is better than good C code, but bad C++ can be much, much worse than bad C code.
One downside is it's hard to find good C/C++ programmers on the market.
It's interesting that C++ is increasingly becoming a niche skill. When I started programming you pretty much had a choice of C++ or VB if you wanted a job.
Suits me fine though. A lot of the most interesting work (DSP, kernels, graphics etc) is in C++.
The remove_char function was fun to write, and I found a bug in my first implementation!
The Intrusive Stack problem; however, is confusing to read. I searched for a description of what an intrusive stack is on DuckDuckGo, and the first result was for the Scalien job application. Further down on the page (through what appears to be several quasi-related links) I found a Boost article on intrusive containers which explained the idea much more clearly. After reading the Boost description, then re-reading the Scalien description another 3 or 4 times, I'm not comfortable to write an intrusive stack.
Are you sure applicants aren't failing because the application problem for the intrusive stack is written in a confusing manner?
I love programming in a sensible subset of C++ too.
The problem is that C++ has long history and when it began, many programmers had erroneous ideas about OO - some skipped it completely, some built absurdly deep inheritance trees, some engaged in ridiculous tricks to stay within "doctrine" (remember a fellow who had a pointer-member to the same object in a parent and a child class just avoid something about down-casting).
So from this history, there's a lot of really bad C++ code "out there".
And just much, when you take two code bases or two groups of programs, each happy with their different sensible subset of C++ and combine them, without being careful, you also wind-up with a hellish mess.
I'm currently implementing a complicated algorithm in C++. I don't have to use many language features for that, so I don't have a strong oppinion about them.
But what I can say is that, compared to Java, the tools for C++ coding suck. Hard. In Eclipse you can write some gibberish and it automatically turns it into valid Java that mostly does what you want. The Java debugger is excellent and works without hickups. The experience you have with Eclipse and CDT just isn't the same. No automatic inclusion of header files, autocompletion doesn't always do what you want, no documentation included, even for the STL. Working with gdb is painful, most of the time it is not possible to properly inspect datastructures in memory and it is generally just easier to litter the code with print statements.
Part of the tools issue arises because C++ insanely hard to parse (the preprocessor makes it even harder); recovering programmer intention from something that is "almost" C++ is an exercise in futility. This is, I think, a genuine problem with the language. There are of course good arguments in the "Java wouldn't need such good tools if it was a better language" camp; best of both worlds would be a language that's easy to write tools for but doesn't really need them.
With regard to debugging, I think you're being unrealistic. You're comparing debugging on a fully introspective and managed virtual machine to debugging annotated assembly language. Apples & oranges. If a fully managed VM meets your needs, then use it. If it doesn't, well, welcome to low level programming.
You also make it sound worse than it is; JVM debuggers aren't perfect either: they debug Java-the-language fine, but other JVM languages are more problematic. Good luck with JNI, too. Likewise, there are C++ debuggers which are STL-aware, and even those that aren't can usually be coaxed into displaying pointers as arrays or as supertype pointers. Using gdb directly is rarely necessary; there are perfectly decent frontends. If you're having problems because you're trying to debug compiler-optimised C++, then you're simply running into the limits of the platform. Debugging post-JIT Java is no fun either.
In Eclipse you can write some gibberish and it automatically turns
it into valid Java that mostly does what you want.
Isn't this the reason that many treat java programmers as suspect ? I think IDEs are fine once you have mastered the language and the syntax, but it often masks the gaps and deficiencies in one's own knowledge. I find that a bit scary.
I understand that mine would be a minority view. Guess work at the IDE together with TDD has significant fan following. Apparently it gets the job done, if that be so, who am I to complain.
Eclipse and CDT for C++ coding sucks. However this doesn't mean there aren't any good tools. Both Visual Studio and XCode are very good for working with C++.
Whilst I couldn't find a way to automatically include header files, once they're added NetBeans automagically switches on autocomplete and finds documentation where available. I've used it for my own C++ projects (using headers and libraries from others as well as my own) and had no problem. I'm by no means an expert (used C++ for only a few months, coming from a PHP background) but I managed to get a few CGI applications working using Xerces-c
(I'm gonna get reamed for this, but...) Visual Studio is great and with the proper setup can do all of that and more. Obviously it's Windows only, so that may be a problem.
Frankly, I think much of people's hatred against C++ is the relative lack of good tools on non-Windows platforms.
That's interesting to me that so many people dislike C++. I prefer it to Java (which I find extremely verbose), don't think its features are really that complex and like its speed. I think it's a powerful object orientated statically typed language.
It seems when compared to other statically typed languages (it doesn't really make sense to compare with dynamically typed languages) C++ does a good job. The STL prevents you from having to reimplement many things you might otherwise need in C and the syntax is more natural or intuitive when compared with C as well.
I have a feeling people just prefer what they're familiar with and make sweeping generalizations or exaggerated claims about other languages and technologies.
A lot of C++ bias lingers from the days when compiler support for more sophisticated features like templates was very immature and buggy. C++ is much more pleasant to code in now than it was when I first used it in 1997. I certainly wouldn't want to write a webapp in C++, but for anything that requires speed and direct control of memory C++ is still really the only game in town and I quite enjoy it when it's the right tool for the job.
People describe Objective-C as "c with objects" done the right way but I'd much rather code in C++ than Objective-C. I also don't really understand why people say they prefer to write in pure C, at least not in 2011. Hacking together a homegrown OO system in C with structs and function pointers and macros doesn't sound any easier or simpler to me.
In which way java is more verbose than C++? People in Java tend to choose longer names but, that is more programming style than something in the language.
In C++ you have to declare your functions in a header, then you have to do it again in the .cpp, I dislike it because if I change one I have to change the other one.
Man I am tired of hearing what Zawinski thought about C++ fifteen freaking years ago. If you're good at C++, use it. If not, don't. If you want to get good at it, practice. How is that different from any language?
One thing to remember, especially when considering the discussion of C++ at Netscape, it took awhile for most compilers to implement a consistent set of the C++ features. Netscape was being built across a dozen or so platforms and this was a major concern. If you have built Mozilla recently, the process to do so is not a couple of click action it is somewhat involved. It was worse way back when.
I've used C++ at the last for companies I have been involved with. The only consistency has been that no place used the same subset of C++ features. It usually boils down to what subset the team members are comfortable with. Variations have included exceptions or not, whether or not to use multiple inheritance, STL or Boost (yes, boost isn't really part of the C++ standard, but things like shared ptrs are in TR1), whether or not to use TR1, etc.
I personally don't have a strong opinion, but there are people that abuse C++ in ways that produce lousy code -- classes as a way to have nearly global variables, the whole C with classes approach, etc.
You really should use the right language for what you are working on and that plays well with any libraries you may want to use.
The real shame about C++ is that it's the only mass market C-level language with advanced features built on top of it. Don't get me wrong: I agree with the author and his interviewees. I think C++ is a horrible language for the very reasons described: everyone uses a different subset of it and it's hideously complicated.
For a more current view, see Linus Torvalds' comments [1] [2].
What I would like to see is a language very much like C (being low-level) with a few features built on top. What those features are I guess is the real trick.
One thing I like about C++ is the constructor/destructor mechanism. It's very explicit. The trend now is towards garbage collection (which, admittedly, you can implement in C++). This is a trend I largely agree with. It's quicker and cheaper to write software that way (IMHO). But there is still a place for simper schemes as all GCs I've come across have issues.
One thing I think such a language shouldn't be is object-oriented. To quote Joel Spolsky [3]:
> A lot of us thought in the 1990s that the big battle would be between procedural and object oriented programming, and we thought that object oriented programming would provide a big boost in programmer productivity. I thought that, too. Some people still think that. It turns out we were wrong. Object oriented programming is handy dandy, but it's not really the productivity booster that was promised.
Or at least such objects should be very limited in scope. Linus addresses some of the reasons for this, such as knowing which function is being called by simply looking at a code snippet (typically a patch in his case).
When writing low-level code I certainly do much prefer C over C++. But having the tools to build automatic reference counting into C would be really nice at times.
There is some decent code in Doom Classic, but it is all C, and I would prefer to do new game development in (restrained) C++
…
I had been harboring some suspicions that our big codebases might benefit from the application of some more of the various “modern” C++ design patterns, despite seeing other large game codebases suffer under them. I have since recanted that suspicion.
There are subsets of C++ that I just find too useful to pass up, particularly STL data structures like strings and vectors. Why shouldn't I use them? I'm just going to have to keep using them until I "blow my whole leg off" as they say.
Interesting article. I do not have much experience in C++ but I am learning Objective-C. Do any of the sentiments mentioned in the article carry over to Objective-C? Or is that comparing apples and oranges? Is Objective-C a better extension/ superset (whatever the formal name) to C?
I would say that Objective-C in itself is a very simple object orientation layer on top of C. If you know C, you can pick up Objective-C in a matter of minutes. It is really simple.
What makes Objective-C useful in OSX programming is the framework Cocoa. If you say, you do 'Objective-C programming' you mostly mean 'Cocoa programming'.
In contrast to that, it probably takes years to really understand everything C++ has to offer. And that is talking about the language only, no frameworks or libraries included. Hence, I would say that you can not really compare Obj-C/Cocoa to C++, since the former is a framework and the latter is a language. (This is assuming that most people mean 'Objective-C and Cocoa' when they say 'Obj-C')
If you want to compare Objective-C and C++ on a language level though, you are comparing two very different languages. Objective-C strives for simplicity and readability, which makes some things easy and some things harder. C++ strives for world domination. There is nothing you can't do with C++, but there are just so many things you can do that figuring out how to 'properly' do stuff can be kind of horrid. Really, there are so many different styles and dialects of C++ that you could use and freely intertwine that defining the language proper is a real challenge. Note that this is not necessarily a bad thing. C++ has a lot of strengths and is increadibly malleable for many different applications. But putting all that flexibility in one language certainly makes that language a truly complex beast, where even reading it can be a real challenge even after years of using it.
Personally, I am a sucker for simplicity and elegance and I would take Obj-C over C++ any day. On the other hand, I have seen some situations where Obj-C's message passing was just too slow for my application and I had to drop back to C function calls in some areas. Also, Garbage Collection and even Reference Counting have a certain performance penalty that might make Obj-C unsuitable for, say, embedded applications.
They are very different languages with different objectives. Both of them started with the goal to provide OO to the C language because It was used for everything at that time.
C++ was designed with performance in mind. The main goal was to be as efficient as C and It means to not use any runtime.
Objective-C was designed to be source compatible with C and extends the language with a Smalltalk like syntax for OO. It uses a runtime which provides things like reflexion and GC.
Objective-C and C++ are very different apart from their C ancestry. C++ doesn't make an especially good Obj-C replacement, and Obj-C is probably no better at the situations where C++ excels than raw C. Objective-C is a higher-level, dynamic-ish, highly-OO extension to C. (great for GUIs, not so great for writing drivers) C++ is quite low level, not dynamic at all, and not overly OO. C++ is very expressive in many situations due to its generic and automatic resource management features, which Obj-C lacks completely. (GUI code is typically horrendous, driver writing is nicer than in C)
Objective-C is a completely different approach to OO C than C++. Obj-C is basically straight C with a very Smalltalk-like OO layer and totally different flavor. Generally speaking I prefer C++ but Obj-C is a better choice if you need to do a lot of metaprogramming. The things you can do with message passing in Obj-C probably make it a better choice for building UIs, for example. Although I really miss the scope-managed resources of C++ when writing iOS apps.
The more dynamic nature of Objective C enables many of the design patterns used in Cocoa development. Delegation, key-value coding, binding targets and actions, the introspection behind Core Data, and many others.
Obviously, C++ being Turing complete these are all technically possible with C++. But in practice it would amount to "Greenspunning" the features of Objective C into C++.
"I think the decision to be backwards-compatible with C is a fatal flaw." --Guy Steele
The funny thing is Objective-C is also backwards-compatible with C and there is a huge world of difference between programming in Objective-C and programming in C++.
While Objective-C is backwards-compatible with C, it doesn't tend to be as noticable as much as it is with C++. Objective-C feels like a markedly different language in which you can do inline C if you want to, while C++ feels like more of an extension of C.
It's not so much that it's backwards-compatible with C so much that it is C. It's plain C with a class and run-time messaging system built on it. Message sends are translated to C function calls by the compiler.
Why we're using C++? Because we're writing 3d graphics
and memory heavy gui applications for the engineering
world. In this regard the combination of Qt and OpenSceneGraph is quite nice.
I really can't understand, how someone can favour C
for C++. Ok, C is the easier language, but the better
abstraction capabilities of C++ outweighs this on a big code base.
I think the key sentence is this:
"I love to see how they do things because I think they don’t rely on it for the stuff that it’s not really that good at but totally use it as almost a metaprogramming language".
Using templates, it has by far the best metaprogramming abilities in a object oriented language. I haven't used Smalltalk, but I've done production code in C# and Java and whenever using them I always yearned to the metaprogramming abilities of C++.
Slowly but steadily I'm gaining ground on Lisp, so who knows, maybe lisp macros will satisfy this metaprogramming need in the near future :)
The following statement made by the Author doesn't sound like a programmer (leave C++ expert alone).
"I think I once managed to read all the way through Stroustrup’s The C++ Programming Language and have looked at at least parts of The Design and Evolution of C++. But I have never done any serious programming in it."
All I can say is, any programmer worth his mettle would make such a statement... Going through Stroustrups's book isn't possible if you're not interested in C++ programming (given that its not part of For Dummies series), IMHO. It is exactly like comparing it to a Novel. A programming guide is not about reading, its about learning.
I'm not sure what you mean. Have you read Stroustrup's book? It was my first "practical" intro to object oriented programming, and I struggled with it.
I would describe it as Byzantine technology explained with an economy of words that approaches poetry, at least in the way you must ponder each sentence. And the exercises are stimulating, in the sense of a cattle prod. I enjoy that sort of thing, in reasonable doses.
Since then I've stayed away from C++ unless it's externally imposed, and built things with C and Python. I like a language whose basic features can fit in my small brain, a language that gets out of the way.
The author is Peter Siebel, a fairly well-known lisp hacker and author of Practical Common Lisp. While he's not a C++ programmer (and doesn't claim to be), you can't say he's not a real hacker.
I think the problem is in fact that nowadays developers jump into languagens like Python, Ruby or PHP because it's easy to learn, easy to install and run the environment and easy to code (you don't have to deal with memory or code optimization).
C/C++ are the base for everything you code today. People start learn how to code with languages like Java, jump straight into OOP. That's wrong.
Every developer should build at least a "hello world" in C, to know what's a real code. Ever developer must know about memory management, to scale optimize the code in any language. Other languages compilers do that for you, but you really need to know how it works.
I really enjoy C++. It's a "live and let live" language. Pick what you want to use and be happy. Sure, not everyone picks the same pieces to use, but like in everything, humans will have differences and C++ allows and encourages that.
You can do procedural, functional, OOP, generic, template meta-programming etc. It has something for everyone and does not try to force anything down your throat. That is why I love it.
[+] [-] Maro|15 years ago|reply
If you need to do systems level programming (eg. write a database), and you want to go beyond C's code organization capabilities, and you can select a sensible subset of C++, it's a great language, and you get to control all aspects of memory and CPU.
We're writing our database(s) in C++, and we're pretty much loving every minute of it, and would not switch to C, Java, Erlang or whatever.
Of course we're a startup, so we got to select our own subset, write our own containers, etc:
http://github.com/scalien/scaliendb
One downside is it's hard to find good C/C++ programmers on the market. The vast majority of applicants cannot complete our first interview filter (removing a characters from a C string and writing an instrusive stack in C++):
http://scalien.com/pdf/job.pdf
[+] [-] suraj|15 years ago|reply
No wonder you find C++ pleasurable, you are using it as C with classes! However, if you are working on an existing code base with mix of STL, boost and bunch of other libraries, you would start feeling pain of using C++. In my experience, every library author uses a different subset of C++ and as an application writer, you often have to grapple with the glaringly different idoms in your program. I find boost pleasurable to use; however looking at boost source is enough to melt my mind.
Almost everywhere C++ (language and libraries) try to satisfy every corner case and sacrifice usability of common case. e. g. STL iterators (at least I have BOOST_FOREACH to soften them). Ah well this is probably contributing very little to the discussion but I feel better now :) So let me redirect to [C++ FQA](http://yosefk.com/c++fqa/) and let yourself decide whether the points in FQA make sense to you.
[+] [-] pmjordan|15 years ago|reply
EDIT: downvoters: if you think I'm trolling, please note that I've written more code in C++ than any other language. I would love a "better C" that's universally better than C++. If you disagree with my points, please elaborate.
[+] [-] dkersten|15 years ago|reply
I've never tried to find C++ programmers on the market, but I do seem to come accross fewer and fewer C++ programmers now. I use a lot of C++ myself (amongst other languages, including Clojure, Java, Python and recently SML). I think having learnt it long before becoming a professional programmer may have given me a kind of attachment to it, but I actually enjoy using it (most of the time, I do often wish it did things differently or supported features I see in languages like ML or Lisp derivitives).
As for your interview question, the first seems almost trivial. The second, an intrusive stack, isn't very hard either [1]. I'm surprised that most applicants have trouble with them!
[1] Heres one I slapped together in ~5 minutes (no comments, only tested by running that code, etc etc): https://gist.github.com/827619
[+] [-] js2|15 years ago|reply
The issue is picking the particular subset and then getting everyone to adhere to it. That works okay in mature engineering shops such as google:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...
So I guess I'd say it requires more discipline than, say, Java. (One could similarly argue that writing good Perl requires more discipline that writing good Python.)
There's also John Carmack's quip:
IMO, good C++ code is better than good C code, but bad C++ can be much, much worse than bad C code.
-- http://twitter.com/ID_AA_Carmack/status/26560399301
[+] [-] cageface|15 years ago|reply
It's interesting that C++ is increasingly becoming a niche skill. When I started programming you pretty much had a choice of C++ or VB if you wanted a job.
Suits me fine though. A lot of the most interesting work (DSP, kernels, graphics etc) is in C++.
[+] [-] rudiger|15 years ago|reply
http://stackoverflow.com/questions/5004162/what-does-it-mean...
[+] [-] GrooveStomp|15 years ago|reply
Are you sure applicants aren't failing because the application problem for the intrusive stack is written in a confusing manner?
[+] [-] joe_the_user|15 years ago|reply
I love programming in a sensible subset of C++ too.
The problem is that C++ has long history and when it began, many programmers had erroneous ideas about OO - some skipped it completely, some built absurdly deep inheritance trees, some engaged in ridiculous tricks to stay within "doctrine" (remember a fellow who had a pointer-member to the same object in a parent and a child class just avoid something about down-casting).
So from this history, there's a lot of really bad C++ code "out there".
And just much, when you take two code bases or two groups of programs, each happy with their different sensible subset of C++ and combine them, without being careful, you also wind-up with a hellish mess.
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] l0nwlf|15 years ago|reply
[+] [-] chollida1|15 years ago|reply
What is an instrusive stack?
[+] [-] adrianN|15 years ago|reply
But what I can say is that, compared to Java, the tools for C++ coding suck. Hard. In Eclipse you can write some gibberish and it automatically turns it into valid Java that mostly does what you want. The Java debugger is excellent and works without hickups. The experience you have with Eclipse and CDT just isn't the same. No automatic inclusion of header files, autocompletion doesn't always do what you want, no documentation included, even for the STL. Working with gdb is painful, most of the time it is not possible to properly inspect datastructures in memory and it is generally just easier to litter the code with print statements.
[+] [-] pmjordan|15 years ago|reply
With regard to debugging, I think you're being unrealistic. You're comparing debugging on a fully introspective and managed virtual machine to debugging annotated assembly language. Apples & oranges. If a fully managed VM meets your needs, then use it. If it doesn't, well, welcome to low level programming.
You also make it sound worse than it is; JVM debuggers aren't perfect either: they debug Java-the-language fine, but other JVM languages are more problematic. Good luck with JNI, too. Likewise, there are C++ debuggers which are STL-aware, and even those that aren't can usually be coaxed into displaying pointers as arrays or as supertype pointers. Using gdb directly is rarely necessary; there are perfectly decent frontends. If you're having problems because you're trying to debug compiler-optimised C++, then you're simply running into the limits of the platform. Debugging post-JIT Java is no fun either.
[+] [-] srean|15 years ago|reply
I understand that mine would be a minority view. Guess work at the IDE together with TDD has significant fan following. Apparently it gets the job done, if that be so, who am I to complain.
Edit: It seems I have hurt someone's ego :|
[+] [-] agazso|15 years ago|reply
[+] [-] GvS|15 years ago|reply
[+] [-] jwh|15 years ago|reply
Whilst I couldn't find a way to automatically include header files, once they're added NetBeans automagically switches on autocomplete and finds documentation where available. I've used it for my own C++ projects (using headers and libraries from others as well as my own) and had no problem. I'm by no means an expert (used C++ for only a few months, coming from a PHP background) but I managed to get a few CGI applications working using Xerces-c
[+] [-] pyrhho|15 years ago|reply
?? What's wrong with vim? (or emacs, or your flavour of choice)
[+] [-] roel_v|15 years ago|reply
Frankly, I think much of people's hatred against C++ is the relative lack of good tools on non-Windows platforms.
[+] [-] gonehome|15 years ago|reply
It seems when compared to other statically typed languages (it doesn't really make sense to compare with dynamically typed languages) C++ does a good job. The STL prevents you from having to reimplement many things you might otherwise need in C and the syntax is more natural or intuitive when compared with C as well.
I have a feeling people just prefer what they're familiar with and make sweeping generalizations or exaggerated claims about other languages and technologies.
[+] [-] cageface|15 years ago|reply
People describe Objective-C as "c with objects" done the right way but I'd much rather code in C++ than Objective-C. I also don't really understand why people say they prefer to write in pure C, at least not in 2011. Hacking together a homegrown OO system in C with structs and function pointers and macros doesn't sound any easier or simpler to me.
[+] [-] huherto|15 years ago|reply
In C++ you have to declare your functions in a header, then you have to do it again in the .cpp, I dislike it because if I change one I have to change the other one.
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] stelfer|15 years ago|reply
[+] [-] jmspring|15 years ago|reply
I've used C++ at the last for companies I have been involved with. The only consistency has been that no place used the same subset of C++ features. It usually boils down to what subset the team members are comfortable with. Variations have included exceptions or not, whether or not to use multiple inheritance, STL or Boost (yes, boost isn't really part of the C++ standard, but things like shared ptrs are in TR1), whether or not to use TR1, etc.
I personally don't have a strong opinion, but there are people that abuse C++ in ways that produce lousy code -- classes as a way to have nearly global variables, the whole C with classes approach, etc.
You really should use the right language for what you are working on and that plays well with any libraries you may want to use.
[+] [-] cletus|15 years ago|reply
For a more current view, see Linus Torvalds' comments [1] [2].
What I would like to see is a language very much like C (being low-level) with a few features built on top. What those features are I guess is the real trick.
One thing I like about C++ is the constructor/destructor mechanism. It's very explicit. The trend now is towards garbage collection (which, admittedly, you can implement in C++). This is a trend I largely agree with. It's quicker and cheaper to write software that way (IMHO). But there is still a place for simper schemes as all GCs I've come across have issues.
One thing I think such a language shouldn't be is object-oriented. To quote Joel Spolsky [3]:
> A lot of us thought in the 1990s that the big battle would be between procedural and object oriented programming, and we thought that object oriented programming would provide a big boost in programmer productivity. I thought that, too. Some people still think that. It turns out we were wrong. Object oriented programming is handy dandy, but it's not really the productivity booster that was promised.
Or at least such objects should be very limited in scope. Linus addresses some of the reasons for this, such as knowing which function is being called by simply looking at a code snippet (typically a patch in his case).
When writing low-level code I certainly do much prefer C over C++. But having the tools to build automatic reference counting into C would be really nice at times.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/57643...
[2]: http://www.realworldtech.com/forums/index.cfm?action=detail&...
[3]: http://www.joelonsoftware.com/articles/APIWar.html
[+] [-] js2|15 years ago|reply
…
I had been harboring some suspicions that our big codebases might benefit from the application of some more of the various “modern” C++ design patterns, despite seeing other large game codebases suffer under them. I have since recanted that suspicion.
http://bethblog.com/index.php/2010/10/29/john-carmack-discus...
[+] [-] freedrull|15 years ago|reply
[+] [-] martijn_himself|15 years ago|reply
[+] [-] Derbasti|15 years ago|reply
In contrast to that, it probably takes years to really understand everything C++ has to offer. And that is talking about the language only, no frameworks or libraries included. Hence, I would say that you can not really compare Obj-C/Cocoa to C++, since the former is a framework and the latter is a language. (This is assuming that most people mean 'Objective-C and Cocoa' when they say 'Obj-C')
If you want to compare Objective-C and C++ on a language level though, you are comparing two very different languages. Objective-C strives for simplicity and readability, which makes some things easy and some things harder. C++ strives for world domination. There is nothing you can't do with C++, but there are just so many things you can do that figuring out how to 'properly' do stuff can be kind of horrid. Really, there are so many different styles and dialects of C++ that you could use and freely intertwine that defining the language proper is a real challenge. Note that this is not necessarily a bad thing. C++ has a lot of strengths and is increadibly malleable for many different applications. But putting all that flexibility in one language certainly makes that language a truly complex beast, where even reading it can be a real challenge even after years of using it.
Personally, I am a sucker for simplicity and elegance and I would take Obj-C over C++ any day. On the other hand, I have seen some situations where Obj-C's message passing was just too slow for my application and I had to drop back to C function calls in some areas. Also, Garbage Collection and even Reference Counting have a certain performance penalty that might make Obj-C unsuitable for, say, embedded applications.
[+] [-] pmarin|15 years ago|reply
C++ was designed with performance in mind. The main goal was to be as efficient as C and It means to not use any runtime.
Objective-C was designed to be source compatible with C and extends the language with a Smalltalk like syntax for OO. It uses a runtime which provides things like reflexion and GC.
[+] [-] pmjordan|15 years ago|reply
[+] [-] cageface|15 years ago|reply
[+] [-] jimbokun|15 years ago|reply
Obviously, C++ being Turing complete these are all technically possible with C++. But in practice it would amount to "Greenspunning" the features of Objective C into C++.
http://en.wikipedia.org/wiki/Greenspuns_Tenth_Rule
[+] [-] stephth|15 years ago|reply
[+] [-] brown9-2|15 years ago|reply
[+] [-] jarin|15 years ago|reply
The funny thing is Objective-C is also backwards-compatible with C and there is a huge world of difference between programming in Objective-C and programming in C++.
[+] [-] tjr|15 years ago|reply
[+] [-] bonch|15 years ago|reply
[+] [-] dan00|15 years ago|reply
I really can't understand, how someone can favour C for C++. Ok, C is the easier language, but the better abstraction capabilities of C++ outweighs this on a big code base.
[+] [-] oiuyuiopiuy|15 years ago|reply
Like other construction materials are better than steel unless strength and reliability are a concern.
[+] [-] maayank|15 years ago|reply
I think the key sentence is this: "I love to see how they do things because I think they don’t rely on it for the stuff that it’s not really that good at but totally use it as almost a metaprogramming language".
Using templates, it has by far the best metaprogramming abilities in a object oriented language. I haven't used Smalltalk, but I've done production code in C# and Java and whenever using them I always yearned to the metaprogramming abilities of C++.
Slowly but steadily I'm gaining ground on Lisp, so who knows, maybe lisp macros will satisfy this metaprogramming need in the near future :)
[+] [-] sedachv|15 years ago|reply
[+] [-] bhavin|15 years ago|reply
"I think I once managed to read all the way through Stroustrup’s The C++ Programming Language and have looked at at least parts of The Design and Evolution of C++. But I have never done any serious programming in it."
All I can say is, any programmer worth his mettle would make such a statement... Going through Stroustrups's book isn't possible if you're not interested in C++ programming (given that its not part of For Dummies series), IMHO. It is exactly like comparing it to a Novel. A programming guide is not about reading, its about learning.
[+] [-] phugoid|15 years ago|reply
I would describe it as Byzantine technology explained with an economy of words that approaches poetry, at least in the way you must ponder each sentence. And the exercises are stimulating, in the sense of a cattle prod. I enjoy that sort of thing, in reasonable doses.
Since then I've stayed away from C++ unless it's externally imposed, and built things with C and Python. I like a language whose basic features can fit in my small brain, a language that gets out of the way.
[+] [-] apu|15 years ago|reply
http://www.gigamonkeys.com/book/
[+] [-] rabc|15 years ago|reply
C/C++ are the base for everything you code today. People start learn how to code with languages like Java, jump straight into OOP. That's wrong.
Every developer should build at least a "hello world" in C, to know what's a real code. Ever developer must know about memory management, to scale optimize the code in any language. Other languages compilers do that for you, but you really need to know how it works.
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] 16s|15 years ago|reply
You can do procedural, functional, OOP, generic, template meta-programming etc. It has something for everyone and does not try to force anything down your throat. That is why I love it.
I use it daily and am very productive with it.
Edit: grammar