C++ Creator Wants To Solve 35-Year-Old Generic Programming Issues With Concepts (cio.com)

C++ creator Bjarne Stroustrup is arguing that we can improve code by grounding generic programming in concepts -- what's required by a template's arguments. An anonymous reader quotes Paul Krill's report on a new paper by Stroustrup: In concepts, Stroustrup sees the solution to the interface specification problem that has long dogged C++, the language he founded more than 35 years ago. "The way we write generic code today is simply too different from the way we write other code," Stroustrup says... Currently an ISO technical specification, concepts provide well-specified interfaces to templates without runtime overhead. Concepts, Stroustrup writes, are intended to complete C++'s support for generic programming as initially envisioned. "The purpose of concepts is to fundamentally simplify and improve design. This leads to fewer bugs and clearer -- often shorter -- code"...

Concepts, Stroustrup believes, will greatly ease engineers' ability to write efficient, reliable C++ code... The most obvious effect will be a massive improvement in the quality of error messages, but the most important long-term effect will be found in the flexibility and clarity of code, Stroustrup says. "In particular, having well-specified interfaces allows for simple, general and zero-overhead overloading of templates. That simplifies much generic code"
Concepts are already available in GNU C Compiler 6.2, and Stroustrup wants them to be included in C++ 20. "In my opinion, concepts should have been part of C++ 17, but the committee couldn't reach consensus on that."

Comments

A new fad?

[OneHundredAndTen]

We'll see.

Re:A new fad?

[Anonymous Coward]

You're obviously not a programmer. Genetic algorithms and programming with such designs are not new.

Re:A new fad?

[Anonymous Coward]

You're obviously new at reading. t != r

Re:A new fad?

[jhoger]

he said generic, not genetic.

Re:A new fad?

[serviscope_minor]

No, not a new fad.

Concepts have been coming in C++ since the 90s.

There are two parts of concepts. On the ideas side, Stapanov came up with the idea with the STL. A concept of X is anything X-like. So loosely speaking if you have an array concept, then anything giving [] and having indexable pointers/iterators matches. So, builtin arrays match, as does std::array and vectors from Eigen would match too.

This makes sense: they're semantically the same and if you wrote an algorithm (eg. sort) using any of them, it would look identical. In this way, it's like a specification. If your class matches the specified "array" concept, then any algorithm written against that spec (the array concept) will work correctly on your class.

It's a great idea.

The other bit is language support. So, much C++ code is written using the idea of concepts, but the language does not assist in any way. Templating is completely generic, you say essentially "accept any class", but if you've written against the array concept, and the class doesn't match, you'll get a compile error right in the guts of the algorithm where you try to use [] on an array.

It would be nice, instead of saying "this function accepts any class" to say "this function accepts any class matching the Array concept", or in short "this function accepts any Array". The compiler knows the types and can tell in advance if the class matches. That way if you try to sort a set with that function, for example, it would simply tell you that the set is not an Array.

You can kind of finesse and finagle something better by utterly abusing a different language feature. The language has a mechanism called SFINAE (substitution failure is not an error), which is designed to make function overloading in the presence of templates sane. When the compiler does overload resolution, it substitutes the current type into any templated functions which match the name in question. If that substitution yields a compiler error, the compiler ignores it and removes that option from the list of overloads. This prevents unrelated templated overloads from breaking builds in irrelevant places. It's supposed to be a hidden detail which makes templating "just work". Except you can abuse it to enable/disable functions based on compile time tests for features of a class. IOW you can use it to implement concepts. Accordding to Stroustrup this means "you know too much :(".

He's right: just because you can do it like that doesn't mean it makes life easy.

Putting concepts into the language gives explicit support, with clean, clear, consistent syntax, not using brittle SFINAE hacks. People have been working out how since the 90s, and there have been several major proposals. It's not actually that trivial. You have to avoid breaking any old code, no matter how perverse. It has to work and work cleanly with old, non concept aware code (otherwise it would get slow/no adoption) and it needs to make life simpler for language users and not be an expert only feature, etc etc.

It looks like the concepts TS is finally hitting enough of the targets to actually work.

So basically, no, concepts is not a fad. It's been a major part of the C++ world for 2 decades.

Re: A new fad?

[Anonymous Coward]

So, a concept is just a fancy name for an interface or an abstract class?

Re: A new fad?

[jaklode]

Yes, AFAICT, it's an interface, but implicit - like a Go interface - not the explicit one you'd have to "implement" like in Java.

Re: A new fad?

[Wootery]

Close, but they're purely compile-time, and apply to the question of what types should be accepted by code templates?

Re: A new fad?

[TheRaven64]

Yes, except with compile-time specialisation instead of run-time specialisation. One of the big problems that I have with C++ is that it has entirely separate mechanisms and syntax for implementing the same thing with compile-time and run-time specialisation and they don't always compose well. Languages such as Java sidestep this by providing only run-time specialisation and expecting the JIT compiler to generate the equivalent of compile-time specialisation.

With an abstract class in C++, you'd require that every method be called via a vtable, which makes inlining hard (though modern compiler can do devirtualisation to some extent). This often doesn't matter, but when it's something like an array access, which is 1-2 instructions, the cost of the method call adds up. In contrast, if you use a template then the compiler knows exactly which method implementation is called and will inline any trivial methods (at the cost of now having one version of each templated function for every data type, which can blow away your instruction cache if you're not careful). The down side of the template approach is that you have no (simple) way of saying 'this template argument must be a thing on which these operations are defined' and the error message when you get it wrong is often dozens of layers of template instantiation later and totally incomprehensible without a tool such as Templight.

Re:A new fad?

[Anonymous Coward]

Kind of seems like a large amount of work for the holy altar of Don't Repeat Yourself. What kind of advantages do concepts (or even templating) give besides algos that can operate on superficially similar data structures? The only other camp that seems this zealous are the Thy Shalt Not Make Any Mutable Variables (even trivial loop iterators).

Re: A new fad?

[vyvepe]

The man difference between a concept and an interface is in the time when the dispatching to some specific called code is resolved.

Concepts resolve the call during compile time. This can lead to binary code bloat since the calling code needs to be "cloned" for each called code.

Interfaces resolve the call during run time. It can reuse the caller code but imposes some call overhead (the run time dispatch).

And sometimes you just need the resolving in the run time. If it would not be available then one would be forced to simulate it ... e.g. using dispatch (switch) on e.g. an alternative type (discriminated union). Well, or you could implement vtable manually if the language gives you enough power (pointer arithmetic) to do it.

Re: A new fad?

[serviscope_minor]

It's similar, but not entirely the same. It's mostly implicit interfaces at compile time. Implicit in that you never need to declare that you meet an interface, your class is tested to see if it matches. However, it's much more parametric. Underneath it all, those tests are arbitrary code, not simply a list of methods and signatures.

Re:A new fad?

[Anonymous Coward]

No, not a new fad.

Concepts have been coming in C++ since the 90s.

There are two parts of concepts. On the ideas side, Stapanov came up with the idea with the STL. A concept of X is anything X-like. So loosely speaking if you have an array concept, then anything giving [] and having indexable pointers/iterators matches. So, builtin arrays match, as does std::array and vectors from Eigen would match too.

This makes sense: they're semantically the same and if you wrote an algorithm (eg. sort) using any of them, it would look identical. In this way, it's like a specification. If your class matches the specified "array" concept, then any algorithm written against that spec (the array concept) will work correctly on your class.

How is this different than duck typing?

Re:A new fad?

[Anonymous Coward]

Yes! It will make a language that is already horrible, even more so, but allow the author to sell more books.

Re:A new fad?

[T.E.D.]

The other bit is language support. So, much C++ code is written using the idea of concepts, but the language does not assist in any way. Templating is completely generic, you say essentially "accept any class", but if you've written against the array concept, and the class doesn't match, you'll get a compile error right in the guts of the algorithm where you try to use [] on an array.

...at which point, your poor client gets the dreaded Error Novel; possibly multiple screens of a single error report, from down deep in the bowels of *your* template.

It would be nice, instead of saying "this function accepts any class" to say "this function accepts any class matching the Array concept", or in short "this function accepts any Array".

... which is exactly how Ada generics have worked for 34 years. Let's be honest: this is a fix for a serious design flaw in the language. This problem didn't *have* to be there. It was designed in.

Re: A new fad?

[Fwipp]

Dang, I wish I'd read this explanation years ago. Everyone was always talking like "concepts" were complicated.

Re:A new fad?

[serviscope_minor]

How is this different than duck typing?

Currently templates are precisely compile time duck typing. Concepts allow you to do a bunch of programmatic checks up front to verify in advance that you do have in fact a duck.

Re:A new fad?

[K. S. Kyosuke]

Neither of the two is actually new. ;)

Re: A new fad?

[Anonymous Coward]

In C# this presents itself as the ability to implement against a range of interfaces that follow a known characteristic ("where" keyword). It makes sense because C# lacks a preprocessor but still allows for templates in object files - it can't use the same deferred tricks that C++ can.

Concepts aren't completely identical to this, but they're pretty close in terms of what they try to model and they add much more information to a software design. They're a new form of software design contract, and those can be very powerful if wielded correctly.

Re: A new fad?

[K. S. Kyosuke]

Or a type class, perhaps?

Re: A new fad?

[Chalnoth]

Sorta kinda. It's not just a fancy name, for one, but an entirely new way of defining types.

Interfaces in C++ are also far more limited than concepts. For one, interfaces only work on class types. Concepts work on both classes and built-in types (e.g. int, float, pointer types). To make use of interfaces, you must pass objects by pointer or reference, not by value. Classes used this way have to be virtual, which carries a performance cost. There's no clear way in C++ to state that an object adheres to both interface A and interface B: you'd have to create a third abstract interface class which inherits from A and B, and have your class inherit from this third class. Interfaces are also highly non-standardized, which would mean that in order for interfaces to replicate the functionality of concepts, library developers would need to come to an agreement on a common interface set and then completely refactor their class definitions to conform to that common interface set.

So yes, it is possible to refactor code to use interfaces and virtual classes everywhere to produce a similar design to the one offered by concepts, but it will require a lot of work, won't be terribly readable, and comes with a performance penalty.

Re:A new fad?

[brantondaveperson]

it substitutes the current type into any templated functions which match the name in question. If that substitution yields a compiler error, the compiler ignores it and removes that option from the list of overloads.

I don't know who you are, but whatever you're being paid, it's not enough. I learnt something new today.

Re: A new fad?

[Pseudonym]

It's more like a Haskell typeclass.

Re:A new fad?

[Pseudonym]

Kind of seems like a large amount of work for the holy altar of Don't Repeat Yourself. What kind of advantages do concepts (or even templating) give besides algos that can operate on superficially similar data structures?

That's useful enough by itself, of course. Especially if, for example, the "thing which could be repeated" is huge, like an XSLT engine which has to work both on UTF-8 and UTF-16 data.

Then there's ability to separate mechanism and policy with zero run-time overhead.

The grand vision, though, is product line engineering. Real programs often do not stand alone. They are one of a suite or line of products, all of which differ in subtle ways. Templates give you a way to manage those differences in a principled yet efficient way.

Re: A new fad?

[Anonymous Coward]

It is a lot of unnecessary work. The whole point is actually Don't Repeat Yourself Or You Will Be Fired And Replaced With An Indian Programmer Willing To Work For Half As Much (DRYOYWBFARWAIPWTWFHAM).

Re: A new fad?

[Anonymous Coward]

Of course, it is just an excuse to fire American workers and replace them with cheaper workers... because that is how capitalism works.

Re: A new fad?

[lgw]

Note that while the current implementation of C++ templates leads to code bloat, that's not inherent in the idea of concepts. Compile-time polymorphism is a great idea that will be very useful, especially for library code where even the slightest increase in time can make people ignore your library.

It's kind of sad that concepts are seen as a template thing, but I guess it makes them more broad than just classes - various bare functions can be concepts as well. I'd rather see it as a kind of interface definition, myself.

Re:A new fad?

[lgw]

It's duck typing done right. You get a compile time error if it's not a duck, instead of a runtime error. That makes all the difference in the world.

Re:A new fad?

[Anonymous Coward]

You get a compile time error if it's not a duck, instead of a runtime error.

Do you have an example of something concepts would catch at compile time that the existing templated generic programming would let compile, but fail at runtime?

Re:A new fad?

[lgw]

No - but most languages with duck typing aren't in any way strongly typed, making them useless for "real code" IMO. Concepts allow compile-time checking with code that looks like duck-typing, and with good usability/maintainability (in strong contrast to current templates for this).

As someone with a masters in this -exact field-

[Anonymous Coward]

Bjarne Stroustrup, Doug Lea, Knuth, etc... still make feel like a moron on a almost daily basis....

Re:As someone with a masters in this -exact field-

[ls671]

make feel who? Yourself? If so, I can understand...

Re:As someone with a masters in this -exact field-

[ShanghaiBill]

Bjarne Stroustrup, Doug Lea, Knuth, etc... still make feel like a moron on a almost daily basis....

If someone makes you feel like a moron when they explain something, then maybe they are not as smart as you think they are. If you are a true master, you should be able to explain concepts in a way that even a child can understand. Richard Feynman was famous for this. So was Albert Einstein. Of course you can go too far, and simplify too much, so the children only think they understand. Donald Trump is a good example of that.

Re:As someone with a masters in this -exact field-

[Ross Finlayson]

That's often the case - but sometimes, people really are morons :-)

Re:As someone with a masters in this -exact field-

[Anonymous Coward]

The new Godwin

I know it's like trying to hold your breath and stuff, but can't anybody restrain the urge to throw up some banal crap about Trump in every thread?

Re:As someone with a masters in this -exact field-

[Anonymous Coward]

There are some things that have a high intrinsic complexity, such that a child can't understand them. Understanding them requires a specific factual base and well-developed cognitive abilities.

While it is true that someone might explain something badly, this doesn't necessarily mean that they don't understand it, just that they aren't good at explaining it. And it might also mean that you need to study up a bit in order to understand it.

Re:As someone with a masters in this -exact field-

[dbIII]

If someone makes you feel like a moron when they explain something

There's always the "why didn't I see that before - it's so obvious" moments that make you feel like a moron.

Re:As someone with a masters in this -exact field-

[Anonymous Coward]

It seems to me that Bjarne's biggest strength is that he committed to being the leader of the C++ project, understood that success depended on building and maintaining a community with diverse interests, took his responsibilities seriously, and never gave that up.

His books never struck me as the work of a master at the same level as, say, Knuth or Ritchie.

Re:As someone with a masters in this -exact field-

[mark-t]

When they make you feel like a moron, it's not because they are trying to, or because what they are saying sounds like something you could never understand, but exactly the opposite. You can fully understand what they are saying, but you simultaneously gain some insight into just how far beyond you they really are. It's a humbling experience, being taught by a genius in their field... and I was fortunate enough to have it happen to me once... While I came out of it knowing vastly more than I knew going in, I can honestly say I still felt stupider than when I started.

Re:As someone with a masters in this -exact field-

[swillden]

you are a true master, you should be able to explain concepts in a way that even a child can understand. Richard Feynman was famous for this. So was Albert Einstein. Of course you can go too far, and simplify too much, so the children only think they understand.

Richard Feynman and Albert Einstein both did exactly this. You really can't understand quantum mechanics or general relativity without math. You can think you do, and both of them were great at providing simple explanations that gave the illusion of understanding... but it was only an illusion, which of course they knew perfectly well.

Re:As someone with a masters in this -exact field-

[Anonymous Coward]

Additionally, learning most things requires foundational knowledge. Most problems with programmers is not their programming ability, but their foundational understanding of mathematics, computer architecture, and programming philosophy. They have a familiarity of those, and a working knowledge of higher levels, but they don't have a deep understanding of the fundamentals, which leads to a flawed understanding of the operational.

The guru can explain, but it does take quite a while to identify the student's misconceptions and gaps in knowledge, and much longer to correct the misconceptions.

Re:As someone with a masters in this -exact field-

[Anonymous Coward]

" If you are a true master, you should be able to explain concepts in a way that even a child can understand. Richard Feynman was famous for this."

Challenge: Cite any explanation of Feynman's, that a child could understand, that was actually useful for anything (not just a pretty metaphor).

Re:As someone with a masters in this -exact field-

[slew]

Richard Feynman and Albert Einstein both did exactly this. You really can't understand quantum mechanics or general relativity without math. You can think you do, and both of them were great at providing simple explanations that gave the illusion of understanding... but it was only an illusion, which of course they knew perfectly well.

I don't know about Einstein, but Feynman was also good at explaining things using math in a way that gave a typical physics student the illusion that you understood it. But that was only an illusion, as when you got back to your dorm room to do the homework you realized that he explained it in a way that you could not replicate because to him the math (usually path integrals) was so intuitive that he could breeze through it on the chalkboard, but you would actually have to grunge out the calculus because of your relative ignorance. Even the TAs weren't able to help you understand it the way he explained, but they would usually also have to grunge out the math to explain it to you.

It was then you realized that not only was he good at explaining things at a high level that gave you the illusion of understanding, but he knew the stuff so thoroughly in a way that you only wish you could understood it, someday.

Even in Physics X, he always had a few mathematical gems that seemed completely unrecreatable outside the lecture room. And if you ever heard him describe his techniques to pickup women, well, those were also something you might think you understand, but were totally unable to replicate later either... ;^)

