Classy move: C++ 20 wins final approval in ISO technical ballot, formal publication expected by end of year C++ 20, the latest version of the venerable object-oriented programming language, has been unanimously endorsed in ISO's final technical approval ballot. It awaits a "final round of editorial work," following which it will be formally published, expected to be "towards the end of 2020." A major new version of C++ comes every …
Don’t get me started on the number of features on Ccrapcrap. When I first encountered Ccrapcrap, I thought I was a bit thick when I couldn’t remember all the gazillion ways to do a simple task. Over the years, I realized that it’s not me but that can of worms. Yeah, it must be much better now after 30+ years of development and all, but Ccrapcrap is still Windows of programming languages. The whole thing is not only a PITA, but Big-Unlubricated-Throbbing PITA.
Bring it on.
When I first encountered Ccrapcrap, I thought I was a bit thick when I couldn’t remember all the gazillion ways to do a simple task
You were probably right. Someone a bit less thick would only need to remember the easiest and most straightforward way to a simple task, and then just lather, rinse, repeat....
So you would rather C++ be unchanging, forever, born in a state of perfection meaning no changes are necessary to the language in the decades ahead to meet programmers' needs?
All you need to do is look at the relative numbers of users of Eiffel, Smalltalk, Simula 67, or whatever other perfect language you care to mention to see how well that would work out. C++ would turn into one of those languages or another version of Objective C - nobody uses them unless they're forced to.
So you would rather C++ be unchanging, forever, born in a state of perfection meaning no changes are necessary to the language in the decades ahead to meet programmers' needs?
Better to dump obsolescence periodically and start again.
That's why we don't all just use Fortran with loads of new features added.
"So you would rather C++ be unchanging".
I don't see what you are getting at at all. Languages should be well designed in the first place. Even well-designed languages can undergo change. Even Eiffel has. Alan Kay has said he expected that Smalltalk would have been improved on by now.
But C++ started in a particularly bad place and has needed massive improvements, the to follow all the machinations of those 'improvements'. The excuse that C++ is evolving and becoming better is a pathetic excuse for what was not a very good language in the first place.
C++ rode on the popularity of C, and the popularity of C is also misplaced.
As far as I can tell there was no other language around which was as popular as C was which could cope with software of operating-system level complexity, certainly none of the examples of languages given here. So C was probably the best place for C++ to start.
If you're saying the popularity of C was/is misplaced then you don't understand why C was and is popular. You still can't write operating systems in Pascal, at one time that supposedly was a contender for C's crown.
C++ built upon this foundation. It was not perfect, but it got results, exactly like C, which is why C and C++ are popular. Other languages might have feature A, B, and C but not all of them. If they're useful then C++ will incorporate them and carry on. The other languages certainly won't be in any hurry to incorporate each other's features, let alone features from C++.
C++ does not aspire to be some perfect representation of an object-oriented language. There is no perfect language, not C++ and not the rest. The others either 1) have barely managed to get out the academic stage, trapped in constant debates about the best way to do things with a moribund user base or 2) are scripted or need a JIT VM or 3) are owned by some megacorp. C++ is the only language which is not owned by anyone, compiles into object code, and has new features which the user base are pushing for. The ones that are getting somewhere (Go, Rust) are getting somewhere due to their similarity to C++.
Pascal could manage a glorified bootstrapper with a GUI, which I guess is an improvement in MS-DOS, but Apple moved away from Pascal with the move towards co-operative multitasking and PowerPC.
See also Why Pascal is Not My Favorite Programming Language.
Dan 55: >>Pascal could manage a glorified bootstrapper with a GUI, which I guess is an improvement in MS-DOS, but Apple moved away from Pascal with the move towards co-operative multitasking and PowerPC.
See also Why Pascal is Not My Favorite Programming Language.<<
Apple moved to NeXT and OS X. So?
And the Kernighan paper – most of it I agree with. But most C people take it too widely and think that it applies to any language with Pascal-like syntax, and that is an excuse to remain in the C black hole. Kernighan's paper is not an excuse just to ignore everything else – it is about some very specific things about Pascal, very notably having array sizes as part of a type, which is wrong.
Kernighan's paper is not permission or exhortation to just ignore everything else.
Many of Kernighan's complaints were addressed in commercial Pascal implementations.
Nope, I was talking just about Pascal.
Apple moved away from a toy language as the moved away from a toy operating system.
The problem is that there is no standard in commercial Pascal implementations, each one solved the many and varied problems in their own way meaning there was no portability, while the language itself remained pristine and unsullied and unusable so the academics were happy.
Meanwhile, in the real world, C and C++ evolved, and all compilers supported the changes (even VC, eventually).
Dan 55: "while the language itself remained pristine and unsullied and unusable so the academics were happy.
Meanwhile, in the real world"
You have this false division between academic and real world. While you persist in that false belief and distinction there is no discussion to be had with you. You live in some kind of 'fool's hell'.
Programming is an intellectual activity. It is based on computational models and virtual machines, some of which are implemented in electrical circuits.
You just want to feel like you can dismiss anything else as not being 'real world'. That is a narrow and silly view.
Computing must improve and move on and if that is a move to academic purity, that is a good thing.
Dan 55 "See also Why Pascal is Not My Favorite Programming Language."
There is another thing here that C people treat whatever Kernighan, Ritchie, and Stroustrup have written as some kind of holy scripture and last word on the subject.
Like I said, Kernighan has a lot of things right in that paper (which I have read several times over the years), but it is not the last word, and Pascal wasn't where that stream of languages ended. Like most things, people moved on from Pascal. But C and C++ seem to attract the kind of people who refuse to move on.
Pascal came up because you were saying the popularity of C was misplaced. I was trying to get the point across that there was no contemporary competition to C which could do the things C could do. At that time, Pascal was C's supposed competition.
I don't know, if you don't like C++ and even don't like C but cite languages like ALGOL and Pascal in other posts, it seems it's not me who's refusing to move on.
" was trying to get the point across that there was no contemporary competition to C "
You are living in the narrow world of C. There were plenty of other languages around when C came out. In the 1960s there was much language activity. C people like you like to take the view that C had no contenders. It did.
"I don't know, if you don't like C++ and even don't like C but cite languages like ALGOL and Pascal in other posts"
Because again that was to contradict your contention there was nothing else. ALGOL was an ancestor of C, and yet, in many ways better. Better and rigorously defined. C was a step backwards. ALGOL was improved by CPL, ALGOL68, Pascal and beyond. C and C++ have become stuck. Even though C++ might seem to have improved with new versions that is still trying to fix mistakes, not any real improvement.
I have more than moved on, but we should not ignore the lessons from the late 1950s and beyond because those people understood the foundations of computing that is lacking in today's practitioners who think programming is down to a couple of flawed languages.
C didn't even exist in the 1960s and neither did Pascal! That link was from the 1980s when both were about a decade old and people had worked out each language's weaknesses.
Anyway, I should move on, as you say. Do keep carrying on talking about the 1950s.
"Do keep carrying on talking about the 1950s."
What I'm suggesting is we should not forget the language ambitions of those times. They were very far sighted. For example Christopher Strachey's CPL, which could not be implemented at the time, so Martin Richards did BCPL, out of which C came.
But C was a compromise at the time both because it was done on limited machines, and because it did not understand the vision of the other languages.
So anything based on C is going to fall short of what could be done in languages. C++ tried to fix some of that, but really just added its own level of cruft.
Yes, Dan 55, do move on. The rest of us have.
Languages get messy because life is messy.
C is actually a very good language, because it provides just enough abstraction from the underlying hardware, but no more than that. If you have ever migrated an embedded software application from device-specific assembler to C, you would appreciate just how useful a C compiler is.
At the opposite end of the abstraction scale, I have experimented with various higher level languages, particularly functional languages such as Haskell. They are mostly elegant, fantastic at abstraction, and totally useless for any real work. I did manage to get some statistical analysis done in Ocaml, which was quite neat.
With C++, I am still learning C++11, so I am way behind. I lapped up many of the new concepts, but I still have a lot to learn. This does not appear to be a problem. I could still write code in older style C++ if I wanted to. I could write my code without range-for loops or auto declared types. I am not forced to use these features, but they are handy once you learn about them.
These complications to the language fix some problems, or simplify writing routine code. I used to write a lot of iterate-over-the-container stuff using the old for loop and iterators ideom. Pretty verbose, and occasionally prone to errors. The simpler range-for syntax makes the code more readable and maintainable. I found the auto type declaration method quite friendly, having got used to type inference in functional languages.
Man inna barrel
Re: Is C++ becoming too large and complex?
"Languages get messy because life is messy."
No, that is absolutely the wrong approach to languages.
Yes the problems are complex. The complexity (essential) should remain in the problems. We should solve the problems with simple tools and paradoxically that is true, not "Languages get messy because life is messy." When the languages get messy that is accidental complexity and you end up wasting a lot of time dealing with that complexity that is not necessary.
"C is actually a very good language, because it provides just enough abstraction from the underlying hardware"
Which underlying hardware are you talking about? This is actually not true, but one of the simplistic maxims of C. I have ported large C systems (from well-known vendors) to platforms that C does not abstract well at all. C needs its own sandbox in that case. Mind you I knew the internals of that C compiler (written in Pascal!) and it was very well implemented.
"With C++, I am still learning C++11, so I am way behind. I lapped up many of the new concepts, but I still have a lot to learn."
Well, why this process of learning each step of C++. This is why I say to understand C++, you actually need to understand the history and evolution, much more than any other language.
I've always found computing to be non-orthogonal. OK I grew up with lots of different languages but C and C++ were my main weapons and C++ has its history writ large in its syntax but its all logical as far as I can see. There's a rational use-case for everything in it, it might not be your rational use-case but you are free to write your own language which will magically become as complex as C++ once you've added solutions to all the rational use-cases and as 'ugly' to the majority of users.
If a language is simple enough for you to know all of it then its not complicated enough for modern use. If you are using bits of a language you dont understand RTFM.
"If a language is simple enough for you to know all of it then its not complicated enough for modern use."
That is complete nonsense and completely misunderstands computing, programming, and languages.
Languages and tools should be simple – it is the problems we express in those that may be complex.
Complex solutions are most often wrong. And that is C++.
AGREED
The biggest problem with C++ is that it is too easy to make "write only code" ie code that no one except the author understands. The overloading of operators often makes it difficult to read a routine and understand it without reading the whole source (including all included files). With more contained languages (FORTRAN, C, BASIC etc) a subroutine could normally be understood on its own without needing to read thousands of lines in other routines. (When Z=X+Y; can mean anything from a simple addition of two numbers to merging two arrays depending on the types of X, Y and Z following the source gets difficult.) In my opinion a well written program is one that another programmer can easily take over without relying on external documentation. C++ makes it too easy to write programs that no one except the author can understand. (Sometimes even the original author can not understand the program!!!)
Interesting. In your first sentence, you lament that C++ makes it easy to write "write only code"...then only two sentences later, hold up FORTRAN, C and BASIC as counterexamples.
Don't bogart that joint, my friend....
BTW, "write-only code" is not a function of the language, but of the language practitioner. Remember, you can write FORTRAN in any language....
No language can really be considered complete unless it has at least half a dozen different ways to declare and initialise a variable.
int a = 42;
int a(42);
int a{42}; (but don't use {} when you mean (), and vice versa)
auto a = 42;
auto a = int(42);
auto a = int{42}; (ditto)
Have I missed any?
Q: Do the following have the same behavior?
A a1 { 0, 1 };
A a2 ( 0, 1 );
A: It depends on what constructors are provided. They will not if (e.g.) the following signatures are available:
A::A( std::initializer_list< std::size_t > );
A::A( std::size_t, std::size_t );
How does auto help there?
It wouldn't, because a1 wouldn't compile.
Why do you say that? It works for me.
#include <cstddef>
#include <initializer_list>
class A {
public:
A(std::size_t,std::size_t) {}
A(std::initializer_list<std::size_t>) {}
};
int main() {
A a1{0,1};
A a2(0,1);
}
$ g++ --std=c++2a -Wall a.cpp
$
"auto a1{0,1};" won't compile from C++17 onwards. AC was asking how auto helps.
"auto a1{0,1};" can never compile, because the compiler can never deduce what type a1 is. You'd need "auto a1 = A{0,1};"
And if the initializer_list version of the constructor has been declared, unwary programmers will then wonder why their programs don't work as expected.
Well, you've missed what auto is for.
No, I haven't missed what auto is for. I do a great deal of C++ programming, and given the choice I usually follow Herb Sutter's AAA style because it should be the compiler's job to deal with tedious details like what types to use.
In fact, I wish that auto wasn't broken in places - for example:
struct Fred { auto i = 43; };
Despite all the C++ programming I do, I still think it has become a bloated dog's dinner of a programming language.
struct Fred { auto i = 43; };
Why would you ever want to do this? If you're not able to be specific about the datatypes used in a DECLARATION, then maybe look at using Python or something. No typed language with type inference allows this kind of "yah, whatever you're having yourself" declaration.
If I were maintaining that code, even if that syntax were possible, I would switch it back to int, so that the intention of the programmer is clearly visible.
Or, to put it another way, what I like about C++ is that I don't have to deduce what could be in a data-structures by looking at field assignments.
Why would you ever want to do this? If you're not able to be specific about the datatypes used in a DECLARATION, then maybe look at using Python or something. No typed language with type inference allows this kind of "yah, whatever you're having yourself" declaration.
Because that is the whole point of auto - deduction of a type from an initializer. It is for exactly that purpose - to allow you not to be specific. And can you make sure you get the return type of foo() right, even though it is dependent upon the machine architecture and the foo header file/library version - your code has got to run everywhere!
#include <foo.h>
int main() {
struct Fred { auto x = foo(); };
auto y = foo();
}
The first auto won't compile, but the second will. Madness.
No madness, just perhaps a misunderstanding of what a declaration is for, and an attempt to misuse a keyword for its side-effects.
Because that is the whole point of auto - deduction of a type from an initializer. It is for exactly that purpose - to allow you not to be specific.
You can't keep hand-waving all the way to the the metal. At some point, you have to be specific, and for a variety of reasons, allocated class member types are one of those places.
Incidentally, you are allowed to use auto to declare a field of a class/struct, but only where that field is both static and const (and the initializer is a constexpr or literal) static const fields are special, though, allocated and assigned just once and shared by every instance (sometimes they don't even get allocated unless your code tries to get the field's address). This single point of initialisation may give you an idea why they can easily be allowed to use auto, while class-members are not... hint: consider how you'd declare a constructor that sets your Fred::x field.
Even if it didn't cause problems for code generation, your desired solution would only work for fields that have a default initializer, and thus it is only half a solution for the legitimate requirement of needing a field that can always contain the return-value of a given function. Luckily, the people standardising the language did consider this, and so if you need a field type that always matches the return type of a function, you should be using decltype(), which can be used regardless of initialization status. (auto can be seen as a special-case of decltype() for use when declaring variables and constants)
struct Fred { decltype("gotcha") x; decltype(foo()) y = foo(); };
... and this syntax also allows you to write a constructor, or any other function, whose argument type will match the return-type of a function, or match the type of any other declared constant.
If you mean 'C', then that is far from perfect with one of the main drawbacks being the unwillingness of WG14 to ever break legacy code. For example, the relational operators still return type int even though the language has had bool (though that is just an optional alias for _Bool) since 1999.
There are many other areas that would benefit from improvements - character handling and I/O, for example, where it is very, very easy to fall into undefined-behaviour (though that happens in lots of other places as well). However, any improvement would break that mythical program that was written pre-standardization that is still in use.
You are quite correct, C is not a perfect language. There aren't any.
However, C is a very good first approximation of a systems programming language. In fact, it is such a good first approximation that nobody has bothered with a second, at least not with any great degree of sincerity.
Why not? Simple answer: Running code trumps all.
"You are quite correct, C is not a perfect language. There aren't any."
So you can invent any old garbage you want because you can always say others have small flaws? That is a non sequitur.
"However, C is a very good first approximation of a systems programming language."
Actually, C is a terrible systems language. A systems language should only be used for systems, not for applications. Where a systems language is used for applications, it means the systems programmers have failed to do their job. They probably don't even know that is their job.
"In fact, it is such a good first approximation that nobody has bothered with a second"
Burroughs system languages blow C out of the water and make C look like the toy it is. I know your response will be 'who uses Burroughs'. But the one thing about Burroughs system languages is that you only use them for the OS, or middleware, not everywhere as is expected of C.
Also Burroughs languages were around half a decade before C. Did you ever stop to wonder where the idea of writing system software in structured languages comes from, and where #define came from? From Burroughs, from an idea Donald Knuth gave them.
"at least not with any great degree of sincerity"
Oh, Burroughs languages are far more sincere than C. There have been many more sincere languages than C or C++, but they get roundly bashed by C/C++ people. Others are getting sick of C and C++ – they are now old and tired.
"By Burrows system languages you mean ALGOL. And then you complain that C++ is old and tired."
Well, you don't even bother to spell Burroughs right.
ALGOL is still a more modern language than C or C++. But ALGOL moved on. It moved to Simula, ALGOL-68, Pascal, and then many more. C and C++ are just stuck in the same quagmire.
The worst technologies lead to lock in. That was the case with IBM, and certainly is now true for C and C++. The others have moved on.
Even so, the Burroughs languages make C look like a toy.
Twas my autocorrect, but Burrows as in head in the stand might be appropriate.
Pascal is nice to teach programming with, but can't be used in the real world. Delphi and Lazarus are not standard Pascal because standard Pascal is too limiting, but even so you still can't write something like an OS with them.
Seriously not getting your complaint about C/C++ being old, stuck in a quagmire, etc... and then going on to quote languages which are fossilised or only of interest inside academia.
Just because the compilers and linkers were never written with that in mind, thereby they don't output the required file formats. There's nothing in the language forbidding it.
Anyway they got 'modules', aka 'units', more than thirty years before C++...
"Pascal is nice to teach programming with, but can't be used in the real world"
Absolutely wrong. I have extensively used Pascal. Now most universities had Pascal IMPLEMENTATIONS that only needed to support students. Both Apple and Burroughs had real-world implementations of Pascal that were extremely useful.
That is not to deny that Pascal's type system was a bit severe and better has been done since. But that does not excuse C's almost complete lack of types apart from int, float (over BCPL). But Wirth moved on to take the lessons from Pascal and create Modula and Oberon.
Others took lessons from Simula and created Smalltalk and Eiffel. C++ took Simula and corrupted it. I don't think at the time Stroustrup had much clue.
The world moved on, but C remained in a time warp along with its followers who believe these myths that nice looking languages are just that way for teaching.
"Seriously not getting your complaint about C/C++ being old, stuck in a quagmire, etc... and then going on to quote languages which are fossilised or only of interest inside academia."
You prove in that your lack of understanding and narrow view of computing. You need to get rid of this false classification of languages into real world vs teaching or academia. C and C++ have become fossilised even though C++ comes out with a new standard every three years – but that is still trying to fix the mistakes and move towards those other languages that you consider 'fossilised'.
And you should speak for yourself. Many people in the industry are now questioning using this complex language where the complexity is accidental – that is part of the language itself, rather than essential complexity, which is part of the problem.
Your response and other responses are based on the cult of C-think of 'other languages are just for beginners', etc. It cannot be simpler – you are wrong.
"None of the languages you cite are getting traction in the commercial world and you miss all the langagues that provide real competition like Java or are up-and-coming like Go and Rust. But apparently I am wrong."
See that is what always happens, people like Dan 55 fall back on "oh it's not used widely". That is the problem of today's populism. People like Dan 55 can't break out of the mould and too scared to admit the flaws in C and C++ and can only keep beating the same drum.
Hilarious. Keep on claiming Smalltalk, ALGOL, Simula, Smalltalk, Eiffel, Pascal, Oberon, etc... are all perfectly designed, that C/C++ is terribly flawed beyond redemption, that C/C++ programmers don't know they can shoot themselves in the foot, that real-world usage which is so little it doesn't get all of these languages combined out of the "Others" column means nothing and certainly not languages which are just of academic interest, and that actual real-world usage to solve real-world problems is populism. Just don't do it while I have my morning coffee please.
"Hilarious. Keep on claiming Smalltalk, ALGOL, Simula, Smalltalk, Eiffel, Pascal, Oberon, etc... are all perfectly designed"
No, I did not say that. However, it does not matter what people think – C++ is a terribly designed language.
Dan 55 is descending to ranting.
Doctor Syntax:
Re: "Competent, core language"
""A systems language should only be used for systems, not for applications. Where a systems language is used for applications, it means the systems programmers have failed to do their job."
I think there's a couple of non sequiturs there."
You are wrong. And you don't even bother to note what the non sequiturs are.
I'll say it again, because it is right:
A systems language should only be used for systems, not for applications. Where a systems language is used for applications, it means the systems programmers have failed to do their job
And more than failed to do their job – it probably means they don't even understand what their job is.
Wait, what? If a systems language is used for applications, the systems programmers have failed to do their jobs? How on Earth is it the system programmer's fault if an application programmer chooses an/the incorrect language for the application? And how the fuck does it follow that the system programmer doesn't understand their job, based of what some other person does?
Your illogic is mind boggling.
Jake: "Wait, what? If a systems language is used for applications, the systems programmers have failed to do their jobs? How on Earth is it the system programmer's fault if an application programmer chooses an/the incorrect language for the application? And how the fuck does it follow that the system programmer doesn't understand their job, based of what some other person does?
Your illogic is mind boggling."
OK, you don't understand what the fundamental goal of system programming is. That is to provide a platform free of the underlying considerations of hardware and 'bare metal' as C programmers love to call it. That is any hardware timing concerns that might affect the outcome of computations are handled. Any other foibles of the hardware platform. Those details are abstracted away.
Similarly in distributed systems, middleware abstracts from the differences between systems to provide a single consistent view.
Put even more simply, the goal of any level of software is to provide a strong and consistent abstraction.
When system programmers think other programmers should be using C, exposing the lower level details that should have been handled, it means the system programmers have not done their job.
I'm sorry, if I wasn't clear on that before, and I hope that explains it to you.
Bollocks; I've been paid to write kernel code for the past 30 years. It is precisely the ability to have a predictable response from operations that distinguishes a language useful for manipulating low level facilities from one that isn't.
Case in point, an Ottawa firm, once renowned as a tech darling for its pbxes, voicemail and lawnmowers, wrote the entire system in a lightly extended Pascal in the early 80s. Hopelessly stuck, the eventual solution by early 2000 was to run a 68k emulator on a SPARC server -- there was no other reasonable path to delivering the functionality on modern hardware.
About the same time as that company had started doing its thing, Sun had been rolling out 68k workstations. By the time the emulated solution was delivered, Solaris had shipped on several 68k editions, 4 editions of SPARC (including a 64bit), and moved from 1 cpu to 64 physical processors, all writtenin C plus a small bit of machine language. In 2001, for kicks, I ran /bin/ls from a 1988 SPARC-1 compiled binary on a 64-bit E10k; it still worked.
If 'application' developers choose a lower level language, the fault is clearly in the insufficiency of application level languages; be it conceptual innanity, runtime overhead, quality of implementation - a trifecta best called C++. Mercifully languages like Go may provide an antidote.
This post has been deleted by its author
If you think that eye-and-brain-pollution expressed as (X > Y ? 1 : (X < Y ? -1 : 0)) is good coding, you don't (and will never) get Stroustrop's point about evolving the language to make it easier (and clearer) .
Of course, you can still continue to write that antediluvian garbage, and continue to dislocate your shoulder patting yourself on the back about what fine code that is. It's nice that the framers continue to allow one to rest on his/her nettles laurels.
Unless you're a complete numpty and/or you're new to C/C++ it is pretty damn clear. What would you prefer, a load of if-else clauses that look pretty? You stick to BASIC or whatever simple syntax language floats your boat and let the grown ups carry on with C++.
It has been over 30 years since the original 'C with Classes' which was just a bunch of #defines to emulate classes of better OO languages (mainly Simula). I did the same with ALGOL (using Burroughs define … #, where defines came from in the first place from Don Knuth's suggestion), but really it was not a good way to do things.
The whole idea of merging OO with C was not classy, but tasteless. More than 30 years later they are still trying to get this language right. I contend IT NEVER WILL BE.
Instead of getting things right C++ just perpetuates the things that are wrong – the things that are wrong with both system programming based on C and application programming (which should have nothing to do with C).
C made compromises back in 1969, excusably because they wanted things that would work in a small environment. That soon became irrelevant. Other compromises were inexcusable.
C++ tries to fix some of these compromises but perpetuates others. To do this is not at all classy, but tasteless.
"Then again, a language that doesn't change is dead"
I agree that languages can improve. But C++ changes to fix the mistakes – that is different and not a measure of anything good.
"that goes for both computing and spoken languages"
No that is not a good analogy. Programming languages are very different to spoken languages.
"Can't see why. They both express concepts and change to express new concepts... or die from lack of use."
Because you seem locked in to the C-think cult. C changes very little.
https://www.quora.com/Will-C-get-new-features-in-the-future
C++ just keeps trying to fix the flaws.
http://trevorjim.com/c-and-cplusplus-are-not-context-free/
https://cacm.acm.org/magazines/2018/7/229036-c-is-not-a-low-level-language/fulltext
https://dl.acm.org/doi/pdf/10.5555/1352383.1352420
Like most bad technologies, they become black holes of lock in. With other languages and technologies, the practitioners seem to be able to move on.
This post has been deleted by its author
"except for the lowest level machine interfaces in which C + asm shine"
Not at all. C is now constraining and hobbling processor design in the same way it has hobbled programming for a long time.
https://cacm.acm.org/magazines/2018/7/229036-c-is-not-a-low-level-language/fulltext
Someone Else: "Well then, I bet you're crying in your beer that C++ has effectively deprecated #defines with modules...."
No, the Burroughs defines were argued about when they were first included. They were much more powerful than the weak C defines, with several levels.
It was very much text-based processing along the lines of the General Purpose Macrogenerator (which one of my language teachers worked on).
https://en.wikipedia.org/wiki/General-purpose_macro_processor#General_Purpose_Macrogenerator
Amazing what you find. Here is an article by Andrew Herbert (who I knew at ISO ODP meetings) on GPM:
https://www.computerconservationsociety.org/software/elliott903/more903/Manuals/CCS%20Resurrection%20GPM%20Article.pdf
Strachey then developed CPL, which became BCPL, B, and C.
A couple of us Burroughs people did a language called SDL on the Apple II which was a cut down (because it had to be) of Burroughs and Elliott ALGOL. The main language designer did not have define # in it – he invented a rather neat macro mechanism to directly put in 6502 assembler code for things not worth doing in the language. However, in a bigger system (which we have these days) you would put such systems stuff directly in the language.
Now here's the thing. People who have used such other languages and systems seem to be able to move on. Sadly the same is not true for C and C++ people who seem to become rusted on to the deficiencies and bad ideas in C and C++.
Me: "Now here's the thing. People who have used such other languages and systems seem to be able to move on."
"Yes, and they seem to have moved on to C and C++...."
Like all matter gets sucked into a black hole.
Lock in is the second-worst problem in the industry after security – which C and C++ are also very bad at. It is not a good thing and the state of programming is not in good shape.
Someone Else: "Modules"
Modules? Isn't that what different files did with separate compilation, or maybe namespaces.
In another post you said just don't use things if you don't like them and you don't need to know all the history.
If modules really replace #define then you need to know you should use modules instead and why you should not use #define. It is all history and having to know that about C++ – it has this thing, but don't use it.
"It seems to me you know very little about the object of your vitriol.". This is the typical response to try to make legitimate problems of C++ as vitriol on the part of those who raise them,
"Now there is an alternative to #include, there is no reason to use #defines either as the last use case, guard defines, are rendered redundant. Obvs."
No, they are orthogonal. You confused #include with #define in the first place.
Good luck doing systems or device driver programming with Simula. The whole point of C++ was an OO systems programming language leveraging the advantages of C and providing alternatives for the bits that weren't so good and allowing already written C libraries to be included in a C++ program.
"C++ was an OO systems programming language leveraging the advantages of C and providing alternatives"
Most programming is NOT systems programming. The fact that systems programmers think all other programmers should be using C and C++ indicates the systems programmers have NOT done their job (they probably don't even understand that is their job).
Simula (like any language) can very simply be extended for system facilities – system facilities are actually very small and they should be limited to small areas of an OS and device drivers.
C and C++ are completely the wrong approach.
OO does have some reasonable definitions. Particularly Eiffel has a better basis:
OOSC (Eiffel)
For a more detailed look at software development for professionals, but at least first section will explain what we should be trying to do (which is programming, not coding).
https://archive.eiffel.com/doc/manuals/technology/oosc/page.html
Cardelli and Abadi have done a more mathematical basis for OO:
http://lucacardelli.name/Papers/PrimObjSemLICS.A4.pdf
https://dl.acm.org/doi/book/10.5555/547964
Of course relational database have a stronger mathematical foundation, that of relational algebra and calculus, but with OO you can build your own algebras in a class. So OO is more general than relational.
Christopher Strachey was trying to give language development a more formal approach. He developed CPL which was done as a temporary cut down version in BCPL (Martin Richards), which was adopted as the base of C (cut down BCPL).
https://www.cs.cmu.edu/~crary/819-f09/Strachey67.pdf
However, I see little hope for C++.
I agree you don't want to program in Z. However, there is a lot to be learnt from it. I have met Jean-Raymond Abrial when he was a guest of Bertrand Meyer at an OO conference. He was Meyer's teacher and much of Z and its ideas made it into Eiffel, particularly Design by Contract.
Contracts still won't be in C++ until 2023, maybe. A generation of programmers have died waiting for C++ just to get it wrong (again).
Like most programming languages, it has no formal logical or mathematical basis and is just a bundle of nostrums, as it seemed good in someone’s judgement.
So a language that can be formally defined by BNF " has no formal logical or mathematical basis", and is "just a bundle of nostrums"?
Wow! Just plain Wow...
So what constitutes a "formal logical or mathematical basis", in your nsHO?
@Stjalodbaer-- Re: Object
"Like most programming languages, it has no formal logical or mathematical basis and is just a bundle of nostrums, as it seemed good in someone’s judgement."
Someone Else : "So a language that can be formally defined by BNF " has no formal logical or mathematical basis", and is "just a bundle of nostrums"?"
Wow! Just plain Wow...
So what constitutes a "formal logical or mathematical basis", in your nsHO?
BNF is only for syntax. A language should also be semantically rigorously defined. The problem with C++ is that it lacked this at the beginning. Strachey (the designer of CPL, the forerunner of C) did work on denotational semantics.
And as far as you can shoehorn C++ into BNF, that does not actually prove a formal syntax. That was retrofitted as well.
http://trevorjim.com/c-and-cplusplus-are-not-context-free/
Why talk about these language lawyer and formal things? Because if you get them right the languages are simpler for everyday programmers. When they are wrong you get all sorts of problems and headaches. Complexity is a pain and C++ inflicts a lot of that.
"Contracts, a feature once slated for C++ 20, has been moved out of this release and into a study group, as they were not ready."
Still not there. Like multiple inheritance and generics, C++ is copying contracts from Eiffel. Eiffel has had contracts for 30 years. Eiffel did most things right over 30 years ago. C++ is still trying to do badly most of the things Eiffel did cleanly in the first place. Eiffel took a more integrated approach to the whole of the software development lifecycle.
The clean and constrained generics of Eiffel became the horror of templates in C++.
https://www.eiffel.com/values/design-by-contract/introduction/
"Is C++ becoming too large and complex?
It is an intimidating language"
It passed that a long time ago. Programming is based on a few simple notions. Those who think it must be complex and build complex languages are going down the wrong path.
The two languages that are both good languages but define the extremes of OO are Smalltalk and Eiffel. Smalltalk as how simple can you get with the notion of messaging, and Eiffel which is sophisticated and implements everything cleanly from the ground up, whereas C++ is kludging everything in.
"Stroustrup said that C++ 20 is “the best approximation of C++ ideals so far”, and that C++ 23 will be better still."
The ideal of C++ has always been just to perpetuate C++. The ideals of programming and OO are already there in Smalltalk and Eiffel and people should look at those languages to understand programming and OO.
A fundamental problem with C++ is practitioners need to understand the history and evolution of C++. I have two books here on my desk "The Evolution of C++" edited by Jim Waldo, and Stroustrup's own "The Design and Evolution of C++". While it is interesting to know the background and thinking in any language, C++ is the one language that demands understanding the evolution – why is this or that construct there, what you should use and what you should avoid.
Different people have different interpretations, likes and dislikes. Different shops will develop their own style rules based on their understandings of C++.
C++ as an evolving language is not a good thing. It is an excuse that C++ still has not got things right – things that were got right 50 years ago in Smalltalk and 30 years ago in Eiffel and other languages, that C and C++ people continually dismiss (and not very nicely).
C++ is like going back 100,000 years and saying there are modern humans, but let's go back a million years and evolve from there. It is time the computing industry lost patience with the approach of C++.
New programmers should absolutely not be taught C++ (or even C, or Java). The fundamentals of programming and computing should be taught with clean languages – and clean languages with semantic checks are not just beginner's languages with 'training wheels'. Semantic checks are a most advanced aspect of computing, not just to be dismissed as training wheels. Also simple languages can be used for all levels of programming.
Programming can use the simplest of tools to build the most complex of systems. C++ is a tool that thinks it must have the complexity built into the tool. This is fundamentally wrong.
Agree with almost everything you’ve written in this thread.
C++ was a bad idea and too complex right from the start. All it ever did was let lazy C users write a file with a cpp extension and claim “hey, I’m programming objects!”
It would be nice if any ‘new’ language had actually learned from Smalltalk, which is *still*, after 50 years, they only language good enough to be worth critiquing.
And finally
“New programmers should absolutely not be taught C++ “
I’d argue that new programmers should be taught documenting before any sort of programming language! Along with actually reading in order to understand specifications and requirements.
Timrowledge:
Yes, I quite agree.
"C users write a file with a cpp extension and claim “hey, I’m programming objects!”"
This is a very good observation and no less than David Parnas said it somewhere as "the worst thing about OO is that people think they are doing good programming just by using an OO language" – maybe not in those exact words. Anyway, he was making the point it is the clean and enforced design of APIs that is important, that is defining all possible interactions of objects.
With C++ you have pointers which can subvert the published APIs of objects.
"I’d argue that new programmers should be taught documenting before any sort of programming language!"
Well, a programming language is actually a documentation language, but what makes it better is that a programming languages is an alive document. That is one of the great things about programming.
God, I'm glad I don't go near C++, it's increasingly getting to become such a nightmare that I don't even understand some of the new features at all. That "concepts" things just sounds like utter nonsense to me.
And though the "three-way-comparison" thing sound good at first, I just see a nightmare of overloaded operators in its future.
All the C++ code I see is generally nothing more than overly complex C code shoved into some paradigm that makes little sense in the circumstances and often generates far more problems for maintainability than it does actually resolve any readability or "object" resolution issues.
I have literally abandoned contributing to some OS projects when they went from C to C++ for no fathomable reason beyond "Hey, I know C++, so you guys all need to learn it too", and then littered the code with tons of unnecessary furniture while leaving 99% of the actual logic exactly as it always was, but with horrendously complex access to simple variables.
I get it, I really do, I remember reading my first books on C++ many, many years ago and it all clicked and I thought that it was amazing and wonderful and so full of potential. And everything I've seen since was a disaster of unreadable code with unpredictable consequences. "C with classes", I would pay you money for. C++ I wouldn't give you tuppence for. And as it evolves it just seems to get worse and worse, and that's when the compilers fully support all the new stuff (which they never do).
There was a time where you could pick up a programming language, learn it in its entirety in a few weeks at absolute worst (for a competent programmer), and then be able to read and understand every bit of code ever written in that language - if not in intent and programmer choice, than at least in syntax and outcome and general gist.
I find that C++ is just a cryptic cipher.
And that's someone who's modified their own Linux kernel code (not just "applied a patch" but actually written code and fixed bugs that nobody else had on obscure hardware), ported other's applications between OS and architectures, written their own programs, etc.
Gimme C99 and a decent gcc any day to all this nonsense. No wonder people are jumping on Go and Rust and everything else (though they are increasingly starting to follow the "just shove the feature in and worry about how people are supposed to read it later" philosophy too).
I'm glad that I'm not the only one who looks at the code (new paradigms) and just sees unintelligable extended character set spaghetti. It's not necessary. Seriously. Code should be legible, clear and not obscured in as many arcane ways as possible.
I am more than capable of writing assember code, and have done for many years, but seeing unintelligible code in any language just makes me sigh. Code reuse is good, compiler hinting is good, but obfuscation even if it's excused as "you should know every arcane illogical and backwards obvious operator for the last 30 years" is not good at all.
Don't excuse exposing what a terrible language C++ is as 'hate posts'. C++ being a terrible language has nothing to do with hate, because it is.
"This reminds me a lot of people, who cannot swim talking to me about the dangers of water bodies..."
No, that analogy does not apply to programming languages. The warnings about problems in languages are technically based and have technical merit – and C++ gives many opportunities for criticism.
Those criticisms are most likely from people who understand programming much better than you do, like a olympic gold medal swimmer saying swimming over Niagara Falls will most likely end in death. Now that is a good analogy.
The same is true of PHP. PHP is a very flawed language, with lots of ridiculous language constructs that appear to have been borne out of the designer hearing about a feature in another language but not understanding enough to implement it properly. On the other hand, its flexibility is why it's so useful at times and the same goes for C and C++.
The more capable, and often the more flexible, a language is the more unintelligible the code can be made. Generally, code should never be written this way and should always be as clear as possible even disregarding "clever" language constructs. In the end, clarity wins.
> He has advocated starting with the “simple and elegant features” and not worrying about parts of the language which may be there only for backward compatibility
Why not define which features in the language spec are there for backwards compatibility only, so you can use only the subset of "good" features. Then you could have a compiler switch to disable them, e.g. -std=c++20only which would fail to compile programs that use the old/"bad" features.
I am currently learning C++. I have wished for this. For example, I only just learned why visual studio keeps trying to replace #define with constexpr.
Though that said, part of my code also needs to compile in C++98. This really highlights one of the strengths of the language; if you write a C++ program that just uses POSIX and the STL, you sure do have a lot of valid build-targets out there.
"The best thing about it is that if you don't like it you don't have to use it!"
It is much more than that. You need to learn what to use and not use and that means understanding why it was there, or still is there. More than any other language you have to understand the history of C++.
C++ is non-orthogonal which means you might end up using a feature in a way you didn't anticipate.
https://dl.acm.org/doi/pdf/10.5555/1352383.1352420
The problem in computing is programming is really powerful and you can do anything in just about any language, no matter how bad it is. BASIC programmers used to extol how good BASIC was and would not move on.
You must learn what orthogonality is – it will greatly help build better software.
Basically orthogonality means inclusion of features that are independent of one another and that don't interact in bad ways. It is the independence of 90º. Non-orthogonality means things interact in surprising and not pleasant ways. Complex languages are more likely to suffer from non-orthogonality. This makes them difficult to predict what will happen.
http://searchstorage.techtarget.com/definition/orthogonal
Orthogonality is fundamental to good software design. Mind you, I do sympathise with you, because of lots of academic-speak (the kind of pretentious academic speak I hate and usually the user does not know what it is either) around 'orthogonality' it took me years to understand it – but the definition is simplicity itself (see what I did there!).
It is much more than that. You need to learn what to use and not use and that means understanding why it was there, or still is there.
No, you miss the point (and now I finally understand why you whine so much about C++ and revere academic oddities like Eiffel). You don't need to learn what to use, based on some abstruse history lesson. Rather, you need to learn when to use a feature, and by induction, when not to use it.
It's a different mindset, and one that may not be available to you.
Someone Else (yet another cowardly anonymous poster)
>>It is much more than that. You need to learn what to use and not use and that means understanding why it was there, or still is there.<<
"No, you miss the point (and now I finally understand why you whine so much about C++ and revere academic oddities like Eiffel). You don't need to learn what to use, based on some abstruse history lesson. Rather, you need to learn when to use a feature, and by induction, when not to use it."
It is you who miss the point. C and C++ are self-obsessed languages. You absolutely have to know what there is and why it might be marked deprecated or something softer. To understand C++, you must understand that.
"revere academic oddities like Eiffel" That comment is no misinformed, it does not even deserve a response.
"It's a different mindset, and one that may not be available to you."
No, it is a mindset I consciously reject because it is a wrong mindset – one stuck in the mistakes of the past. One that is locked in and unwilling to see that there have been other much better things.
It is you who miss the point. C and C++ are self-obsessed languages. You absolutely have to know what there is and why it might be marked deprecated or something softer. To understand C++, you must understand that.
Complete garbage. I believe I have a firm understanding of C++ (I've been using it successfully and commercially since '92, so were I to not have a firm understanding of it, I doubt that I would have been commercially successful with it). Yes, I do have to know the syntax of the language to use it, as would you of Eiffel, or whatever your chosen expression of perfection might be. But understanding the history of the changes? Bah. I just have to know how to use the language to achieve my goals. And I really don't give a flying fig about how it got there. YMMV, of course, but this way, I get my job done in a timely fashion, and my blood pressure remains manageable.
Oh, and "self-obsessed"? Puh-LEEZE! You have a lot of damn gall to project your personal opinion on the entirety of the ANSI and ISO standards committees. Methinks you overreach, my friend.
So I said "It is you who miss the point. C and C++ are self-obsessed languages. You absolutely have to know what there is and why it might be marked deprecated or something softer. To understand C++, you must understand that."
Someone Else (SE) responds: "Complete garbage. I believe I have a firm understanding of C++ (I've been using it successfully and commercially since '92,"
That proves my point SE has been following this for nearly 30 years – about the same time since I was assigned to a large X.500 C++ project. People who have been involved with the language for that long can't understand how they have followed the history and changes, but for someone new to the language trying to understand all that is difficult. That is why I said C and C++ are 'self-obsessed' languages.
"But understanding the history of the changes? Bah" you just don't get it. You have been doing it for 30 years. Perhaps you understand not to use pointers and rather references or smart pointers or whatever. It is not just a case of syntax (although C++ is peculiarly convoluted and ugly). To understand C++ and why it is the way it is you need to read the history and evolution books, more so than in any other language. And that is for regular programmers, when it should really only be for the language lawyers. In other words C++ exposes all that when other languages abstracts that working away.
"Oh, and "self-obsessed"? Puh-LEEZE! You have a lot of damn gall to project your personal opinion on the entirety of the ANSI and ISO standards committees. Methinks you overreach, my friend."
OK, I'll address that again. Complexity becomes self obsessed. Complex technologies get lock in. Note how obsesses C and C++ people are, always leaping to defence whenever anyone criticise them. There is an obsession around C and C++ that is almost cult like – day anything that is wrong and abuse those who point them out.
I've been involved in ISO myself and there is a lot of posturing that goes on. The observations are not overreach. But there are probably some good minds trying to fix C++ and get it right. But it still is not in that position in 2020 and they still have things left out to fix in 2023. And those are things that have been around for 30 years. The problem is trying to kludge them into a language that was not suitable in the first place.
Languages.
Different hardware architectures => assembly.
Thin layer abstracting most of those differences => C.
Thinnish layer abstracting common OS features => probably Rust, Go etc., but nothing 'unsafe'.
Everything above => whatever maps best to the requirement. And that's the hard part.
But it's not C++.
As always, horses for courses.
Quite frankly, you are coming off as a jaded, disillusioned academic.
In light of that, instead of writing reams about how bad the programming languages that are in use today, producing code that people used productively[0] are ... would you care to tell us all what language(s) we should be using?
I, for one, await your answer with bated[1] breath ...
[0] For massively variable values of "productively" ...
[1] I'd have used "baited", but I'm not trolling regardless of appearance.
"Quite frankly, you are coming off as a jaded, disillusioned academic."
You descend to ad hominem. I just wrote this in another answer: my first exposure to this world was I was taught Simula by a professor who had worked in the UK with some of the great minds in computing (he did not say it at the time, but I have found out since). But the term OO was not mentioned. I then became one of the first adopters of OO in this country, have done languages and compilers, many large software projects, and studied OO deeply.
So you can take your false assessments and you know what to do with them.
As for giving you (Jake, whoever you are) examples – well you can do your own research. C++ people just bash everything.
That's not ad-hom, it's an observation based on available evidence.
Whoever I am, I am not Jake. That's one of a couple other ElReg commentards. Kindly keep them out of it. Ta. (Or does your mythical "perfect" programming language ignore CaSe?)
So you're not going to allow us into your world, where the best language is obvious? Somehow I'm not surprised.
Nowhere have I so much as hinted that I am one of the "C++ people", quite the opposite in fact. Kindly retract that heinous jibe.
Jake: "That's not ad-hom, it's an observation based on available evidence."
Oh, yes it is, you said:
"Quite frankly, you are coming off as a jaded, disillusioned academic."
You used the word 'you' referring to me and then made a remark, which is just wrong. Instead of addressing the subject which is C++, you attacked the person. That is ad hominem.
Jake: "Whoever I am, I am not Jake."
So you don't understand (or hopefully you do now if you read my last post) that system programmers should be hiding the details of the platform so that applications programmers don't all have to deal with those details (that is the aim of software at all levels), and yet you want to hide your own identity.
I can only think you have come here to troll, and this discussion has certainly declined into ranting.
"You used the word 'you' referring to me and then made a remark"
The remark was modified by the phrase "coming off as". Don't be disingenuous.
"I can only think you have come here to troll, and this discussion has certainly declined into ranting."
Projection is an ugly thing.
I'm still not Jake. Jake is one of at least two other entities here on ElReg.
All languages have their good and bad points. Generally people favor languages that they are familiar with:
LISP - lexical closures, precise garbage collection, can mimic most other languages
JAVA - type erasure, precise garbage collection
C - "machine language" with better syntax
C++ - C + separation of algorithms and containers through iterators
HASKELL/ML - precise garbage collection, list comprehension
Your Favorite Language - stuff, more stuff
What C++ needs is a precise garbage collector although careful coding using values instead of references can eliminate most memory problems.
YMMV
Doctor Syntax:
""'Best approximation of C++ ideals so far,' ... but is it too big and complex?"
I thought too big and complex were the ideals."
No, sophistication is the idea – and sophistication results in simplicity. It is the complexity of the problems we should handle, not the complexity of the tools. Problem complexity is essential complexity – complexity in tools is accidental and self-inflicted complexity. That is the problem with C++.
There are many other new features, including the “spaceship operator” <=> which does a three-way comparison and returns less, equal or more.
It took over 50 years, but C++ finally came up with a way to implement the equivalent of FORTRAN II's (in)famous 3-position 'if' statement.
For those of you who are not retired, and have therefore never had the pleasure, the FORTRAN II 3-position 'if" looks something like this:
IF (expr) 10, 20, 30
where 'expr' is evaluated, and if it is less than 0, control jumps (as if via a GOTO) to the labeled statement represented by the first entry in the comma'd list (statement 10, in this case). If 'expr' is exactly equal to 0, control jumps to the second labeled statement (20, here), and if greater than 0, the 3rd label is jumped to (30, here).
What fun!
This post has been deleted by its author
I don't get all the hate for C++. It's not a good application language for most applications, but it's very good for applications that need to run REALLY fast while doing complex stuff. If that's not your use case: pick another language. It's as simple as that. I've written UEFI code that was beautiful C, and compiled to very small sizes. I've written desktop applications in Java and C#, for which C would have been a pain in the ass.
I'm currently in a team writing new features for graphics processing software that uses C++ 14 after 10 years of having written C++ code, and I was surprised by how comfortable the language has become. It is definitely evolving.
The right tool for the right job should be the mantra for every programmer.
"I don't get all the hate for C++"
You don't get it because it is not hate. All programming languages are technical artefacts and should be analysed for what they are good for, where they are a match to some problem domain more than others. But they should also be criticised for their cross-domain flaws.
What computer people should aim for is simplicity. C++ is the antithesis of that. That is not hate on the part of people pointing that out – the problem IS WITH C++.
"If that's not your use case: pick another language. It's as simple as that"
No it's not as 'simple as that'. Many are stuck with having to suffer C++ because of its flaws. Some can see the flaws – others just don't know that is why they are having a hard time programming.
"It is definitely evolving."
Evolving towards what other languages were 30 years ago. Still contracts are put off until C++23. Many people who know other languages roll their eyes and say 'C++ finally got that'. But then they look at it and the C++ way is so much more obscure and then you find it interacts badly with other parts of the language in non-orthogonal ways.
"The right tool for the right job should be the mantra for every programmer." The C and C++ world is full of these false mantras. Yes, there is some truth in that. but in contrast C++ tries to be the tool for all jobs and in that becomes overly complex. The right tools are simple and sophisticated. C++ takes the unsophisticated and complex path.
Literally not a single feature makes c++ easier to read , easier to program or improve performance(main reason people use it), since c++ 11. It seems they are trying to turn the beautiful language into ugly Java ( which already exists and it does what it does) , I cannot figure out why . Bjarne created a beautiful thing 30 years ago , is he ( and others) trying to make sure it does not outlive himself ?
