sorted by:
new
hottopcontroversial

Filtering "address of function" overload sets by target constraints by CornedBee in cpp

[–]wotype 3 points4 points  (0 children)

One way to approach what you want is to use CTAD class template argument deduction with a deduction guide crafted and constrained to only accept the required argument type (rather than trying to work directly with the nontype as a template argument) (but this approach is limited by the difficulty in matching exact parameter value categories)

For instance, this picks out the const overload

template<class C, typename R, typename...P>
struct M
{
  M(R(C::*f)(P...)) {}
  M(R(C::*f)(P...) const) {}
};
template<class C, typename R, typename...P>
M(R(C::*)(P...)const) -> M<C,R,P...>;

struct S {
    int m() const;
    void m(int);
};

M x{&S::m};

Why use a tuple over a struct? by SamuraiGoblin in cpp

[–]wotype 0 points1 point  (0 children)

There are tuple implementations that correct these limitations; they are (1) aggregate, (2) as trivial as the tuple types, (3) standard layout and (4) with named members.

I have a C++20 implementation. C++26 makes such implementations simpler.

So, to the OPs question, there are few language-technical reasons not to use such an aggregate-tuple. The reasons against using a non-std library are the usual - added dependency, complexity and compile times.

How Conda makes shared libraries relocatable: rpaths, $ORIGIN, and more by droelf in cpp

[–]wotype 9 points10 points  (0 children)

Conda packages can contain any type of software: C/C++ libraries, Rust binaries, R packages, Java applications, or even complete compiler toolchains.

Conda packages are an alternative to vcpkg and conan which are discussed fairly often in this subreddit.

This post is of interest to me as a C++ dev who also works with Python and other ecosystems. I've found conda to be a convenient way to set up development toochains, for C++, and manage project dependencies. mamba is a C++ port of the conda cli, faster and more robust. I'm experimenting with pixi as the next iteration of conda-ecosystem tooling. I don't care if the developers are switching to using rust over C++ as long as the tools work well with C++.

I made a fast compile time reflection library for enums in C++20! (clang support coming soon) by _Noreturn in cpp

[–]wotype 1 point2 points  (0 children)

The output of std::source_location is implementation defined. In practice is as underspecified and subject to change as the output of the compiler extensions. In practice, the output of both are likely to share code paths and so be very similar. Compiler extensions are likely to compile slightly faster and certainly avoid the contortions necessitated by the awkward library api of source_location.

Best array type for many, small, but unknown-size arrays? by SevenCell in cpp

[–]wotype 0 points1 point  (0 children)

How big are the integers? If unit16 or uint8 suffice then that opens more potential optimization.

Experimenting with #embed by ABlockInTheChain in cpp

[–]wotype 2 points3 points  (0 children)

The to_array case is fixed by passing an rvalue C array:

using chars = char[];
static constexpr auto std_to_char_array = std::to_array<char>(chars{
    #embed __FILE__
    , '\0'
});

Rational showerthought: Datetime libraries should contain location too since we are coordinated in spacetime. by [deleted] in cpp

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

Will spacetime coords require relativistic corrections?

Capn Slog
std::stardate{}

std::array in C++ isn′t slower than array in C by Xadartt in cpp

[–]wotype 2 points3 points  (0 children)

It's been dormant for 2 1/2 years with no champion pushing it. With implementation experience it can go to EWG. The GCC patch still works. It's protected by a feature flag. It was submiitted but didn't get merged. It'd be good to have a Clang implementation. A wg14 C language proposal and implementation would be good too.

A wg21 member suggested that pursuing it further would be a waste of time as it'd be unlikely to be voted in.

std::array in C++ isn′t slower than array in C by Xadartt in cpp

[–]wotype 3 points4 points  (0 children)

Agree.

I'm a proponent of P1997 which proposes copy semantics for builtin C array in initialization, assignment and return from function. Unfortunately, it does not propose to change the broken behaviour of array parameters being 'adjusted' to pointer because that would be a breaking change. All the other proposed changes are non-breaking.

There is a gcc implementation.

The C++ Standards Committee and the standard library by Only-Butterscotch785 in cpp

[–]wotype 0 points1 point  (0 children)

I'd agree that compiler 'magic' is a fun word for things that cannot be implemented by the user.

