Is C++ More Popular Than C? 141
Last month TIOBE announced its estimate that the four most popular programming languages were:
1. Python
2. C
3. C++
4. Java
But this month C++ "overtook" C for the first time, TIOBE announced, becoming (according to the same methodology) the #2 most popular programming language, with C dropping to #3. " C++ has never been that high in the TIOBE index," says TIOBE Software CEO Paul Jansen in the announcement, "whereas C has never been that low."
1. Python
2. C++
3. C
4. Java
C++ started a new life as of 2011 with its consistent 3 yearly updates. Although most compilers and most engineers can't take up with this pace, it is considered a success to see the language evolve.
The main strengths of C++ are its performance and scalability. Its downside is its many ways to get things done, i.e. its rich idiom of features, which is caused by its long history and aim for backward compatibility.
C++ is heavily used in embedded systems, game development and financial trading software, just to name a few domains.
There's different rankings from the rival PYPL index of programming language popularity. It lumps C and C++ together to award them a collective ranking (#5). But unlike TIOBE, it shows Java [and JavaScript and C#] all being more popular (with Python still the #1 most popular language).
Of course, statistical anomalies could be also skewing the results. Visual Basic also lost two ranks in popularity in the last month, according to TIOBE, dropping from the #7 position to the #9 position (now falling just behind Go and SQL). This becomes the first time that Go has risen as high as #7, according to TIOBE's announcement — with Rust also reaching an all-time high of #17...
1. Python
2. C
3. C++
4. Java
But this month C++ "overtook" C for the first time, TIOBE announced, becoming (according to the same methodology) the #2 most popular programming language, with C dropping to #3. " C++ has never been that high in the TIOBE index," says TIOBE Software CEO Paul Jansen in the announcement, "whereas C has never been that low."
1. Python
2. C++
3. C
4. Java
C++ started a new life as of 2011 with its consistent 3 yearly updates. Although most compilers and most engineers can't take up with this pace, it is considered a success to see the language evolve.
The main strengths of C++ are its performance and scalability. Its downside is its many ways to get things done, i.e. its rich idiom of features, which is caused by its long history and aim for backward compatibility.
C++ is heavily used in embedded systems, game development and financial trading software, just to name a few domains.
There's different rankings from the rival PYPL index of programming language popularity. It lumps C and C++ together to award them a collective ranking (#5). But unlike TIOBE, it shows Java [and JavaScript and C#] all being more popular (with Python still the #1 most popular language).
Of course, statistical anomalies could be also skewing the results. Visual Basic also lost two ranks in popularity in the last month, according to TIOBE, dropping from the #7 position to the #9 position (now falling just behind Go and SQL). This becomes the first time that Go has risen as high as #7, according to TIOBE's announcement — with Rust also reaching an all-time high of #17...
Yes (Score:3)
If you look at job postings on LinkedIn, you'll see vastly more C++ jobs than C jobs.
Re: (Score:2)
C jobs are more common for embedded work. Unless you're searching for that kinda work, you won't see those ads.
But the most likely explanation for the TIOBE index is people clicking on both C and C++.
Re:Yes (Score:4, Informative)
C is like perl - when its coders can't figure something out, they don't do a web search - they hop onto some IRC channel that's been running continuously since 1994, and ask there.
Re: eh (Score:2)
Reusablecode tends to be very complex. And there is no guarantee that in systems programming that you won't have to dive into that code and understand it. Usually I end up there when dealing with toolchain and compiler issues. As gcc and clang aren't quite as bulletproof as one might imagine, especially if you're off the beaten path. This isn't necessarily an argument to use C over C++, but that there are trade offs that each team much asses independently.
Re: (Score:2)
It's sad to see the fact that C has so few features
That is rather sad (and it's why so many people use C++ or even higher-level languages instead of C for a lot of things), but OTOH there are a number of low-level programming areas where you just need the language to get out of your way, do exactly what you tell it to, and definitely not do any "clever" things for you behind your back. For those cases, C is very well-suited.
you have to basically reinvent every bloody thing from scratch every time
Not if you have any kind of foresight as a developer. If you have to develop a feature, it's well worth your time to make it reusable
Re: eh (Score:2)
Re: (Score:2)
I've been using C for more than 30 years. I've never once felt like I need to "basically reinvent every bloody thing from scratch every time". Why do you think that is?
Give it a few minutes, it's not all that hard to puzzle out. It'll be worth the effort. Once you figure it out, your entire world is going to change.
Re: (Score:2)
how many times did you start a new C project from scratch?
Never? I've occasionally had to implement parts of the standard library, but that almost never happens. What, exactly, does "from scratch" mean to you?
it's not a surprise you didn't have to reimplement everything
That's my entire point. Between the standard library and my own collection, I'm certainly not implementing "everything every time" as the parent claims.
At the absolute extreme, even if all you do is produce C compilers for novel hardware, you're not going to start every project "from scratch". It's an absolutely ridiculous claim.
Re: Yes (Score:2)
It's even worse than you think. Look at the website listed in his profile.
Re: (Score:2)
The "evolution of C++" could be described as major blunders and mis-steps, the same ones that Python, PHP, Perl, Java and even Javascript have been doing, and all of those have been repeating the mistakes of C++.
A programming language needs to be as backwards compatible, FOREVER, otherwise it's a DEAD language. You can not demand that programmers rewrite 20, 30, 40 years of programming just because the idiots in charge of the standard decided to change the function named "strcpy". If you want to change the
Re: (Score:2)
To be fair, Javascript hasn't broken compatibility since it was invented. It drags the quirks it has had since the beginning where 0=="0" and "0"==0 give different results. What has changed is that some runtimes (node) have dropped support for the things those same runtimes invented in the first place.
Python, on the other hand, keeps breaking things for the sake of breaking things. Python 3 is fundamentally incompatible with python 2, and major dot releases are only mostly compatible. The problem is that de
Re: Yes (Score:2)
Is there any reason you can't use an HAOS VM ?
Re: (Score:2)
first of all, basically that the only VM solution that works on FreeBSD is VirtualBox and it breaks with every FreeBSD dot release as it relies on a kernel module. So with every freebsd upgrade I need to rebuild VirtualBox from source, and lock the package to prevent upgrades. It's very slow and annoying. The solution proposed by FreeBSD, bhyve, does not work. It's an abandoned piece of software that can only run by freeBSD gurus. I've requested support many times on "how do i run a linux vm" and have never
Re: Yes (Score:2)
Re: (Score:2)
The course was about safety critical real time applications. The professor clearly was not a fan of C and C++ in that environment.
Re: (Score:3)
Sort of. C++ best practices are opt-in, but do eliminate a lot of the most egregious gotchas found in C, especially in "modern" C++, which eliminates most manual memory management. The difference is that when C++ classes or interfaces are well designed, it's more difficult to misuse them subsewuently. In C, you need to be careful all the time because those compile-time assurances are not there. Of course, in compensation, C is a much simpler language overall.
I'd agree that neither C nor C++ would be at
Re: Yes (Score:5, Interesting)
Fully agreed. In particular, it's about STL.
In C, every time you want to allocate memory, you need to remember to free it yourself. With STL, you almost never do.
With C, every time you want an expanding array, you have to code it yourself (easy to make mistakes). With STL, you don't.
With C, all data structures are written from scratch. With STL, you rarely need to.
With C, all pointers are dumb. With STL, you have the option of smart pointers that self-cleanup.
With C, threading is a mess. With STL, it's much easier to launch and manage (can even run commands inline with lambdas).
With C, you need to deal with all locking and unlocking manually. With STL, you can use std::lock to automatically unlock when it goes out of scope.
On and on. The most common types of errors made in C just don't exist in STL. C is just dangerous.
I switched from C to C++ like two decades ago when I got past the notion that C was fast and clean and C++ wasn't. Because it's just not true. Like, for example, std::sort is usually way faster than C's qsort - not only is it a better algo, but shock of all shocks, having code templated to the right variable type and not having to dereference pointers is a good thing, performance-wise.
Of course today I mainly code in Python, but C++ is still good for when you need a tight, fast routine. Rust might be a better option, but I do it so seldom (and never in a business environment), and C++ has a so much wider and more mature ecosystem, that it's not been worth bothering learning for me.
Re: (Score:2)
> but shock of all shocks, having code templated to the right variable type and not having to dereference pointers is a good thing, performance-wise.
So what? If qsort() is the bottleneck (it hardly ever is IME) and inlining solves the problem, one can still implement a faster or equally fast algorithm in C. More work? Of course, but kinda cool too.
Re: Yes (Score:5, Insightful)
So what? If qsort() is the bottleneck (it hardly ever is IME) and inlining solves the problem, one can still implement a faster or equally fast algorithm in C. More work? Of course, but kinda cool too.
Given that a human programmer can only write (and debug, and maintain) a finite number of lines of code per year, the ability to write an algorithm that is optimized for use with a particular datatype is very limited in C. You'd only do it where it was absolutely necessary, and for everything else you'd fall back to a datatype-agnostic (but slower and more awkward) generic algorithm in the style of qsort().
With C++, OTOH, you write your datatype-agnostic algorithm as a template, and you get the best of both worlds: optimum runtime efficiency (since it compiles to a datatype-specific algorithm as necessary at compile-time) and also optimum programmer-time efficiency (since you only had to write/debug/maintain one routine rather than a separate-but-similar routine for every datatype where performance is a factor).
That was the primary motivating use-case for C++ templates, and it's why they are so popular even despite the fact that their syntax is a bit of a nightmare.
Re: Yes (Score:2)
Re: Yes (Score:2)
And don't forget, that with C++ you also get object oriented disease!
Re: Yes (Score:2)
The main problem with OOP from my perspective is inheritance and all of the baggage that goes with it.
Re: Yes (Score:2)
Re: Yes (Score:2)
It's still annoying, and when you want reusable code you have to create often kludgy wrappers because interfaces alone can't make one thing fit within another thing's inheritance tree. Especially when libraries only give you abstract classes.
This is also part of the reason why object oriented languages age so poorly: An ever increasing range of mutually incompatible inheritance trees.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
If only C had things like functions and libraries, you wouldn't need to do so much 'from scratch'.
... SMH ...
Parsing Bug (Score:5, Funny)
downside (Score:4, Insightful)
The problem with C++ is the un-intuitive design that leads to many pitfalls that are easily fallen into.
Re:downside (Score:5, Informative)
The problem with C++ is the un-intuitive design that leads to many pitfalls that are easily fallen into.
In the early 1600s, the Puritans brought cows to the Plymouth Colony, and the cows soon wore paths between their barns and pastures. When walking between their fields, farmers used the same paths. As the settlement grew, more houses were built along the paths, and the paths were widened to accommodate wagons. Soon, larger buildings were constructed along the same roads, and the roads were paved for automobiles. So when people wonder why the streets of Boston are such a mess, it's because the layout of the streets is based on where cows walked 400 years ago.
C++ was designed the same way.
Re: downside (Score:2)
You have to give those cows credit though, because Boston roads were designed better than Los Angeles roads.
Re: downside (Score:2)
Speaking as an American who grew up in the bladerunner land and now lives in Boston, you just don't know any better.
Re: downside (Score:2)
If you want that, have a look at Phoenix. Perfect grid so it's easy as hell to navigate. At the same time, there are parks everywhere, generally at least one for every city block, but often more. The reason why is they double as storm basins both to prevent flooding the roads and to replenish the natural groundwater.
This is as opposed to Los Angeles, whose roads not only make no fucking sense at all and the road signs double as graffiti canvas so you can't read them anyways, but their solution for storm wat
Re: (Score:2)
The two aren't separable.
The upside of C++ is it's strong source compatibility with C. You can take an old C project and slowly upgrade piecemeal without a rewrite making it shorter, simpler and less buggy by slowly introducing C++
https://m.youtube.com/watch?v=... [youtube.com]
Also closely related is it's backwards compatibility. Code I wrote and debugged in 2003 still works and I still use it.
But that leads to the design. The design is only intuitive if you understand C well, and the whole design and ongoing changes to
Re: (Score:2)
The two aren't separable.
Well that's a lie. You can have intuitive design while still maintaining backwards compatibility.
Also closely related is it's backwards compatibility. Code I wrote and debugged in 2003 still works and I still use it.
Yeah, C++ deserves a lot of credit for backwards compatibility. Many other languages should learn from that. As Doug Crockford said, "a backwards-incompatible change is an act of violence." (paraphrased). So 10 points to C++.
The design is only intuitive if you understand C well, and the whole design and ongoing changes to C++.
No that's not true at all. For example, operator overloading is a cool feature and a good idea in some cases, but it's a mess in C++ due to poor design. That has absolutely nothing to do wit
Re: (Score:2)
Ok, well to continue this conversation let it be noted I'm arguing with the kind of fuckwit who can't grasp the difference between a lie and a difference of opinion.
Anyway as expected you haven't actually backed up your opinions with anything, so there's no conversation to be had.
Re: (Score:2)
Anyway as expected you haven't actually backed up your opinions with anything,
You said that it's impossible to create new features in C++ without unintuitive design. You didn't explain why you think that.
Re: (Score:2)
You called me a liar for having that opinion.
No one has managed what you claim is possible. There's C++ and over the last 30-years an almost endless stream of contenders. None of them have managed almost complete C source compatibility work an "intuitive" design.
You are claiming that something which guess not exist is possible, provide no evidence that it is possible and call naysayers "liars".
How about you take your stupid opinions and piss off?
Re: (Score:2)
How about you take your stupid opinions and piss off?
Oh, now you're angry. Anger let's people manipulate you.
None of them have managed almost complete C source compatibility work an "intuitive" design.
Really? You really 'believe' that?
Re: (Score:2)
Oh, now you're angry.
Not especially, you snivelling wankstain, I just see no reason to be anything other than utterly rude to you since you decided to open with calling me a liar for having a different opinion.
Naturally you cannot provide any evidence of your supposed intuitive design, which you called me a liar for not knowing about.
Turns out you're another boring, blowhard tosspot with many opinions and little intelligence.
Re: (Score:2)
Re: (Score:2)
Oh right I see you are too stupid to have an actual argument so you go straight for accusations of lying.
Ugh why do I keep engaging with morons who cannot provide a single shred of evidence or reasoning to back up their arguments?
Re: (Score:2)
Why exactly do you think it's a mess in C++? It has a few pitfalls:
Re: downside (Score:2)
Re: (Score:2)
Re: (Score:2)
Yes, because it's a useful feature with a short list of well-known and easily-avoided pitfalls. Once again, how would you improve the design? Would you just make it impossible to overload the unary &, && and || operators?
Issues with confusing behaviour caused by implicit conversions between pointer, integer an Boolean types are inherited from C, but the situation has been improved in recent updates to the language standards.
It would have been nice if explicit cast operators and constructors we
Re: (Score:2)
Once again, how would you improve the design? Would you just make it impossible to overload the unary &, && and || operators?
Ruby has a much easier approach with fewer pitfalls, for example.
For better or worse, a bunch of things in C++ are the way they are because that's what Cfront did, and what Cfront did effectively was the standard (similar to Perl 5 which had an official policy of, "When the interpreter and the documentation disagree, the interpreter is correct," and the current situation with Rust where there isn't a formal standard and the reference implementation is considered "correct" by definition). That's how we got things like SFINAE.
Ok, well now you are explaining why C++ is a bad design, but that's agreeing with me. My point was that C++ is bad design.
Re: (Score:2)
Re: (Score:2)
The problem with C++ is the un-intuitive design that leads to many pitfalls that are easily fallen into.
Right, but the un-intuitive design is a direct consequence of having so many features and a mandate to maintain near-100% backwards compatibility across 45 years of evolving language and library design.
Or to put it another way: it would be possible, in principle, to take C++, chop out all the backwards-compatibility cruft and unsafe or no-longer-considered-best-practices misfeatures, and declare the result to be a new language that would have most or all of the power of C++ with none of the sharp edges. T
Re: (Score:2)
Right, but the un-intuitive design is a direct consequence of having so many features and a mandate to maintain near-100% backwards compatibility across 45 years
No, that is false. It is an excuse you believed for some reason.
C is elegant design. C++ is crap design. Pretending that the crap design was necessary because of "backwards compatibility" doesn't even make sense, I don't understand why you believe that.
Re: (Score:2)
Pretending that the crap design was necessary because of "backwards compatibility" doesn't even make sense, I don't understand why you believe that.
You misunderstood. The implementation of the crap design wasn't necessary -- a better standards committee might well have produced a better design. Unfortunately, they didn't.
But once the crap design was finalized and widely adopted, the preservation of the crap design became necessary, because once a large number of people have written software that relies on C++ working a certain way, to break all that code would be language suicide.
And that's why C++ remains difficult and error-prone today. Even if ev
Re: (Score:2)
But once the crap design was finalized and widely adopted, the preservation of the crap design became necessary,
That doesn't need to get in the way. For example, friend was basically deprecated and no one uses it anymore, so it's still there (good!), but it doesn't prevent good new design.
Re: (Score:2)
That doesn't need to get in the way. For example, friend was basically deprecated and no one uses it anymore, so it's still there (good!), but it doesn't prevent good new design.
I'll give you an example of the problem.
An infamous C++ design mistake was made in the implementation of std::vector<bool>. The implementers thought they'd be clever and save memory by storing each boolean value in a single bit rather than wasting an entire byte on it. They did that by implementing special proxy-logic code for the bool & operator[size_t] operators for that that one type, and succeeded in reducing memory-usage -- but also in making std::vector<bool> behave differently from
Re: (Score:2)
Or you can do it the C way, and just emit a compiler warning every time someone uses std::vector with a bool. In C it's with the gets() function. gets() has been there for 40 years, but no one uses it. No need to remove it.
I'm sure there are other ways of dealing with it.
Do you really care? (Score:5, Insightful)
Unless you're a limp one-language trick, you learn to write reasonable code several languages quite early in your career and then you just add more.
I don't know what car analogy is there, maybe defining your auto mechanic skills by the brand of wrenches you use.
Who does that?
Re: (Score:2)
Re: (Score:2)
Yes, so eventually you learn all that matter. And some that don't.
Re: (Score:2)
"Reasonable" code? (Score:2, Insightful)
I hate to break the news to you my friend but a lot of employers want a lot more than "reasonable" code particularly in aerospace and defence where I've worked (where admittedly is usually more a case of Ada and restricted versions of C than C++) so you won't get away with moderate knowledge of a language, you need to be absolutely on point.
"the brand of wrenches you use."
C++ is not a wrench, its more like a full workshop including OBD diagnostics and it literally will takes years to get up to proper speed
Re: (Score:2)
If you are starting a project with budget of 10 million dollars or more and it is estimated that the project will be online for a decade or two and there are other requirements for the projects also, do you care what language you use in the project?
You need to worry
- Where do you get the developers for the project?
- Where do you get new developers after a decade?
- Is the language active after a decade? Does it get security updates?
- Does the language have license costs or legal issues?
- Does the language wo
Re: (Score:2)
Yes, you need to worry about many things, and most of the things you need to worry about are quite tangential to the "popularity" of the language today as measured by the number of Google searches of the language name in the past month.
Re: (Score:2)
Yep. And sometimes there's that one car you just can't let go and it needs that particular tool, so we have a few of these knuckles permanently wrapped in mental band-aid :)
Again? (Score:3, Insightful)
Anyone who makes any kind of decision based on this is out of his mind.
Who keeps submitting this?
Re: (Score:2)
Anyone who makes any kind of decision based on this is out of his mind.
The TIOBE index is flawed but is a rough measure of popularity.
Popularity is important when choosing a language. The more popular a language is, the easier it will be to hire proficient programmers. There will also be more libraries, documentation, and support available.
Also, there are reasons why unpopular languages are unpopular. I've worked with Ada, Ruby, and Haskell. I am very happy to watch them die.
Re: (Score:2)
The more popular a language is, the easier it will be to hire proficient programmers.
And it will be even easier to hire bad programmers, because the market is saturated with them.
Re: (Score:2)
You can find bad programmers for any language.
Re: Again? (Score:2)
Maybe. I would expect, and yes that is purely subjective and speculative, that the proportion of "bad" coders is higher with more popular languages. For instance I would feel much more confident hiring a Lisp developer than a JavaScript developer. Reasons are variations of the fact that one language is more accessible (if anyone can use it, then any idiot can use it).
Re: (Score:2)
It's not flawed, that would imply it does an overall sane thing but in a way that's not quite right. TIOBE is not even wrong.
They just look at an arbitrary number returned by some search engines then apply ill-defined fudge factors.
Problem is, Google results have little to do with actual usage. Somebody had a spat and duplicated a Wiki? Language got more popular! Popular site dropped off the net? The reverse. A programming language takes the absolutely trivial step to maximize of "$LANG programming"? Sudden
Read the Definition of their ranking. (Score:2)
> The ratings are calculated by counting hits of the most popular search engines. The search query that is used is
> +" programming"
> The number of hits determines the ratings of a language
So, what they are saying is that python has the most number of people posting online for help on how to do basic stuff.
Re: (Score:2)
Should have read +"{language} programming".
Always forget that SL can't post angle brackets in comments.
Re: (Score:2)
< and > produce < and >
& to produce &
Slashdot supports a few other named HTML entities, not sure if there is a list. — for — and – for – are the only ones that come to mind ATM.
Finally! (Score:2)
Re: Finally! (Score:2)
No, Linux did have an inkling of what he was doing. Programmers do not want to hear it but C++ is on a downward slope. The problem being it is an inherently insecure language with possible buffer overflow and memory type exploits that remain a possibility within the C++ world. It's a needless liability for companies when there are much more secure languages arriving (aka rust). Lawyers will be able to litigate that these new languages are not being used if there happens to be a bad data breach!
Companies are
The main strengths of C++ are its performance (Score:2)
Hmmm. (Score:2)
A language that evolves fast has, by definition, both constructs that were poorly thought-out and a lack of constructs that developers actually need.
Since backwards compatibility is built-in, it also has a vast amount of cruft. And this is the really bad part. That cruft will include constructs that are rarely, if ever, used, so are rarely, if ever, tested. It also has to handle an ever-increasing number of cases, which means the compiler is more complex (so will contain more bugs) and will be slower (impac
Re:Hmmm. (Score:4, Interesting)
I'm going to dispute most of this. C++ isn't perfect but...
C++ hasn't evolved fast. If anything it's been pretty slow, especially the painfully long 98 to 11 gap. It's now 45 years old, old enough to be the parent of some people with "senior" job titles.
C++ doesn't have vast amounts of "cruft" as you call it. It certainly has rarely used features, but they are things that you absolutely need but rarely and that serve as foundations.
If you are using volatile a lot, or lock free concurrency constructs a lot, or manual memory allocation a lot, poor explicit lifetime management a lot, then you are likely doing something wrong. But you need all of those in the language because without low level constructs you cannot build the higher level ones. They should all generally be wrapped and rarely seen floating in the wild, but you still need them.
So I challenge you, find some features which fit the mould of "cruft" especially ones that have complex interactions that cause problems and for which there is a reasonable alternative.
Many many attempts have been made to "overhaul" C++ without keeping compatibility. Many have failed, some have succeeded in their own right but very very few have even managed to scratch the domains where C++ is very good.
If it's not compatible in some way, then you lose the advantage of decades of very vert solid libraries. So really it has to offer something more than a temporary cessation of "cruft".
But no, I disagree that C++ is massively over engineered.
Re: (Score:2)
Still, kind of wish there was some clarification on what const
Re: (Score:2)
A "static" member of a class is most certainly in no way static like an English dictionary would define the word.
I looked up the word static in the dictionary and it lists 9 different definitions. Static simply means the thing (e.g. function, variable) is scoped to the TU rather than the container (e.g. function or class) in which it was defined.
One of the many definitions of static is stationary which seems apt.
Re: (Score:2)
Then look up the different meanings of static in C/C++/Java.
It does not mean,. what you think it means.
And in case you want to reread your sentence: Static refers to allocation of a variable - strictly speaking: it is wrong.
Re: (Score:2)
Agreed. When C++ was designed, nobody expected it to be used as a general purpose language. Oh, and look, it is not. For example, things like inefficient virtual function dispatch are a dead giveaway that it is not even a proper OO language. Another is the general non-orthogonal nature of visibility, which is screwed up to an impressive level. There are more. This is a complex, hard to handle monster with surprises in too many places and it should never have seen the light of day.
My take is the only reason
Re: (Score:2)
Really, C++ needs a complete overhaul, backwards compatibility be damned.
You're not wrong -- the only problem is, backwards compatibility with existing C++ codebases (and existing C++'s developers' brains) is the main reason for C++'s continued popularity. The beautiful shiny language that comes out at the end of your overhaul wouldn't be C++ in any meaningful sense of the word, so almost nobody would use it. (The people who would use it are already using Rust ;) )
Re: (Score:2)
C++ needs a complete overhaul, backwards compatibility be damned.
Right, and call it "Rust".
Re: (Score:2)
Wtf? Just add the keyword "pure" FFS!
The counterargument is that adding the new keyword would break all existing code that uses "pure" as a variable or function name or etc.
So for consistency, the C++ committee decided to do what they usually do: sometimes add a new keyword (potential breakage be damned) and sometimes adopt a weird syntax to avoid adding a new keyword. /s
Give it up! (Score:3)
There is literally (used correctly) no way to say which is "more popular" as that term is not defined. More people using it? More downloads? More complete programs produced? (not that you could really count that anyway)
The only important metric is if the language is still being used and evolving/being supported. This penis measuring competition is meaningless.
TIOBE doesn't rank code that makes money. (Score:2)
Re: (Score:2)
Rubbish. Where do you think bespoke coders go to answer their coding questions?
C jobs are often less explicite (Score:2)
For example, a lot are things like writing firmware, drivers, high-performance software, etc. C++ is pretty unsuitable for these.
Re: (Score:2, Interesting)
Not a shred of truth to that. Educate yourself. [www.qt.io]
Re: (Score:2)
No need to educate myself. Your view is rather limited. On new designs with an all-C++ enabled development team, there may even be some truth to your reference. But that is not the standard case.
Fact is, the C++ fans have been pushing how great their language is for everything for a long time. Nobody outside that community believes it and for good reasons. This effect can be observed with other language communities as well.
Re: (Score:2)
It is apparent that you have zero experience in this sector, which does not stop you from spewing rubbish. Embedded c++ development platforms have been popular since the early 90's.
Re: (Score:2)
And is the term "embedded" anywhere in my original posting or my response? No, it is not.
Re: (Score:2)
WTF does "firmware" mean to you?
Re: (Score:2)
So use go-to, then what's the problem?
It's not like goto causes instant code death.
Anyway just because you can't figure out the new features doesn't mean the rest of us can't make good use of them.
Re: (Score:2)
Well you understand logical fallacies about as well as you understand C++.
You were whining about the committee not adding features for which there is a perfectly good solution.
Also you are complaining no one uses the features when in reality those of us who understand then use them.
Re: (Score:2)
Are you a GPT work a very small token buffer?
You appear to have forgotten that you referred to unspecified "endless crap".
Those features. The "endless crap" you refer up is the features you can't figure out. Or feel free to specify then I can mock you for your lack of skill.
Re: (Score:2)
Right... so you can't actually list a feature. The old "trust me it's in there prove me wrong" attitude.
Angry opinions are a great substitute for intelligence and skill, I hear.
Re: (Score:2)
You no doubt won't have heard of them , but go check out some of the 2017 type_traits meta constructs. If there's a real world use for that crap then I'll be amazed.
Re: (Score:2)
Oh right you're whining about some small bits of library code that you are too unimaginative to use as a feature.
But do go on be specific. Which one do you do object to?
Re: (Score:2)
If you have to use imagination to use a feature then you're not solving a problem, you're thinking up excuses to piss about.
"But do go on be specific. Which one do you do object to?"
Go on genius, give me a *real* world example for a use of is_move_constructible - ie a situation where you couldn't complete the program without it.