автор10. Правильно ли я понял, что безопасный с точки зрения исключений код -- это код, который при выбрасывании исключений в вызвавшую его функцию не даёт утечек памяти, а также не меняет состояние объекта?

Да, чаще всего ещё и без требования неизменности состояния объекта.

автор11. Чем отличается size_t от int и других целочисленных типов? Для чего вообще нужен size_t?

Это специальный тип для хранения размера объекта.
Дело в том, что размеры int long и void* не определены стандартом и в принципе везде разные.
А size_t, который должен хранить любую разницу между двумя void* -- вообще был бы не понятно какого типа, если бы не было size_t в явном виде.

автор12. Есть объект, созданный не в куче, а у него поле, созданное в куче.
Этот объект считать созданным в куче или нет?

Нет, этот объект создан не в куче (на стеке, в глобальной памяти или ещё как).

авторТот же вопрос в том случае, когда объект создан в куче, а его поля -- на стеке.

Это -- ошибка проектирования Объект при этом создан естественно в куче. Только как он будет жить при выходе из скопа автоматических объектов, на которые он ссылается -- не понятно. Такое иногда допустимо, если он ссылается на автоматические переменные в функцие main, например.

автор13. Чем отличается operator new() от оператора new()? Один из них можно перегружать, дрйгой является встроенным, один из них вызывает другой... А зачем надобность сразу в двух похожих операторах?

Видимо, речь идёт о обычном new и placement new ? Уточни...

автор14. f(new T1, new T2). Допустим, в теле функции f(...) сработало исключение. Очищается ли автоматически память, выделенная для T1 и T2? Если нет, то как её можно очистить, кроме как внутри функции f() (внутри, полагаю, кодом delete T1; delete T2;)?

Тонкий момент. Точно не знаю.
Видимо, не должна очищаться.
При аналогичном почти случае внутри инициализаторов конструктора очищается автоматом.

автор15. Надо ли удалять указатели на функции подобно тому, как мы удаляем указатели на объекты?

Надо, если ты выделял функцию динамически, с помощью new. поскольку это сделать в С++ (пока по крайней мере) нельзя,
то это "надо" не наступает никогда.

автор16. При срезке обычно теряются члены дочерних классов. Допустим, дочерний класс занимал какое-то место в памяти. А куда всё девается область памяти, в которой содержатся члены дочернего класса, при преобразовании его в базовый класс, если речь именно о преобразованиях объекты, а не указателя или ссылки? Информация теряется, но происходит ли утечка памяти?

Срезка происходит только при копировании самого объекта. При присваивании, при возврате объета по значению.
При этом обычно объекты находятся: исходный -- всё равно где и не меняется, результирующий -- на стеке (при возврате), либо там, где его определили при присваивании. В любом случае проблем с памятью не возникает и утечек никаких нет.

автор17. Если использовался размещающий new, то при исключении в конструкторе вызывается размещающий delete, который должен быть прописан, если же всё хорошо, вызывается обыкновенный delete. Верно ли, что для каждого из перегруженных new надо вызывать соответствующий перегруженный delete?

Нет, на сколько я понимаю вопрос. new может быть наперегружен дофига как, фактически ты можешь указать у new любое кол-во любых аргументов. А delete этим всем new будет соответствовать только один.

автор18. Верно ли, что ислючения всегда передаются по значению,

Куда передаются ? Исключения -- это обычные объекты, если ты их используешь по-обычному, они передаются так же, как объекты во всех других случаях (слово "объект" тут означает не только объекты классов, но и объекты встроенных типов С++).
Если при выкидывании исключения имеется в виду в вопросе -- тогда ровно так они передаются, как идёт выкидывание.
Если кидается сам объект, происходит передача по значению, если адрес выкидываетсы -- то по указателю.
Т.е. с учётом семантики указателей можно сказать, что передаётся при TROW объект всегда по значению (т.е. если выкидывается указатель, то по значению передаётся указатель).

автордаже если стоит что-то типа catch(ExepClass& ex){} или catch(ExepClass* ex){}, всё равно будет передана копия выброшенного объекта, а всякие ссылки и указатели нужны у catch только для полиморфизма?

Нет, это совсем неверно. Если будет кидаться объект по значению, а ты будешь ловить указатель, то просто данный catch ничего не поймает. И наоборот, если кидается указатель, а ловится ссылка или значение, тоже не поймаешь. Ловля по значению и по ссылке отличается лиш тем, что при ловле по значению происходит дополнительное копирование (и возможно срезка).

авторЕсли передана копия, то верно ли, что даже если try-catch стоят вместе (catch тут же отлавливает возможные исключения), то всё равно в catch передаётся копия выброшенного объекта?

Да.

автор19. Везде ли есть выравнивание?

