Wataru

Используйте std::vector. Их можно присваивать как переменные. При этом там под капотом не будет никакого копирования, а просто изменение указателей в данном случае (так как правая часть - временное значение).

std::vector<int> a, b;
a = a0;
b = F(a);
for (int i = 1; i <= n; ++i) {
  a = G(b);
  b = F(a);
}

Если вас напрягает, что функции G и F выделяют память внутри, то можно сделать, чтобы они получали vector, в который надо вернуть значения:

void F(const vector<int> &a, vector<int>& res);
void G(const vector<int> &b, vector<int>& res);

std::vector<int> a, b;
a = a0;
b = F(a);
for (int i = 1; i <= n; ++i) {
  G(b, a);
  F(a, b);
}

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

Посмотрите в этот allStatic: https://github.com/openjdk/jdk/blob/496641955041c5...

Там написано, почему используются статические методы: Почему-то авторы какого-то проекта HotSpot решили, что плодить namespac'ы плохо. Так что это вызвано соглашениями по стилю в конкретном проекте. Их право.

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

Еще логично сделать функцию членом класса, если она именно с классом работает. Например, функции фабрики.

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

Это называется яркость света. Цвет лазера особо не меняется. Наверно, можно считать, что яркость уменьшается очень медленно линейно из-за рассеивания воздухом. Для не лазерных источников света яркость убывает квадратично от расстояния.

Try doing what the error messages are telling you:

Detected compiler newer than Visual Studio 2022, please update min version checking in WindowsPlatformCompilerSetup.h

Or install the Visual Studio 2022 instead of what you have.

100gb - это не так и много. Даже не надо кластера, чтобы это обрабатывать.

Быстрее, конечно, работать будет на C++/rust каком-нибудь, но обработка csv может быть легче реализованна на питоне.

Разница как бы есть. В одном случае у вас *(p++), а в другом просто p++. И то и другое сдвинет указатель p на одну ячейку вправо, т.е. код имеет ровно тот же результат. Но в случае с * вы еще и адрес p, который там был до увеличения, разименуете, т.е. получите доступ. Но просто такое выражение, где вы его разименовываете и ничего с ним не делаете не имеет смысла. Его можно использовать, если вы со значением что-то делаете, например:

void Copy(char *src, char *dst) {
    while (*src) {
      *dst++ = *src++;
    }
    *dst = '\0';
  }

Тут вы значение по адресу src берете и записываете в адрес dst. Но из-за ++ оба указатлея сдвинутся. Получается копирование сишной строки.

Но делать просто *p++; смысла никакого нет. Это примерно то же что и:

int i;
i;

Вот выражение `i;` - оно как бы получает доступ к i, но со значением ничего не делает. Это странный и бесполезный код.

Так что * у вас там явно лишняя.

В ошибке же написано "Unexpected compiler version, expected CUDA 10.1 Update 2 or newer."

Перевод на русский - поставьте CUDA версии 10.1 update 2 или новее.

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

Самая концептуально простая реализация будет, если сделать функцию для отсечения группы многоугольников полуплоскостью. Прямоугольник ваш - это 4 полуплоскости: 2 вертикальные и 2 горизонтальные. Пересечение с полуплоскостью проще - там тупо прямая же одна. Вот пресеките многоугольник с первой, полученные ответ со второй, потом что осталось с третьей и потом с четвертой полуплоскостью.

Удобно хранить множество точек и для каждой - указатель на сделующую в обходе многоугольника (ориентированного так, что слева от отрезка внутренность многоугольника). В таком виде входные данные, в таком виде будет и ответ.

Точки будем помечать, как обработанные.

Обойдите все точки циклом, для всех необработанных еще, которые лежат внутри полуплоскости, начинайте с них строить ломанную-ответ. Идите к следующей точке, пока отрезок не пересечет полуплоскость (это значит конец строго внутри удаляемой области), помечая точки обработанными. До этого момента добавляйте точки в ответ сохраняя указатель на следующую точку. Для текущей следующей сделайте новую точку - точку пересечения. Еще запомните где-то эту точку пересечения, это потом понадобится. Продолжайте обход, пока отрезок не выйдет из полуплоскости (конец строго снаружи удаляемой области). Тут создайте точку пересечения, запишите ее в ответ, и для нее следующей сделайте конец отрезка снаружи. Продолжайте обход как в начале. Если встретили уже обработанную точку, вы закончили строить ломанную ответ.

Потом надо будет все точки пересечения соединить в порядке вдоль прямой парами (смотрите так, чтобы удаляемая область была справа от направления движения). Их будет четное количество.

Вот у вас все оставшиеся точки образуют многоугольники, если идити по указателям на следующую. Правада, они в массиве могут идти вперемешку, а не подряд. В конце вам может понадобится их сгруппировать, но это делается похожим обходом: помечайте точки обработанными, берите любую не обработанную и идите от нее по указателям, пока не вернетесь в нее же, помечая все точки как обработанные и добавляя в ответкак часть одного многоугольника. Это можно сделать после того, как пересечете со всеми 4 полуплоскостями.

Удобно прямую хранить в виде Ax+By+C=0. И знак подобрать так, что точки внутри хорошей области, если их подставить в это уравнение дают положительные значения (а точки снаружи - будут отрицательные). Соответственно, проверка, что с точки можно начать обход - просто посмотреть на знак. Проверка, что есть пересечение - конец отрезка дает отрицательный знак (а потом - положительный). Точки удобно хранить в виде массива координат и массива номеров следующей точки в обходе. Никаких сишных указателей - номера следующей точки в массиве. Сортировать точки пересечения надо будет по значению Ay-Bx.

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

Это все удовольстивие будет работать за O(n log n) - потому что надо потом точки пересечения на прямой отсортировать.

Правильно ли понимаю, что после присвоения _Fmtflags skipws = (_Fmtflags)_IOSskipws; _IOSskipws становится челном перечисления _Fmtflags ?

Нет, сначала препроцессор заменит _IOSskipws на 0x0001, потом skipws инициализируется 0x0001.

Зачем так сделано? Может, кто-то очень жестко следует правилу не использовать магические числа в коде. Все константы должны быть как-то определены заранее. Видимо, в стиле, принятом тут, константы заводят через define.

Или IOSskipws используется в инициализации каких-то еще констант в этом или другом классе и тогда имеет смысл заводить его отдельно.

Оказывают ли поля _Fmtmask = 0xffff, _Fmtzero = 0 перечисления _Fmtflags, какое либо влияние на поля _IOSskipws

_IOSskipws - это вообще не поле, это символ, заменяемый препроцессором на 0x0001. Он с точки зрения С++ вообще не существует.

break; в коде все портит. Выполняется первая проверка, не срабатывает, наверно, потому что currentState не тот. А может, потому что у вас там еще break между уловными проверками расставлены. До проверки на BUTTON_ID_CLOSE_SERVICE код никогда не доходит.

Break должен быть один раз в конце case блока, чтобы управление не перешло на следующий case. Switch же просто переносит управление на соответствующий case и все. Он не отключает как-то куски кода в других альтернативах.