What sort of cover art should we use for the book?
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.
At least it's the sort of mountain peak where you can initialize user data types with {} and use closures like every other language in existence. It's a much better peak than it was three years ago.
How about a picture of an F35 fighter jet? Because a fighter jet goes much faster than [insert your preferred hipster language]? Or, you know, the F35 uses C++ code (and not Python/Clojure/LISP/PHP/Ruby/whatever).
The F-35 is about embedded software, i.e. it's about C/C++ vs. Ada, not C/C++ vs. Python. The reason they didn't go with Ada was a lack of programmers, not language design issues, as I recall.
In any event, I don't think the F-35 with its numerous software-related problems [1, 2] is a good advertisement for C++.
I expect to see all the usual writeoffs of C++ here. And, to be sure, it's an easy language to criticize. But, for better or for worse, it's still the only reasonable choice for a lot of very interesting application domains. And a lot of its less elegant features make more sense when you think carefully about the specific design goals for the language.
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.
Yes, I also noticed that when it comes to the really interesting things, it's almost always either C or C++. Operating systems, DBMS'es, interpreters, game engines, browsers and lots of other stuff. Projects like webkit, v8, unreal engine are all frighteningly large pieces of high-quality performance-critical software written in C++. I think it really deserves more credit.
Exactly. I'm a (web) developer, mainly working with dynamic scripting languages, and honestly for my "play" at home, C/C++ is what I'm forced to use to do interesting things.
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.
They're both interesting and worth knowing something about but it's important not to conflate C and C++ - these are two languages that are probably more different than Python and Ruby are. Nor does merely writing in C or C++ guarantee performance - JRuby, for instance, often outperforms the standard ruby interpreter written in C.
Correct, they're not exactly the same language, but C can be made to be compatible with C++ compilers (and is sometimes considered a subset of C++, though not exactly true). However, one wouldn't want to assume all bugs, quirks and syntax are 1:1. That would be like saying because you can drive an automatic transmission, you can easily drive a manual without any practice and knowledge beforehand.
Much more info about the compatibility and differences for anyone interested on wikipedia[1].
Oh I didn't mean as a matter of compatibility, although compatibility is (mostly) achievable and they share a syntactic and structural origin.
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.
Sure but that's true for almost all software. It's turtles/C[++] nearly all the way down, if you pick a particular way of looking at it. Besides, a modern JVM JIT does not emit C.
You can but I don't think that's a particularly fair, representative or insightful comment on why the difference exists.
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 think that's true, but it's also sad. I've looked at D and it's criticism seems reasonable to me: it actually seems to have more features than C++.
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.
Go is nice but it's a replacement for Java or Python not for C++. I'm working on an in-memory analytics engine, something that has only become affordable in recent years because memory prices have fallen so much.
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.
Garbage collection pauses are a huge concern with larger heap sizes. Depending on the application it may be OK to make a user wait for a second or two, but not for 30 seconds. Multitasking doesn't cause that kind of lag usually.
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.
Most definitely - on a modern multitasking operating system your "all types of pauses" is generally only synchronous IO issues to disk or network - as long as you've got spare CPU available to your process/threads and you're sensible with your memory allocation.
> 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.
What about languages like Erlang and Rust where each actor/object/process has its own heap, GCed individually?
> 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.
As someone who had tried to work with available GCs in Java, GP is spot on; it doesn't matter that algorithms exist - production JVMs still pause (or at least did 2 years ago when I looked into it)
Can you point me to a reasonably mature and efficient implementation of such an algorithm for Go or Java? I only know the Azul one which costs thousands of dollars per server per year.
Irrelevant for what? This was a debate about whether or not Go can replace C++, remember? So the fact that there is no such implementation for Go has to be relevant.
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.
> Irrelevant for what? This was a debate about whether or not Go can replace C++, remember? So the fact that there is no such implementation for Go has to be relevant.
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.
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.
That's exactly how I feel, I guess. D seems to have a lot more features (import, public import, and static import?) and I'm no expert but I feel some aren't all that necessary/add enough value. Go has fewer than C++, which I think is really good, except for some few ones that I wish were there. Only generic programming/templates off the top of my head actually.
See I don't know about that. Maybe exceptions was one of the features that was good to be left out. I think maybe the comma ok idiom forces the programmer to more actively check for errors and recover from them, and there is no need to do things like RIIA. Maybe also the code is clearer to read, because you can see "if not ok then do_this()" and know that this is error checking/recovery code, instead of looking up the call stack to see where the exception that was thrown in one place is being handled.
I haven't looked at D in a while, but I recall it having two competing standard libraries.
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.
There isn't anything nondeterministic about garbage collection systems; it is just that it is hard to predict how much time they will take for a call.
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.
If it interrupts your running code, it only can happen at moments when you allocate memory, just like with malloc. You cannot predict when malloc calls brk(), either.
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.
With Gargage collection, there are ni deallocations.
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.
Just followed that thread again, and I think we're on the same side :)
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.
I've recently started learning C++ again to get into game programming. Initially I was learning Flash/AS3 based engines, as I used to be quite a great AS2 programmer back in the day.
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
I'm a short while away from releasing a game made in C++/DirectX for Windows 8 (using the DirectXTK helpers and obvious APIs like XAudio2) - i.e. mostly 'from scratch,' more or less.
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].)
Holy crap, that's perfect. Thanks so much! You don't have a refferal link by any chance, I'd love to make sure you get something for a rec like that: i've been looking for something like this for weeks now!
> 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
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.
Hah, you are right. I thought the switch to C++ was in tech5 but nooo. Although there is still a fair bit of straight C in there. Again, link to the relevant Fabien Sanglard architecture review:
He seems to be specifically interested in that, done in C++, while learning C++. The code of the various id games is definitely worth looking at - starting with Fabien Sanglard's code reviews is probably more informative than the raw github dump
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.
Heh, I will, with some effort, resist the urge to debate analogies - my point was: I don't think that, interesting as it is (especially with Sanglard's excellent reviews) is what the threadparent was asking for.
Probably the most common development pattern is the "update loop" or "game loop". Typically game objects are represented by C++ objects. Aside from that, virtually every design pattern in existence is used in the context of games.
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.
If Bjarne had been able to keep C++ his own creation instead of letting the "standards" people come in and take the thing over, C++ might have avoided becoming the over-designed language its become. Anyone recall the differences between [const const {star}], [const {star} const], etc ?
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++.
> If Bjarne had been able to keep C++ his own creation ... C++ might have avoided becoming the over-designed language its become.
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.
Agreed. I recently started working in C++ after spending a lot of time with more traditional web application languages like Ruby, Python and Clojure. It was shocking to see how grotesque and overbuilt the language was compared to the tools I was used to.
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++.
I am currently doing a small performance intensive project in C++, and my take is that C++ has been a good fit for this.
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.)
I recommend anyone using C++ to do this exact thing. It's the sanest way to use it without driving yourself mad when something no longer works because X causes issues with Y.
Any Rubyist or Python developer will be caught off-guard with C++. Dynamically typed languages are intrinsically easier, and languages like Python and Ruby do garbage collection for you, resulting in a lot less work for the developer.
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.
>Dynamically typed languages are intrinsically easier
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.
I'd be hard pressed to name a popular dynamically typed language that does not offer duck typing. Technically there may be a distinction, but it is not one that matters.
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'm not entirely sure I understand your example.
You have a class A, with a member of type B
You want B to have a method which takes an object of type A as a parameter.
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.
Go's "duck typing" is basically Java-style interfaces that don't have to be explicitly declared: if a type has all the properties to fulfill an interface, it automatically fulfills it.
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.
}
In this example, you could use reflection or the unsafe package to call arg.Baz() despite the fact that arg isn't guaranteed to have that method, but it takes some work and you're basically breaking the way the language is meant to be used.
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 duck typing (without losing the compile time type checking) in C++ using templates. Somehow they get a lot of bad press, but for me they're one of the key features of C++.
I've never worked with templates. Do they require you to write the function for use with templates, or can you use templates to pass an object into a function which was designed for another specific type of object.
Based on my limited understanding of compilers, I do not see how you could efficiently implement duck typing without some type of JIT compiling.
They require you to write the function for use with templates; as long as the callee is ready to use templates, you can pass anything that fits the interface needed. Everything is done at compile time.
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".
C++ is the 1980's Lancer with the same frame and same engine and the rest kept up to date with the latest performance tech. Fortunately for it, all the high performance cars which have been built since then can't reuse the same parts which are currently dominating the market.
The problem isn't really the number of people on the committee, but rather the inability to remove and revise features without breaking backwards compatibility.
> 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
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.
Waaa, programming is hard, waaa, I don't want to worry about const correctness of pointers, waaa I don't want to know what pointer is at all, waaaaaa let me keep making my HTML programs in Visual Clojure BASIC.
The particular example of the language could have been done with distinct words, not a single overloaded word that depends on order of placement. More decorator-like, for example.
All he did was reverse the order of the types. Right-to-left parsing really isn't that complicated, and mimicking English grammar is not as good an idea as you think it is.
Because it requires too much typing, especially for something you use all the time. Seriously, the syntax is not that difficult to understand and remember.
Some developers need tools that offer better performance than the languages you enumerated. Not that I have anything against those languages or more abstract languages in general. Quite the contrary, if it was up to me we'd all be writing lisp. Outside of serving as a prototyping tool, a role that Python and Matlab admittedly fill pretty well, I don't believe using Javascript or Ruby or any other (interpreted/high level/more abstract) language would bring much to the problem domain I do most of my work in, realtime computer vision.
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
> I would expect most people to realize that native code still has its place, at least for now.
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.
for the record, const const * is redundant. I think const is only so confusing because you can write it two different ways (char const * vs. const char *); if only the former was allowed, it would seem a lot more logical.
Exactly: if 'int const * ' were common, it would be relatively clear that const goes after the type of the thing that is const - but the overwhelming use of the alternate form, 'const int *', makes it more confusing what to do.
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 like C++, I think I know it reasonably well, I've been programming in C++ full time for the last 10 years.
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.
I think of Stroustrup's book as a reference manual. It is very comprehensive in covering the standard. Fact is that you don't learn to program by reading books any more than you learn to play a sport by reading books.
That is how I've ended up using his book, but what is the appeal of a heavy, printed reference manual? I could only make sense of the idioms and patterns in C++ by reading the Guru of the Week articles at the same time:
Still can't overload the semicolon operator. I asked Stroustrup about this critical feature lack in C++, and he admitted that he simply forgot. Embarrassing!
Yup. The day I discovered "smart" pointers was the day I vowed to never use C++ again. I mean this is a language that touts being close to the metal as an advantage, and then it allows you to create something that looks like a pointer but doesn't fit into the space for a pointer. Genius...
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).
The expected audience for this book are hard-core hackers who work on important systems, are paid accordingly and can probably expense it on their corporate AMEX. So no, I don't think $75 is unreasonable. Maybe you're thinking of "Scala for Social Media Hipsters Trying to Code a Startup on a $10,000 YCombinator budget"
This would really benefit from being an ebook - for years I had the 3rd edition with hanging sheets of errata folded into the back (ahh wait, I still have that edition...) . I'd soo much rather get an email with a note that a new correction was available for download...
I write ANSI C for a living, and I still learn new tricks and insights from the second edition. In fact, many of the neatest ways we use C are things that we learned from references published the 1980s and early 1990s.
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.
It doesn't really "shrink" the language. It adds a level of abstraction. But the problem is that it doesn't really implement the abstraction very well. The complexity doesn't go away, you still have all std::vector<std::ostream::operator<<std::iterator<T><2<std::bla_bla>>>> underneath, and if you make a small error in the code, compiler will still spit out an incomprehensible error message.
C# 2.0/ECMA-334 4th edition [1] is specified on 553 pages - Microsoft did not submit later versions. The underlying virtual machine, the common type system, the assembly language and so on are specified in ECMA-335 6th edition [2] on 574 pages supplemented with 161,593 lines of XML (plus 155 lines DTD) specifying the base class library.
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.
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.