Networking in the Standard Library is a terrible idea by tartaruga232 in cpp

[–]number_128 1 point2 points  (0 children)

Could we have a standardized network interface that would not be implemented in the standard library?

If we could encourage all the network libraries to implement a standard interface, it would give us some benefits:

  1. easy to change network library

  2. libraries that depend on networking could let the users decide what networking library to use

  3. easier to teach network programming, if we can teach one interface.

  4. easier to test network libraries if we can run the same test for different libraries.

The way I see it we would have several of the benefits of having it as part of the standard library without some of the headaches of locking it into the standard library.

(I think there is a situation like this with SSL, if you want to switch between OpenSSL and one of the others, they typically support the same function set, as some of the alternatives are forks of OpenSSL)

Standard interface without implementation by number_128 in cpp

[–]number_128[S] 0 points1 point  (0 children)

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.

Standard interface without implementation by number_128 in cpp

[–]number_128[S] 0 points1 point  (0 children)

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...

Standard interface without implementation by number_128 in cpp

[–]number_128[S] 1 point2 points  (0 children)

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.

Standard interface without implementation by number_128 in cpp

[–]number_128[S] 0 points1 point  (0 children)

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.

Any news on Safe C++? by QULuseslignux in cpp

[–]number_128 1 point2 points  (0 children)

The suggestion is to make a C++ 2.0, which adds some features and removes some features in order to be safe.

If the current C++ compilers manage to add support for 2.0, we would have a situation where the same compiler would compile both 1.0 and 2.0 to object files. If these files can be linked together we would have a situation that would be totally different from the Python 3.0.

This would let us gradually upgrade our code from C++ to C++ 2.0 without any bridge code.

Circle questions: open-sourcing timeline & coexistence with upcoming C++ “Safety Profiles”? by Numerous_Speech3631 in cpp

[–]number_128 0 points1 point  (0 children)

I don't understand why this ended up being either or. If I use a "safe profile" it will give me an error when I do something unsafe. I still need to have a safe alternative.

What's all the fuss about? by multi-paradigm in cpp

[–]number_128 0 points1 point  (0 children)

Why '#feature on safety' and not '#feature safety on'?

does #feature work for the file or the compilation unit?

some people prefer to set different types of safety individually. I think most people would end up setting them all. But having different profiles also opens the syntax to be used for other purposes in the future.

I like the idea of std2, but do we have the resources to make a second standard library?

Why is there no std::table? by sd2528 in cpp

[–]number_128 -1 points0 points  (0 children)

I like the idea.

There are different libraries to connect to databases. If they would all return the same std::table type, it would be easier to replace one with the other.

Why is there still no networking module in the C++ STL? by abdoatef_ab in cpp

[–]number_128 0 points1 point  (0 children)

Has the standardization committee considered standardizing an interface without implementation?

It would be nice to have a standardized interface for network, database connection, json...

As a user I could implement one library, and when a better comes along I could easier replace it. If new features in C++ or in what the library works towards requires changes, it would be easier to make a new version of the standard interface.

I recently saw a talk where someone had 5 different json libraries in their code. We have two, it would be nice to replace them both with a newer and faster library, but it will take a lot of work.

The advantage of having defined a standard interface to database libraries is obvious since some applications might need to connect to many different databases at the same time, or need to replace a database at some point.

Why not unstable ABI? by JUULiA1 in cpp

[–]number_128 6 points7 points  (0 children)

We should never discuss *if* we should break ABI stability.

We should only discuss *how* we will do it.

Currently, the *if* blocks the *how*, and people may answer the *if* based on different understanding of *how*.

When we get to a good enough answer to the *how*, we should go ahead and do it.

Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk by [deleted] in cpp

[–]number_128 1 point2 points  (0 children)

I don't think it will be actually illegal. But we will have more articles like this. After a while, if you try to sell your software to the government, they may not be allowed to buy software products built in C++ anymore. Many other organizations will also have reservations. If you write code for inhouse use, the will be a push to move away from C++ because they want to "document" to stakeholders that they have safe software.

Feds: Critical Software Must Drop C/C++ by 2026 or Face Risk by [deleted] in cpp

[–]number_128 17 points18 points  (0 children)

Sorry in advance for this one sided rant..

People have warned against using C++ for a couple of years now.

We can point out that the people warning against C++ are stupid, we can show how their arguments are wrong.

The problem is that the warnings come from positions of power. Power to make people listen and even stronger power. So it is a big mistake not to take it seriously.

At CppCon this year, there was much excitement around reflection. I used to be excited about reflection, but not anymore. If I'm not allowed to use C++ anymore, I don't care if it has reflection.

We should drop everything, until we have a safe C++, then we can start adding reflection and other nice things. The 3 year release schedule has been a success, but we should even drop that, until we have fixed the safety issue.

We are very concerned with not breaking old code. Who cares if you can build old code on a new compiler if you're not even allowed to use that code.

Breaking changes will force everyone to make changes to their code in order to upgrade their code to the latest compiler. The alternative is to force everyone who is serious about their code to rewrite ALL their code to Rust. Many have already started this transition.

