Итак вы программист на высокоуровневых языках: Python, Java, C++ (прости господи)... И вот однажды вам, по долгу службы, выпадает необходимость взять и написать код на C/C++ с использованием прекрасной чистой C библиотеки... мы будем ее звать X.
В этой замечательной библиотеке есть функция
struct power_management_ctx_t; // opaque struct
При работе над разными числодробилками, анализирующими последовательности, применяющими фильтры к картинкам, cчитающим свертки и проч, периодически возникает необходимость преобразовать массив целых чисел в массив чисел с плавающей точкой и наоборот.
На C++ это может выглядеть так
std::vector<float> to_floats(std::vector<int> input) {
std::vector<float> result(input.size());
std::transform(begin(input), end(input), begin(result), [](int x) -> float { return x; });
| #include <memory> | |
| #include <type_traits> | |
| #include <concepts> | |
| #include <span> | |
| #include <functional> | |
| #include <iostream> | |
| struct Context { | |
| std::string_view body; | |
| std::string_view headers; |
| #pragma once | |
| #include <type_traits> | |
| namespace cxxconcept17 { | |
| namespace detail { | |
| enum class RequiredE { kRequired = 0 }; | |
| } |
в предыдущей серии мы изобретали CRTP. А в этой серии мы вернемся обратно к тому с чего начинали и изобретем удивительно прекрасную синтаксическую конструкцию, сравнимую по красоте с концептами.
Пусть наша задача написать свой собственный std::bit_cast. C++20, конечно, вышел, но до продакшена везде и повсюду ему далеко, так что такая задача вполне может быть.
bit_cast позволяет посмотреть на значение одного типа, как будто бы это значение совершенно другого типа. Как reinterpret_cast, только без нарушения strict aliasing rule и провоцирования UB.
В простейшем и очень не правильном виде, bit_cast реализуется так:
- А можно нам lifetime checker?
- У нас есть lifetime checker дома
Lifetime checker дома:
Собственно, этому и посвящена данная заметка. В C++, начиная с 11 стандарта, есть механизмы, позволяющие немного снизить вероятность влететь в проблему с обращением по ссылкам к уже мертвым объектам
В предыдущей серии мы изобретали нечто, называемое XXX_traits, где под XXX скрывается какой-то концепт. А сам трейт описывает, какие операции доступны для типов, реализующих данный концепт. И все взаимодействие с шаблонными параметрами происходило с помощью вспомогательной структуры.
template <class T, class S>
auto accumulate(const std::vector<T>& arr, S&& op)
-> RESULT<T>::REQUIRES<SummatorTraits<S>::value> {
using STraits = SummatorTraits<S>;| #include <iostream> | |
| #include <cstring> | |
| #include <type_traits> | |
| #include <utility> | |
| #include <tuple> | |
| // graph descriptions | |
| template <int... Next> | |
| using AdjacentList = std::integer_sequence<int, Next...>; |
| #include <type_traits> | |
| template <class From, class To> | |
| concept is_convertible = requires(From f){ | |
| { static_cast<To>(f) } -> To; | |
| }; | |
| template <typename Fst> | |
| concept BaseFst = requires { |
В предыдущей серии мы пытались сделать нечто, напоминающее проверку концепции C++20 средствами C++14/17.
У нас была функция sum, от типов аргументов которой мы требовали применимости операции +.
И выглядело в конечном итоге это так:
template<typename T>
auto sum(T a, T b) -> RESULT::REQUIRES> {