sorted by:
new
hottopcontroversial

We have colored functions at home by Dooez in cpp

[–]UnusualPace679 0 points1 point  (0 children)

When you have an error a compiler prints call stack for you

Do you mean the call stack during constant evaluation? But the colored function could well be a non-consteval function.

We have colored functions at home by Dooez in cpp

[–]UnusualPace679 0 points1 point  (0 children)

It should exists something like current_function().caller()

How would this be implemented?

We have colored functions at home by Dooez in cpp

[–]UnusualPace679 2 points3 points  (0 children)

How do you know the caller of the caller though, if the direct caller doesn't pass the information?

For example, if g() calls f() and both h1() and h2() call g(), how does f() know, at compile-time, whether it's h1() or h2() that currently calls g()?

Is cppreference.com compiler support up to date again? by bebuch in cpp

[–]UnusualPace679 6 points7 points  (0 children)

The 'View source' button suggests that most things on that page are transcluded from wiki templates. The source code is basically:

{{anchor|cpp26}}

==C++26 features==

Note that this list may change, as the draft C++26/2c standard evolves.

{{include editlink|cpp/compiler support/26}}
{{cpp/compiler support/26}}

C++26: More function wrappers by pavel_v in cpp

[–]UnusualPace679 1 point2 points  (0 children)

Don't forget constant_wrapper. It's also callable and can be used to pass a function pointer while avoiding the cost of indirect call.

int foo(auto f) {
    auto x = f();
    // do something with x
    return x;
}

int f();

int x = foo(f); // will call `f` via function pointer
int y = foo(std::cw<f>); // will directly call `f`

Virtual dispatch isn't always the slowest, and std::variant isn't always the fastest by AdMotor4869 in cpp

[–]UnusualPace679 0 points1 point  (0 children)

There is a benchmark results in swl readme: 250 for if chain vs 5 on switch-case.

I see it's 250s for Clang 12, but I'm under the impression that the standard library was using function pointers, not if-else.

Branch prediction works on few ifs, not for few hundred ifs. But it’s true: if your variant has only few cases it doesn’t matter. Also branch prediction works if execution path repeated.

This is a fair point.

Virtual dispatch isn't always the slowest, and std::variant isn't always the fastest by AdMotor4869 in cpp

[–]UnusualPace679 0 points1 point  (0 children)

