C++ is broken

47

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

So, I'm not really sure I understand your point, or what you think should be improved.

Can you give me a TL;DR/bullet points on what you think?

4

u/mintyc Jul 21 '19

Mixed language development may well be the answer where C++ is complemented by C# ecosystem, python etc.
I want high performance in parts so want to follow a lot of what's good about C++ (or Rust etc. as systems languages)
I want C++ to allow the choice.
Concrete example:
I look at Herb Sutter's proposal for a meta language description to enable ecosystem libraries to integrate with the core.
Personally I would ditch at least 50% of what is currently ongoing. (Too late for C++ 20)
I would move heaven and earth to get that capability fast tracked as soon as possible. As is, it'll canter along and perhaps be fully released in C++ 26 and gain traction and experienced best practice/ be tweaked in C++30.

5

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

I want C++ to allow the choice.
Personally I would ditch at least 50% of what is currently ongoing. (Too late for C++ 20)
Everyone has different priorities. If you want C++ to have choice, that means we will spend time working on things that not everyone may think is important.

2

u/mintyc Jul 21 '19

Indeed everyone does have different features they deem important.
My criteria for work by standards would be at least one of
Cannot be implemented as an external library
'Needs' language/keyword support for a consistent, usable interface
Provides a framework or ABI to align code generation tooling (compiler etc.)
More importantly, criteria that don't of themselves warrant inclusion in the standard
Needs the insight of the experts within the standards committee
Needs to be a std:: feature to ensure everyone uses it (std lib vendors need to deliver it)
Used as the basis for other libraries
Provides a widespread feature e.g. unicode, formatting, file system i/o
Note that goalposts do move as more and more functionality can be implemented as external libraries.

3

u/NotMyRealNameObv Jul 21 '19

Cannot be implemented as an external library
Are you saying almost nothing in the standard library belongs in the standard?

1

u/mintyc Jul 21 '19

At the time they were developed it was the right thing to do for a lot of the libraries, but I wouldn't be in favour of, for instance, a decimal value or currency class. If <complex> didn't exist, I'd probably sit on the fence :)
Filesystem, regex, many others - omain advantage for being standardised is the std lib is probably available everywhere.
Well, imagine if you could get that sort of advantage as an external library but allow it to evolve, not require the standard development process (e.g. extensibility hooks, measured progress) and may be get to the 90% functionality point in 3 months.
Its a mindset change for libraries development; NOT giving up on it. If anything, trying to release creativity without consuming vast parts of the standards time.
For instance maybe an opinionated solution may be a good library to start with. e.g a filesystem using utf8 using 'bytes' exclusively (too scared to say char).
Libraries can be developed on their own timescales, can deliver partial implementations, can have versions that don't have such a high bar on backward compatibility. Just like real life.
Something like ranges would be a difficult one. I'd probably say external (but from a position of ignorance, and admiration of what it achieves)
At this point in C++'s life, adding more basics in std might NOT be the right thing.

0

u/[deleted] Jul 21 '19

[deleted]

1

u/mintyc Jul 21 '19

Note I'm making this suggestion for C++ as it currently is. <random> has your back already.
I'm NOT suggesting this strategy for a new language.

2

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

RemindMe! 3 days
(To post my "what belongs in the standard library" slides).

1

u/RemindMeBot Jul 21 '19

I will be messaging you on 2019-07-24 12:28:37 UTC to remind you of this link
CLICK THIS LINK to send a PM to also be reminded and to reduce spam.
^{Parent commenter can} ^{delete this message to hide from others.}
^Info ^Custom ^{Your Reminders} ^Feedback

1

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 24 '19

The official criterion that the Library Evolution Incubator uses can be found here.

0

u/[deleted] Jul 21 '19

[deleted]

1

u/mintyc Jul 22 '19

Thats one of the many rambling points I made.
I've been waiting on the committee to deliver networking while using ASIO.
I've now realised that committee probably shouldn't be tackling networking directly as it doesn't have the resources and maybe applies a level of rigour not required (extensibility hooks, not paying for not used, strict(ish) backwards compatibility.
Instead I've suggested that the committee does help and encourage a repository of excellence, along the lines of boost but with less baggage and support for more modular inclusions. Essentially mimicing what the std lib vendors would do nowadays.

3

u/jwakely libstdc++ tamer, LWG chair Jul 23 '19

I don't understand why people keep suggesting that the C++ committee should come down from the mountain with two stone tablets, describing a package manager and a code repository. That's batshit. Why do you think a hugely varied group with specialists in fields including programming language design, compiler front-end implementation, compiler back-end optimisation, numerical computing etc. are the right people to do that?
Every time this dumb idea is suggested I think that somebody should just go and build the damn thing, and if it's good people will use it. "If you build it, they will come". Asking for a top-down, design-by-committee solution for this problem is silly. You'd get something horrific like Clearcase.
Relevant: https://twitter.com/TartanLlama/status/1137254531291594752
If the existing solutions don't meet all your needs, get involved and improve them! The alternative is to start again from scratch and get something inferior that still doesn't meet your needs. Insisting that the C++ committee should just solve the problem, as though just telling them to do that will make it a success, is hopelessly optimistic and naive.

9

u/smdowney WG21, Text/Unicode SG, optional<T&> Jul 21 '19

Everything new in the standard is there because someone thought it important enough to do a lot of hard and time consuming work. It's an almost entirely individual and volunteer effort, even for those people who are supported by their company.
Ideas that "The Committee" should focus on X, and then X would happen faster, misunderstand how the project works. The committee doesn't direct efforts, although the committee has recently started identified areas they would like to see work done. The committee basically invites people to do work, by submitting papers, and discussing them.
And, at least in my opinion, the things that were pushed to 23+, like Contracts, Executors, and Networking, did not suffer from a lack of people working on them, or a lack of attention by the committee. They are difficult technical topics that will involve tradeoffs in design and implementation, and it simply takes time to get that to a local optimum. Particularly where we would like the library and language to maintain coherency, so considerations about how each change affects the whole, and how each piece should use the rest, takes time.

2

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

Very well said!

1

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

I look at Herb Sutter's proposal for a meta language description to enable ecosystem libraries to integrate with the core.
Which proposal do you mean?

4

u/mintyc Jul 21 '19

https://wg21.link/p0707

1

u/mintyc Jul 21 '19

I'm suggesting the (excellent) committee isn't achieving the big picture goals for C++.
I think it has spectacularly failed to give the wider productive tool BUT perhaps that is the fault of the ambitions.
It is excellent at providing those carefully considered 'dont pay' and extensible building blocks.
But applying those same principles to say networking has not been a success.
The standards part needs to reduce what it takes on but in parallel encourage the wider community to created 'boosted' (non) standard, perhaps opinionated solutions.
So my 10 years frustration that say ASIO hasn't been standardised has changed to realise it shouldn't be in the standards. It just distracts.
There are a lot of other working groups on specific items that fall into the same category.
Standards purpose needs to do less and focus just on what it's very good at.