Стандарт не определяет это. Так что ничего об этом сказать нельзя. Где-то оно есть, где-то его нет.
Сказать, что оно есть везде, нельзя. Сказать, что его нигде нет -- тоже.
автор20. Почему поля static не являются безопасными с точки зрения потоков?

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

авторИ верно ли, что для встроенных типов нет необходимости применять синхронизацию?

Нет. В корне неверно.

автор21. Что понимают под high frequency и low latency на C++?

Это не имеет отношения к С++, выходит за его рамки. Не имеет смысл обсуждать.

авторПочему плюсы считаются быстрее Java?


Потому что C++ рулез а Java -- говно голимое.
На самом деле конечно нельзя сказать, что С++ быстрее Java. Можно сказать только, что конкретная программа на С++ быстрее аналогичной на Java или наоборот. Кстати, наоборот вполне возможно, это часто связано с выделением памяти -- Java-программам часто память даётся большими кусками, и на выделении получается экономия. В С++ же дефолтный (и иногда единственный) хип может быть не самым лучшим для данного алгоритма работы или вообще плохим по жизни (это зависит от реализации компилятора, а не от языка, это не С++ плохой, а конкретная реализация)

авторТолько из-за другого распределения памяти (в Java вся ответственность на сборщике мусора, что замедляет вычисления)?

Вот тут есть один момент, который существенно влияет на "почему плюсы считаются быстрее Java". В Java часто (почти всегда) перераспределение памяти может возникать в любой момент работы программы. Ну вообще просто тупо почти всегда. Поэтому её не любят создатели ПО, которое расчитано на маленькие задержки, или почти или полностью realtime. Ну действительно -- ты тут считашь что-то, считаеш, торопишся, ещё милисекудна, ещё пол милисекунды осталось -- а тут бац -- и сборщик мусора заработал.
В С++ выделение и освобождение памяти всегда детерминировано, предсказуемо. Когда оно произойдёт -- всегда известно.
Поэтому такое ПО писать легче.

авторПочему другие языки не такие бытрые, как C++ и что им мешает быть быстрее?

Ну, это уж вообще философский вопрос -- наверное, надо "спрашивать" у тех языков об этом.
Языков много, все разные... Есть языки ничуть не менее быстрые чем С++, С например, Паскаль, Fortran. Да и много других.

sherzod_ayvango14. f(new T1, new T2). Допустим, в теле функции f(...) сработало исключение. Очищается ли автоматически память, выделенная для T1 и T2? Если нет, то как её можно очистить, кроме как внутри функции f() (внутри, полагаю, кодом delete T1; delete T2;)? Порядок вычисления передающихся аргументов не известен. Поэтому такой код это верный способ получить утечку при исключении во втором вызвавшемся new. Дальше надо думать головой.

ayvango16. При срезке обычно теряются члены дочерних классов. Допустим, дочерний класс занимал какое-то место в памяти. А куда всё девается область памяти, в которой содержатся члены дочернего класса, при преобразовании его в базовый класс, если речь именно о преобразованиях объекты, а не указателя или ссылки? Информация теряется, но происходит ли утечка памяти? Информация _не_ теряется если _не_ допускать банальную ошибку, объявлением деструкторов _невиртуальными_. Если у вас будут виртуальные деструкторы то апкаст ни к чему плохому не будет приводить. Если в базовом классе невиртуальный деструктор то будут утечки, связанные с невызовом деструктора потомка.



Видимо, тут sherzod_ абсолютно не понимает, о чём речь идёт.
При чём там порядок вычислений в первом случае и виртуальные деструкторы во втором -- вообще не понятно.

sherzod_C++ не быстрее Java. Java не быстрее С++.
...
Плохо когда тебя "закубовывают в рай".

+1
Классный пост! sherzod_ - молодец !

sherzod_ Действительно такой термин имеет место быть. "placement form of operator delete." Судя по описанию placement delete это не совсем то о чем можно подумать. Ушел изучать...

Вкратце --
placement new -- способ вызвать конструктор,
placement delete -- способ вызвать деструктор

32vs64Добавлю, что насколько я помню если компилируешь под 32 бита, то и size_t 32 битный unsigned int.
А если под 64 бита, то size_t 64 битный unsigned long long.

Что, в общем, очень логично

Best practice for exception handling in C++:
- throw by value
- catch by reference, in ascending order of generality (least general types go first)

- кидать про значению
- ловить по ссылке, в порядке увеличения отрешенности типа, т.е. конкретные типы сначала, обобщенные — потом.

[quot вариант с shared_ptr]MasterZivBest practice for exception handling in C++:
- throw by value
- catch by reference, in ascending order of generality (least general types go first)

- кидать про значению
- ловить по ссылке, в порядке увеличения отрешенности типа, т.е. конкретные типы сначала, обобщенные — потом.
А это из какой книги?

Ну из многих. Напр. Из Меерса.


И обработчик исключения держать в виртуальной функции самого этого же исключения - это хороший вариант?

Это все равно.