Антон Жилин

Ваше присваивание выполняет p1.first = p2.first и p1.second = p2.second. Но вы запретили присваивать в p1.first, объявив его как const.

operator< ищется через ADL. Нельзя определить оператор для чужих типов, и чтобы его подхватили алгоритмы. Предлагаю такое решение: вместо char искать свою структуру (её можно определить просто как struct с char), для которой определить сравнение так же, как ты это сделал с char.

std::any позволяет сохранить в себя объект любого типа, после чего через any_cast вытащить значение, если оно такого типа, как мы предполагаем. Проверка осуществляется через RTTI. Если поддерживается много конкретных типов, вы должны писать здоровенную цепочку if-else-if. В таком случае лучше уж идти через наследование.

Нет, директивы препроцессора не ограничены никакими областями видимости. Они заменяют абсолютно все вхождения соответствующего имени после своего определения. Пример:

namespace what {
#define apples 2
}

namespace stuff {
    class foo {
    private:
        int apples = 3;  // ОШИБКА: 2 - недопустимое имя
    public:
        int read_apples() {
            return apples;  // 2
        }
    };
}

Мораль: не используйте макросы там, где можно обойтись constexpr константами или inline функциями. А там, где они необходимы, давайте им длинные страшные КРИЧАЩИЕ_ИМЕНА.

Это объявление (declaration) конструктора. Значения полей должны быть заданы в определении (definition). Раз определения тут нет, значит, его нужно искать где-то в другом месте. Возможно, вы найдёте его в одном из следующих шагов. Возможно, его написание оставлено как упражнение для читателя. Возможно, содержимое конструктора (присвоение параметров полям) авторы посчитали очевидным.

Пример определения, которое должно следовать за таким классом:

Cls::Cls(char c, double d, int i)
    : c(c), d(d), i(i) {}

Убери предпоследнюю строку. Компилятор жалуется на дублирующееся объявление метода IdentifyLength, а не на typedef. К слову, в новом коде вместо typedef следует использовать using:

using DigitArea = unsigned int;

А ещё лучше - использовать типы из <cstdint> по умолчанию. Например:

using DigitArea = std::int64_t;

#include "std_lib_facilities.h"
Вы уверены, что скопировали в проект файл std_lib_facilities.h и подключили его должным образом?

Предрасчитанный ключ - вполне валидная стратегия, если расчёт хеша сильнее влияет на производительность, чем хранение дополнительных 8 байтов на элемент.

template <typename T>
class hashed {
    T value_;
    size_t hash_;

    friend class std::hash<hashed<T>>;
public:
    template <typename... Args>
    constexpr hashed(Args&&... args) :
        value_(std::forward<Args>(args)...),
        hash_(std::hash<T>()(value_))
    {}

    // rule of zero

    constexpr T& get() & noexcept { return value_; }
    constexpr const T& get() const& noexcept { return value_; }
    constexpr T&& get() && noexcept { return value_; }
    constexpr const T&& get() const&& noexcept { return value_; }
};

namespace std {
    template <typename T>
    struct hash<hashed<T>> {
        constexpr size_t operator()(const hashed<T>& x) const noexcept {
            return x.hash_;
        }
    };
}

std::unordered_map<hashed<std::string>, int> cache;
auto it = cache.find("property1");  // хеш на этапе выполнения

// хеш на этапе компиляции, работает с constexpr std::string из C++20
constexpr auto h = hashed<std::string>("property1");

auto it2 = cache.find(h);  // предрасчитанный хеш

Когда лень писать лямбду. Часто [](widget& w) { return w.foo(); } можно заменить на widget::foo.

C++ не может повредить. Если вы используете virtual, RTTI, exceptions, iostreams, то вы платите за них, но если эта цена неприемлема - просто не используете их.

Однако C++, особенно C++11 и C++14, часто не поддерживаются компилятором, когда приходится собираться не под уютные gcc/clang x86, а что-нибудь специфическое, вроде Arduino или CUDA. Ещё в ядре Linux C++ традиционно под запретом.

Так что посмотрите, можете ли вы использовать C++ в вашем конкретном случае. Если нет, то выбирать не из чего.

Для любого типа T, T.Type - это метатип (metatype), то есть тип, объекты которого предоставляют описание типа T. Статические функции и init-функции T становятся функциями-членами T.Type. Пример:

struct Duck {
    static func kind() -> String { return "Bird" }
    init() { }
    func talk() { print("Quack") }
}

let meta: Duck.Type = Duck.self
meta.kind()  //=> Bird
let obj: Duck = meta.init()
obj.talk()  //=> Quack

Существует 2 класса метатипов, но на практике встречаются existential metatypes, то есть их объекты могут описывать как данный тип T, так и любой наследник (subtype) типа T. Другими словами, множество объектов типа T.Type - это U.self для всех типов U: T. Пример:

class Animal { class var name: String { return "Animal" } }
class Cat: Animal { override class var name: String { return "Cat" } }
class Dog: Animal { override class var name: String { return "Dog" } }

var meta: Animal.Type
meta = Cat.self
meta.name  //=> Cat
meta = Dog.self
meta.name  //=> Dog

Или, например, можно представить себе такую функцию генерации животных:

class Animal { ... }

func createAnimal(_ type: Animal.Type) -> Animal {
    if type == Cat.self {
        return Cat(...)
    } else if type == Dog.self {
        return Dog(...)
    } else {
        fatalError()
    }
}

На практике, такая функциональность метатипов используется редко. Как правило, они служат для явной специализации шаблонных функций. Например:

func unsafeCast<T, U>(_: T, to: U.Type) -> U

Здесь единственный способ указать тип U при вызове - это передать "фиктивный" параметр тип U.Type, так как аргументов типа U функция не принимает. Вернее, это лучший и принятый в Swift способ. Можно было бы выкрутиться вот так:

func unsafeCast<T, U>(_: T, sameAs: U) -> U

Но, понятно, что для этого нужно иметь под рукой объект типа U, и это не идеальный вариант. Жаль, что нельзя писать просто unsafeCast<U>(t) при вызове.

При использовании метатипа U.Type таким образом, его значение, как правило, игнорируется. То есть даже если вы передадите туда метатип наследника типа U, то функция всё равно будет работать с U.

P.S. Есть ещё много недокументированных фич метатипов в Swift, но там всё не очень логично и продуманно (даже разработчики из Core team не всё там понимают), так что на практике лучше ограничиться применением для явной специализации функций, как показано выше.