Простой инлайн-визитор для boost::variant

Можно сделать «метафабрику» предикатов для кастомизации обобщённых лямбда-функций.

Простой инлайн-визитор для boost::variant

В классе

VisitorBase

нет using-директив для «выноса» всех операторов

operator ()

в most-derived класс. Здесь есть указание на то, что если компилятор принимает такой код, то это не соответствует стандарту. Здесь подробно обсуждается код, эквивалентный вашему. Этот вопрос тоже относится к проблеме.

Простой инлайн-визитор для boost::variant

Последнее замечание — по-моему верное. Судя по всему, такой запрет существует до сих пор лишь только по историческим причинам.

Простой инлайн-визитор для boost::variant

Насчёт более тонкого паттерн-матчинга:

template< typename T >
struct is_cref_vector
    : std::false_type
{ ; }

template< typename T >
struct is_cref_vector< std::vector< T > const & >
    : std::true_type
{ ; }

[] (auto const & v) -> std::enable_if_t< is_cref_vector< decltype(v) >{} > { /* ... */ }

Проверяем исходный код Appleseed

В таких выражениях рекомендуется сразу указывать константу SIZE_MAX.

Это будет не в C++-стиле. Мне кажется, с педагогической точки зрения, лучше советовать указывать std::numeric_limits< std::size_t >::max().

Способ написания синтаксических анализаторов на c++

Можно ещё дальше пойти и (в ваших терминах) сделать так: expr ::= expr, { ('+' | '-' | '*' | '/'), expr } а затем применить алгоритм сортировочной станции, чтобы достроить поддеревья для подвыражений с двуместными операциями (вот пример грамматики в Boost.Spirit X3 и пример применения алгоритма сортировочной станции для «допарсивания» выражения).

«Ра-а-авняйсь, смирно!». Выравниваем данные

Вы удивили. В каких компиляторах поддержка C++11 весьма ограничена на сегодня? Если верить инфографике и другим данным, то (по крайней мере) не в 95% самых используемых.

Новое предупреждение о неверном вычислении размера массива в gcc 5.1

Что-то некорректно написано?

Новое предупреждение о неверном вычислении размера массива в gcc 5.1

Контроль типов для конструкций вида

void f(char x[100])

не обязывает в точности контролировать тип передаваемого значения параметра функции с точностью до количества элементов. Если нужно точно

char x[100];

, то следует использовать именно ссылку

void g(char (& y)[100])

.

Передача сохраненных аргументов в функцию

template <typename T>
struct call_type : call_type<decltype(&std::remove_reference_t< T >::operator())>
{};

Я бы сделал так.

Передача сохраненных аргументов в функцию

вызвать функцию через указатель и передать в нее предварительно сохраненные аргументы

Я себе это вижу так:

#include <utility>

template< typename ...types >
auto
make_caller(types &&... _values)
{
    return [_values...] (auto && callee) mutable -> decltype(auto) { return std::forward< decltype(callee) >(callee)(std::forward< types >(_values)...); };
}

// main.cpp
#include <iostream>

#include <cstdlib>

struct A
{
  
    template< typename ...types >
    void
    operator () (types...) const &
    {
        std::cout << __PRETTY_FUNCTION__ << std::endl;
    }
  
    template< typename ...types >
    void
    operator () (types...) &&
    {
        std::cout << __PRETTY_FUNCTION__ << std::endl;
    }
  
};

void
f(int, float, double, long double)
{
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

int
main()
{
    auto caller = make_caller(1, 1.0f, 1.0, 1.0L);
    caller(A{});
    A const a{};
    caller(a);
    caller(f);
    caller(&f); // в точности то, что нужно
    return EXIT_SUCCESS;
}

Передача сохраненных аргументов в функцию

Вы используете forwarding-references, но для случая `const T &` код не сработает:

template <typename T>
struct call_type : call_type<decltype(&T::operator())>
{};

Такой user-код даёт hard-error:

struct A { void operator () () const { ; } };
A const a{};
auto f = make_function(a);

Необходимо использовать `std::remove_reference_t`.

Самая медленная инструкция x86

Неужели логарифм по основанию 2 так долго считается? Есть ли аналоги для расчёта логарифма? AVX и SSE содержат что-либо для расчёта тригонометрических и экспоненциальных функций? Или только приблизительно можно считать?

Алгоритм Quickhull для нахождения выпуклой оболочки

Добавил проверку выпуклости. В CGAL не Quickhull, так что противоречия нет.

Алгоритм Quickhull для нахождения выпуклой оболочки

Вопрос, безусловно, философский. По ссылке, насколько я помню, автор придерживается несколько другого подхода, а именно: он рассуждает в терминах луча зрения, который должен иметь возможность падать на сетчатку без помех (have an unobstructed path). Автор делает вывод:

A 2D retina works, because there is a 3rd dimension in which the light can travel unobstructed from the object onto the retina.

Т.о. сетчатка должна иметь размерность (D — 1) и меньше.

Алгоритм Quickhull для нахождения выпуклой оболочки

Как-то году в 2011 решал задачку и никак не мог взять в толк, как её решить. Со второй попытки (прошлым летом) всё же решил в общем виде, будучи в отпуске.

Алгоритм Quickhull для нахождения выпуклой оболочки

Спасибо за ссылку. Полезным будет реализовать проверку выпуклости результата как у них (Mehlhorn algorithm).

Пишем простой интерпретатор на C++ с помощью TDD, часть 2

Тоже пытался написать свой компилятор, но так и не завершил. Вот хоть поделюсь своей реализацией алгоритма сортировочной станции.