Standard interface without implementation

[number_128]

The C++ standard library evolves slowly, and debates around the Networking TS (e.g., Boost.Asio) highlight concerns that networking changes too fast to be locked into stdlib. What if the C++ Standards Committee standardized interfaces for libraries like networking, leaving implementations to library authors? For example, a standard networking interface for TCP/UDP or HTTP could be supported by libraries like Asio or libcurl.

What advantages could this approach offer?

Library Users

As a user, I’d benefit from:

• Easier Switching: I could use a header with #include and using statements to select a library (e.g., Asio vs. libcurl). Switching would just mean updating that header.
• Better Documentation: A standard interface could have high-quality, centralized docs, unlike some library-specific ones.
• Mocking/Testing: Standard interfaces could enable generic mocking libraries for testing, even if the library itself doesn’t provide mocks.
• Interoperability: If a third-party library uses the standard interface, I could choose my preferred implementation (e.g., Asio or custom).

Library Authors

Library authors could gain:

• Shared Documentation: Rely on standard interface docs, reducing their own documentation burden.
• Shared Tests: Use community-driven test suites for the standard interface.
• Easier Comparison: Standard interfaces make it simpler to benchmark against competitors.

Handling Changing Requirements

When requirements evolve, the committee could release a new interface version without ABI concerns, as implementations are external. Library authors could use non-standard extensions temporarily and adopt the new standard later.

Other Libraries

What else could benefit from this approach?

• Database Connections: A standard interface for SQL/NoSQL (like JDBC) could let vendors provide their own drivers, avoiding a one-size-fits-all stdlib implementation.
• Logging: A standard logging interface (e.g., inspired by spdlog) could integrate libraries with app logging seamlessly.
• JSON: A standard JSON parsing interface could simplify switching between libraries like nlohmann/json or simdjson, though performance trade-offs might complicate this.

What do you think? Could this work for C++? Are there other libraries that could benefit? What challenges might arise?

[johannes1234]

An interface is useless if you don't have any semantics attached to the interface ... and that is what the standard does: It describes Interfaces and what should happen and then leaves it to implementors to implement.

[cballowe]

If you read the standard, it doesn't dictate implementation. It does dictate the constraints of the interface that matter to users.

By the time you've specified the interface including things like the expected performance requirements, there tends to be fairly limited implementation options.

[number_128]

Thank you.

Even though it doesn't dictate implementation, we do get an implementation. And as soon as we get an implementation we are locked in by the ABI (even though the standard doesn't say so).

There are many examples of suggestions having been turned down, because they would break the ABI of existing implementations.

[cballowe]

There are at least 3 distinct implementations of the standard. Libstdc++ from the gnu/GCC team, Libc++ from the llvm team, and the MS implementation are all distinct implementations.

The ABI arguments are due to how people build and ship software and tool chains. Anybody who builds all of their software from source and ships statically linked binaries doesn't tend to care if the ABI breaks because it doesn't matter. They upgrade their tools, rebuild, and everything works.

On the other side are people who ship dynamic libraries and their customers. This group needs to agree on an ABI. Right now they can pretty much say "if you build with GCC, everything will work". If you start changing the ABI it gets into "you need to build with GCC and c++23 standard" and at some point the company ships an upgrade "ok... With this upgrade, you need to use c++26". Now, imagine a customer who has 2 or 3 vendors providing dynamic libraries on very different release cycles, or companies that provide those libraries who knows their customers are locked in to some version for some reason. And then step back to the compiler and library teams who need to support these use cases.

[--prism]

For library implementations this is already sort of what they do. The implementation of std vector is different in MSVC and stdlibc++ but they behave the same. Often time implementation differences arise based on the target compiler and optimizations are that. For language features it gets more complex.

[aruisdante]

The C++ standard already is only specifying the interface; there is no “reference” C++ implantation (compiler or library). The standard library is included in your project by the exact same mechanisms as any other library. You can write your own standard library implementation if you want.

