Здравствуйте, VladD2, Вы писали:

VD>Извини, что предложил тебе набраться знаний. Тебе, конечно же, некогда. Ведь трясти надо.
Ты в качестве аргумента кинул ссылку на сайт, предлагающий купить 640-страничную книгу на довольно широкую тему. Давай я тебе в ответ ссылку на Александреску кину, пойдешь молча читать, поблагодарив за знания, или покрутишь пальцем у виска а-ля "какое отношение это имеет к теме дискуссии"?

VD>

	Скрытый текст
	Решили как-то сравнить прапорщика с обезьяной. посадили их в две одинаковые комнаты с деревом и бананом на дереве. Обезьяна потрясла, потрясла дерево — банан не падает. видит палка в углу стоит, зацепила банан палкой, сидит и жрёт довольная. VD>Прапорщик же трясёт пальму трясёт, трясёт, трясёт. Час трясёт, два трясёт. Ему говорят: "товарищ прапорщик, ну вы вокруг посмотрите, подумайте немного.", на что тот отвечает: "Некогда думать! Трясти надо!"

VD>Иди базарь про таргетинг и прочую муру, а сам тем временем "тряси".
Нахамить оппоненту на форуме можно всегда. Только пользователей это вашей замечательной поделке не прибавит. Я же пытаюсь донести мое понимание того, что могло бы прибавить. Посмотрим, что WolfHound ответит.

Здравствуйте, Константин, Вы писали:

К>Разобраться можно даже в скомпилированном коде. Вопрос в целосообразности тратить на это время.

А тебя не смутили три комента // HACK..., поиск ключевого слова через header.Contains(" static ") и приседания с "prevNamespace" и пространствами имен?

К>Ставлю breakpoint в этом вот макросе и нажимаю "Build project" — breakpoint сработает?

Да, если перед этим зайдешь в свойства проекта в котором он используется и установишь в свойствах проекта, на закладке "Build", значение "Run debugger" в true. А можно, просто, в нужном месте макроса вызвать assert2(false) и запустить компиляцию. Вылетит диалог ассерат, по нажатие Retry запустится отладчик...

Здравствуйте, hi_octane, Вы писали:

_>Да ну нафиг. Runtime вообще появляются на свет только из-за отсутствия compile-time решений. Спроси у C++ников, они вон буст придумали, лишь бы в рантайм не ходить . И что там было насчёт применимости T4 для задач генерации кода? Ну чего-же проще-то? Взять поля, в одном методе сложить, в другом достать. Опять T4 оказался плохо применим? Я так и думал А уж задачи изменения кода, под конкретную ситуацию, я вообще не касаюсь. Посмотрим на Roslyn, может хоть там что-то приличное появится.

Кстати, в Нитре мы используем макросы сериализации с поддержкой безболезненной миграции на новые версии типов. В наших задачах важна скорость работы, так что решение на рефлексии неприемлемы.

_>...но и сорцы на C#, прямо в своих проектах. И там, в этих сорцах C#, работает отладчик, автокомплит, подсветка.

Комплит не работает. Подсветка стандартная, студийная. Отладчик работает.

Переведем Немерл на Нитру, заработает все и в высоком качестве.

Здравствуйте, Константин, Вы писали:

К>Я этого не делаю: всегда можно что-то придумать (например generics, reflection, functional programming, на худой конец T4) и написать этот кусок только один раз.

Да чтобы яму выкопать, всегда можно взять лопату. Еще можно найти 100500 отмазок, чтобы не брать эксковатор. Типа на нем учиться работать надо. Не все фирмы примут эксковатор. Все привыкли к лопате.

Когда имеющиеся решения решают проблему с нужным качеством, то нужды обращаться к макросам, конечно же, нет. Вот только почему-то в нашем коде макросов целая уйма. Все они нужны. Без них работа была бы неподъемной для маленького коллектива.

Т4 убога, но действительно, может заменить макры когда нужно только сгенерировать код по модели. Проблема только в том, что модель трудно читать, трудно описывать, и трудно поддерживать в консистентном состоянии.

Но зачастую, ДСЛ-и и модели нужно использовать из кода на языке общего назначения. И тут у подхода с Т4 все становится еще хуже. Он не может изменить синтаксис шарпа или хотя бы его реинтерпретировать. Хорошо если удалось заложить модель в атрибуты, или вынести в отдельный фал. Если не удалось, то ришение выйдет кривыми.

Встроить код внутрь шарповских методов с помощью Т4 нельзя. Значит склеивание дсл-ей и автоматизация внутри методов для нас закрыта.

