u/wotype

I'm looking out for this.

Will there also be a version sold with the ergo stand RD280UA -> RD280UGA? Or is the arm available separately?

Inspiring stuff. Well put together with really nice visuals.

Thanks for posting here.

Interesting, thanks for posting

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};

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.

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

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.

Reminds of a snapshot from 2007

https://howardhinnant.github.io/TypeHiearchy.pdf

The docs are very nicely done

https://aurora-opensource.github.io/au/main/

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

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'
});

:thumbsup emoji

Will spacetime coords require relativistic corrections?

Capn Slog
std::stardate{}

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.

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.

wg21.link/P1912
Types with array-like object representations
(Related: GitHub issue)
CWG2182: Pointer arithmetic in array-like containers (2015-10-20)

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.

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.

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.

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]; //

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.

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.

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

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