Есть консольная утилита NETZ, которая заворачивает ваши сборки в одну автоматически.
К сожалению, с WPF она работает некорректно, но зато подходит для консольных и WinForms приложений.
А для WPF можете попробовать мою реализацию аналогичной утилиты NBox nbox.codeplex.com
Не так давно сам заворачивал довольно большую WPF-программу (порядка 15-20 сборок в зависимостях).
Чем дальше идет профессиональное развитие, тем сильнее сглаживаются различия между талантливыми людьми и не такими талантливыми, как они, но такими же целеустремленными.
Одна учительница, еще в школе, говорила про это так:
1. Главное — это систематичность труда.
2. Талант — 5 процентов результата, остальные 95 — усердный труд.
Тогда мы посмеивались, передразнивали ) А ведь правда на все 100. Особенно первый пункт.
Действительно странно, что дефолтные значения аргументов так поздно решили прикрутить. Особенно с учетом того, что это — не более чем синтаксический сахар.
На месте девелоперов я бы еще в C# 2.0 их воткнул. )
Здесь, скорее наоборот, если адрес переполняемого буфера находился в куче, тогда не в .text перезаписываются данные, а в .data — шеллкод. И страница .data может оказаться не защищенной от выполнения в ней кода.
Вот лично мне доставляли неудовольствие квип-акки только до того момента, как я узнал про /isolated.
Последние несколько месяцев ношу последний стабильный билд на флешке, с ярлыком, настроенным на запуск с параметром /isolated.
И все прекрасно, никаких проблем. Спасибо разработчикам за удобный и стабильный продукт.
По идее, упасть должно или некорректные данные прочитать из стека или из кучи.
Наверное, код был редко выполняющимся. И все равно непонятно, как программер, писавший это, не удосужился протестировать метод оО. Неужели белиберда, прочитанная из стрима, настолько была похожа на правду? )
Как дотнетчик, недавно взявшийся за Obj-C, скажу, что в этих нюансах и сконцентрирована основная сложность перехода на новую платформу. Особенно если раньше имел некоторый опыт программирования на С++ — смешивать ОО-модель плюсов и obj-C непросто, и это часто приводит к неэлегантным решениям (начиная с организации callback-вызовов obj-c кода из С++ и заканчивая нестандартным управлением памятью).
Это не самое важное. Как я только что написал выше, цель List<> по сравнению с ArrayList — обеспечить интерфейс, безопасный по отношению к типам. Отсутствие боксинга — это не причина, а следствие появления обобщений (generics) C#.
> главный плюс типизированных коллекций — возможность избавиться от приведения типов
Я бы сказал, что основным здесь является не желание избавиться от явного кастинга, а то, что пользовательский код должен быть безопасным по отношению к типам, т.е. чтобы в коллекцию можно было добавлять объекты только указанного типа (или типа, неявно приводимого к указанному, например, производного от него). И чтобы компилятор мог осуществить верификацию этого кода на этапе компиляции (шаблоны C++, generics C#, Java).
К сожалению, такие проверки в PHP не могут быть реализованы на этапе трансляции и могут обернуться потерей производительности в рантайме.
Однако, есть несложный обходной путь: использовать макросредства и заключить код проверки типов в нечто вроде
#ifdef DEBUG
… проверка типов
#endif
в этом случае в режиме DEBUG коллекция будет безопасной по отношению к типам, а в режиме RELEASE будет иметь производительность, близкую к оригинальной.
Правда, я не в курсе, есть ли в PHP макросредства, аналогичные сишным. Если нет, то придется наваять свой маленький макропроцессор )
Total rocks. Больше всего нравилась сборка podarok edition, жаль только, что там вьювер был глючный и часто падал, что особенно раздражало при интенсивной навигации по множеству исходников и XML-файлов. К сожалению, похоже, что podarok не обновляется.
и я разочарован.
К сожалению, с WPF она работает некорректно, но зато подходит для консольных и WinForms приложений.
А для WPF можете попробовать мою реализацию аналогичной утилиты NBox nbox.codeplex.com
Не так давно сам заворачивал довольно большую WPF-программу (порядка 15-20 сборок в зависимостях).
учиться, учиться и учиться — вот требование образования и упорства в одном флаконе )
1. Главное — это систематичность труда.
2. Талант — 5 процентов результата, остальные 95 — усердный труд.
Тогда мы посмеивались, передразнивали ) А ведь правда на все 100. Особенно первый пункт.
На месте девелоперов я бы еще в C# 2.0 их воткнул. )
Последние несколько месяцев ношу последний стабильный билд на флешке, с ярлыком, настроенным на запуск с параметром /isolated.
И все прекрасно, никаких проблем. Спасибо разработчикам за удобный и стабильный продукт.
Наверное, код был редко выполняющимся. И все равно непонятно, как программер, писавший это, не удосужился протестировать метод оО. Неужели белиберда, прочитанная из стрима, настолько была похожа на правду? )
Я бы сказал, что основным здесь является не желание избавиться от явного кастинга, а то, что пользовательский код должен быть безопасным по отношению к типам, т.е. чтобы в коллекцию можно было добавлять объекты только указанного типа (или типа, неявно приводимого к указанному, например, производного от него). И чтобы компилятор мог осуществить верификацию этого кода на этапе компиляции (шаблоны C++, generics C#, Java).
К сожалению, такие проверки в PHP не могут быть реализованы на этапе трансляции и могут обернуться потерей производительности в рантайме.
Однако, есть несложный обходной путь: использовать макросредства и заключить код проверки типов в нечто вроде
#ifdef DEBUG
… проверка типов
#endif
в этом случае в режиме DEBUG коллекция будет безопасной по отношению к типам, а в режиме RELEASE будет иметь производительность, близкую к оригинальной.
Правда, я не в курсе, есть ли в PHP макросредства, аналогичные сишным. Если нет, то придется наваять свой маленький макропроцессор )