Re:As someone with a masters in this -exact field-

[Waccoon]

If there's one thing I've learned in my life, it's that experts are often terrible teachers.

It's no wonder the general public is always so intimidated and suspicious of smart people.

Re:As someone with a masters in this -exact field-

[Dr. Evil]

"If you are a true master, you should be able to explain concepts in a way that even a child can understand. "

This isn't needed to be a master in a field and it isn't necessary unless you're speaking to novices or people outside the field. Sagan, Hawking or Feynman are good examples of this. Einstein was a real aberration, where even some of his papers were written with disarming clarity.

For Trump, I think you're mixing this up with the Dunning Kruger effect, where a person's inability to understand what's going on around them makes them think they have a better understanding than the experts.

Re:As someone with a masters in this -exact field-

[ShanghaiBill]

Challenge: Cite any explanation of Feynman's, that a child could understand, that was actually useful for anything (not just a pretty metaphor).

Ok. Feynman Diagrams are easy to understand, and very useful.

Re:As someone with a masters in this -exact field-

[Anonymous Coward]

These days he just sits behind his computer trading stocks unless someone interrupts him. Uh oh, the truth is out..

Re:As someone with a masters in this -exact field-

[jandersen]

Well, I heard an anecdote about Einstein many years ago - he was writing one of his articles about GR and wanted to make it understandable to the general public, so he read it to his granddaughter (or something like that), who was only about 5 years old, thinking, if she can understand it, then of course everybody else would as well. And, amazingly, this young child, who was playing happily with her stuff while listening to her nice graddad, would yes "Yes" every time he asked if she understood what had read out. I think it is a very sweet story ;-)

Another saying that I have seen attributed to Einsteing is, that you should always strive to make things as simple as possible, but no simpler. GR is a good example of this - it is a remarkably simple and elegant theory, and you really couldn't make it simpler; but it is still bloody complicated, not least because the toolset required (differential geometry on a smooth manifold with a Lorentzian metric as well as a volume form) is rather complicated in itself. C++, I suppose, compared to C, is like GR compared to Newtonian Mechanics; it gets really, really crinkly around the edges, not because the idea is unsound, but the subject just is that complicated, when you pursue it - and you can't make it simpler without losing important bits.

Re:As someone with a masters in this -exact field-

[Anonymous Coward]

is this the logic of a trump supporter?

Re:As someone with a masters in this -exact field-

[hey!]

If you are a true master, you should be able to explain concepts in a way that even a child can understand

This is, in a word, horse pucky. It's the same reasoning my niece uses to justify her anti-vaxxer beliefs: the quacks and charlatans she listens to are more credible than epidemiologists and immunologists because they're easier to understand. This is the real-life equivalent of the joke about searching for the $20 bill under the street light because where you actually lost it is inconveniently dark.

If it were true that a child could understand anything, there wouldn't be a need for education. You'd just find a "true expert" to explain, say, fluid dynamics to a random bunch of people off the street and then set those randos to work designing aircraft. Or cryptographic systems.

There's an unfortunate cultural trend to devalue anything that requires mental effort and dedication to understand as elitist bullshit. This is a dangerous development, especially when combined with our national vanity: ever since the Moon landing we see technological and scientific leadership as a birthright. It's not. It's something we have to earn, and continue earning every day by dint of hard labor.

The humbling truth is that real understanding in many things requires trekking a long and arduous road. It's a near certainty that you don't actually understand General Relativity; crude analogies about balls and rubber sheets notwithstanding. General Relativity is like a mountain that looks easy to tackle from a great distance, but the fact is it takes years of toil before you can even grasp how arduous the foothills of Mount Einstein are.

Re:As someone with a masters in this -exact field-

[Anonymous Coward]

Feynman's explanations, especially in his famous Caltech lectures, were known as "Chinese food physics", because you felt full and sated right afterward, but empty of understanding a little while later.

Re:As someone with a masters in this -exact field-

[Anonymous Coward]

C++, I suppose, compared to C, is like GR compared to Newtonian Mechanics; it gets really, really crinkly around the edges, not because the idea is unsound, but the subject just is that complicated, when you pursue it - and you can't make it simpler without losing important bits.

Nope. The problem with C++ is that the language designers want to do a lot of things statically at compile time rather than at runtime. And their compile time system is sort of a Turing complete pattern matching abomination using the C syntax as a sort of Gödelian alphabet for describing a problem to be solved by the linker.

If I wanted to program m4 patterns, I would use m4, thank you very much.

Re:As someone with a masters in this -exact field-

[Grishnakh]

Similar, but not exactly. The OP is pointing out why experts are frequently bad at imparting their knowledge to others, particularly laypeople. This is a valid hypothesis.

Trump supporters, OTOH, go much farther, and simply discount anything claimed by experts if it contradicts their "gut feeling" or what they "know" or what their preacher tells them.

Re:As someone with a masters in this -exact field-

[Grishnakh]

Doing things statically at compile time rather than at runtime is how you get high performance. If you want lousy performance, then there's other languages that are easier to write in, such as Python or Java, that do tons of stuff at runtime.

Re:As someone with a masters in this -exact field-

[Jack9]

As an adult who never _ever_ took a formal physics class, these diagrams ( e's probably mean electrons? and a y, q's and a g) are almost devoid of meaning.
Challenge still stands.

Re:As someone with a masters in this -exact field-

[brantondaveperson]

This is such an intelligent comment that it ought to win some sort of prize.

More features.

[Anonymous Coward]

That's what C++ needs: More features! They had better introduce sidgils like in Perl so they can have room for more keywords.

Templates produce very bloated code. Most embedded programmers working in C++ use a very small subset of the language for a reason. But C++ has lots of other problems. It was nice when it saved you from having to hand-build vtables doing OOP in C. Now after the meta-programming fads have gotten into it the language seems all over the map.

Re:More features.

[Anonymous Coward]

False, false, false, false, false.

Either you're trolling, or (more likely) you're one of those so-called "hard core" C guys, who had a look at C++ for 5 minutes back in early-to-mid-nineteen-ninety-whatever, didn't understand it, and decided that therefore it was a stupid language for all time.

P.S. captcha: wearying

Re:More features.

[HornWumpus]

Templates are like 600+ hp engines. At least you know your limitations.

Embedded programmers mostly write C, Forth or assembler. If they are using a C++ compiler, they are likely using it to code in C (or FORTRAN).

Re:More features.

[dyfet]

Indeed, in important ways, templates are both somewhat orthogonal to and do break some kinds of efficient object oriented design practices. Just think about templates and virtuals and why they do not really work together at all... It also has turned C++ into a modern version of IBM macro assemblers, where deeply obscured code regurgitation rules apply to what was actually compiled, hence also the bloat. However, the main benefit it still retains is that even if it may suck, for the things it is most often used for the other alternatives sadly often do suck even more ;).

Re:More features.

[The Evil Atheist]

https://www.youtube.com/watch?... Most templates and other code compile away. Learn to use the compiler.

Re:More features.

[The Evil Atheist]

There are no "efficient object oriented design practices". Templates are more efficient than shoving everything into a class hierarchy.

Re:More features.

[Anonymous Coward]

Templates neatly removed the #define hell most people were creating to create the mutable type problem in C++.

Re:More features.

[__aaclcg7560]

[...] you're one of those so-called "hard core" C guys, who had a look at C++ for 5 minutes back in early-to-mid-nineteen-ninety-whatever, didn't understand it, and decided that therefore it was a stupid language for all time.

That would describe me. When I went looking for a book about compilers, I recently ordered a used copy of "Writing Compilers and Interpreters" by Ronald Mak. I got the 1991 edition because it was written in Borland C and easier to translate into a modern dialect of C. According to the reviews, later editions used C++ that's almost impossible to translate into a modern dialect of C++. Long live C!

Re:More features.

[fozzy1015]

I used to write code for an enterprise network switch platform and our C code base started being built with g++. The toolbox analogy is apt. Forget the object orientated fluff, just use C with the STL container library. You have an optimized, standard interface library into commonly used data structures.

Re:More features.

[MightyYar]

That compiler explorer web site is really cool.

Re:More features.

[lucm]

That's what C++ needs: More features!

True. The guy should go and write more Seinfeld episodes instead.

Re:More features.

[Anonymous Coward]

Back in the day I learned the standard C++ library. Almost as soon as I had mastered it, the powers that be said "never mind!". "We now have an all new and incompatible version for you to learn". Dropped C++ and never looked back.

Re:More features.

[Waccoon]

I especially like it when those new features have incredibly generic names, implying how simple and fundamental they are regardless of usage, and not to mention how difficult it will be to search for information about them on the web.

Re:More features.

[Anonymous Coward]

Bullshit.

Re:More features.

[phantomfive]

Embedded programmers mostly write C, Forth or assembler.

All the same I'd be willing to bet there are more C++ programmers in embedded than Forth programmers........I've never seen a job posting with Forth, although I assume they exist. If I could find a job writing Forth, I would seriously consider it.

Re:More features.

[johannesg]

If they are using a C++ compiler, they are likely using it to code in C (or FORTRAN).

So how much are they saving by rolling their own vtables instead of the ones the compiler will generate for them? How much smaller are their executables because they used #defines everywhere instead of templates? Does the fact that they use functions instead of overloaded operators really give them an edge, in terms of size or performance? Does ending every function call in "if (err) goto endx" really save space and time over having a single try-catch block somewhere?

Re:More features.

[luis_a_espinal]

That's what C++ needs: More features! They had better introduce sidgils like in Perl so they can have room for more keywords.

Templates produce very bloated code. Most embedded programmers working in C++ use a very small subset of the language for a reason. But C++ has lots of other problems. It was nice when it saved you from having to hand-build vtables doing OOP in C. Now after the meta-programming fads have gotten into it the language seems all over the map.

1. Templates (and most other OOP features) are not necessarily meant for tackling problems in embedded programming, which is why people do embedded programming in C (or a stripped down version of C++). In fact, they just don't use C, but they use some formal strict subset of it (MISRA-C or something like that.)

2. Templates produce very bloated code... if you don't know how to use them or how you use them recklessly.

3. They (and other features) are meant to create richer application level functionality (with a well understood trade-off over lean and mean code.). Engineering is all about trade-offs (and knowing what the trade-offs are.)

Re: More features.

[Anonymous Coward]

He may have learned it before 2002. That is the year when gcc finally adopted the C++98 standard and threw out the old non standard library.

Re:More features.

[TheRaven64]

Really? Prior to 1998, there was no standard library, though the Standard Template Library from SGI was pretty much treated as the standard library. When C++ was standardised in 1998, most of the STL was incorporated into the C++ standard library, so almost everything that you'd learned from the STL would still be relevant. The next bump to the standard was in 2011. Lots of stuff was added to the standard library, but very few things were changed in incompatible ways (auto_ptr was deprecated, because in 13 years no one had figured out how to use it without introducing more problems than it solved) and almost all C++98 code compiles without problems against a C++11 library. C++14 and C++17 have both added a lot more useful things but removed or made incompatible changes to very few things.

Let's look at a commonly used class, std::vector. The only incompatible changes in the last 18 years have been subtle changes to how two of the types that are accessible after template instantiation are defined. Code using these types will still work (because the changes are not on the public side of the interface), but the chain for defining them is more explicit (e.g. the type of elements is now the type of elements, not the type of things allocated by the thing that allocates references - code would fail to compile if these weren't the same type). The changes in std::map are the same.

That said, you do need to learn new things. Modern C++ shouldn't use bare pointers anywhere and should create objects with std::make_shared or std::make_unique. The addition of std::variant, std::optional, and std::any in C++17 clean up a lot of code.

Re:More features.

[TheRaven64]

For embedded systems, you really don't want exceptions. The runtime for RTTI and exceptions is bigger than the flash on most systems (I wrote the one that ships on FreeBSD, the PS4, and a few other places - it's not a huge amount of code in the context of a desktop OS, but it's 100KB of object code for the C++ bits, plus the generic stack unwinder - you don't want to burn 150-200KB of space on an embedded system for this) and stack unwinding performance is very hard to reason about in anything realtime. The reason that the Embedded C++ subset excluded templates was that they make it very hard to reason about code size. A small amount of source code can easily become 10-100KB of object code if you instantiate templates with too many different types. Writing foo() is now not a simple case of set up the call stack and jump, it's either that simple if someone else has instantiated the same template function, or it's creating an entirely new copy of foo and all other templates that it refers to using the template parameters. This makes it very difficult to work out what changes were responsible for pushing the size above the available space. Actually, it's even worse, because the specialised function might now be simple enough to inline everywhere and give an overall space saving, but reasoning about exactly where that balance is becomes very hard. It's not that C++ generates bigger code than C, it's that object code size in C++ has far less of a direct correspondence with source code size than C.

Re:More features.

[Anonymous Coward]

Templates are mostly superfluous because we don't actually need to apply the same kind of operation (sorting or whatever) to lots of different types.

Re:More features.

[Anonymous Coward]

The only incompatible changes in the last 18 years have been subtle changes...

In 1997, std::vector was not legal syntax. In that time frame, you would use vector. After that you would either need to start adding std:: for every STL class used anywhere in the code, or using namespace std in every file that used the STL, or use some compiler dependent option to help you. So that was a big change. Technically it may be outside of your time window, though.

Another change that happened involved the meaning of delete with respect to arrays. Old code would introduce bugs if compiled with new compilers and new code would leak memory if compiled with old compilers. That fits your time window.

I will concede that more recent changes to C++ have been less likely to break code written in the past, but the above two changes did have significant impact.

Re:More features.

[TheRaven64]

In 1997, std::vector was not legal syntax.

1997 was prior to C++ becoming standardised, so there was no standard library. The vector from vector.h in SGI's STL was similar to the standard library vector, but it was not part of the standard library. The STL was also still available for a good decade or so after it was deprecated in favour of the C++ standard library.

Another change that happened involved the meaning of delete with respect to arrays. Old code would introduce bugs if compiled with new compilers and new code would leak memory if compiled with old compilers. That fits your time window.

Only if your compiler is buggy. Arrays have required deletion with delete[], not delete, for as long as the language has had a standard.

Re:More features.

[GuB-42]

Concepts are not really a new feature. More like a way of doing what is already done using templates but without the ugly hacks.
The idea is to restrict what kind of types can be used in templates, so that instead of having an error that pops up deep inside the template code, you have a much clearer "this type is not supported" kind of error right off the bat. It also helps making the SFINAE trick a little less tricky.

As for templates producing very bloated code, I suppose you mean binaries. If you use them improperly, sure, but not if you know what you are doing, they work fine. They can do a good job replacing macros which seem to be all too common in embedded code. As for using only a subset of C++, there is nothing wrong about it. C++ is huge, I have more than 10 years of experience being paid doing C++ and I still regularly learn new things. I'd set using only a subset, or just plain C is good practice, but it is nice to know that should you want something more complex, you can do it.

Re:More features.

[Anonymous Coward]

Does ending every function call in "if (err) goto endx" really save space and time over having a single try-catch block somewhere?

I haven't tried, but considering what try-catch does I would say yes.
But that is largely irrelevant since you want to avoid using exceptions in embedded systems for other reasons.

Re:More features.

[Anonymous Coward]

What book or tutorial or website you would advise to start learning C++ today?

Re:More features.

[Anonymous Coward]

The short answer is "yes." The long answer is "yes, but not really a lot so this is more an intellectual circle jerk than anything else." I'd write more but have too much actual coding to go do.

Re:More features.

[Anonymous Coward]

Some of us are pushing 50 and so will never admit this because we remember when classes were a whole new thing and template did not exist. That's the sole cause and source of any pushback and why templates didn't make it into C++ 17.

Re:More features.

[Anonymous Coward]

I've got some experience developing for really memory constrained devices (32k RAM + 32k ROM) and I've found that the judicial use of C++, particularly templates, can save a lot of ROM space. You don't tend to use templates to generate code of course, that'll flood your ROM in no-time, but when used to just trick the type system into generating different signatures for the same code, basically what Java and C# use generics for, it avoids a lot of code duplication. And in C++ you can often avoid doing any run-time type bookkeeping, which saves precious RAM space.

Re:More features.

[Grishnakh]

That's not the only reason you don't want exceptions. Exceptions are non-deterministic. Anything that's non-deterministic must be disabled on a mission-critical realtime system. This even includes processor caches.

Re:More features.

[CSMoran]

Templates are mostly superfluous because we don't actually need to apply the same kind of operation (sorting or whatever) to lots of different types.

For a suitably narrow definition of 'we'.

Re:More features.

[TheRaven64]

I honestly couldn't say. I learned C++ about 20 years ago, hated it, tolerated it a bit while working on LLVM, revisited it in C++11 and discovered that the language had changed beyond all recognition and didn't suck anymore. I like cppreference as a reference for the standard library, but I've not used a tutorial (and I definitely wouldn't recommend the old book that I read).

Re:More features.

[Anonymous Coward]

To be honest, the Embedded C++ folks didn't understand the bits they cut well enough - smarter cuts would have been possible.

For instance, the template bloat is chiefly due to _implicit_ instantiation. Embedded C++ could have kept explicit template instantiation. C++ allows you to throw anything, even floats and pointers, but it would have been reasonable for EC++ to limit this to just the handful of exception classes predefined in the Standard Library.

Re:More features.