С отдельным файлом тоже оргромная проблема. Его ведь нужно отпарить и стипизировать (извлечь из него информацию, семантику). И тут Т4 нам ничего не предлагает.

Немерл же предлагает отличное решение как для генерации классов и их членов, так и для склеивания ДСЛ-ей внтури тел методов. С его помощью можно интегрировать ДСЛ-и прямо в код. Причем интегрировать "глубоко" (осуществлять проверки ошибок как в самом ДСЛ-е так и в его сопряжении с основным кодом, делать подсветку, отладку и т.п.).

К>>>Имел в виду reflection не на каком-то их этапов сборки, а в runtime.
_>>Runtime вообще появляются на свет только из-за отсутствия compile-time решений.
К>Только в очень узкой области так.

Широта облести определяется только твоей фантазией и опытом. Если у тебя с ними все впорядке, то ты почти все сможешь сделать в компайлтайме. Даже саму рефлексию времени выполнения.

К>Куча задач вообще лучше подходит для интерпретируемых языков, в которых вообще нет компилятора, а только парсер и рантайм.

Таких языков почти нет. Большинство современных языков компилируются в байткод. Разве что жабаскрипт на страничке. Да и у них есть куча недостатков от низкой производительности, до плохой багозащищенносоти.

К>Причём C# со своими анонимными типами и dynamics заимствует некоторые вещи оттуда, и вовсе не из-за отсутствия compile-time решений.

Анонимные типы тут вообще не причем. А динамики — это именно что костыль затыкающий отстутсвие компайлтайм-решений. И, кстати, аналог динамика в Немерле сделан на основе макроса (пример использования). Его сделал один из не пользователей немерла и предложил в стандартную библиотеку. Так что нам не пришлось много лет ждать выхода новой версии языка с поддержкой динамиков или этот самого лэйта, пользуясь до этого времени рефлексией (порождающую жуткий код).

Это ли не демонстрация силы макросов?

Ну, и не надо забывать, что именно из-за макросов Немерл в разы удобнее и элегантнее Шарпа. Даже средства имеющие аналоги в Шарпе в Немерле реализованы куда более удобно и мощно. Даже примитивные if и foreach в разы мощнее шарповских аналогов. И если тебе все же что-то нехватает, ты можешь не ждать от моря погоды, а сесть и сделать нужную фичу самому.

Здравствуйте, Константин, Вы писали:

_>>foreach{} else{} — давай, придумывай
К>Вот готовый http://www-jo.se/f.pfleger/.net-for-else но мне никогда не было нужно такого.

Ага. И получите и распишитесь тормоза от лямбд и убогий синтаксис. И все это на ровном месте.

_>>Я тоже настоящий сварщик Но выбирая compile-time или runtime в C++ нужно иметь очень веские основания чтобы выбрать второе.
К>В С++ конечно, но в C# уже не так однозначно, т.к. runtime намного более годный.

Годный. Но кода на нем получается много и код оплучается медленным. Довольно жалко выбирать компилируемый язык и получать на нем решения медленнее и опаснее чем на интерпретируемом.

К>>>Нормально применим, я использовал, когда было нужно.
_>>Нормально применим только в одном случае — когда у тебя есть готовый источник на базе которого ты будешь генерировать код, и нет никакой необходимости трогать уже сущетсвующий код. Кому-то этого хватает, но с такими ограничениями заявлять что "Для генерации кода есть T4", слишком смело ИМХО.
К>Во-первых очень надуманное ограничение.

Ограничения — это загонять себя в рамки Т4. Кстати, не надо еще забывать, что в нем хорош генерируются только иерархии вроде классов и методов, а вот герерация сложного кода внутри методов с помощью его шаблонизатора делается крайне коряво. Фактически работа скатывается к написанию текстовых строк. О какой-то там гигиене и говорить не рпиходится.

К>Если очень нужно, вполне можно использовать например CodeDOM.

Попробуй, потом расскажешь. Я как раз в 2005-ом с этого начал. Был такое проект R#. В нем я начал делать более качественную версию КодДома. Было даже сделал, но когда я увидел Немерл, то мне стало жаль бездарно потраченное время, так как мой проект ему в подметки не годился.

Вместо код-дома можно взять АПИ студии. Но у него море косяков и работате оно только в студии, так что во время компиляции код не по генерируешь. А это значит, что в репозиторие будут храниться и все генерируемые файлы, а править все придется только из студии.

Костыль на костыле, короче.

