Interviews: Bjarne Stroustrup Answers Your Questions 102
Last week you had a chance to ask Bjarne Stroustrup about programming and C++. Below you'll find his answers to those questions. If you didn't get a chance to ask him a question, or want to clarify something he said, don't forget he's doing a live Google + Q & A today at 12:30pm Eastern.
Cutting features and old syntax? by Katatsumuri
Sometimes well-established languages keep adding new features and syntactic constructs until most developers are not even aware of all the possibilities and use maybe 20% in their usual daily work. The old features and syntax are kept around for compatibility and to keep the old guard content, even if cutting them would lead to faster compilation, more elegant language and less confusion.
This may be part of the reason for the constant introduction of new trendy languages with radically simplified syntax and libraries... Which then follow the same pattern. Few languages are introducing new paradigms, many are trying to be a "better" C++, Java, LISP, JavaScript or Perl.
Do you think this cycle is inevitable, or could it be a good idea to sometimes clean up the syntax and the obscure features in new specification versions, to keep the established languages more competitive?
Bjarne: Languages grow. The alternative is stagnation because there is nothing the maintainer of a large code base hates more than working code breaking – even if that code is full of avoidable errors. We dream of cleaning up the mess, but somehow there is never the month or couple of years needed. I dream of “cleaning up the mess” as much as the next guy, and I know the mess better than most. It is hard to evolve a language compatibly, but IMO it is harder still to make a major – worthwhile – breaking change. Stagnation is not something I can accept – we can and must do better (even if that takes compromises).
You probably didn’t mean that, but “syntax” isn’t the most important aspect of software development. People will suffer atrocious syntax to get valuable functionality (C++ template meta-programming is an example). Also, developers and maintainers of production code eventually tire of cute (often very terse) syntax. “Syntax” is the user-interface for programmers, rather than the system itself. What we hope for is a minimal and logical interface to a useful semantics.
For any reasonable definition of “paradigm” (a words I use only very rarely), there are very few new paradigms coming along, so people have to be happy with incremental changes. Slow steady progress can – over time – add up to major improvements. However, few people take the longer (decades) view.
On the evolution of C++
by stox
How do you feel about the evolution of C++ since it was first implemented with Cfront? What began as a pretty straightforward language has been expanded to significant complexity. Has this evolution been positive, or has it been an attempt to make the language apply to too many possible applications?
Bjarne: C++14 is a far better tool for software development than “C with Classes” was, far more powerful in the key areas that “C with Classes” was invented to deal with. It is more expressive, better checked, generates faster code, and is applicable in areas that “C with Classes” could not touch. The cost has been complexity. My aim has been constant: a direct mapping to hardware plus zero-overhead abstraction. C++ is not the best language for everyone and everything, but then I never promised that it would be. However, C++ is an excellent tool for attacking a vast variety of system design and implementation problems.
I hope that the tide has turned so that C++ is becoming more “novice friendly.” C++11 and C++14 are steps on that route: auto, range-for, lambdas, uniform initialization, concepts, etc., all makes it easier to express simple things simply (without loss of performance). For example, a friend sent me this C++99 code (simplified, of course, but from a large code base):
// old code:
std::vector::const_iterator cit = MemVec.cbegin();
for ( ; cit != v.end(); ++cit) {
if (LookForPatterm(*cit))
return true ;
}
return false;
He deemed this to be somewhat messy and in need of improvement. For starters, we can eliminate the long type name by letting auto deduce it:
// first step:
for (auto cit = MemVec.cbegin(); cit != v.end(); ++cit) {
if (LookForPatterm(*cit))
return true ;
}
return false ;
auto is the oldest C++11 feature. I implemented in in 1983/84, but was forced to remove it for C compatibility reasons. It provides the ability to deduce a type from and initializer; after all, the compiler knows the type of MemVec.cbegin() so why should I need to repeat it? Note how the scope of cit is now limited to its area of use.
We can simplify regular loops using a range-for, so we get:
// second simplification:
for (const auto& x : v)
{
if (LookForPatterm(x))
return true ;
}
return false ;
There is now no iterator, so it cannot be accidentally or deliberately modified in the loop. Now it is obvious that we should have used a standard-library algorithm:
// good:
return find_if(cbegin(v), cend(v), LookForPattern) != v.cend() ;
That’s where my friend stopped, observing that it was now also obvious how to use a lambda as the operation in other places. Being a fan of range/container algorithms, I would have said:
// my variant:
return find_if(v,LookForPattern)!=v.cend();
This involves having a range version of find_if lying around somewhere. For example:
// range version of std::find_if:
template
Iterator find_if(Cont& c, Pred p)
{
return std::find_if(begin(c),end(c),p);
}
Next time such an improvement is needed, I think my friend and his colleagues will jump directly to one of the later variants. With a bit of luck, they will even have tool to help them find candidates for simplification.
Regrets
by Anonymous Coward
What do you regret most in C++ and how would you like to change it?
Bjarne: No regrets! Seriously, a language grows up at a specific time and in a specific environment. To survive that language has to be viable at every stage of its evolution. I’d hate to second guess 1980s vintage Bjarne. He was at least as smart as I am and had a far better grasp of the world at the time. Simply saying, “if I had had a few million dollars for buying market share with ‘free’ libraries or for developing a better definition of templates C++ would have been better” just isn’t intellectually honest.
If I had a time machine, I just might jump back to 1987 and drop a sketch of a design of templates with concepts on Bjarne’s desk. He was working on the template design at the time and knew the problems with template parameter requirements well. Unfortunately, neither he nor anyone else at the time knew how to simultaneously get generality, performance, and well-specified interfaces. Given a bit of help from the time traveler, he might very well have gotten the point. Then, in 1990, we would have been able to write:
void sort(Sortable& c); // sort random-access sequences of elements with
void user(vector& vs, vector>& vc)
{
sort(vs); // OK
sort(vc); // error: vs not Sortable; complex does not have }
However, I don’t have a time machine, so we had to wait until next year (or now if you use the concepts branch of GCC).
Future of C++ Standard Library
by DaphneDiane
One of the recent concerns raised with C++ compared to other popular languages is the breadth of the standard library. I know that the C++ standard committee was looking at adding a C++ transformed version of Cairo to the standard. And of course there is boost. What else do you see coming to address the perceived API shortcomings?
Bjarne: C++ is a formally standardized language. It is defined by the ISO. Compared to other such languages, C++ has a huge and growing standard library. However, compared by commercially owned languages, such as Java and C#, the ISO C++ standard library is tiny. We – the C++ standards committee – do not have the resources to buy market share. The committee is trying to add useful libraries as fast as it can safely do so. The standard library is most important because it creates a common foundation, but it can never be sufficient for the needs of the huge community.
We somehow have to create a better “exchange” for open-source and other libraries. We will also have to work harder on library interoperability. There are a huge number of C++ libraries “out there,” but they tend not to be designed for interoperability and many producers of libraries have their very own programming styles and specialized assumptions.
To speed up standardization – especially the standardization of libraries – the ISO C++ standards committee has started “study groups” producing “technical specifications.” A technical specification is not a full-blown international standard, but it is a document produced by the order of 20 people and approved by the full committee. Current library TSs in progress are:
File system
Library foundation (e.g., optional and string_view)
Ranges (for people tired of saying v.begin(),v.end() and much, much more)
Concurrency (threads, etc.)
Parallelism (parallel algorithms, networking, and more)
Numerics (incl. SIMD)
Transactional Memory (has core language parts)
I/O (incl. 2D graphics)
See here for details.
ABI
by gbjbaanb
Do you think that one thing holding C++ back is the lack of a standardized binary interface?
Currently if I want to make a module that can be consumed by others (whether than is others using a different language, or a different C++ compiler, or even just to use a pre-built module without sources) I have to export everything as C and use its (de-facto if nothing else) binary standard.
I think an ABI for C++ would increase its "real world" attractiveness considerably with little, if any, overhead. Do you agree, or are there issues around this that make it a significant challenge (apart from vendor adoption of course).
Bjarne: A C++ ABI would be a huge boon to the C++ community, however, it is not an easy problem to solve technically and most C++ implementation providers have a huge user bases that would howl in outrage if binary compatibility with their previous version was broken.
To solve the technical problem, we would need the ABI to cover basic object layout (easy), class hierarchies (not hard), and abstractions using templates (hard). An ABI that could not handle std::vector, std::map, and similar user-supplied abstractions would be a failure. I do not (in any detail) know how to do that.
To solve the political problem, we would need all vendors on a platform to adopt that ABI (probably impossible except in the longer term) or provide it as an “exchange format” in addition to their traditional ABI.
Which feature would you add to C++?
by jonwil
If you could add one feature to C++ (either the language or the standard library) and have it adopted in the C++ standard and supported by all the compilers etc., what would it be and why?
Bjarne: Ah! Just one feature? You must be kidding, but I’ll say “concepts.” They will change the way people think of generic programming and of programming in general, and we’ll have them next year. They are already shipping in a branch of GCC and will be an ISO C++ TS (Technical Specification) in 2015 (I hope and expect).
People have mentioned more standard libraries and a standard ABI. I’d like to see higher-level concurrency models –the type-safe C++11 threads and locks are still too low level. I’d like to eliminate the need for the visitor pattern workaround; for example, see:
Y. Solodkyy, G. Dos Reis and B. Stroustrup: Open Pattern Matching for C++. ACM GPCE'13.
Y. Solodkyy, G. Dos Reis, and B. Stroustrup: Open and Efficient Type Switch for C++. Proc. OOPSLA'12.
P. Pirkelbauer, Y. Solodkyy, and B. Stroustrup: Open Multi-Methods for C++. ACM GPCE’07.
Remember that an academic paper plus an implementation does not add up to a complete standards proposal, but wouldn’t you like to be able to write:
bool intersect(virtual Shape&, virtual Shape&); // non-member virtual function
void user(Shape& s1, Shape& s2)
{
if (intersect(s1,s2)) //
//
}
Assuming suitable overloads of intersect() to handle Shapes that are Circles, Triangles, etc. The alternative today is a mess of if-statements, some clever special-purpose workaround, or an elaborate visitor setup.
C++ without the C
by kthreadd
Apple recently introduced a language they call Swift or Objective-C without the C. It is technically a completely different language from Objective-C though. When C++ started out it had the major benefit that it was (mostly) compatible with C which at the time was immensely popular, making it trivial to mix new C++ code with existing C code. Today C is still a popular language but not as widely used as it once was. Assuming that C++ could drop C compatibility, how would you take that opportunity to improve C++?
Bjarne: People tend to underestimate C. Today, we probably don’t need C compatibility (except to keep billions of lines of critical code running), but we do need a direct map to hardware. If we didn’t have C or the C-level subset of C++, we would have to find a different way to do that map. Languages without C’s problems typically rely on C or C++ to do their dirty work for them.
I think we should think more about isolating unsafe code in a program than to eliminate it. Putting the necessary unsafe code into a different language limits our control of it, limits what can be communicated to it, and typically imposes overheads.
That said, when people rail against C, and by implication C++, they usually (and correctly in case of C and C-style C++) point to two problems: lack of type safety and the lack of abstraction mechanisms. Together, those two problems leave people with lots and lots of low-level code in which bugs can hide (e.g., buffer overflows, invalid pointers, and resource leaks).
C++ attacks these problems by providing alternatives. You can write type-safe code in C++; you can write simple code that doesn’t leak or leave invalid pointers behind; you can do so with zero overhead compared to lower-level alternatives. Consider:
vector collect(const string& terminator)
{
vector res;
for (string s; cin>>s && s!=terminator; )
res.push_back(s);
return res;
}
void user() { auto ss = collect("end"); // ss is a vector
// }
I used C++11’s move semantics and auto to simplify that code. Note the absence of memory management code and the absence of leaks. Returning containers by value is simple and efficient in C++11 because the standard library provide move constructors for all containers, such as vector.
The problem is that many people don’t write such simple code and are stuck with the old problems hidden in lots of far more complicated code.
I don’t actually think that there is less C and C++ programming these days. I think that in absolute terms there is more than ever, and not just people working on “legacy code.” People are confused by unscientific estimates of usage and especially by the fact that there is much more software development these days, so that the amount of C and C++ is declining relative to the total. In particular, I think I see significant growth of C++ in its core domains. The number of C++ programmers today is more likely to be 4 or 5 million than the 3 million I estimated ten years ago. But it is hard to count programmers.
Hour of Code
by Orestesx
What is your opinion of the "Hour of Code" as promoted by CSEdWeek? Does it trivialize computer science education?
Bjarne: I guess that anything that popularizes hands-on software development experience is good. On that count, I’m in favor of Lego, programming contests, Raspberry Pie, etc. Too many people think science and (especially) engineering boring.
Do color change and explosive chemistry experiments trivialize chemistry? Do demonstrations of Newton’s cradle and prisms trivialize physics? No! You need to inspire and motivate students in preparation for the necessary hard work. I think Computer Science should be taught as a serious academic discipline – like Physics and Biology – for which years of work is needed for mastery, rather than as a basic skill that must be quickly mastered by all. I think the serious work should start in high school, like it is (or IMO should be) for mathematics, physics, and biology. It is not just child’s play. It could start in university if it wasn’t that students tend not to choose fields of study in university that they have not encountered in high school.
Not everybody can become a good programmer. The world needs a lot of programmers, maybe 20 million, but we don’t need a billion. We need to distinguish between the education of professionals and giving people a bit of computer literacy. People seem confused about this or unwilling to accept that serious preparation is needed for people who build serious software. Our lives and livelihood depends on software. Just think of the amount of computing that goes into delivering your food to your table: agriculture, transport, telecommunications, embedded systems, planning, scheduling, etc. You cannot milk a herd of cows without the help of computers these days! Or at least you cannot if you have to keep records of the cows’ health and production for the obligatory quality control. I would strongly prefer for critical software to be developed and maintained by professionals. I’m less concerned about the quality of your favorite videogame or the advertisements that pop up to annoy me when I try to read the news.
I’m more interested in the engineering part of computer science than the pure science part. Computer science is among other things a set of science-based practical skills, an engineering discipline.
Personal programming projects
by kthreadd
Apart from work, do you have any personal programming projects going on? Which type of programming do you like most and is there a particular project that you would like to implement?
Bjarne: I tend to look at three kinds of code: code that creates trouble in the context of the C++ standard (subtle cases and proposals), small experiments with programming techniques, and production code. This implies looking on a lot of libraries and writing lots of small examples. Unfortunately, my “day job” plus my standards work do not leave time for significant personal projects.
Code rejuvenation
by SansEverything
You speak a lot about code rejuvenation and bringing old code to new standards. As you are working on C++14, many compilers do not fully support C++11 yet. In the past, it was even worse. Don't you think that this lack of feature support from compilers is a major problem and the biggest obstacle to code rejuvenation?
Bjarne: No. C++11 and/or C++14 implementation availability is not a major problem. Both are getting remedied fast, faster than I would have believed a couple of years ago. The adoption of C++11 is far faster than the C++98 adoption was. Waiting a year or two is not a significant problem in this context. There is plenty of work that can be done today.
When I talk about “rejuvenation” (some people call it “modernization” or “upgrading”), I mean rewriting large amounts of code written in styles known to complicate comprehension, hide bugs, and hinder optimization. I’m thinking of C-style code, code overusing class hierarchies, and some examples of complex template metaprogramming. Such code also tend to prevent newer, better, and simpler techniques to be used in newer code. The reason is partly that the need interoperate with such code messes up new code, partly that programmers steeped in the old style are reluctant to believe that the newer techniques work.
For example, I’d like to replace uses of arrays and pointers with std::arrays and vectors. I’d like to eliminate macros. I’d like to replace old-style for loops with range-for loops. I’d like to eliminate overuse of free store (heap). I’d like to break up large functions into smaller and more precisely defined ones. I’d like to replace ad hoc code with algorithms. I’d like to replace hand-crafted containers with standard-library ones. If I can, I’d like to eliminate race conditions and increase the amount of concurrency. I want to do all that without adding run-time overheads.
Typically, we cannot afford to rewrite the old code by hand. So when I talk about rejuvenation, I focus on (static) code analysis and code transformation: we must automate the rejuvenation process as far as possible. The reason I don’t refer to this as “refactoring” is that I’m typically not interested in a process that produces 100% compatible code. Some of the transformations I want require human attention. I want major improvement, not bug compatibility. People are working to produce such tools.
SoylentNews (Score:-1, Offtopic)
Is www.soylentnews.org better than beta.slashdot.org?
Re:SoylentNews (Score:-1)
Does beta need to be worse for soylnetnews to be better?
auto_ptr (Score:0)
Who was responsible for std::auto_ptr, and what dungeon is he rotting away in?
Re:auto_ptr (Score:0)
Oh yeah (Score:0)
Bjarne is awesome.
C++ is useful.
Nuttin' more to say.
Re:Oh yeah (Score:2)
I really like the new stuff, makes me almost want to start coding C++ again.
Re:Oh yeah (Score:3)
Re:Oh yeah (Score:4, Interesting)
I ran into an issue not too long ago with a custom stateless unique_ptr deleter, when one of the interfaces I derived from (in a third party library) was placed ahead of my own interface class in the derived class declaration. My own interface had a virtual destructor, while the library interface did not (which I didn't notice at the time). The deleter was blowing up, and only after I noticed it was off by one was I able to figure out why it was happening: the code was unable to cast properly, so ended up at the wrong address in memory because of the v-table layout.
This was fixed by switching the order of the two interfaces which corrected the in-memory layout so it would work. Alternatively, a shared_ptr would have worked as well, albeit with unnecessary extra overhead in that case. It's not exactly a new gotcha, but the unique_ptr + deleter put enough of a new wrinkle on it to throw me off for a while.
C++ gives you a lot of power and speed, but it definitely comes at a price in terms of issues like this. No one who knows C++ would seriously claim the language doesn't have sharp edges that still trip up full-time professional C++ programmers. Still, I love the power and speed the language gives me, while still affording me protection from the sort of mistakes that crop up in C code. For me, C++11 has been an amazing win so far in terms of overall productivity and code safety.
Re:Oh yeah (Score:0)
> the code was unable to cast properly,
Did you have a C-style cast in the code somewhere?
As far as I know, these kinds of problems can be avoided by strictly never using C-style casts, and by never typing `delete` (or `new`) in your code, in order that we have to delegate these tasks to unique_ptr and its friends.
> No one who knows C++ would seriously claim the language doesn't have sharp edges that still trip up full-time professional C++ programmers.
I agree, but I'll play Devil's Advocate. I think there is a well-defined subset of C++ that is quite well-behaved, but it still recognizably C++ and is still very useful. C-style casts and C-style arrays have better alternatives and could be banned by a modern C++ compiler to help create better programmers. Most (all?) uses of raw pointers could perhaps be banned too
Re:Oh yeah (Score:0)
Fresh out. Only fresh outs are afraid of pointers. Only fresh outs say 'better' when they mean 'easier for me'. Yes, pointers carry risk, but so does your simple, constrained language that doesn't support them. Same goes for casts. I mean really. Is this what Slashdot has come to? A bunch of fresh outs afraid to code, asking Bjarne how to 'make it easier'? You deserve all the defects you'll create from ignorance.
Re:Oh yeah (Score:0)
> Fresh out.
> Is this what Slashdot has come to? A bunch of fresh outs afraid to code
I was commenting on Slashdot 15 years ago when I was just out of college. I've been coding the entire time since. Your dickhead comment reminds me why I don't miss Slashdot.
I'll never apologise to you for wanting to deprecate raw pointers. In fact, if you look at what people like Bjarne (he's more experienced than both of us, no doubt) are doing with the language, you'll notice that it is they (not me) who are gradually removing pointers from the language
Re:Oh yeah (Score:2)
No C-style casts or any explicit casts were involved at all in this particular case. I've long since stopped that sort of dangerous style of programming and adopted a much saner and safer subset of C++ unless there's no alternative.
Disabling "unsafe" features might be useful for some, but not in my case. In my particular field (videogame programming), we often have to interop with older C-style libraries, or write some very specific low-level optimizations down in the engine for maximum performance. For instance, nearly all AAA games that I've worked on completely replace the default memory manager, which is why I was using custom deleters. When you write your own memory allocator, you obviously have to do a lot of raw pointer manipulation and unsafe casting.
Honestly, it's probably better to simply develop a personal or corporate coding standard and make sure it's followed. That way, if there's a legitimate need to "break the rules", you can do so, but only if there's no realistic alternative. That's part of what makes C++ so useful. It's a very pragmatic language.
Re:Oh yeah (Score:0)
I had forgotten that there are implicit casts in the language that can cause the same problem. For example, if you call a function that takes a NonVirtualBase * and you pass in a VirtualDerived * and then delete inside that function then you will get the off-by-one explosion you talked about. I would like to change things such that raw pointers where un-delete-able.
new should not return a raw pointer, it should return a deletable pointer. This type would easily convert to, but not from, an undeletable pointer. This would make it easier to ensure that delete is called on the correct form of the pointer. To do this in C++ as it is now, you could simply ban direct calls to new and delete in your coding standard, and create two helper functions of your own that return and take deleteable. The developer could "break the rules" with explicit casts, for example deletable would have a method ::dangerous_explicit_cast_may_be_off_by_one. The main purpose of my idea here is to stop implicit casts accidentally making their way to delete
Shame (Score:4, Insightful)
Re:Shame (Score:-1, Troll)
The problem you! (Score:5, Funny)
The problem you! Real programming is hard, and requires real languages and real programmings. Fire bad! You stupid! You no good programmer! I smart!
Re:Shame (Score:3)
he admits the rough edges already, and has improved the language.
(no not a c++ fan, suffered much with it at job)
Re:Shame (Score:1)
Shame a few of the questions are trying to guilt trip him into saying C++ was a mistake.
"Shame"?
Shame on who? To those that believe that C++ WAS a mistake or to mister Bjarne who tries to imply with those "buying market share" statements that Java/C# don't deserve their success?
Re:Shame (Score:-1)
Re:Shame (Score:0)
Why go with c language when you could go with Assembly Language or 11110101 machine language?
Re:Shame (Score:2)
Re:Shame (Score:0, Troll)
How is that deprecated auto_ptr working out for you?
C++ has become a complete cluster fuck of over-engineering. The lambda syntax is hideous. Hell even Javascript makes it easy to declare anonymous functions!
An honest person wouldn't be afraid to admit that.
Re:Shame (Score:3)
How is that deprecated auto_ptr working out for you?
Er huh? Old code using it still works does it not? Now you get a warning if you use it. I imagine you will have something approaching infinite time to remove it after you upgrade your compiler.
So it's fine. No problem in fact. I'm not sure what your point is?
The lambda syntax is hideous. Hell even Javascript makes it easy to declare anonymous functions!
Hideous is in the eye of the beholder, but hard to create anonymous functions in C++, it is not.
[&](auto x){ do something with x};
If you think that's hard, you should seriously consider another career.
An honest person wouldn't be afraid to admit that.
Where has he been dishonest? He's always admitted C++ has flaws. An HONEST person wouldn't cast false accusations.
Re:Shame (Score:3)
C++ is over engineered: for standard library authors. When you're not writing general purpose libraries, you don't use most of the over-engineered stuff and you would be fine. However when you want to write generic libraries that are highly performant, you'd be glad it makes it possible to express in a high level what low level semantics should be. I would rather over engineer than be forced to write boilerplate code because the library author has no facilities to express requirements through their API. In short, C++ gives you Qt. C gives you Gtk. Gtk is a greater clusterfuck of over-engineering made all the more worse by the fact that it cannot hide its complexity from its API clients.
Javascript syntax makes it easy to declare anonymous functions because it's a pass-by-reference language. You can write them easy, but they'll be very slow if you want to do anything complicated and/or in a loop. If you want performance, you need to pass by value (or have move semantics) but for most simple lambda cases you would want to use, the syntax is pretty easy and actually looks like declaring a function in the middle of a function.
If you can't get over a little syntax weirdness, you shouldn't be programming. If you don't like learning something new, you shouldn't be programming. If you don't want to consider performance (speed AND power consumption), you shouldn't be programming.
Re:Shame (Score:2)
You can write them easy, but they'll be very slow if you want to do anything complicated and/or in a loop.
Unless they get inlined, type-specialized, yada yada yada...
Re:Shame (Score:2)
Re:Shame (Score:2)
Re:Shame (Score:2)
Re:Shame (Score:2)
Re:Shame (Score:2)
Re:Shame (Score:2)
No, because in Java you declare variables to have types.
But if those types are not final, you don't know the dynamic subtype of concrete values (and the concrete methods to call) in advance, and you're forced to do the same kinds of optimizations that Javascript does. Seriously, look at current VM tech again. Type feedback and speculative inlining are of legal drinking age in the US by now.
Re:Shame (Score:2)
Re:Shame (Score:2)
That wouldn't be (good) C++ code, since C++ has inheritance and so faces the exact same problem.
But the real problem with "var" types is that the compiler can't check type safety for you, so you get a whole new class of bugs at runtime. Why not go the Haskell way: the compiler inferes type information where it can, you provide it where it can't, and you can optionally provide it where ever you want? That gives you the best of all worlds: short "script" programs are fast and easy to write, all functions and data structures are generic by default, and the whole program has run-time type safety?
Re:Shame (Score:2)
I've been spending a lot of time in C++11 and I can tell you short script programs are almost as easy as python to write. The only thing lacking is standard library support for networking, graphics and databases. C++11 does have type inference now, which is one of the reasons why it's now faster to write C++ than ever before. Actually, C++ has had type inference when templates were introduced, but it just wasn't available outside of templates like auto does now.
Re:Shame (Score:0)
Qt is not C++ code, it's Meta-Object Compiler code, where MOC is C++ with additional facilities (SIGNAL/SLOT) which, as gtkmm has proven, do not need to exist.
Re:Shame (Score:2)
Re:Shame (Score:0)
Because C++ is the only language that deprecates features.
Python, for one.
Re:Shame (Score:0)
Re:Shame (Score:1)
Considering I am a rendering/optimization/UI expert working for a Fortune 50 company on R&D you tell me?
Without janitors to keep the place clean people would get sick. Everybody has their role to do a company -- no one is more important, or less important, for a company to function properly and efficiently.
Pro-Tip: Using an ad hominem [wikipedia.org] just makes oneself look like a complete tool.
Here is some free advice:
"Better to remain silent and thought a fool then to open your mouth and remove all doubt."
Now if you have something constructive to add to the discussion ...
Re:Shame (Score:0)
From the troll that has nothing constructive to add to a conversation about C++.
Pot, get your head out of the kettle's ass.
Re:Shame (Score:3)
You probably didn’t mean that, but “syntax” isn’t the most important aspect of software development. People will suffer atrocious syntax to get valuable functionality (C++ template meta-programming is an example). Also, developers and maintainers of production code eventually tire of cute (often very terse) syntax.
[to change how people use C++] I’d like to replace uses of arrays and pointers with std::arrays and vectors. I’d like to eliminate macros. I’d like to replace old-style for loops with range-for loops. I’d like to eliminate overuse of free store (heap). I’d like to break up large functions into smaller and more precisely defined ones. I’d like to replace ad hoc code with algorithms.
Not everybody can become a good programmer. The world needs a lot of programmers, maybe 20 million, but we don’t need a billion. We need to distinguish between the education of professionals and giving people a bit of computer literacy.
Languages without C’s problems typically rely on C or C++ to do their dirty work for them. I think we should think more about isolating unsafe code in a program than to eliminate it.
My aim has been constant: a direct mapping to hardware plus zero-overhead abstraction.....I hope that the tide has turned so that C++ is becoming more “novice friendly.”
Re:Shame (Score:2)
Re:Shame (Score:0)
Personally, it doesn't matter to me. I don't take what this guy says seriously. Bjarne Stroustrup doesn't have a clue about C++.
Do You Need A Loan, Apply Now (Score:-1, Offtopic)
Please fix up the HTML (Score:2, Insightful)
There are obvously characters in the post that didn't appear properly.
1980 called, and they want their HTML markup problems back.
Re:Please fix up the HTML (Score:3)
The problem is that Slashdot is stuck in 1840 and doesn't support UTF-8 like the rest of the planet.
Re:Please fix up the HTML (Score:1)
I don't think its a UTF-8 problem, more likely simply inability to parse '' characters properly.
But lack of UTF-8 is still a problem of course.
Re:Please fix up the HTML (Score:2)
Re:Please fix up the HTML (Score:0)
Ok, I exaggerated by a few years. But only a few, I certainly used the web in 1992, and it was by then already fairly well established in academic circles. Although it was probably 1995 by the time the individual departments were setting up homepages, and it would have been later than that before the university got a homepage (I think, I'm not too sure, but the university homepage wouldn't have contained any useful information back then so I wouldn't have noticed it).
Questions we forgot to ask (Score:0)
1. Do you expect that we'll ever see a successful general purpose OS kernel written almost entirely in C++?
2. How does the D programming language stack up against C++?
3. How does Objective C stack up (technically) against C++?
4. Do you think there is an outer limit (say, in terms of LOC) to the scalability of a C++ codebase, before higher level languages need to be considered?
Re:Questions we forgot to ask (Score:2)
4. I would say look at Qt. You can write pretty complicated graphical applications in fewer lines.
Re:Questions we forgot to ask (Score:1)
Easy it would be called BeOS, Symbian, Genode, Windows 9 maybe (if the kernel transition to compile with C++ is already done) ...
Good questions - interesting answers (Score:5, Insightful)
From someone in the trenches using C++, I can definitely tell you that C++ 11/14 has made a massive difference, along with the adoption of better programming practices that have occasionally been eschewed by game programmers because of speed concerns. I describe the new C++ as feeling like C#, except with far uglier syntax. It's fantastic to be able to almost completely eschew the use of raw pointers (at least ones which I have to use to manage memory). It almost feels like the language has garbage collection, except that RAII + smart pointers work wonderfully on resources as well as memory.
I've been working in what is essentially a version of C++ 98-compatible style for nearly my entire programming career. Modern hardware has really reached a point where game developers can effectively take advantage of some of the real advantages of modern C++. It's remarkable how much more productive you can be when you're not worrying about having to carefully manage memory, tracking down a ref-counted leak, or (worst of all) spending hours or even days searching for some memory stomp.
Best of all, a some of the newer features don't even require a significant amount of overhead, but really just put more work on the compiler instead of the programmer. And there are ways to mitigate some of the downsides of ubiquitous RAII-type design (the cost of creating lots of small object), though custom memory managers optimized for those sorts of scenarios.
I have to say, I agree with Bjarne's answers, especially his answer to the notion of dropping compatibility with older features. While it does make the language more complex to keep that cruft around, it's equally important to allow programmers to wrap up older libraries with newer interfaces, for example, and make sure the codebase still compiles cleanly. Since I started out on my own just a year and a half ago, I had the advantage of starting my game codebase from scratch, so I could use the most modern techniques, but I've worked at places with 10 to 15 year old codebases. There's just no way all of that is going to get rewritten in the near future, so backward compatibility is hugely important for the C++ community.
Overall, C++ gets a lot of grief for it's ugly syntax and nasty gotchas, but modern techniques have really eliminated a huge percentage of those. Personally, I tend to view C++ like an extremely sharp kitchen knife. It can be a dangerous tool for novices, and you certainly don't want to use it when a butter knife will do, but there are some jobs that simply demand it.
Re:Good questions - interesting answers (Score:0)
While it does make the language more complex to keep that cruft around, it's equally important to allow programmers to wrap up older libraries with newer interfaces, for example, and make sure the codebase still compiles cleanly.
The interview left me wondering if compiler warnings wouldn't be the way to go about that deprecation. That is, those old legacy features are still around, but raise a compiler warning. That way they're flagged and identified (and hopefully removed), but are still available to legacy code.
That would require compiler warnings to get more of an official status, though. I could certainly be wrong, but I don't think the C++ standard currently sets up any structure regarding warnings, either in their generation or their control. If you wanted to address the issue through warnings you would need some sort of standardization, at the very least to be able to label legacy code in a standard fashion to say "Yes, I know it's crufty - I'm keeping it that way for reasons/I don't have time to fix it, don't bother me about it." Right now turning off warnings is horribly compiler-specific.
Re:Good questions - interesting answers (Score:2)
Re:Good questions - interesting answers (Score:1)
Re:Good questions - interesting answers (Score:0)
Maybe that's the problem? Can't we have the power of the sharp kitchen knife without the four years of training from Tibetan monks? We can. I've been using http://nimrod-lang.org even for what I used to write throwaway python scripts, but I write "serious" software with it too without problems. I chuckle when people learn about Nimrod and say "well, it's just a better C++". As if that wasn't enough given C++'s sorry state. Plus you can use it along C++ without problems, so there is no effective migration trouble other than willing to improve by rewriting small/new parts of existing codebases leaving the well tested foundation in C++.
But seriously, look ahead, there are nicer things in the future than C++, the newer standards are only good if you are shackled to C++ for some external reason.
Re:Good questions - interesting answers (Score:2)
Re:Good questions - interesting answers (Score:2)
Maybe that's the problem? Can't we have the power of the sharp kitchen knife without the four years of training from Tibetan monks?
Sure. What we can't have is the power of the sharp kitchen knife, plus the compatibility with existing code and libraries without the four years of training.
I can teach a novice to use a nice, pleasant, safe and very powerful subset of modern C++ in a fairly short period of time... as long as the novice is only working on code written in that subset. If the novice starts looking at and modifying other code, though, all bets are off until he's done his years on the mountain top.
The way I see it, C++14 is a very nice language with a bunch of baggage you should just ignore... except when you have to use because you're working with code that already does. This means given a clean, modern codebase you should be able to hire a bunch of smart novices and get them productive fairly quickly. Just keep an old salt around who can answer their questions when they step outside of the nice subset.
Re:Good questions - interesting answers (Score:2)
Is there some reason you couldn't do backwards compatibility the same way every other data format does: just provide a version number so the compiler knows what you're trying to say?
Oh darn I forgot to ask... (Score:0)
...how the hell you say that guy's name.
Re:Oh darn I forgot to ask... (Score:2)
Re:Oh darn I forgot to ask... (Score:1)
Re:Oh darn I forgot to ask... (Score:2)
Re:Oh darn I forgot to ask... (Score:0)
That's a nice name you got there, Mr. Aino-nyme-us Coward. It would be a shame if somebody was to mispronounce it.
Re:Oh darn I forgot to ask... (Score:2)
...how the hell you say that guy's name.
Roughly "B-yarn-uh Straw-strop".
Re:Oh darn I forgot to ask... (Score:1)
http://www.stroustrup.com/bs_f... [stroustrup.com]
Just scroll down to after the links at the top and you even got a sound-file with it! :)
Oh darn I forgot to ask... (Score:0)
...how the hell you say that guy's name.
How to pronounce his name is his most frequently asked question:
http://www.stroustrup.com/bs_faq.html#pronounce
The Compiler Knows... (Score:1)
auto... the compiler knows the type of MemVec.cbegin() so why should I need to repeat it?
You're not repeating it; rather, you're specifying it.
Specifying the type is establishing a contract for the following code. This can be very worthwhile.
Note how the scope of cit is now limited to its area of use.
Of course, you could have achieved the same by declaring the variable inside the for-loop; keep things looking simple via a local typedef outside the for-loop:
typedef std::vector::const_iterator CIT;
for (CIT cit = MemVec.cbegin(); cit != v.end(); ++cit) {
if (LookForPatterm(*cit))
return true;
}
return false;
Re:The Compiler Knows... (Score:2)
Re:The Compiler Knows... (Score:0)
It can be worthwhile to specify the type again, but in the case of iterators it is not valuable at all, which is why auto was introduced. Which part of that is difficult to grasp?
Re:The Compiler Knows... (Score:2)
There's no "again" about it.
Which part of that is difficult to grasp?
Re:The Compiler Knows... (Score:2)
Re:The Compiler Knows... (Score:2)
That's begging the question; that's assuming the contract; that's the "programming by [implicit] convention" that plagues dynamic typing.
That is to say, such informal programming tends to be practical in these cases, but don't confuse that practicality with correctness.
Re:The Compiler Knows... (Score:2)
Re:The Compiler Knows... (Score:2)
See here [slashdot.org].
Re:The Compiler Knows... (Score:2)
You're entirely missing the point while getting hung up on 'repeating'.
Why should I have to write something like this:
A lot of the time, as in your example, you don't even care what the type is. You're just looking for a thing in a thing container.
Re:The Compiler Knows... (Score:2)
I've already covered this.
As an aside, you should have already abstracted away the details of that type-specifier via at least a typedef. In other words, your argument is a straw man.
Re:The Compiler Knows... (Score:1)
Specifying the type is establishing a contract
Except that you can't do this with c++ iterators or rather the contract you specify will be the same contract specified by cbegin(), object slicing makes it a very bad idea to specify a type that does not correspond directly to the return value - hence the redundancy of it. You can't even argue readability since returning anything other than an iterator from cbegin() is a gigantic misdesign, however it would be wrong to expect sane design from someone still using a notation similar to Hungarian notation MemVec even its inventor claimed that anyone using it got the wrong idea, you don't encode the c++ class in the var name, you encode its purpose.
Re:The Compiler Knows... (Score:0)
Re:The Compiler Knows... (Score:3)
returning anything other than an iterator from cbegin() is a gigantic misdesign
That's precisely the point, now isn't it...
You are begging the question; you are assuming the contract; you are programming by [implicit] convention—that which plagues dynamic typing.
That is to say, such informal programming tends to be practical in these cases, but don't confuse that practicality with correctness.
Re:The Compiler Knows... (Score:-1)
Re:The Compiler Knows... (Score:0)
Thanks for your answers (Score:1)
Editing (Score:0)
I'll take "Common Problems from 1995" for 1000, Alex
Characters after a common math relation, or inside template parameters for C++ often vanish because of this?
What is: ignorance of HTML escape functions?
You are correct! Please pick again.
Ah yes, for that we have D (Score:3)
Not to be a fanboy, but: a lot of this stuff makes me think "Ah yes, that's why we have D".
We dream of cleaning up the mess
Yep. D is pleasantly free of the mess.
a direct mapping to hardware plus zero-overhead abstraction
Here, D and C++ differ somewhat. D isn't totally unusable without its trusty garbage-collector, but it's not something that's often done.
Being a fan of range/container algorithms
Andrei Alexandrescu agrees. [zao.se] See [informit.com] also [reddit.com] these [digitalmars.com].
Ranges are a standard thing in D.
I think we should think more about isolating unsafe code in a program than to eliminate it. Putting the necessary unsafe code into a different language limits our control of it, limits what can be communicated to it, and typically imposes overheads.
Precisely why D has a safe subset [dlang.org] and the @safe and @trusted attributes.
Of course, D doesn't have compatibility with old C++ code, or even with old D code (that's why there's the ancient-but-stable D 1.0 language).
Re:Ah yes, for that we have D (Score:5, Insightful)
D sounds like a neat language that I'll probably never be able to use. I'm a game developer, and C++ has a native compiler for every machine I would ever need my code to run on, as well as an already mature ecosystem (engines, code libraries, sample code, all in C++). In fact, C/C++ is pretty much the only option I have if I want my code to be broadly portable.
It's interesting how a lot of languages don't seem worry too much about backward compatibility, because they want to focus on a clean and better language. Unfortunately, in the real world, there are always massive amounts of legacy code that need to continue to work alongside whatever new whizbang features are introduced, even at the expense of a cleaner or more elegant language.
If I had to give any one reason for C++'s success, it would be the standards committee's stubborn (and in hindsight, wise) refusal to "clean up" the language by removing crufty features and syntax, a lot of which were leftover from C. C++ code from 20 years ago still compiles today mostly unchanged, and that's incredibly important when trying to build up or maintain a large ecosystem. You can see what a huge split it causes in the community when a language breaks compatibility like Python did (2.x vs 3.x), and ultimately, I wonder if it's more damaging than C++'s more conservative approach. As a developer, I'd be hesitant to heavily invest in a language that is more likely to break compatibility and leave me stranded.
Re:Ah yes, for that we have D (Score:2)
I'm not the GP, but I thought I'd bite.
tldr; It's not perfect, but it's closer than you'd think.
D sounds like a neat language that I'll probably never be able to use. I'm a game developer, and C++ has a native compiler for every machine I would ever need my code to run on
DMD, LDC and GDC (the 3 most popular D compilers) work fine on x86 and x86_64.
LDC supports ARM and PowerPC with some issues. GDC apparently has better support for ARM
as well as an already mature ecosystem (engines, code libraries, sample code, all in C++).
D has very good interop support for C and C++ libraries. There's a significant number of wrapper libraries in dub as well.
In general, C code can be used as is, while C++ libraries often need a wrapper to work around issues like templates.
In fact, C/C++ is pretty much the only option I have if I want my code to be broadly portable.
Yes, C compilers exist for pretty much every architecture in existence, with C++ supported on most of them.
But this is a red herring, because the only instruction sets that really matter to someone in game development are x86, x86_64 and ARM. Whether or not you can compile your code for PIC is completely irrelevant. (That said, LDC uses LLVM for its backend, so it probably has the best chance of supporting unusual architectures.)
It's interesting how a lot of languages don't seem worry too much about backward compatibility, because they want to focus on a clean and better language. Unfortunately, in the real world, there are always massive amounts of legacy code that need to continue to work alongside whatever new whizbang features are introduced, even at the expense of a cleaner or more elegant language.
If I had to give any one reason for C++'s success, it would be the standards committee's stubborn (and in hindsight, wise) refusal to "clean up" the language by removing crufty features and syntax, a lot of which were leftover from C. C++ code from 20 years ago still compiles today mostly unchanged, and that's incredibly important when trying to build up or maintain a large ecosystem. You can see what a huge split it causes in the community when a language breaks compatibility like Python did (2.x vs 3.x), and ultimately, I wonder if it's more damaging than C++'s more conservative approach. As a developer, I'd be hesitant to heavily invest in a language that is more likely to break compatibility and leave me stranded.
Backward compatibility is always an issue with any piece of software. That said, I think there's something to be said for handling breaking changes well as opposed to handling them poorly - anything which creates a rift in the community is obviously an example of the latter.
Python was an example of the that, since it wasn't possible to combine code from old and new versions. While D had a breaking change with D2, there is only one person I am aware of who is still using D1. The standard library from D1 (Tango) was ported to D2, and the syntactic changes were fairly minor and easily remedied.
It's also worth noting that the D1 branch of DMD is still maintained, should you actually need to compile D1 code.
Pretty much every language is going to accumulate cruft over time. Even if D accumulates it at the same rate C++ did, it's relative youth means that it will be much more pleasant to work with, since C++ will always have more. I think the only real way to completely remove all that cruft is to create an entirely new language - no one would have complained about Python 3 if it were marketed as a new language, rather than as a new version with breaking changes (Nimrod is an example of this). This is what D is to C++ - a language with equivalent power that wipes the slate clean.
Re:Ah yes, for that we have D (Score:2)
As a developer, I'd be hesitant to heavily invest in a language that is more likely to break compatibility and leave me stranded.
Well said. Nothing worse than having to rewrite a bunch of solid code, just because someone thought it wasn't elegant.
Re:Ah yes, for that we have D (Score:2)
Gotta love those disclaimer headers that are essentially outright lies.
"Not to be rude but...."
"Not that I'm bragging, but..."
"I don't mean to crtiticize, but.."
Re:Ah yes, for that we have D (Score:0, Troll)
"I'm not a racist, but..."
Re:Ah yes, for that we have D (Score:0)
Re:Ah yes, for that we have D (Score:2)
Laziness.
Me qualifying my comment with a nod to that I'm about to discuss a non-C++ language doesn't, in itself, make me an irrational zealot.
I even pointed out that C++ beats D if you're after a "zero-cost abstractions only" language. I had hoped that would be enough to prevent your sort of waste-of-space comment.
I do all my real programming work in C++, by the way. That's mostly because C++ is a more mainstream language than D, but the superior integration with C code is also nice, as is the far superior tooling.
ABI (Score:2)
Well, I'm slightly disappointed he side-stepped the issue of an ABI as I think its probably the most unglamourous but most essential aspects of a platform. Its not a cool language feature, but for big software comprising lots of modules, it would make life much easier and I think C++ adoption more popular.
I work with C# as well, which has such a thing as an ABI, and using libraries is a real doddle - just drop the assembly dll in the bin directory, add a reference to it with a corresponding #import in the source files you want to use it... and you're done. C++ lacks this, though I would be fine having to include a header file too, its the ubiquity of dynamically loaded modules that could be written in any language (or more likely, they calling into my c++ library).
When you have several hundred modules in your program, you realise how nice it would be.
The issue of vendors is a non-issue I think. I recall building a program using Sun's compiler, then we upgraded and nothing would link - because Sun had changed their ABI between versions. I think Microsoft doesn't change it, but only because its stable, not for any other reason. Standardising wouldn't be much of an issue anyway - they'd probably have a flag that said "generate old or new" exports and leave it up to the user if they wanted the old, compatible ones (doubt it, most people recompile everything every time anyway due to the lack of an ABI!).
Meanwhile Microsoft comes up with their own versions (first COM, now WinRT) and they're inferior, being based on a funny sort of C for the first, and a funny sort of C# for the latter, leaving C++ binaries only practically accessible to other C++ programs.
Re:ABI (Score:1)
The lack of an official ABI is what relegates C++ to monolithic systems work or only using C++ libraries where you must have all the source code - including the header files. And god help you if a C++ library was written with a specific C++ compiler in mind - proprietary extensions.
And in addition to requiring all the C++ source code to your project and the C++ libraries it uses - you have to somehow build all the C++ code by reworking the various library makefiles, compiler flags, vcproj files or whatever flavor of the day build system some C++ code was designed with.
C++ code is brittle as hell from a build point of view.
I'm no java booster, but you can use jar file libraries in most projects with little regard to how they are implemented, and without source code.
That's why the C ABI is the Lingua Franca of all programming languages - the only stable ABI.
On ABIs (Score:0)
"and abstractions using templates (hard)"
This answer has been pretty much unchanged for the 1000 or so times the question has been asked:
(1) C is necessarily able to have a standardized ABI because everything you can do in C can be exposed across module boundaries.
(2) There are parts of C++ (templates) that can't be exposed across module boundaries.
(3) Therefore, C++ can't have a standardized ABI.
Unfortunately, (3) is pretty fallacious. It's true that C++ can't have a standardized ABI that includes the whole language. But it could easily have a subset ABI that includes all the parts of the language that can be exposed (specifically excluding templates.)
In fact, even (1) is a little fallacious: major portions of C, such as struct layouts and enums, can't really be exposed across boundaries. They are just assumed to be the same on both sides. But that hasn't stopped frameworks and OSes from adopting the C ABI, with additional out-of-band protocols to deal with API revisions.
The real issue is more political than anything: to have an ABI that excludes templates is seen as something that might rub against the template metaprogramming adoption drive, which has been one of the major philosophical underpinnings of the C++ mantra.
I'm actually a huge fan of templates, but I think there's plenty of political room to manouver in, without spoiling the doctrine. The alternative is the status quo of 100 or so half-baked ABI workarounds (think libsigc++) that can never be unseated, because they can't be significantly improved upon without changes to the language.
Re:On ABIs (Score:0)
You could expose templates across module boundaries, if you were willing to have enough type information at run-time that you could have a single compiled template that does the same thing as multiple instantiated ones. Call it a "virtual template" if you like, since "virtual" seems to be the keyword for "useful language features not allowed by default due to slightly founded performance concerns".
Sorry, Bjarne, you're wrong. (Score:-1)
All those syntactic sugar examples don't make things easier - they make things more complex.
Instead of just being able to SEE what's going on, you now have (as a half-competent developer) to know exactly what is going on with the sugar under the hood.
You have failed.
Re:Sorry, Bjarne, you're wrong. (Score:0)
To be honest, modern C++ is much better at hiding useless implementation details when it's not needed. E.g. auto, shared_ptr, etc. The main thing left is proper run-time memory safety, which could be mitigated at least a little through the use of exceptions on NULL pointer access.
Good interview, but ... (Score:0)
When I read stuff like this, I'm thankful I don't have to use C++.