[Anonymous Coward]

Even stonger, the bits of the STL which didn't go into the Standard Library just continued to work. After all, the STL was not magic. Its algorithms worked on anything pointer-like, whether that was a real pointer, an iterator from an STL container, or an iterator from the new std::vector.

This is of course fundamental to the STL idea, and now to these Concepts. With OO, you must declare up front that a certain type implements a given interface. With Concepts, it just matters whether a type is actually compatible, not whether its author said so.

Re:More features.

[Anonymous Coward]

I like Scott Meyers's Effective C++, 3rd Edition and Effective Modern C++

Re:More features.

[Anonymous Coward]

For beginners, Stephen Prata's "C++ Primer Plus," or Bruce Eckel's "Thinking in C++" though the latter is outdated. I wish he'd do a 3rd edition.

Re:More features.

[lgw]

Exceptions are perfectly deterministic. I guarantee you no entropy source is included either at compile time or at run time.

However, you can't safely use exception unless all your types are exception-safe. This is an easy pattern to follow, and easy to get right in code review, but it's not widely known. Plus, people just assume any C++ feature that's not in C must be slow, so the idea of cleaning up allocations and whatnot automatically as part of stack unwind must somehow be slower than writing all that code manually at the bottom of every function.

Scoped objects (inherently exception-safe objects) are definitely less error prone than goto fail.

Re:More features.

[lgw]

There are no "efficient object oriented design practices".

Sure there are. OOP doesn't automatically imply "crazy inheritance trees". If you only use inheritance when runtime polymorphism is really needed, and that's rare, your code will be plenty efficient.

Without runtime polymophism, a method call is just a function call, no overhead (and no object bloat). This is really a problem with library code, which all to often ends up OOP-heavy to make it broadly usable. Concepts really shine there, of course, and to your point the resistance against it in the committee is quite irrational.

Re:More features.

[Grishnakh]

Here's a discussion on StackOverflow about it.

Re:More features.

[The Evil Atheist]

Actually I find functional style programming is a much better application of runtime polymorphism than OO inheritance hierarchies are. As a library designer, all I need to do is to accept a function object that fits a specification. As a user of that library, I don't need to know anything about the library other than what function object to pass to it. I can put only the minimal state I need in that function object. That way, neither library designer, nor library user introduce any coupling between each other's types.

Re:More features.

[TheRaven64]

That's a false dichotomy. The Ingalls definition of an OO language is one in which you can declare a new kind of integer and use it to describe the coordinates of a window that you place on the screen. Concepts are a lot closer to this definition than C++'s attempt at OO. I suspect that a lot of the hostility towards OO comes from languages like C++ that get the rough shape of OO right but without getting most of the useful parts.

Re:More features.

[TheRaven64]

Plus, people just assume any C++ feature that's not in C must be slow, so the idea of cleaning up allocations and whatnot automatically as part of stack unwind must somehow be slower than writing all that code manually at the bottom of every function.

It's important to separate the mechanism from the implementation. I know of five mechanisms that mainstream languages have used to implement exceptions:

• Make every try block a setjmp, every throw a longjmp. Put the exception in a thread-local variable and put the handling code in the conditional path from the setjmp.
• Reserving a second return register for the exception and following every call with a branch on that register value.
• Following every call instruction with a branch to the exception handler and making the normal return path return to the following instruction (return address plus the size of one instruction).
• Emitting unwind tables that describe to some support code how to unwind each stack frame and where to go for each kind of cleanup.
• Creating a linked list of functions in thread-local storage that know how to do the unwinding.

The first is a terrible way of implementing exceptions, because it makes throwing exceptions quite cheap but entering try / catch blocks very expensive. It was easy though, so a lot of systems used it. Java implementations often use one of the next two, because exceptions are quite common and want to be on the fast path. These have very similar performance characteristics, independent of whether you take the normal or exceptional return path.

The next one is the so-called 'zero-cost exception' model. This is used on most UNIX (and bare metal / embedded) systems. If you don't enter the exception path, these are almost free (the overhead comes from the fact that you split basic blocks to allow for the exceptional control flow path and so make some compiler optimisations less efficient). The cost of throwing an exception is very high in this model. You first call into the language runtime library, which allocates space to store the exception and some structures for storing the unwind state. It then calls into the generic unwinder, which parses some data structures (DWARF frame descriptions on UNIX systems), constructs a partial unwind state, then calls into the language-specific personality function (32-bit ARM has a few optimisations on this that reduce flexibility but generate smaller code, but the approach is broadly the same), which then parses some more data structures to work out whether to catch the exception, whether it needs to run cleanups, or whether this frame is safe to ignore. Once the generic unwinder has found a place that catches the exception, calls back into the personality function for each frame that needed to run cleanups. Each call provides the landing pad for the cleanups and the personality function unwinds the stack to that function and allows it to continue. This function then calls back into the generic unwinder, which then repeats the process until you end up at the catch frame. At the end of the catch statement, the catching function calls back into the language runtime, which frees language-specific data structures and the unwind state.

The final approach is used on Windows. This is slightly cheaper to use because each of the functions that handles the unwinding (called funclets in Windows terminology) runs on the top of the stack, but with a pointer into the stack frame that it's unwinding. If they're running cleanups, then they destroy objects in place, then tail call the next funclet. The one that handles the cleanup then transfers control back to the original function.

The problem for embedded programming is that the exception path and the non-exception path have very different performance characteristics. Exception implementations (particularly for C++) tend to assume that exceptions happen in exceptional circumstances and so optimise for the non-exceptional c

Re:More features.

[lgw]

The second model is of course what you get if you don't use exceptions, so any solution that is no slower isn't a performance hit.

The problem for embedded programming is that the exception path and the non-exception path have very different performance characteristics.... throwing an exception with the 'zero-cost' model can involve dozens of function invocations, each of which has to parse complex data structures

Yeah, that just sounds like lazy compiler writing. It's one thing to bias optimization for the path likely to be taken, it's another to just blow off performance on some path. Really, though, if you're using scoped objects, you'll be going through the same clean-up code regardless of the reason the stack is being unwound (the destructors for all your primitive objects).

It seems bizarre that you'd add a huge perf hit, when the semantics are no different from classic "safe" C code. Sounds like there's room for a C++ compiler tuned for embedded systems.

Re:More features.

[TheRaven64]

It's not laziness, it's generality. When you have exceptions, you're unwinding an arbitrary number of stack frames. When I throw a C++ exception, I have no control over the languages of the intervening stack frames. They might be C, Objective-C, Java (with gcj), Fortran, Algol, Go, Swift, or something else. The unwinder has to be able to run cleanups for all of them. If you're willing to sacrifice the ability to call between languages, then you can optimise (which Java can, because it has an entirely different mechanism for propagating exceptions through JNI frames, which most JNI code gets wrong).

Re:More features.

[michael_wojcik]

That said, you do need to learn new things. Modern C++ shouldn't use bare pointers anywhere and should create objects with std::make_shared or std::make_unique. The addition of std::variant, std::optional, and std::any in C++17 clean up a lot of code.

Amen to that. In my experience, the biggest problems with C++ are the vast amount of poor old code, and the large number of C++ programmers who are still using the constructs that were necessary before C++98 - often mixed and matched with newer approaches, so large codebases get increasingly stovepiped.

Green-field C++ using a modern variant (even C++98 / C++03) can be very clean and elegant. But when I look at C++ sources, whether it's proprietary commercial stuff or open source, it's usually pretty awful.

Re:More features.

[lgw]

Oh, I agree - and Lambda is finally part of C++. The old std::function stuff was pretty bad, but it's much nicer now..

Re:More features.

[lgw]