Так что будете вы ждать от моря погоды в виде Рослина, молясь, при этом, о том, чтобы в Рослине оставили лазейку для внедрения в процесс компиляции. А когда дождетесь, то поймете, что работа с кодом там сложна и неудобна, а без расширения синтаксиса многие решения остаются все равно недоступными.

К>Но нужно бывает редко, потому что рефлексия + функциональщина; я например могу по пальцам одной руки пересчитать написанные за карьеру T4 templates, а reflection постоянно использую для разного.

Ты с какими-то совсем не критичными к производительности задачами работаешь. Может тебе просто на скрипты перейти? Надежность, ведь, у решений на рефлексии еще хуже чем у скриптовых.

К>При том, что продукт это не только исходный код который компилируется, это ещё и поддержка, и обучение пользователей, и сообщество.

Ну, начались песни о старом. А зачем ты тогда Шарп то используешь? Писал бы на С, раз главное это обучение пользователей, а время на написание кода у тебя не уходит.

К>Кстати про сообщество: на SO два вопроса с тегом nemerle. Для сравнения, там 500 вопросов с тегом clojure, 4000 вопросов с тегом scala, и 140’000 вопросов с тегом C#. Даже безотносительно вопроса «почему так мало», это говорит о том, что если у меня возникнут по нему вопросы, в мире найдутся очень немного людей, способных мне помочь.

Это потому что вопросы по немрерле в гуловской коные идут и здесь. В прочем, пользуйся кложуром, раз для тебе важнее не язык и его удобство, а количество вопросов на СтекОверфлоу.

Нормальным людям важно, чтобы на их вопросы были ответы. С этим у Немерла не хуже чем у любого другого языка.

Здравствуйте, bazis1, Вы писали:

B>Да-да-да, когда аргументы кончаются, мы переходим на личности и начинаем додумывать за собеседника. Интересно, почему все мелочные неудачники так похожи?

Какие аргументы могут быть против ничем не подкрепленного трепа? Ты сначала потрудись обосновать свои утверждения, а потом про аргументы рассуждай.

Вот тебе аргумент которого ты заслуживаешь:

Мартышка к старости слаба глазами стала;
А у людей она слыхала,
Что это зло еще не так большой руки:
Лишь стоит завести Очки.
Очков с полдюжины себе она достала;
Вертит Очками так и сяк:
То к темю их прижмет, то их на хвост нанижет,
То их понюхает, то их полижет;
Очки не действуют никак.
"Тьфу пропасть! — говорит она, — и тот дурак,
Кто слушает людских всех врак:
Всё про Очки лишь мне налгали;
А проку на-волос нет в них".
Мартышка тут с досады и с печали
О камень так хватила их,
Что только брызги засверкали.

___

К несчастью, то ж бывает у людей:
Как ни полезна вещь, — цены не зная ей,
Невежда про нее свой толк все к худу клонит;
А ежели невежда познатней,
Так он ее еще и гонит.

VD>>Трепачь, короче.
B>Слушай, я человеку выше вполне конкретно ответил. Если у тебя баттхерт от того, что фигню, на которую ты потратил кучу времени, почти никто всерьез не воспринимает, то это твои личные проблемы и к обсуждаемой теме они отношения не имеют.

У тебя на любой ответ 100500 отбехов. Все как одни не состоятельны и проистекают из того, что ты обсуждаешь то в ничего не понимаешь.

Здравствуйте, hi_octane, Вы писали:

_>Да это пример был. Представь программирование на C# без foreach. Вот это ощущение что ты регулярно пишешь ненужные но обязательные из-за убогости языка куски кода у тебя будет каждый раз когда ты будешь садиться за C# после Nemerle. В C# нет foreach {} else {}, нет foreach(index, element), и т.д. и т.п. — отстутвие каждой такой фича по отдельности вроде как не смертельно. Но когда их нет всех вместе, а особенно нет возможности объявить свою, нужную один раз, но здесь и сейчас, получаешь незабываемое ощущение что убогость языка тебе программировать реально мешает

Я это называю — "ломка". После того как возвращаешься с Немерла на Шарп в первый раз наступает ужасное ощущение связанности рук. Не хватает того, сего, пятого десятого. Ты выкручиваешься подручными средствами, но в какой-то момент говоришь себе — "Стоп! Хватит! Ради чего я над собой издеваюсь?". И только по переходив туда, сюда начинаешь свыкаться с неизбежностью отсутствия выразительных возможностей.