6

u/[deleted] Jul 21 '19 edited Jul 21 '19

It is excellent at providing those carefully considered 'dont pay' and extensible building blocks.
Right. We can agree on this one and that's what I love about C++.
But applying those same principles to say networking has not been a success.
I personally couldn't care less about std::network getting in. There's Boost.ASIO and the standalone version, people can use that. With the help of bcp bundling just the necessary parts of Boost is easy. Not everything needs to be in the standard library and, perhaps more importantly, the standard library isn't, or at least shouldn't be, a mean to distribute a library to one's users.
The standards part needs to reduce what it takes on
I do tend to agree. I don't see any point in std::web_view and from here it looks like it will take a ton of time that could be better spent on something else.
but in parallel encourage the wider community to created 'boosted' (non) standard, perhaps opinionated solutions.
We have Boost, Abseil and GSL. I haven't used GSL, but I've used the other two. IMHO* is great and would have the same opinion of Boost if it were "rebased" onto C++11.
So my 10 years frustration that say ASIO hasn't been standardised has changed to realise it shouldn't be in the standards. It just distracts.
Again, we can agree on this, but for this to work the way I think you're imagining, we need wide adoption of modules. If the reported benefits end up in the same ballpark (for a pretty liberal definition of "ballpark") I believe we'll see pretty fast adoption of modules.**
There are a lot of other working groups on specific items that fall into the same category.
Maybe domain experts need to figure out how to gather around and discuss moving C++ forward in their domain outside of the C++ standardization process, but that is a wild dream. Why? Just try justifying that to your employer.
Employee: Hey, I'm going on a trip and the company should cover my expenses, like in the previous year.
Employer: C++ standard meeting again?
Employee: Something like that, yeah...
Employer: "Something like that"?
Employee: Well, this time we decided to separate from the standard. It's just me and a few guys going to Kona for a week. The actual committee meeting is in two weeks and I also have a paper I should champion there.
Standards purpose needs to do less and focus just on what it's very good at.
Good luck getting people to agree what parts should be dropped, potentially after years of work. A simple example: I don't care about ASIO getting into the standard, but would have loved it if P0593 got into C++20. At the same time I'm sure there are people who don't give a rat's ass if P0593 ever gets adopted, but want Networking TS adopted yesteryear.

* "IMHO" sometimes read as "In My Horrible Opinion".
** If the compile time drops by 50% (and claims were made that much larger improvements are possible), suddenly selling a) move to C++20, b) large refactoring effort and c) switch to modules to your CTO becomes plausable. "If you let us do this for a while, the distributed system used to compile this beast would need only 50% of the power, saving you potentially a lot of money every month in electricity."

3

u/[deleted] Jul 21 '19

Maybe domain experts need to figure out how to gather around and discuss moving C++ forward in their domain outside of the C++ standardization process, but that is a wild dream. Why? Just try justifying that to your employer.
Maybe we should move on from the idea that you need to physically be in a certain place to communicate with others.

1

u/mintyc Jul 21 '19

All forms of communication have their place and it looks like C++ WGs encourage use of most.
I'm involved in standardisation processes for mobile network technologies. They might coordinate 20+ working groups for a release with some WGs similar in size to the whole of C++.
They deliver a release quickly and reliably every 18 months or so across these WGs.
Some considerations I've seen work well
Overlap requirements, architecture and implementation work (stage 1/2/3) so a group may be working on three releases at a time.
In C++, requirements seem to pop up and vie for attention throughout the first 2 years of a 3 year cycle. Managing them via the three stage approach with say a year per stage on average, gives a bit more focus and smaller releases. A release a year? Still a 3 year release lifecycle
There might be advantages in not actually doing working group work itself at the plenary.
Encouraging separate working group meetings whether face to face, virtual conferencing, short calls, emails etc. The point is that each group can adapt a little more and not require the full complement of 200+ interested parties in the building.

1

u/jwakely libstdc++ tamer, LWG chair Jul 23 '19 edited Jul 23 '19

Encouraging separate working group meetings whether face to face, virtual conferencing, short calls, emails etc. The point is that each group can adapt a little more and not require the full complement of 200+ interested parties in the building.
That already happens for WG21. Just because there are face-to-face meetings as well, doesn't mean there isn't other work going on all year round.

1

u/[deleted] Jul 21 '19

You should hear what /u/blelbach has to say about that. For the record, I'm not against the idea, but there's two sides of every coin.

3

u/[deleted] Jul 21 '19

I dug up the comment I think you're referring to and I find it hard to agree with most of it. Your face is irrelevant to the ideas you have, and face-to-face conversation isn't inherently superior to internet communication in any way; that part reads like "we've always done it this way so this must be the right way" to me.
The part that I find somewhat valid is that the committee members get to take some time off to focus on C++. I guess that's good for those who can convince their employers to fund it, but I am unconvinced that it's a good enough reason to make it prohibitively expensive for everyone else. Why can't employers who are okay with this kind of thing just give those people extra PTO to be used for this?

3

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

face-to-face conversation isn't inherently superior to internet communication in any way;
I strongly disagree with this statement.
Firstly, I'm not claiming it's superior, it's just different.
Technical discourse at this level is inherently intense and emotional.
Would you break up with someone you are dating over email?
Making decisions on what to do with something that people have invested significant amount of energy into is best done in person.
Sometimes, we have an important member of the committee who cannot attend face to face meetings regularly. Despite efforts to use messengers/voice chat/video chat to keep them involved, the work always suffers when we don't have them in person.
Also, you missed one of my major arguments; the face to face meetings force us to focus on committee work for a full week, to the exclusion of all else. That is a huge benefit. We are all very busy in our day jobs.
That said, a lot of important committee work does happen online. It's not one or the other; we need both face to face and online.

2

u/[deleted] Jul 21 '19

Making decisions on what to do with something that people have invested significant amount of energy into is best done in person.
I'd argue the opposite, actually. Typing out an email (or any other form of non-real-time communication, like this reddit comment which I've edited in several places now for clarity and coherence) means you can carefully consider and edit what you're about to say before committing to it.
Sometimes, we have an important member of the committee who cannot attend face to face meetings regularly. Despite efforts to use messengers/voice chat/video chat to keep them involved, the work always suffers when we don't have them in person.
This is the same argument that companies use against remote workers. The rebuttal is the same here: yeah, if most of you are talking in person and then relaying it to that other person, you're going to have a bad time. If everyone is remote, you're all on equal footing, and the problem goes away.
Also, you missed one of my major arguments; the face to face meetings force us to focus on committee work for a full week, to the exclusion of all else. That is a huge benefit. We are all very busy in our day jobs.
I didn't miss it. I explicitly (partially) conceded that point in my comment.

4

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

I guess we just have a different perspective. I prefer to deal with people in person. I find face to face communication goes better.

1

u/jwakely libstdc++ tamer, LWG chair Jul 23 '19