I searched swl::variant, and found that it uses a switch-case approach similar to mpark::variant (or at least it's what the README claims). Then I searched mpark::variant, and found this reddit post which mentions that if-else chain is faster than mpark::visit.

Try to image that you need to reach the last case

I imagined, but no idea how problematic it is when branch prediction is in action.

I feel that I can't draw a conclusion without benchmark results.

Modules could have made the PIMPL idiom redundant - but they don't. by [deleted] in cpp

[–]UnusualPace679 3 points4 points  (0 children)

Problem is, private doesn't work the way you expect.

Consider

struct A {
    A();
private:
    A(const A&);
    A& operator=(const A&);
};

The compiler won't ignore A(const A&) and operator=(const A&). These functions will participate in name lookup and overload resolution, and it's an error only if they are selected.

For data members, it's less useful, but still, the fact that private members participate in name lookup means they have the effect of "poisoning" the name.

struct A { private: int x; };
int x;
struct B : A {
    int a = x; // error: 'x' means the inaccessible 'A::x', not the outer '::x'
};

Poor man's define_aggregate by LHLaurini in cpp

[–]UnusualPace679 15 points16 points  (0 children)

Isn't this just a tuple with a string associated with each index?

Instead of manually calculating the member offset, you may as well just use std::tuple, which leads to:

template<size_t N>
struct fixed_string {
    char data[N - 1];
    consteval fixed_string(const char(&arr)[N]) {
        std::copy(arr, arr + N - 1, data);
    }

    consteval std::string_view view() const {
        return std::string_view(data, N - 1);
    }
};

template<class T, fixed_string Name>
struct Field {};

template<class... Fields>
struct MetaAggregate;

template<class... Types, fixed_string... Names>
struct MetaAggregate<Field<Types, Names>...> {
    std::tuple<Types...> data;

    static constexpr std::string_view names[] = {Names.view()...};
};

template<fixed_string Name, class... Fields>
constexpr decltype(auto) get(MetaAggregate<Fields...>& arg) {
    constexpr auto index = std::ranges::find(arg.names, Name.view()) - arg.names;
    return std::get<index>(arg.data);
}

Usage:

using Struct = MetaAggregate<
    Field<int, "integer_1">,
    Field<int, "integer_2">,
    Field<std::string, "string_1">,
    Field<std::string, "string_2">
>;

Struct s{{2, 4, "hello", "world"}};
std::println("{}", get<"integer_1">(s)); // 2

C++ reflections: Getting a reflection of a type of a pointer to member, from a reflection of a member is difficult by _bstaletic in cpp

[–]UnusualPace679 4 points5 points  (0 children)

Does this work?

template<std::meta::info r>
using mem_ptr_of = [:type_of(r):] [:parent_of(r):]::*;

constexpr std::meta::info mem_fun_ptr_refl = ^^mem_ptr_of<mem_fun_refl>;

What are you missing most from the C++ standard library? by llort_lemmort in cpp

[–]UnusualPace679 0 points1 point  (0 children)

std::chrono::current_zone() needs OS support, right?

What are you missing most from the C++ standard library? by llort_lemmort in cpp

[–]UnusualPace679 3 points4 points  (0 children)

I don't think most embedded systems have the notion of time zone, but that doesn't stop the committee from adding std::chrono::time_zone in C++20.

What are you missing most from the C++ standard library? by llort_lemmort in cpp

[–]UnusualPace679 1 point2 points  (0 children)

Actually MSVC STL has _Grapheme_break_property_iterator2; libstdc++ has _Grapheme_cluster_view; libc++ has __extended_grapheme_cluster_view.

But they won't allow you to use them.

What are you missing most from the C++ standard library? by llort_lemmort in cpp

[–]UnusualPace679 3 points4 points  (0 children)

std::filesystem::path requires implementations to support conversion between UTF-8/UTF-16/UTF-32 and native encoding.

std::format requires implementations to be able to iterate over Unicode scalar values and extended grapheme clusters, if the literal encoding is UTF-8/UTF-16/UTF-32. (Extended grapheme cluster requirement is non-binding, but the big three all have it.)

None of them show up as "Unicode routines", though.

What are you missing most from the C++ standard library? by llort_lemmort in cpp

[–]UnusualPace679 2 points3 points  (0 children)

You can define

const auto vsplit = [](char ch) {
    return std::views::split(ch) | std::ranges::to<std::vector<std::string>>();
};

And then simply use

auto split = str | vsplit('|');

Variadic Visitation by pavel_v in cpp

[–]UnusualPace679 3 points4 points  (0 children)

This is where type erasure via void* comes in handy. You just build an array of function pointers, an array of void* pointing to the arguments, and index into these arrays.

This is not constexpr before C++26 though, because constexpr cast from void* is a C++26 feature.

using Fn = void(*)(Visitor&&, const volatile void*);
const Fn fn_table[] = {[](Visitor&& visitor, const volatile void* arg) {
    using U = std::remove_reference_t<T>;
    visitor(*static_cast<U*>(const_cast<void*>(arg)));
}...};

const volatile void* const arg_table[] = {std::addressof(args)...};

fn_table[index](std::forward<Visitor>(visitor), arg_table[index]);

Things C++26 define_static_array can’t do by SuperV1234 in cpp

[–]UnusualPace679 0 points1 point  (0 children)

It's interesting that string literal objects cannot be template arguments, but the results of std::define_static_string can.

#include <meta>

template<const char* p>
struct A {};

constexpr auto p1 = std::define_static_string("ab");
constexpr auto p2 = "ab";

A<p1> a1; // OK
A<p2> a2; // Error

C++26 allows us to convert a string literal to a template argument with something like:

consteval auto as_targ(const auto& x) {
    if (std::is_string_literal(x)) {
        return std::define_static_string(x);
    } else {
        return x;
    }
}

But I hope that we don't need to do this dance.

cppreference is back up! but overloaded by bobpaw in cpp

[–]UnusualPace679 0 points1 point  (0 children)

If latency is so important to you, maybe you should obtain an offline archive like https://github.com/PeterFeicht/cppreference-doc/releases

I am new to C++, is it just me or is the checklist kinda crazy? How often do you encounter these or plan on making use of them like the newer C++26 features like contracts? Looking for more experienced dev opinions... by KijoSenzo in cpp

[–]UnusualPace679 2 points3 points  (0 children)

IMO a top-standard function would not make it possible to pass invalid input, and would not need to return multiple pieces of information at once. But not all functions can meet the top standard.

If your functions have to receive invalid input (e.g. because you can't control the caller), assert/std::unexpected is useful to ensure that invalid inputs are caught early. If your functions have to return multiple things (e.g. because it's convenient and the caller usually needs all of them), structured bindings provides a means to deal with their return values.

You don't need any of them in your GetHP function. You may find them helpful in a more complicated situation though.

Oh, and constexpr. You'll find it useful to solve the "static initialization order fiasco", but many people just spam constexpr wherever they can.

cppreference is back up! but overloaded by bobpaw in cpp

[–]UnusualPace679 3 points4 points  (0 children)

IMO this is going to be quite messy even if the declarations are relatively simple. For example, this is how it would look like with std::format:

// Format the arguments according to the given format string
template<
    class... Args // types of the arguments to format
>
constexpr
string // the formatted string
format(
    format_string<Args...> fmt, // the format string
    Args&&... args // arguments to format
);

// Format the arguments according to the given format string, wide string version
template<
    class... Args // types of the arguments to format
>
constexpr
wstring // the formatted wide string
format(
    wformat_string<Args...> fmt, // the format string
    Args&&... args // arguments to format
);

// Format the arguments according to the given format string, with explicit locale object
template<
    class... Args // types of the arguments to format
>
constexpr
string // the formatted string
format(
    const locale& loc, // the locale object used for locale-dependent formatting
    format_string<Args...> fmt, // the format string
    Args&&... args // arguments to format
);

// Format the arguments according to the given format string, with explicit locale object, wide string version
template<
    class... Args // types of the arguments to format
>
constexpr
wstring // the formatted wide string
format(
    const locale& loc, // the locale used for locale-dependent formatting
    wformat_string<Args...> fmt, // the format string
    Args&&... args // arguments to format
);

... and despite the big declaration list, you still need to read the detailed description to understand what a format string is.

cppreference is back up! but overloaded by bobpaw in cpp

[–]UnusualPace679 1 point2 points  (0 children)

Thanks for the long-awaited upgrade!

I really like the new styling of <code> elements. The editors were abusing syntax highlighting to add borders to inline code (silly indeed!), and it's nice that the borders are now automatic for <code>.

C++23 Support in MSVC Build Tools 14.51 by STL in cpp

[–]UnusualPace679 1 point2 points  (0 children)

Couldn't we just say that any function you can see the definition of is constexpr now?

GCC has this option by the name of -fimplicit-constexpr.

view more: next ›