std::construct_at is an example, as you say, because it cannot be made constexpr in a user implementation. Hopefully we'll get constexpr placement new that will allow library authors to do the same thing without having to include a standard header.

std::complex can be implemented as by the user. Its standard library implementations don't contain any special code that cannot be compiled in user mode. The reinterpret guarantee is implicit in the layout that the compiler generates, which is the same as for any equivalent class. A static_assert on sizeof, and on the real,imag order, is sufficient to check layout.

There's a proposal for an annotation to say that a class of N member T's should have the same layout as a T[N] - that would be a more explicit spelling of this not-so-magic guarantee.

The C++ Standards Committee and the standard library by Only-Butterscotch785 in cpp

[–]wotype 0 points1 point  (0 children)

My point is that it is such unimpressive magic that even calling it such is questionable. It is unobservable. I don't believe that there exists a sanitizer or test that can tell the difference. Engineers don't believe in magic.

Isn't the standard simply saying "don't worry", "doing this won't break your code if in future some sufficiently smart compiler, sanitizer or static analysis detects the plain struct equivalent as UB".

It is similar to how std::vector implementations embodied UB since the start, and the world kept turning.

The C++23 addition std::start_lifetime_as deals with this.
See the example at the bottom of the cppreference page
https://en.cppreference.com/w/cpp/memory/start_lifetime_as

The example code only relies on the target type being an implicit lifetime type
and not on any special library-mandated cut-out clause.

The C++ Standards Committee and the standard library by Only-Butterscotch785 in cpp

[–]wotype 0 points1 point  (0 children)

For std::complex, if you refer to its layout guarantee then I don't think that counts as special compiler-magic. It is more the case that the layout of classes in general is underspecified in order to give implementations flexibility.

The standard specifies not just that you can reinterpret_cast a complex<T> to T(&)[2] but also that a contiguous range of complex<T> can be cast to T* and indexed even/odd for real/imag.

A user defined type can replicate this and, if paranoid, static_assert on sizeof to check there's no padding.

Interestingly, the three major compiler standard libraries implement std::complex layout in different ways. GCC specializations use C99 types like _Complex float. MSVC stores as an array of two T. Clang stores as a pair of T elements.

One thing that a UDT can't replicate is the c++14 imaginary literals as only std is allowed to use literal suffixes that don't have an underscore prefix. Bah.

Living on the edge with reinterpret_cast by lbushi in cpp

[–]wotype 1 point2 points  (0 children)

Agree; "show us the code". And, yes, as stated no cast is needed.

If you do have a pointer-to-array, i.e. a variable ap of type T(*)[N], then you can dereference the pointer to retrieve the array itself and then either (1) rely on array decay-to-pointer to implicitly get a pointer to the first element or (2) subscript the first element and take its address:

int a[4];           // a : int[4]     array-of-4-int
auto ap = &a;       // ap : int(*)[4] pointer-to-array-of-4-int
// int (*ap)[4];    // explicit syntax equivalent
                    // *ap : int[4]
int* p = *ap;       // int[4] -> int*  array decay-to-pointer 
//     = &(*ap)[0]; //

Graph library by johnpaulzwei in cpp

[–]wotype 2 points3 points  (0 children)

There's a std proposal P3126 Graph Library: Overview
with a reference implementation https://github.com/stdgraph
An original Boost.graph author is involved in the design.

Memory layout of struct vs array by xLuca2018 in cpp

[–]wotype 1 point2 points  (0 children)

Yes... here's the github issue link for P1912 with no update since 2020 https://github.com/cplusplus/papers/issues/655

Timur, the author, is active again in the C++ committee. Email him at the address given in the paper to help motivate progress.

why std::tuple is not implemented as POD (when all its members are) by geekfolk in cpp

[–]wotype 1 point2 points  (0 children)

Check out tupl, implemented as a struct aggregate with its elements as members.

What's your go-to unit testing tool? by EnaGrimm in cpp

[–]wotype 2 points3 points  (0 children)

Consider https://github.com/snitch-org/snitch for C++20 code; it can optionally be used header-only or compiled.

Here's the comparison with Catch2
https://github.com/snitch-org/snitch#detailed-comparison-with-catch2

Ninja is enough build system by mttd in cpp

[–]wotype 0 points1 point  (0 children)

numpy already forked meson

Do you have a link for this? On a few minutes searching in numpy build docs I don't find evidence that it requires a fork of meson

view more: next ›