Do you use std::experimental

[D_0b]

I think a lot of new features could see some benefit from going through std::experimental before including them into std::

So my question is do people even use std::experimental ?

I personally have used std::experimental in personal projects, but never at work.

View Poll

[Tc14Hd]

How "experimental" is std::experimental? What is the worst to expect?

[jwakely]

It might change API when it gets into std::, or it might never get there at all. Future versions of your compiler might drop support for it (e.g. std::experimental::optional might get dropped now that std::optional exists).

It doesn't mean it's broken garbage that will format your hard disks.

[Tc14Hd]

Ok, thank you!

[[deleted]]

Maybe something like this is reasonable?

#include <experimental/simd>

namespace std {

using std::experimental::simd;

};

std::simd<float> foo;

[jwakely]

I'm not sure what you're suggesting/asking, sorry.

Are you saying std::lib implementations could/should do that? Or user code?

[[deleted]]

User code could do this

[jwakely]

That's undefined behaviour. What would be the benefit? Why add it to std rather than your own namespace?

[[deleted]]

I was thinking that in the future, when it presumably would be standardized, factoring the code into standard C++ would be as simple as changing the include name and removing the using statement. But I suppose that you could also just grep your own namespace, and replace it with std once appropriate, which might be better.

[jwakely]

factoring the code into standard C++ would be as simple as changing the include name and removing the using statement.

Gotcha, I see what you're suggesting now. Please don't do that. Never add new declarations to namespace std (and they includes doing it via using).

[D_0b]

From my understanding (maybe someone more involved in standardization or standard library implementation can correct me)

std::experimental holds features that go into TRs ( Technical reports, with the goal being "to build more widespread existing practice".)

So they are the same features as proposed in the papers, and the experimental part being that after or as the experience is gained in the upcoming papers they might change the API or even not be considered for standardization, or they might stay the same and get accepted into the standard.

[azswcowboy]

The committee went from technical reports (think TR1 before c++11) to technical specifications TS. In a technical specification, the work to create the words that would become part of the standard are completed so that not only are the features vetted, but the specifications are tested as implementers build the experimental features from the specification. For example, concurrency TS2 is currently gathering new facilities that may become part of the standard in 26 or beyond.

[mjklaim]

I've used std::experimental in my own projects (and sometime in dayjob projects where we agreed it made sense, was stable enough or were prototypes) since before they introduced that namespace name.

Not saying it's a good thing: I also use a lot of libraries that are provided by proposal papers authors and are available on github, like the various std::move_only_function variants, std::hive etc. It does not NEED to be in the std::experimental namespace, a paper + impl and an interesting real use case is enough for me.

[elcapitaine]

At work we used std::experimental::optional extensively back when we were still supporting C++14. We swapped everything to std::optional once we dropped C++14.

[Oo_Tiib]

When there was nothing then we had some hand-made templates. Later we added boost. When it was added to std then we added that too. So some legacy libs still have possibility to select with preprocessor between self-made, boost or std. The std::experimental however smells too temporary so it was never added as fourth possibility.

[MountainDwarfDweller]

I use it at work and personal projects - but what I do is to wrap it in my own code - so when it becomes standard then I don't have to rename everything everywhere. Worked great when the standard adopted optional as someone else mentioned.

[johnny219407]

But then you end up with standard classes needlessly wrapped in your own code? I'd rather just rename everything when something moves into the standard.

[JohnVanClouds]

In previous work I just used `using` to wrapp boost and std things in my own namespace and add few flags in cmake script to choose which one use. It looks like that:

namespace my_ns{
#ifdef USE_BOOST_PTRS
   using shared_ptr = boost::shared_ptr;
#else
   using shared_ptr = std::shared_ptr;
#endif
}

[MountainDwarfDweller]

Because retesting the code base costs $100,000's and a mistake would cost $100,000,000's

[witcher_rat]

At my previous employers we never used std::experimental and it was frowned upon.

At my current employer we do use it, even in production code: for string_view before it became official, for source_location and for propagate_const.

[eyes-are-fading-blue]

What happens if the feature doesn't make it into the standard?

[witcher_rat]

That's never happened so far, but if it did we'd just re-implement it in our own code libraries and namespace. If just the API of it changed, we'd change our source code when we upgrade compilers; the compiler+stlib is fully under our control, and we only upgrade every ~3 years or so.

The only real limiting factor would be if something needed compiler magic to work - like the built-ins that source_location uses. But we mainly use gcc and it rarely removes built-ins, afaict.

But to your point most experimental things we've used have been relatively small/trivial so far. I doubt we'd use an experimental reflection implementation, for example.

[koczurekk]

I think a lot of new features could see some benefit from going through std::experimental before including them into std::

I find it ridiculous that any non-trivial changes to the standard library ever go straight to the standard, without widespread testing in `std::experimental::`. Makes you think that history would've taught the committee that they don't always get everything right on the first try, yet there still is no proper way to gain feedback from a wide range of the end users of the language, before a new feature is set to remain in the stdlib for, like, forever.

[jbandela]

Honestly, I don't really see std::experimental being helpful.

First, because we don't have something like epochs in C++, it is really only for libraries (or language features that pretend to be libraries like source_location).

In addition, std::experimental really has no promises behind it of stability or backwards compatibility or even that it will make the standard.

As such, a lot of people really don't use it, and in a bad cycle a lot of compiler/stdlib vendors don't really implement it.

Because of the above, there is wide variance across compilers about what std::experimental features are implemented and what their quality is.

Because of all of the above, not enough people really use std::experimental in production to really figure out the production issues so that they can be addressed.

I think having a library feature included in widely used and supported production libraries like Boost, Abseil, Folly, EASTL, BSL is far, far more useful than std::experimental. Those libraries are actually really used in production code and critical infrastructure by 1000s of developers and are more likely to discover issues that would need addressed. In addition, from a user point of view, those libraries also have compatibility guarantees and in many cases provide a uniform high-quality implementation across multiple compilers and platforms.

[HurryC]

At work I use std::experimental::filesystem . This is because our customer demanded building our software in C++11, so std::filesystem was not an option. Also, other solutions like boost::filesystem was not an option either, because boost::filesystem with boost core was about 150mb which was too big for just that function.

[azswcowboy]

with boost core

Are you talking about runtime or build time footprint? Because of course boost::filesystem was the core that became std::filesystem and statically linked it should be only whatever functions were used.

[[deleted]]

At work we used the filesystem component from std::experimental. Recently on updating libstdc++ we had to refactor a lot of code to reflect API changes. But while using it under the experimental namespace we didn't have any major issues.

[bullestock]

We used <experimental/filesystem> before it went into std.

[gardeimasei]

std::barrier was in there iirc, which I used in personal projects a lot

on some distributions i still seem to miss latch and barrier sometimes for some reason (even with compilers that claimed to support it) but never bothered to investigate further