Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
sherzod_ Действительно такой термин имеет место быть. "placement form of operator delete." Судя по описанию placement delete это не совсем то о чем можно подумать. Ушел изучать... Вкратце -- placement new -- способ вызвать конструктор, placement delete -- способ вызвать деструктор ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2012, 22:39 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
32vs64Добавлю, что насколько я помню если компилируешь под 32 бита, то и size_t 32 битный unsigned int. А если под 64 бита, то size_t 64 битный unsigned long long. Что, в общем, очень логично ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2012, 22:43 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
MasterZivавторТот же вопрос в том случае, когда объект создан в куче, а его поля -- на стеке. Это -- ошибка проектирования Объект при этом создан естественно в куче. Только как он будет жить при выходе из скопа автоматических объектов, на которые он ссылается -- не понятно. Такое иногда допустимо, если он ссылается на автоматические переменные в функцие main, например. Да это не то что ошибка, это в принципе не возможно - создать объект в куче, а его члены данные на стеке. Оно уже все будет в куче. автор14. f(new T1, new T2). Допустим, в теле функции f(...) сработало исключение. Очищается ли автоматически память, выделенная для T1 и T2? Если нет, то как её можно очистить, кроме как внутри функции f() (внутри, полагаю, кодом delete T1; delete T2;)? В любом случае этот код не правилен. Конечно объекты сами не будут удаляться. Даже с использованием shared_ptr boost::shared_ptr BestPractices Видимо, тут sherzod_ абсолютно не понимает, о чём речь идёт. При чём там порядок вычислений в первом случае и виртуальные деструкторы во втором -- вообще не понятно. А он видимо имеет ввиду вариант с shared_ptr по ссылке выше: ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 01:03 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
MasterZivТонкий момент. Точно не знаю. Видимо, не должна очищаться. При аналогичном почти случае внутри инициализаторов конструктора очищается автоматом. Имеется ввиду если в списке инициализации конструктора класса выделяется динамическая память в куче, то при выбросе исключения до того как объект будет создан и выполниться конструктор, эта динамическая память освобождается? MasterZivавтор18. Верно ли, что ислючения всегда передаются по значению, автордаже если стоит что-то типа catch(ExepClass& ex){} или catch(ExepClass* ex){}, всё равно будет передана копия выброшенного объекта, а всякие ссылки и указатели нужны у catch только для полиморфизма? Нет, это совсем неверно. Если будет кидаться объект по значению, а ты будешь ловить указатель, то просто данный catch ничего не поймает. И наоборот, если кидается указатель, а ловится ссылка или значение, тоже не поймаешь. Ловля по значению и по ссылке отличается лиш тем, что при ловле по значению происходит дополнительное копирование (и возможно срезка). А есть здесь какой-то best practice, допустим кидать объект по значению, а ловить его полиморфно по ссылке базового класса, и уже по этой ссылке вызывать виртуальную функцию которая и обработает это исключение? MasterZivавторЕсли передана копия, то верно ли, что даже если try-catch стоят вместе (catch тут же отлавливает возможные исключения), то всё равно в catch передаётся копия выброшенного объекта? Да. А RVO или move constructor тут не работают? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 01:04 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
вариант с shared_ptrВ любом случае этот код не правилен. Конечно объекты сами не будут удаляться. Даже с использованием shared_ptr boost::shared_ptr BestPractices shared_ptr надо создавать через make_shared<..>(...) и тогда все ок. При чём там порядок вычислений в первом случае и виртуальные деструкторы во втором -- вообще не понятно. А он видимо имеет ввиду вариант с shared_ptr по ссылке выше: Кстати shared_ptr (по крайней мере бустовскому) не нужен виртуальный деструктор для нормального удаления потомка. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 03:14 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
вариант с shared_ptrА есть здесь какой-то best practice, допустим кидать объект по значению, а ловить его полиморфно по ссылке базового класса, и уже по этой ссылке вызывать виртуальную функцию которая и обработает это исключение? ... А RVO или move constructor тут не работают? Кидать исключение по значению и ловить по ссылке - это в принципе единственный разумный вариант. Если вы будете кидать указатели (new) - то надо не только ловить но и удалять . А если кидать и ловить по значению - то будет никому ненужное копирование, которого нет при ловле по ссылке, и поэтому никакой оптимизации тут не нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 03:38 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovskyвариант с shared_ptrВ любом случае этот код не правилен. Конечно объекты сами не будут удаляться. Даже с использованием shared_ptr boost::shared_ptr BestPractices shared_ptr надо создавать через make_shared<..>(...) и тогда все ок. А std::make_shared<..>(...) в новом стандарте принимает и передает в конструктор любое количество параметров через вариадические шаблоны? Anatoly Moskovsky При чём там порядок вычислений в первом случае и виртуальные деструкторы во втором -- вообще не понятно. А он видимо имеет ввиду вариант с shared_ptr по ссылке выше: Кстати shared_ptr (по крайней мере бустовскому) не нужен виртуальный деструктор для нормального удаления потомка. Код: plaintext 1. 2. А как и в чем он начальный тип запоминает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 03:51 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
вариант с shared_ptrА std::make_shared<..>(...) в новом стандарте принимает и передает в конструктор любое количество параметров через вариадические шаблоны? Ну наверно, иначе зачем тогда вариадик нужен :) Код: plaintext 1. 2. А как и в чем он начальный тип запоминает? Конструктор у boost::shared_ptr шаблонный, он выводит и сохраняет тип аргумента внутри shared_ptr (в так называемом deleter, который юзер и сам может предоставлять указателю, если надо) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 04:05 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
MasterZivавторТолько из-за другого распределения памяти (в Java вся ответственность на сборщике мусора, что замедляет вычисления)? Вот тут есть один момент, который существенно влияет на "почему плюсы считаются быстрее Java". В Java часто (почти всегда) перераспределение памяти может возникать в любой момент работы программы. Ну вообще просто тупо почти всегда. Поэтому её не любят создатели ПО, которое расчитано на маленькие задержки, или почти или полностью realtime. Ну действительно -- ты тут считашь что-то, считаеш, торопишся, ещё милисекудна, ещё пол милисекунды осталось -- а тут бац -- и сборщик мусора заработал. В С++ выделение и освобождение памяти всегда детерминировано, предсказуемо. Когда оно произойдёт -- всегда известно. Поэтому такое ПО писать легче. А как с этим дела обстоят в С# или в .NET в целом? Так же? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 10:55 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
Best practice for exception handling in C++: - throw by value - catch by reference, in ascending order of generality (least general types go first) - кидать про значению - ловить по ссылке, в порядке увеличения отрешенности типа, т.е. конкретные типы сначала, обобщенные — потом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 12:07 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
MasterZivBest practice for exception handling in C++: - throw by value - catch by reference, in ascending order of generality (least general types go first) - кидать про значению - ловить по ссылке, в порядке увеличения отрешенности типа, т.е. конкретные типы сначала, обобщенные — потом. А это из какой книги? И обработчик исключения держать в виртуальной функции самого этого же исключения - это хороший вариант? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 15:14 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovsky Код: plaintext 1. 2. А как и в чем он начальный тип запоминает? Конструктор у boost::shared_ptr шаблонный, он выводит и сохраняет тип аргумента внутри shared_ptr (в так называемом deleter, который юзер и сам может предоставлять указателю, если надо) А, там шаблонный функтор-deleter на который в shared_ptr полиморфно храниться указатель базового типа. Т.е. shared_ptr хранит 3 указателя: на объект, на счетчик и на функтор-deleter. И если использовать make_shared<..>(...) то в куче выделяется память один раз, а если не использовать, то 3 раза? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 15:21 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
вариант с shared_ptrИ обработчик исключения держать в виртуальной функции самого этого же исключения - это хороший вариант? Это бессмысленный вариант. Все равно что сказать: вот у меня функция F() но присваивать ее результат вы можете только в переменную A. Если бы объекту исключения было известно как самого себя обрабатывать, то смысла бросать исключения нет - сразу бы его и обрабатывали. Но обычно ничего такого не известно. Одно и то же исключение в разном контексте обрабатывается по-разному. Поэтому невозможно в исключении держать обработчик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 15:24 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
вариант с shared_ptrТ.е. shared_ptr хранит 3 указателя: на объект, на счетчик и на функтор-deleter. И если использовать make_shared<..>(...) то в куче выделяется память один раз, а если не использовать, то 3 раза? deleter хранится со счетчиком в одном объекте. make_shared да, оптимизирует выделение памяти под вспомогательные объекты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 15:27 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovskyвариант с shared_ptrИ обработчик исключения держать в виртуальной функции самого этого же исключения - это хороший вариант? Это бессмысленный вариант. Все равно что сказать: вот у меня функция F() но присваивать ее результат вы можете только в переменную A. Если бы объекту исключения было известно как самого себя обрабатывать, то смысла бросать исключения нет - сразу бы его и обрабатывали. Но обычно ничего такого не известно. Одно и то же исключение в разном контексте обрабатывается по-разному. Поэтому невозможно в исключении держать обработчик. Конечно всю обработку в самом исключении не сделаешь, но запись в лог-файл через потокобезопасный синглтон сделать можно. Хотя наверное лучше писать в лог в конструкторе базового класса исключения заодно используя __LINE__, __FILE__, __DATE__, __TIME__, __func__ , т.к. он как раз для всех наследуемых исключений выполнится в месте самого исключения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 16:45 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
вариант с shared_ptrХотя наверное лучше писать в лог в конструкторе базового класса исключения заодно используя __LINE__, __FILE__, __DATE__, __TIME__, __func__ , т.к. он как раз для всех наследуемых исключений выполнится в месте самого исключения. Если вы это имеете в виду Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. то это не будет работать, т.к. подставится значение макроса не для места вызова конструктора, а для самого конструктора. Чтобы правильно работало, надо само создание объекта исключения оборачивать в макрос и из него передавать все эти атрибуты вызывающего кода через аргументы конструктора. А с макросами уже не так приятно иметь дело. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 17:04 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovskyвариант с shared_ptrХотя наверное лучше писать в лог в конструкторе базового класса исключения заодно используя __LINE__, __FILE__, __DATE__, __TIME__, __func__ , т.к. он как раз для всех наследуемых исключений выполнится в месте самого исключения. Если вы это имеете в виду Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. то это не будет работать, т.к. подставится значение макроса не для места вызова конструктора, а для самого конструктора. Чтобы правильно работало, надо само создание объекта исключения оборачивать в макрос и из него передавать все эти атрибуты вызывающего кода через аргументы конструктора. А с макросами уже не так приятно иметь дело. Да, фактически надо будет что-то типа: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. Макросы конечно не приятно, но а какой другой выход если хочется в логах как можно точнее знать место исключения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 20:34 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
вариант с shared_ptr Код: plaintext 1. 2. 3. 4. 5. Бррр... Надеюсь такой изврат никогда не увидеть в коде с которым мне придется работать. Если вы уже используете макрос при вызове исключения, то в нем и логируйте. Откладывать логирование до поимки и потом tot ловить ... это антипаттерн (даже два). Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 20:50 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovskyвариант с shared_ptr Код: plaintext 1. 2. 3. 4. 5. Бррр... Надеюсь такой изврат никогда не увидеть в коде с которым мне придется работать. Если вы уже используете макрос при вызове исключения, то в нем и логируйте. Откладывать логирование до поимки и потом tot ловить ... это антипаттерн (даже два). Код: plaintext 1. 2. 3. 4. 5. Смотрите, ваш подход будет логировать только те исключения, которые кидаете именно вы. А если есть: - сторонняя dll-библиотека, которая кидает исключения - чужой cpp-код, который кидает исключения - исключения которые кидают std::dynamic_cast, new и т.д. То как вы предложите логировать эти исключения? А какие именно 2 проблемы (2 антипатерна) вот такого подхода? Ну, помимо того, что в каждом catch придется писать log_exception(); Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2012, 22:02 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
[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) - кидать про значению - ловить по ссылке, в порядке увеличения отрешенности типа, т.е. конкретные типы сначала, обобщенные — потом. А это из какой книги? Ну из многих. Напр. Из Меерса. И обработчик исключения держать в виртуальной функции самого этого же исключения - это хороший вариант? Это все равно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2012, 01:35 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
вариант с shared_ptr, Суть в том что исключения - это не обязательно ошибки. Так что логировать все подряд нет смысла. Более того концепция исключений предусматривает возможность не ловить их где не нужно по логике программы. Это самая важная возможность исключений, которая позволяет писать простой и надежный код. Если для вашей фичи нужно обязательно ловить исключения, то это фактически нивелирует все преимущества исключений. При этом я не отрицаю что в программе на самом верхнем уровне вложенности кода (обычно это тело цикла событий потока) может быть перехватчик всех непойманных исключений с логированием того факта что исключение не поймано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2012, 14:46 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovskyвариант с shared_ptr, Суть в том что исключения - это не обязательно ошибки. Так что логировать все подряд нет смысла. Более того концепция исключений предусматривает возможность не ловить их где не нужно по логике программы. Это самая важная возможность исключений, которая позволяет писать простой и надежный код. Если для вашей фичи нужно обязательно ловить исключения, то это фактически нивелирует все преимущества исключений. При этом я не отрицаю что в программе на самом верхнем уровне вложенности кода (обычно это тело цикла событий потока) может быть перехватчик всех непойманных исключений с логированием того факта что исключение не поймано. В принципе со всем согласен. Но действительно есть места, где необходимо обязательно ловить исключения и либо тут же их обрабатывать, либо логировать место их первой поимки и посылать их для обработки выше. Например в перечисленных мною же случаях при исключениях выходящих из библиотек, чужого кода и из std. Если внутри самой библиотеки/чужого кода исключение не поймано и выходит наружу, значит это уже ошибка, а не рабочий момент. И желательно знать где оно произошло. Аналогично и с bad_cast, bad_alloc и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2012, 15:28 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
вариант с shared_ptrИ желательно знать где оно произошло. Аналогично и с bad_cast, bad_alloc и т.д. Узнать место можно только при бросании исключения. Если вы споймали bad_alloc или другое чужое исключение вы никак не узнаете откуда оно брошено. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2012, 15:50 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovskyвариант с shared_ptrИ желательно знать где оно произошло. Аналогично и с bad_cast, bad_alloc и т.д. Узнать место можно только при бросании исключения. Если вы споймали bad_alloc или другое чужое исключение вы никак не узнаете откуда оно брошено. Локализую это место насколько можно точнее и выбор будет из 3 new, а не из 100. Тоже касается и чужих dll/cpp, по крайней мере я пойму из какой именно библиотеки и функции исключение. А по DATE TIME я пойму, когда компилился исходник вызывающий чужой код и найду эту версию в SVN/GIT. Зачастую если проект является не заказным решением, а коробочным продуктом, то невозможно ни получить от клиента адекватное описание бага, ни получить из-за коммерческой тайны входные данные воспроизводящие баг, ни отдебажить пошагово на стороне клиента. Так что лог и в лучшем случае дампы - это все, что от них можно получить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2012, 16:26 |
|
||
|
Ещё несколько вопросов начинающего программиста
|
|||
|---|---|---|---|
|
#18+
Можно как-то числовую константу __LINE__ взять в кавычки, чтобы не выдумывать всякие stream2string(). Что-то типа: #define THROW_PLACE std::string() + __FILE__ + ": " + "__LINE__" А то тут в кавычках подставится не значение константы __LINE__, а сама надпись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2012, 13:34 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=38059841&tid=2020626]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
167ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 15ms |
| total: | 283ms |

| 0 / 0 |
