C++ is About To Get a Huge Update (zdnet.com) 217
ZDNet reports:
The International Organization for Standardization's (ISO) C++ group, Working Group 21 (WG21), has agreed upon the finalized version of 'C++20', the first major update to the 35 year-old programming language since C++17 from 2017... The 2020 release of C++ is huge by historical standards. Herb Sutter, a Microsoft engineer and long-time chair of WG21 C++ ISO committee, said it "will be C++'s largest release since C++11", meaning it's bigger than any of the past three releases, which happen every three years. It's also the first version that has been standardized....
Two of the most important features coming to C++20 are "modules" and "coroutines". Modules, which was led by Google's Richard Smith, stands in for header files and helps isolate the effects of macros while supporting larger builds. As Sutter noted recently, C++20 marks the "first time in about 35 years that C++ has added a new feature where users can define a named encapsulation boundary...."
Coroutines represents a generalization of a function. "Regular functions always start at the beginning and exit at the end, whereas coroutines can also suspend the execution to be resumed later at the point where they were left off," C++ contributors explain in a proposal for coroutines.
"We expect it to be formally published toward the end of 2020," Sutter said said in an announcement.
Interestingly, the year C++ was first released in 1985, Microsoft used it to build Windows 1.0, ZDNet points out. "These days Microsoft is exploring Mozilla-developed Rust to replace legacy Windows code written in C and C++ because of Rust's memory safety qualities."
Two of the most important features coming to C++20 are "modules" and "coroutines". Modules, which was led by Google's Richard Smith, stands in for header files and helps isolate the effects of macros while supporting larger builds. As Sutter noted recently, C++20 marks the "first time in about 35 years that C++ has added a new feature where users can define a named encapsulation boundary...."
Coroutines represents a generalization of a function. "Regular functions always start at the beginning and exit at the end, whereas coroutines can also suspend the execution to be resumed later at the point where they were left off," C++ contributors explain in a proposal for coroutines.
"We expect it to be formally published toward the end of 2020," Sutter said said in an announcement.
Interestingly, the year C++ was first released in 1985, Microsoft used it to build Windows 1.0, ZDNet points out. "These days Microsoft is exploring Mozilla-developed Rust to replace legacy Windows code written in C and C++ because of Rust's memory safety qualities."
So the complex mess gets even more complex? (Score:5, Insightful)
I moved back to C a long time ago. C++ is just not worth it. Its OO implementation sucks badly. Its other features are minor conveniences. The whole thing is an exercise in remembering exception from the rules.
Re: (Score:2, Interesting)
Really? You couldn't even see any value in std::string and std::vector?
Maybe you should move back to assembly language, for the same reasons.
Re:So the complex mess gets even more complex? (Score:5, Informative)
Not really. The price they come at is far too high. It would have better to do that in C.
Oh, wait, some people did: https://www.gnu.org/software/l... [gnu.org]
C++ poor manuals? (Score:4, Informative)
It there any truth in that? My understanding is that people try features that should be used only in rare circumstances, and get poor results.
Re:C++ poor manuals? (Score:4, Informative)
Possibly. I read the book by Stoustrup (sp?) and it was certainly badly written. Probably set the standard.
Re: (Score:2)
My understanding is that people try features that should be used only in rare circumstances,
There is no general agreement on which set of features should be used, and which should not. When you have a team, you start by setting out some general coding standards of which features to use, how to handle errors, etc; but you still have to use libraries that have different coding standards.
Also, every feature was considered a great thing when it was introduced. Watch, people are going to write a ton of code using co-routines, then in a decade everyone will complain about how they shouldn't be used.
Re: (Score:3)
> people try features that should be used only in rare circumstances, and get poor results.
That probably goes for C++ as a whole.
Re: So the complex mess gets even more complex? (Score:2)
What price is that?
Re: (Score:3)
the way c++ has become, it might just be preferable to write asm.
Re: (Score:3)
Naa, don't throw out the child with the bathwater. C is a perfectly serviceable fine language for the competent. I hear you can write large application and even complete OS kernels in it that do not suck.
Reading the Intel CPU manual right now (Score:3, Interesting)
> Maybe you should move back to assembly language, for the same reasons.
I'm reading Intel's processor manual right now. The official documentation of the instruction set, registers, protection rings and all that. It's quite obvious that the CPU and instruction set are designed for C programming. Assembly is course pretty much what the CPU does internally, and it's clear that the assembly instructions were designed with C in mind as the processor's interface to programmers.
Re:Reading the Intel CPU manual right now (Score:4, Insightful)
It's nowhere near "what the CPU does internally". Once you get the decoding of the assembly-level instructions into micro-operations, micro-register assignment, micro-operation reordering to obtain an efficient scheduling, and God knows what in the actual execution phase, it's lucky that what you see in memory at the end of the run still aligns with your conception. You talk as if you can still derive some idea of program efficiency by looking at the C-level code (other than for the grossest "Don't use an N^2 algorithm when an NlogN one will do, m'kay?" sort of evaluation).
Re: (Score:3)
The microcode and how it interacts with physical gates is, of course, an entirely different animal. One that can and does change with different Intel and AMD processors.
Re: (Score:3)
C: 1972. Intel 8086: 1979 (Score:3)
x86 came out 7 years after C did. So C could not have been designed with x86 instructions in mind.
Re: (Score:2)
No. The first thing I did when I learned C++ 20 years ago was write my own container templates. They fit in a 2000-line header file. They still work just fine today, and best of all, I don't have to wonder why my code is running two or three big-O orders slower than I thought it would.
Re: So the complex mess gets even more complex? (Score:4, Insightful)
As long as you can guarantee no side effects, along with verifiable pre-conditions and post-conditions, the internals should never matter. They should always be invisible.
The problem is, a lot of programmers break the no side effects rule. If they kept it, you can program as if everything was a black box.
You could even replace one black box with another that had similar enough conditions, without changing how anything worked.
Re: (Score:3)
Really? You couldn't even see any value in std::string
std::string is trash, and you're better off writing your own string library.
Re: (Score:2)
I find that I often implement an object system in C, but it is always pretty lightweight, and I never really want very many features. C++ wants to have a full featured object environment, but that doesn't really fit with the modern use cases for these languages.
But seriously, who is going to even consider C++2020 I mean, come on. I'll wait for C++666 or something.
Re: (Score:3)
I completely agree. I learned to do OO in C when writing Python modules in C. I agree on the limitations of the C++ model, and the Python model (i.e. let the designer decide whether, for example, a child conforms to the parent or the other way round or not at all and _that_ gives you re-use) is the modern model. You can even have it with static type safety, as Eiffel demonstrate. Of course, this requires people that really know what they are doing, but that is true for all of OO. It is just not that obvious
Re: (Score:2)
I find that I often implement an object system in C, but it is always pretty lightweight, and I never really want very many features.
Structs with data-initializers ("constructors") and the odd function inside them is a very useful thing, it can avoid a lot of mistakes and code verbosity.
C++ even allows you to initialize members at declaration time:
struct foo {
int n = 0;
double pi = 3.142;
};
Why would anybody not want that? (shrug)
Re: (Score:2)
Structs with data-initializers ("constructors") and the odd function inside them is a very useful thing, it can avoid a lot of mistakes and code verbosity.
1) It creates mistakes too. Nobody has ever proven this sort of language feature reduces bugs, instead it just changes the type of bugs. Which type of bug is more appropriate for the type of software where a C-type language is a good choice? I'm going to say that your automated mistakes are much worse in this domain, and the mistakes you're trying to avoid are the sort of mistakes that a C or C++ programmer will always have to protect against. The person who needs that protection should be using a higher le
Re: (Score:2, Insightful)
Re: (Score:2, Insightful)
If you are not using STL container classes, you are wasting your time rewriting your containers again and again. Or you are working in some sort of dead moribund code. I would not hire anyone who can not use STL effectively.
Talk about being ignorant. And who says I have to write my own containers more than once, if I chose to do that?
Re: (Score:3, Insightful)
just what the world needs. Yet another incomplete, buggy and informally specified reimplementation of half of the STL.
I've never personally encountered a bug in any of the major STL implementations. Do you know how many bugs I've encountered without looking in various "better" containers?
99.9% of the time, reimplementation of containers and algorithms has no benefit yet increases the maintenance burden plus adds impedance in the code between different bits using different containers. It's just wankery.
Re: (Score:3)
Now, just two compilers, Microsoft Visual Studio and gcc. Almost all use cases of our beloved klib was gone. Last holdout was our simple_hash class. But with unordered_set, map
Re: (Score:2)
Re: (Score:2)
Yeah I mean C++ isn't prefect and in the past QOI left something to be desired, hell in '98 many compilers firms have member templates which nixed any decent STL support. I was an intern then and smug about C being superior (and I didn't really understand C++). By the time I started using it professionally and liking it, or had got a lot better, and I was probably lucky not finding bugs in the early 2000s.
These days though yeah it's solid.
Re: (Score:2)
Do not assume that if I do this, it is on the skill level you are capable of.
You have my absolute assurance tthat I at no point ever assumed you would do it on the skill level I am capable of.
Also, why would I reimplement STL? In addition to their implementations, their interfaces suck too.
Gosh, so not only will it be a maintenance burden, buggy and poorly specified, but it will also be hard to interoperate with. You're doing a fine job of feeling selling it!
Re: (Score:2)
Do not assume that if I do this, it is on the skill level you are capable of.
Its good to know there are people as arrogant as I am, thank you gweihir.
Powerful tools have complex interfaces and training and dedication to use. STL interfaces are complex because they are extremely powerful. They slice and dice all the pieces of containers, for example, and allow you to replace any module you want with your code, while providing a well tested implementation for each piece. Like comparisons, memory allocations, etc.
If your code does not need complex containers, may be what it does i
Re: (Score:2)
Talk about being ignorant. And who says I have to write my own containers more than once, if I chose to do that?
Yep. it cal all be done far more elegantly by the C preprocessor using #define.
(barf)
Re: (Score:2)
Talk about being ignorant. And who says I have to write my own containers more than once, if I chose to do that?
Feel free to educate us all on the correct way to do it...
(please!)
Re: (Score:3)
In other words: You can't.
Yeah, C++ never quite fit any project for me (Score:3)
Same here.
Of course, different languages fit besr for different projects.
Most obviously, SQL isn't better or worse than PHP, they are each well fit to their different purposes. Same with C and Python, for example - some projects, C makes sense, some projects Python makes sense. C where you have reason to have fine-grained control or where top performance is paramount, Python where you just want to get it done in a hurry or are dealing with large integers and you aren't worried about bugs.
For me, I've yet t
Re:Yeah, C++ never quite fit any project for me (Score:5, Informative)
C++'s primary use case is when you have three requirements: top performance, decent abstractions, and broad ecosystem support.
I work in game development, where C++ dominates the landscape. Top performance is a must, of course. C++ does a pretty good job of allowing us to create high-level, zero-cost abstractions that make complex code easier to work with, without imposing significant performance penalties. And of course, the ecosystem for game development assumes you'll be writing in C++, so this tends to be self-perpetuating. For example, the SDKs, libraries, frameworks, tools, and engines you need are likely written C or C++, including on closed, proprietary systems like consoles. Choosing another language creates a huge amount of friction on these platforms.
At this point, for new projects, without that ecosystem requirement hanging over you, it's a lot harder to make an argument that any arbitrary new project should be written in C++ purely on the merits of languages. C++ is a very old language with a LOT of cruft and warts. But hand-waving away the ecosystem argument is ignoring the reality that there's a staggering amount of existing C and C++ code out there, and by using C++, you have access to much of that wealth of code and libraries with relative ease.
Re: (Score:3)
People have been making the claim that it's theoretically possible for many years, but I have yet to see any evidence that it's happened, with a LOT of evidence pointing to the contrary result.
The tricky part of these sorts of comparisons is that it's fairly easy to write poorly performing C++ if you're not well versed in the language. On the other hand, experienced C++ programmers are very likely to be able to create a version of a program that runs faster than a managed language, because there are a lot
Re: (Score:2)
Lack of decent compilers as I've (fuck you IAR) I've never had a project where C is superior to C++ from a language perspective. You can write C like code but with better type safety, and a more same macro system.
And better libraries. Fixed point arithmetic in C++ is much nicer than in C.
The more things change... (Score:2)
The more "features" that get added to C++, the more closely it starts to resemble APL. And that's not necessarily a good thing.
Re:The more things change... (Score:5, Informative)
Anecdote: I used C++ lambdas last month for the first time. I was working on some code that really really needed them. The code would have been huge/repetitive without them.
Don't ever dismiss a feature as "not needed" because you really never know...
Re: (Score:2)
Re: (Score:3)
Anecdote: I used C++ lambdas last month for the first time. I was working on some code that really really needed them. The code would have been huge/repetitive without them.
Using lambdas is throwing away opportunities for reducing repetition in exchange for not straining yourself.
Don't ever dismiss a feature as "not needed" because you really never know...
Mere dismissal is too kind for "features" which enable people to go down rabbit holes they otherwise would have been avoided entirely.
Re: (Score:2)
I still rarely use lambdas if I can help it. When they are required, I feel I have to document the hell out of them because trying to figure out what they are doing in a debugger is impossible. Case in point, working on a java project where there were 15 nested lambdas and one of them was throwing a NPE (null pointer exception) and zero documentation because the manager wanted function names to be self documenting (which doesn't happen with lambdas, and is a terrible practice, but this manager wasn't compet
Re: (Score:2)
Re: (Score:2)
Are you kidding?
Just read this thread to see how much resistance there still is to adding new features to C.
Re: (Score:2)
Why weren't they there from the beginning instead of lot of the other nonsense?
Probably because of the annoying restrictions and dangers that come with using lambdas that only have stack-based allocation and RAII (as opposed to generalized closures that have garbage-collected state). Nobody would have imagined that they would really be worth implementing.
Re:The more things change... (Score:4, Informative)
Only if you aren't paying attention. Just about every new feature added in this update is making the language more powerful, safer, and more convenient to use.
Getting modules in the language, meaning we can finally get rid of those damned header files, is huge. There are other nice features as well, such as the new "spaceship operator" (simplifies writing comparison overloads for custom types), the inclusion of Python-like formatting library fmt into the standard library (as opposed to the non-typesafe printf family), and convenience functions for simplifying the erase-remove idiom, used for efficiently removing arbitrary items from the contiguous memory of a vector. And so on...
Every single one of those is currently a minor pain point in the language, so I've heard very few people who actually USE C++ in their daily work complaining about these improvements. Perhaps the one exception is from people who worry about the language evolving so fast, it's getting more difficult to stay current. A fair point, but C++ has such exceptional backwards compatibility that it lends itself towards learning to use these new features at your own pace.
Honestly, most of the bitching I hear on Slashdot seems to be from people who don't actually seem to use C++. That's fine - don't use it if it's not appropriate. No one is hawking C++ as a general-purpose language you should use for all the things. It's terrible in that role. It's a specialist language, made for some pretty specific roles. When you need a language that is incredibly fast, has good abstraction models, and maximum platform/deployment compatibility, C++ fits the bill. Languages like C, Rust, Go, Swift, etc have different strengths.
Re: (Score:2)
The more "features" that get added to C++, the more closely it starts to resemble APL.
No LOL. APL is an elegant language [zerobugsan...faster.net], there is no part of C++ that is elegant.
In fact, people who hate C++ hate it because of its lack of elegance.
Goodbye C++ (Score:5, Funny)
Welcome C+++
Re: (Score:2)
Surely you mean C+=2
Re: (Score:2)
I came here to say this, but I knew in my heart that it had already been said.
Why not C++ (Score:4, Interesting)
That has made it too clumsy for me to embrace in my line of work.
Re: (Score:2)
That's true, but it's also true of just about everything that's computer-related.
eg. Why is Excel such a behemoth? Same reason.
Why are web browsers such mastodons? Same reason.
That has made it too clumsy for me to embrace in my line of work.
You can't figure out which part you need...?
Re: (Score:2)
Re: (Score:2)
The real problem with C++ is that it's so configurable. It's like everyone's C++ code is actually in a different language, so if you want to modify, or even read it, you have to wade through their hundreds of pages long style guide. If they have one.
It's not necessarily limited to C++, but it does seem to be exacerbated. I've seen people do horrible things with macros in plain old C, including an engineering professor who actually taught a class that the first thing to do when you get a piece of code is to
Re: (Score:2)
The real problem with C++ is that it's so configurable. It's like everyone's C++ code is actually in a different language
That happens in any language.
There's an old saw about FORTRAN programmers being able to write FORTRAN in any language.
https://www.ee.ryerson.ca/~elf... [ryerson.ca]
Re: (Score:2)
Different language developers put different emphasis on the tradeoff between features and simplicity.
Re: (Score:2)
The real problem with C++ is that it's so configurable. It's like everyone's C++ code is actually in a different language, so if you want to modify, or even read it, you have to wade through their hundreds of pages long style guide. If they have one.
It's not necessarily limited to C++, but it does seem to be exacerbated. I've seen people do horrible things with macros in plain old C, including an engineering professor who actually taught a class that the first thing to do when you get a piece of code is to declare macros to correct all the capitalization and spelling mistakes.
Bah. Try Perl.
Re: (Score:2)
I have. Still recovering from the PTSD.
More Complex & Less Readable Code is a good th (Score:2)
If I didn't know any better, it seems to me that Working Group 21 is working at destroying C++.
I guess in some people's minds this will make things better but from what I can see, things will become more complex with:
- Global macros that may or may not be available in different parts of the code depending on which Modules they're used in
- Functions which can stop and restart/is this to avoid understanding pre-emption in a multi-tasking OS
Maybe the changes are to support very large (operating system/browser)
Re: (Score:3)
Question: Will the new feratures be as bad as the hacks/workarounds that people have been using before this version of C++ allowed them to do it properly?
I doubt it.
Re: (Score:3)
The FEM simulation software we sell has four top level parts. The Field Solver solves a finite element formulation. The mesh generation/pre processing forms the other top unit. Solution post processing is the third part. The Executive that manages it all forms the fourth unit. You can imagine them to be sort of Army Group level of organization.
The executive has humongou
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Global macros that may or may not be available in different parts of the code depending on which Modules they're used in
If something is not available everywhere, how exactly is it "global"?
Functions which can stop and restart/is this to avoid understanding pre-emption in a multi-tasking OS
What does advanced control flow have to do with multitasking OSes?
Re: (Score:2)
That was a bad description of co-routines. The Python generator is a better fit for what they're talking about.
The idea is that a function can yield a result (rather than return) in the middle. When the calling function invokes a next method to iterate over the returned values, the called function resumes from after the yield to generate the next value.
The most similar alternative would be to use the called function as the target of a new thread and have it pass results through a queue with appropriate thre
Re: More Complex & Less Readable Code is a goo (Score:2)
> programmers who pride themselves on using every feature of a language
You mean: bad programmers?
Re: (Score:2)
I'd consider them bad programmers, but they're out there and they think they're smarter than anybody else.
They usually generate more bug reports and they feel it's a quantifiable way of demonstrating their superiority.
First? (Score:4, Insightful)
> the first major update to the 35 year-old programming language since C++17 from 2017
So, first major update since 2017? Good job making those 3 years sound dramatic. Why the heck does it even reference the age of the programming language?
Time for RISC Equivalent Programming Language? (Score:3)
With an Evangelist/leader who is a Fascist defined as: "a form of far-right, authoritarian characterized by dictatorial power, forcible suppression of opposition, as well as strong regimentation of adherents."
I feel like languages today are subject to the whims of Working/User Groups that end up kowtowing to the loudest voice and their special interests that don't see things in a totality. Have a simple language and keep it simple.
The leader should be somebody who uses RMS as an example of what NOT to be.
Re: (Score:2)
"Whoever does not understand LISP, is doomed to reinvent it."
Re: (Score:2)
LOL. Thank you.
Re: (Score:2)
Against popular believe: I never reinvented LISP :P
This is exactly why Google invented Golang (Score:5, Interesting)
Thanks for reminding me precisely why I program in Python and Go instead of this bullshit.
'Back around September 2007, I was doing some minor but central work on an enormous Google C++ program, one you've all interacted with, and my compilations were taking about 45 minutes on our huge distributed compile cluster. An announcement came around that there was going to be a talk presented by a couple of Google employees serving on the C++ standards committee. They were going to tell us what was coming in C++0x, as it was called at the time. (It's now known as C++11).
In the span of an hour at that talk we heard about something like 35 new features that were being planned. In fact there were many more, but only 35 were described in the talk. Some of the features were minor, of course, but the ones in the talk were at least significant enough to call out. Some were very subtle and hard to understand, like rvalue references, while others are especially C++-like, such as variadic templates, and some others are just crazy, like user-defined literals.
At this point I asked myself a question: Did the C++ committee really believe that was wrong with C++ was that it didn't have enough features? Surely, in a variant of Ron Hardin's joke, it would be a greater achievement to simplify the language rather than to add to it. Of course, that's ridiculous, but keep the idea in mind[...]'
https://commandcenter.blogspot... [blogspot.com]
Re:This is exactly why Google invented Golang (Score:4, Insightful)
Surely, in a variant of Ron Hardin's joke, it would be a greater achievement to simplify the language rather than to add to it.
This will simply coding for some people. Not necessarily you or me, but somebody out there really, really needs these features.
(they wouldn't have been added otherwise - the C++ committee requires very high levels of proof before a new feature is added, believe it or not).
Re: (Score:2)
^simply^simplify, glubdammit.
Re: (Score:2)
Thanks for reminding me precisely why I program in Python and Go instead of this bullshit.
Because Python has never had versions? Or even a version that knowingly broke backwards compatibility with previous versions?
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:3)
It's not the versions, it's the piling on of features. Features are nice to have, but the more you've got the more you can use, and the more everyone trying to read your code need to know.
I don't think Python is immune to this. Lately they've been adding some pretty arcane stuff, along with arcane symbols to support it.
Re: (Score:2)
It's not the versions, it's the piling on of features.
I think the "piling on" is an exaggeration by the writer of this article.
It's quite a small number if you look at it in context.
Re: (Score:2)
Simple languages are great for very simple things. I'll use small C for embedded, as I don't use most of the regular C libraries.
C for a more fully featured coding environment.
C++ if I really want something to be shared well between people and larger projects.
Python is great for lots of things, but there are times I prefer the compiled languages (i.e. when I have to distribute packaged executables).
R is great for others. Go and Rust have their places, as does Java, C#, Perl and so on.
The problem with Simp
Re: (Score:2)
C++ actually contains C as well. You can use the same compiler for all you usage cases. :-)
(and don't forget that all those tiny little Arduinos are being programmed in C++)
Re: (Score:2)
I was thinking real small C, that omit a huge amount of things the regular compilers expect. Yeah, I've heard that the Arduinos use C++, and gave a little cheer for that. :)
Re: (Score:3)
"Having a feature available, but not used (and certainly not being added to the executable if it's not used) isn't, to me, a problem. It's simply there if you need it. Over time, you'll get more familiar and at home with a language/environment and get to know more on when and where to use the subtleties."
That's an attitude that works fine when you're writing your own greenfield code. It's less fine when you're maintaining some else's code and you have to unravel all the clever features he used at the same
Re: (Score:3)
I found Python and Cython a good combination. When you need some performance you can write anything between regular Python, Python with hints, and pure C (or C++ if you desire), and it gets converted to C and compiled.
Re: (Score:3)
C++ has been corrupted (Score:2, Interesting)
I've been working with C++ for, oh, I don't know, maybe 30 years. C++ has gotten insanely complex. Some of the complexity has been fairly advanced, and actually very useful, in my opinion.
But C++ has now gotten to the point that it's become batshit crazy. A simple example would be the "coroutines" that have been mentioned in the article.
Co-routines are a mess. They accomplish absolutely nothing useful, whatsoever, that cannot be done with execution threads which have been standardized since C++11. The only
Re: (Score:2)
+1 Insightful.
Re: (Score:2)
Re: (Score:3)
coroutines are not for threading. They're for writing generators, or waiting for IO on a single thread, or anything else you want to use them for. Without needing to transform your procedural code into a buggy state machine yourself.
C++ is about to get a small update (Score:2)
Since when has anyone cared about coroutines? We've had libraries to do these things for decades and they are seldom used. Keeping a bazillion stacks in memory limits the usefulness of this scheme vs. other async methods.
Modules vs. header files is mostly a nonissue only pedants care about.
Calling this a huge update by highlighting two mostly useless features makes no sense.
Re: (Score:3)
Since when has anyone cared about coroutines?
Since about the time Microsoft added them to C#.
Re: (Score:2)
Keeping a bazillion stacks in memory limits the usefulness of this scheme vs. other async methods.
It's one of the reasons why garbage collection is so complicated in Go. While goroutines lack the same capabilities as full coroutines, the compiler and runtime underneath it has to solve some of the same implementation difficulties.
Once you add modules and coroutines to C++. Add in a package system and you have a viable competitor to Go that overlaps its features completely. Makes some sense from a marketing standpoint, we don't want C++ compiler writers escaping from their ivory towers and into the real w
Coroutines and modules ?!? (Score:3)
Re: Coroutines and modules ?!? (Score:3)
Modula-2 was better than the current C++ spec. Modula-2 could fit in less space than the current C++ spec.
Current versions of Ada and SPARK (a safety critical subset of Ada) are bulky but at least the code is readable and maintainable.
Reference compiler? (Score:2)
Is there a reference compiler that 100% conforms to the standard? Any standard?
Adding features to the language is meaningless without a compiler that supports them correctly.
Re: (Score:2)
I recommend the process be that you define what you want to do in a specification, and have all parties agree to it, before you implement and publicly release it. A proof-of-concept is of course an important part of that process, but that doesn't necessarily mean it should be production ready or should it fall into the hands of the public.
Get your wallet ready, your favorite vendors will have new tools for you to buy this Christmas.
We are now C+++PLUSPLUS! (Score:2)
We are an inescapable tool that you hate worse than the thought of having your manhood chopped off with a butter knife!
Annoying evolution of C++ (Score:5, Interesting)
As a computational biologist, I'm admittedly a pseudo-programmer. The type of work I do is much different than that of a professional software developer, and necessarily I write in a hodgepodge of different languages and for different platforms. C++, more than any other, is the one that feels that when you go away from it a bit and then come back to it it's changed enough that you've really got to relearn not just a handful a standard library changes, but very low-level changes that are thrown in. From my perspective, the changes cause more problems than they are worth most of the time.
Re: Annoying evolution of C++ (Score:4, Funny)
C++ has an unusually high mutation rate, is subject to horizontal transfer and has more junk DNA than a fungus.
These don't make it bad, just difficult to maintain.
code in C++:ca2000 != C++:ca2020 (Score:2)
I have been using C++ for 20+ years. Mostly in high-end (read: big) embedded environments. If you compare the code written in the end of 1990s to the code written today, it has very little semantic resemblance. Yes, the basic syntactic tone is there but the constructs are totally different. It is not the same language anymore, mostly due to subtle C++ changes that enabled radical change in the std libraries.
I also observe that complexity growth leaves weaker programmes behind in the dust. C++ become an expe
Unbelievable (Score:5, Funny)
C++20 marks the "first time in about 35 years that C++ has added a new feature where users can define a named encapsulation boundary...."
It's an unforgivable outrage to me that we had to wait so long for this feature, whatever the hell it is.