Столкнулся я с вашим шарпом...

<petrosyan-mode>

if (WIN_VERSION < XYZ) BSOD();

А чем не катит просто

if ( NEW_COOL_FEATURE ) 
{
  <new code here>
}
else
{
   <old working code here> 
}

?

Там централизовано прописывается в зависимостях одна из 100500 версий фреймворка. А в каждой версии - стабильный набор NEW_COOL_FEATUREов.

Dependency Injection, Inversion of Control

Это работает на этапе выполнения.

это там есть. но определения можно дать через параметры компилятора.

больше, больше баззвордов!

на шарпе сразу неработающий код пишут... а что-то кастрированое типа

#if DEBUG
   <debug code here>
#endif

баззворд - это тоже баззворд, но мои хоть проблему ТСа решают.

как?

Позволяют иметь несколько реализаций паралелльно, не засирая код препроцессорными директивами.

</petrosyan-mode>

Каких, которые в рантайме цепляются?

В рантайме, да. Препроцессорными директивами, можно управлять тем, какие реализации будут зарегистрированы в application root приложения.

не засирая код препроцессорными директивами.
Препроцессорными директивами [...] какие реализации будут зарегистрированы

Эка тебе солнцем напекло...

Эпичненько... mono перенёс тему о mono...

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

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

Я не совсем понял, о чём ты, ну да ладно... Вопрос был именно про директивы, чтобы с помощью них включить новую фичу.

Паттерн стратегия

нет глобальных макросов

ибо нефиг.

Это работает на этапе выполнения.

Ответ не верный. Это работает на этапе JIT компиляции. (Хотя по идее компилятор еще при компиляции с CIL может все лишнее вырезать, может уже и тогда сразу вырежет все).

Удаляешь старый не нужный код и оставляешь только новый. Зачем разводить бардак в исходниках?

не с нашим, а с вашим.

#if NEW_COOL_FEATURE
   <new code here>
#else
   <old working code here>
#endif

git branch new_cool_feature

А чем не катит просто

old working code
working

к тому же возможна ситуация, когда new code не скомпилется ( ты это не описал)
//А вообще, макросы это не красиво.

Тред ушел в совершенно левые дебри. Задача топикстартера должна решаться при помощи средств типа частичных методов (partial method) или аттрибута Conditional

http://msdn.microsoft.com/ru-ru/library/4xssyw96(v=vs.90).aspx

разъясни плз, чем для шарпа это будет отличаться? По идее, если мы просто напишем if(x), где x - константа, компилятор выбросит ненужный кусок сразу же, не? До рантайма не дойдет, просадки в перфомансе не будет. Вместо этого предлагается делать именованный блок и навешивать на него адовую аннотацию - куча синтаксического мусора.

Почитайте Framework Design Guidelines - http://www.amazon.com/Framework-Design-Guidelines-Conventions-Libraries/dp/03...

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

Ответ не верный. Это работает на этапе JIT компиляции.

JIT компиляция работает во время выполнения => ответ верный.

JIT компиляция работает во время выполнения => ответ верный.

Только не в случае C# (да и любого другого .NET языка). JIT компиляция работает один раз, при первом запуске бинарника. Потом - скомпилированное кладется куда-то в assembly cache, и дергается напрямую оттуда, в уже собранном виде. Так что накладные расходы - почти нулевые. Ну и опять-же, скорее всего еще компилятор C# еще на этапе компиляции исходников, задолго до JIT, вырежет мертвые ветки кода. Всякие Скотты Майерсы и прочие давно даже для C/C++ советуют использовать if вместо #ifdef, т.к. с ним проблем меньше. Единственное удобство в #ifdef в случае C/C++ - это то, что можно макросы через -D в командной строке задать.

Как народ обычно добавляет фичи без макросов?

«Народ» обычно за макросы устраивает показательную порку, поскольку считается (и небезосновательно), что макросы вредят читабельности и сопровождаемости кода.

Это фича!

