Чего мне больше всего не хватает в Тотал коммандере, так это:
1) Нормальной поддержки Юникод (В некоторых местах приходится пользоваться explorerом)
2) Выполнение правой и левой панели в разных потоках.
Это просто не нужно. Если на документе есть фотография человека, то обычная ксерокопия уже сама по себе является заверенной копией документа. ВЗПчка - делают копию - и её при желании можно заверить.
Очень хорошая вещь для шантажа 5 и 6 значных номеров. С кучи номеров отослать ICQ System нужный номерок и всё? Ведь некоторые аськи покупают, и вполне смогут заплатить некоторую сумму для откупа.... IMHO бред какой то... Думается мне он для других целей задуман.
Хм, не понимаю когда private и protected выносят в начало... На них так часто внимание обращается? Может лучше public конструкторы, потом public методы, потом public property, а дальше public fields? Хоть сразу видно как работать с объектом... Ну а остальное в удобном порядке по принытому шаблону...
Писал только, чтобы вспомнить javascript.
javascript:function SpeedUp(func,speed){var raw=document.getElementById("typetext");if(raw==null){window.setTimeout(SpeedUp,100,func,speed);return;}var result=raw.innerHTML.replace(/
Прошу меня извинить, что вот я уже на протяжении двух статей докапываюсь к автору, просто я не согласен с его мнением. Дизайн паттерны http://en.wikipedia.org/wiki/Design_patt…(computer_science) заслуживают отдельной ветки, и они не совсем связаны с кодогенерацией.
Мне просто не приятно как разработчику читать такие статьи, когда говориться не зная про что. Чтобы вы не приняли мои слова за пустоту, постараюсь вам объяснить. Я разработчик ПО для ОПСОСов. Одной из моих задач является создание сценариев поведения при звонках, это обработка биллинга, разрешение абоненту звонить/получать и отправлять другие виды траффика. Все сценарии выглядят однотипно, в виде блоков. Блоки это обращение к разным системам за информацией. То есть легче написать приложение, куда выносишь эти блоки граффически, делаешь между ними связи и вперёд, генеришь нужный код, потом его компилишь.
А теперь вернёмся к этой статье.
Кодогенерация по большому счёту создание кода, который схож между собой, но, например, последовательность его разная, или разные стуктуры данных (например код для каждой таблицы в базе данных со своими полями). Вот для этого используется кодогенерация, чтобы не писать почти одно и тоже тысячу раз, а позволить это делать программе.
Автор же в этой статье пытается всунуть Дизайн паттерны, которые имею совсем другой смысл, и не связаны с кодогенерацией. Дизайн паттерны указывают на стиль написания вашего кода, но они никогда не заменяют кодогенерацию или как то связаны с ней, наоборот, в кодогенерации сгенерированный код может быть по какому-то из шаблонов, но рассматривать все стили программирования чтобы объяснить кодогенерацию это бред.
Кто хочет разобраться побольше с Дизайн паттернами советую посмотреть на Spring.NET(http://www.springframework.net).
Возвращаясь к статье, хочу сказать, нет, она в приципе не плохая, ну конечно неполно написано, но в целом нормально, но она не по адресу.
Вы ссылаетесь на источник, но при этом сами НЕ понимаете вопрос. Я бы вам хотел прояснить это, и всем людям, которые тоже ДОВЕРЯЮТ статьям, при этом отключают голову для анализа, и не разбираются в проблеме.
А теперь этапы компиляции:
1) Разбиение на токены
2) Проверка синтаксиса и семантики
3) Кодогенерация (например на asm)
4) Компиляция
И это только с моим скудным познанием компиляторов, который я ещё помню с университета, когда приходилось их писать. Уверен профессионалы укажут больше стадий. Но кодогенерация, как раз является частью процесса компиляции. И тут уже не поспоришь. НО если рассмативать компиляцию в общем виде, как перевод из одного в другой, то да можно так сказать, как написано в английском варианте. Но пожалуйста, голову то используйте, перед тем как давать ссылки на статьи. Их надо ПРАВИЛЬНО читать. Удачи.
Не знаю зачем меня заминусовали, никто мою идею не понял, поэтому объясню ещё раз. Я не придираюсь ко всей статье, я лишь хочу сказать, что это немного некорректно приводить ТАКОЙ пример LINQ как кодогенератора, а потом говорить, что компиляция это часть кодогенерации. Либо автор не совсем понимает и ещё не использовал LINQ в своих проектах. Я бы и слова не сказал, если бы привели пример ДЕЙСТВИТЕЛЬНОЙ кодогенерации например cпециальную утилиту КОДОГЕНЕРАЦИИ SqlMetal.exe. Зачем вводить тут людей в заблуждение, и расказывать какие то левые примеры кодогенерации LINQ, что вот этак конструкция сгенерила этот код, а эта вот этот. Это чушь, самую основную деталь LINQ to SQL автор почему то пропустил, а это самый главный пример, который можно привести если рассматривать LINQ. Я не понимаю также, почему автор выбрал именно LINQ в этом контексте, в котором он его использовал, так как можно было взять ЛЮБУЮ конструкцию любого языка программирования, и показать как она интерпретируется/компилируется в машинный/промежуточный код. В качестве примера указываю источник - Code Generation in LINQ to SQL (http://msdn2.microsoft.com/en-us/library…). Посмотрите на нормальный пример, а не притягивание за уши к статье того, в чём автор НЕ РАЗОБРАЛСЯ но очень бы хотел воткнуть, потому что это наверное модно.
Прошу прощенья за сарказм, но, работать - разновидность жизни... А жизнь это разновидность существования. Зачем переходить к астракции без необходимости?
Я про то, что смешно как то называвать например свойства, которые тоже генерятся в методы get_ и set_. Или анонимные методы, которые в превращаются в
[CompilerGenerated]
Метод {}
Вобщем считаю это чушью, потому что компиляция С#, VB.NET генерит IL код (ниразу не слышал, чтобы кто то называл это процессом кодогенерации). При компиляции C++, C, геренирует asm код с последующей компиляцией...
Честно говоря не согласен с LINQ и кодогенерацией... Linq - это расширение языка, которое компилируется в IL код. Если же про LINQ говорить как о кодогенерации, то тогда давайте возьмём все оставшиеся N конструкций языка C#...
1) Нормальной поддержки Юникод (В некоторых местах приходится пользоваться explorerом)
2) Выполнение правой и левой панели в разных потоках.
javascript:function SpeedUp(func,speed){var raw=document.getElementById("typetext");if(raw==null){window.setTimeout(SpeedUp,100,func,speed);return;}var result=raw.innerHTML.replace(/
Мне просто не приятно как разработчику читать такие статьи, когда говориться не зная про что. Чтобы вы не приняли мои слова за пустоту, постараюсь вам объяснить. Я разработчик ПО для ОПСОСов. Одной из моих задач является создание сценариев поведения при звонках, это обработка биллинга, разрешение абоненту звонить/получать и отправлять другие виды траффика. Все сценарии выглядят однотипно, в виде блоков. Блоки это обращение к разным системам за информацией. То есть легче написать приложение, куда выносишь эти блоки граффически, делаешь между ними связи и вперёд, генеришь нужный код, потом его компилишь.
А теперь вернёмся к этой статье.
Кодогенерация по большому счёту создание кода, который схож между собой, но, например, последовательность его разная, или разные стуктуры данных (например код для каждой таблицы в базе данных со своими полями). Вот для этого используется кодогенерация, чтобы не писать почти одно и тоже тысячу раз, а позволить это делать программе.
Автор же в этой статье пытается всунуть Дизайн паттерны, которые имею совсем другой смысл, и не связаны с кодогенерацией. Дизайн паттерны указывают на стиль написания вашего кода, но они никогда не заменяют кодогенерацию или как то связаны с ней, наоборот, в кодогенерации сгенерированный код может быть по какому-то из шаблонов, но рассматривать все стили программирования чтобы объяснить кодогенерацию это бред.
Кто хочет разобраться побольше с Дизайн паттернами советую посмотреть на Spring.NET(http://www.springframework.net).
Возвращаясь к статье, хочу сказать, нет, она в приципе не плохая, ну конечно неполно написано, но в целом нормально, но она не по адресу.
А теперь этапы компиляции:
1) Разбиение на токены
2) Проверка синтаксиса и семантики
3) Кодогенерация (например на asm)
4) Компиляция
И это только с моим скудным познанием компиляторов, который я ещё помню с университета, когда приходилось их писать. Уверен профессионалы укажут больше стадий. Но кодогенерация, как раз является частью процесса компиляции. И тут уже не поспоришь. НО если рассмативать компиляцию в общем виде, как перевод из одного в другой, то да можно так сказать, как написано в английском варианте. Но пожалуйста, голову то используйте, перед тем как давать ссылки на статьи. Их надо ПРАВИЛЬНО читать. Удачи.
http://ru.wikipedia.org/wiki/%D0%9A%D0%B…
[CompilerGenerated]
Метод {}
Вобщем считаю это чушью, потому что компиляция С#, VB.NET генерит IL код (ниразу не слышал, чтобы кто то называл это процессом кодогенерации). При компиляции C++, C, геренирует asm код с последующей компиляцией...
CodeSmith (http://www.codesmithtools.com/) с кучей уже готовых шаблонов
StringTemplate.NET (http://www.stringtemplate.org/)
NVelocity (http://nvelocity.sourceforge.net/)
iCodeGenerator (http://codegenerator.sourceforge.net/)
и это не говоря уже о конкретных шаблонах, например для CodeSmith, типа:
.netTiers (http://csharp-source.net/open-source/tem…)
new {
Lenght = blablabla
}.Lenght
А авто-свойства да, не влезли =)