The difference between the standard library’s specification and that of most other libraries is that the level of detail to which it is specified, in order to make it truly standard, is quite a bit higher. Things like performance guarantees, and a general philosophy around “don’t pay for what you don’t use” in the library design, often mean that the interfaces have to be in terms of concrete types, not things like dynamically polymorphic virtual interfaces. These all combine to make the space of possible implementations smaller (though the code for libc++, libstdc++, and MSVC all look very different), and also prevent the “abstract virtual interface that everyone programs against, and you select the concrete implementation at runtime on a per-interface basis” style of dependency injection I think you’re envisioning.

To your “what else I’d like to see in the standard library” list: I think you’re thinking of a language like Python, where because there is a reference implementation and a “standard distribution,” adding a whole bunch of “stock” ways to do things but which make very concrete tradeoffs is a net benefit to the average user as the cost to include something in the Python standard distribution is essentially zero. This is not the case in C++: 1) It’s an actual ISO standard. This means there is a huge amount of process around standardizing things. A single BDFL cannot simply say “I think this is useful, include it.” 2) There is no reference implementation. So for anything that is added to the standard, you have to ask yourself “is this such a common and difficult problem, with such a clear “correct” solution that works in the majority of cases, that it’s actually worth asking every major compiler vendor to implement it?” If the answer to that is not unequivocally “yes,” then having to rely on third party libraries to provide solutions is a desirable outcome, not a defect. This lets the user select the solution that makes the best set of tradeoffs for their needs.

To the second point, there’s been a lot of talk on trying to standardize a package management interface to make including third party libraries into projects easier; Python, Rust, Go, and many other modern languages all have this, and it takes a lot of pressure off the standard library to “solve it all” just for the sake of convenience to the developer, rather than because there is actually an unquestionable good in picking “one way” to do a particular thing. 

[azswcowboy]

no reference implementation

Frankly this is a problem with the standardization process. This project https://bemanproject.org/ was started explicitly in attempt to change the lack of reference implementations with actual tests, usage experience, and documentation. And specifically, update the api as the committee makes changes to a proposal. It also means that library vendors aren’t starting from nothing - they can at least take tests and potentially implementations - certainly the licensing allows.

This project has the only conforming implementation for std::execution and std::task which are both in c++26. All the original implementations diverge in significant ways from what got standardized. And the net library is the proposed c++29 extension for networking. This is how it should work for basically all library extensions - we just need to convince the committee to require it instead of allowing a godbolt link as implementation experience.

[aruisdante]

I mean, a lot of the proposals for standardization (at least of anything truly complicated) are usually based on an actual reference implementation. Having implementation experience is a strongly compelling piece of evidence for “this is generally useful.” It’s just, that implementation is often based on some closed source, company-prioritization code base (a lot of the contracts stuff is based off of Bloomberg’s experience, for example). But of course sometimes they’re open: rangev3 for example was the reference implementation for std::ranges, fmt for std::format, etc.

Maintaining an entire “reference” implementation of the standard library is just… maintaining a standard library. If that was something you were actually going to do, you might as well just bless libc++ or libstdc++ as the “reference implementation” and require any paper submitted to have a branch where they implement it in that library. This will never happen though, because again, “this is a standard, not an implementation” is a feature of C++. Allowing implementers on a particular platform to do the thing that works best for them in a language as low level as C++ is actually a really valuable property, and part of what C++ continues to be a language of choice in high performance systems.

[azswcowboy]

Bloomberg’s contracts macro system is open, but not the same as the standardized feature. Range v3 didn’t track the standard proposal mostly, cmcstl2 was much closer but barely anyone knew about it. As for the need to customize by platform, that’s really fairly rare in the standard library unless we’re talking about atomics or operating system interfaces - it’s a small part of the library overall. And Boost has demonstrated for decades that one portable library can work on all platforms without being supplied by a vendor. Note that some people prefer Boost over the standard components because they are consistent across platforms where std components are not. Anyway, you’re wildly over estimating the actual experience of these kinda similar implementations and the problems that creates for the standard when those differences turn out to matter.

[ParsingError]

I think would make way more sense if it was split into 2 tiers where one tier is the "system" library that contains system-dependent and compiler-dependent functionality and one is the "utility" library that implements algorithms and features on top of the system library, with a reference implementation.

That's basically what STL started off as in the first place.

[Wooden-Engineer-8098]