Maybe we should move on from the idea that you need to physically be in a certain place to communicate with others.
As somebody who works remotely 100% of the time and collaborates with colleagues all over the world, I'm well aware that communication is possible without being physically in the same place. Possible doesn't mean optimal for all cases. More and more WG21 work is done remotely, but that doesn't mean the face-to-face meetings are redundant or a waste of time. The problems with the C++ ecosystem are not because WG21 meets face-to-face.
Maybe it's time we should move on from the idea that the C++ committee needs to solve all problems in C++, and create new, useful things in other communities. Boost did a great job of that at one time, but is collapsing under its own weight. There are too many stakeholders who want Boost to provide a pre-C++11 crutch for old code, so it's probably not going to move on. Something else can, and should, replace it for modern code. And third-party code repos and package managers should be able to thrive without help from WG21 too.
There might be significant overlap between the people active in WG21 and [INSERT OTHER THING HERE], but WG21 doesn't need to create or maintain [THING].

8

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

If the compile time drops by 50% (and claims were made that much larger improvements are possible), suddenly selling
2x to 3x compile time perf wins for switching to modules is what I'm hearing from the three major compiler vendors. During the SG15 last Friday, an LLVM implementor showed us a live demo of hello world (using <iostream>) compiled without modules against a build with implicit modules (e.g. no code changes, just include translation of <iostream>).
Building with modules was about 4x faster in the live demo (discounting the time it took to build the <iostream> module). I was impressed.

1

u/[deleted] Jul 21 '19

I've heard Bjarne mention that he heard even wilder stories, but I tried to be conservative with 2x speed up.

1

u/Auriculaire Jul 21 '19

The demonstration using iostreams represents close to the best case scenario for modules. Its written in an old-school style using next to no templating, which really does benefit a lot from modules.
However I suspect you may feel disappointed when applying modules to a codebases that spend a significant fraction of their (respective) total compilation times in template instantiation. I feel like a lot of the community has an expectation that modules will somehow cache template instantiations or something between compilations, but as it stands, that isn't the case. Projects leveraging boost, ranges-v3, or even HPX (given their starting to lean into concept emulation to support ranges) will likely see very little benefit.

1

u/jwakely libstdc++ tamer, LWG chair Jul 23 '19 edited Jul 23 '19

Its written in an old-school style using next to no templating
This would be the iostreams that are written as a class template like `basic_ostream` that uses a class template like `basic_streambuf` that uses class templates like `ctype` and `num_put` for every operation, right? ;-)

2

u/Auriculaire Jul 23 '19 edited Jul 23 '19

This would be the iostreams that are written as a class template like basic_ostream that uses a class template like basic_streambuf that uses class templates like ctype and num_put for every operation, right? ;-)
Yup.
You're right. I was imprecise. I was referring to the number of required template instantiations, but I think that was clear from the context.
The points of reference here are range-v3 and boost (namely metaprogramming, metaprogramming heavy, and constexpr heavy libraries such as hana, hof, spirit, and units for example). So yeah, by comparison iostream requires very little in terms of template instantiation. A given instantiation of basic_ostream has a handful of instantiations based on it's character type and few function templates to be stamped out based on the streambuf iterator and CharT* types.
This is 'next to nothing' relative to a typical workflow with the range library's views, which is now a part of the standard library and can be expected to see significant usage. Compounded with the ever expanding power of constexpr, I think it's to be expected to see more and more program logic pushed to the compile time. Modules don't help us here.
I guess my criticism is that modules are being presented as (or interpretted as) the solution to C++'s problematic compile times. At least as far as reddit and the C++ community on twitter (that I'm aware of), I'm seeing gains from modules being presented only for optimistic use cases which (I suspect) will become increasely less representative of real-world code as time goes on.

1

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

HPX has a lot of templates, but there's also a large shared library component. I expect some wins there.

14

u/JuanAG Jul 21 '19

Do you mind if i give my opinion?
In short, a smooth experience like the one you get with Python, Node or similar
No build system, make it a default one that hides all the complexity of the project but that allows some customization, Visual Studio ones is far from perfect but it would be a good starting point
A good package manager, including a third party lib is painfull and slow and chances of success are not 100%
A better and more complete STL with simplier sintax, list.find() or list.contains() instead of "std::list<int>::iterator findIter = std::find(ilist.begin(), ilist.end(), ObjectToFind);" which will require a post process in the findIter object, i know the C++ is more versatile but it makes harder and complex to use
That´s would be a nice starting point and if the ISO promises it will be coming to the language in recent years (26?) i will wait for it because i am at the point of switching, in the next months i am going to buy a good book about Rust and give a real try, if i like what i see i will make the switch, i was reading the reddit about it and there are jobs offer (here are too but in the sense that is not a toy, is a useful tool that companys are using) or the fact that they are working on an ultra fast compiler only for debuging make me smile like i havent since C++ 11 release, and it is only one feature

40

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

