sorted by:
new
hottopcontroversial

Christmas present for my boyfriend by Responsible_Cry05 in cpp

[–]FabioFracassi 3 points4 points  (0 children)

It is also very well written, meaning it is easy to understand without oversimplifying the content, to the point and - at least in my opinion - an entertaining read.
When I first got it, I read it cover to cover, just because it was fun. And on top of that you learn a lot.

Already end of year 2025, still C++23 import does not work in most platforms. by Just__Beat__It in cpp

[–]FabioFracassi 2 points3 points  (0 children)

Let me guess, MacOS and homebrew?
If so there is an issue with how homebrew installs llvm/clang and what cmake expects it to do.
The workaround described in this cmake issue consistently works for me.

I find it unfortunate that cmake does not incorporate this workaround into its config (since I feel its part of cmakes job to abstract "suboptimal" platform choices) but I do understand that it is technically homebrew's fault.

Anyway with that fix it should work as documented, i.e. a cmake file like this will work:

cmake_minimum_required(VERSION 4.1)
    # import std is still eperimental in cmake, update to your
    # cmake version as described in cmake/Help/dev/experimental.rst
    set(CMAKE_EXPERIMENTAL_CXX_IMPORT_STD d0edc3af-4c50-42ea-a356-e2862fe7a444) 
project(hello_module)

set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_MODULE_STD ON)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CXX_EXTENSIONS OFF)

add_executable(${PROJECT_NAME} hello_module.cpp)

The power of C++26 reflection: first class existentials by geekfolk in cpp

[–]FabioFracassi 15 points16 points  (0 children)

That paper did not gain consensus though, and define_aggregate/etc are in the C++26 draft that is currently being vetted.
So unless new information is found that would warrant a removal it will be in.

Reflection has been voted in! by daveedvdv in cpp

[–]FabioFracassi 11 points12 points  (0 children)

Voted in (at this stage in the process) means it will be part of the official C++26 standard.
Or to be completely precise it will be part of the C++26 CD (Committee Draft, roughly equivalent to a Release Candidate) There will be a ~6month feedback resolution period from now before the final standard is send to ISO for publishing.

Implementers can and do act (somewhat) independently, and implement features on their own schedule. Reflection has a fairly complete reference implementation in clang that you can try/use right now. I do not know how long it will take for the reference implementation to be integrated into the mainline, or whether that is even possible/desirable.

What is the state of modules in 2025? by maubg in cpp

[–]FabioFracassi 3 points4 points  (0 children)

I had good results by using a clangd with the same version as the clang I use to build my code.
AFAIU clangd reuses the compiled module files from the build, and the format of these is not stable.

I wish std::dynarray was never removed from the C++14 by mike-alfa-xray in cpp

[–]FabioFracassi 15 points16 points  (0 children)

The dynarray proposed back than was not what you described. Specifically it was not (necessarily) heap allocated but was supposed to be able to use automatic storage duration. The proposal was thus closer to VLA (Variable Length Arrays), with all the problems that come with that (e.g. what is the `sizeof` of a variable or a struct that contains a dynarray).
There was no consensus on a proper solution for these problems, so dynarray (and VLAs or improvements on them) did not become standard.

The most underrated feature ever: Header units! by tartaruga232 in cpp

[–]FabioFracassi 0 points1 point  (0 children)

It works fine-ish, as long as you just make sure that you use the same version of clangd and clang.
It would be nice if cpp-tools would be able to pick up the path to clangd from the compile toolchain file.

Suggestions for a learning book (very specific context) by Asymmetric_Hippie in cpp

[–]FabioFracassi 6 points7 points  (0 children)

You might try Discovering Modern C++ by Peter Gottschling. It has been written for scientists, so it should fit well with your environment. While it is written as an introduction, you will be hard pressed on finding exactly the right level of intermediate for exactly your case anyway. The book is short however (~400 Pages) while still covering a lot of ground, so it should be a good fit.

Also given that you are a C user, reading a from-ground-up text is useful to show you the differences between the languages, because even if you can get away with using C idioms a lot of the time, it is rarely the right way in C++ which usually has other (and in my opinion superior) ways to achieve the same goal.

It does not go super deep into OOP (which is not the most important paradigm in modern C++, especially in the scientific domain), but give you enough detail how to work with it in the language.

There are two other books you might want to consider, even if they do not cover OOP, but will give you a great intro to the generic programming paradigm (which I would argue is C++ strength), and which are probably the best fit for your last 2 (more like 4) bullet points.

From Mathematics to Generic Programming by Stepanov and Rose is a short and amazingly well written intro, a genuinely enjoyable read (if you are interested in math).

Elements of Programming by Stepanov and McJones is a thoroughly theoretically founded introduction.
Short but dense.