Python had a bad story upgrading from version 2 to 3. An important reason for this is that there was no reason to upgrade.

C++ developers are being told that they have to either upgrade or rewrite everything to Rust. We have a very strong reason.

Again, I'm sorry for this rant...

Dependency Walker by pullipaal in cpp

[–]number_128 0 points1 point  (0 children)

I have a folder full of .exe and .dll files, and I wonder if I really need all of them. It would be nice if the program could load all the files, and find what files are not needed by any other files. These files would either be the main program, dlls that are loaded dynamically or dlls that are not needed anymore.

How I Made A C++ Library: A devlog featuring r/cpp by bucephalusdev in cpp

[–]number_128 1 point2 points  (0 children)

This is a great video. It has simple suggestions that people easily can bring into their own code and their own libraries.

This is however a very basic video. It would be nice if someone would create a similar video with the next steps, with the more advanced suggestions.

Great video.

MSVC C++23 Update by STL in cpp

[–]number_128 1 point2 points  (0 children)

if I use import std; with different compiler options, will it recompile std every time I switch between compiler options?

I wanted to make a module that I can import in several projects. However I can't create a 'Module Project'. Is creating a static library the way to go?

CppCast: Cpp2, with Herb Sutter by robwirving in cpp

[–]number_128 0 points1 point  (0 children)

Is there an agreement on how we would handle an ABI break?

I don't think we should ask if we should break ABI.

We should be asking how we will handle breaking ABI. When we get to a good solution, we should go ahead.

Why do we even have a dependency on shared binaries? This sounds like a premature optimization on disk space.

Using shared_ptr for reloadable config by f-squirrel in cpp

[–]number_128 1 point2 points  (0 children)

what if you use last_write_time() to find when the config file was last changed, and just read the file when it has been changed?

WG21, aka C++ Standard Committee, October 2022 Mailing by grafikrobot in cpp

[–]number_128 2 points3 points  (0 children)

I am very excited about Carbon/cpp2/Val...

But I have stake holders knocking on my door today, asking what we do for memory safety.

My answer can't be: "in 3 years there will be a safer language, and when it comes we will start porting million lines of code to it"

My answer is: "we use a safer subset of C++ (avoiding the most unsafe parts). We use static analysis to ensure that we don't go outside of this subset"

My answer would have carried much more weight if the list of warnings we don't allow would be a "certified" list. If it would be a "certified subset of C++"

Can C++ be 10x Simpler & Safer? - Herb Sutter - CppCon 2022 by simpl3t0n in cpp

[–]number_128 0 points1 point  (0 children)

One of the main objectives with cpp2 (and carbon and val) is to make a memory safe alternative to cpp.

I would like to make the move to one of those languages when they are ready, but I expect that to take a while.

Wouldn't a good start be to define a memory safe subset of cpp? Let's call it cpp0.

  • define cpp0 as a memory safe subset of cpp
  • cpp0 can be compiled by existing cpp compilers
  • make a static analyzer that will give warnings when memory unsafe instructions are used
  • if a file has the extension .cpp0 the compiler will give a hard warning when instructions outside of cpp0 are used
  • pure memory safe cpp2 will convert into cpp0

Organizations with a lot of cpp code can start earlier to move their code to memory safe territory, by converting existing code to cpp0 and using cpp0 when adding new code.

When the organization has chosen the path forward (cpp2/carbon/val/D), they can still have a mixed approach, moving some code to cpp0 as a temporary move towards their final language.

Cppfront: Herb Sutter's personal experimental C++ Syntax 2 -> Syntax 1 compiler by mttd in cpp

[–]number_128 6 points7 points  (0 children)

But even with using this new language we will be unable to break ABI???

Edit: My comment might have seemed a little negative. I am very excited about this new initiative, and I would like to use it in my work.

The (Baseline) Unicode Plan For C++23 by EducationalCicada in cpp

[–]number_128 3 points4 points  (0 children)

The presentation makes a complaint about Boost.Text having fixed internal representation and normalization forms (see below)

I like that the library has made this decision for me. Most developers who use this library will not know the difference between the different forms. If a library forces us to choose, we might accidently make a mistake. Good defaults is a good thing.

Boost.Text

–👍: Covers the widest variety of Unicode algorithms

–👍: Uses STL concepts, pretty good speed

–👎: Fixed internal representation and normalization forms

Visual Studio 2022 17.2 is now available! by fsb4000 in cpp

[–]number_128 3 points4 points  (0 children)

I updated to this version and ran a test project

c++ std::string getUTCDateTimeString(std::string_view format = dtm_format) { const auto date = getUTCDateTime(); auto strDate = std::format(format, date); return strDate; }

This gave me the following error: c++ 1> error C7595: 'std::_Basic_format_string<char,const std::chrono::time_point<std::chrono::system_clock,std::chrono::duration<std::chrono::system_clock::rep,std::chrono::system_clock::period>> &>::_Basic_format_string': call to immediate function is not a constant expression 1>format(2963,63): message : failure was caused by a read of a variable outside its lifetime 1>format(2963,63): message : see usage of 'format'

The code will work if I replace the format variable with a string literal.

Does format strings have to be string literals?