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 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?

[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?

[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?

[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?

[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?

[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]

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-

[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-

[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-

[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-

[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-

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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.

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 ...

[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.

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? "

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.

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: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.

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!

[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!

[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.

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.

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?

[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?

[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: 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.

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: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.

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: 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: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: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.

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.

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=...

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

[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]

the brake code is a terrible example.

Re:Infection

[The Evil Atheist]

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

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.

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

[JustNiz]

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

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: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.

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...

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.

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.

GCC has it.

[FithisUX]

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

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: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: Hipsters

[TheRaven64]

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

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.

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: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: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: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.

Creator of C++ Worried About Efficient Code?

[BrendaEM]

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

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: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: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.

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.

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.

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: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: 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: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.

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: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

[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: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.

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.

If you need generics with type constraints

[PJ6]

than you shouldn't be using C.