Армянское Радио

Для кода на плюсах, надо вызывать не gcc а g++

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

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

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

Сначала стоит подумать над тем, чтобы строительством буфера занимался GPU
Если с этим напряжно, у вас есть вариант использовать DMA (glMapBuffer), (я бы сделал этот вариант), использовать два контекста, или делать как вы хотите - по сигналу дочернего потока вызывать glBufferData

Полезное на почитать

Если пакеты большие, а обмен интенсивный, то да, куски пакетов могут теряться даже на localhost

Если есть риск присванивания знакового значения в беззнаковое, компилятор выдаст WARNING

Гораздо опаснее пихать всюду int, особенно в качестве индексов массивов и размеров. Потому что в какой-то момент кто-то захочет посчитать больше 2^31 штук объектов.

Выдержка из материала по ссылке:

большое количество диагностических сообщений, выдаваемых анализатором Viva64, связанны именно с рекомендацией использования memsize-типов. Использование memsize типов (таких как size_t, ptrdiff_t, INT_PTR) в 64-битных программах, вместо 32-битных типов (int, unsigned) позволяет:

Построить компилятору более простой и, следовательно, более быстрый код, в котором будут отсутствовать лишние преобразования 32-битных и 64-битных данных. Особенно это полезно при работе с адресной арифметикой и индексации массивов.
Избежать ряда ошибок при обработке большого объема входных данных, когда количество обрабатываемых элементов превышает количество UINT_MAX.
Избежать ряда других, более специфичных ошибок.
Сделать код более переносимым между 64-битными Windows и Linux системами, в которых используются различные модели данных. Так, например, в Linux системах для индексации больших массивов можно использовать тип unsigned long, а в Windows нет.

Компилятор С++ пенсионного возраста, или не настроен C++ >= С++11

-проверить, что компилятор новый (GCC 11й версии или Clang 12й)
-добавить флаг -std=c++17

Банальная порча всех итераторов, ссылок и указателей в тот момент, когда вы вызываете emplace у вашей свалки потоков второй раз. Лечение - избавиться от переаллокации при вызове emplace, путем вызова reserve(), или использовать контейнер, который не передвигает свое содержимое туда-сюда, например, std::list

Формально, единственная функция, в которой можно не делать return - это именно main.

В остальных случаях, если функция что-то возвращает, наличие return обязательно - иначе будет UB.

Почему для main исключение - никто не знает, потому что параграф в стандарте языка, на который ссылается другой параграф - потерялся:

I looked it up. I believe this was introduced with C99, and apparently the C99 rationale is defect. It has comments for 5.1.2.2.1 Program startup, then labels the next chapter 5.1.2.3 Program execution. It should have been 5.1.2.2. As a consequence of this, the rationale for Program termination that should have been in the real chapter 5.1.2.3, has gone missing in action. Thus, main allows no return code in C99 and there exists no rational reason why.

Источник

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

В данном случае, a+n трактуется как указатель на элемент массива с идексом n, то есть, &a[n].

g = nullptr не удалаят память, оно просто записывает в переменную g значение со смыслом - "указатель вникуда". Память при этом остается нетронутой и к ней можно обращаться, что вы и делаете, запомнив указатель в другой переменной.

delete[] же освобождает память, а значит, все последующие обращения к ней, что при помощи g, что при помощи gg - будут вызывать UB

Оператор << не является точкой следования, таким образом, вы получаете неопределенное поведение - у вас вызовы ++(*val) не отделены точкой следования друг от друга.

Вот так ошибки не будет:

cout << a.get();
cout << b.get();

Потому что ; является точкой следования.

В более свежих версиях стандарта может быть другая терминология, но суть проблемы - прежняя.

Ну все правильно - объявления функций вы положили в неймспейс, а тела - нет

0) Такие ошибки возникают в рантайме, то есть тогда, когда приложение работает.
1) Когда приложение работает, компилятор уже не участвует.
2) Все эти ошибки C++ обрабатывает, только это надо запрограммировать

Да, это реально так. Более того, при желании, можно написать свое такое же - например, как в моем миниатюрном классе логов:

Lout& operator << (Lout& out, Lout& (*func)(Lout&));
Lout& operator << (Lout& out, std::function<Lout& (Lout&)>&&func);

//stream commands & modifiers
Lout &anounce(Lout &ret);
Lout &flush(Lout& out);
Lout &ok(Lout& out);
Lout &fail(Lout& out);
Lout &newLine(Lout& out);
Lout &pop(Lout& out);
Lout &Color(Lout& out, const uint8_t);
Lout &noColor(Lout& out);