How C++ Programming Language Became the Invisible Foundation For Everything, and What's Next (techrepublic.com) 107
The origins of C++ date back 40 years, yet it remains one of the most widely used programming languages today. TechRepublic spoke to C++ creator, Bjarne Stroustrup, to find out why. An excerpt from the interview: Today, Stroustrup is a Technical Fellow at Morgan Stanley. His work with the International Organization for Standardization (ISO) for the C++ standard and on the C++ Core Guidelines are considered part of his role with the finance giant, and he remains very much involved in the development of C++. Most notably, Stroustrup forms part of the direction group, which presents and discusses recommendation about the future of the programming language. He also follows the evolution group, and takes part in discussions about new language features. When it comes to the day-to-day running of C++, however, Stroustrup is happy to take more of a backseat role. "I follow administrative activities but try to do as little as possible there. I am not a great administrator," he admits. Before the pandemic, Stroustrup would travel a lot to teach, and to explain C++ to the world at large through his books, articles, and interviews -- though much like the rest of the world, 2020 has put a temporary end to this.
"For my work, I depend critically on talking with people to learn about their problems and hear how my ideas might help them," Stroustrup says. "In this time of the pandemic, I am deprived of much-needed feedback. Virtual talks and interviews are not the same, and the dynamic of Zoom meetings are inferior to real face-to-face meetings when it comes to discussing design and ideas." The COVID-19 pandemic has also hindered progress with the next two iterations of the language, C++20 and C++23, though Stroustrup affirms that "almost all" of C++20 will ship in 2020. "Beyond that, there is work on Unicode, numerics, game development and low latency, tooling, AI, and much more," he says. "We ship a feature (language and library) when it is ready, and we issue a revised standard every three years. C++14, C++17, and C++20 shipped on time. It is worth noting that the standards effort and the major implementors are very much in sync. "It is crucial that C++ remains coherent and is a stable platform for development."
"For my work, I depend critically on talking with people to learn about their problems and hear how my ideas might help them," Stroustrup says. "In this time of the pandemic, I am deprived of much-needed feedback. Virtual talks and interviews are not the same, and the dynamic of Zoom meetings are inferior to real face-to-face meetings when it comes to discussing design and ideas." The COVID-19 pandemic has also hindered progress with the next two iterations of the language, C++20 and C++23, though Stroustrup affirms that "almost all" of C++20 will ship in 2020. "Beyond that, there is work on Unicode, numerics, game development and low latency, tooling, AI, and much more," he says. "We ship a feature (language and library) when it is ready, and we issue a revised standard every three years. C++14, C++17, and C++20 shipped on time. It is worth noting that the standards effort and the major implementors are very much in sync. "It is crucial that C++ remains coherent and is a stable platform for development."
C++ is the worst programming language (Score:5, Funny)
Except for all the others
Re: (Score:2)
Except FORTH
Re: (Score:2)
Yoda programmer FORTH best is!
Re: (Score:2)
FORTH isn't FIRST
Re:C++ is the worst programming language (Score:5, Insightful)
C, not C++ is the fundamental building blocks of pretty much all software.
100% of programming libraries out there are written in C or export only C bindings, not C++. Third parties write C++ bindings for C libraries. Fundamentally every program only works because it can speak C.
So it's unfair to go "C++ is the foundation for everything" when that's really C.
Re:C++ is the worst programming language (Score:4, Informative)
And plenty of them are just wrappers around FORTRAN, with the calling convention fixed for C developers.
Re:C++ is the worst programming language (Score:4, Informative)
All modern high performance C compilers are now written in C++.
Re: (Score:1)
And yet, almost all the libraries are in C, even if the application is in C++. For reasons the compiler knows about...
Re: (Score:2)
Many are, some are not. Everything except C does have an ABI problem (though overblown IMO). There's also a weird obsession with C in the open source world.
For reasons the compiler knows about...
Eh?
Re: (Score:2)
Re: (Score:1)
If you think that
int values[] = { 88, 56, 100, 2, 25 };
int cmpfunc (const void * a, const void * b) {
return ( *(int*)a - *(int*)b );
}
qsort(values, 5, sizeof(int), cmpfunc);
is more elegant than
std::sort(values);
then you need to look up what elegant means
(https://www.dictionary.com/browse/elegant)
Re: (Score:2)
Re: (Score:1)
Shouldn't that be "std::sort(values, values+5)"?
If there's a new std::sort function that I'm not aware of and that only takes one argument, how does it know the size of the array?
Re: (Score:1)
I agree!!! While I would LIKE to say it was the K&R C, it's really the ANSI C that is the core building block. Linux (the OS) is one example.
Re: (Score:2)
While I would LIKE to say it was the K&R C
No C developer ever wanted to say that, though.
Re: (Score:1)
Re: (Score:2)
C, not C++ is the fundamental building blocks of pretty much all software.
100% of programming libraries out there are written in C or export only C bindings, not C++. Third parties write C++ bindings for C libraries. Fundamentally every program only works because it can speak C.
You're talking about the C ABI, not the C language, and the C ABI is just low level data types (ie. "assembly language" level - pointers and ints/floats).
A C++ ABI would be very, very difficult, eg. how would you pass a std::vector to a library from Python?
Add new reserved words FFS (Score:2)
Python went the wrong way making Python 3 incompatible with Python 2.
But C++ has gone too far the other way, not adding any new words and onstead overloading the old ones.
And when I switch from Python to C++, the ugly C++ syntax really sticks out.
"static" should have ONE meaning and ONE meaning only, FFS.
Re:Add new reserved words FFS (Score:5, Insightful)
the ugly C++ syntax really sticks out.
You can get used to syntax.
It's a lot harder to get used to a language that keeps running into brick walls WRT abilities or performance, or that happily compiles and runs and constantly massages data types so you can compare strings with numbers and get all sorts of subtle errors at runtime.
Re:Add new reserved words FFS (Score:5, Funny)
constantly massages data types so you can compare strings with numbers
Types are a hindrance to productivity for the Modern Programmer.
Re: (Score:3, Insightful)
Re: (Score:3)
Re: (Score:1)
> You can get used to syntax.
"People will suffer atrocious syntax to get valuable functionality (C++ template meta-programming is an example). " - Bjarne Stroustrup (https://features.slashdot.org/story/14/08/20/011231/interviews-bjarne-stroustrup-answers-your-questions)
Re: Add new reserved words FFS (Score:5, Informative)
For a global variable, static gives it internal linkage. For a local variable, static gives it a fixed memory location and initialisation on first use only.
Yes, C++ added another similar meaning (per-class storage rather than per-instance storage), but the overload of static already existed in C.
Re:Add new reserved words FFS (Score:4, Insightful)
For Python 2.0 to 3.0, I have no problem with sacrificing backwward compatibility where necessary. That's what major versions *mean*, in my mind, an incompatible change.
What made me feel sick to my stomach whenever I saw "Python" is this:
Python 2.6 breaks compatibility with Python 2.5
2.7 breaks things written in 2.6
2.8 isn't compatible with 2.7 oops never mind 2.8 officially isn't Python anymore
3.0 breaks things written in any earlier version
We're not talking about breaking little-used features either, we're talking they broke things like PRINT. Pretty much every single script ever written in Python was broken.
Over the course of 20 years or 40 years some things have to be broken as the language progresses, right? Python broke the basics three times in three years! Ever damn year they broke everything again.
They say they are thinking about only breaking everything every few years now. We'll see what they actually do.
Re: (Score:3)
For the most part, a Python 2 script can be made compatible with Python 3 with just importing the print function. A few libraries have changed, but I found the migration fairly painless
Re: (Score:2)
Yeah, this problem I want to say originated in Perl, as PHP and Python and Ruby have all done this "point release breaks things"
The only appropriate way to version software is:
(majorversion) . (minor version feature set) . (bug/security fix version).(optional build number or letter)
In Major versions, you're allowed to remove features while adding new features that are improvements over the feature being removed.
In Minor versions you introduce the features you intend for the next major version, but only depr
Twenty six years (Score:4, Insightful)
I've been using Perl regularly for over years and I can't think of anything that's been broken. The code I wrote 15 years ago runs just fine today. (An is an integral part of hundreds of thousands of web sites, so stability matters).
Contrast Python 2.5, 2.6, 2.7, (2.8), 3.0 breaking most code every single year. Three total breakages in three years.
I'm sure there has been SOMETHING that works slightly differently in the last 26 years, the 26 years that we've been using Perl 5. Whatever that is, it's enough of an edge case that I've not had a single problem with it. Generally what Per does is add new functionality, not randomly rename core functions or change their arguments (fucking Python). If you want different arguments, in Perl you add the new one as an optional argument. The old calling convention keeps working just fine.
Re: (Score:2)
Everybody likes crapping on Perl, but it just does what it's supposed to, it doesn't break things, and it's efficient.
The problem is it doesn't force people to write legible code, so some people think who they're clever but end up writing crap they can't make sense of a month later. Also, OOP was added as an afterthought and is ugly, this is where Python excels.
Nevertheless, for small programs, nothing beats Perl.
One cool thing, though (Score:2)
There is one really cool thing about Perl's object implementation. It's transparent. You can easily see exactly how it works. Building one class in Perl, you learn how objects actually work under the hood in most languages. I think that's really cool.
Re: (Score:2)
I can still run almost all my Ruby scripts from 2004 now, with a modern Ruby.
Even most of my old libraries in C still work. The C api has grown but is mostly compatible.
The stuff that changed and would break is mostly related to meta-programming, something you shouldn't normally do anyway outside of rapid prototyping.
This (Score:3)
And other stupidities such as throw meaning throw , uh , except when part of a function definition when it means the exact opposite.
Oh , and const_cast which perversely means remove const ness.
Updated Design and Evolution book? (Score:2)
One of the more interesting computer programming related books I've read, was "The Design and Evolution of C++" by Bjarne Stroustrup. He did a really good job laying out how the language came to be...
Doesn't anyone know if there's any updates to that? The one on Amazon appears to still be the one from 1994; it would be really interesting to see a similar work covering the changes that have happened since then.
Re:Updated Design and Evolution book? (Score:5, Informative)
Doesn't anyone know if there's any updates to ["The Design and Evolution of C++" ]
The closest is, I believe, his "A Tour of C++", which is basically a "This is what the new [up to C++17] features are there for" book, although you wouldn't really know that from the title. Not exactly the same emphasis as the earlier book... but it's by Stroustrup and therefore worth reading regardless.
Re: (Score:1)
it's by Stroustrup and therefore worth reading regardless.
Thanks, didn't think about looking for other books by Stroustrup, I'll take a look. I don't really do any C++ at the moment but I like to keep up with what the language is doing, so even though that sounds less philosophical it still is probably a good idea to read through.
Re: (Score:2)
One of the more interesting computer programming related books I've read, was "The Design and Evolution of C++" by Bjarne Stroustrup.
...should be mandatory reading for C programmers.
Re: (Score:1)
...should be mandatory reading for C programmers.
That is a great point, I think maybe it should be mandatory reading for just about any programmer! The concepts it covers are really timeless and it's a really well written book that covers a pretty deep topic of language design... I think it would give anyone better appreciation for whatever language they ware working with.
Probably time for a re-read myself..
Yikes to Mike (who's Mike?) (Score:3)
Re: (Score:2)
I can't wait for what's next because I never understood C++. I never understood why it had to be so hard to use.
It's not hard to use, it just takes some time/effort to learn.
(Time/effort that's well invested and will make you a real programmer, not just a fingers crossed copy-paster).
Re:Yikes to Mike (who's Mike?) (Score:5, Informative)
I thought early versions of C++ were very nice, they added object oriented features to C in a simple, and efficient way. IMHO that made it a very nice tool for low level programming the efficiency of C with some nice added syntax.
Gradually though its become more complicated. Not it seems neither fish nor fowl, not really appropriate for low level coding, but as the poster above implied, far harder to use than high level language like Python.
Re: (Score:2)
Not it seems neither fish nor fowl, not really appropriate for low level coding,
How is it not appropriate for low level coding? I sometimes write code for ATTiny's and when I do it's C++.
far harder to use than high level language like Python.
Depends on the task. Often you can hack something together in python faster, though by no means always. For code with longevity, Python is horrid. Lack of static typing for example makes refactoring a complete nightmare.
Re:Yikes to Mike (who's Mike?) (Score:5, Insightful)
C++ is for people too dumb to use pass by reference and function pointers.
Re: (Score:3)
And C is for people too smart to automate away a ton of error prone drudgery.
Re: (Score:3, Informative)
If C++ is too hard, may I suggest Visual Basic?
If you think that C++ isn't hard to use correctly, may I suggest you read the "C++ Frequently Questioned Answers" page in its entirety.
Re: (Score:3)
The FQA is hyperbolic junk written by someone with a very very large axe to grind.
Re: (Score:3)
The FQA has been somewhat dated with the release C++ 11/14/17 - the author even admits this on his page. But some of the points still stand. But its a good argument for why the more modern paradigms, such as smart pointers, should be used. And also in general, a reminder for coders if they run into a situation where the only way out is to use some darker corners of the language, they should probably rethink your approach. Its better to write more code that is clear, than terse code that is esoteric that
Re:Yikes to Mike (who's Mike?) (Score:4, Interesting)
OK, then. Forget the FQA if you think it's "junk". Just read the whole FAQ that it refers to, which still proves that C++ is a vast and dangerous minefield for developers.
In particular, when someone like the OP tries to make fun of a person who calls C++ "hard", then it proves that they have no clue what they're talking about. C++ *is* hard, and if you don't think so, then I guarantee that you've been writing piles of bugs and vulnerabilities.
Re:Yikes to Mike (who's Mike?) (Score:4, Insightful)
The FQA pages pretty much nailed every reason why I grew to hate C++. Eventually, I switched to Python. Then I got a bunch more embedded work, looked at C++ and went back to C. Python works when speed isn't a factor. C seems to work better than C++ when doing the low-level real-time code.
It really takes the right type of project for C++ to shine. For a language with as many features as it has, it is surprising how obtuse C++ can be.
Needs a platform independent UI support (Score:5, Insightful)
Its syntax is arcane and abstruse, but the power is amazing. I live and die by STL.
If it is possible to support a UI markup language, leaving the actual rendering to the system but the same call to launch and get a file name browser from directory, something simple, buttons, radio buttons, drop box, edit box, .. It would be great.
Like it is absorbing boost and stuff, it should absorb basic Qt or something.
No (Score:3, Funny)
Security has become too important. Code will be rewritten in languages like Rust and C++ will be thrown on the same scrap heap Cobol was.
Remember when Pascal was the be-all to end-all?? Same thing will happen with C++
That's great they're updating it though. They do the same with Fortran from time to time.
Re: (Score:2)
Re:No (Score:5, Insightful)
Security has become too important. Code will be rewritten in languages like Rust and C++ will be thrown on the same scrap heap Cobol was.
Remember when Pascal was the be-all to end-all?? Same thing will happen with C++
That's great they're updating it though. They do the same with Fortran from time to time.
Cobol has been thrown on a scrap heap? Seriously?!?! You think that?!?!?
Re:No (Score:4, Insightful)
I feel we need to move past "The language is not dead, there's still a bunch of ancient software in COBOL that needs to be maintained".
No programming language ever truely dies,
they just fade away.
Re: (Score:2)
You're ignorant. There is modern maintained code in COBOL, moving your money in banking and insurance. Not dead and one of the most prolific languages ever for business.
Re: (Score:2)
I took the comment to mean that new software is not being written in COBOL, though certainly new code is being written to support old software. I thought financial software was mostly written in Java now?
Re: (Score:2)
>I thought financial software was mostly written in Java now?
For some reason, I've feeling an urge to go bury my wealth in the back yard . . .
(but can't, because it's practically impossible to find coffee cans thee days!)
Re: (Score:2)
So tell us.
What features of COBOL, other than to use existing routines entrenched in a given business, draws people to use it over any of the modern languages?
What makes modern COBOL attractive over the modern alternatives?
What kind of new project would I say, I should use COBOL for this, it just is the right tool for the job? Aside from interfacing with legacy systems, that is.
Re: (Score:2)
What features of COBOL... draws people to use it over any of the modern languages?
1) Decimal math, everywhere.
2) Easily link C libraries when needed
3) Very fast formatted IO
4) Efficient, deterministic runtime
What kind of new project would I say, I should use COBOL for this?
You won't. If you had to ask, use a more general tool.
Re: (Score:2)
COBOL is a specialised language that excels at volume processing tasks - like when I was taught it, the first thing you're given to do is merge a set of payroll and employee datasets. 3 lines of COBOL later you think, "well that was easy". And 2 of them were print statements.
Its a bit like SQL, great language for what its designed to do, and what it does is exactly what financial systems do mostly - manipulate vast sets of data.
Re: (Score:2)
You mean easier than what you can do today with modern DataFrames in Python, R or Scala?
Re: (Score:2)
Don't underestimate the value of knowing that all your numbers are decimal.
Re: (Score:2)
Code will be rewritten in languages like Rust and C++ will be thrown on the same scrap heap
But what language will we write the Rust toolchain in?
Re: (Score:3)
When I was studying CS (some decades ago), it was clear that you write the tools for a language in the language itself. And then you write a basic compiler in machine code, that is able to compile a simple compiler for a stripped down version of the language, which was used to write a compiler for the fully fledged language, in which you then write the compiler with all the bells and whistles and optimization options for the l
Re:No (Score:4, Informative)
In Rust.
Really? I don't see Rust's dependence on LLVM going away soon. I also don't see LLVM being ported to Rust. So the whole 'throw C++ on the scrap heap' seems a bit premature.
Re: (Score:2)
Re: (Score:1)
You don't necessarily have to write the basic compiler in machine code. You can write a cross compiler in C, Pascal, Lisp...etc.
I'm old enough to remember when a lot of stuff was written in Assembler, and I've even toggled binary code in from the front panels of machines a few times, but I don't think that happens very much anymore. (They don't even have front panels anymore.)
Re: (Score:2)
Re: (Score:1)
My personal experience with front panels was mostly with the Modular Computer Systems ModComp II, a 16 bit computer. You would be debugging some code, and want to try some little change. Rather than re-assemble, link, and load the whole program, you could sometimes get away with just toggling in a change, maybe a value to be loaded in a register, something like that, to see how it worked with the program already loaded. Those Modcomps had magnetic core memory. You could turn them off, then turn them bac
Re: (Score:2)
When I was studying CS (some decades ago), it was clear that you write the tools for a language in the language itself.
That's a self-hosted [wikipedia.org] language, as opposed to bootstrapped [wikipedia.org]. They are both things.
Re: (Score:2)
The C tool chain is written in C.
No it isn't, it's written in C++. GCC was written in C in the past. It got moved over to C++ and they recently adopted C++. Personally I think that GCC's bootstrapping policy is daft. I think a much better policy would be to update the minimum compiler much more frequently, possibly set to the previous major version number release.
Don't get me wrong, it would be irritating to bootstrap, say, gcc 11 from gcc 4.8 by going to 5-6-7, etc all the way up to 11, but frankly not tha
Re: (Score:2)
A programming language isn't a real programming language unless it can compile itself. If it can't compile itself, then it's not yet a mature language. LLVM is the exception to the rule here because it is a C++ IR. So the front end compiler for Rust to LLVM means it's really being translated to C++, not actually depending on a self-hosted Rust runtime.
Because OS's only come with C runtimes, fundamentally every OS runs on, and depends on C. Some OS's like Windows and OSX also come with additional runtimes, b
Re: (Score:2)
C++ will be thrown on the same scrap heap Cobol was.
In your wishes. C++ enables one to write extremely low-level and extremely high-level code in the same language, there will always be people who understand and appreciate that. Even Cobol is far from dead, BTW.
Re:No (Score:4, Insightful)
Hopefully people will stop commissioning high level code written in C++ though, it would do us all a massive favour. C(++)'s continued widespread use for the last few decades long after the seriousness of exploitability of the type of errors common in "unsafe" languages is economically unjustifiable, a trillion dollar mistake.
Lots of rich criminals, lots of broken windows and wasted efforts on bandaids ... just because programmers refused to let go of their illusion of control.
Re: (Score:2)
It's scarily common for websites to allow login without a password. That's not incompetence, it's outright not caring.
Re:No (Score:5, Informative)
There are plenty of cases where security isn't of primary importance, like in videogames. No one is going to seriously suggest rewriting the million or so battle-tested lines of C++ in the Unreal or Unity engines in Rust, not to mention all the native OS/console APIs, utility libraries, frameworks, etc. It's just not going to happen, period, because it's *not practical*.
Rather, what's going to happen is that C++ will evolve into a language that emulates more Rust-like behaviors and traits, improving memory safety and tooling over time, all while trying to carefully maintain backwards compatibility - something which has been achieved to a remarkable degree so far, and makes C++ very attractive for long-term projects.
C++ isn't just being "updated from time to time", like its in maintenance mode. Rather, the C++ language and standard libraries have undergone very substantial overhauls over the past decade. For instance, C++ 11 was a very substantial update, the beginning of what we call the "modern C++" era, introducing automatic memory management via smart pointers lambdas, and other modern techniques. C++ 20 has introduced modules, eliminating the need for archaic header files. The most recent language looks remarkably different than it did only a decade ago.
Also, who exactly is touting C++ as the be-all end-all? Certainly not anyone I know of. It's a fairly specialized and difficult language only to be used in specific circumstances. C++ excels in three areas: high performance, powerful zero-cost abstractions, and its broad ecosystem and compatibility. If you don't need all three of those, pick another language.
Re: (Score:1)
Re: (Score:2)
Obviously, I'm not claiming security isn't important in some non-core aspects. I only said security wasn't of "primary importance", not that it was completely irrelevant. This is especially true for multiplayer games and MMOs.
Keep in mind that you CAN write secure code in C++, especially modern C++, which has much better facilities for avoiding memory-related issues. Naturally, it's not nearly as good as Rust in this aspect, but far better than C or even older C++. Besides which, just as writing code in
Re: (Score:1)
COBOL isn't on the scrap heap, you're just ignorant of two of the hugest uses on planet earth apparently. COBOL moves your money and provides your insurance. Rust is a fad language, it will be nowhere in 15 years. No major industry is using it.
Re: (Score:1)
I don't think Pascal never achieved the mindshare of C or C++ in the commercial world - not even close.
I was programming in C in the very early 80's and went to a startup that was using Pascal (with some mods to support pointers - it was a parallel database machine that still is sold today although the code has since been mechanically converted to C and, of course, extended and with completely different hardware) - but we would have preferred C had we been abl
Re: (Score:1)
Delphi was incredibly popular for a very long time.
It should have been adopted instead of Visual Basic, but like so many other failures-in-the-name-of-profit-and-control, MS saw it off.
Re: (Score:2)
Security has become too important.
I'd like to agree with you, but security is an afterthought if you're lucky.
Re: (Score:2)
The difference is that in spite of huge amounts of hype, Pascal never actually got much traction in the real world. Meanwhile, C++ is everywhere, and honestly is a more credible choice now than it was in the '90s (I saw some pretty awful code in the '90s that tried way too hard to be C++).
Re: (Score:2)
Code will be rewritten in languages like Rust and C++ will be thrown on the same scrap heap Cobol was.
... someday. Probably a decade or two after IPv4 has been thrown on the scrap heap.
Face it, there are too many millions of man-hours invested in developing, debugging, and maintaining all the C++ code that's already out there; nobody in their right mind is going to throw away all that working code until they absolutely have to. Which means we're going to keep using C++ for the foreseeable future, regardless of how fakatka the language is.
Re: (Score:2)
Remember when Pascal was the be-all to end-all??
Pascal was never the "be-all to end-all".
It had serious problems that were well known to everybody, eg.: https://www.lysator.liu.se/c/b... [lysator.liu.se]
Crap++ is popular. Go figure /s (Score:5, Interesting)
While C++ has become ubiquitous for "systems" programming, game development, etc. it encourages what I call Crap++ thinking. C++ encourages slow, bloated, over-engineered code that takes forever to compile:
* iostream performance [gitlab.com] is crap. [fastformat.org] This has been known about since 2013 [youtu.be] The committee is looking to adopt std::format() to address these performance concerns. Who cares about performance when you can just throw more hardware at a problem!? /s
* Modules are finally herein C++20. Meanwhile Pascal has had modules for what 50 years? ??? Why did it take so fucking long???
* A simple crc32() in C takes roughly ~25 lines of code to implement. Parameterizing this into C++ turns it into this clusterfuck "solution": Boost's 2305 lines of code [boost.org]!?!?! The problem is that C++ encourages people to use a bloated library without actually thinking about the underlying, real problem. Because the last time you needed to extend a crc() function from 32-bits to X bits was when exactly? NEVER! You would be using a DIFFERENT algorithm that is faster, and more cryptographically secure.
* Instead of lambas having a nice single keyboard, say I don't know "lamba", we get the [] and [=] clusterfuck array overload notation. A keywords makes searching trivial.
* C++11 "auto" is constantly over-used. While this makes code easier to write it makes it much harder to read because now I have to do the job of the compiler. Why is there no standardized way to turn this crap off?
I see that the C++ committee continues to remain out of touch:
* Someone is still trying [open-std.org] push the stupidity of adding a 2D Graphics Rendering API into the language. A solution in search of a problem. Meanwhile everyone else is already using D3D12, Vulkan, or OpenGL. [steampowered.com] and setting z=0. OpenCL and CUDA already exist. Hell, even single header include files like stb_image.h [github.com] has existed for years.
* When is C++ getting standardized support for float16 [wikipedia.org]?
* When is C++ going to deprecate the "short" and "long long" nonsense?
C++ has remained popular and will remain popular because it gives good performance in-spite of its design-by-committee problems.
--
There are two types of programming languages: The one everyone bitches about and the one no-one uses. -- Bjarne Stroustrup
Re: (Score:2, Informative)
your post isn't right. It's not even wrong.
It's so far wide of the mark that outs hard to know when where to begin.
I will however congratulate you on your parsimonity; in a mere two lines you managed to convey a, lack of understanding of C++, the standardisation process, Cairo, Vulkan, OpenCL, CUDA, and stb_image.h
Re: (Score:2)
You don't know what the fuck you are talking about.
Cairo (A Proposal to Add 2D Graphics Rendering and Display to C++) was proposed back in 2014 [open-std.org].
In 2020 [open-std.org] it STILL hasn't been implemented.
So what were people supposed to do in the six years they have been waiting for "Cairo" to be implemented? Wait ANOTHER 4 years before it gets standardized???
Do you even understand the difference between CPU rendering vs GPU rendering???
Re: (Score:2)
You don't know what the fuck you are talking about.
I really do.
Cairo (A Proposal to Add 2D Graphics Rendering and Display to C++) was proposed back in 2014.
In 2020 it STILL hasn't been implemented.
Eh? Cairo, the library, has been implemented, working and in use for years, nearly 20 if I recall correctly. The proposal was to essentially add Cairo to the C++ standard. It was proposed 6 years ago, and the committee are still not happy with actually bringing it into the C++ standard. You don't seem to realise
Re: (Score:2)
Cairo, the library, has been implemented, working and in use for years, nearly 20 if I recall correctly
It seems like that's how long I've been trying to get it to compile, anyways. If it wasn't for that one stinker, I could probably use the same distro for 10+ years, but I end up having to compile half the world for that to work.
Re: (Score:2)
It seems like that's how long I've been trying to get it to compile, anyways. If it wasn't for that one stinker, I could probably use the same distro for 10+ years, but I end up having to compile half the world for that to work.
Ouch. I've never tried, myself, but I've encountered libraries that are weirdly hard to compile before. You have my sympathy.
Re: (Score:2)
> The proposal was to essentially add Cairo to the C++ standard
C++ doesn't need a C++ wrapper for C code [wikipedia.org] for yet another shitty, incomplete graphics API.
Putting it into the standard is NOT going to a change a single damn thing except for:
1/ People who need it are ALREADY using it. Everyone else who needs rasterization is already using another API.
2/ This will only
Re: (Score:2)
if you have a problem with projects sponsored by DARPA, i have some bad news about the internet...
Re: (Score:2)
You seem angry about something. You've ragily replied to my post as if I were somehow one off the authors off this proposal, or a supporter of it. But you know, you do you bro.
Putting it into the standard is NOT going to a change a single damn thing except for:
3/ new code which isn't written yet.
And your point 2 isn't exactly correct: it's not the necessarily three same people implementing the libraries and the core compiler, so it's not like one detracts from the other, and besides in terms of core languag
Re: (Score:2)
Does OpenGL belong in the standard C++ library? No
Does Vulkan belong in the standard C++ library?
Does someone's pet graphics library belong in the standard C++ library? No
I'm tired of of morons proposing half-baked retarded ideas.
Re: (Score:1)
Nothing "nonsensical" about "short" and "long long", they're 18 and 72 bits on one non-IBM mainframe, there are more types of processors in this world than what you know about, x86 boy
Re: (Score:2)
* iostream performance [gitlab.com] is crap. [fastformat.org] This has been known about since 2013 [youtu.be]
Are you kidding me? Are they still struggling with that? iostreams performance problems go back way longer than 2013, I actually thought that was a 1990's problem that they surely must have solved by now.
It's the perfect illustration of where C++ fails to live up to its promise. If you look at the iostreams design, there's some nice thinking behind it. The idea is to replace the slow printf interpreter with compile-time machinery for the double benefit of type-safety and speed. In theory all those laye
Didn't read, of course, but... (Score:5, Funny)
I assume in response to this: "How C++ Programming Language Became the Invisible Foundation For Everything" the answer was "mistakes were made".
foundation for what? (Score:1)
Most devices are mobile, they use C and Java (Android) or C and Objective-C (iOS)
Also Windows kernel is C, the C++ is layers about that.
C is the foundation. C++ is facade and interior decoration.
C++ is beautiful, and can do everything (Score:3)
Procedural, OOP, functional, high-performance, backwards-compatible, you name it. It's an unholy mess and half the time you're walking through a minefield, yes, but you can go wherever you want. C is the basis of everything, C++ is that too, plus a million ways for more fun and self-harm :)
Re: (Score:2)
Procedural, OOP, functional, high-performance, backwards-compatible, you name it. It's an unholy mess
You know what's even more messy? People writing all those "paradigms" in languages that don't support them. Just look at C libraries and Javascript trying to support OO.
C++ is actually really simple - no one writing professional C++ actually cares about what paradigm they're using. It only matters to poor programmers and noobs who can't program but are actually just cargo culting it.
In C++, all there is is the question "what minimal thing do I need to implement this functionality?". It also gives the