Mercury13

Это называется name mangling — как по-русски, я не знаю, но называю это «козявить имена».

Названия foo в объектных файлах действительно не будет существовать.

Линкер тут ни к чему, имена готовит компилятор. Потому, кстати, в межъязыковых библиотеках стараются имена не козявить.

Чтобы функция называлась именно так, как надо, в Си++ есть ключевое слово extern "C", и часто его применяют, например, при экспорте в межъязыковой DLL, при интеграции Си-кода с Си++. Что в Ди, не знаю.
В Си такого точно нет, как ты назвал, так и называются.

Линкер, конечно, может каким-то образом подхватывать DLL (так работает LD), но это очень не стандартно — при переходе с LD на LLD пришлось готовить *.a для всех имеющихся DLL. Но в любом случае именами занимается компилятор.

Это права доступа к методу. Относятся не к Cи++, а к ООП в целом.

private — имеют доступ только методы самого объекта.
protected — имеют доступ методы объекта и его потомков.
public — кто угодно.

Также существуют права доступа типа «не важно, что объекты станут связанным клубком; я готов к тому, что этот клубок придётся добавлять в программу целиком». В общем, когда объекты имеют доступ к private-методам друг друга.
• В Си++ — ключевое слово friend
• В Java — без ключевого слова (т.н. права доступа package)
• В Паскале — по умолчанию есть доступ к private-полям и методам всех объектов в том же модуле.

Эти особые права доступа (friend/package) оправданы, когда…
• Издержки от клубка незначительны (например, объекты невелики и хорошо взаимосвязаны).
• В клубок входят объект и его утилиты (например, какая-нибудь операция ++).

Не детерминирована.
В зависимости от компилятора, может скомпилироваться, но не заработать правильно.

У вас нормальное (хоть и корявое по части кода, я за такой код пинаю!) лобовое решение. Очевидно, придётся наладить какой-нибудь ускоритель, позволяющий выполнить запрос быстрее, чем за O(n).

Моё предложение: map (ради скорости можно прикрутить собственный аллокатор типа «объектный пул», благо кол-во блоков данных ограничено сверху 100k), показывающий, например, для третьего примера картинку «1→1, 2→2, 3→3, 4→4, 5→5». После первой транзакции — «1→2, 3→3, 4→4, 5→5». Поиск в этом map’е — upper_bound минус единичка (даже поиск 1-цы укажет или на второй элемент, или за первый). Сможете наладить методику разделения и склеивания диапазонов?

Можно и наоборот: 2→1, 3→3, 4→4, 5→5. Поиск в таком map’е — lower_bound (даже поиск 5-ки не выкинет за пределы, правильно?).

Разложим НОД и НОК на простые множители.
Для каждого простого определим степень в НОД и НОК.

Если хоть для одного простого a p[НОД,a] > p[НОК,a], STOP: 0.
[ПРИМЕР: НОД=2, НОК=5 — ну не бывает такого, правда? А не бывает из-за того, что в НОД 2¹, а в НОК 2⁰.]

Теперь возьмём другой пример: в НОД 2¹, в НОК 2³. Это значит, в одном числе будет 2¹, в другом 2³ — два варианта.

Итого ответ: 0, если хотя бы для одного простого a будет p[НОК,а] < p[НОД,a]
Иначе 2^{КОЛИЧЕСТВО{простых a} ( p[НОК,а] > p[НОД,a] )}

ПРИМЕР: НОД = 2¹·3⁰·5² = 50, НОК = 2³·3¹·5² = 600
1-2. 1-0-2 = 50, 3-1-2 = 600 и 600-50
3-4. 1-1-2 = 150, 3-0-2 = 200 и 200-150
Правильно, четыре штуки?

UPD. Для большей скорости можно разобрать на простые множители НОК, а в НОД просто проверить то, что получилось: нет ли степени выше, нет ли посторонних простых.
Ну и, конечно, очень крайние случаи: НОД=НОК → 1 штука, НОД>НОК → 0 штук

Нужно взять интеграл от функции c: C(t) = ∫c(t)dt,
и тогда x = cos(Ct), y = sin(Ct).

Если же функция настолько страшна, что интеграла не взять — тогда придётся решить дифур C'(t) = c(t,x,y).
Пускай даже самым простым способом C(t+h) := C(t) + hc(t,x,y). Есть и более сложные способы, гуглите «методы Рунге-Кутты».