Это передать нельзя. Это можно только почувствовать. А чтобы это прочувствовать нужно как следует освоить Немерл, а не использовать его как шарп с выводом типов.

Здравствуйте, VladD2, Вы писали:

I>>Создание лямбды и её вызов ничтожны по сравнению с асинхронной операцией. Более того — ничтожны даже сравнивая со временем переключения контекста.

VD>Во-первых, это это не так. Блокировки разные бывают. Например, spinlock-и.

Это ничего не меняет, поскольку проблема в самом ожидании. Спинлок только в идеальном случае вернет управление сразу, без ожидания.

VD>Во-вторых, бямбда то создается в коде который полезную работу осуществляет, так что тормозится именно она. Тут еще умник предлагает через рефлексию автоматизацией заниматься. Вас послушать и компилируемый язык превратится в тормоз почище интерпретируемого.

Если такие издержки критичны, то однозначно стратегия синхронизации выбрана принципиально неверно.

VD>В-третьих, выделение памяти влияет на все приложение, так как дает нагрузку на ЖЦ.

Ничтожная нагрузка. Замерить такие издержки на лямбды можно только в синхронном коде каких нибудь числодробилок.
Если приложение из за лишней лябмды начинает осязаемо подтормаживать, то с вероятностью примерно 99% в ём уже серьезные проблемы с памятью, например фрагментация адресного пространства.

Здравствуйте, VladD2, Вы писали:

К>>В С++ конечно, но в C# уже не так однозначно, т.к. runtime намного более годный.
VD>Годный. Но кода на нем получается много и код оплучается медленным.
Не умеешь значит.

