Press J to jump to the feed. Press question mark to learn the rest of the keyboard shortcuts

Found the internet!

Create an account to follow your favorite communities and start taking part in conversations.

C++

r/cpp

38

pinned by moderators

Posted by

MSVC STL Dev

2 months ago

C++ Jobs - Q1 2023

38

59 comments

18

Posted by26 days ago

C++ Show and Tell - February 2023

18

24 comments

59

Posted by

Robotics Software

11 hours ago

What do you think of when you hear “modern” C++?

I basically only write C++17. I often hear people refer to “modern” C++ as a superior way to write C++ but don’t really know what this means anymore since it’s tossed around so frequently.

59

83 comments

71

Posted by20 hours ago

std::format, UTF-8-literals and Unicode escape sequence is a mess

I'm in the process of updating my old bad code to C++20, and I just noticed that std::format does not support u8string... Furthermore, it's even worse than I thought after doing some research on char8_t.

My problem can be best shown in the following code snippet:

ImGui::Text(reinterpret_cast<const char*>(u8"Glyph test '\ue000'"));

I'm using Dear ImGui in an OpenGL-application (I'm porting old D-code to C++; by old I mean, 18 years old. D already had phantastic UTF-8 support out of the box back then). I wanted to add custom glyph icons (as seen in Paradox-like and Civilization-like games) to my text and I found that I could not use the above escape sequence \ue0000 in a normal char[]. I had to use an u8-literal, and I had to use that cast. Now you could say that it's the responsibility of the ImGui-developers to support C++ UTF-8-strings, but not even std::format or std::vformat support those. I'm now looking at fmtlib, but I'm not sure if it really supports those literals (there's at least one test for it).

From what I've read, C++23 might possibly mitigate above problem, but will std::format also support u8? I've not seen any indication so far. I've rather seen the common advice to not use u8.

EDIT: My specific problem is that 0xE000 is in the private use area of unicode and those code points only work in a u8-literal and not in a normal char-array.

71

95 comments

12

Posted by11 hours ago

Looking at the syntax of various cross-platform build system for C++

I was contemplating switching to a different build system for my pet projects, so I ended up spending the whole day researching what build systems exist and what their build declaration files look like. I compiled the results into a blog post.

Note that this is not about how the systems work, their features etc. Just the syntax. You can see which systems look nice to you, and which ones are so terrible you never want to touch them or hear about them again. Then you can research the nice ones.

https://violetgiraffe.github.io/2023/02/25/cpp-build-systems-syntax-comparison.html

12

19 comments

9

Posted by14 hours ago

Would you consider type decay a form of implicit conversion?

Recently I got into an argument with some people. My point is that type decay (e.g. T[] -> T*) is different than implicit conversion and thus T[] -> T* is not analogous to, say, int -> long, and they disagree. The fact that type decay is an intrinsic rule of C++'s type system (auto will always automatically decay, you'd have to decltype(auto) to prevent decay) already makes it quite different than implicit conversions which are extrinsic to the type system.

I wonder what's your opinion about this. 🤔

9

10 comments

21

Posted by20 hours ago

How to define API stability for a C++ library?

Let's assume that I write a C++ library and I want to use version numbers to indicate breaking API changes (e.g. semantic versioning). What, exactly, is a breaking change in C++? A strict definition would be that if any user code compiles with the old version but not with the new, then the new version contains breaking changes. However, this seems overly strict since it doesn't even allow for adding new functions - if the function foo::bar() is added the following statement will no longer compile:

static_assert(!requires { foo::bar(); });

This is obviously an extreme example since the user code is explicitly checking whether a function exists, but similar things can happen implicitly or accidentally. What I'd like to know is if there are any semi-official guidelines for what constitutes a breaking API change.

Intuitively, I would like things like adding new functions, types, variables, templates, and static class members to be non-breaking unless there are good arguments against it; while changing function signatures, variable types, template signatures, adding non-static class members, and obviously removing anything to be be breaking.

21

12 comments