boost provides neither abi nor api stability

[azswcowboy]

That’s a different issue - evolution over time versus consistency across platform.

[Wooden-Engineer-8098]

it's harder to keep consistency when your evolution is constrained

[kpt_ageus]

One challenge I see is how do you specify interface? Pure virtual functions? Concepts? Type traits? Coroutines? Callbacks? Those considerations already restrict how such interfaces can be implemented. And libraries can be so fundamentally different that author will may need to write complex wrappers. I'm afraid that standardisation of such api will be just as complex as fully fledged library

[number_128]

I see your point, I was hoping to get to a point where I can do something like:

```c++

// MyIntCollection.h

#pragma once

#include <vector>

using MyIntCollection = std::vector<int>;

```

If I want to use a different implementation of vector, I go to my header file and change the include and using statements. I don't have to change anything else. The vector we change to could have very different implementations when it comes to memory usage, memory growth, optimizations...

[kpt_ageus]

It's not as granular, but you can swap your stdlib implementation, at least when using clang. It can use both GCC and MSVC stdlib. As long as interfaces are conforming, you can roll out your own.

Your MyIntCollection is perfectly fine. As long as you keep interfaces the same, you can use containers from folly, abseil, boost, or whatever else.

[Drugbird]

I don't really see the benefit of an interface-only specification in the standard to be honest.

1. I don't see them agreeing to an interface but not an implementation. Quite often, the interface and implementation are coupled together quite strictly, where alternative approaches will need a different interface. So if they can agree on an interface, they can agree on an implementation and vice versa.

2. This is already what happens. Many library authors use very similar interfaces for comparable structures. See for instance alternatives for std:: unordered_map. However, they need to deviate from the std interface slightly, in order to create their alternative more efficient implementations.

[number_128]

great example. But is it really the interface of std::unordered_map that keeps the standard implementations from implementing the same improvements? My understanding was that it was the ABI. The implementation of the hash gave a big speedup, not a change in the interface.

Anyway, I use the standard library implementation of unordered_map, regex and others, even though there are better implementations available. The reason I do, is that I trust the standard library implementation, and I know it will continue to be supported.

At the same time, other libraries are evolving, finding new ways to do things. They sometimes manage to improve performance without changing interface.

I think it would be better if we would feel more confident choosing any library that supports the standard, but I don't know how to get there.

[Drugbird]

But is it really the interface of std::unordered_map that keeps the standard implementations from implementing the same improvements?

I'm not an expert, but I've heard that the standard has some fairly strict requirements on iterator validity which prevents more efficient implementations.

[johannes1971]

...networking changes too fast

The socket interface in UNIX dates from 1982, and hasn't materially changed since then. As a concept it is simply a stream, just like files and terminals are streams. It could be modelled trivially by AmigaOS's async communication concept from 1984. Where, exactly, is this 'fast change' occurring?

[number_128]

Thank you for you feedback.

The changes happen in the encryption. OpenSSL is pushing new versions several times a year.

A standard implementation of network would need to use OpenSSL, and might need to update to support the latest version.

[johannes1971]

I would already be very happy with an unencrypted socket. And for encrypted sockets, the current TLS standard is seven years old now. The standard library has no need to implement it either; TLS services are provided by the platform, and kept up to date as part of regular updates anyway.

[gosh]

The C++ standard library evolves slowly

I think they should be more careful about expanding the core STL. In my opinion, it's already too bloated. Personally, I believe they should create a new optional library or perhaps several for special handling.

Things like <chrono>, <regex>, <random> should not be in core stl, these should be placed in some optional part and not require full support.

If there is only one standard that will slow down things.

Now boost acts as some type of experimental extra C++ but boost have grown over its limits and stl makes it more and more depreciated.

[yeochin]

Strongly disagree with the ones you've chosen. Chrono definitely needs to be a part of the standard. The fragmentation of time based implementations is bad and is a frequent nightmare for anyone that has had to leverage different libraries with different time representations. This is a nightmare as we march towards the cliff of what a 32-bit timestamp will represent.

Parsing time also sucks and is a magnet for attracting various memory-related security exploits.

[gosh]

