The C++ Programming Language (4th Edition)
stroustrup.com
stroustrup.com
How about a snow-capped mountain peak? You know, the kind of mountain peak where people die either for lack of oxygen, or because crevasses open randomly across the landscape. The kind of mountain where you might go blind if you take off your sunglasses.
That kind of place.
In any event, I don't think the F-35 with its numerous software-related problems [1, 2] is a good advertisement for C++.
[1] http://spectrum.ieee.org/riskfactor/aerospace/military/f35-s...
[2] http://www.nextgov.com/defense/2013/03/f-35-joint-strike-fig...
At night, the wolves howl...
Photo on the cover is reversed: http://www.shutterstock.com/pic-76471816/stock-photo-snowbou...
Well, it probably is in the right context, but you know what I mean.
:: Clicked the link. RTFA fairy told me to. ::
Oh, that is the actual cover art.
I'd love to be able to write my DSP code in cleaner, simpler language but for now I'm happy that I have a tool that lets me build the software I care about.
I really hope Go catches on more and fixes some of the (imho) bad things about it (like lack of generic programming). And then C++ won't be the only option anymore.
I think that would be much easy to add than C++esque `smart pointers as library`.
I'm pinning all my hopes and dreams on Rust, but as a frequent (ab)user of Boost.Coroutine and gevent I certainly wouldn't mind if Go gained a bit more traction.
Regarding Rust, Rust has lightweight green threads just like Go does. (Go's scheduler is currently more mature though.)
It seems like Rust never ceases to impress.
In-memory computing is a very important trend and garbage collected languages just don't work. You can't have the system stall for seconds or even tens of seconds unless it's purely a batch workload.
I have to admit that I haven't really researched what can be done in Go to keep in-memory data off-heap so the garbage collector doesn't see it. I have done that research for Java and it's unworkable. It's either slow or extremely unproductive to work with or both.
It's even more problematic for some types of trading systems or stream processing of sensor data, etc.
All the trends are working against garbage collection right now. Memory sizes are growing and we're moving away from batch processing for many workloads.
What about languages like Erlang and Rust where each actor/object/process has its own heap, GCed individually?
Rust should work. It's the right approach I think. I haven't used it yet, but I really hope it gains popularity and becomes a real alternative to C++.
Nice omission of pauseless GC algorithms there.
It is also very relevant for me that there is no Java implementation of a pauseless garbage collector that is even remotely viable for my business model or the business model of 99% of all startups out there.
If all you want to say is that it is possible to solve this problem for garbage collected languages, then we can agree. Unfortunately there is no viable solution available right now.
Well, surely with so many top notch brains Google can come up with a way to improve Go's runtime if they care about the issue.
> It is also very relevant for me that there is no Java implementation of a pauseless garbage collector that is even remotely viable for my business model or the business model of 99% of all startups out there.
Do you mean viable, as free of charge?
> If all you want to say is that it is possible to solve this problem for garbage collected languages, then we can agree. Unfortunately there is no viable solution available right now.
Yes, that is my main point.
No, but it would have to be a fraction not a multiple of my per server profit margin. Azul's target market is clearly hedge funds and the like. They don't even quote a price on their website.
To be not only viable but also beneficial, the Azul license plus the additional DRAM cost of Java itself would have to be less than it costs me to use C++ instead of Java.
However, the same can be said about classical C style memory management. An alloc can be almost immediate or take lots of time because it has to request a fresh memory block from the OS. Similarly, a free can or cannot take time to coalesce blocks.
Yes, the differences are much smaller there, certainly historically, but garbage collectors have improved, and I am not sure that C-style allocators can stay predictable in long-running programs. Let's say you have a terabyte of RAM, and want to run a multi-threaded server in it 'forever'. Chances are that your garbage-collected system will be more stable and use less memory because it can compact memory. A C style allocator would need quite a few heuristics (or maybe, even contain some machine learning code that builds a model of memory allocation patterns) to prevent memory fragmentation. Such features would make their timing less predictable.
Because of that, I think we may at some time see an OS with built-in garbage-collection become mainstream.
The problem is not how much but when - you never know when GC fires and interrupts your running code. That is a nondeterminism.
Also, most OS-es are non-deterministic, anyways. You cannot predict whether your code lives in cache/main memory, or on disk. In some systems, your data even might have to be brought in by a tape robot without your code being aware of it. As soon as a garbage collector manages to get its interruptions to be about equal to delays caused by caching and virtual memory, I doubt many people will care.
You never know when GC fires - starts harvesting for memory locations that need to be freed and frees them.
Also, garbage collection does not "harvest for memory locations that need to be freed and frees them.". Garbage collection does not collect garbage, it collects used space.
Here are some more details if you're interested:
http://en.wikipedia.org/wiki/Garbage_collection_(computer_sc...
https://news.ycombinator.com/item?id=5503066
HN is small ;)
I mean, when I say that I prefer deterministic memory management, that includes an automatic reference counting - smart pointers - which are now part of C++11.
On that thread, under my "deterministic", you assumed only "manual" as it seems.
Although, I will say that Vala plus GTK+ is amazing for desktop development on Linux, especially with elementary OS's Granite library. The thing is, it's really just a nice language on top of C plus GObject as a transpiler!
I do wish that some other languages were as nice to use as various scripting languages, but with the performance and pure utility of C/C++. Maybe one day.
Oracle's Project Graal plans to replace the C++ JIT by a Java one. This is based on the work of the Maxime VM.
Much more info about the compatibility and differences for anyone interested on wikipedia[1].
[1] http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B
I just think that their names, common syntax and saying things like 'C++ is a [sort of] superset of C' make people unfamiliar with them think that they are more related than they are. That's why I brought up Python and Ruby - two languages that are different in syntax and many details but in the same conceptual space, whereas C and C++ look more similar, sound like almost the same thing but are, conceptually, on different planets.
The developers of MRI are focused on developing an interesting and useful language first and everything else second. The developers of JRuby are focused on replicating that language on the JVM. They benefit from a sophisticated JIT and GC and in later JVMs some direct help, none of which diminishes their own efforts to improve performance.
Sure you can write slow code in anything but I don't see how that's in any way related to 'your JRuby/CRuby' comparison.
By that logic, any mention of any difference between any language, runtime or its implementation can simply be dismissed by 'well, they ARE all Turing equivalent!'
I just wanted to point out on your previous comment - it is not surprise that only choosing some particular language doesn't mean a guaranteed performance.
I want to learn to create cross-platform games, but want to get in the guts a bit more than, say, Unity lets you. So, C++ is what I decided on.
It's a beast of a language, I'll tell you that much, but it's actually really quite enjoyable to program in! It was the first real language I tried to learn when I was 12 years old. I got as far as making a text game with `switch' statements ;)
Definitely going to order this one I think. Coming from an ALGOL-derived language background for the most part, having something like this as a reference will be brilliant, and a good addition to go with my `Pro C++' book (handles architecture and idioms more than the language itself per se, but does cover some advanced features).
The only thing I wish I could find was a reference on how games are actually _built_: what development patterns, what tools I'll need to write, etc. All I can find are low-level OpenGL based things for writing engines, or fluffy "Design a Game!" crap. *sigh
http://fabiensanglard.net/quake3/index.php
Still, it's not C++. If the goal is C++ sending someone there is akin to suggesting someone interested in studying classic English novels ought to read Les Misérables in French instead of David Copperfield.
http://archive.gamedev.net/archive/reference/list981c.html?c...
I am trying to do the same thing you are doing, to scratch an old itch and get into the guts of programming a game. The following resources proved useful :
http://gameprogrammingpatterns.com/ Developing Games in Java by David Brackeen : it is in Java but goes into some useful detail on how games are built.
Also which book are you referring to when you say Pro C++ ? I am using Nicolai Josuttis' book but I am always on the lookout for good books.
It's `Professional C++ (2nd Ed.)' by Marc Gregoire, et al. It covers C++11 :)
I'm only a little way through it (it's quite a tome!), but it's written well, and covers a lot of questions that I had/have. Well worth checking out IMO.
Here's an alternative: Dive into the GamePlay engine (https://github.com/blackberry/GamePlay/) and go through all the samples (https://github.com/blackberry/GamePlay/tree/master/samples), especially this collection of small feature demos (https://github.com/blackberry/GamePlay/tree/master/samples/b...). You'll get exposed to core concepts like Lighting, Terrain, Particles, 2D GUIs and Lua Scripting, all implemented from the ground up in C++ and OpenGL.
What tools you'll need to write all depends on what tools you'll want to write. Many develop games with no tools at all. Many have a full tool suite that lets them create any kind of content imaginable, whether it's levels, characters, behaviors, scripted events, etc.
And I have to say - yeah, you definitely learn a lot from that kind of project, not least because you have to constantly bear the rather large technical overhead. And that learning certainly feels great. =)
However, I also have to say this: while the sheer power of the 'raw' C++/DirectX combo is enormous in terms of what games you could potentially make, the fact that even basic ideas take a comparatively long time to prototype is something that I think acts as a substantial disadvantage when it comes to the actual business side of things.
I think a lot of really interesting, innovative ideas for game mechanics (or game atmosphere or feedback or other critical and somewhat subjective aspects of game development) don't require the full horsepower (performance or flexibility-wise) of the raw C++/(DirectX || whatever) approach. A few basic ideas (which you don't have to realise from scratch) can combine to give unexpected results, some of which could be really interesting. Maybe it's like spanning a 2D vector space with a linear combination of just two different vectors.
(This might link in nicely with what Daniel Cook means by 'finite infinity' in his talk on game design [1].)
Just something to think about. =)
[1]: http://www.youtube.com/watch?v=f7DFuXDN29M&list=PL1A42B4...
Language design has come a long way since the early 80's. His concerns back then were a programming language that would retain the performance of 'C' on most hardware and be straightforward to generate from 'C' code due to re-use of the 'C' syntax (the early C++ systems relied on converters that translated C++ to 'C'). Over time compilers were created to generate machine code straight from C++. When 4k was a lot of RAM, it made sense to focus on this; it still does if you're developing embedded software with very limited hardware. (FWIW, I've written software in C++ since 1990).
I'd argue hard that today, in most cases, and in particular in web applications, the issue is developer productivity. Today we're focusing more on expressing solutions in code that are much closer to the way that we think. Whether it's Ruby, F#, Scala, or Javascript, the tools we're using allow for more powerful solutions in far less code and complexity than C++.
Let the flames begin..
int const * - pointer to const int.
int * const - const pointer to int.
int const * const - const pointer to const int.
Is that so hard? Those people posting here who think that THIS is the hardest problem in computing should perhaps find a new line of work.
I see this is as
(const int)* foo;
which is the same as
(int const)* foo;
And people prefer
const int foo;
over
int const foo;
So it all makes sense in terms of the grammar. Admittedly, it can be difficult to remember, but pointers and const correctness are complicated and combining them is going to be complicated to write out no matter what grammar you use. Even if the grammar was restricted, it's difficult to remember this type of thing and if you encountered such code in the wild and had any doubts about its semantics then you would look it up on Google before modifying it (right?)
I don't think I was just having sticker shock due to the relative lack of power and expressiveness of C++. I expected to spend time managing memory, recasting objects, etc -- that didn't surprise me. Instead, I was surprised by how badly different parts of the language play with each other, and how many more parts C++ has. ANSI C has about 30 keywords. C++98 had about 30 more. C++11 adds even more. All of these language constructs have complicated relationships with each other, often filled with gotchas and traps. Compare this with the ~30 keywords in Python (and even less in Clojure).
If I'm bound by CPU performance nowadays (which doesn't happen often), I'd use Go or a JVM language. If I absolutely had to, I'd consider C. But never C++.
But you have to consciously decide at the start what set of features that you will use. And no more. Because C++ has multiple usable subsets. Find one. Stay within one. Avoid confusion. (Particularly if, like me, you're not a C++ programmer and don't wish to become one. Then you can have a clearly defined boundary of what needs to be learned for the project.)
C++ does none of that. It's a slightly higher-level modification of C with object-oriented features, and C is still a lower-level language closer to, say, ALGOL or Simula rather than higher-level like Java or Smalltalk. Adding OOP still retains the hardware control and all of the bad stuff that comes with it (segfaults, buffer overflows, etc.), but adds complexity.
C++ is complex. Twisted. Mangled. But it's powerful, and you can do things in it that you could never dream of doing in C, Java/Jython/Mono, Python, Ruby, or Go.
It's like a Mitsubishi Lancer Evolution. It's a pain in the ass to deal with on a daily basis, but its potential is simply unmatched by any other vehicle in its price range. There are others that are more comfortable. But none reach the capability and sharpness of the Evo.
C++ is the Evo.
I don't think this is necessarily true. Dynamic typing moves an entire class of bugs from compile time to run time. And, I am not aware of what benefits it brings (other than minor expressiveness) that can not be had in a static type system. For the most part, you will right code assuming a variable has a given type. If that is not the case, you will get a runtime error instead of a compile time error. In the cases where the variable can be multiple types, doing so in a static type system can be as simple as declaring the type to be polymorphic (or as horrible as java generics, or as hacky as void*). The other advantage of dynamic type systems is that they often come with autocasting.
While both of these do provide some expressiveness, working around them in statically typed isn't really complicated, just a minor amount of boiler plate.
The main awesomeness of Python's type system (and maybe Ruby's, I've never used it) isn't dynamic typing, but duck typing. The idea hear is that you almost never care what type an object is, only if it supports a given method. For example, if I define a new object, and define a method 'read()', I can pass it into a function that was expecting a file, so long as it only calls the 'read()' method.
Of course, avoinding garbage collection is still a big advantage.
The thing that I find creates the most boilerplate for me with static typing is useless helper classes that only exist to get around the fact that class A owns object of type B, so you don't want to allow an object of type B have a method that requires its parent A. Instead you create a class C owned by A which everything that B needs for that call can move into, and then let B know about C. (It does not much matter whether you make A inherit from C, or make C owned by A. Though I stylistically strongly prefer the second.)
Yes, you can set up mutual recursion between two classes in C++, but this involves some gymnastics and is frowned on.
In a dynamically typed language you'd just pass objects of type A into a method for type B.
Refactoring out a whole new class out of an existing one is not "a minor amount of boiler plate" in my books. But that is what C++ pushes you to do.
I do not see why static typing causes difficulty with this. The only gymnastics I have seen in C/C++ do accomplish this is forward declarations. These are not needed because of the type system, but rather because C/C++ requires things to be defined before they are used. For example, java does not have this requirement.
Also, I believe that Go has something simmilar to duck typing, and its a static type system.
This sounds similar to duck typing, but it's significantly less powerful because you pass values into functions with a particular declared type, and you can only access methods available to the declared type of the value.
For example:
interface MyInterface { Bar() }
struct Foo {}
func (this Foo) Bar()
func (this Foo) Baz()
func MyFunction(arg MyInterface) {
arg.Bar() // Fine, because MyInterface has this method.
arg.Baz() // Compiler error because MyInterface does not have this method.
}
This isn't a problem in Python or Ruby because they don't have a notion of declared type in function arguments -- the "type" is resolved at run-time by method lookup.
You can use a generic type as argument (template <typename T> void method(T arg) ), or a templated one (template <typename T> void method(MyObject<T> arg) ). In both cases the method will fail to compile if the body requires a missing field or method, but in the second one you get a standard "type mismatch" error, while in the first you'll get a "type X doesn't support method Y".
> Today we're focusing more on expressing solutions in code that are much closer to the way that we think. Whether it's Ruby, F#, Scala, or Javascript, the tools we're using allow for more powerful solutions in far less code and complexity than C++.
If you compare the amount of code to the ease of abstraction then I'd say C++ scales much better than languages like JavaScript. It's just that C++ gets multiplied by a huge constant: http://i.imgur.com/WxU2oLy.png
My impression is that this is wrong - the language owes essentially everything that it is (including the over-design) to Bjarne. I wrote my first C++ program in 1992 (or perhaps even earlier? I can't find copies of anything I wrote in C++ earlier than 1992), and I've been following the evolution and standardization.
Bjarne is definitely the person that started the "Oh, it's useful! Let's add it to the language incoherently introducing redundancy, duplication, and corners, and we'll sort it out later" mess that is C++.
I campaigned (unsuccessfully) in 1993 with my employer at the time to switch from C to C++ because I saw the benefits. Back then, C++ was already a mess in the making, but it was still small and elegant, and if you stayed within the subset supported by Turbo C++, g++ and Cfront, life was good.
Since 2005 or so, I've been campaigning against C++ and for C (or Python if performance is not critical). That was after I was brought in to fix a C++ monstrosity of a project (and not the first project like that), and realized that the problem actually IS with the language and culture.
This is the reason why I hope I never program in C++ again: you can't learn it (or re-learn it) by inspection.
Yeah, I suppose your example has something to do with the spiral rule (it's been many years), which comes from C (and C has its excuses). But if you come at that cold, it's impossible to reason it out.
No language is entirely learnable by inspection, it's a scale, and C++ is way on the wrong end.
int const * - pointer to const int.
int * const - const pointer to int.
int const * const - const pointer to const int.
I'm not sure what type of grammar could have been used to make this easier. Nobody said that indirection is easy, but indirection IS essential.
If you have to use other words to describe what something is, why not use the other words in the first place?
(well to be fair, 'add 1 to cobol' should be enough)
const typedef;
It may be a shock to some on HN, but there are other applications for computing than web development. I doubt Scala is going to be penetrating triple-A game development any time soon, although I do think it's neat that Javascript has become popular for game UI work. I really like that C#/Unity is going strong and I'm really itching to do something cool with WebGL, asm.js, and/or emscripten.
But despite all the progress these languages have made, some problems still haven't been overcome and it's disingenuous to imply that they have. I doubt many would make the argument that C++ is suitable for web development, and I would expect most people to realize that native code still has its place, at least for now. The day I can use Python, Ruby, F#, Haskell, Erlang, or something cool, I will officially be the happiest person on the planet. It hasn't happened yet. Maybe Rust (oh yes) or Go will set everyone free.
With all that being said, C++11 is a very welcome addition to the language. While adding more bulk to the language, it ends up reducing the complexity of your code. Auto and decltype have been fantastic for eliminating redundant typing info and boilerplate by making code more generic. Smart pointers, unique_ptr particularly, have been great. For Lambda functions combined with STL algorithms like for_each have eliminated a substantial amount of code on their own. Move semantics have had the effect of reducing the amount of line noise by reducing the frequency of seeing things typed const& and the double whammy of bringing performance gains for little or no effort in many cases. I don't think anyone can deny that C++ is a bit heavier than any language ought to be, but it's what we have and I'll welcome any attempt to make my life easier.
Software and programming languages are not zero sum. The use and existence of C++ doesn't preclude the existence or use of another language. Don't try to convince yourself and others that all problems are nails just because you really like hammers.
edit: for the record, I mostly do Python and Clojure outside of work when I'm not doing something graphics oriented
Native code has always had a place and will always have a place. New applications will be written in C++, 20 years from now, when all the inefficient, fadish languages (and the inconsequential websites that they power) have long been forgotten.
I never managed to warm up to Stroustrup's book. I've tried reading it a couple of times. It feels like a schlep. There are many great books on C++. Koenig and Moo, Josuttis, "Effective C++", they all convey the technical information and at the same time read like page turners. I only read fragments of "Thinking in C++" but I think it's in the same category, it reads great. Some of them will no doubt have new editions, updated for C++11. So, not that there's anything wrong with Stroustrup's book, but it just can't compete. Much as I'm looking forward to reading a book on C++11 the language--there already exists an excellent one on the standard library, which is the new edition of Josuttis--it will not be "The C++ Programming Language", 4th edition.
http://www.icce.rug.nl/documents/cplusplus/
It's written more lively and opinionated. Also, it's apt-gettable on Debian and Ubuntu :).
It didn't click at all while using Stroustrup's book, even when I did the exercises.
I don't really have a point, I guess. I haven't tracked C++ in many years and was just surprised at such a large difference.
I'll take C any day of the week, and if I need some higher level features, I'll either write a precompiler that can parse my higher level features before generating C code, or I'll write a bindings generator to connect to Javascript/Ruby (I've used both options successfully in the past).
Anyone know how different the book is from the previous edition (minus the obvious C++11 stuff)
(I kid, I kid... please don't hurt me?)
It's true that it's hard to shrink a language, but several of C++'s new features are designed to make modern designs expressible in much more concise, elegant code.
compared with other C++ code that is :-).
Amazon states it's 1368 pages.
TR/84 [3] provides tools to generate documentation in various formats from the mentioned XML file. The included output as PDF sums up to 5,868 pages.
Finally there is TR/89 [4] describing some more generic types on 67 pages.
[1] http://www.ecma-international.org/publications/standards/Ecm...
[2] http://www.ecma-international.org/publications/standards/Ecm...
[3] http://www.ecma-international.org/publications/techreports/E...
[4] http://www.ecma-international.org/publications/techreports/E...