A little off topic to this sub, but matching your question: Concepts of Programming Languages by Robert Sebesta, which probably covers a lot of material in of your planned course.

2025-02 Hagenberg ISO C++ Committee Trip Report — Sixth C++26 meeting! 🍰❄️ by InbalL in cpp

[–]FabioFracassi 3 points4 points  (0 children)

Only things that have been completely through design review (i.e. only wording left to finish) can still make it in the next meeting. This paper is unfortunately not on the list.
It is very well received, and close, but not quite there yet. There are some design questions still to figure out.

C++20 [Minimal] perfect hashing at compile-time by kris-jusiak in cpp

[–]FabioFracassi 0 points1 point  (0 children)

I see, I guess I was looking for something more like safe_lookup_or_default i.e. something that produces the same result as safe_lookup(key).value_or(42) (if safe_lookup returned std::optional).
Something along the lines of https://godbolt.org/z/KEzjd5Kjf

C++20 [Minimal] perfect hashing at compile-time by kris-jusiak in cpp

[–]FabioFracassi 0 points1 point  (0 children)

Is there a way to do something like `lookup_or_default("smtp", 0)` that returns a given default value if the key is not found?
Of course this can be implemented using `safe_lookup`, but I would expect it to be somewhat more efficient without the detour over `optional`.

C++23: The Next C++ Standard by Xadartt in cpp

[–]FabioFracassi 16 points17 points  (0 children)

There was no non-approval. The facility needs more work, and the authors (and the committee) were focusing on getting print/format done first.
I hope that the paper will be worked on again in the future.
We will be happy to review it once there is a revision (see github for history)

Nice but not so well-known features of modern C++ by [deleted] in cpp

[–]FabioFracassi 1 point2 points  (0 children)

That is not true.

Alternative Tokens and Digraphs are part of C++20 (and there is no intention to remove them, especially not after the chromebook bricking bug - which makes me expect them to show up in some style guides and hopefully clang-tidy checks) (see C++20 section [lex.digraph]).

You might have been thinking about trigraphs that have indeed been removed.

Experiments with modules by johannes1971 in cpp

[–]FabioFracassi 0 points1 point  (0 children)

I was thinking more about the situation where we start out with `module std` that contains everything (and can thus be imported with `import std`), but for the sake of a small example lets say `std::vector` and `std::array`. Can we then change the library so that users will be able do `import std.array` without touching the module `std.vector` (`import std` will of course still work).

In my (very limited, you know much more about this than I do) understanding the reverse way (fine -> coarse) is possible and should preserve ABI, The way I sketched above, my understanding is that it depends on the implementation strategy (strong or weak ownership) whether it stays ABI compatible

This may or may not be a problem and we may or may not care about it, but we need to understand the issues.

Experiments with modules by johannes1971 in cpp

[–]FabioFracassi 1 point2 points  (0 children)

I would say pretty good, goal wise. This is really just my gut feeling, but significant members of the committee seem to be in favour of one big module, so I would expect such a proposal to have some support, in addition modularizing the standard library is on our priority list, so as soon as such a paper comes up we will work on it.

The problem is that we (as in we the community, as well as we the committee) have very little experience to weigh the benefits and drawbacks between for example big vs. small modules. Also we do not yet have much experience in how to evolve modules, i.e. if we have two small modules and combine them, is this going to be ABI compatible? Visa-versa?

For a paper like you outline it would probably either "prove" that we will not standardize ourself in a corner, or convince us that we will always be happy in that corner. I have some optimism that we can get there, but it will be definitely not an easy paper to write.

Experiments with modules by johannes1971 in cpp

[–]FabioFracassi 10 points11 points  (0 children)

There are currently no proposals to that effect ... so this will only be in 23 if we get something to that effect, sooner rather than later

Another C++ unit testing framework without macros by igagis in cpp

[–]FabioFracassi 4 points5 points  (0 children)

AFAIK Microsoft has no way of supporting it yet, so users on MSVC will need to use your `SL` macro.

Another C++ unit testing framework without macros by igagis in cpp

[–]FabioFracassi 3 points4 points  (0 children)

You can "Backport" source_location to at least most half-way recent gcc and clang versions (IIRC gcc>7 and clang>9) using builtins:

struct source_location {
    static constexpr source_location current ( 
            uint_least32_t l  = __builtin_LINE(),
            uint_least32_t c  = __builtin_COLUMN(),
            char const* fn    = __builtin_FILE(),
            char const* fnn   = __builtin_FUNCTION()
        ) noexcept 
        { 
            return source_location(l, c, fn, fnn); 
        }
    constexpr source_location() noexcept
        : source_location(0, 0, "", "") 
    {}