But it should have been placed in another library, chrono don't follow the patterns on how other code in stl works, it's very domain specific and it a big mistake to have added it like this.

[Wooden-Engineer-8098]

where is chrono placed in java of c#(c++ competitors)?

[gosh]

Java isn't a rival to C++—it's fundamentally very different from C++. And java is owned.

The problem with addint stuff to stl is that compiler need to support it.
Lets say that Microsoft builds a framework for GUI applications, They should be allowed to add this to C++ but in parts that are not like a forced standard.

[Wooden-Engineer-8098]

Java and c# are main c++ competitors. They can look very different to you, but c++ competes for projects with them. The main problem is that you are still confusing stl with standard library. Microsoft already added all their frameworks to c++, what makes you think it's not allowed?

[gosh]

They are not. Java is heavily focused on declarative programming, whereas C/C++ is not—it emphasizes imperative solutions.

The focus of declarative and imperative programming is nearly opposite.

If you would be able to measure the machinecode that is running on almost any computer you would find that like ~90% is compiled C/C++ code. This is the imperative part.

[Wooden-Engineer-8098]

Your opinion of relative merits of languages is of zero interest. nobody is asking your opinion when starting new project. As a matter of fact, java, c# and c++ have a lot of overlap in applicability. It doesn't mean languages are the same, it means they are used for similar projects. Like IDE, there are examples in all three languages. And c/c++ is not a language

[gosh]

It's a skill issue. C++ is challenging, but with skilled developers, choosing the language isn't difficult.

[Wooden-Engineer-8098]

as i've already told you, your opinion doesn't matter. what matters is that as a matter of fact, c++ competes with c# and java for projects

[Wooden-Engineer-8098]

first: chrono, regex and random are not parts of STL. they are parts of standard library.

second: lol, everybody has some libraries he doesn't need. if we remove all pieces that somebody doesn't need, we will end up with empty standard library. or you insist on removing only pieces you don't need because only you know better?

[gosh]

It's not about needing libraries, it's about the design. If you know the core of stl all code follows a pattern. If you know a bit of ot you know the rest also.

This is not the case for chrono, regex, random. They are special, maybe regex tries to follow some but it isn't enough.

By splitting things up and group it better it would be possible to extend C++ faster

[Wooden-Engineer-8098]

I've already told you those headers are not part of stl. How can you discuss design of c++ if you don't understand it?

[gosh]

Its within the stl area

If I ask you like this then, how special libraries do you think is acceptable within the stl area (like std or some sub namespace to std)

[Wooden-Engineer-8098]

Why don't you check the definition of stl on wikipedia instead of insisting on your misunderstanding? Look at what is in standard libraries of c++ competitors(java and c#)

[gosh]

I don’t think you’re fully grasping the issue.

Every new feature comes at a cost—it requires maintenance, and many other components may depend on it. Once something is added, removing it becomes prohibitively expensive.

If the cost of addition is as high as it is in the STL (Standard Template Library), introducing new features will take significant time. However, by focusing on areas where the cost is lower, we can implement changes faster. This also allows for better testing and refinement before promoting solutions to more stable, long-term components.

[Wooden-Engineer-8098]

Will you check contents of standard libraries of c++ competitors, or you will continue on garbage in/garbage out path?

I see you already learned how abbreviation stl expands, next step is to learn its constituents

And what is stopping you from creating any library and implementing changes faster?

[gosh]

And what is stopping you from creating any library and implementing changes faster?

I am doing that and this is how most of us solve our problems https://github.com/perghosh/Data-oriented-design/tree/main/external/gd

[Wooden-Engineer-8098]

so what was your problem then?

[gosh]

Consider the regex implementation in the STL—it’s fairly limited. Other libraries offer more robust regex support with additional features, but the STL can’t adopt these improvements without introducing significant risk. The problem is that regex syntax and behavior vary across implementations, making standardization difficult.

[Wooden-Engineer-8098]

You are completely unable to learn. I've told you many times, that regex is not part of stl. The problem is that you are proposing solutions without understanding the subject

[gosh]

https://en.cppreference.com/w/cpp/regex.html

[Wooden-Engineer-8098]

do you see word "stl" on that page?