C++20 Is Feature Complete (hackaday.com) 231
Long-time Slashdot reader mejustme shared this report from Hackaday:
If you have an opinion about C++, chances are you either love it for its extensiveness and versatility, or you hate it for its bloated complexity and would rather stick to alternative languages on both sides of the spectrum. Either way, here's your chance to form a new opinion about the language. The C++ standard committee has recently gathered to work on finalizing the language standard's newest revision, C++20, deciding on all the new features that will come to C++'s next major release.
After C++17, this will be the sixth revision of the C++ standard, and the language has come a long way from its "being a superset of C" times. Frankly, when it comes to loving or hating the language, I haven't fully made up my own mind about it yet. My biggest issue with it is that "programming in C++" can just mean so many different things nowadays, from a trivial "C with classes" style to writing code that will make Perl look like prose. C++ has become such a feature-rich and downright overwhelming language over all these years, and with all the additions coming with C++20, things won't get easier. Although, they also won't get harder. Well, at least not necessarily. I guess? Well, it's complex, but that's simply the nature of the language...
From better type checking and compiler errors messages to Python-like string handling and plans to replace the #include system, there's a lot at play here!
The article mentions coroutines, the spaceship operator for three-way comparisons, and "a bunch of additions to lambda expressions," as well as a new keyword constinit and removing limitations on the usage of constexpr.
And in addition, "ranges are the new iterators" and concepts "have graduated from being an experimental feature to a full-fledged part of the language standard, allowing the addition of semantic constraints to templates, and ultimately making generic programming a hint more specific."
After C++17, this will be the sixth revision of the C++ standard, and the language has come a long way from its "being a superset of C" times. Frankly, when it comes to loving or hating the language, I haven't fully made up my own mind about it yet. My biggest issue with it is that "programming in C++" can just mean so many different things nowadays, from a trivial "C with classes" style to writing code that will make Perl look like prose. C++ has become such a feature-rich and downright overwhelming language over all these years, and with all the additions coming with C++20, things won't get easier. Although, they also won't get harder. Well, at least not necessarily. I guess? Well, it's complex, but that's simply the nature of the language...
From better type checking and compiler errors messages to Python-like string handling and plans to replace the #include system, there's a lot at play here!
The article mentions coroutines, the spaceship operator for three-way comparisons, and "a bunch of additions to lambda expressions," as well as a new keyword constinit and removing limitations on the usage of constexpr.
And in addition, "ranges are the new iterators" and concepts "have graduated from being an experimental feature to a full-fledged part of the language standard, allowing the addition of semantic constraints to templates, and ultimately making generic programming a hint more specific."
Erlang whoaa more hipster grade (Score:2)
Who needs C++ when there is elexir or techno psycobitch [youtu.be] that will even be cooler than rust with the she hipsters
Re: (Score:3)
Re: (Score:3)
Heh, nice. So, about std::format()... I'm actually really looking forward to this addition. The fmt library, which this is based on, is really great to use.
A lot of people give C++ crap for this (yes, sort of funny to have three string format libraries), but honestly, it's just the result of a pragmatic realization that stream operators was just not great for string formatting. Nearly everyone I know vastly prefers simple, concise printf style formatting, but printf is really pretty awful as well - passi
Re: Erlang whoaa more hipster grade (Score:2)
Re: (Score:2)
Yep, I could tell the ribbing was good-natured. Keep in mind this is strictly a string formatting library, not a logging library, so it's really more a replacement for sprintf() than for printf(). It's always hard to be certain, but having used the fmt library for a while in my own projects, I'm pretty sure this will be a very useful and well-received addition to the std lib.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
If your first and only thought is speed, you'll never understand preferring C. I use some OOP when needed, like accessing archive files in a consistent way. Or the std templates like vector. But otherwise there's not much point. I don't do game engines where the complexity has to be managed and boundaries drawn for separation of concerns.
If I did need that, I'd use C# because the standard library is huge and we'll tested, it can be as fast as C, and productivity is so much better than C++ in general. C++ is
Re: (Score:2)
It depends on your job.
> I'll take care of freeing my own memory, thank you.
Famous last words.
C is unsuitable for a vast majority of modern programming tasks. It is serviceable only in situations where we can afford to have a lot of eyes to inspect it for errors since it is the most error prone statically typed language ever.
It sounds like you only learned C and did not spend much time in other paradigms.
C++ and Rust don't produce bloated code at all.
If you are new to programming and don't need a lot of
Re:Simplicity (Score:5, Informative)
It depends on your job.
> I'll take care of freeing my own memory, thank you.
Famous last words.
Yes, manual memory management is a pain and error prone. On the other hand, I am not fully convinced by most automatic approaches used in other languages. If you use C, you would usually rely on additional tools to check for errors (sanitizers, valgrind, etc.). This works really well in practice.
C is unsuitable for a vast majority of modern programming tasks. It is serviceable only in situations where we can afford to have a lot of eyes to inspect it for errors since it is the most error prone statically typed language ever.
If I look at all the programs I use often, most of them are written C (linux, xcfe, bash, terminal, vim, x11, postgresql, git, gimp evolution,evince, etc.).The three big exceptions are: the web browser, gcc, and openoffice. gcc is essentially still a C code base compiled with a C++ compiler (I occasionally contribute patches to gcc). The programs I use that are written C tend to be extremely reliable and light-weight, while those that are written in C++ feel less performant und are less reliable. For example, inkscape is another C++ program I sometimes use, but i tends to be slow and sometimes crashes. Openoffice is also not too performant. With Chromium which is written n C++ I am quite happy though. So I would say C works extremely well for all kinds of programming tasks and the result tends to be good. But of course, this is my biased view, maybe I don't know what "modern programming tasks" are.
It sounds like you only learned C and did not spend much time in other paradigms.
C++ and Rust don't produce bloated code at all.
If you are new to programming and don't need a lot of fancy features, you can still just use a small subset of C++ or Rust features.
You can certainly stick to a subset of C++ that does not produce bloated code. But I would say that many programmers don't.
Re: (Score:2)
"modern" programming tasks, perhaps I should call them business tasks - the kind of jobs you find on a typical job board - creating web sites, creating enterprise/in-house software, data analysis etc.
A good chunk of core software that I use was written in C too. But I have run into exactly zero programmers at work who used C as their main language since a couple of decades. I would use C to write small bits of code to create a library for use in a higher level language but I have never run into a scenario w
Where's muh kitchen sink? (Score:2)
Only added? (Score:3)
How about removing some features for once? Not that C++ is the only language with feature creep. Stuff that Java marked as deprecated back in version 2 is still in version 9. In fact, it seems to be incredibly rare that any language design committee dares to prioritise having a clean spec over backwards compatibility.
Re: (Score:2)
In fact, it seems to be incredibly rare that any language design committee dares to prioritise having a clean spec over backwards compatibility.
Oh, you should try Node.js. Backwards incompatibility is what it does. It will make you happy.
Re: (Score:3)
Go on, choose a feature and I'll tell you why it can't be removed.
Thing is if you want a different, incompatible language there are plenty to choose from, depending on your domain. If however you want to be able to (a) take advantage of some of the anguage developents of the last 40 years but (b) not rewrite well tested, working code from 15 years ago, then not removing features is not a bad choice.
In fact, it seems to be incredibly rare that any language design committee dares to prioritise having a clean
Re:Only added? (Score:5, Informative)
C++ has deprecated and removed features in each of the three most recent language revisions:
There are additional features deprecated/removed in C++20 (including e.g. the partial deprecation of volatile [open-std.org] as mentioned in the linked article) but I couldn't find a convenient list of them.
It is true that it is harder to remove features than add them, and people are usually more interested in what's new than what's been removed, so it does not get much attention. However, this doesn't mean it doesn't happen.
Deprecate Ponter Arithmetic (Score:2)
I wish they would do that.
And add proper 19802 style garbage collection.
Write once run everywhere would be good.
C++ is becoming as big as Java, but without the benefits.
Re: (Score:2)
Plus, you drop all of the overhead of using a virtual machine.
Only very limited types of use cases occur in the real world where VM languages like Java actually compete with C++ in terms of performance... and of those, virtually all can still be made to outperform Java if one approaches the problem differently (such as using custom allocators s
Re: (Score:3)
it seems to be incredibly rare that any language design committee dares to prioritise having a clean spec over backwards compatibility.
Python did that, breaking compatibility in Python 3. The result is that now there are two Python languages (Python2 and Python3), each with half the user base of the original, and for the forseeable future you have to support both of them.
Because it was not big enough (Score:2)
As a C++ programmer... (Score:3, Insightful)
.... I've got to say, I'm really tired of having to play catch up with the latest features just to keep some idiot interviewer happy down the line when I look for a new job when its almost certain most of their code is still C++98 with a bit of 2011 thrown in or to have to grok some code written by someone who wants o try out everything in the C++ guide appendix A-Z.
C++98 was a mess - 2011 was the language C++ should have been to start with. 2014, well ok, a few nice bits but generally meh frankly, and as for 2017, honestly who cared?
The language really is the proverbial kitchen sink now and IMO its probably time to call it a day. I'm really not interested in some new obscure bit of syntax that might save me 1 line of code and as for co-routines, honestly , who gives a shit - they're just glorified gosubs and will probably be a threading nightmare.
Re: (Score:2)
Yes, C++11 is finally a great baseline. In go, there are go routines, which is a dead simple model for threading. C++20 coroutines, though, are yea, meh, but I think if you look at the spec, resumable, etc, it sounds to me like a first stab at/foundation for eventually introducing python style "generators", and yes, that would be even more kitchen-sinkism.
Re: (Score:2)
C++ is a problem because it makes dysfunctional companies more obviously dysfunctional? Sounds like a feature not a bug to me. If the inter
Re: (Score:2)
"Everything in programming is glorified something else"
True, but there's a law of diminishing returns. Loops were a much clearer form of if-goto. co routines OTOH are not easy to read or follow and if you want generators there are much simpler and just as efficient ways to achieve it with inlined functions.
Re: (Score:2)
co routines OTOH are not easy to read or follow and if you want generators there are much simpler and just as efficient ways to achieve it with inlined functions.
What you can do with lambdas returning {lambdas returning lambdas}, you can replace with co-routines which make the logically linear flow control appear as linear flow control (with arbitrary pauses at the yield points). I figure at this point we both understand that as the mechanism and are both talking about the same thing.
I certainly agree you
Re: (Score:2)
"What you can do with lambdas returning {lambdas returning lambdas}, you can replace with co-routines"
I can't think of a single use case where lamdas returning lambdas is a sane thing to do. It just sounds like show off sphagetti code.
Co routines serve no practical purpose , they're an academic toy and as ugly as C code that uses setjmp and longjmp. If you want to keep state in a seperate code path but don't want to overhead of a stack push and pop and don't like globals then just use static inlined functio
Re: (Score:2)
Well, you could have mentioned parallel STL too ;).
But I really am getting very tired of kitchen-sink featurism extensions of the language.
A decades old bait-and-switch on programmers (Score:3)
Hey, I remember those times: "If you like your C programs, you can keep your C programs".
Too bad, much of C code will no longer compile with a C++ compiler and the fans will gleefully tell you, how C++ has "overgrown" that stage, when it had to gain the programmers' trust and midnshare by claiming to be a superset of C...
Re: (Score:3)
You don't really have to be a fan to say that. That feature was very important in the early years but it simply isn't now. Even now converting a massive old C codebase to C++ is doable (see GCC).
Re: (Score:2)
Too bad, much of C code will no longer compile with a C++ compiler
I've never seen any evidence of that, has anyone?
The only problems I've ever had compiling C inside a C++ compiler was when the C programmer used C++-reserved-keywords (like "new" or "delete") as variable names, and that was easily resolved with a simple search-and-replace (e.g. :s/new/newVar/g).
Am I missing something?
Re: (Score:2)
You're not missing anything, as I don't think there's much to that claim. Most large C++ project I know of make use of quite a few C libraries. It's true that C++ is no longer a strict superset of C, but it's been that way for quite a while. Most authors of C libraries take care to ensure their libraries compile with both C and C++. And since C and C++ programmers mostly use the same compilers, it's not hard to make a library compatible with both languages.
Re: (Score:2)
Yes, I have. Indeed, it is far from begin a secret. Wikipedia, for example, even say this (emphasis mine):
Had it been Microsoft — and had it been Slashdot of at least 10 years ago — someone would've brought
Re: (Score:2)
Re: (Score:2)
I've never seen any evidence of that, has anyone?
Well, there's the void pointer conversion without a cast (the biggest), VLAs, designated initialisers and a few others. VLAs are the hardest to work around, but not that hard.
I was really hoping for the dot operator.... (Score:3)
Without it, one is forced to relegate the semantics of their object to be similar to that of a smart pointer, which does not necessarily accurately reflect the intended functionality of the user-defined class.
Was the CoC good? (Score:2)
C++ is a grand undefined behavior factory (Score:3)
// One is quite obvious, 3 others are not unless you have years of C++ experience.
// you must be completely out of your fucking mind to use C++ for any new projects.
// compile with "g++ -c -pedantic -Wall -Wextra test.cpp"
// P.S. I don't give a shit whether this is "part of the language standard". If the standard permits it then it's just garbage.
#include <iostream>
class Base {
public:
Base() { std::cout << "Base()\n"; }
~Base() { std::cout << "~Base()\n"; }
int m_counter;
};
class Derived: public Base {
public:
Derived() { std::cout << "Derived()\n"; }
~Derived() { std::cout << "~Derived()\n"; }
};
int main() {
Base* b = new Derived[10];
std::cout << b[10].m_counter << '\n';
delete b;
return 0;
}
// spoiler:
// 1. non-virtual destructor in base class. Derived destructor is never called.
// 2. use of uninitialized field m_counter.
// 3. array access outside of boundaries.
// 4. delete operator without []. Runtime errors are guaranteed.
Re: (Score:2)
You're the one out of your mind, undefined behavior exists with all languages in common use. C++ is fine solution for many problems and majors works used by hundreds of millions of people do just fine with it.
Re: (Score:2)
It goes both ways. C++ had move semantics, which Rust later copied.
Re: (Score:2)
It goes both ways. C++ had move semantics, which Rust later copied.
The entirety of Rust is based on C++ philosophy and coding style. The whole language
is 2016 C++ best practices made first class citizens.
Re: Sounds like C++ is borrowing from Rust (Score:2)
Re: (Score:3)
All of these changes have been in the works since before C++11. Bjarne started working on the proposal in 2009. I remember because I was longing for it to hit C++11, but the standards committee didn't feel it was mature enough. 9 years later the C++ folks let everyone else make the mistakes and are finally accepting it. I cannot wait.
Concepts have been in the works since the 1980s. They first came to prominence with the STL (1994ish, standardised in 1998) which pioneered the concept design, but without lang
Re: (Score:2)
The difficulty in making concepts happen marks the great failure of C++: templates. They should have just had a real, type-aware macro language. Instead for pre-processing there are c-preprocessor macros, templates, and constexprs, each completely unrelated.
Template meta-programming is the most perverse thing I've seen in any (non-joke) language. It does the right set of things, but the syntax is so damn bad that trying to express concepts took decades.
Re: (Score:3)
The difficulty in making concepts happen marks the great failure of C++: templates. They should have just had a real, type-aware macro language.
I won't disagree. They didn't actually know they'd created a language until years afterwards. It was meant to be a language integrated text substitution thing to replace macros with something more pleasant. It turned out to be Turing complete, and it's never a good thing to get Turing completeness by accident.
templates, and constexprs, each completely unrelated.
Th
Re: (Score:2)
Constexprs are clsoe to the right answer IMO. If you've ever messed about with Scheme, you may have seen extend-syntax, which is a macro language that is (a) a text-substitution thing when doing simple things, (b) a real programming language to do complex things, and (c) the same real programming language as the base language. That's the right pattern.
Something I worked on in college was a research project demonstrating that with the right simple primitives, and the right macro language, you could express
Re:What's the point of C++ now that we have Rust? (Score:5, Insightful)
What benefits does C++ give us that Rust doesn't
Backward compatibility, compilers from several different vendors, possibly less egos (I'm not sure about this one).
Re: (Score:2)
How easily does it interface with ladder logic?
Re: (Score:2)
Actually, one thing I will say about Rust is they do have a great core developer community, and not that much egoism in it. They also do listen to criticism, and don't simply answer "it doesn't match our pre-chosen ideology". Of course the problems I find in Rust I believe are original sins, such as choosing a C style syntax, and hence not changeable now, but still that is very different from my experiences with core go devs.
Comment removed (Score:5, Insightful)
Re: (Score:3, Informative)
Re: What's the point of C++ now that we have Rust? (Score:5, Interesting)
Rust also has one of the most equitable communities around because its Code of Conduct prevents bigotry, racism, sexism, transphobia, hate and intolerance.
Nowadays, I really suspect that everybody that mentions Rust's code of conduct instead of discussing the technical merits of the language, is a de-facto anti Rust troll. Even if you believe that Rust is the ultimate programming language, it would be wise to promote it based on its benefit, not based on how it "relates" to political conflicts which can't be solved by a programming language, no matter how good.
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2)
TLDR. Sorry, that's my policy for every comment about transgenders in a discussion topic that's about programming. I would react the same if I read an article about LGBT rights and someone started to write several paragraphs about programming language specs.
Bootstrapping to avoid Trusting Trust (Score:4, Informative)
There's no need for another Rust compiler because the existing one is free, open source, and excellent already.
Even if the compiler's source code is available under a free software license, compiling the Rust compiler requires a Rust compiler. This means someone could sneak a back door into the binaries, as Ken Thompson described in "Reflections on Trusting Trust" [cmu.edu] and Manish Goregaokar reiterated in "Reflections on Rusting Trust" [github.io]. The usual defense against a "Trusting Trust" style back door in a self-hosting compiler is David A. Wheeler's "diverse double-compiling" construction, which relies on having multiple independent implementations of a language. But there's only one widely used Rust compiler.
The other way is to make the build process so transparent and the initial binary seed so tiny that the majority of experienced programmers would be able to find and correct any irregularities. As part of the stage0 project [nongnu.org] to bootstrap from source code, someone wrote a simple assembler in raw machine code, a sophisticated assembler in simple assembly language, and a C compiler in human-readable (and thus auditable) assembly language. From there, Mes [gnu.org] can bootstrap old GCC, and from old GCC you can bootstrap modern g++. But how do you get from there to a Rust compiler, or even to an OCaml compiler to compile the first ever version of Rust?
Re: (Score:2, Informative)
Re:What's the point of C++ now that we have Rust? (Score:5, Interesting)
Rust has problems. They are not in the borrow rules and scoping lifetimes, those are actually pretty easy to grok. The problems are deeper. This was very apparent though watching a live demo by someone from Mozilla who used both rust and c++ performing a live demo, fumbling over and having problems with basic syntax, trying to convince us to use rust. This was just so painful to watch.
Rust tries to be a Haskell in C clothing, because C style languages are I guess more popular. But it uses so many strange and idiomatic constructs, much more so than other C-like languages. It also uses decorators, and does so for things that really should actually have been part of the core language, such as deriving traits. It is just a hot mess of quirky syntax that is hard to follow, and apparently hard even for those who already mastered it to use correct. Then, of course, Rust is also a (semi) functional language, rather than imperative, and C style syntax conveys that rather poorly. It would have been far better adopting a more expressive syntax, like Perl, it does risk being write once/read nowhere.
Re: (Score:2, Interesting)
Rust tries to be a Haskell in C clothing
This is much more true for C++ than for Rust. Rust tries (emphasis on tries) to only incorporate features that are safe, that can't cause people to shoot themselves in the foot. It tries to take features that have been tested before (either in C++ or other languages) and combine them in one (hopefully) well-engineered language. C++, on the other hand, incorporates features all over the place, without any cohesion, not minding if they contradict each other or cause over complication. It's almost as if C++ is
Re:What's the point of C++ now that we have Rust? (Score:4, Interesting)
Rust does similar lazy function evaluation, it actually copies the haskell trait system, and with the exception of being able to optionally mutate state, it could easily be described as a kind of Haskell. This doesn't make Rust bad, quite the contrary, it should make it far stronger for safe concurrent programming. However, all of this I think is perceptually lost and poorly expressed in respect to C style syntax and the other strange idiomatic rules. You look at it and think C/C++ like, when in fact it is conceptually very different. I think it is this sense of the uncanny valley that I think causes these problems, like this presenter had, as he apparently develops at different times in C++, Python, and Rust.
C++ is a true kitchen sink of different and often disjunctive ideas, yes, often lacking cohesion and with sometimes strange consequences, but it is expressed with a still fairly consistent syntax. However, unlike Haskell, I would not describe C++ as functional (well, one may take different meanings from that ;). They are in that respect very different animals.
Re: (Score:2)
However, unlike Haskell, I would not describe C++ as functional (well, one may take different meanings from that ;). They are in that respect very different animals.
You can use C++ as a functional programming language, it is an extremely multi-paradigm language. With C++11 (before C++14 and 17) you had to write all constexpr functions in functional-programming style.
Re: (Score:2)
There is a whole reddit thread I believe, on how rust managed to do safe and fast lazy evaluation, and when it does it.
Re: (Score:2)
Rust uses lazy evaluation now!? How the hell did they manage to make it efficient enough to compete with C++ and Golang?
If I was to guess. Rust isn't a lazy programming language, but reserves the right to evaluate some things lazy. Optional laziness like that, unlike hard laziness like Haskell has is a compiler relaxation. It makes it possible for the compiler to make more aggresive optimizations (you can eliminate more dead-code and reorder more without breaking the rules of the language).
Re: (Score:2)
Lazy evaluation makes ode faster, as parts that are not on the actual execution path are not evaluated.
No idea what you are aiming at.
Re: (Score:2)
Purist lazy evaluation (i.e. nothing that's not needed is not executed, 100% of the time) requires to do a lot of runtime book-keeping and even Haskell does not support it completely. I do agree that allowing the compiler to decide on its own the run order of the code and to omit dead code can result in faster execution, but this is also done, somewhat, in C++ compilers.
Re: (Score:2)
This is much more true for C++ than for Rust. Rust tries (emphasis on tries) to only incorporate features that are safe, that can't cause people to shoot themselves in the foot.
I think C++ has been aiming much higher than that. With C++ is easy to shoot yourself in the brain.
Re: (Score:2)
Yeah, but the funny thing is: you hit the brain and other parts regardless at what you aim.
Re: (Score:2)
Yeah more like Perl with the 100 data types in Perl 6 still in development since 2001. Erlang with declarative programming [youtu.be] is all the rage with the kids today
Re: What's the point of C++ now that we have Rust? (Score:2)
Re: (Score:2)
It was a private demo, and I do not want to embarrass the poor fellow further. But it did convince me and others we do not want to touch Rust. Yes, it was that awful a presentation. It also made me realize what I liked about Haskell and think about why Rust just feels wrong as a C style language.
Re:What's the point of C++ now that we have Rust? (Score:5, Funny)
What benefits does C++ give us that Rust doesn't?
Fewer zealots.
Re: (Score:2)
Re: (Score:2, Insightful)
Because only C and C++ have runtimes on all operating systems. Sometimes C++ runtimes do not exist on small 8-bit/16-bit microcontroller systems, but for the most part these are the only two languages that you are required to know to program anywhere. Even then you are better off with straight C.
C++20 is trying to turn it into python, and every version of C++ after C++11 with STL should have been called something other than C++.
I can't believe how co-routines are being pushed though, this is poor-mans threa
Re: (Score:2)
Speaking of Python, I believe, and given the resumable nature of coroutines suggests, that they are a way to later add python style generators. How many more strange different things can you toss in, and yet still not fix the network library??
Re: (Score:2)
Rust does seem to leverage at least some parts of libc. This becomes very apparent when you start cross compiling Rust, and does make it trickier to do than with go, which bundles in its own unique runtime. This, along with its ffi support, also makes Rust easier to leverage existing C libs. Of course, anytime you dip into C, that's unsafe from the Rust perspective. But Rust could be a much better optimized language than C++ for embedded uses, and is a more complete one than C. I had considered using R
Re: (Score:2)
But Rust could be a much better optimized language than C++ for embedded uses,
You can already run C++ on an attiny25 with a generous 64 bytes of SRAM. What optimizations does Rust offer that C++ doesn't?
Re: What's the point of C++ now that we have Rust? (Score:5, Interesting)
I guarantee you 10 and 20 years from now there will be C programmers. Python definitely, Perl yes, Java maybe. I wouldnâ(TM)t put much faith in Swift, Rust, or any other âoehipsterâ fad language. Yes they are definitely better in some ways and worse in others. At the end of the day who cares, why waste the time learning a new language. By the time you go through all of the gotchas, workarounds, and hacks of a new language you might as well just have used C.
Re: (Score:2)
C++ has stagnated for years IMO. When they FINALLY added lambda functions and threads in C++11 I thought maybe we'd get built in thread pools ala java and C# by 2014 (when java added it, C# already had them), but they still don't have them. They obviously don't care about parallel programming, but should - every PC has multiple cores now, even f**king Raspberry Pis have multiple cores. Sure you can roll your own (I did as far back as 1991), or use some of the very good add-on libraries out there but you sho
Re: (Score:2)
C++ has exceptional good multithreading support since decades. Minimum 2. All of Javas meanwhile also 10 year old concurrent library is copied from Doug Lea's Tao(? - ah, yes: TAO) project. http://gee.cs.oswego.edu/dl/ht... [oswego.edu]
They are not "standard" but portable mostly lockless multithreaded concepts/libraries.
Unfortunately for me, my life is heavily focused on interpreted languages these days (C#, java, javascript).
None of them is interpreted. They are all compiled (C#/Java) and then JIT compiled (C#/Java/Jav
Re:What's the point of C++ now that we have Rust? (Score:5, Informative)
What benefits does C++ give us that Rust doesn't?
* An open standard that multiple vendors can follow.
* Compilers from multiple vendors.
* Working compilers for all platforms.
* A consistent syntax.
Re: (Score:2)
Re: (Score:2)
Ubiquity
Re: What's the point of C++ now that we have Rus (Score:2, Funny)
Die like COBOL ha ha ha ha ha!
Re: What's the point of C++ now that we have Rus (Score:5, Insightful)
IT TAKES A LOT OF MONEY
Why? Because it takes a lot of time and effort. And time = money. I'm not talking about software that runs a company, I'm talking software that runs countries. Most developers are of the opinion that "we will just rewrite it in [pick your language]" and it's true. It can be rewritten. But the cost to TEST it is astronomical. The cost if it fails is even higher. So COBOL is still chugging along, with it's well tested code that is years old and working just fine. People who want to get into programming and are finding it hard should probably just approach a bank and offer to learn COBOL (on their dime) they would probably snatch you up. After all, after a year or three you can always move to your language of choice now that you have some work experience, if you are willing to take a salary drop that is. COBOL programmers are making a killing.
Re: (Score:2)
The programming paradigms of COBOL and modern languages are very different.
E.g. the concept of a process is different. In COBOL it is common that a process runs a short time, sets up its data in its memory and terminates. The surrounding JCL will launch a new program in the same process space and continue working on the set up data. While this is also possible under modern OSes no one is really doing stuff like that.
This makes rewriting or Y2K analyses/conversions a bit more challenging.
Re: (Score:2)
Worst haiku ever.
Re: (Score:2)
Indeed, it is clearly not a logical replacement for already working code. I had considered using it for entirely new projects for awhile, but the surprising cognitive costs to bringing existing people up to speed with it are what I feel kills that, so I have become rather skeptical.
Re: (Score:2)
Yeah, it is also I think why so many C++ people actually do want Rust to somehow succeed.
Re: (Score:2, Troll)
People still write java??
Re: (Score:2)
Java is the most used language on the planet.
And yes, in my current job I write Java, not Kotlin, not Groovy, not Scala.
Re: (Score:2)
Part of my day job is working on a java and C# interface that wraps multiple other tools that do similar things (basically a big interface that knows the tools and uses a common language). The scripting language people that use the tool work in is java or C# (and that is actually handled by some code that uses the interface library).
Honestly, it really, it doesn't matter, I could even add, say lua bindings if I felt like it - just something that calls the APIs in the DLL or jar file. I just threw lua out th
Re: (Score:2)
Perhaps your circle of influence has changed, still gets plenty used in games I play / mod, never been a fan personally, seems like a bastard child, but I still see it in use all over the place.
Re: (Score:2)
Multi-Language Developers aren't really doing Serious Stuff.
Re: (Score:2, Funny)
Re: (Score:2)
Re: (Score:2)
This prevents "frist post" garbage.
Named after Republican Bill Frist, former U.S.Senate Majority Leader?
Re: (Score:2)
C++14 actually does complete C++11, and compilers were quick to adopt it, too. C++17 is a bit of a different animal in the sense that it changes abi. Worst still, in that sense, C++20 also has structural and abi changes, including of course modules.
I tend to feel most enterprise work will continue to use C++11/14 given long product lifecycles, and eventually will migrate to C++20 and later, but C++17 may well become a kind of orphan.
Re: (Score:2)
Like what?
Re: (Score:2)
Re: (Score:2)
Actually, this is precisely what Mozilla has been doing with firefox development, converting parts of it to Rust. But I guess it is over oxidized ;).