A good package manager, including a third party lib is painfull and slow and chances of success are not 100%
A single central package manager isn't the right solution for C++. We don't even have a single implementation (and that's a good thing). We couldn't make a global package manager that will work for everyone.
What we can and are doing is figuring out how to interact with many different package ecosystems, including existing ones. That's one of the reasons that my study group is writing a C++ Modules Ecosystem Technical Report.
Our goal shouldn't be to standardize a package manager. Our goal should be to make it significantly easier to use 3rd party libraries in C++. And we are working on that. C++20 modules will help with that by giving us a modern compilation model with proper encapsulation.

10

u/jpakkane Meson dev Jul 21 '19

Our goal should be to make it significantly easier to use 3rd party libraries in C++. And we are working on that.
This problem can be split into two pieces:
using dependencies that have been somehow prebuilt (if needed) and installed
using dependencies in a way that you build them at the same time as your code that uses it
There is a solution to the former, which is called pkg-config. Not only does it work, but it is already widely used. The whole of Linux userland development is built on pkg-config, including many C++ packages. Even Qt provides pkg-config files and it works really nicely. Pkg-config is not without its issues, sure, but the fact that almost all discussion about C++ dependency provider discussion an papers either don't mention Pkg-Config at all or just poh-pooh it away in a corner is not particularly nice.
The latter problem, on the other hand, is not really solvable. Having two different build systems working together in one build dir does not work and can't really work. A lot of people desperately want this to be possible, but it is not. I wrote a blog post about this ages ago. It talks about mixing Rust and C, but the core issue is the same.

10

u/templarvonmidgard Jul 21 '19 edited Jul 21 '19

pkg-config is great for system-level dependencies, but not so much for dependencies that you want to ship.
So, at work we maintain 2 legacy versions of our software in addition to current version and the to be released future version. We also use Qt, which you want to be in the prebuilt category, for the GUI of this software, with the following configurations:
Legacy 1: Qt 4.8, gcc 4.9
Legacy 2: Qt 5.5, gcc 4.9
Current version: Qt 5.5, clang >= 7, system stdlib
Development version: Qt 5.12, clang >= 7, libc++ >= 7
Oh, and these configurations must be built side-by-side on the same system.
AFAIK, pkg-config literally can't solve our problem, but I would be delighted if you could prove me wrong.
EDIT: also see P1313R0 - Let's Talk About Package Specification which discusses some of the issues.

4

u/jpakkane Meson dev Jul 21 '19

Well it depends on what you mean by "side-by-side". There are at least two different meanings for it:
all versions are installed in some common prefix (e.g. /usr, /usr/local, /opt/something etc)
each dependency type is installed in its own separate place (e.g. /opt/qt-55-clang etc)
In the former case it does not seem to be possible to have two versions of Qt since they install e.g. their headers to the same path so they would overwrite each other.
The latter case is fairly straightforward. Since all of the installations are in their own directories, choosing between them is a question of setting PKG_CONFIG_PATH and possibly LD_LIBRARY_PATH to suitable values before running configuration and possibly execution steps. This is a common development method and has been used in Linux development for close to 20 years.
This approach does have some boilerplate. There is a longer and better solution for this problem but you'll have to wait until CppCon when I'll have a presentation about it.

5

u/smdowney WG21, Text/Unicode SG, optional<T&> Jul 21 '19

It's been common in Unix for more like 40 years. But shadowing things in /usr/, /usr/local, ~/, plus /opt/package can be very complicated. You can't mix libraries compiled against different versions of dependencies in C++, or really C for that matter, although the conventions in C make it less of an issue. It's why so many projects "vendor" packages into the build rather than using system packages. It's not just not wanting to use the older system supplied version.

4

u/smdowney WG21, Text/Unicode SG, optional<T&> Jul 21 '19

pkg-config is designed to work within a consistent distribution of software. It's utterly insufficient for dealing with variant versions of "the same" library. It does a pretty good job for answering the question "What flags do I need to supply the compiler and linker to use this library the way it was compiled". For package management you also need to answer the question "How do I build this package", which is much more complicated. It's the difference between debian/control and debian/rules vs the .pc file produced as part of building the package.
Modules are going to make this even more complicated, as it's very likely a project will have to compile the module interface compatibly with the compiled library being consumed. (format editing)

2

u/templarvonmidgard Jul 21 '19

That is the exact point I wanted to make.

2

u/c0r3ntin Jul 21 '19 edited Jul 21 '19

Neither problem are solvable. 1 is an odr minefield. I fully agree with you on 2, there is a reason why dependency managers have a tendency to eat the world. You can't get far without a single source of truth.

5

u/jpakkane Meson dev Jul 21 '19

I am going to present a third solution in my CppCon talk. You'll just have to wait until then. :)

1

u/c0r3ntin Jul 21 '19

Looking forward to it ! I will also explore a few things in mine. Exciting times !

1

u/ed_209_ Jul 24 '19

The smart money is rarely on trying to solve everybodies problems all of the time.. Can you not attempt to standardise an abstraction instead. Look at game engines, they usually have 20+ third party libs. In some ways they constitute a static package manager of sorts but where the creator had sorted it all out.

9

u/tecnofauno Jul 21 '19

You don't need a single implementation to have a good standardized package manager. We need a standard dependencies format (e.g. Requirements.txt, project.json) and a standard CLI for the frontend. Then we can get as many implementors as we like.

8

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

We are moving in that direction, with the C++ Modules Ecosystem Technical Report, which will contain a number of different build interchange formats.

1

u/oldprogrammer Jul 21 '19

Something along the lines of how ibiblio repository is setup for Java Maven? Standard layout, common versioning semantics, metadata files with known names and structures.

2

u/c0r3ntin Jul 21 '19

You can have many tools under a single universe. Yarn is a reimplementation of npm but the package descriptions are identical and libfoo:1.42 is bitwise identical regardless of client use. Having a single source of truth is important. Multiple reimplementations are hard to deal with indeed. What does "c++20 standing lib" means?

1

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

Where do you see "c++20 standing lib"?

1

u/c0r3ntin Jul 21 '19

Oups, standard

1

u/JuanAG Jul 21 '19

Well, i dont want an explicit one, only something that make easy and quick to work with, if you can achieve this i am sure someone (even me) could develop a layer on top to make looks like a one command importing system as other does
I know that the main reason of modules it is to make that but i am not a believer, i want but i fear it will not be enough. I hope i am wrong and it is the tool we deserve

0

u/[deleted] Jul 21 '19

[deleted]

10

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

Here's hoping C++20 modules are a big help with that.
Modules alone won't. We need some coordination between tools, build systems, and compiler implementors. That's what SG15 is for, and why we are working on an auxiliary document (the C++ Modules Ecosystem Technical Report).

1

u/germandiago Jul 21 '19

This is going to be the most important effort from the usability point of view in the next years. Looking forward.

2

u/smdowney WG21, Text/Unicode SG, optional<T&> Jul 21 '19

They're going to be a help because they're going to force a lot of these issues to get addressed. Modules themselves are not at all a packaging solution, nor are they intended to be. Even distribution of compiled module artifacts has issues and controversy. Fortunately the stakeholders are working together in SG15.

23

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

No build system, make it a default one that hides all the complexity of the project
See, this is the problem with zero-config build systems; you can't just "hide" the complexity in the general purpose case. Can you make something that works for many simple use cases? Sure. But you can't make something that works that way for everyone's large scale C++ projects.
C++ targets a different later in the stack than Python or Node. You use it to solve different problems. You use C++ to build fundamental and system software layers. Sometimes, by nature, that is complex.

8

u/kalmoc Jul 21 '19

I don't think the main problem is that c++ is used for different kind of projects (although that is a problem). The main problem is that there hasn't been any standard build system, project layout, dependency management system, c++ featuresey or in general "standard way to do things" for the last 2-3 decades. But any modern solution (package management or build system) is expected to make interop with all the projects that have been developed in all that time to "just magically work".

7

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

There is no standard build system or project layout that will work for everyone.

8

u/kalmoc Jul 21 '19

I never said it would. But there is a difference between having a default that works for 90% of the projects and and special solutions for the remaining 10% and having a dozen different solutions that are each used by 20% of the projects (with each project supporting multiple ones). You wouldn't even need a single build system for the 90% just a standardized interface (e.g. description of how to compile it and how to use it).
But it really is a moot point: We live in the world we live in.

3

u/degski Jul 21 '19 edited Jul 21 '19

Iff there were to be a iso-std-layout, that would hugely improve the chances of coming up with [or converging to] a std-build-system and/or for existing tools to 'just magically' work [also] on that std-layout.

3

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

SG15 voted on this at this meeting. We had consensus against recommending a particular project layout.

6

u/degski Jul 21 '19 edited Jul 22 '19

Well, at least "we" made progress, "we" decided not to decide anything.
Could you please spell out the reasons for not even wanting to recommend some std-layout [nobody talks about imposing]?
The way I see it is that, once we define the 'ideal' target, all build-systems, the existing build-systems, could start to [try and] 'shoot at' something [as it will be no longer a moving and/or fuzzy target], we could make some progress. I appreciate it's not easy, but we could [I think] create some structure, that over time will work with any build-system [in my opinion it doesn't matter how good or bad it is, just something]. /u/vector_of_bool seemed to have made some progress with this and at least attempted something.