Ну и опять-же, скорее всего еще компилятор C# еще на этапе компиляции исходников, задолго до JIT, вырежет мертвые ветки кода.

Я не понял. То есть если я напишу

if (0) {
   no_such_type x;
   undefined_function(x);
}

То это скомпилируется?

Всякие Скотты Майерсы и прочие давно даже для C/C++ советуют использовать if вместо #ifdef, т.к. с ним проблем меньше. Единственное удобство в #ifdef в случае C/C++ - это то, что можно макросы через -D в командной строке задать.

На C++

$ g++ test.cpp
test.cpp: In function ‘int main()’:
test.cpp:4:8: error: ‘no_such_type’ was not declared in this scope
test.cpp:4:21: error: expected ‘;’ before ‘x’
test.cpp:5:27: error: ‘x’ was not declared in this scope
test.cpp:5:28: error: ‘undefined_function’ was not declared in this scope

Т.е. в C я бы написал:

А кто мешает на код шарпа предварительно cpp натравить? А ещё лучше, сразу m4.

Или на шарпе сразу работающий код пишут?

Ага. Сразу неработающий.

Единственное удобство в #ifdef в случае C/C++ - это то, что можно макросы через -D в командной строке задать.

В случае макросов препроцессор вырежет весь ненужный код до компиляции, удаче тебе ядро компилять (500 МB исходников) c твоими if (0) без макросов - компилятор каждый раз будет проверять корректность всего кода.

В случае макросов препроцессор вырежет весь ненужный код до компиляции, удаче тебе ядро компилять (500 МB исходников) c твоими if (0) без макросов - компилятор каждый раз будет проверять корректность всего кода.

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

(Не надо думать, что я сторонник C#, - убогий язык. Но глупо отрицать очевидные факты, даже не смотря на нелюбовь к языку)

Я не понял. То есть если я напишу

if (0) { no_such_type x; undefined_function(x); }

То это скомпилируется?

Конечно нет, и это правильно.

Именно. Все правильно.

Про make-файлы я из без дебилов знаю. А ты попробуй без макросов кроссплатформенные независимые от типов двусвязные списки, фифо, рабочие череди сделать на С.

Только не в случае C# (да и любого другого .NET языка). JIT компиляция работает один раз, при первом запуске бинарника.

Не может быть. Так ничего не наоптимизируешь, без PGO. Там кажется есть AOT компилятор, но это точно не дефолт.

Такое конает с нативным кодом, тем более там не тащат с собой компилирующий рантайм. Но при такой тупой компиляции управляемый код тормозил бы еще адовее. А так его спасает PGO, потому пол-кода, фреймворков и библиотек попросту выкашиваются из нативного образа

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

На самом деле легко, т.к. в C есть волшебный тип void* :) только вручную приводить типы прийдется каждый раз. Но вообще да, для именно C макросы порой бывают незаменимы, к счастью область применения C ограничена в основном ядром и эмбедщиной.

Не может быть. Так ничего не наоптимизируешь, без PGO. Там кажется есть AOT компилятор, но это точно не дефолт.

Возможно мы «оба правы». Просто по результатам выполнения программы и всех рантайм профайлингов, получается некий бинарь, рано или поздно. Оно и кешируется, что-бы в следующий раз не начинать с чистого листа. Но в какой-то форме оно точно кешируется, если верить учебникам по C#/.NET.

Не может быть.

Именно так все в .net и есть.

Но при такой тупой компиляции управляемый код тормозил бы еще адовее.

Ну не тормозит :)

Было бы ссылочку еще хорошо сюда

Ты ламер?

RTFM про ngen, lmd!

Это же отдельная утилита. Ее существование никто и не отрицает. Но по дефолту все приложение собирать в натив в .NET вроде не делают

CIL код компилируется при первой необходимости, потом нативный код кешируется, но никогда не перекомпилуется в рантайме. Хотя Рихтер пишет, что гипотетически CLR этому можно научить и может быть когда-нибудь научат.

А если всего лишь парочка прогонов, о не интерпретируется?