Comments 43
Все правильно, но статью можно сократить до: «Придерживайтесь стандартов».
О боги, о чем речь — если вы пришли к необходимости написать код проверяющий this на ноль, вы до этого что-то сделали не так.
Don't use MFC :)
Это еще что, я один раз, когда встретился с MFC и его указателями, долго думал, можно ли писать delete this. Так оказывается, что можно :)
del
Очень нерепрезентативная ссылка, при всём уважении к Алёне.
В общем случае неизвестно, где ещё есть указатели на this, а они могут быть в том числе в сторонних либах, и что конкретно делает деструктор, который в случае MFC является обёрткой над win32 api, и, вполне вероятно, закрывает нижележащий хэндл, который опять же может висеть неизвестно где.
Ну да, да, плохой дизайн и всё такое, но не стоит забывать, что на момент разработки MFC с одной стороны было системное api на С, к которому нужно было обеспечить прямой (читай, быстрый) доступ из С++, с другой — стандартная библиотека С++ пребывала в зачаточном и убогом в смысле поддержки состоянии, а с третьей — Майерс, Александреску и банда четырёх ещё только планировали свои книги.
В общем случае неизвестно, где ещё есть указатели на this, а они могут быть в том числе в сторонних либах, и что конкретно делает деструктор, который в случае MFC является обёрткой над win32 api, и, вполне вероятно, закрывает нижележащий хэндл, который опять же может висеть неизвестно где.
Ну да, да, плохой дизайн и всё такое, но не стоит забывать, что на момент разработки MFC с одной стороны было системное api на С, к которому нужно было обеспечить прямой (читай, быстрый) доступ из С++, с другой — стандартная библиотека С++ пребывала в зачаточном и убогом в смысле поддержки состоянии, а с третьей — Майерс, Александреску и банда четырёх ещё только планировали свои книги.
Хотите безопасный null — пишите на Objective C ;)
Ага, одну проблему замени другой, вам не кажется не правильным формула — вызови метод из нулевого указателя и получи нулевой указатель в возвращемом значении? Особенно если ждеш дaлеко не этого.
UFO just landed and posted this here
Ну я и не говорю что это идеальное решение. Единственный 100% верный вариант решения этой проблемы — отказаться от null вообще и использовать Maybe
Ох уж эти аналитики сферических коней в вакууме.
Как красиво и логично рассуждать о правильном создании\удалении объектов на программах размеров в пару десятков классов, кушающих от силы пару десятков мегабайт ОЗУ. А вот что бывает на практике в настоящих проектах.
Есть такой себе движок для Javascript — V8. Используется в таких малоизвестных проектах как Google Chrome и Node.js, например. Так вот, менеджерение ресурсов и сборка мусора в проектах такого масштаба — штука сильно сложная, и на примитивной логике деструкторов её не реализовать — будет либо тормозить, либо глючить. И вот что же мы видим в главном header-файле v8.h?
А знаете сколько всего раз
А мысль в общем: «никогда не говорите „никогда“».
Как красиво и логично рассуждать о правильном создании\удалении объектов на программах размеров в пару десятков классов, кушающих от силы пару десятков мегабайт ОЗУ. А вот что бывает на практике в настоящих проектах.
Есть такой себе движок для Javascript — V8. Используется в таких малоизвестных проектах как Google Chrome и Node.js, например. Так вот, менеджерение ресурсов и сборка мусора в проектах такого масштаба — штука сильно сложная, и на примитивной логике деструкторов её не реализовать — будет либо тормозить, либо глючить. И вот что же мы видим в главном header-файле v8.h?
virtual void Dispose() { delete this; }
А знаете сколько всего раз
delete this встречается в исходниках V8? 63 раза. О том, нафига оно так и каким образом там освобождаются ресурсы можно почитать тут. А мысль в общем: «никогда не говорите „никогда“».
Какая связь между использованием delete this и сравнением this с нулем?
Да тоже, в общем-то, сомнительная практика.
Может быть такая, что после вызова Dispose(), который сделает «delete this» у вас останется в наличии указатель, с которым дальше может произойти всё, что угодно (в том числе и вызов по нему следующего метода — а кто ж помешает?)
Но и после обычного
delete a; в указателе «a» такой же мусор.Ага, вот только
delete a никого не ужасает, равно как и тот факт, что после этого его использовать не надо. А вот комментарий "О боги, о чем речь — если вы пришли к необходимости написать код проверяющий this на ноль, вы до этого что-то сделали не так" — вон выше +38 набрал, хотя суть то та же самая — ручное управление временем жизни ресурса и связанные с этим неудобства типа необходимости доп. проверок.
Помнится это уже обсуждали
На самом деле, довольно печально, что все еще возникают вопросы, почему не нужно использовать оператор -> у нулевых указателей.
UFO just landed and posted this here
Чем больше знаешь C++ тем больше ты его не знаешь.
Это стандартное состояние человека, пишущего на плюсах. Даже через несколько лет непрерывного хождения по граблям.
* Это стандартная суперпозиция знаний человека в области плюсов в произвольно взятый момент времени :)
Могу Вас успокоить — и через 20 лет это все равно не проходит :)
На самом деле, через несколько лет начинаешь ценить динамические языки для высокоуровневой логики и прототипирования, вынося в плюсы/чистый С только ресурсоёмкие либы.
Самое главное в жизни программиста — это его затраченное время.
Самое главное в жизни программиста — это его затраченное время.
Сильно зависит от области. У меня (вычислительные задачи, высокопроизводительные системы, иногда мягкий real time) в большинстве случаев не получается. Хотя скриптовые языки (lua) использую широко — везде, где только возможно. Уже давно хотелось бы иметь что-то типа D, но когда оно еще дойдет до готовности к использованию в боевых системах. Да и с годами я как-то все больше начинаю ценить простоту, а в D с этим тоже не очень.
«Мягкий реалтайм» это оксюморон. Реалтайм бывает либо жёсткий (когда не успел посчитать — значит отбрасывай), либо это не реалтайм. «Как бы надо уложиться в 40 мс» — это не пункт ТЗ, а строка художественного романа.
Для вычислительных задач все низкоуровневые либы (читай решение СЛАУ, дифур, Фурье, вейвлеты и пр.) давно написаны и заоптимизированы производителями оборудования (intel,nvidia, etc). Разницы, вызывать их из С или из JS — нет. Если вы не можете свести свою задачу к стандартным — наймите математика. Если вы не можете прикрутить к своему проекту условный icc — наймите того, кто сможет.
Высокопроизводительные системы — очень расплывчатое понятие «ни о чём», примерно как «мягкий реалтайм».
В-общем, весь вопрос во взгляде архитектора и менеджера. Если в команде «только хардкор, только плюсы» и никто не считает деньги — то да, городим велосипеды. Если это космос на советских ТТЛШ или дешевый девайс на тупых копеечных SOIC — то тоже да, тоже городим велосипеды. В остальных случаях нет.
Для вычислительных задач все низкоуровневые либы (читай решение СЛАУ, дифур, Фурье, вейвлеты и пр.) давно написаны и заоптимизированы производителями оборудования (intel,nvidia, etc). Разницы, вызывать их из С или из JS — нет. Если вы не можете свести свою задачу к стандартным — наймите математика. Если вы не можете прикрутить к своему проекту условный icc — наймите того, кто сможет.
Высокопроизводительные системы — очень расплывчатое понятие «ни о чём», примерно как «мягкий реалтайм».
В-общем, весь вопрос во взгляде архитектора и менеджера. Если в команде «только хардкор, только плюсы» и никто не считает деньги — то да, городим велосипеды. Если это космос на советских ТТЛШ или дешевый девайс на тупых копеечных SOIC — то тоже да, тоже городим велосипеды. В остальных случаях нет.
Вы, батенька, совершенно не в теме.
Мягкий риалтайм (fort realtime) — это общепринятый термин, наряду с другими видами. Ваши собственные верования тут имеют как бы мало ценности.
А это — широко распространенная легенда, в которую нравится верить тем, у кого с математикой проблемы. Для простейших применений действительно кое-что доступно, но я еще не встречал реальной задачи, в которой этого бы хватало. Кроме того есть масса математики, для которой никаких реализаций не доступно и масса случаев, когда под конкретную задачу разрабатываются совершенно новые математические методы. Нам тут больше всего нравится именно эта ниша, поскольку туда редко лезут «программисты», но и в обычных областях приходится подвизаться, когда эти «заоптимизированные» решения почему-то перестают справляться в конкретной задаче и приходится заменять их на «велосипед», который продолжает ехать.
Типичная позиция программиста в худшем смысле этого слова. Мы тут как бы все математики (ага, т.н. «действующие», т.е. с фамилиями, узнаваемыми в сообществе математиков по публикациям) и все программируем профессионально. Как ни странно, такое быват, хотя и стоит очень дорого :)
Как раз опыт и умение считать деньги приводит к разработке кастомных решений, которые хорошо масштабируются в рамках той задачи, которая решается, а не под абстрактную «сферическую задачу в вакууме». А жертвы самоуверенных кодеров потом приходят со своими вроде бы работающими хреновинами и желанием, чтобы оно действительно работало и удивляются, почему сумма получается 6-значной. Но ничего, платят и получают бесценный опыт.
Реалтайм бывает либо жёсткий (когда не успел посчитать — значит отбрасывай), либо это не реалтайм.
Мягкий риалтайм (fort realtime) — это общепринятый термин, наряду с другими видами. Ваши собственные верования тут имеют как бы мало ценности.
Для вычислительных задач все низкоуровневые либы (читай решение СЛАУ, дифур, Фурье, вейвлеты и пр.) давно написаны и заоптимизированы производителями оборудования (intel,nvidia, etc).
А это — широко распространенная легенда, в которую нравится верить тем, у кого с математикой проблемы. Для простейших применений действительно кое-что доступно, но я еще не встречал реальной задачи, в которой этого бы хватало. Кроме того есть масса математики, для которой никаких реализаций не доступно и масса случаев, когда под конкретную задачу разрабатываются совершенно новые математические методы. Нам тут больше всего нравится именно эта ниша, поскольку туда редко лезут «программисты», но и в обычных областях приходится подвизаться, когда эти «заоптимизированные» решения почему-то перестают справляться в конкретной задаче и приходится заменять их на «велосипед», который продолжает ехать.
Если вы не можете свести свою задачу к стандартным — наймите математика. Если вы не можете прикрутить к своему проекту условный icc — наймите того, кто сможет.
Типичная позиция программиста в худшем смысле этого слова. Мы тут как бы все математики (ага, т.н. «действующие», т.е. с фамилиями, узнаваемыми в сообществе математиков по публикациям) и все программируем профессионально. Как ни странно, такое быват, хотя и стоит очень дорого :)
никто не считает деньги — то да, городим велосипеды
Как раз опыт и умение считать деньги приводит к разработке кастомных решений, которые хорошо масштабируются в рамках той задачи, которая решается, а не под абстрактную «сферическую задачу в вакууме». А жертвы самоуверенных кодеров потом приходят со своими вроде бы работающими хреновинами и желанием, чтобы оно действительно работало и удивляются, почему сумма получается 6-значной. Но ничего, платят и получают бесценный опыт.
Sign up to leave a comment.
Вы все еще кипятите и сравниваете this с нулем?