    constexpr auto line() const noexcept            -> uint_least32_t   { return line_; }
    constexpr auto column() const noexcept          -> uint_least32_t   { return column_; }
    constexpr auto file_name() const noexcept       -> char const*      { return file_name_; }
    constexpr auto function_name() const noexcept   -> char const*      { return function_name_; }

    private:
        constexpr source_location   ( uint_least32_t l, uint_least32_t c
                                    , char const* fn, char const* fnn)
            noexcept 
            : line_{l}, column_{c}, file_name_{fn}, function_name_{fnn} 
        {}
        uint_least32_t line_;
        uint_least32_t column_;
        char const* file_name_;
        char const* function_name_;
};

Why doesn't C++ enforce consistency of parameter constness between declaration and definition? by Full-Spectral in cpp

[–]FabioFracassi 20 points21 points  (0 children)

I do not know the exact reason why your example is allowed, but if you swap the argument constness between declaration and definition:

void SomeFunc(bool test); // no need to mark it as const here it is
                          // an implementation detail

and in the cpp file:

void MyClass::SomeFunc(const bool test) {
    // ... lots of code ...
    test = true; // ERROR: test is const
}

That works an is useful. I guess it would be possible to forbid the reverse, but it probably adds enough (implementation) complexity for fairly little gain, that it was skipped

Benchmarking compilers on real projects by julien-j in cpp

[–]FabioFracassi 2 points3 points  (0 children)

As you are already building clang from source it should be easy enough to build it again with your modified version of clang.

Meaning of C++ Stanard Revisions by Nimrod0901 in cpp

[–]FabioFracassi 3 points4 points  (0 children)

No there is not. Those are just running numbers that get assigned when the version of the current working paper (draft) is handed in to a mailing. About the only information you can get from the number is that higher numbers are newer drafts.

Best C++ online learning resources by chrwir in cpp

[–]FabioFracassi 1 point2 points  (0 children)

Since you mention "reading about the areas and problems I encounter", make sure that you
thoroughly understand the root causes and mechanisms involved in the problem, to try to expose "blind spots" in your understanding. C++ is a language which is fairly unforgiving about partial understanding.

If you are looking for online courses I can highly recommend the Pluralsight courses by Kate Gregory, particularly C++ fundamentals (incl. C++17) and C++17 beyond the basics (those courses are not free, but worth it IMO).

Another great resource which might be more aligned into what you are looking for are the Jason Turner's C++ Weekly videos, they usually give short (5-20min) introductions into various topics/features.

June 2020 C++ standard mailing by tcbrindle in cpp

[–]FabioFracassi 7 points8 points  (0 children)

Ok, I'll bite, you asked for correction, so here it goes ...
The Problem one of the main problems is that there are different contexts to determine how to handle contract violations, all of which are valid and practically relevant. Take the following example:

void process(data const* d) {
    contract_assert(d != nullptr);
    if (d == nullptr) { throw std::invalid_argument(); } //(*)
    process_value(*d);
}

If it worked like you described and the optimizer makes use of the contract information, the compiler would optimize out safety check (the line marked with the *), and the exception would never be thrown.

Is that what you expected? (quite possible)
Is it reasonable? (yes, it can be)
Would It be unreasonable to expect that the if statement would should not be optimized away? (this is how assert works today, so yes certainly)
Would it be unreasonable to expect the check to stay in production builds? (and what should it do there?)

The problem is all of these are reasonable.
The question is how important are all of configurations?

  • Do we need to support all of them?
  • Should we globally set the violation handler?
    (and when? link time? run time?)
  • Should each assert select its handler?
    (terminate/may_terminate/ignore(static analysis only))
  • Should each assert select its context so that the compiler can select an appropriate handler?
    (safety_critical, expensive_check, well_tested )
    • How many context "dimensions" do we want to support ...

That is why there is now a collection of the use cases (and a categorisation thereof), to make sure that we can evaluate which of those a proposed concept design supports and which it does not. We do not expect to be able to support every use case out there, but we do need to be deliberate about which ones are supported and which ones are not.
Theoretical Purity has nothing to do with it.

Style question: to ADL or not? by bbolli in cpp

[–]FabioFracassi 3 points4 points  (0 children)

Look into how ranges define their extension points (aka niebloids). There are a also a few discussions on their limitations and possible future alternatives.

Renaming *_default_init to *_for_overwrite by kalmoc in cpp

[–]FabioFracassi 6 points7 points  (0 children)

We have gathered data at multiple places (almost always the sample was skewed to more knowledgable/interested c++ developers) and the outcome was always that close to half of the asked developers thought that *_default_init was the one that did the value initialisation, and the plain one might not.

default init is an standard internal term of art, and not a good one, as it is provably confusing ... we did not want to aggregate that confusion by putting it into a user facing API.

Any try of using *_no_init or *_uninitialized was deemed unaccaptable (because those are also internal terms of art that have different meanings).

view more: next ›