Mercury13

Можно, разумеется.
Нельзя «драть», в том числе методом проксирования.

Вызов конструктора Parent считается частью вызова конструктора Child. И он происходит раньше, чем конструирование всех полей, добавленных в Child — и уж тем более до тела Child::Child.

goto перед концом внешнего цикла.

for(первый) {
  for(второй) {
    goto a;
  }
  a:;
}

Что вы не поняли в решении: вы оптимизируете «чёрную» половинку графа, забыв, что самое малое ребро может быть в «белой».

ДЛЯ КАЖДОЙ ВЕРШИНЫ: ук-ль на «начальника» + флаг инверсии. Если у вершины нет начальника — то указывает в null.
ДИРЕКТОРОМ назовём вершину, у которого нет начальников. Считаем также, что у директора флаг инверсии всегда false.

Заведём функцию getInfoNonDestructive, она возвращает структуру из двух элементов. Во-первых, это директор (никогда не null!!). Во-вторых, это цвет — XOR флагов инверсии от самóй вершины до директора.

Функция getInfo вызовет getInfoNonDestructive, а затем проведёт ОПТИМИЗАЦИЮ СТРУКТУРЫ: ЕСЛИ вершина имеет начальника, ТО: начальник вершины := директор, флаг инверсии вершины := цвет вершины.

СЛИЯНИЕ фирм происходит так. Директор фирмы становится подчинённым кому-то из членов другой фирмы.

ИЗНАЧАЛЬНО для всех вершин начальник — null, флаг инверсии — false. То есть каждая вершина белая и сама себе директор.
РЕШЕНИЕ: Отсортируем рёбра в порядке возрастания.
Для каждого ребра…
• Находим информацию о вершинах — концах ребра.
• Если директор один и цвета разные — ничего не делаем.
• Если директор один и цвет один — выводим вес этого ребра как ответ.
• Если директора разные — сливаем фирмы. Подкручиваем флаг инверсии того директора, который исчез, так, чтобы цвета вершин — концов ребра были разные. Хотя бы так.

VertexInfo info1 = getInfo(vertex1);
VertexInfo info2 = getInfo(vertex2);
if (…) {
  info1.director->superior = info2.director;
  VertexInfo info1new = getInfoNonDestructive(vertex1);
  if (info1new.color == info2.color)
    info1.director->inverseFlag = !info1.director->inverseFlag;
}

ВНИМАНИЕ, без оптимизации структуры сложность с «чуть более O(N)» превращается в N²! Но конкретно в этом месте важно получить инфу без разрушений — временно запрещается кого бы то ни было выводить из-под старого директора, пока не выставим ему флаг инверсии цвета.

Если рёбер не осталось — перед нами двудольный граф, такого по условию не бывает.

(такая структура данных, только без флага инверсии, называется, «система непересекающихся множеств»).

ТЕОРИЯ. Начиная от самых «маленьких» рёбер, начинаем раскрашивать вершины в разные цвета. Если в какой-то момент это не удалось (цвета уже одинаковые) — выводим это ребро как ответ. Если соединяются два раскрашенных «островка» (в нашей терминологии «фирмы») — возможно, один из островков придётся инвертировать, и надо наладить инверсию так, чтобы она не захватила весь островок (судя по цифре 10⁵, от нас ожидают сложность N log N, а не N²). Поскольку соединение кусков графа рёбрами и подсчёт компонент связности — это самая настоящая система непересекающихся множеств, я попытался приделать к этой самой СнПМ раскраску, не повышающую общую сложность (амортизированные почти что O(1) за транзакцию).

Попробуй доказать самостоятельно, что данная система не зависит от того, в каком порядке оказались рёбра с одинаковым весом.

И кончайте на чужом буе в рай въезжать!

Это называется 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 я не могу привести примеры, но представьте себе: одну строку кэша сбросило в память, а вторую держит.