Доживание чернового варианта до продакшена — особенность программиста, а не языка или платформы.
Так что если у вас на Дельфи все оставалось в сыром виде — то «кроссплатформенность и привычные уже плюшки» не помогут.
Кстати, если уж 10 ничего не писали — то все вашим тезисам о минусах Дельфи грош цена.
Как ни странно, но предлагаемый подход есть антипаттерн, основанный на толковании не самых лучших формулировок Дийкстры.
Причина — структурный переход («вперед-вверх») является вполне законной частью структурного программирования, отнюдь не нарушая принцип «один вход — один выход»: после выхода из подпрограммы управление переходит не куда попало по метке, а строго к следующему оператору (или блоку обработки исключений для raise) в вышестоящей процедуре.
В рассматриваемом примере после рекомендованной модификации добавляется лишний уровень вложенности кода (что резко ухудшает читаемость) без всякой компенсации, кроме моральной. Хорошо еще, что эрзац-флагов не прибывает.
Не совсем — собственно дженерики в Delphi куда лучше плюсовых ввиду нетипизированности последних.
Другое дело, что средств метапрограммирования общего назначения в Delphi нет.
Но и тут у плюсов особых дивидендов нет: там, где кровь из носу требуется метапрограммирование — будут использовать LISP, Nemmerle и т.п.
Все верно, от двойного удаления FreeAndNil не лечит, а маскирует.
Но любое другое использование висячей ссылки после освобождения маскирует уже Free, причем с куда худшими последствиями. Так что если код падает на Free, то сначала надо устранить двойное удаление, а уже потом заменить Free на FreeAndNil — для демаскировки использования висяка.
Этот алгоритм много быстрее DES-подобных (при равной криптостойкости) из-за отсутствия неэффективных на обычной архитектуре операций перестановки битов. Кстати, пост здорово напоминает статью из журнала Монитор бородатых годов.
Пятиэтажки тоже сталинские — вся подготовительная работа проделана до кукурузника.
И ругать их «вообще» не стоит — для своего времени и своих задач они более чем адекватны.
Другое дело — тогда в кошмарном сне не могли увидеть, что в хрущевках будут жить в 2010.
Что же до «старой Москвы» — то сталинские высотки к ней во всех смыслах слова ближе, чем лужковские новоделы.
Прочитал.
Участники дискуссии упускают из вида один важный момент (подробно освещенный по ссылке) — двойное удаление есть лишь частный случай использования висячей ссылки на объект, причем самый безобидный. Зато если после удаления будут вызваны любые другие методы объекта, то в случае использования FreeAndNil будет сразу возбуждено исключение, а Free эту ошибку замаскирует, причем наглухо — падать будет не всегда и совсем не там, где ошибка. Это куда более дорогая цена по сравнению с успешным двойным удалением (которое по факту все равно будет успешным однократным).
А про то, что если в «живом» объекте забыть обнулить одну (не слабую) ссылку на другой объект, который уже не нужен — то сборщик мусора не тронет и забытый объект и все, на что он ссылается.
Плюс утечки памяти — это лишь один из видов утечки ресурсов, причем отнюдь не самый опасный.
Я вовсе не считаю сборщик мусора чем-то лишним или бесполезным, а только лишь указываю, что не стоит преувеличивать его значение в плане защиты от ошибок.
Странно — почему-то ни дотнетных тормозов, ни плюсовых неудобств не замечал, видимо вы лучше меня умеете работать с Delphi.
Напротив — приложения заметно легче и быстрее дотнетных, а язык намного удобнее, чем плюсы, причем не только для человека, но и компилятора. А уж про COM-объекты на плюсах вообще молчу.
Да, генератор кода Delphi никогда изощренностью не отличался, но случаев, когда быстродействия дельфийского кода (после алгоритмических оптимизаций) не хватает и нужна ломовая мощь оптимизатора Intel C Compiler и теоретически очень мало и практически мне не попадалось.
Фраза ни о чем.
Конечно же, такому эксперту и ясновидящему как вы, «судьба и отсутствие шансов» видны даже при полном незнании темы.
А жесткая конкурентная борьба выдвигает наверх тех, кто принимает правильные решения, а не тех, кто задним числом рассказывает про «отсутствие шансов».
Или вы один из тех самых менеджеров? Тогда понимаю, но не сочувствую.
Ясно, на простой и понятный вопрос вы в первый раз прямо ответить не смогли или не захотели.
Но я могу его повторить: могут ли Java и C# при компиляции в нативный код воспользоваться традиционными преимуществами нативных приложений — малые размеры дистрибутива и малые требования к ресурсам?
Я не спрашиваю, считаете ли вы эти преимущества значимыми и мне известно, что такое JIT.
В объеме дистрибутивов приложений, «простоте» установки, требуемых ресурсах, поддержке не COM библиотек, тормозах C# действительно «превзошел» Delphi в несколько раз. Это не говоря о том, что вы даже Win32 от .NET отличить не соизволили.
Про агрегирование (точнее, делегирование реализации интерфейса другому классу) — на уровне языка платформа .NET и C# его не поддерживает. Как паттерн же его можно реализовать хоть в ассемблере. В общем опять судите как о программах, так и об оппонентах, ничего о них не зная, господин тролль.
Вы явно не в курсе истории Delphi, так как стратегию Borland, начиная с восьмой версии, иначе как самоубийственной назвать сложно.
Правильно определив будущий мэйнстрим, избрали самую плохую реализацию из возможных:
1. Положили болт на Win32, в результате ничего не выиграли, зато потеряли основную массу разработчиков, а ведь был хороший шанс занять освобожденную MS нишу.
2. Потащили VCL в .NET — это оказалось не нужно ни для перехода c Win32 (все равно платформы слишком разные) ни для обучения с нуля — исходный фреймворк вполне самодостаточен.
3. Прибили прежнюю IDE и вместо использования Visual Studio сделали свою на .NET — в результате получили отставание по поддерживаемым технологиям, прожорливость по ресурсам и кучу багов.
4. Прибили прежнюю справку и сделали новую с нуля в непотребном мелкомягком формате — в результате медлительность и неполнота справки Delphi стали притчей во языцех.
То что после этого Delphi не умер — наглядный показатель ее силы и качества как языка и инструмента разработки.
Поясняю. Основное преимущество нативных приложений — скромные требования к ресурсам и малый объем дистрибутива.
Могут ли им воспользоваться скомпилированные в нативный код Java и C#?
Откуда эта страсть к наклейке ярлыков? Этак можно Яву назвать средством создания пилорам для корпоративных бабок (что соответствует истине примерно в той же степени как и «средство создания оболочек»).
Хотелось бы увидеть хорошее пользовательское приложение на Яве ;)
Так что если у вас на Дельфи все оставалось в сыром виде — то «кроссплатформенность и привычные уже плюшки» не помогут.
Кстати, если уж 10 ничего не писали — то все вашим тезисам о минусах Дельфи грош цена.
Причина — структурный переход («вперед-вверх») является вполне законной частью структурного программирования, отнюдь не нарушая принцип «один вход — один выход»: после выхода из подпрограммы управление переходит не куда попало по метке, а строго к следующему оператору (или блоку обработки исключений для raise) в вышестоящей процедуре.
В рассматриваемом примере после рекомендованной модификации добавляется лишний уровень вложенности кода (что резко ухудшает читаемость) без всякой компенсации, кроме моральной. Хорошо еще, что эрзац-флагов не прибывает.
Другое дело, что средств метапрограммирования общего назначения в Delphi нет.
Но и тут у плюсов особых дивидендов нет: там, где кровь из носу требуется метапрограммирование — будут использовать LISP, Nemmerle и т.п.
Но любое другое использование висячей ссылки после освобождения маскирует уже Free, причем с куда худшими последствиями. Так что если код падает на Free, то сначала надо устранить двойное удаление, а уже потом заменить Free на FreeAndNil — для демаскировки использования висяка.
И ругать их «вообще» не стоит — для своего времени и своих задач они более чем адекватны.
Другое дело — тогда в кошмарном сне не могли увидеть, что в хрущевках будут жить в 2010.
Что же до «старой Москвы» — то сталинские высотки к ней во всех смыслах слова ближе, чем лужковские новоделы.
Участники дискуссии упускают из вида один важный момент (подробно освещенный по ссылке) — двойное удаление есть лишь частный случай использования висячей ссылки на объект, причем самый безобидный. Зато если после удаления будут вызваны любые другие методы объекта, то в случае использования FreeAndNil будет сразу возбуждено исключение, а Free эту ошибку замаскирует, причем наглухо — падать будет не всегда и совсем не там, где ошибка. Это куда более дорогая цена по сравнению с успешным двойным удалением (которое по факту все равно будет успешным однократным).
Плюс утечки памяти — это лишь один из видов утечки ресурсов, причем отнюдь не самый опасный.
Я вовсе не считаю сборщик мусора чем-то лишним или бесполезным, а только лишь указываю, что не стоит преувеличивать его значение в плане защиты от ошибок.
Напротив — приложения заметно легче и быстрее дотнетных, а язык намного удобнее, чем плюсы, причем не только для человека, но и компилятора. А уж про COM-объекты на плюсах вообще молчу.
Да, генератор кода Delphi никогда изощренностью не отличался, но случаев, когда быстродействия дельфийского кода (после алгоритмических оптимизаций) не хватает и нужна ломовая мощь оптимизатора Intel C Compiler и теоретически очень мало и практически мне не попадалось.
Конечно же, такому эксперту и ясновидящему как вы, «судьба и отсутствие шансов» видны даже при полном незнании темы.
А жесткая конкурентная борьба выдвигает наверх тех, кто принимает правильные решения, а не тех, кто задним числом рассказывает про «отсутствие шансов».
Или вы один из тех самых менеджеров? Тогда понимаю, но не сочувствую.
Но я могу его повторить: могут ли Java и C# при компиляции в нативный код воспользоваться традиционными преимуществами нативных приложений — малые размеры дистрибутива и малые требования к ресурсам?
Я не спрашиваю, считаете ли вы эти преимущества значимыми и мне известно, что такое JIT.
Про агрегирование (точнее, делегирование реализации интерфейса другому классу) — на уровне языка платформа .NET и C# его не поддерживает. Как паттерн же его можно реализовать хоть в ассемблере. В общем опять судите как о программах, так и об оппонентах, ничего о них не зная, господин тролль.
Правильно определив будущий мэйнстрим, избрали самую плохую реализацию из возможных:
1. Положили болт на Win32, в результате ничего не выиграли, зато потеряли основную массу разработчиков, а ведь был хороший шанс занять освобожденную MS нишу.
2. Потащили VCL в .NET — это оказалось не нужно ни для перехода c Win32 (все равно платформы слишком разные) ни для обучения с нуля — исходный фреймворк вполне самодостаточен.
3. Прибили прежнюю IDE и вместо использования Visual Studio сделали свою на .NET — в результате получили отставание по поддерживаемым технологиям, прожорливость по ресурсам и кучу багов.
4. Прибили прежнюю справку и сделали новую с нуля в непотребном мелкомягком формате — в результате медлительность и неполнота справки Delphi стали притчей во языцех.
То что после этого Delphi не умер — наглядный показатель ее силы и качества как языка и инструмента разработки.
Могут ли им воспользоваться скомпилированные в нативный код Java и C#?
Хотелось бы увидеть хорошее пользовательское приложение на Яве ;)