К>>Если очень нужно, вполне можно использовать например CodeDOM.
VD>Попробуй, потом расскажешь.
Пробовал, прекрасно работал.
Например когда-то (в эпоху C# 4.0 + Async CTP) запилил на нём генератор task-based асинхронных WCF клиентов (щас в коробке со студией), и task-based асинхронных реализаций сервера (по-моему до сих пор нет в коробке), на входе — CodeDOM с WCF интерфейсами.

К>>Но нужно бывает редко, потому что рефлексия + функциональщина; я например могу по пальцам одной руки пересчитать написанные за карьеру T4 templates, а reflection постоянно использую для разного.
VD>Ты с какими-то совсем не критичными к производительности задачами работаешь.
Точно не умеешь.
Рефлексия нужна один раз за запуск приложения, построить из type information и закешировать какие-нить функторы.
Если нужна производительность, подойдёт например Expression.Compile, получившийся IL код не будет отличаться по производительности от скомпилированного компилятором.

VD>Надежность, ведь, у решений на рефлексии еще хуже чем у скриптовых.
Если входные параметры не проверять, то надёжности не будет и у скомпилированного кода.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Немного offtopic: а какие у Nemerle основные принципы дизайна? Какова основная идея? Чем руководствуются создатели при принятии тех или иных решений?

Мое впечатление и ИМХО. Никакой идеологии и общего видения у Немерле нет. Когда читал доки, создалось впечатление, что язык весьма неконсистентен (говорю только про первую версию). Что-то дернуто оттуда, что-то отсюда.
Хуже того, у языка нет киллер-фичи. Просто фичи есть, а киллер-фич — нет. Макросы — это хорошо, но лично мне за много лет программирования что-то подобное требовалось считанные разы (да, компиляторы я не пишу). Опять же, сложилось впечатление, что в основном макросы нужны для трансформации самого языка. Но кому нужен язык-конструктор? Ну может кому-то и нужен, но это явно маргинальное направление. Типа как дали человеку кусок глины — лепи чего хочешь. На мой взгляд, людям в основном требуется совсем иное — продуманный язык с определенным предназначением и видимыми достоинствами (ну и проистекающими из всего этого недостатками, само собой).

Я согласен с кем-то из этого топика, что более полезным Немерле был бы в виде надмножества C#, как в начале своего развития С++ был надмножеством С. Пишешь на чистом C#, а когда надо — применяешь пару убойных штук, которые "не для масс" (те же макросы). Это было бы очень круто и многим энтузиастам бы понравилось. Правда, C# тоже развивается и остается все меньше места для этих всех надмножеств, скоро словосочетание "надмножество С#" будет вызывать такой же глупый смех, как сейчас "надмножество С++" (это же полный п).

В общем, сейчас мы имеем чисто маргинальный язык, который может служить разве что площадкой для экспериментов. И, судя по настрою авторов, эта ситуация не изменится.

Здравствуйте, AlexRK, Вы писали:

ARK>Я согласен с кем-то из этого топика, что более полезным Немерле был бы в виде надмножества C#, как в начале своего развития С++ был надмножеством С. Пишешь на чистом C#, а когда надо — применяешь пару убойных штук, которые "не для масс" (те же макросы). Это было бы очень круто и многим энтузиастам бы понравилось. Правда, C# тоже развивается и остается все меньше места для этих всех надмножеств, скоро словосочетание "надмножество С#" будет вызывать такой же глупый смех, как сейчас "надмножество С++" (это же полный п).
Это возможно сейчас.
Компилятор Nemerle умеет компилировать C# . ( Не все фишки и есть некоторые нюансы )
И тут можно использовать макросы Nemerle, на сегодня только макроатрибуты т.к. они не меняют синтаксис.

Например берем Memoize:

class A
{
  [Nemerle.Memoize] 
  public static int F(int a, int b) { return a+b; }
}

Здравствуйте, _NN_, Вы писали:

_NN>Это возможно сейчас.

Боюсь, это "возможно" весьма условно. Это как студент написал программу и типа все у него готово. Правда, чуть-чуть в одном месте не доделано, в другом странная ошибка вылетает, тут вот пока не оптимизировано, а здесь рыбу заворачивали.

"Возможно" — это вот здесь: http://www.postsharp.net/
Вот там все возможно. А у Немерле невозможно.

Когда будет стабильный компилятор, нормальный сайт, установка одним кликом и полноценное использование внутри студии, подробная документация, какое-никакое сообщество и ответы на StackOverflow — вот тогда это можно назвать "возможно".

_NN>Компилятор Nemerle умеет компилировать C# . ( Не все фишки и есть некоторые нюансы )

Так вот надо бы сделать все фишки и устранить все нюансы, а не рассказывать басни про Нью-Васюки.

_NN>И тут можно использовать макросы Nemerle, на сегодня только макроатрибуты т.к. они не меняют синтаксис.

Это неплохо, но, ИМХО, даже до t4 не дотягивает.

Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, AlexRK, Вы писали:

ARK>>Я согласен с кем-то из этого топика, что более полезным Немерле был бы в виде надмножества C#, как в начале своего развития С++ был надмножеством С. Пишешь на чистом C#, а когда надо — применяешь пару убойных штук, которые "не для масс" (те же макросы). Это было бы очень круто и многим энтузиастам бы понравилось. Правда, C# тоже развивается и остается все меньше места для этих всех надмножеств, скоро словосочетание "надмножество С#" будет вызывать такой же глупый смех, как сейчас "надмножество С++" (это же полный п).
_NN>Это возможно сейчас.
_NN>Компилятор Nemerle умеет компилировать C# . ( Не все фишки и есть некоторые нюансы )
_NN>И тут можно использовать макросы Nemerle, на сегодня только макроатрибуты т.к. они не меняют синтаксис.

_NN>Например берем Memoize:
_NN>

_NN>class A
_NN>{
_NN>  [Nemerle.Memoize] 
_NN>  public static int F(int a, int b) { return a+b; }
_NN>}
_NN>

1. Как добавить интервал обновления кеша ?
2. Как добавить правило обновления кеша ?
3. Как из другого кода вызвать очищение кеша ?

Пока хватит.

Здравствуйте, BoobenCom, Вы писали:

BC>1. Как добавить интервал обновления кеша ?
BC>2. Как добавить правило обновления кеша ?
BC>3. Как из другого кода вызвать очищение кеша ?
BC>Пока хватит.
Никак. Данный макрос это не умеет.
Но ты можешь написать свой. И делать все, что тебе надо. И ровно, так как тебе надо в данном конкретном проекте.

Здравствуйте, WolfHound, Вы писали:

К>>Во-вторых, в тех случаях когда мне нужно генерировать C# код на этапе компиляции, в коробке со студией есть для этого T4 text templates.
WH>Было: http://rsdn.ru/forum/dotnet/4159707.1

Автор: Sinix
Дата: 16.02.11

WH>Стало: http://rsdn.ru/forum/dotnet/4187035.1

Автор: hardcase
Дата: 09.03.11

Было: читаемый код визитора, в котором всё предельно понятно
Стало: макрокод из которого не очевиден, собтвенно, сам визитор.

Неочевидная проблема — как теперь проводить код-ревью ? Предполагается, что любой ревьюер способен выполнить в уме макрокод и так же в уме просматривать ?

Правильное решение в обоих случаях — конечный результат угадывается предельно просто, даже человеку со стороны, даже если он еле еле знаком с конкретным ЯП.

Здравствуйте, Ikemefula, Вы писали:

I>Это ничего не меняет, поскольку проблема в самом ожидании. Спинлок только в идеальном случае вернет управление сразу, без ожидания.
Если ты часто отвисаешь на локах, то ты очень плохо спроектировал приложение.

I>Если приложение из за лишней лябмды начинает осязаемо подтормаживать, то с вероятностью примерно 99% в ём уже серьезные проблемы с памятью, например фрагментация адресного пространства.
Для того чтобы фрагментировать память лямбдами нужно очень сильно постараться.

Здравствуйте, bazis1, Вы писали:

B>Ты в качестве аргумента кинул ссылку на сайт, предлагающий купить 640-страничную книгу на довольно широкую тему.

Скажу по секрету, что наш мир не столь справедлив и, если тебе жаль денег автору, то его книгу можно найти и нелегально в формате ПДФ.

B>Давай я тебе в ответ ссылку на Александреску кину, пойдешь молча читать, поблагодарив за знания, или покрутишь пальцем у виска а-ля "какое отношение это имеет к теме дискуссии"?

Я его книгу читал. Это была одна из книг подтолкнувшая меня на путь полноценного метапрограммирования.

B>Нахамить оппоненту на форуме можно всегда. Только пользователей это вашей замечательной поделке не прибавит. Я же пытаюсь донести мое понимание того, что могло бы прибавить. Посмотрим, что WolfHound ответит.

Я не вижу оппонента. Я вижу человека, своим поведением, смахивающего на мартышку из басни. Не в силах понять ты ищешь фатальные недостатки в том что не понимаешь и тех кто занимается непонятными тебе вещами.

Здравствуйте, WolfHound, Вы писали:

I>>Это ничего не меняет, поскольку проблема в самом ожидании. Спинлок только в идеальном случае вернет управление сразу, без ожидания.
WH>Если ты часто отвисаешь на локах, то ты очень плохо спроектировал приложение.

Интересный способ ведения беседы — перефразировать часть скипнутого текста. Цитирую себя:"Если такие издержки критичны, то однозначно стратегия синхронизации выбрана принципиально неверно."

I>>Если приложение из за лишней лябмды начинает осязаемо подтормаживать, то с вероятностью примерно 99% в ём уже серьезные проблемы с памятью, например фрагментация адресного пространства.
WH>Для того чтобы фрагментировать память лямбдами нужно очень сильно постараться.

В том то и дело, я про то и пишу.

Здравствуйте, Ikemefula, Вы писали:

I>Это ничего не меняет, поскольку проблема в самом ожидании. Спинлок только в идеальном случае вернет управление сразу, без ожидания.

Твоя компетенция поражает. Чужой блокировки может не быть при 99% попытках ее получения. Операция может быть (и обычно так оно и бывает) крохотной, например, присвоением поля или вызовом не затратной по времени функции.

VD>>Во-вторых, бямбда то создается в коде который полезную работу осуществляет, так что тормозится именно она. Тут еще умник предлагает через рефлексию автоматизацией заниматься. Вас послушать и компилируемый язык превратится в тормоз почище интерпретируемого.

I>Если такие издержки критичны, то однозначно стратегия синхронизации выбрана принципиально неверно.

Универсальные отбрехи пошли.

VD>>В-третьих, выделение памяти влияет на все приложение, так как дает нагрузку на ЖЦ.

I>Ничтожная нагрузка.

От одного случая — да. Но у вас же весь код подобными вещами утыкан. В итоге и получаются неповоротливые, монструозные приложения, полные глюков и дедлоков. Причем поделать с ними ничего нельзя, так как тормоза и глюки планомерно размазаны по написанному в рукопашную коду, и устранение одного случая особой рояли не играет.

I>Если приложение из за лишней лябмды начинает осязаемо подтормаживать, то с вероятностью примерно 99% в ём уже серьезные проблемы с памятью, например фрагментация адресного пространства.

Я уже приводил пример из реального проекта — ReSharper. В нем были вынуждены специально проходиться по коду и преобразовывать линк-код в императивный, так как профайлер показал, что лямбды привели к тормозам.

Здравствуйте, Константин, Вы писали:

К>>>Если очень нужно, вполне можно использовать например CodeDOM.
VD>>Попробуй, потом расскажешь.
К>Пробовал, прекрасно работал.

Уровень твоей не компетенции зашкаливает. И ты еще спорить лезешь?