@ProCxx

« Назад

Страница 2404 из 2477

Далее »

Igor

04.10.2018
07:48:03

и вообще до кучи сам доклад https://www.youtube.com/watch?v=vLinb2fgkHk

Firstname

04.10.2018
07:53:15

еее thank you

еще такая тема с пары

волгринд на новом маке падает

Google

Firstname

04.10.2018
07:53:32

вот

так что кому критично, лучше не обновляйтесь

Alex

04.10.2018
07:54:59

https://i.stack.imgur.com/b2VBV.png

Спасибо за табличку. А в чём разница между красным и синим defaulted?

Igor

04.10.2018
07:56:42

красное - deprecated на момент с++11, насколько я помню; в докладе подробнее

если не определяешь ничего - компилятор сам всё подставит если определяешь какой-нибудь конструктор - компилятор выкиыдвает дефолтный если определяешь деструктор - компилятор выкидывает всё кроме дефолтного конструктора

Simon

04.10.2018
08:07:58

Что-то я сейчас затупил, наличие какого либо из 5 генерируемых операторов в базовом классе влияет на генерацию оных в наследнике? Влияет же, да?

А да

Тогда бы буст нонкопиабл не работал, если бы не так было

Ilia

04.10.2018
08:57:35

Что-то я сейчас затупил, наличие какого либо из 5 генерируемых операторов в базовом классе влияет на генерацию оных в наследнике? Влияет же, да?

Нет,не влияет

Тогда бы буст нонкопиабл не работал, если бы не так было

Там другое, ты при конструировании наследника ОБЯЗАН вызывать какой-то конструктор предка. non-copyable просто скрывает все конструкторы.

Alexey

04.10.2018
09:36:09

Разве все?

Anatoly

04.10.2018
10:15:15

@kotanyaaa в личку @AlexFails, отсюда удаляю

Constantine

04.10.2018
11:26:35

Я решил почитать, как делается type erasure, чтобы точно вспомнить, и мне кажется, что там 3 вызова: (1) разыменование unique_ptr на concept, (2)виртуальный вызов метода в concept дает проход в vtable из которой (3) проход в реализацию метода в классе. А вызов у базового класса при дин. полиморфизме даст 2 прохода по указателям. ЧЯДНТ? Это я про плохие type erasure прочитал?

Проход в реализацию в классе не в счет, невиртуальный вызов

Google

Andrew

04.10.2018
11:35:58

Да, правда.

Vyacheslav

04.10.2018
12:38:36

господа. а у меня такой вопрос. Насколько нормально испльзовать в библиотеке std::runtime_error ?

это типа good practice для c++?

yuri

04.10.2018
12:41:57

за пределы либы выбрасывать исключения вроде не good practice.

Александреску топит за std::expected

Ilia

04.10.2018
13:19:06

господа. а у меня такой вопрос. Насколько нормально испльзовать в библиотеке std::runtime_error ?

Абсолютно нормально.

за пределы либы выбрасывать исключения вроде не good practice.

Гон

за пределы либы выбрасывать исключения вроде не good practice.

Если библиотека для С, то конечно плохо бросать исключение (но иногда даже можно). Если библиотека для С++, то почему бы не бросать?

Alexander

04.10.2018
14:08:53

Ссыль видать куда-то попала

Anatoly

04.10.2018
14:09:07

Если библиотека для С, то конечно плохо бросать исключение (но иногда даже можно). Если библиотека для С++, то почему бы не бросать?

если для C библиотека, то исключения C++ нельзя выпускать через границы публичного интерфейса.

Anatoly

04.10.2018
14:12:10

с++ Разумно пользоваться здравым смыслом в этом вопросе, а не трендами. Если важна скорость и/или функции вызываются часто - возвращаем результат. Если приложение по факту ошибки можно закрывать, то можно спокойно бросать эксепшены, разумеется предварительно задокументировав такое поведение.

Admin

ERROR: S client not available

Vyacheslav

04.10.2018
14:16:27

Кстати, господа, можете накинуть примеры проектов с хорошей документацией и комментариями? Best practice, так сказать

Владислав