Sure, but why does that necessarily involve a huge perf hit? You need a conditional branch on each frame, sure, if you're not using Microsoft's trick (but you're doing that even if no exception was thrown, to hook the destructors), but having taken that branch and found an exception handler, why should it be crazy expensive at that point?

Re:More features.

[TheRaven64]

Because unwinding into a stack frame involves finding where the called frame spilled any registers and restoring it. The Itanium ABI (which all UNIX systems use) specifies DWARF unwind data for this. The callee can spill things on the stack, move them to different registers, and so on. You must first parse tables to find where all of these things are and reconstruct a register set for the next stack frame that you're unwinding into. You then need to determine whether the frame is going to catch the exception. For C++, this involves first checking whether it's a C++ exception. If so, then you next have a list of possible catch blocks. Each has an associated type_info object. You then have to call the check method on the type_info objects to see if the thrown object is compatible (which, in cases of diamond inheritance is very expensive and in cases of simple inheritance involves walking a linked list). If none of the catch blocks match or it's a foreign exception, but there is a catchall (catch(...) block) then you jump there. If there's no catchall, but any local objects have nontrivial destructors, then you have to do a cleanup, which will then resume unwinding at the end.

The decision to walk the stack twice is to allow language semantics (C++ supports this, as do a few other languages) where unhandled exceptions invoke a handler on top of the stack, without destroying any current stack frames. The simplest use for this is to print a stack trace of where an unhandled exception was thrown before terminating, but it's also allowed for a program to walk up the stack running cleanups and gracefully terminate a thread that has an unhandled exception, or do something like aborting any in-flight transactions from that thread and shutting down the program gracefully.

Oh, and in C++11 you're allowed to catch the exception, encapsulate the in-flight exception in an object, and then pass it to another thread for handling (rethrowing it there). Or simply defer it and rethrow it later. All of this adds complexity.

TL;DR: Exception throwing machinery is complex because the semantics of exceptions are far more complex than simply 'oh, this thing returned an error, run cleanup code'.

Re:More features.

[TheRaven64]

LLVM code is mostly pretty nice. They adopted a lot of C++11 library features with their own implementations before they were standard and then replaced them with C++11 when it was widely supported. For example, llvm::OwningPtr was originally a purely local implementation, then had an #ifdef so if you were compiling with a modern compiler and standard library it was just another name for std::unique_ptr, and eventually uses were all replaced with std::unique_ptr and the LLVM class went away. Oh, and when lambdas were supported widely a whole load of copy and pasted code was replaced with a lambda that was just called in the function - compilers are really good at inlining these, so you end up with identical binary code, but much simpler sources.

I've found that there are two really bad ways to write C++. One is to think of it as a C-like language and try to write in the style of C. The other is to think of it as an OO language and write Smalltalk-like code. The language supports both styles (though supports the latter less well), but it doesn't do either very well.

Re:More features.

[Anonymous Coward]

All of Scott Meyers' books are excellent, and I wouldn't hire a C++ programmer that hadn't read (and understood) at least his first Effective C++ book. However, recommending those to a newbie C++ programmer is like teaching someone to drive on an active racetrack. Start in an empty parking lot. Unfortunately like the GP, I learned the basics of C++ too long ago to recommend a good modern book for beginners.

Re:More features.

[lgw]

Sure, where there's actually a catch block there's an expense, because you have to check the class hierarchy of the thrown exception at runtime, that part makes sense, it's more branches than a simple return code check, but if you avoid Pokemon code that's not a big deal. And if your thrown exception type is not a derived class, then it should just be a pointer comparison anyhow (of course, deep inheritance chains for exceptions seem to be a common pattern, for some reason).

Multiple catch blocks is no different from a switch on a return code. Hooking the exception at the point it's thrown for debuggers is something I've seen in C debuggers as well, though admittedly it comes up a lot less.

Re:More features.

[Anonymous Coward]

Try C++: The Good Parts

Re:More features.

[TheRaven64]

And if your thrown exception type is not a derived class, then it should just be a pointer comparison anyhow

No, you only get to make the saving if you're in a language that doesn't permit subclassing. In a few cases (e.g. throwing an int) you could special case it to generate a simple comparison, but that case is sufficiently rare that it's not worth optimising for. In C++11, if a class in a catch block is marked as final then you could potentially do the same optimisation, but most exceptions are subclasses of std::exception or some library-specific equivalent, so that's also pretty unusual and not worth optimising for.

Multiple catch blocks is no different from a switch on a return code

No it isn't. If I write try {...} catch (foo e) {} catch (bar e), then I must check first if the thrown exception is a subclass of foo, then if it's a subclass of bar. It's only a simple switch for a language that doesn't allow subtyping so I have a unique value for each type and only exceptions of type foo are caught by the first and exceptions of type bar are caught by the second catch.

Your point is that if you restrict the language semantics to something less expressive than the current exception model then you can make it more efficient, at the cost of generality. That's true, but not particularly relevant to why exceptions are expensive for a language that has rich exception semantics.

Epicycles

[helixcode123]

The vagaries and complexities of C++ as it progresses in it's specification is reminiscent of efforts to get epicycles to explain motions of heavenly bodies. Geez, people are snide about Perl syntax. Now we have &ref, &&global_ref, [](args){my_lambda_code();}, copy constructors, move constructors, 'override' to fix virtual function breakage. This is just a mess of a language.

Re:Epicycles

[helixcode123]

Yeah, I know. &&global_ref => &&universal_ref.

Re:Epicycles

[The Evil Atheist]

I learnt it and found it easy. I think the problem is with you.

Re:Epicycles

[Anonymous Coward]

"The vagaries and complexities of C++ as it progresses in it's specification"

Yet it's vs. it is is so simple, but you can't understand that...

Re:Epicycles

[Anonymous Coward]

You are DEAD ON. I almost created an account to try to mod this up. C++ is just like Kepler trying to fit the orbits to polyhedra! It is missing the fundamental concept in a big way. In my opinion (30+ years getting paid to write code), there is VERY little difference between the dozen or so (interpreted & compiled) languages in favor today. Perl and Python really are nearly identical to Ruby and Javascript, and C++ and JAVA: some have rougher edges than others, but they all solve the same problems with nearly identical syntax. Its almost embarrassing that people are so entrenched in the language wars.

Anyway, my point isn't to pretend to be Grand-daddy Badass Coder, my point is that while handling strings has become easier in the past 30 years, the language paradigms have changed very little. I want to lean on the film Arrival: the language you affects how you think, and we need to be taught new ways of thinking. I'm in my early 50's and I'd fight to the front of the line to learn a new language if it would help me be a better programmer.

Maybe he's on to something. It feels like it. It's going to take a Stallman/Stroustroup type brain to think us into a new way of solving problems. (I left out Torvald because IMHO he is not a philosophical thinker, he is a laser-focused one man execution team.)

Re:Epicycles

[Anonymous Coward]

And C# is headed the same way.

Re:Epicycles

[Anonymous Coward]

It's not even that:

Raise your hand if you actually USE an appreciable part of C++ that's newer than C++03.

Yep: variable declaration, &, *, [ ], callFunction(), &someFunction, maybe template .

Re:Epicycles

[Anonymous Coward]

I can fix broken cars. My ability to fix them, doesn't make them less broken.

Put more bluntly: You're being a dick, trying to paint people making legitimate arguments as stupid with a logic that is, itself, stupid.

Re:Epicycles

[helixcode123]

I don't think so. Even folks that love C++ will say "well, you don't really need to know foo-obscure-feature, but it's there if you need it. I was reading through Scott Meyers' "Effective Modern C++", an excellent book, but probably half of it was showing how to make sure you "move" your data instead of "copying" it. I'm no Java fan, but at least everything is a reference, so you don't have copy-by-accident ooga booga. If copying is so bad (which apparently it is because you'll definitely get reamed during a code review if you do), force a copy action via clone(), ike Java.

The pain in C++ is on account of the "keep it compatible with C" mantra. C++ could be great if they'd just jettison that idiocy. It's like that stupid fighter that they're building that has to fit the requirements of every branch of the mility. It's complicated, overbudget, and doesn't work. They should build three fighters that work well in each domain. C++ should just be C++, and C can be C. That will probably happen eventually.

Well, eventually C++ will re-implement Lisp according to Greenspun

Re:Epicycles

[Anonymous Coward]

I found it easy when I learnt it too. Then I studied it a bit more, used it a whole lot more, and realised I was wrong and it was in fact a rather complex and obscure beast.

Re:Epicycles

[The Evil Atheist]

The features he listed were not obscure. The expanded types of reference, move, and lambda functions are easy to grasp after one day of using it. In fact, most of the time you don't need to explicitly use it because the standard library constructs use it automatically.

Re:Epicycles

[Jamu]

The pain in C++ is on account of the "keep it compatible with C" mantra. C++ could be great if they'd just jettison that idiocy.

Which would be nice, but it would also break existing code.

Re:Epicycles

[Anonymous Coward]

Backwards compatibility with C is a very minor part of the current C++ language. More importantly, it is its killer feature and breaking C compatibility would also break compatibility with previous C++ versions in a rather painful way.

Re:Epicycles

[TheRaven64]

I'm no Java fan, but at least everything is a reference, so you don't have copy-by-accident ooga booga.

That's true, but Java doesn't really have an equivalent of the C++11 move idiom. If you want Java-like semantics from C++, just alias your pointers (ideally wrapping them in something like std::shared_ptr first). The term move is actually a little bit misleading: you're copying the object, but you're transferring ownership of the expensive contents of the object. For example, when you move a string you're creating a new string object, but you're not copying all of the string data, you're just transferring ownership of the underlying buffer. This is even more important for collection types, where you really don't want to do a deep copy and delete.

You can implement the same thing in Java by splitting your objects into cheap wrappers that have a reference to an expensive object and then adding a move() method that transfers ownership of the expensive object to the new wrapper, but it's not integrated into the language. The language integration isn't actually essential in C++ either: people have implemented the same thing using a special Move<> template, which could be used as an argument to an overloaded constructor, which would do the move operation. The nice thing about having it in the standard library and with language support is that tooling understands it. Your compiler / static analyser can warn you if you move an object and then try to anything with the old version.

If copying is so bad (which apparently it is because you'll definitely get reamed during a code review if you do), force a copy action via clone(), ike Java

Saying 'copying is bad' is just as wrong as most other 'X is always wrong' rules. Copying for small types is fine. A std::pair of an integer and a float is a couple of instructions to copy and move semantics would make no sense for it. clone() in Java is also problematic because the standard library doesn't distinguish between a deep and shallow clone.

Re:Epicycles

[AmiMoJo]

The problem with just having so many features is that if code you need to maintain is using them, you need to understand them. Not just have a vague idea of how they work or the syntax, but understand them well enough to write new classes or change existing behaviour without breaking everything.

A lot of bad code started out as good code, then someone who wasn't familiar with what used to be the latest and greatest new paradigm back in 2003 had to maintain it.

The great thing about C is that you can quite easily understand all of it. C++ can trip you up easily. C# isn't bad as a language because it often simply does not allow clever but error prone stuff that C people love, but still suffers from supporting too many different design patterns in some areas.

Re:Epicycles

[Anonymous Coward]

The JSF uses C++ so it is a perfect example of why the cost is so high and has so many problems...

http://www.stroustrup.com/JSF-AV-rules.pdf

Re:Epicycles

[K. S. Kyosuke]

I think the idea is perhaps that they should have done that in the late 1980s.

Re:Epicycles

[The Evil Atheist]

The great thing about C is that you can quite easily understand all of it. C++ can trip you up easily.

What I find though is that libraries written in C are harder to understand than C++. Compare qsort to std::sort. In qsort, I have to manually pass in sizes, counts and a function pointer. In std::sort, I just need to pass in a begin and end iterator. The "size" and "count" are all worked out for me at compile time, and uses the default "
So yes, you can easily understand C. But you can't easily get the gist of a program written in C.

It is harder to understand C++. But you can easily get the gist of a program written in C++, but without sacrificing performance.

Re:Epicycles

[brantondaveperson]

The difference between C++, and the other languages that you mention, is that those languages are written in C++. There is a reason for this. If you need performance, without sacrificing expressiveness, there is no substitute.

I want to lean on the film Arrival ...<snip>.

Argh. Spoiler....

Re:Epicycles

[Anonymous Coward]

The expanded types of reference, move, and lambda functions are easy to grasp after one day of using it.

The whole computer language of Lua is easy to grasp after one day of using it. Its syntax specification fits on a single piece of A5 paper (half letter-size for the backwater guys).

C++ has enough "easy to grasp after one day of using" things to fill up the whole year and then you forget where you started. Calling C++ a computer language is like calling the ecosystem erupting from a corpse a person. Yes, there is a common history, but it just does not make for a coherent whole, with parts being at cross-purposes.

C++ is just sticking around too long on the graveyard after burying C.

Re:Epicycles

[Anonymous Coward]

For the people who want C++ without its backwards compatibility, there's D.

Of course, D now has some backwards-compatibility pains with D itself. That's the price you pay, when you have language developers who are a bit too willing to break existing code.

Re:Epicycles

[Anonymous Coward]

I started learning Python just a few months before the release of Python 3.

It was unpleasant.

Re:Epicycles

[The Evil Atheist]

If you're not using C++, then why are you complaining?

Just what we needed

[tphb]

I was just saying, "You know, C++ is too straightforward, and there are too few ways to get things done. It needs a few more keywords and paradigms to make it make it work."

What a freakin' mess.

Re:Just what we needed

[Anonymous Coward]

Nobody is forcing you to use any of the new features.

Re:Just what we needed

[Dutch Gun]

Do you know what I never hear a carpenter saying? "Geez, look at all these tools. I wish I had fewer tools in my toolbox."

C++ is a language toolbox. You can use the parts of it useful to you, and largely ignore the rest if you don't happen to need it at the moment.

Re:Just what we needed

[cfalcon]

> "Geez, look at all these tools. I wish I had fewer tools in my toolbox."

No, but I do here people who go in to modify something say "Gosh, I wish there weren't so many different types of connectors, why does this screw have a starburst and this one a rhombus on it?"

Remember that for every Clever Lad who writes this code, an army of dudes has to come through and read and modify it over time.

That's not to speak against it- merely that as the language gets broader, supporting it becomes slower and more expensive.

Re:Just what we needed

[Dutch Gun]

Well, part of being a professional programmer, at least IMO, is not going batshit-insane with fancy language features when they're not needed. C++ is a language in which you can write some really, really horrible code if you're determined to do so. And I don't think I've ever heard anyone describe it as a language that's easy to master. But for highly experienced C++ programmers like myself, it's an incredibly powerful language, and that's what's important, at least when I use it professionally.

It's pretty easy to list off a litany of problems with C++. It's bloated, it's ugly, it's hard to learn, full of strange idioms and tricky rules. But it has three characteristics that make it indespensible for certain industries and applications:

* It's ubiquitous. Nearly every platform has a C++ compiler, and there's a lot of sample C or C++ code available to use. It also makes hiring and training easier.
* It's efficient. You don't pay for features you don't use, and it compiles down to fast, efficient, native code.
* It's got reasonably good abstraction features that don't require paying a heavy price for that safety, enabling large, complex programs to be written more easily.

There are a lot of great new languages coming out, but nearly all of those fail on the first point. Unfortunately, that's a deal breaker for many projects.

Re:Just what we needed

[x0ra]

> "Geez, look at all these tools. I wish I had fewer tools in my toolbox."

No, but I do here people who go in to modify something say "Gosh, I wish there weren't so many different types of connectors, why does this screw have a starburst and this one a rhombus on it?"

Easy: different physical / mechanical properties to tweak each a given job. Can you use a plywood screw to attach together two load bearing 2x4 ? Sure, but they might corrode faster and fail sooner than proper wood screw (not to say that it's the best). Same goes for torx vs 6-point vs 12-point bolt, same goes for grade 2 vs grade 5 vs grade 8 bolts / nuts.

Re:Just what we needed

[Jeremi]

As a C++ programmer, I don't know if I'll ever use "concepts" in my own code.

That said, I'm nevertheless very much looking forward to them becoming part of the language, if only so that when I do something wrong when using an STL class, the compiler can come back with an error that tells me what I did wrong, rather then five pages of incomprehensible gibberish.

Many C++ features are like this, aimed not primarily at the average C++ user, but rather at the STL developers.

Re:Just what we needed

[Anonymous Coward]

As another old-schooler, just wanted to say thank you for not using the word "engineer" anywhere in your post. That means that you really are a hard-core C++ guy who actually gets shit done with well-written, maintainable code.

Seems everyone I run into these days who says "I'm a software engineer" has zero CS instinct and just slings poo against the wall hoping something sticks.

Re:Just what we needed

[arth1]

Do you know what I never hear a carpenter saying? "Geez, look at all these tools. I wish I had fewer tools in my toolbox."

Bad analogy. When the carpenter needs to repair something, he doesn't need to line up all the tools used to create it. And someone taking over the work doesn't need to learn the tools the previous carpenter used.

The only fitting part of the analogy is that if the dovetails or tenons have gaps or cause the wood to split, it's probably because the carpenter used power tools and templates instead of more precise hand tools and reading the grain. Too much abstraction and little understanding of the fundamentals truly hurts the end product.

Re:Just what we needed

[Anonymous Coward]

I don't disagree with anything you've said, but the problem is that everyone working on the codebase has to meet those high standards. So maybe I disagree with you on "It also makes hiring and training easier."

The problem with "largely ignore the rest if you don't happen to need it at the moment" (from your grandfather post) is that I'm happily ignoring (or oblivious) to the new stuff and then one day I touch something and it breaks and I find myself staring at

template <typename S, typename T>
    requires Sequence<S> && Equality_comparable<Value_type<S>, T>
Iterator_of<S> find(S& seq, const T& value);

Personally, I might spend the rest of the day reading about the latest C++ standards and figuring it all out. But I bet at least 50% of the time the function gets re-implemented in a way the reader understands. (Or I say "I don't want to implement half a dozen operators so my class will meet the definition of a 'Number' just so I can call this function. It's easier to use some other function.")
I suppose Concepts may actually help with this if they make for clearer compiler errors, but still I think the assumption that parts of the language can just be ignored is slightly shaky for shared code development.

Re:Just what we needed

[mrprogrammerman]

Exactly just because it's a c++ feature doesn't mean everyone needs to use it. There are some that making developing libraries like STL easier.

Re:Just what we needed

[Dutch Gun]

That's actually a really good point. I've watched some conference talks in recent years that explained how C++ is actually two languages... one designed for library writers (where a lot of the most hard-core features are aimed, such as move-semantics or template-related features), and a simpler subset for library-users, who often just call the code that the library writers write. The real world is not quite as clean-cut as that exactly, but I think it's true to some degree, certainly.

All this makes for libraries which are incredibly easy-to-use while at the same time are both safe and efficient. In many cases, the user doesn't even have to know about all the optimizations that have been made. They can simply take advantage of the new language features like shared_ptr without having to worry about all the language features and work that went into making sure it works as naturally as though it were a built in language feature and not a library class. It's hard to describe how transformative the C++ 11/14 standard was for C++ as a language to people who still view it through the lens of what it was a like a decade or two ago. I often remark that C++ actually feels a lot like a managed language like C# now, only with much uglier syntax.

What's remarkable to me is that this was done without breaking existing code out in the wild. I joke about the ugly syntax, but a lot of that comes from the reluctance to introduce new operators and keywords, which would invariably break existing code. Many of the complaints about C++'s "bloated" nature also comes from features left in place for backwards compatibility. If I had to offer a fourth quality to C++, it would be "stability", for which we can thank the C++ design community, who (along with various working groups) have been doing an amazing job this past decade. You can see modern examples of how traumatic it is for a language-using community when backwards compatibility breaks, something that many more modern language designers don't seem to feel as reluctant to do as I think they should.

Hell, C++ 17 is only now removing support for trigraphs, for goodness' sake, an artifact of ancient keyboards that didn't support all the characters required to program C/C++. Hilariously, IBM is opposing its removal (it's already been delayed since C++ 11, largely thanks to them), which tells you that there's some rather ancient C/C++ actually living out there in the wild, as well as indicating how conservative the C++ community is in this regard.

Re:Just what we needed

[dargaud]

OK, I started reading the comments hoping to be enlightened about what "Concepts" are (Gee, another common word reused to mean something else, it's going to be great searching for that on Google), but you are the only one who even mentioned it. Everybody else is too busy fighting about the bloating of C++.
So I'll ask: what are Concepts ?!? And please talk to me like I'm a stupid C programmer...

Re:Just what we needed

[serviscope_minor]

No, but I do here people who go in to modify something say "Gosh, I wish there weren't so many different types of connectors, why does this screw have a starburst and this one a rhombus on it?"

But the engineers that make things, never go and say "oh I wish there weren't those 2000 different thread forms and sizes which all have different tradeoffs". The complexity of screws and threads is *astonishingly* huge once you start looking into it.

Even with the simple head, even ignoring the stupid security heads, there are loads of different heads all with different tradeoffs in terms of cost to manufacture, cost to manufacture the bits, camout and stripping, wear on the bits, suitability for automated driving, suitability on various material types, and so on and so forth. And that's just the driving bit. Then there's the different kind of actual head in which the driving recess fits...

Re:Just what we needed

[serviscope_minor]

A concept is pretty similar to what you might think of as a concepts. However there are two parts, the idea and the language support.

So, for example numbers are concepts. They have +,-,*,/ and, well, work like numbers. This works for ints, unsigned ints, (of all widths), floats and (now) in C complex numbers. In C++ it works for ints, floats, std::complex and some random bigint or arbitrary precision float library you might use. Basically, it's a duck-test. If it looks like a duck and quacks like a duck, then it fits the concept of a duck, and you can use it anywhere why might use a duck.

So, far that's just an idea or a spec. If you write generic code (i.e. type agnostic code) against the number concept, your code will make use of +,-,*,/ and maybe a handful of others (assignment, comparison). If you do that, then your code will work cleanly on anything that fits the concept of a number.

At the moment you can only write template code that accepts any type.

If you feed your code a vector instead, it will break in a horrible way. At some point, deep in the algorithm, you'll use something that vector doesn't do (like divide) and you'll get a an error, which gives you a stack trace of all the templates. Ideally you'd like the compiler to tell you at the point you called the function not in the guts.

The language support is basically you say "define Number concept as any type which accepts +,-,*,/ etc". Then you can say your function accepts any Number, i.e. any type provided it actually quacks like a number. If you try to provide a non-number to that function, the compiler will tell you with an obvious message.

Re:Just what we needed

[Anonymous Coward]

You will use this new feature, because the compiler will give you significantly more descriptive error messages.

And those error messages will occur "earlier". Meaning, you won't get some cryptic template error message that is buried in STL code you never wrote.

You'll get something more readable like "sort() requires a Sortable array", right at the call to sort() (that's what i mean by earlier).

Re:Just what we needed

[jaklode]

A concept is list of functions and types that must exist for some type(s). It's like Haskell's typeclasses, or traits/interfaces - but implementation is implicit, rather than explicit.

Re:Just what we needed

[DrXym]

Do you know what I never hear a carpenter saying? "Geez, look at all these tools. I wish I had fewer tools in my toolbox."

Do you know what I never hear a carpenter saying? "Geez I wish my tools had known flaws such as splintered handles and hidden razor blades that could slash my hands if I use them wrong? And I wish I had a detailed a nuanced and comprehensive set of rules for using each tool that I couldn't possibly follow. And I wish my tools were so complex and unsafe that nothing I make will work reliably without further time consuming repairs."

Re:Just what we needed

[TheRaven64]

Here's the thing. You might not want to look at this:

template <typename S, typename T>
requires Sequence<S> && Equality_comparable<Value_type<S>, T>
Iterator_of<S> find(S& seq, const T& value);

But today, you'll instead find something like this (from the C++17 spec):

template< class InputIt, class T >
InputIt find( InputIt first, InputIt last, const T& value );

You broke it because either T doesn't implement the operator== overload that compares against T correctly, or InputIt doesn't correctly implement operator++ and operator* with the (documented, but not expressed in the code anywhere) requirements of a sequential access iterator. Now, as soon as you find this you know that the first argument must be a sequence (of type S) with elements of type X, that the second argument must be a type such that X == T is well defined, and that the return value will be an iterator into S, which can be dereferenced to give a reference to an X.

If your error is something syntactic, for example you've deleted the operator==(T&) on S, then your compiler will say 'This find function can't be used with this type because you're missing this method', whereas today it will give you a cryptic error about S::operator==(T&) not being defined somewhere in a deep set of template instantiations.

Concepts give you better compile-time error checking, better compile-time error reporting, and better in-code documentation. They're one of the few C++ language features that are purely benefit.

Re:Just what we needed

[Anonymous Coward]

The guy below was wordy.... It's Constraints in template matching. Instead of matching the template and failing inside the body, concepts let you prevent matching of the template, similar to SFINAE.

template

template

etc...

Re:Just what we needed

[T.E.D.]

As a C++ programmer, I don't know if I'll ever use "concepts" in my own code.

I was just writing something last week that could have done with it. I wanted a class to iterate through ranges of an enumeration (so I can just chuck my enum ranges in those nice safe range-based for loops). Next obvious thing to do was make it a template, so it isn't restricted to just my one enum type. However, there's no way to *restrict* the template to just enums, which means I have to make up the difference with comments, and hope I was clear enough. In theory, I *should* be able to use a "concept" to enforce "this template parameter must be an enum type".

Its very simple code. The kind of stuff any CS101 student could be assigned (if they are so unfortunate as to be using C++ for CS101). And it could have used concepts.

Re:Just what we needed

[Anonymous Coward]

* It's ubiquitous. Nearly every platform has a C++ compiler, and there's a lot of sample C or C++ code available to use. It also makes hiring and training easier.
* It's efficient. You don't pay for features you don't use, and it compiles down to fast, efficient, native code.
* It's got reasonably good abstraction features that don't require paying a heavy price for that safety, enabling large, complex programs to be written more easily.

The first point is not a very good argument when comparing with C. C supports a lot of obscure architectures and ISO-C have been specifically phrased so that they can continue to be supported.
The efficiency can also be argued about. It has the capability to be efficient, but it appears to be more common that it adds a lot of overhead because the programmer didn't understand how the abstraction worked.
I would say that it is easier to look at C-code and figure out where the processing intensive parts are and where it is possible to make optimizations. Primarily because of fewer abstractions.

Re:Just what we needed

[Anonymous Coward]

C++ is a language toolbox. You can use the parts of it useful to you, and largely ignore the rest if you don't happen to need it at the moment.

The explicit keyword had to be introduced exactly because you cannot ignore the rest if you don't happen to need it at the moment, just like you cannot ignore a rat infestation that you don't happen to need at the moment.

Re:Just what we needed

[Grishnakh]

No, but I do here [sic] people who go in to modify something say "Gosh, I wish there weren't so many different types of connectors, why does this screw have a starburst and this one a rhombus on it?"

Well if people had adopted a really good screw-head standard way back, we wouldn't have this mess. We have different types because better standards have been invented, and the old ones are utter crap (particularly slotted and Philips heads). Now we have Robinson (square) and Torx and e-Torx which are much better fastener heads than what came before. Strangely, Robinsons have been around for about a century now, but only started catching on in recent years for some reason (I believe patents had something to do with it).

BTW, do you really now know how to spell "hear"? I'm seeing so many mistakes like this lately, I'm starting to wonder if everyone is using voice-to-text to compose messages, and the result is a complete mess.

Remember that for every Clever Lad who writes this code, an army of dudes has to come through and read and modify it over time.

Try removing a Philips-head screw that's been over-torqued or just from age/corrosion has gotten stuck. Now try it with a Torx-head screw. On the former, you're going to be drilling it out after stripping out the head, whereas the Torx will come right out. There's a reason we invent new standards: because the old ones are frequently shit. Just look at the early versions of Java.

That's not to speak against it- merely that as the language gets broader, supporting it becomes slower and more expensive.

Yep, there's really no way around that. The alternative is stagnation (getting stuck with a shitty old language that has demonstrable deficiencies (again, see early Java)), or having people constantly jumping to new languages that aren't much different from the old ones (which we're seeing to an extent now: Rust, Go, D, etc.), and this incurs its own costs.

Re:Just what we needed

[Anonymous Coward]

No, trigraphs are not an artifact of ancient keyboards. Or rather, that is not why IBM opposed their removal. EBCDIC does not contain characters such as { and }. https://en.wikipedia.org/wiki/Digraphs_and_trigraphs

Re:Just what we needed

[Anonymous Coward]

do you really now know how to spell "hear"?

Do you really not know how to spell "not"?

Just following gates getting rid of goto in basic

[Anonymous Coward]

should REALLY do something original here

C++ is due for deletion ...

[Anonymous Coward]

c++ is due for deletion

When a "high" level language require half a dozen or so ways to implement a cast, it's time to go.

Remember when a programming language was truly object-oriented? I mean the object was what it
produced; not itself.. Look at any C++ code lately, you see what I mean. C++ programmers care
more about the screaming during the delivery than the baby.

And we're still waiting for a decent C++ strcpy() implementation! Not gonna happen...

Jeez...

CAP === 'beatify'

Re:C++ is due for deletion ...

[Anonymous Coward]

Is there some reason std::copy doesn't work for you?

Re: C++ is due for deletion ...

[Anonymous Coward]

You are aware of the differences between the various kinds of casting in C++, right? There are different variants because there are different situations that can arise, and they need to be handled properly.

C++ isn't complex because its creators want it to be. It's complex because the real world is complex. Just because you aren't aware of this complexity doesn't mean it doesn't exist. It does exist, and C++ is there to deal with it.

Re: C++ is due for deletion ...

[DrXym]

No. C++ is complex because it's a 30 year old language sat on top of a 45 year old language. It made some terrible, unsafe design choices that affect code to this day. Rather than correct mistakes such as deprecating bad / unsafe conventions, or defining C++ profiles that compilers honour to elevate warnings to be errors, or just generally tidying up the language, they keep heaping more and more stuff on top of what's already there.

Re:C++ is due for deletion ...

[TheRaven64]

When a "high" level language require half a dozen or so ways to implement a cast, it's time to go.

Of all of the criticisms of C++, this one makes the least sense. Different casts in C++ have very different semantics and one of the worst things that a programming language can do (and which C++ does in many places) is give you the same syntax for different semantics. Are you taking the same set of bits and interpreting them as a different type (typesafe languages don't need this because they don't permit it)? Are you explicitly removing a const qualifier and thus declaring that you know what you're doing when you do something that might break the invariants of an interface (similarly, not permitted in typesafe languages)? Are you saying create a new instance of the target type initialised from this one?

Remember when a programming language was truly object-oriented?

I still use some that are, but C++ is not one of them. If you try to write Smalltalk-like code in C++, you will write almost as bad code as if you try to write C-like code in C++.

Re:C++ is due for deletion ...

[brantondaveperson]

Good idea. Let's rewrite Python, Java, Javascript, clang in something else. I think perl is still written in C, and gcc is too, so those would be OK.

C++ strcpy() implementation!

strcpy is C. C++ uses std::string, which solves your strcpy problems, whatever they might be.

Anything that keeps

[Anonymous Coward]

American jobs for Americans. Send all the H1-B indo-chimp street shitters back to the third world! God bless President Trump.

Re:Anything that keeps

[Anonymous Coward]

"Too often, we judge other groups by their worst examples while judging ourselves by our best intentions" -- George W. Bush

1985 Called

[Anonymous Coward]

Bjarne Stroustrup, I appreciate your continuing to improve C++ and all that. But really, if "Concepts [...] are intended to complete C++'s support for generic programming as initially envisioned," maybe Concepts should have been included in the language definition in 1985 or thereabouts?

The heyday of C++ was a long time ago now. Practitioners of C++ will probably welcome this enhancement. However if this completes Stroustrup's original vision for the language, this is late, very late in the day. Maybe too late.

Another SLOW Language

[Anonymous Coward]

Another slow addition to an already slow language.

Just program in Java. Java already supports "concepts", this is just another way C steals from Java in order to make it relevant, and appear fast.

Java is the language of the future.

We will all be programming java, using java runtimes written in java, running on java runtimes written in java, because recursion [a concept!] makes things faster!

Re:Another SLOW Language

[BarbaraHudson]

Another slow addition to an already slow language.

Just program in Java. Java already supports "concepts", this is just another way C steals from Java in order to make it relevant, and appear fast.

Java is the language of the future.

We will all be programming java, using java runtimes written in java, running on java runtimes written in java, because recursion [a concept!] makes things faster!

Java runtimes are written in c/c++. Java needs a runtime written in another language because java cannot "self-host".

Re: Another SLOW Language

[Anonymous Coward]

Maybe you are thinking of C++ from a decade or two ago? Not so now.
https://www.quora.com/Generally-how-much-faster-is-C-compared-to-C++

Re:Another SLOW Language

[Anonymous Coward]

Obvious troll is obvious.

Re:Another SLOW Language

[Anonymous Coward]

Java sucks. It was designed by idiots for idiots. You're an idiot if you use it not just because it sucks technically, but because Larry Ellison will make you his towel boy sooner or later.

Re:Another SLOW Language

[Anonymous Coward]

> Java needs a runtime written in another language because java cannot "self-host".

It's JVMs all the way down!

Re:Another SLOW Language

[TheRaven64]

That's not necessarily true. Smalltalk VMs have been written in a subset of Smalltalk that is statically compiled for a while, and these days the JIT parts are written in the full language. In the case of Java, the sun.misc.Unsafe package include pretty much everything that the JVM needs to be able to do in terms of bypassing its own safety guarantees to be able to self host. In Jikes, the JIT and GC are written in Java. The main reason that JVMs are written in C/C++ is that you don't get much benefit from writing the bit of code that is explicitly allowed to violate a language's invariants in that language (and it makes bootstrapping harder).

Re:Another SLOW Language

[BarbaraHudson]

Who cares what the JIT and GCC are written in? In the end, the actual code has to run on a runtime - it can't run itself. Hence the need for a JVM. If Java could compile to runable binaries instead of byte code, you'd have a point, but it doesn't.

Re:Another SLOW Language

[TheRaven64]

The JIT and the GC are the two parts of the VM that must be able to escape the constraints of the language model (the JIT must be able to generate executable code, which the Java security model doesn't permit, and the GC must be able to allocate memory and assign it a type and delete objects that are still reachable). Absolutely everything else in a JVM can be implemented in Java fully respecting the language model. You can write almost all of a JVM in Java, as long as you have a small amount of statically compiled Java code that is treated as trusted and so permitted to violate the language invariants. This is precisely how Smalltalk VMs are typically written. There is no requirement for C/C++ to implement Java, it's just an easy way of doing it.

Re:Another SLOW Language

[BarbaraHudson]

And yet as of Java 8, nothing in the JVM is written in Java. It's all c/c++. Almost 250,000 lines.

Obligatory Stroustrup "interview"

[Latent Heat]

https://www-users.cs.york.ac.u...

"Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought 'I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers? "

I reckon

[Anonymous Coward]

I reckon he's starting to go a bit ga-ga. What next, incantations? Almost as bad as Android's java-except-it-isn't with its motivations or whatever it calls signals & slots.

Re:I reckon

[BarbaraHudson]

Look at the bright side. It might just be enough for people to take their skills back to the land of C instead, and actually learn how to manage memory instead of depending on all sorts of smart/weak/whatever_ptrs. And bye-bye to the STL and the GoF.

Re:I reckon

[Anonymous Coward]

Indeed, this always bugged me about those touting RAII as the one-true-way and at the same time hating on both manual memory management AND garbage collection.
Do they even know that their beloved shared_ptr uses refcounting, and is thus a form of garbage collection, of the worst kind?

Re:I reckon

[Jeremi]

Why would they go back to C, when they could instead just stick to using whatever subset of C++ that they find useful?

The fact that feature X is available doesn't mean you are required to use it.

Re:I reckon

[The Evil Atheist]

Why would we want to do something the compiler can do? There is no bragging rights to stupidly doing what a compiler can do. I can know exactly the scope of some malloc'd buffer, but so can a wrapped type like a vector. Why would I possibly want to waste time writing and testing/valgrinding to make sure every malloc is freed when the compiler can automatically call the destructor for me?

Only idiots brag about doing excessive work.

Re:I reckon

[arth1]

Why would we want to do something the compiler can do? There is no bragging rights to stupidly doing what a compiler can do. I can know exactly the scope of some malloc'd buffer, but so can a wrapped type like a vector. Why would I possibly want to waste time writing and testing/valgrinding to make sure every malloc is freed when the compiler can automatically call the destructor for me?

Because you have information that the compiler doesn't have. Like what's vital code and what's gilding, and how to prioritize based on business needs. You can free up non-critical code allocations early to avoid background gc impacting performance, or re-purpose already allocated memory in critical code to reduce overhead, or a large number of other techniques that are available because you know more than the compiler.

Why do anything that a machine can do? Because in many circumstances you can do it better. Use automation where useful, but when you have knowledge that the automation lacks, use it. Whether you're driving a car, cooking a meal, composing a song, or writing a program, use your special knowledge and skills. If you think a black box can do it better than you can, you're probably right. And ripe for being replaced.

Re:I reckon

[The Evil Atheist]

You can free up non-critical code allocations early to avoid background gc impacting performance

Nothing in C++ stopping from doing that. That's what scope based resource management gives you automatically. In C++, you allocate in the precise scope you need it and when that scope ends it's freed for you. You don't even have to think about impacting gc performance. You kind of proved my point that a compiler just makes that easier while sacrificing none of your control.

or re-purpose already allocated memory in critical code to reduce overhead

Again, nothing in C++ stopping you from doing that. In fact, move and perfect forwarding makes it even easier to repurpose resources but without sacrificing the deterministic destruction. And you STILL don't have to waste time writing clean up code.

Because in many circumstances you can do it better.

None of yours were examples of that and in fact shows its better to leave it to the compiler because it's a waste of productivity in most cases. And given the amount of access bounds and resource management errors in C code written today, it is a fact that it is not better to leave it to humans.

Re:I reckon

[Anonymous Coward]

Because C works everywhere and C++ adds a lot of poorly standardised (in practice) dependencies wile adding very little that is of any actual use.

Re:I reckon

[BarbaraHudson]

Because each person will probably want to use a different subset, so eventually you end up with code that uses a lot more c++ than you ever intended, which means everyone has to be aware of all the peculiarities of all of c++, the stl, etc.

Consistency is a virtue.

Re:I reckon

[BarbaraHudson]

It's not excessive work if you just remember what your mother told you - if you take it, put it back when you're finished with it. Memory management isn't that hard once you keep that in mind. Programs should be deterministic. You don't need valgrind if you know what you're doing. Then again, the same people who think that it's okay to write random shit and then test it in the hope of detecting leaks would freak out if they ever had to write in assembler.

Re:I reckon

[The Evil Atheist]

C++ destructors are deterministic. It isn't that hard of a concept.

Having to write clean up code more than once, ie outside of a destructor, is excessive work. I can write a vector, with one destructor, knowing everywhere the vector is used, its destructor will get called when its scope has ended without me having to write it. Deterministic and an efficient use of my time.

Whereas with malloc, you have to write free every single time afterwards.

Do the maths.

And what about shared ownership? Very common pattern in user interfaces. Look at the mess C UI frameworks are with their manual reference counting.

Seriously, if in this day and age you can't understand that scope based resource management is deterministic, maybe you should seriously consider actually learning the concept.

Re:I reckon

[BarbaraHudson]

The destructor is called when the code goes out of scope. YOU can't determine that since you don't determine when there are no more references to the code, unlike a call to free(), where it doesn't matter what code owns it, it's gonna happen - so you'd better know when it's no longer being used anywhere. Also, if UI frameworks are a mess, blame the authors. It should always be possible to know with 100% certainty which piece of code "owns" the resource. There should never be a question of "dangling pointers".

And you SHOULD write free() every time you write malloc(). Allocate it in one place, use it, free it. Anything else is just begging for problems. As I said, if you take something, put it back when you're done. Even Java runs faster if you expressly call the garbage collector when you're done and have only thousands of objects to check to see if they can be deleted rather than waiting for the GC to pile up a million objects and then decide that "oops, I need to free up some space, lets walk those million objects, oh wait, let's lock up the whole UI for 30 seconds because this sucker is running on a computer with a YUGE amount of ram and we took it all .."

Re:I reckon

[Delwin]

Seems to me like you've never worked on anything large enough that one person can't do it all.

... or anything with libraries.

Re:I reckon

[BarbaraHudson]

Seems to me you're making suppositions without any evidence. There are plenty of projects involving lots of people that didn't use automatic memory management - pretty much all those old programs that got the home computing industry off the ground, when using c++ exclusively would have been far too slow, and way too memory-bloated.

Re:I reckon

[The Evil Atheist]

YOU can't determine that since you don't determine when there are no more references to the code

Yes you can. Most things are not shared pointers, and shouldn't be shared pointers. Most C++ Standard Library objects are decidely NOT shared pointers but use RAII. Get with the times - that was the case since C++98, but apparently you won't bring yourself to accept it. Hell, even in C++98, the "smart pointer" library type was auto_ptr, which is decidely NOT shared, and that's been superseded by unique_ptr, which is NOT shared, which was based on Boost's scoped_ptr, which is NOT shared. Keep staying stuck in your pre-98 knowledge

And you SHOULD write free() every time you write malloc().

Yes, you should, if you're writing malloc and free. But if a compiler can call the equivalent of free for you every time, why stupidly keep doing it yourself? I call "free" every time I "malloc" because I create and/or use types which make that happen automatically. AND THEY DO NOT SHARE REFERENCES. Get that through your head please.

Also, if UI frameworks are a mess, blame the authors.

No, UI frameworks written in C are a mess. Frameworks like Qt are just fine, WITHOUT the use of shared pointers. But, hey, keep ignoring that point because it's inconvenient. Even Linus changed his diving software from GTK to Qt, even though he hates C++. He could not find a UI framework he liked written in C, that's how bad it is.

It should always be possible to know with 100% certainty which piece of code "owns" the resource. . . . Allocate it in one place, use it, free it. Anything else is just begging for problems.

Yet tools like Valgrind exist because that's what C programmers need. In a perfect world, everything would work perfectly. You should be complaining about the world not being perfect.

Even Java runs faster if you expressly call the garbage collector when you're done

Yes, and even better is if I don't even need a garbage collector, especially a mark and sweep garbage collector because I'm NOT using shared resources almost all of the time.

Re:I reckon

[BarbaraHudson]

RAII is wrong. It's sloppy. Stop drinking the kool-aid. And I stopped using valgrind a couple of months after I started using it. Write code properly, you don't need valgrind or ANY other memory leak detectors. Also, valgrind introduces bugs because it changes the running of your program, especially multi-threaded code. I never used any sort of garbage collection or STL classes in c++ - I alloc(), I free(), and f*ck new and delete. Not needed, same as templates, same as all the modern build tools, the whole "we have a problem to solve that no language solves, so let's invent yet another language", shit like ruby, the gazillion javascript libraries, etc.

Call me when your *nix OS is written in c++ - then we'll talk.

Re:I reckon

[The Evil Atheist]

RAII is wrong. It's sloppy. Stop drinking the kool-aid.

How would you know? Judging by our conversation, it's obvious you know nothing about it. You obviously stopped learning C++ long before the 98 standard, or you didn't bother to learn something properly.

I never used any sort of garbage collection or STL classes

You use garbage collection. You just stupidly write code that a machine could do for you because you have gross misunderstanding based on an unwillingness to learn.

Not needed, same as templates

Templates can make code faster than C code. Just compare std::sort to qsort. Templates allow high level optimizations not possible with pointer based "generic" code. Templates aren't needed, but they're better.

Call me when your *nix OS is written in c++ - then we'll talk.

Whatever. The compilers used to build those C Unixes are written in C++. GCC has been compiling as C++ for a while now, but you probably didn't want to know about it either.

same as all the modern build tools, the whole "we have a problem to solve that no language solves, so let's invent yet another language", shit like ruby, the gazillion javascript libraries, etc

We are talking about C++ here, so the whole "let's invent another language" doesn't EVEN apply here. But trust you to not bring up any points of relevance.

Re:I reckon

[BarbaraHudson]

C++ keeps inventing new features. It's one of the best examples of bloat going.

And you clearly don't understand templates if you claim that template code runs faster. All template code does is allow the precompiler to generate code that could also be generated in other ways, such as by a script. The resulting code runs at the same speed in either case. As for sorting, you can write different sorting routines based on the data and needs that are faster than anything you'll find in std::sort.

Re: I reckon

[Anonymous Coward]

Why do you keep talking about free () and malloc() in a C++ discussion? You are thinking of C.

Re:I reckon

[The Evil Atheist]

C++ keeps inventing new features. It's one of the best examples of bloat going.

Hey, you can keep living in the stone age if you want. Things were simpler then in the good ol' days.

And you clearly don't understand templates if you claim that template code runs faster. All template code does is allow the precompiler

I don't understand templates? You're calling it a "precompiler". Templates don't run in the precompile stage. Macros run in the precompile (or preprocessor, rather) stage. Templates require the full type information that is generated as the compile process goes along. Preserving type information allows for checks and optimizations that are not possible with void pointers, or pointers in general.

generate code that could also be generated in other ways, such as by a script.

And yes template code does run faster because of the "generated code". THAT IS THE POINT. Not just a moment ago, you were decrying the creation of new languages blah blah, and here you are talking about writing scripts to generate code. Where do you think those new languages come from if not because of people like you who would rather do more work for little benefit because it fits into some extremist ideology?

As for sorting, you can write different sorting routines based on the data and needs that are faster than anything you'll find in std::sort.

In case you didn't know, TEMPLATES can choose different routines based on the data. That's the whole point of templates. eg, you can have a generalized copy-range function, but depending on the compile time type, have it choose a fast copy using compiler intrinsics. That's the point of the std::sort example. Not because std::sort is the one and only sort, but because it is a demonstration of templates. Templates provide the ability to have tailored optimal algorithms without having to keep writing zillions of slightly different interfaces, or use void pointers and lose type information.

Re:I reckon

[Anonymous Coward]

Sure, and go back to using containers that store everything as void*, or use some macro-based abomination for typing? No thanks.

Re: I reckon

[BarbaraHudson]

Originally, new and delete were just wrappers for malloc() and free(). History - it provides context - and both malloc() and free() still work just fine in c++ - or did you forget that because you're wilfully blind? Same as you thing that std::sort will be quicker than bsort()?

Re:I reckon

[BarbaraHudson]

Check again. Template code is generated before the translation to machine language stage. And I'd rather invoke bsort() directly than depend on a template getting it right - because knowing the type of data isn't going to also know that the data is ordered in such a way that bsort() can be used, which is far quicker than qsort() or any other algorithm. You need to know that the data is ordered properly, or bsort() won't give right results - and the compiler CANNOT know that.

Re:I reckon

[BarbaraHudson]

Or don't use containers, duh!

Re:I reckon

[The Evil Atheist]

Check again. Template code is generated before the translation to machine language stage.

First, the "compile" stage is not just the code generation phase. The semantic analysis is pretty much part of the compile phase. Second, The type information preserved by templates can aid in the code optimization stage.

You need to know that the data is ordered properly, or bsort() won't give right results - and the compiler CANNOT know that.

Whoop de do. You can write a generic bsort in C++. You can write a generic algorithm anything. But please, keep missing the point as you keep doing.

Re:I reckon

[BarbaraHudson]

And YOU miss the point that a human, having better knowledge than the compiler can ever have (no, your "semantic analysis" won't tell the compiler to use bsort()) can do better with a smaller footprint, so fewer code paths to verify, fewer side effects, easier to check for and handle corner cases, etc.

Not my fault that YOU aren't that human. And that IS my point, at this point. You want one size fits all, because that's all you know.

People like you are the reason that people think running Doom in a web browser is somehow cool, even though it runs slower on a machine with 5,000x more cpu instructions executed per second than a 386, 2,000x more ram than that same old 386, 2,000x more video ram, but oh look - web.

Re:I reckon

[The Evil Atheist]

And YOU miss the point that a human, having better knowledge than the compiler can ever have

Which is why there are no bugs, ever.

You want one size fits all, because that's all you know.

Explain why I know Java, Javascript, Python, LISP, assembly, plain-C, REXX, awk etc

People like you are the reason that people think running Doom in a web browser is somehow cool

Why would a C++ programmer want Doom to run in a web browser?

Re: I reckon

[Anonymous Coward]

std::sort IS often quicker than bsort. If your compiler can't inline the comparison (which it often can't when using function pointers), then std::sort is almost guaranteed to be faster. Not only that, bsort() is far uglier and less type safe.

Re:I reckon

[Anonymous Coward]

Which is why std::unique_ptr exists, and should be the default - you shouldn't reach for std::shared_ptr unless you know you need shared ownership.

Re:I reckon

[Anonymous Coward]

I honestly can't tell if you're trolling or not at this point. If you think having a library of data structures at your disposal is bad, and don't want to use them, then all I can say is I'm really glad I don't have to work with you.

Re: I reckon

[Anonymous Coward]

Eh, I meant to refer to qsort above. bsort is a much narrower domain, and is thus far less useful. However, it is asinine to compare a general sorting routine to a specialized O(n) radix sort. Nothing is stopping you from implementing this in C++ either, if you actually need it, or - shock horror - just using the bsort code directly if you have POD.

Re:I reckon

[BarbaraHudson]

That's the great part - bug counts are going to be far lower if you HAVE to have complete knowledge of what's going on. And you take that one-size-fits-all approach to everything you do, no matter what the language. You just follow the crowd, never thinking outside the box. And seriously, awk? What next - brag about knowing grep? That's just stuff that comes with the territory, same as framing a house, it's assumed you know what a hammer is and which end to hold.

Re:I reckon

[The Evil Atheist]

That's the great part - bug counts are going to be far lower if you HAVE to have complete knowledge of what's going on.

Publish your solution to the halting problem and then we'll talk.

And you take that one-size-fits-all approach to everything you do, no matter what the language.

Coming from the person who obviously thinks everything should be written in C.

And seriously, awk?

Wow, you've seriously lost it in your old (mental) age. You tried to criticize me for supposedly only knowing one language. Then I proved you wrong. Instead of accepting that you come up with yet another non-sequitur. The fact I have used multiple languages to do what is needed is proof I don't have a one-size-fits-all approach.

Remember: YOU'RE the one who went of on a headless chicken rant about young'uns inventing new languages left right and center, but at the same time maintain the cognitive dissonance to also hate people who want to add new features to a language to avoid having to invent new languages all the time. Sort your own cognitive dissonance out first.

I'm done talking to you. This whole discussion has basically been about you being an old fuddy duddy who not only hates learning anything new, but wants people to stay stuck where you are. Here's an idea: FUCK OFF. Why are you even here? If someone wants to add to their language, IT DOESN'T AFFECT YOU.

Re: I reckon

[BarbaraHudson]

bsort is a much narrower domain, and is thus far less useful.

bsort() is used anywhere you have indexed data, unless the implementors are complete morons. It's been that way pretty much since the beginning - it's the obvious choice for searching sorted data.

Re:I reckon

[BarbaraHudson]

Why use a whole library when you can do it quite easily with a page of code that is simpler, specific to the task at hand, and you don't have to worry about hidden side effects because you don't have to audit the whole damn library to find that one little piece makes the whole thing not thread-safe?

Re:I reckon

[BarbaraHudson]

Actually, I *did* publish my solution to the halting problem, under my original account, years ago. Got into a nice argument with an engineering grad student who couldn't find a hole in it.

Re: I reckon

[Anonymous Coward]

Searching sorted data...you mean bsearch, not bsort.

Re:I reckon

[Anonymous Coward]

You aren't writing a thread-safe, cross platform implementation of any kind of moderately complex data structure in a page of code in C, and any assertions to the contrary are complete and utter horseshit.

You seem to have a serious case of Not Invented Here syndrome.

Re: I reckon

[BarbaraHudson]

You're right. It's been years since I've been able to code ... (wasn't able to read for a couple of years, had a concussion (and probably seizures from too low blood sugar - 0.9 is scary low, a personal record) that put me out for almost 2 hours, since then all attempts have failed until this week, where it appears to SLOWLY be coming back. Not the algorithms - they never left. Just the "okay, I'm sitting in front of the computer, I want to write some code, start the editor, ... blank - nothing happens." Happened for a year back in the '90s after a sexual assault, the mind can be a strange thing.

Re:I reckon

[BarbaraHudson]

Are you fucking sick? The differences between freebsd and linux are a few header files and some conditional includes - works fine on both platforms. Or do you think that it's mandatory to include windows when writing server software? Which would make you doubly sick.

In Putin's Russia

[Latent Heat]

New features force . . . you!

Seriously, people, you may decide to forgo those features, but you may be "forced" to maintain code using those features that you need to figure out what that code does.

Re:In Putin's Russia

[The Evil Atheist]

Then learn the new features. What's the problem? You learn a new language when one annoys you too much. This is a different issue from C++ altogether. Java 8 has some new features. Learn to use them. Perl 6 has new features. Learn to use them. Javascript, Go, Rust, Swift, whatever - tell me what language doesn't acquire new features over time that you have to learn and maintain?

"I'm too scared to learn new stuff" is a stupid attitude.

Re:In Putin's Russia

[lucm]

tell me what language doesn't acquire new features over time that you have to learn and maintain?

VBScript. I guess they got it right the first time.

Re:In Putin's Russia

[The Evil Atheist]

Great. Now let's all write everything in VBScript because people are too scared to learn new stuff. Oh way, learning VBScript will be like learning new stuff!

Re:In Putin's Russia

[roca]

The problem is that the set of features offered by C++ is absolutely enormous. Many of them are features you probably shouldn't use (e.g. "volatile", or throws specifications, or wchar_t, or virtual base classes), but are there for legacy reasons. Most projects define a subset and try to stick to it, but the subset varies from project to project so you inevitable have to learn the old crappy stuff.

C++ exhausted its complexity budget long ago and is now deep into deficit spending.

Modern languages give you power without the cruft.

Re:In Putin's Russia

[The Evil Atheist]

Why shouldn't you use volatile, especially if you're writing hardware interfacing code?

Most of the new C++ stuff actually reduces the "complexity" budget. Type deduction outside of function interfaces greatly simplifies most everyday code. I find using C++11 and 14 and then going back to C++98 or 03 or TR1 actually helped understand the older stuff without much effort.

Re:In Putin's Russia

[roca]

The problem is that it's all additive. You can write simpler code with the new features than the old features, but the old features still exist and are still being used.

Some old uses of volatile should be replaced with atomics. You're right there are still some valid uses of volatile.

Re:In Putin's Russia

[lucm]

In small doses, writing VBScript is a guilty pleasure. It's like snorting coke; you only do it on special occasions and you know it's bad for you, but it's still enjoyable for a limited time.

Is it true?

[140Mandak262Jamuna]

I heard Stroustrup used to post regularly in comp.lang.c++ and engage in huge protracted flame wars with newbies. I was a FORTRAN guy those days, and so I don't know first hand. Could not find such postings in the typical archives. Is it true, or just some stories bandied about him?

Re:Is it true?

[Anonymous Brave Guy]

I never saw that in the many years I was working primarily with C++ and a regular reader of the related newsgroups. When Bjarne did contribute in any forums I followed, he generally seemed direct and reasonable, and it was usually in the more advanced discussions about tricky areas or the future of the language.

Re:Is it true?

[140Mandak262Jamuna]

OK, thanks I will correct people spreading such rumors.

Re:Is it true?

[Anonymous Coward]

Can you tell when Bjarne comments here on his own stories?

Re:Is it true?

[Anonymous Coward]

I never saw that in the many years I was working primarily with C++ and a regular reader of the related newsgroups. When Bjarne did contribute in any forums I followed, he generally seemed direct and reasonable, and it was usually in the more advanced discussions about tricky areas or the future of the language.

See, when someone tries getting to the bottom of things and difficulties and argues reasonably about minor ascents one needs to overcome in order to reach the global minimum and yet consistently ends up on the highest mountain ranges of the world, you need to shut out his "reasonableness", stop it from poisoning your mind, and restart from scratch without enlisting the help of him or his followers.

C++ has not evolved to become simpler. Not in 10 years, not in 30 years. Not ever since the first ARM was posted by Ellis/Stroustrup. Every new standard gets mind-numbingly more complex. And this proposal is not going to help in that respect. When the shit hits the fan, you'll still have the internals of your libraries flying in your face and sticking there, just with an occasional piece of teflon thrown in.

Hipsters

[Anonymous Coward]

A bunch of hipsters using computers designed with C++, running a kernel written in C++, using graphics libraries written in C++, through keyboard drivers written in C++ that are sitting in a chair that was manufactured with mostly C and C++ code.... of course with internet mostly going through BSD/Linux systems both of which were written with mostly C++.

But we're glad to know their little C++ program that runs their code is so cool that they think they can get rid of C++.

Re: Hipsters

[Anonymous Coward]

Unices are written in C.

Re: Hipsters

[x0ra]

GCC & clang are written in C++, Windows' kernel is written in C++, python is written in C, linux in "object oriented" C (there is plenty of template/virtual-table/inheritance/constructor/destructor code).

Re:Hipsters

[Anonymous Coward]

Linux systems both of which were written with mostly C++

Linux is written in C.

Re:Hipsters

[Anonymous Coward]

The original C library for Linux was written in C++ by H.J. Lu. But the GNU C++ compiler was too immature and the resulting library was full of bugs because if that. Upon realizing the tools weren't up to it, H.J. Lu switched development to standard C.

Re: Hipsters

[Anonymous Coward]

The 'C++' in which GCC s written is well over 99% C. The maintainers switched to compiling in C++ mode a while ago, but the code itself uses very little C++ that is not also C.

Re:Hipsters

[x0ra]

Linux systems both of which were written with mostly C++

Linux is written in C.

In appearance, yes, but they rely on all kind of compiler extension to really use an object-oriented C, for example __typeof__() to mimic templates. It's also full of function pointers, overload, inheritance, etc.

Re:Hipsters

[serviscope_minor]

In appearance, yes, but they rely on all kind of compiler extension to really use an object-oriented C, for example __typeof__() to mimic templates. It's also full of function pointers, overload, inheritance, etc.

And of course the compilers used to compile it are written in C++ now.

Re:Hipsters

[Anonymous Coward]

Linux is usually compiled using GCC, which is compiled in C++ mode, but written in C.

Re: Hipsters

[TheRaven64]

Device drivers in XNU (iOS / macOS) are also typically written in a subset of C++.

Re: Hipsters

[Anonymous Coward]

Yeah I write in assembler and use on a very little Visual Basic.

Re:Hipsters

[Anonymous Coward]

> Linux is usually compiled using GCC

Make that 'always' - the system source is so heavily tied to GCC I hesitate to even call it standard C.

Re:Hipsters

[Anonymous Coward]

In appearance, yes, but they rely on all kind of compiler extension to really use an object-oriented C, for example __typeof__() to mimic templates. It's also full of function pointers, overload, inheritance, etc.

And of course the compilers used to compile it are written in C++ now.

Not any more.

like Windows?

[Anonymous Coward]

Well, when I was thinking about programming languages a long time ago, I have come to a grudging respect for Windows, and backwards compatibility. Really good compilers, IDEs and debuggers will take many man years before production code can be made. In order to get that fancy stuff, you need a really big market to justify all that expensive development. That god scripting languages don't require such complicated tooling, and one has choices. I'm looking at you Javascript!

Not good enough!

[jd]

I want him to roll in the additions from Cilk++, Aspect-Oriented C++ and FeatureC++, the mobility and personalisation capabilities of Occam Pi, the networking extensions provided by rtnet and GridRPC, full encryption and error correction code facilities, everything in Boost, and a pointless subset of features from PL/1.

If you're going to do it all, might as well do it in style.

Seriously, though, Aspects would be nice.

Re:Not good enough!

[The Evil Atheist]

The fact that the C++ committee still rejected Concepts shows they're not willing to add in any old feature because reasons.

Funny how other languages don't get shit for actually including parallelism, networking, GUI, XML, JSON, etc into their standard library.

At least in C++ if you don't need those libraries, you don't have to still download/install a huge runtime environment, or rely on online package managers that have to be up all the time.

Re:Not good enough!

[Anonymous Coward]

I want him to roll in the additions from Cilk++, Aspect-Oriented C++ and FeatureC++, the mobility and personalisation capabilities of Occam Pi, the networking extensions provided by rtnet and GridRPC, full encryption and error correction code facilities, everything in Boost, and a pointless subset of features from PL/1.

You haven't been paying attention to what the C++ committee did the last decade, I take it. Way ahead of you.

Re:Not good enough!

[Anonymous Coward]

I want him to roll in the additions from Cilk++, Aspect-Oriented C++ and FeatureC++, the mobility and personalisation capabilities of Occam Pi, the networking extensions provided by rtnet and GridRPC, full encryption and error correction code facilities, everything in Boost, and a pointless subset of features from PL/1.

If you're going to do it all, might as well do it in style.

Seriously, though, Aspects would be nice.

After adding all that, it'll be the perfect language for re-implementing systemd! [ducks]

Re:Not good enough!

[Peter La Casse]

This is the second time I have found someone "in the wild" who thinks Aspects are a good idea. It inspired me to log in after all these years. It seems to me that Aspects are a maintenance and debugging nightmare. Not that there aren't plenty of those already. The main use seems to be letting a developer use printouts to poorly mimic a proper debugger. What is nice about them? I'm willing to be convinced.

Re:Not good enough!

[Anonymous Coward]

The fact that the C++ committee still rejected Concepts shows they're not willing to add in any old feature because reasons.

Could probably be made more complex yet.

Funny how other languages don't get shit for actually including parallelism, networking, GUI, XML, JSON, etc into their standard library.

At least in C++ if you don't need those libraries, you don't have to still download/install a huge runtime environment, or rely on online package managers that have to be up all the time.

Being able to put stuff into a library rather than having to fscking extend the core language with yet-another bolt-on syntax and associated semantics is a feature, not a bug.

Re: Not good enough!

[jd]

Damn, you have a lower UID than me. Hey, on Slashdot, that's a pretty good test of credibility!

Seriously, I get bothered a lot by mixed model software, as it's very hard to keep straight what the programmer intends (and worse for the compiler, the nonsense that compilers magically work it all out is just that, stacks don't manage themselves and optimization - which has always been one of the black arts - isn't simplified by ad-hoc paradigm mixes).

When it comes to using a single paradigm, always choose the one that makes robust code the easiest to write. Forth is still used because there's a lot of hardware programming that is far, far easier with stack operations than procedures or objects. No matter what the current generation of whippersnappers think.

So, the question reduces to this. Is there a class of problem that is better done with aspects? If so, you need it the same way you need Forth. And even Ada.

how about modules?

[ooloorie]

How about first fixing something much more basic, like modules?

Re:how about modules?

[Anonymous Coward]

Really. After doing a little Ada programming, or even java with interfaces, not having a hard separation between interface and implementation is infuriating.

Re:how about modules?

[ckatko]

I've been playing around with D for a year or so and it features 99% of the stuff you wish C++ had. Modules are one of them.

Plenty of the features in D end up in C++... except (literally) more than ten years later.

The same thing everyone always bitches about D (as a reason for not trying it), is the garbage collector. But GC isn't actually required and can be disabled entirely or for critical sections. The standard lib uses GC but there's no reason someone couldn't bother to write an identical GC-free one... there's just no incentive for the existing community. You can also use data types that are not seen at all by the garbage collector and go RAII till the sun goes down. The power is yours to decide.

Don't get me wrong, it's not a perfect language. But the language itself is .1% of the problems you'll encounter. The other 99.9% of the problem is the relatively small (but very helpful!) community, lack of tutorials and references, relative lack of D-specific libraries. When Javascript, C#, C++ and whatnot, you can literally google "C" + [any topic], and get pages of tutorials with great ones at the top. With D, there are much fewer and you'll end up with questions that don't have easy Google answers like "What does double colons mean here?"

But as for the language? Man, I love it. INTEGRATED UNIT TESTING. Compile-time evaluation of complex functions. Built-in 2-D/3-D arrays. Built-in dynamic and static arrays. Static if statements. Contract programming. Ranges beat iterators. Immutable types (which are NOT the same as const, which can be cast away.) Pure functions. Array slicing. constructors named this() instead of classname() so you can rename them simply. No stupid .h/.cpp file. No extern. NO CIRCULAR OR FORWARD DEPENDENCY PROBLEMS. Parsing is TWO PASS. So you don't have to forward declare a class that uses another class... ten lines lower in the damn file. I mean what is this, 1978? Support for directly calling C code, (and direct C++ is supported in a fork called Calypso.)

I could spend PAGES going on about each feature I learned and when I had a eureka moment for each one going, "MY GOD. THAT'S SO MUCH EASIER/MORE POWERFUL."

I'm currently building up a framework basis for a moderate-sized game and I'm honestly having _fun_ writing this D code. I don't spend time writing boilerplate. I spend my time writing code that does stuff.

I honestly hope, and can't wait, for the day that D becomes more popular.

Re:how about modules?

[Anonymous Coward]

But... can you declare your own number types and have operator overloading without objects in D? And how lame would it be to have to use "critical sections" for my whole project if I don't want all of that fancy OOP jazz

Re:how about modules?

[TheRaven64]

You can't really have a clean separation between interface and implementation in C++ without radically redesigning the compiler model. Class and function interfaces are simple, but when you throw in templates then you need to be able to have access to all of the code needed to construct a new instance of the template. The original 4Front C++ compiler did this by a horrible dance of trying to compile the code, catching the linker errors, generating code for the missing symbols, and repeating. Modern C++ compilers just generate a copy of every template that a compilation unit needs and expecting the linker to throw away the duplicates (which is why something like LLVM ends up with over a gigabyte of .o files for a 10MB binary). A lot of newer languages get around this by simply not supporting shared libraries, so you can ship the code (or some IR) along with the interface files and your compiler can generate specialised versions at static link time, or by including a big VM so that everything is distributed as some form of IR and you compile on demand.

Re: how about modules?

[Anonymous Coward]

I thought it was called cfront not 4front

Re:how about modules?

[ooloorie]

Roughly speaking, modules in C++ are a replacement for include files, not shared libraries, so the limitations of shared libraries aren't relevant. Compiler support for modules is somewhat like a combination of cproto and precompiled headers. Making that work is not rocket science, just a lot of tedious work for all the weird edge cases. VisualStudio, gcc and clang support this already in one form or another. And it needs to happen. It's a lot more important than "concepts".

Re:how about modules?

[TheRaven64]

Yes, modules as proposed for C++ (which don't give you what the grandparent wanted: a clean separation between interface and implementation) are pretty easy. Clang has mature support for them and even some logic to implicitly generate modules from headers. They give you a compilation speedup, which is sorely needed for C++, but not the benefit that the grandparent was looking for, though they do at least require that you don't litter your headers with #ifdefs (which means C++ and C can't share modules).

Agreed. I've moved on.

[Traf-O-Data-Hater]

I used to be a C/C++ dev, and wrote a lot of COM objects for the financial space back in the day. The ten different ways to cast something was becoming a pain to deal with.
I was tasked to evaluate .NET/C# for my company in about 2001, liked what I saw and moved over to C# with a short stint in Java along the way, and I have NEVER looked back. Writing LOB applications is all about delivering functionality for the end user. In C# I've designed the most, developed the most and maintained the most applications I've ever managed to do in my 30 year career in software development.
Beautiful generics, LINQ, clean looking code, interoperability with legacy code, ultra-rich APIs and a rock-solid dev environment, ECMA-standardised are clear winners for me and C#.
A greybeard trying to breathe new life onto a now 30 year old language he put together doesn't surprise me, but C++ is never going to get the attention it once had. Sorry Bjarne, I saw it all before with Bertrand Meyer trying his darndest to keep Eiffel relevant. Same thing's happening with your baby, sorrry to say.

Re:Agreed. I've moved on.

[Chuck Messenger]

C# and C++ do not cover the same application space. C++ is a bare-metal language. C# requires a large stack, which is suitable for enterprise software but not for performance or embedded software.
Therefore, one can not say C# > C++, or C++ > C#.

Re:Agreed. I've moved on.

[Anonymous Coward]

COM/OLE was an abomination. And "Inside OLE" was one of the most miserable technical books ever written, partly because it was the only book from MS Press (i.e. authoritative) on COM for a long time.

MFC, which many companies used for COM support, was absolutely the worst piece of garbage API which ever obtained widespread adoption. Everyone involved in creating that should be banned from the software industry for life.

So I don't think your experience was representative of C++ programming.

Re:Agreed. I've moved on.

[Nemyst]

Ha, you wish. As much as I love C#, there will always be a need for a low-level language that makes zero performance compromises. Games alone ensure that there will be significant demand for it. It might not remain C++ forever, but all of the new languages intending to replace C++ have thus far failed to gain sufficient traction to do so.

For most business applications, C#, Java, Python or even JavaScript are gonna be fine. When you need high performance, they turn into severe limiting factors.

Re:Agreed. I've moved on.

[Dutch Gun]

I can never figure out why people don't understand that different applications have different requirements, and as such, there will NEVER be a single "best" language. Even in the videogame industry, C# and other managed or scripted languages are often used for tool development, while C++ is nearly always used for engine and game code.

No one with any sense expects it to be the most *popular* language. But there are literally billions of lines of working C++ code out there. At this point, C++ is ubiquitous enough that it will never really die. Or at least, certainly not before I do.

Re:Agreed. I've moved on.

[The Evil Atheist]

Except Microsoft, Google, Facebook, Intel, Bloomberg, and many other companies are giving it more attention as the standard moves on. C++17 is on track, with all the major compilers having implemented most of the features already. Standardization is almost moving to become a mere formality, and most of the design and implementation testing is done at the compiler level years before the next standard.

As for ECMA-standardized C#, C++ is ISO standardized, and there's no possible patent threat with it.

Re:Agreed. I've moved on.

[Anonymous Coward]

As the other AC said, your problem was with COM and MFC, not C/C++.

Re: GAY NIGGER FUCKS ASS WRITTEN IN C AND C++

[Anonymous Coward]

This is actually how the GNAA spawns new members. For years, a requirement for joining their group was to first post this spam on slashdot, and it may still be the case. They are a group of dual classed hacker/trolls. As with all the posts, you could be witnessing the birth of a new member, an old member being bored, or a nonmember who just wants to fuck over discussion if possible. In general, it will get modded all the way down, and often deleted. But anyway, this is what these posts have looked like for years.

Alias Templates?

[Anonymous Coward]

The concept stuff seems all well and good, but I was a little horrified at
template<typename X> using Value_type<X> = X::value_type;

I'm sure there are good uses for this language feature, but in this case it just looks like he wants it to be angled brackets all the way down.

Like Ada 83

[Anonymous Coward]

So, 2020 is the year C++ finally catches up to Ada wrt generics?

Sounds overly complicated

[Kjella]

The key difference between this and interfaces in Java seems to be push vs pull, does a class explicitly declare that it is say sortable or do you just check if it has functions that match something that's sortable. If you look at the example he does on page 8 with Shape.draw() and Cowboy.draw() sure you could be more explicit in the template requirements or you could demand that the cowboy explicitly has to say he's "drawable". To me Stroustrup's idea sounds a bit too much like the story about the blind man and the elephant, if you only touch it in enough places you can be sure it's an elephant. The obviously problem is that once you have a birth defect or amputee with only three legs, it all fails.

For example I might like to define a class "SequenceNumber" that has functions like setInitialValue(), getNextValue() etc. but lacks typical characteristics of a number like being able to add and subtract them, but I can still sort sequence numbers. If it's explicit I only have to declare it sortable and implement the necessary functions. If it looks at the "concept" number it'll say nope, you're not a real number because we can't add two of you together.

This could be trivially avoided by having the possibility to supplement class definitions as implementing additional interfaces, like here's a library with the Circle shape header and I say it's a drawable even though it doesn't say so itself. It'll still have to actually fulfill the interface, but that way you're not bound by the ones supplied by the library. Since that's purely a synthetic check on whether your code should be able to call that code I don't see how that should be a problem.

Re:Sounds overly complicated

[Pseudonym]

The key difference between this and interfaces in Java [...]

...is that algebras in Java are single-sorted, whereas in C++ they are trying to be more multi-sorted.

The primary purpose of an algorithm (or a program, for that matter) is to transform data from one form to another form. Simula-style object orientation, as you find in Java (and in the OO part of C++), associates operations with a single type. This is the least-common and least-useful case, because the interesting parts of programs almost always involve more than one type.

One key thing about the C++ concepts proposal that a lot of people miss is that it many templates have more than one argument. So it's not just a single type we're talking about here, but also associating related types.

So it's not just "adding an interface after the fact". (Although that's a useful feature in itself; how many times have you needed to "decorate" a type from a library whose source code you don't own?) It's bringing the concept of a "class" closer to what that word actually means.

Of course, Haskell's typeclasses are even better.

Re:Sounds overly complicated

[w1z7ard]

I don't think your break down is what this is really about, although perhaps I'm misunderstanding you. There are few concepts (cough...) at play here. One is whether the language itself supports a notion of duck typing or not. Java generally doesn't. You must explicitly implement an interface to adhere to it, and even if your class has methods which do implement it, the compiler still will generate an error or the runtime a class cast exceptions if you attempt to treat it as the desired interface.

If you were to implement concepts in java, I imagine it would have to be permitting a cast as mentioned above by the compiler, rather than treating the types as different. Note that both interfaces and concepts have same compositional power, except that concepts end up being more flexible, as you are generally only enforcing the type in the scope of a particular algorithm, not a class, even if many classes end up supporting the concept.

Back to C++ land. Templates in C++ incidentally fit into a duck typing oriented model, *unlike* Java. Thus, concepts almost existed to provide order to somewhat unwieldy compiler errors from the template system and provide explicit design clarity for those implicit utilizing concepts previously.

Finally, IMHO, modules (and module signatures) implement the idea of concepts quite elegantly (eg. in OCaml).

Re:Sounds overly complicated

[Anonymous Coward]

The analog to a Java interface in C++ is a base class containing only public pure virtual functions, and possibly typedefs. IWBNI C++ supported the "interface" keyword, but avoiding keyword bloat has been part of the C++ culture from the beginning.

Re:Sounds overly complicated

[Anonymous Coward]

For example I might like to define a class "SequenceNumber" that has functions like setInitialValue(), getNextValue() etc. but lacks typical characteristics of a number like being able to add and subtract them, but I can still sort sequence numbers. If it's explicit I only have to declare it sortable and implement the necessary functions. If it looks at the "concept" number it'll say nope, you're not a real number because we can't add two of you together.

If I was trying out a new library sort function that required the concept "is a number", I would throw it out and find one written by someone who is actually smart enough to write an efficient and generalizable sorting function. Sorting should only require a < operator, that items can be safely swapped, and random access iterator or indexing for the container it is operating on. Overly restrictive concepts is an implementation error, not a flaw in the language feature.

Re:Agreed. I've moved on. collect your garbage NOW

[Anonymous Coward]

The real problem with C# is forced garbage collection. For your case, it may not matter, but in large memory needs I've seen GC run 30% of my CPU. Sure, you can find ways to pin memory - reuse it - but then you complain about "10 different ways to cast", which frankly is a stupid complaint compared to GC.

C# is fine for many. For performance cases where lots of memory use is required, to name just one, it's not a good choice.

This is obvious...

[__aaclcg7560]

"In my opinion, concepts should have been part of C++ 17, but the committee couldn't reach consensus on that."

No wonder C++ is a mess. Where's a benevolent dictator when you need one?

Re:This is obvious...

[lucasnate1]

C++ is also a mess because it has to support backward compatibility for a huge amount of code already written for the industry. Blaming just the commitee for it is ignoring history.

Re:This is obvious...

[__aaclcg7560]

C++ is also a mess because it has to support backward compatibility for a huge amount of code already written for the industry.

Wouldn't that be a problem for the compiler than the language?

Blaming just the committee for it is ignoring history.

A benevolent dictator could pull a Python by declaring a new version C++ that cleans up the language and is mostly backwards compatible.

Re:This is obvious...

[lucasnate1]

Wouldn't that be a problem for the compiler than the language?

No, because whenever you add new syntax, you have to avoid breaking compatibility with old syntax. For example, every time you add a keyword, you risk messing up code that had variable with the same name as the keyword. The same is true for language semantics imho.

A benevolent dictator could pull a Python by declaring a new version C++ that cleans up the language and is mostly backwards compatible.

And just how successful python 3 is? In every shop I worked in, they insisted on using python 2.

Re:This is obvious...

[Grishnakh]

It doesn't need to be that backwards-compatible. When you compile C++, you can easily set the compiler to use a particular standard (c++0x, c++11, c++14, etc.).

So if you have old code, simply direct your new compiler to follow the older standard instead of the latest one. You don't need to drag everyone else down.

Re:This is obvious...

[Grishnakh]

No, because whenever you add new syntax, you have to avoid breaking compatibility with old syntax.

No, you don't. You just need to tell your compiler to use the older standard. GCC does this with the --std= flag. If your code won't work in C++17, just add "--std=c++0x" or something.

And just how successful python 3 is? In every shop I worked in, they insisted on using python 2.

The problem with Python is they didn't do it like C++. To run a Python2 program, you actually have to have a Python2 interpreter/runtime and libraries compatible with it. You can't just take the latest Python3 interpreter and pass it a "--std=python2" flag and make it work. So you end up having to have two entirely separate and parallel installations of Python. It's a big mess. C++ isn't like this; you can even compile your libraries with a different C++ standard than your application code or each other, because the linker will resolve the linkages.

The problem isn't backwards compatibility, the problem is that Python did a terrible job of making a new version of their language.

Re:This is obvious...

[lucasnate1]

Here we agree. I don't understand what's the problem with the standard defining something like this:

    #include <no_backward_compat>

GHC Haskell has something similar that forces you to specify dangerous and obsolete language features that you want to use. It can easily be applied to C++ as well. The weird thing is that I never even heard of someone offering this.

Still no template definition checking :-(

[roca]

Concepts lets you check that the parameters of a template instantiation satisfy the template's requirements. However, it doesn't let you check that the *definition* of a template is valid whenever the parameters satisfy the template's requirements. So it's really only solving half of the problem.

Re:Still no template definition checking :-(

[Pseudonym]

That's true, but Boost already has facilities for that.

Re:Still no template definition checking :-(

[roca]

You mean the archetype stuff?

> The validity of the archetype class test is completely dependent on it being an exact match with the concept, which must be verified by careful (manual) inspection.

Sad.

Re:Still no template definition checking :-(

[Pseudonym]

Yes. That's the nature of STL concepts. Unlike Haskell typeclasses, it's not enough just to see that there are operations with the right types, because STL concepts are often defined in terms like "this is a valid expression, which returns a value convertible to bool".

Re:Infection

[Beeftopia]

Only the poorly educated say 'learnt' in the US (it's 'learned') here, but using a 't' for past tense is a legitimate British grammar construct. I've seen terms like this in respected British publications. More here.

My experience with expressing unusual concepts

[hackwrench]

I want people to not think they understand me when they don't more than I want them to understand me due to the odds involved, so I choose slightly harder to understand constructions. People generally come back with the notion that I am stupid, and that I think my statements are too brilliant for the average mind.
By no means. I think that if the average mind takes an honest stab at what I am trying to convey and asks for clarifications they can readily come to understand what I intend to get conveyed. Very few have gone that route, though.
But anyways the concepts expressed by those people aren't that out of reach and just require some dictionary lookups and Google searches that require reads of still other articles. By this approach the meaning of just about anything becomes substantially clearer.

What Trump does

[hackwrench]

Trump does tend to oversimplify so that his followers only think they understand. If the parent post meant to say that Trump is like a child who only thinks he understands, that is not the case, but the former is pretty true.

Re:What Trump does

[Anonymous Coward]

Trump is completely irrelevant to the subject at hand. Using his name is just a feel good cheap shot to seek approval from the 'in' crowd.

I have two editions

[hackwrench]

I wanted one I didn't get. I forget exactly which two I have, but besides the one in C there is one in C++ and one in Java. If I recall correctly I have the C and Java one. I think I bought the C one myself and added the C++ edition to my Amazon gift wishlist, but my Aunt thought she had a better idea to buy a newer edition. My wishlist now contains only things that it doesn't matter about editions.

I'm happy with C++

[Anonymous Coward]

Since C++11, I feel c++ has been on a roll with a lot of great new stuff (a lot ported from boost, of course).

But I think the syntax is not improving. I use C++17 extensively. My brother is starting to learn C++, coming from other languages. I don't think looking at my code is going to help him get started. For example, I use SFINAE, which could have been implemented in C++ with a clear syntax as opposed to using weird looking template/struct constructs.

Re:Language Wars

[hackwrench]

Because everybody knows that QB64 is the most productive language to program in. There's a huge library of code that will compile in it and IBM samples included with DOS will compile with it. Compressed files with IBM DOS and the aforementioned samples are available on the net. https://www.bing.com/search?q=...

Re:Just what we needed C++

[Anonymous Coward]

Please see this: http://www.medicaldaily.com/10...
You will notice there are 10 parts (organs) you don't need in your body that we don't need. But nature put it there so if has to reprogram people, it has the tools. C++ evolves and your own needs do not over ride the needs of others. Natural Language like English has lots of redundant words etc. Now if you specifically show how a feature has affected 2 or more application in your life, then it will prove either you did not understand the tool or took it for granted. Just deeply think and write. Robustness does not include absoluteness which with one single error will destroy the whole system. Head ache never kills you. but that is part of having head and the enviornment.

enough with the pedantic attitude

[lucm]

Seems everyone I run into these days who says "I'm a software engineer" has zero CS instinct

That's because software engineering has very little to do with computer science. A software engineer solves real-world problem with software.

How many cops do you run into these days that have more than the strict minimum knowledge of the law needed to do their job? Does that make them incompetent cops, or is it possible that maybe a different skill set is required?

If you want to stick to academia and horse around in labs that depend on grant money and alumni, knock yourself out, nobody is stopping you - there will always be a need for abstract thinkers. But out there in the real world, people must build things on time and on budget, and while we all wish that the best algorithms and the most elegant code is the way to achieve that, when push comes to shove, shipping the product is what pays the bills and if that means ugly code, then ugly code it is. Do you think the POS software on the cash register that allowed you to buy grocery this week is a masterpiece, or that the algorithm that decides when and how to to take over your car brakes is flawless? No, it's probably full of bugs and hard-coded passwords and antipatterns. But guess what, you still got that food in your fridge and you've made it alive on the freeway. Good. Enough.

Re:enough with the pedantic attitude

[Anonymous Coward]

Somebody find what this guy works on and his hard-coded password, stat.

Re:enough with the pedantic attitude

[serviscope_minor]

If you want to stick to academia and horse around in labs that depend on grant money and alumni, knock yourself out, nobody is stopping you

No one will stop you, apart from the people who you know actually dish out grant money. Academia is now fiercely competitive. If you think you can simply get grants and horse around, you have no idea what is required to make it as an academic these days.

Re:enough with the pedantic attitude

[Anonymous Coward]

"Good. Enough."

Ah, the cry of the "programmer" who churns out barely functional junk. Let us know how you get on after your non-job is automated.

Re:enough with the pedantic attitude

[Anonymous Coward]

the brake code is a terrible example.

Re:enough with the pedantic attitude

[Anonymous Coward]

I agree about getting things done but you are missing a key viewpoint.

It's like using metal vs wood. Sure wood is easier to use, work with, faster, etc.... But some projects absolutely require using metal.

Some people have been obsessed with coding on a single project long enough to realize some other points that are almost *never* brought up here. After going long enough you eventually run into road blocks that revolve around using wood and not metal.

I built a massive OpenGL 2D application for managing robotic systems in python. Despite coding it cleanly and neatly, the language kept biting us in various ways. Breaking things up into modules didn't really help, it was just that all the new logic was slowing down the system more and more. I started having to cache things in odd places and use various hacks to lazy-load things. It started becoming a real mess. It was hard to lock down against reverse engineering. Even the py2exe stuff just dumps the code into a wrapped file, ripe for unpacking. I started wanting to do more and realized I couldn't, the app had basically reached scale.

In C++ these problems never even appeared. None of that horrid hacking was required. The project could be grown and it didn't really effect the speed at all. Certain types of bugs are now compile-time errors. I could guard off places where others may make errors with better const handling. The code was actually more readable and easier to make assumptions about since I'm not crazy with globals/operator overloading/various tricks/etc. With discipline you can write code that almost looks like other languages, giving each class it's own file, always use headers for every class cleanly breaking definition from implementation. CMake build system makes it easier to produce shared libraries from the same code that runs the UI....

Sometimes a project is just more demanding and requires more structure and less impact from scaling up. C++ should really be looked at....

Re:enough with the pedantic attitude

[Anonymous Coward]

Fierce competition is a problem for sales people. Engineers do not care about competition.

Re:enough with the pedantic attitude

[Anonymous Coward]

Sure - but to stick with your analogy - I think people are complaining that the cops don't even know the laws. I constantly meet people in IT who don't even know the basics (if I have to tell one more person how to use telnet to check if a port is open, or how to open up cmd to ping a server, I'm going to shoot myself in the head).

Re:Infection

[The Evil Atheist]

Just because you never encountered the variant "learnt" in your small world doesn't make it wrong, idiot.

Yes But

[inhuman_4]

The concepts thing sounds interesting. But when will C++ run on Node.js and MongoDB? That's the real question.

Re:Yes But

[Anonymous Coward]

It already does:
https://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html

Re:Yes But

[JustNiz]

If you're writing in C++, why would you need node.jss?

Why not Ada?

[Anonymous Coward]

Why not simply, get rid of curly braces, restrict C compatibility, and just rename it to Ada while you are at it...

C# Type Constrains

[Anonymous Coward]

Something like C# Type constraints on generics?
public class Vector where T: IComparable

https://msdn.microsoft.com/en-us/library/d5x73970.aspx?f=255&MSPPError=-2147217396

C++ is for writing libraries

[Laxator2]

The problems appear when people with no technical background make the decision of which language to use for a particular project. They base their decision on what they heard from friends or on the latest buzzwords. For example Scala is now imposed on some projects simply because of the word going around that it is the latest and greatest thing.

Experienced developers have already agreed that C++ is great for writing libraries. Personally I use it because I can do everything I need with one language. Handling large data trees, SSE optimizations, OpenGL graphics, all in the same language, but these are all one-person projects.

Go to any large organization and look at a C++ code base developed over 20 years by a team of kept to a size of about 50 developers, when each developer spent an average of 2 years on the job. After a while you can identify what different developers tried to learn on the job.

By the way, I saw similar code bases, but developed in Java. They look just as bad as the C++ ones, and the managed environment which prevents crashes makes the bugs more difficult to find.

Re:Infection

[Anonymous Coward]

In my country we use "learnt" to specify the past tense of learn and "learned" (with emphasis on the -ed) to specify a person with high academic credentials.

Re:Infection

[Anonymous Coward]

What is supposed to be wrong with that statement? It is quite common to say thant one has learnt a programming language when one knows the grammar and the syntax of a language and is able to write code in it.

Haskell

[lucasnate1]

In Haskell both 'concepts' and 'virtual function interfaces' have the same name and syntax, 'type classes'. The only thing that differentiates between them is a pragma called SPECIALIZE which decides on which implementation to used. It is too bad, but not surprising, that C++ insists on forcing duality where it is not needed.

Re:Haskell

[anarcobra]

Pretty much. I'm sure that this new concepts thing is an improvement over whatever they have; but when I compare it to the equivalent in Haskell I almost want to cry. The way they do it in Haskell seems so much cleaner and less of an after thought.
Any type simply declares that it implements Ord, or Show, or whatever you need, and then functions can declare that they require a type to implement that.
Of course Haskell has it's own problems with error messages not being entirely useful and code being slow as shit if you don't know exactly how to optimize.

Re:Haskell

[lucasnate1]

Actually, if you enable {-# LANGUAGE IncoherentInstances #-}, type classes gain much of the problmeatic semantics of C++, it's just that this is disabled by default, which is good.

Re:Haskell

[Anonymous Coward]

It's true that C++ concepts are much like Haskell typeclasses. I'd say that's a good thing!

There's a detailed comparison of the two here: http://dl.acm.org/citation.cfm?id=1411324&dl=ACM&coll=DL&CFID=892273769&CFTOKEN=59889597 . It dates from 2008 so it might be a little out of date.

Re:Haskell

[Anonymous Coward]

This is (potentially) not so different:

        template <typename T>
        concept bool orderable =
        requires(T a, T b)
        {
                {a < b} -> bool;
                {a > b} -> bool;
        };

compared to:

        class Ord where
                (<) :: a -> a -> Bool
                (>) :: a -> a -> Bool // Rest of Ord typeclass

So while a Haskell function might be something like:

        foo :: (Ord a) -> a -> a -> Bool

With concepts it'd look like:

          template <typename T>
          requires orderable<T>
          bool foo(T a, T b) { ... }

(This is just using the proposed concepts syntax, if and when it becomes standardized, it may be different).

The major difference is of course that typeclasses are basically a dictionary keyed on types that gets passed in at runtime, while concepts are entirely a compile time feature that is basically there to cut down on the template error garble that you get when using a template with a type that doesn't satisfy the required operations. Concepts are more "open" in that a type doesn't need to declare that it "implements" a certain concept, which will help enormously with backwards-compatibility.

Re: GAY NIGGER FUCKS ASS WRITTEN IN C AND C++

[Anonymous Coward]

aah look. an 18 year old telling a 16 year old how to drive.
Look here kid. I've been on here since 98. the gnaa and the trolls are a part of the magic that is this site. we do want them here, and it's not spam. grammar nazis are spam. the gnaa adds spice.

and by the way, no, posts on this site don't get deleted. period. go back to reddit dipshit.

GCC has it.

[FithisUX]

"Concepts are already available in GNU C Compiler 6.2," So, it is a standard :-)

Feynman was good at choosing the subject ...

[Laxator2]

... such that it would be amenable to have a simple, self-contained explanation. He avoided the more hairy subjects.
He did not go over the structure of the proton, or QCD and try to make those accessible.

And for the more accessible subjects other physicists have done a great job at explaining them as well. Landau and Kitaigorodsky come to mind.

Complication

[Anonymous Coward]

I'm sorry but I don't see how adding more to a language will simplify things and make code better. Teach good programming practices. Teach COMMENTING! Teach by example. Don't teach programmers to be lazy and use the simplest tools but teach them to use the best tool for the job.

relevant xkcd

[Anonymous Coward]

Standards

https://xkcd.com/927/

Creator of C++ Worried About Efficient Code?

[BrendaEM]

C++ is many things to many people, but efficient? I don't agree.

Re:Creator of C++ Worried About Efficient Code?

[Anonymous Coward]

C++ is many things to many people, but efficient? I don't agree.

Spoken like someone who has never implemented anything of import in C++ and is parroting something they read on the internet one time.

Re: GAY NIGGER FUCKS ASS WRITTEN IN C AND C++

[Anonymous Coward]

actually, I take that back. I troll, but the race and sexuality issues are real, and putting up with this stuff, even if it's a long-running meme, just normalises something awful. I don't know if I want a deletion system, but I shouldn't have been so antagonistic, so sorry about that.

I'm an old man who's trying to do better in a world that's a lot more sensitive than it seemed when I was young, but, y'know, anonymity on the internet, it brings out the worst in us.

Re:Just what we needed C++

[Grishnakh]

First, those 10 things aren't "organs", they're just features. Your fingers aren't organs either, even though you probably need them to function normally every day.

Secondly, the article is partly wrong. For #1, it even admits that the "third eyelid" is useful for ensuring tear drainage and sweeping debris away. #9 is flat-out wrong: the appendix, while not essential to life, is very useful when you have big problems with your GI system. It's basically like a first-stage bootloader for your gut bacteria. You may never even need it, but when you do, it's really useful. #10 isn't a misfeature, it's a by-product of the way we develop as embryos. Take away male nipples and you lose female ones too, which really do have an important function. Eliminating them without losing the female ones would probably require a significant re-engineering of the genetic code, which doesn't happen with an evolved system. #4 sounds like #9: calling something "useless" because we don't fully understand it yet. Maybe we really do make good use of the ability to detect pheromones (or then again, maybe it causes us to make terrible choices for dating/marriage partners). For #3, I've read some people claim that armpit and pubic hair does serve some important function WRT bacteria, I forget exactly what now. It may have some truth or may be bunk, I don't know, but as seen with #9 and our complete lack of understanding until very very recently the role of gut bacteria (such as with its effect on obesity), it does seem like our medical sciences have largely overlooked the roles of bacteria on human health over the years.

So back to C++, just because you don't see the need for a feature doesn't mean that it's actually useless. A good example here is the 'volatile' keyword. It's useless in most C++ programming, but absolutely essential if you're doing low-level hardware access on an embedded system.

Re: As someone with a masters in this -exact field

[Anonymous Coward]

The mark of someone looking for mastery is the humbleness to know that you don't know everything and seek wise people.

Arrogance and over-confidence leads to poorly designed software that changes frequently and pisses off the customers. We call that "Web Software".

Haskell Type Classes

[Anonymous Coward]

I think he just reinvented Haskell's type classes. Good, they're a useful concept.

Good enough is good enough

[lucm]

"Good. Enough."

Ah, the cry of the "programmer" who churns out barely functional junk. Let us know how you get on after your non-job is automated.

"Good enough" means fit for purpose. If you go beyond that you're not solving a business problem, you're feeding your OCD on the company's dime, like an office manager that puts barcodes on office chairs.

Nail it then scale it

[lucm]

I see nothing wrong with your OpenGL example. You basically used python to flush out requirements and determined that you needed a more robust language to get you to the next level. That's the "nail it then scale it" approach, which is pure engineering.

If for no other reason

[awol]

Than to replace those 50 lines of template compile errors to something the poor sucker who has to try and understand someone else's template code can actually read, yet alone understand. I vote !Yay!

Re:Infection

[michael_wojcik]

Only the poorly educated say 'learnt' in the US (it's 'learned') here, but using a 't' for past tense is a legitimate British grammar construct.

I don't know when I've seen such a glide from prescriptivism to descriptivism in a single (albeit compound) sentence before. Perhaps in Bryson's book on English. (As a professional crank, Bryson's good at freely mixing fact and opinion.)

In any case, DARE[1] shows some regional use of "learnt" in the US, and I dare say[2] that you'd have a difficult time demonstrating that every such use was by someone who is "poorly educated" by any reasonable standard.

Certainly use of the -t suffix has been declining on this continent for more than a century, though in English as a whole the trend is not so clear. And it's not just the past-tense inflection of verbs, as the rarity of "whilst" in this country shows.[3]

[1] The Dictionary of American Regional English, the unassuming name for a mammoth project to catalog regional differences in English usage in the US.

[2] Heh.

[3] Etymologically "whilst" is "whiles" + -t, where -t is still in effect a suffix indicating the past tense. But "whilst", a synonym for "while", is pretty much always used grammatically an adverb, even if etymologically it's the simple past tense of "to while" (as in "while away the time"). All this thanks to the eagerness with which English users move words among parts of speech.

If you need generics with type constraints

[PJ6]

than you shouldn't be using C.