C++ Creator Wants To Solve 35-Year-Old Generic Programming Issues With Concepts (cio.com) 339
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."
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."
A new fad? (Score:2)
Re: (Score:2)
he said generic, not genetic.
Re:A new fad? (Score:5, Informative)
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? (Score:2, Interesting)
So, a concept is just a fancy name for an interface or an abstract class?
Re: (Score:2)
Re: (Score:2)
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? (Score:5, Informative)
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? (Score:4, Informative)
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: (Score:3)
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: (Score:2, Informative)
You're obviously new at reading. t != r
More features. (Score:2, Insightful)
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. (Score:4, Insightful)
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: (Score:3, Insightful)
Re: (Score:2)
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: (Score:2)
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. (Score:5, Informative)
Re: (Score:3)
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 ofte
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
That compiler explorer web site is really cool.
Re: (Score:2)
That's what C++ needs: More features!
True. The guy should go and write more Seinfeld episodes instead.
Re: (Score:2)
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: (Score:2)
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 (
Re: (Score:3, Interesting)
[...] 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. (Score:5, Interesting)
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 [cppreference.com]. 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.
Epicycles (Score:5, Insightful)
Re: (Score:2)
Obligatory Stroustrup "interview" (Score:2)
https://www-users.cs.york.ac.u... [york.ac.uk]
"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? "
Re: (Score:2, Funny)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
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: (Score:3)
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 transferrin
Re: (Score:3)
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 eas
Re: (Score:3, Interesting)
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: (Score:2)
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. [oxforddictionaries.com]
Re: (Score:3)
like Windows? (Score:2, Interesting)
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!
Just what we needed (Score:4, Funny)
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 (Score:4, Insightful)
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 (Score:5, Insightful)
> "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 (Score:5, Insightful)
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.
enough with the pedantic attitude (Score:5, Insightful)
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: (Score:2)
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.
Good enough is good enough (Score:3)
"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.
Re:Just what we needed (Score:5, Insightful)
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 (Score:4, Insightful)
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: (Score:2)
So I'll ask: what are Concepts ?!? And please talk to me like I'm a stupid C programmer...
Re: (Score:3)
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, th
Re: (Score:2)
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,
Re: (Score:2)
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 fundament
In Putin's Russia (Score:2)
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: (Score:2)
"I'm too scared to learn new stuff" is a stupid attitude.
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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 po
Re: (Score:2)
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: (Score:2)
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.
Not good enough! (Score:4, Funny)
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: (Score:2)
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.
how about modules? (Score:3)
How about first fixing something much more basic, like modules [meetingcpp.com]?
Re:how about modules? (Score:4, Interesting)
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? (Score:4, Interesting)
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.
Sounds overly complicated (Score:5, Insightful)
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 [wikipedia.org], 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 (Score:4, Insightful)
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 [wikipedia.org].
Of course, Haskell's typeclasses are even better.
Still no template definition checking :-( (Score:3)
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: (Score:2)
That's true, but Boost already has facilities for that.
Re: (Score:3)
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: (Score:2)
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".
Yes But (Score:2)
C++ is for writing libraries (Score:2)
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
Re: (Score:2, Troll)
make feel who? Yourself? If so, I can understand...
Re:As someone with a masters in this -exact field- (Score:5, Informative)
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: (Score:3)
That's often the case - but sometimes, people really are morons :-)
Re: (Score:2)
There's always the "why didn't I see that before - it's so obvious" moments that make you feel like a moron.
Re: (Score:2)
Re: (Score:3)
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- (Score:5, Interesting)
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: (Score:2)
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: (Score:3)
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: (Score:2)
"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 w
Re: (Score:3)
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 rea
Re: (Score:3)
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
Re: (Score:2)
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 [wikipedia.org] are easy to understand, and very useful.
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
Only idiots brag about doing excessive work.
Re: (Score:2)
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 bett
Re: (Score:2)
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
Re:Is it true? (Score:5, Informative)
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: (Score:3, Insightful)
Agreed. I've moved on. (Score:3, Interesting)
I was tasked to evaluate
Re:Agreed. I've moved on. (Score:4, Insightful)
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: (Score:2)
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: (Score:2)
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
Re: (Score:2)
As for ECMA-standardized C#, C++ is ISO standardized, and there's no possible patent threat with it.
Re: (Score:3)
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 doi
Re: (Score:2)
Re: (Score:2)
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.