RM
аа все нормально
Size: a a a
2020 April 18
RM
там Node принимает затем по ссылке
RM
а затем снова move
RM
так что правильное решение
net_sv_msg_cb_map.emplace(msg_id, std::move(cb));.
Тебе нормально самому с собой общаться?
RM
Тебе нормально самому с собой общаться?
Я вот жду, поправит меня кто-то или я прав
RM
Должен ли я помечать функции использующие внутри себя семантику перемещений, как noexcept, если я уверен, что методы внутри функции не вызываются исключение? (Прочитал что от этого зависит оптимизация)
RM
И следом вопрос, что произойдет если помеченная как noexcept функция все же имеет внутри себя вызов какого нибудь new который может бросить исключение?
O
Должен ли я помечать функции использующие внутри себя семантику перемещений, как noexcept, если я уверен, что методы внутри функции не вызываются исключение? (Прочитал что от этого зависит оптимизация)
1) А ты уверен, что они всегда будут
2) А почему нет?
noexcept? 2) А почему нет?
RM
1) А ты уверен, что они всегда будут
2) А почему нет?
noexcept? 2) А почему нет?
Не совсем то что хотелось бы услышать
O
И следом вопрос, что произойдет если помеченная как noexcept функция все же имеет внутри себя вызов какого нибудь new который может бросить исключение?
Проверь. Оно упадёт
RM
В каком смысле не всегда будут noexcept ?
RM
Если внутри вызывается что-то, что может бросать исключение?
O
Не совсем то что хотелось бы услышать
Это вопрос по С++ же, тут никогда в ответ не получаешь то, что хочешь...
/¯
И следом вопрос, что произойдет если помеченная как noexcept функция все же имеет внутри себя вызов какого нибудь new который может бросить исключение?
UB (обычно резолвер зовёт здесь std::terminate, но как повезёт)
RM
Это вопрос по С++ же, тут никогда в ответ не получаешь то, что хочешь...
Я хотел услышать что-то вроде:
1) Не обязательно, но так компилятор будет лучше оптимизировать код для семантики перемещения, однако, нужно учитывать что можно острелить себе ногу если забыть что функция помеченная, как noexcept внутри себя вызывает функции, которые могут бросить исключение
1) Не обязательно, но так компилятор будет лучше оптимизировать код для семантики перемещения, однако, нужно учитывать что можно острелить себе ногу если забыть что функция помеченная, как noexcept внутри себя вызывает функции, которые могут бросить исключение
O
В каком смысле не всегда будут noexcept ?
Вот используется у тебя семантика перемещений и все конструкторы перемещения
noexcept. А однажды ты решаешь реализовать в конструкторе перемещения одного из классов нетривиальную логику и позволяешь ему кидать исключения. Ты, конечно же, сразу вспомнишь все методы, полагающиеся на этот конструктор и пойдёшь с них снимать noexcept?O
Я хотел услышать что-то вроде:
1) Не обязательно, но так компилятор будет лучше оптимизировать код для семантики перемещения, однако, нужно учитывать что можно острелить себе ногу если забыть что функция помеченная, как noexcept внутри себя вызывает функции, которые могут бросить исключение
1) Не обязательно, но так компилятор будет лучше оптимизировать код для семантики перемещения, однако, нужно учитывать что можно острелить себе ногу если забыть что функция помеченная, как noexcept внутри себя вызывает функции, которые могут бросить исключение
Именно последнюю часть я тебе и рассказал с учётом потенциальных изменений в коде
/¯
Должен ли я помечать функции использующие внутри себя семантику перемещений, как noexcept, если я уверен, что методы внутри функции не вызываются исключение? (Прочитал что от этого зависит оптимизация)
Что значит "должен"? Кому должен
RM
UB (обычно резолвер зовёт здесь std::terminate, но как повезёт)
А почему бы не сделать так чтоб функция помеченная как noexcept компилятором автоматом отбрасывалась если эта функция вызывает функции, которые могут бросить исключение?