А там нет такого уж сложного анализа. Процессор преобразует каждую команду x86 в команду VLIW (Very Long Instruction Word — что делать каждому из блоков процессора), а затем пробует спрессовывать эти команды вместе. Насколько мне известно, первым на x86 такой механизм был предложен в процессоре Transmeta Crusoe, за пару лет до Intel.

А ещё подобное налаживание зависимостей позволяет процессору делать что-то сразу же, а не ждать данных из медленной памяти. А ещё — патчить ошибки процессора :). Не помню, запатчили так Meltdown или нет.

Подсистема памяти тоже может так работать — на x86 я не могу привести примеры, но представьте себе: одну строку кэша сбросило в память, а вторую держит.

Опять вынужден сам отвечать. MSYS вполне себе содержит LLD в качестве альтернативного линкера.

int64_t и long long — одно и то же.
Компиляция ускоряется, потому что не подключается файл <stdint.h>, в котором наверняка больше строк, чем в основной вашей программе.
На исполнение повлиять не должно.

typedef bool SymbolBoolMap[16][15];
static SymbolBoolMap symbol_Bool_Map_English_Upper_A = { ... };

и возвращай [const] SymbolBoolMap&.

Вообще есть два разных метода организации многомерных массивов: кусок памяти M×N и одномерный массив[M] указателей на массивы[N].
Если для одномерных массивов кусок памяти длины N впрямую конвертируется в указатель (и даже при определённых условиях всё работает), то в многомерных первое и второе НЕСОВМЕСТИМЫ.

1) Не нужны никакие AND, INNER JOIN — часть FROM. 2) Псевдонимы разные сделай.

SELECT * FROM orders
 INNER JOIN projects AS pf ON pf.project_id = orders.order_from
 INNER JOIN projects AS pt ON pt.project_id = orders.order_to

3) Не очень хорошее название колонок order_from и order_to. Лучше project_from/project_to.

Ваши ошибки.
1. Вы считываете строку куда попало. Надо выделить память, или сделать статический массив char s[3][40];
2. Обозначение для символа перевода строки — \n, с обратным слэшом.
3. *a = a[0].

Сейчас куда лучше для отладки использовать линкер LLD. Он В ДЕСЯТКИ раз быстрее, чем LD.
Разумеется, настройки компиляции надо ставить в «самое отлаживаемое» -O0.
Я так и не понял, как ставить иконку и что с LTO — потому выпуск идёт всё ещё через LD.

UPD 2022. А сейчас LD достаточно крут и ничего не нужно!

Для неизменяемых данных я придумал.

#include <iostream>

template <class T>
struct Array
{
    const size_t size;
    const T* const data;

    const T* begin() const { return data; }
    const T* end() const { return data + size; }

    constexpr Array(const std::initializer_list<T>& x)
        : size(x.size()), data(x.begin()) {}
};

using Row = Array<int>;
using Matrix = Array<Row>;

Matrix mtx = {
  {1, 2, 3 },
  { 10, 20, 30, 40, 50 },
  {},
  { 100 }
};

int main()
{
    for (auto& u : mtx) {
        for (auto& v : u) {
            std::cout << v << ' ';
        }
        std::cout << std::endl;
    }
    return 0;
}

Для изменяемых данных пока вышло только так.

#include <iostream>

// Изменяемый вариант
template <class T>
struct Array2
{
    const size_t size;
    T* const data;

    T* begin() { return data; }
    T* end() { return data + size; }
    const T* begin() const { return data; }
    const T* end() const { return data + size; }
    T& operator[](int i) { return data[i]; }

    template <size_t N>
    constexpr Array2(T (&x)[N])
        : size(N), data(x) {}
};

using Row2 = Array2<int>;
using Matrix2 = Array2<Row2>;

int main()
{
    int i;
    std::cin >> i;

    int row1[] = { 1, i, 3 };
    int row2[] = { 10, 2*i, 30, 3*i, 50 };
    int row3[] = { 13 };
    int row4[] = { 100 };

    Row2 mtx[] = { row1, row2, row3, row4 };

    mtx[1][4] = i * 6;

    for (auto& u : mtx) {
        for (auto& v : u) {
            std::cout << v << ' ';
        }
        std::cout << std::endl;
    }
    return 0;
}