7

u/c0r3ntin Jul 21 '19

I think fundamentally C++ has a culture of people doing whatever they want and guidelines will go against that. It's also difficult to explain to people that guidelines for open source projects or new projects will not prevent people with existing codebases and build engineers from continuing to do what they have always done.

3

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

This is also fair and true.

2

u/degski Jul 22 '19

Unless you make it extremely easy to solve 'the' problem by just sticking to the rule[s]. People can obviously do what they want, how can it be hard to explain?

4

u/smdowney WG21, Text/Unicode SG, optional<T&> Jul 21 '19

I wasn't in the room, but have been working in SG15 for months. I kicked the tires and made a bunch of suggestions on /u/vector_of_bool 's pitchfork layout.
My feeling is that a lot of layout proposals work for "large" projects of dozens of files. I have medium sized projects at work with thousands of files, and it's not clear how you move from one to the other.
There's also cost borne by tool vendors to make it work transparently, which would be the point of specifying it, which would have to be in addition to the cost of a more general solution.
That all said, if we can get traction for a set of project conventions like layout, getting tool vendors to adopt it organically is more likely.
I personally think standardizing project descriptions in a way that makes integration and reuse easier will get us more bang. pkg-config only for build, not consume.

2

u/degski Jul 22 '19

That all said, if we can get traction for a set of project conventions like layout, getting tool vendors to adopt it organically is more likely.
This.
I personally think standardizing project descriptions in a way that makes integration and reuse easier will get us more bang. pkg-config only for build, not consume.
I think both should be pursued.

3

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

Could you please spell out the reasons for not even wanting to recommend some std-layout [nobody talks about imposing]?
I think the general feeling of the room is that anything we would recommend would be unlikely to work for some use cases, and might conflict/contradict the best practices for those outlying cases.
To paraphrase one participant, "I'm strongly opposed to this, not because I don't think it would be useful for a lot of people, but because my organization already has a proscribed project layout, and I'm almost certain whatever the C++ committee comes up with would contradict that."

2

u/konanTheBarbar Jul 22 '19

To paraphrase one participant, "I'm strongly opposed to this, not because I don't think it would be useful for a lot of people, but because my organization already has a proscribed project layout, and I'm almost certain whatever the C++ committee comes up with would contradict that."
I see that point, but I fail to see the problem when an existing system is not compatible with a certain default layout? I mean it's not like that would mean that all the other layouts would suddenly fail to compile... Are people afraid that they would not be able to use shiny new things? So rather not let have all the others have it?

1

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

Well, at least "we" made progress, "we" decided not to decide anything.
Incorrect, we have pretty clear guidance on what to pursue and what not to pursue. We are interested in implicit builds of modules, but not mechanisms that rely on a proscribed file name or file layout scheme. That leaves only one alternative; fast dependency scanners, a technology that we have already been working on and looks very promising.

1

u/degski Jul 22 '19

