Общие вопросы по программированию (1291 стр)

totoro
> Но в дизасме временный объект живет до тех пор, пока ret не наступит из вызываемой ф-ии, не смотря на то что захват по ссылке не осуществлялся.
у тебя нет временного объекта, твой случай про время жизни аргумента. Временный объект о котором я тебя предупреждал это когда ты возвращаешь его из функции. Что-то типа такого:

const int* getPtr() const
{
  int v(value);
  return &v;
}

totoro
> Но в дизасме временный объект живет до тех пор, пока ret не наступит из вызываемой ф-ии.
Повторяю: он живёт до точки с запятой по месту создающего выражения. У тебя сначала создаётся один Темп, на котором вызывается гетВальюПтр, после чего отрабатывает наПолучи целиком, и только после этого — когда все вычисления в текущем выражении закончены — тогда начинается фаза очистки временных и Один Темп удаляется. Это самый минимум времени жизни объекта — до конца statement. Некоторые формы инициализации могут сделать удлиннение до конца скоупа. Но даже без удлиннения — все темпы, сконструированные выражениями в этом statement, живут до самого окончания этого statement, даже если это надефайненный по самые яйца 15-километровый statement с 30 уровнями вложенности и 40 операторами запятая.

Aroch
> у тебя нет временного объекта, твой случай про время жизни аргумента.
Аргумент и временный объект в моем примере имеют разные типы и разное время жизни. Аргументом является указатель на целочисленный знаковый объект, который, в свою очередь, так же является полем временного объекта.

totoro
> и разное время жизни
нет и под нет разумеется не имеется ввиду тупо указатель, а данные на которые он указывает.
https://timsong-cpp.github.io/cppwp/class.temporary#4

А есть смысл рисковать? Сейчас видна сомнительность ситуации (пусть и допустимо, если верить Ведьмаку), а потом будешь рефакторить - и стрельнет когда не ждали.

Dmitry_Milk
> А есть смысл рисковать?
Согласен. Код явно стремный.

entryway
> Согласен. Код явно стремный.

Ну на самом деле (a+b).c_str() можно пихать в WinAPI-функции. Это уже не изменится.

Накой чорд нам std::byte, когда есть унсигнид чар и std::uint8_t?

nes
https://gamedev.ru/flame/forum/?id=248221&page=36&m=5087412#m526

nes

std::uint8_t опциональный тип. unsigned char арифметический тип и, в зависимости от контекста, символ. А std::byte одновременно и чист, как слеза комсомолки, и любой объект можно представить в виде массива std::byte.

entryway

> https://gamedev.ru/flame/forum/?id=248221&page=36&m=5087412#m526
Мда

entryway
у nes'a "вопросы от нуба" закончились и он решил по второму кругу пойти.

Ghost2
А де тогда наши std::word, std::dword, в стандарте 2030 высруть?

Безопасен ли код:

double foo(double x) {
if (x==0.0) // гарантировано, что нулевое значение не попадёт в операцию деления? 
return 0.0;
return 1/x;
} 

Вообще, вопрос возник из задачи для ноомализации вектора.
Upd: в Ogre3d версии 1.9 есть ссылка на форум в коде нормализации вектора, которая объясняет зачем они отказались от использования эпсилон. Но я так и не понял, почему.

nes
> Накой чорд нам std::byte, когда есть унсигнид чар и std::uint8_t?
Чтобы когда ты увидишь функцию с сигнатурой
    size_t hash(std::byte const* buf, size_t len)
У тебя не возникало вопроса: "а если в буфе встретится нулевой байт раньше чем лен, это будет воспринято как конец строки и всё что дальше будет проигнорировано, или же нули не имеют никакой специальной обработки и все лен байтов будут прочитаны без вариантов?"