We are interested in implicit builds of modules ...
I see a parallel [but it's an ISO/vendor problem], but that's not what I [or others] was thinking of.

1

u/tcris Jul 23 '19

why?

1

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 23 '19

We don't think there's one answer that works for everyone.

1

u/tcris Jul 27 '19 edited Jul 27 '19

java has maven which uses a default layout in 99.99% of cases. They still support non-std layouts via parameters. Something similar can't be done for c++? (nothing ever fits everyone, that's sure and that's not the point)
Yes, I know it's not java, but maven supports other languages as well, generated code, folders for tests, resources, whatnot. It's not impossible to adapt something like that.

0

u/[deleted] Jul 21 '19

[deleted]

8

u/hgjsusla Jul 21 '19

Cargo is only simple because it forces you to use a very specific project structure, if you follow the same setup in C++ (which you probably should) then setting up CMake is a walk in the park

0

u/[deleted] Jul 21 '19

[deleted]

2

u/hgjsusla Jul 21 '19

The thing isn't about you having the same setup, it's about a standard
In this context that's the same.
This is again similar to naming conventions, there is already a standard yet people fork and come up with their own snowflake conventions when everything would be easier if you just sticked to the idiomatic style.
Style readability is mostly about familiarity anyways. I mean you would never write snake_case in Java or C#, and for the same reason it doesn't make sense to use camelCase in C and C++.

8

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

it doesn't make sense to use camelCase in C and C++.
A surprisingly number of people use camelCase or PascalCase in C++.

5

u/hgjsusla Jul 21 '19

Yep it is indeed surprising. Seems like a thing that mostly only C++ suffers from. In other languages people tend stick to the standard/idiomatic style to a much higher degree.

3

u/megayippie Jul 21 '19

Both Pascal and camel cases are good to use since the standard is written in the third-case. So you'll never interfere with the standard. Like, Rational is useful since rational is just a proposed standard. And Complex is useful since complex does not promote properly. And Vector is useful since vector does not represent vectors.

4

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

Or you could just use namespaces.

-1

u/NotMyRealNameObv Jul 21 '19

ADL is a thing, and if you avoid camel_case in your own code, you reduce the risk of getting bitten by it.

3

u/c0r3ntin Jul 21 '19

You avoid ADL with the standard, not with all other libraries that might have decided a different case. It doesn't scale. Of course because we don't have dependencies management it never had to.

0

u/[deleted] Jul 21 '19

[deleted]

1

u/hgjsusla Jul 21 '19

Please re-read my comment this is exactly what I meant. People should stick to the standard not make up their own. That makes things consistent which is what matters

7

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

It's a fine solution for Rust, which has a single implementation, a very targeted set of use cases, and ~100k users.
C++ has multiple implementations, runs on a myriad of platforms, and supports a wide range of domains and environments.
Something global like cargo wouldn't work for everyone in C++. We should enable something like that to be built, but we should also enable other options (distro package systems, in house package systems, etc).

4

u/c0r3ntin Jul 21 '19

Distributions are built from source in a consistent environment (the only thing that is not guaranteed consistent is compiler flags)

4

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

I work adjacent to the CUDA driver team. A large part of building the CUDA driver involves custom build steps/phases that are unique to what we are doing (building a massive Windows core driver/Linux kernel driver + user mode driver components + compilers + SDKs). I doubt a standard build system/project layout would ever work for us. I think this is true for a lot of environments.
We need to enable people to use the solutions/structure suitable for their specific domain/organization.

5

u/c0r3ntin Jul 21 '19

I still think you can express that in term of a dependency graph. Build x with tool y. And if you have a recipe to build y your can build it before x implicitly. In theory. I wouldn't claim this is currently practical for your use case. I am pretty sure it is not. Striving for simplicity in the general case doesn't mean we will, can, or should do that for every project anytime soon. I think that whatever the use case getting rid of unecessary complexities (for example avoiding TU specific flags) is beneficial. Maybe different approaches can converge.

1

u/Auriculaire Jul 21 '19

You're describing Spack

1

u/krapht Jul 22 '19

I wish Spack supported Windows. Instead I'm implementing reproducible builds in some terrible mixture of Conan, Ansible, and Vagrant. Same way you can't get Guix running on <not Linux>. Seriously! Cross-platform support is a feature, not a bug!

0

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

Even if they do converge, it doesn't mean everyone will migrate.

4

u/c0r3ntin Jul 21 '19

We don't need them too ! Just need a critical mass of open source projects. Look how fast people moved to cmake over the past decade. The reason they did it is because they saw a value in a bigger ecosystem

→ More replies (0)

3

u/c0r3ntin Jul 21 '19

Migrating everyone, whereever to, should be a non goal. My personal goal is to make it easy for people to use lots of open source libraries very easily in a way that result in correct, reproductible programs that don't crumble over time. That alone is ambitious enough that we may never get there even if we already have good approximations.

0

u/[deleted] Jul 21 '19

[deleted]

8

u/c0r3ntin Jul 21 '19 edited Jul 22 '19

Magically behaving ide are part of the problem because they hide an incredible amount of complexity instead of reducing it, leading to ecosystem fragmentation. VS code is in a much better place because it doesn't try to pretend building c++ is magical. It let users set up the few required build command manually and let the build system deal with the nastiness

1

u/JuanAG Jul 21 '19

The problem is the reason that forced they to has to hide it. Build system is only equal to pain and stress, it may handle the nasty stuff but requires much effort from the developer in order to do it
And bigger problem is that Rust has hoard my attention recently and it went to "will see the future of this new C++ killer" to "i am eager to try and see if it becomes my new high performance lang". I has for granted so many things and more that are comming that really makes it hard not to do the change so in the end is promises vs reality. The issue is that much more people see this way than not and people are tired of waiting for them to arrive

1

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

MSVC ranges (which gives you that overload) are still a work in progress. /u/stl, is it available yet?

1

u/STL MSVC STL Dev Jul 21 '19

Not yet. Casey will be working on it.

13

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

A better and more complete STL with simplier sintax, list.find() or list.contains() instead of "std::list<int>::iterator findIter = std::find(ilist.begin(), ilist.end(), ObjectToFind);"
std::find(ilist, ObjectToFind); in C++20. That seems fine.

3

u/[deleted] Jul 21 '19

I was under the impression that those overloads are under std::ranges no?

3

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

Ah, yes, that is right I believe.

3

u/eniacsparc2xyz Jul 22 '19

> No build system, make it a default one that hides all the complexity of the project but that allows some customization
In this case, it seems that CMake fits the bill. I have tested many building systems and IDEs and CMake is the only one that has more adoption and is supported by many IDEs. In addition, it is scalable and can easily use any other library or subproject as a dependency wit add_subdirectory or its command for donwloading libraries. But unfortunately, many projects and C libraries still use GNU autotools and other building systems.
> A good package manager, including a third party lib is painfull and slow and chances of success are not 100%
Well, conan may not be a standard package manager, but it saves the day, it is pretty easy to use and saves lots of compile-time.
> i am going to buy a good book about Rust and give a real try,
I've heard a lot about Rust, but it seems to have an even worst compile-time than C++. There are other alternatives to C++ such DLang D-language which has an amazing fast compile-time and ADA spark for embedded systems and safety-critical systems.

4

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

Do you mind if i give my opinion?
Please do, feedback is always good.

4

u/MrWhite26 Jul 21 '19

A good package manager, including a third party lib is painfull and slow and chances of success are not 100%
CMake does allow for concise project definitions. For personal projects, the vcpkg package manager makes it easy to use 3rd part libs.
It's all not python level ease-of-use, but also not a world apart either.

8

u/[deleted] Jul 21 '19

Python's package manager is "fine", until you need to package a module written in C++ that optionally links against a shared library. And then, when ~~you~~ I try to use pip to install a dependency, ~~you~~ I get flooded by bug reports because users have the python interpreter and CPython headers, but a lot of them don't have pip.

In my personal experience, every C++ build system was much easier to work with than Python's pip. We ended up forking a dependency just so we can build it with cmake instead of using pip.

1

u/thesuperbob Jul 21 '19

Then there's the unlucky bunch who have pip installed somehow, but what they really need is pip3. Also there's the matter of linux disros that only offer an ancient version of pip, and updating pip effectively brakes it on that system.
It's really not in a good place right now, at least not for people who just want a package installed and don't feel like going on a wild ride of trying to fix it.

1

u/megayippie Jul 22 '19

pip was not in the python standard before python 3.4. It is convenience when it works. And often an SEP otherwise.

1

u/JuanAG Jul 21 '19

Vcpkg is awesome but is not a fault free solution and they still dont has all the libs, they are working hard and i am thankfully that MS released it for more than Visual Studio
Cmake could allow what you want, the problem is that you start dealing with differents commands that do the same and the party starts, there are few libs that works as expeted with only adding the add_subdirectory() so 99% of the times you will has to struggle to make it work, and that is if the libs has the cmakelist, because are some really important projects that they dont, ffmpeg is one of them, the most important codec library of the world and no support...

7

u/degski Jul 21 '19

... is not a fault free solution and they still dont has all the libs ...
No, but getting better and there are now over 1'000 libs (and counting), going for 'all' seems a bit over-ambitious.
CMake is doing the same as C++ itself, add more stuff and keep the old, for backward compatibility.

1

u/eniacsparc2xyz Jul 22 '19

There is also Conan package manager that it is easy to use with CMake and uses recipes to download packages from remote repositories. Conan also store the library object-code in its local cache which allows later reuse in other projects saving compile-time.

0

u/[deleted] Jul 21 '19

[deleted]

-3

u/JuanAG Jul 21 '19

Why not, they are real, i cant always use the lib i want even if it has the same build system, there are times when you simply arent able and let it be choosing another. If the library owner do the job to ingrate with the package manager i know for a fact that it will work, well, if that day finally comes
And i dont know about the rest but i dont like having to track my cmake as i code, if i put a class name and later decide other better i only want to change once, not in C++ and latter on CMake, or if i try something like another lib not having to do the cmakelist clean up latter
The comunity and/or the comitte could do what they want, i am only telling what less hardcore users wants and why nobody these days is learning C++, i has been warning since a long time but now is aproching the end, i dont like to code at least 3 times slower at best compared to Java (which i love) with more problems when there are other options, i choosed C++ back in the day for the performance and i has been locking this week benchmarks, the conclusion i gathered is that C is faster, later Rust and in 3rd place C++, they are close but numbers dont lie so Rust is not a bad choice, it is at the same level of performance (wil depend on every case if it is second or third) but it has a better tooling and the things that will come are incredible
Past christmas i will try for real and if i like it and if all the things about it are true (performance, smooth experience, good library, ...) i will switch, myself it is not relevant but i am sure that my case is the same as many more, and once the ball starts rolling no one cant stop it, if i think is better (so i will use it) i will tell others to try, and the ball will keep getting bigger, that´s the problem and the ones who did that before me and speak about the experience only grows my desires to try and see for my self, when Rust was only a toy from Mozilla i didnt looked at it thinking i will try it in the future, some years later i only read good things about it and has the things i want in a tool that make my life easier, i hope anyone could see the picture because if C++ dont do anything really good about it will not matter at all in not so many years
And when developers start to switch the industry will follow which means the ISO will start loosing people, if the company dont plan to use anymore the tool makes no sense to invest money on it, Nokia, Kodac or even BASIC back in the day were "to big to fail" and we all know what happened, nothing is granted and you can be the number one that will see tomorrow if it still true

42

u/krapht Jul 21 '19

TL;DR: OP wants a BDFL to ship a high-quality, batteries included standard library.

OP, you'll never get your wish. Too many people use C++ for high-perf code where people want to understand and specify exactly how their code gets compiled down to machine instructions. These machines also may be weird embedded systems lacking all sorts of capabilities you'd expect from a modern CPU. This means any standard library implementation has to satisfy a gajillion stakeholders and use-cases.

No offense, but if you want high-level libraries with "it-just-works" semantics and reasonably high performance, maybe try C#? You can stack allocate most objects if you need performance, it runs on both Linux and Windows, and it has a huge ecosystem of libraries.

10

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

What's BDFL?

6

u/afiefh Jul 21 '19

Benevolent dictator for life. https://en.m.wikipedia.org/wiki/Benevolent_dictator_for_life

5

u/krapht Jul 21 '19

Benevolent dictator for life, like Guido Rossum for Python.

1

u/matthieum Jul 21 '19

Guido stepped down, though.

4

u/DubioserKerl Jul 21 '19

Google tells me it is the "Bund deutscher Fußball Lehrer" (German Soccer coaches association) ... 🤔

5

u/JuanAG Jul 21 '19

I dont think he wants a dictator ruling the language, i think he wants what many of us dream about and many other competitors has, i like coding and i enjoy doing in Java, in C++ it is hard to do as it is not the code, it is the code and all the ecosystem around you and because it is from the 80s is the experience you get, far from a good one, back in the day may be fine but since i has tried better things i want them

-4

u/mintyc Jul 21 '19

I guess that's the point. I want java's ecosystem but in a C++ system. I still love C++
This was a goal stated for C++ 10 years ago when C# emerged and Java was also already more productive for most application development.

11

u/Drugbird Jul 21 '19 edited Jul 21 '19

So are you arguing for our against the use of third party libraries? You seem to be for in one paragraph, and against in another.

2

u/mintyc Jul 21 '19

C++ needs them. Standards committees principles means that it cannot deliver the length and breadth required.
Limited standards resource should be focused more tightly.
It has the power to encourage and guide the ecosystem but doesn't have the resource or maybe even the mindset to implement.
Halve the scope of the standards work, but encourage 10x ecosystem development

8

u/Drugbird Jul 21 '19

I'm sorry, but i have a very hard time understanding what you're saying exactly?
How does the standards committee encourage (or not) third party library development?

2

u/mintyc Jul 21 '19

It should encourage but not 'do'.
Lots of proposals consume evaluation effort. Some make it further.

5

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

By focusing on making it significantly easier to use third party libraries. Modules goes a long way towards this, by giving us better code encapsulation.

1

u/Drugbird Jul 21 '19

They're already doing this?

0

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

Not sure what you mean?

2

u/jwakely libstdc++ tamer, LWG chair Jul 23 '19

I wholeheartedly agree with this.
We (the standards committee) have invited people to make proposals, and people are doing so in larger numbers than ever before. Not all of it is really what we should be standardising IMO, and there should be more focus on what's essential. I wish the response to more library proposals was "this is great, but it doesn't need to be in the standard - go away and make it successful on github".

19

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

The committee is practical, not "intellectual".

Have you ever been to a committee meeting? If not, then perhaps you should attend one to see how things actually work.

6

u/JuanAG Jul 21 '19

I will want to attend to one but i am afraid of going and voting, i am not a guru so my vote, even if it is needed for quorum i wouldnt feel good about it because i will be voting based on what others do not on what i think is the best
And i always defend the hard work of the ISO and people like you that keep us to date of what´s going on, the problem is not lack of hard work, i guess it is a focus one, instead of dealing with so extreme cases it should be better to improve the foundations. I dont know how to solve it but the overall results are not fulfilling if you compare to other recent rivals

10

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

Being a guru isn't a requirement for participation. My point was more that the author might have a different perspective if he saw how we actually work.

0

u/[deleted] Jul 21 '19

[deleted]

1

u/bstamour WG21 | Library Working Group Jul 23 '19

You can attend and abstain from voting in the straw polls.

2

u/[deleted] Jul 22 '19

The committee is practical, not "intellectual"
Well, when I look at examples how std::variant is supposed to be used, I have to slightly disagree...

-8

u/mintyc Jul 21 '19 edited Jul 21 '19

I don't need to attend. You have a proven and excellent track record at the building blocks level. I trust you.
I know you wrestle with the wider issues constantly. Should this feature be considered, rejected etc.
I look at the outcome and for every great building block or strategic change requiring standards support e.g ranges, modules, you have struggled to deliver the goals stated 10 years ago for a wider ecosystem, productive tool.
Time to recognise that less is more in the standards work.

6

u/blelbach NVIDIA | ISO C++ Library Evolution Chair Jul 21 '19

Time to recognise that less is more in the standards work
I agree. I'm solidly in the "batteries not included" camp. Not everyone is, though - some believe that a lot more features and a bigger standard library is necessary for C++ to remain competitive.

3

u/CODESIGN2 Jul 21 '19

Language evolution is NOT the end objective in the real world.

end goals or AIMS are not objectives. AIMS & end-goals should be specific, measurable, actionable / assignable, relevant and time-based. Objectives help you get to end goals, but generally represent a unit of work towards an end goal or aim.

How can you be complaining about language whilst using incorrect words?

It's ok to define things that aren't infinitely flexible, and infinitely extensible but get the job done.

Agreed. Kate Gregory talks about this in some of her more accessible pluralsight courses. Also Kate has done a number of YouTube talks covering this.

It's OK and, in some ways better, to provide an opinionated library outside the standards rather than deliver an intellectually burdened, extensible interface two years later than needed.

If I squint a bit this might be okay for a business. Not a standard or framework.

Of course you can cast everything using (void *) if you're working on some internal noise project. Doesn't mean training should push that as a good way to code.

All the helpful features in the core language and core libraries are MEANT to enable a much wider ecosystem to make the tool that is C++ more productive.

What does this mean. Do you have examples of when core libraries restrict ecosystem and make C++ less productive?

But we aren't getting a wider ecosystem, we are just getting a language where we are apparently 'not paying for' a huge intellectual burden.

All programming languages suffer this to an extent. Some of the newer languages have enterprise support from Giants like Google & Mozilla, but ultimately, all are under-funded. C++ further suffers from not having too many giants supporting a freely available compiler, and many compilers having differences which make inter-compiler compatibility a burden. There are additional costs to even get started with C++

Look at how the wider productive ecosystem hasn't flourished since C++ 11.
I know many excellent libraries have been made, but think about your next large project and how much is coming from a mixed bag of variable quality 3rd party libs to plug basic capabilities.
The committee work is spread so thin that core building blocks get pushed out further in time and so can't be built upon by library authors.
Networking, executors, any form of I/O - slipping again.
Lots of hard work being done but by far too few people in their spare time.
Seems a very dysfunctional way to move the monolith forward.
'You don't pay for what you don't use' is laudable up to a point, but the 'don't use' because you don't actually have, say, a basic network library is more of a reality.

Hmm... IDK it is easier for application languages to make lots of decisions up-front about this sort of thing. For example non-blocking as a default, or hashmaps called arrays because the mental model is contiguous. C++ largest challenge as I can see here is C and legacy C++ compatibility.

My point is that whilst language sugar and features may be available in a lot of other places; choice and robust open design are not.

It would be nice to have an official C++ compiler, linter, formatter, interactive debugger (pdb + pdb++ is great IMO), documentation standard and a larger standard library, but without finding millions of dollars to fund it; I don't expect it will fall from the sky at any point soon. Worse still, implementations of C++ for embedded platforms and non-x86 hardware will continue to have warts

1

u/mintyc Jul 21 '19 edited Jul 21 '19

What does this mean. Do you have examples of when core libraries restrict ecosystem and make C++ less productive?
Not being a 'positive' change isn't the same as being a 'negative' one.

1

u/CODESIGN2 Jul 21 '19 edited Jul 21 '19

If changes are not discernibly negative or positive to you, they are probably positive to someone, even if it's not you

8

u/Lectem Jul 21 '19

I've been saying for a long time now that we mostly don't need new shiny library features but more core features. Most people couldn't care less about 2d, ranges, asio, audio if we had a good standard package description and compilation model. They would just use a 3rd party. The std for me should not be a big framework or try to standardize stuff that is sometimes not even yet a standard in domains not related to the language itself. (see all the fuss the 2d proposal made) Less new fancy stuff that do not solve actual problems (if there are easy to install 3rd party, it is not a problem).

It seems modules are partly going in the right direction at least on this point, it will make us have a more modern and decent compilation model.

4

u/DerekClives Jul 21 '19

Another example of why software development is a job not a profession.

15

u/JuanAG Jul 21 '19

Uff, brace your self, this type of opinions are not very popular here even it they contain part of the truth or reality

I will say it is half broken if you compare to modern products, it needs a updgrade and soon, the good part is that is optional, using C++ is not mandatory, you can choose any other language you want

2

u/khleedril Jul 21 '19 edited Jul 21 '19

Wouldn't all this go away if library header files were stored in the library container itself (.a, .so, or whatever), and the compiler only needed a -lthirdpartylib flag to get everything needed without version incompatibility problems or other infrastructure dependency?

1

u/sebamestre Jul 21 '19

I don't think stating dependencies in compiler flags is the right way to go about this.
If anything, they should be in the source files, or in a separate dependency description file, and the linking should be done automatically.

3

u/Dean_Roddey Jul 21 '19 edited Jul 21 '19

Of course I've been saying similar things for a long time, though it's a little ambiguous exactly what you are saying I think. I certainly believe, if this is what you mean, that way too much time has been spent on stuff like containers, much of which anyone can trivially do if when they need to, and not enough time on stuff that real applications need these days which aren't trivially doable. I also think a huge amount of time has been spent pushing premature optimization all the way up into the language design process, and trying to serve too many masters (which I think is one thing that you are clearly saying.)

I've put my money where my mouth is and created a system that puts the emphasis where I think it should be, i.e. less on creating an operating system in a single templatized header that uses zero CPU and runs at compile time, and more on providing the type of functionality that is needed to do the kinds of programs that C++ is intended for (other than embedded) without having to just throw a bunch of bits and pieces together, and maintaining readability by avoiding massive templatization, using them only where they really required.

https://github.com/DeanRoddey/CIDLib

My argument would be for a 'RISL', a Reduced Instruction Set Language, that provides the core functionality without forcing any runtime libraries at all, allowing for the development of specialized library sets for specific needs, but within the context of the same language syntax.

Not sure why I bothered typing this, because your post will get down-voted into oblivion within minutes probably and no one will ever see this.

10

u/[deleted] Jul 21 '19

Not sure why I bothered typing this, because your post will get down-voted into oblivion within minutes probably and no one will ever see this.
Rest assured, some of us ignore the downvotes on the post and see 80+ comments as a indicator of an interesting discussion. Too bad most redditors don't understand that they should upvote interesting content, even if they don't agree with it.

7

u/[deleted] Jul 21 '19

like containers, much of which anyone can trivially do if when they need to
I would be very surprised to hear about a non-trivial application that doesn't use any containers. Since they are very useful, why shouldn't they be in the standard library?
I also think a huge amount of time has been spent pushing premature optimization all the way up into the language design process,
Not everyone thinks that having everything be a polymorphic class with runtime configuration for things that should be really decided at build time is a good idea.
without having to just throw a bunch of bits and pieces together
I'd rather combine multiple high-quality single purpose libraries to do the tasks that I need than having a single huuuuge monolithic library that does everything badly (or at the very least not as good as the single purpose libraries).
maintaining readability by avoiding massive templatization,
I don't know what exactly you have against templates, but they're pretty useful. Sure if you're doing a library you're probably going to need some template stuff that is a bit verbose at times but really, when you're writing code that uses them they're perfectly readable.

0

u/Dean_Roddey Jul 21 '19 edited Jul 21 '19

The fact that something is built to work as a system and shipped as such doesn't mean it's monolithic. That would require it be all in one giant library. My stuff is split up into many libraries. But they are all designed to work together from the ground up.
And it's a bit of a stretch to conclude that it's bad if it's not a standalone library. Ultimately the sum of the parts counts for a lot. When everything shares the same architectural features, the power you get from that, IMO, is a lot larger than anything you lose from the fact that every piece isn't the ultimate implementation. In fact the ultimate implementation, IMO, is sometimes not all that great because it's may be created with the problem domain in mind, not with the process of building systems in mind, and often including a lot of extra complexity that many to most applications won't need.

C++ is broken

You are about to leave Redlib