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


L>Смотри выделенное.
Неужели не встречал ситуёвины, когда что-то на С, а что-то на С++? Интероп там оч. хороший, да и можно просто наследовать С-код, просто включив его в С++ проект...

L>Засим откланиваюсь.
Ну и к лучшему, в смысле всего хорошего!

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

VD>>Погугли и почитай, что за бред там пишется. Все про С++. Это локальная терминалогия отдельных идиотов. Научного понятия статического полиморфизма нет. Есть статическая типизация и разные виды полиморфизма. Но любой из них может отрабатывать в рантайме.

E>А как называется сод, вроде std::sort, который можно натравить на данные разного типа, удовлетворяющие каким-то формальным требованиям, и получить соответсвующий результат?

Параметрический полиморфизм и утиная типизация.

E> Пусть члово полиморфизм не годится. Какое таки годится?

Слово "полиморфизм" годится. Только тип используемого в шаблонах С++ полиморфизма называется "параметрическим".

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

VD>утиная типизация.

А это что обозначает?

Здравствуйте, Erop

VD>>утиная типизация.
E>А это что обозначает?
Если что-то крякает как утка — это можно зажарить, даже если это был дядя вася с манком.

Гуглить duck typing.

Если тупо на пальцах и неправда — то это динамическое приведение типов по совпадению имён/сигнатур членов класса.

Как-то так:

class HunterVasya
{
  void Cryack()
  {
    // ...
  }
  ...
}

class Duck
{
  void Cryack()
  {
    // ...
  }
  ...
}
...
void Main()
{
  HunterVasya vasya = new HunterVasya();

  Duck duck = (Duck)vasya; // The magic lives here.

  duck.Cryack();
}

Здравствуйте, Erop, Вы писали:
VD>>утиная типизация.

E>А это что обозначает?
http://rsdn.ru/Forum/Message.aspx?mid=3165397&only=1

Автор: Воронков Василий
Дата: 06.11.08

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

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

V>В общем ладно, может тут и моя вина, что не описал контекст, поэтому не понимаю твоего сопротивления очевидным, на мой взгляд, вещам.
А ты читал, что пишут другие люди про очевидные "на твой взгляд" вещи?


V>В общем, сервер конференций, видео, VoIP и вся лабуда типа шаринга приложений и прочие примочки. Основная реалтаймовая и одновременно нагрузочная вещь — это именно VoIP, остальное реалтаймом можно назвать лишь условно. Что есть VoIP: это 50 пакетов в секунду на абонента в одну только сторону, т.е. итого 100 пакетов на абонента. Железка должна держать их несколько сотен, желательно под тысячу. В общем, у меня такой сценарий, что я даже не могу позволить себе такую мелочь, как лишнее копирование данных и тем паче ни о каких 100тыс выделений буферов в секунду не может быть и речи.
Поэтому для этих целей ведущие собаководы выделяют все нужные буфера заранее.

V>Оно не возвращает, оно читает из сокета в наш предвыделенный буфер. После прочтения возвращает кол-во прочитанных байт. В пакете заголовок и собственно сами данные с неким смещением (зависит от заголовка). Данные обрабатываются прямо из этого буфера по указанной выше причине.
Поэтому в таких случаях ведущие собаководы применяют либо ансейф, либо трюк с джитом типа вот так:

for(var i =0; i<buffer.Length; i++)
{
    if (i==iactualLength) // выходим из цикла
      break;
  PerformTerribleCalculationAgainst(buffer[i]);//здесь устранены проверки на выход за пределы buffer
}

V>Обычная там фильтрация, ФНЧ/ФВЧ, алгоритм рекурсивного фильтра примитивен — это просто вычисление многочленов z1*a1+z2*a2+z3*a3+..., zi — элементы последовательности, ai — константы. Думаешь, я тебе вру о том, что затраты на доступ к массиву сопоставимы с полезными вычислениями?
Думаю, ты просто не вполне корректно готовишь собаку.

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

S>Поэтому в таких случаях ведущие собаководы применяют либо ансейф, либо трюк с джитом типа вот так:
S>

S>for(var i =0; i<buffer.Length; i++)
S>{
S>    if (i==iactualLength) // выходим из цикла
S>      break;
S>  PerformTerribleCalculationAgainst(buffer[i]);//здесь устранены проверки на выход за пределы buffer
S>}
S>

Мммм... А чем это отличается от проверки, выполняемой автоматически? Ну, за исключением того, что мы не словим потенциально IndexOutOfRangeException?

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

VD>>утиная типизация.

E>А это что обозначает?

Это означает, что типы считаются одинаковыми если они обладают одинаковым набором членов или свободных функций.

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

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

C>Мммм... А чем это отличается от проверки, выполняемой автоматически? Ну, за исключением того, что мы не словим потенциально IndexOutOfRangeException?
Тем, что она будет делаться один раз на тело цикла, а не один раз на каждое обращение к элементу массива.
Хотя да, в коротких формулах будет немногим лучше .

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

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

C>>Мммм... А чем это отличается от проверки, выполняемой автоматически? Ну, за исключением того, что мы не словим потенциально IndexOutOfRangeException?
S>Тем, что она будет делаться один раз на тело цикла, а не один раз на каждое обращение к элементу массива.
S>Хотя да, в коротких формулах будет немногим лучше .

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

Здравствуйте, samius, Вы писали:
S>Сравнил. При одном обращении к массиву на цикл код получается как минимум эквивалентным по производительности (с точностью до погрешности измерений, т.е. разница в десятую долю секунды из полутора минут прогона). Это означает, что при множественном обращении к массиву по индексу выигрыш от проверки внутри цикла наверняка будет.
Ну, можно попробовать применить что-нибудь поинтереснее — например, фильтрацию. Там вообще простор фантазии — в том смысле, что фильтрация — это свёртка подмассива с массивом. Как-то типа так:

public double[] Filter(double[] data, double[] filter)
{
  double[] target = new double[data.Length-filter.Length];
    for(int i = 0; i<target.Length; i++)
    {
      for(j=0; j<filter.Length; j++)
          target[i]+=data[i+j]*filter[j]; // количество неустраненных проверок границ в этом месте определит общий успех предприятия
    }
    return target;
}

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

V>>Я тебя уже спрашивал, почему именно С, ты так и не смог предметно объясниться.
G>Еще раз обясняю. C — потому что низкоуровневый и быстрый. Там где нужны более сложные абстракции лучше юзать более безопасные языки, чем C++.

Ты зачем с ног на голову все ставишь? Язык определяет задачи, или задачи определяеют выбираемый язык — суть инструмент?

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

И что за повторяющаяся ахинея насчет "более сложных абстракций"? Речь сейчас исключительно о тех задачах, где ты предлагаешь пихать голый С.

--------
(Вариант ответа, типа "потому что есть платформы с С, но без С++" не принимаются, т.к. для таких платформ мы бы и не сравнивали).

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

V>С++ такой же низкоуровневый, быстрее в общем случае, чем С.

Насчёт быстрее в общем случае, чем Си — это вряд ли. В некоторых случаях может быть быстрее кода на Си, в этом месте как правило спешат привести хрестоматийный пример qsort vs. std::sort. Собственно, это была одной из целей Страуструпа — не сильно потерять в производительности. Но совсем этого избежать не получилось.

V>И что за повторяющаяся ахинея насчет "более сложных абстракций"?

Исключения, например, сильно мешают некоторым оптимизациям, приводят к громоздкому бинарному коду. Совсем же без исключений на C++ писать трудно, тем более что даже простой new может бросить std::bad_alloc.

Шаблоны могут привести к разбуханию и дублированию бинарного кода, что как минимум скажется на cache locality (C++FQA).

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

VD>Параметрический полиморфизм и утиная типизация.

If the range of actual types that can be used is finite and the combinations must be specified individually prior to use, it is called ad-hoc polymorphism. If all code is written without mention of any specific type and thus can be used transparently with any number of new types, it is called parametric polymorphism

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

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

VE>

VE>If the range of actual types that can be used is finite and the combinations must be specified individually prior to use, it is called ad-hoc polymorphism. If all code is written without mention of any specific type and thus can be used transparently with any number of new types, it is called parametric polymorphism

VE>Если я правильно понимаю, у шаблонов полиморфизм как раз не параметрический, особенно в данном случае (различный sort для разных типов).

Как раз у шаблонов — параметрический. Специализация шаблонов — ad hoc.

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

V>>В общем ладно, может тут и моя вина, что не описал контекст, поэтому не понимаю твоего сопротивления очевидным, на мой взгляд, вещам.
S>А ты читал, что пишут другие люди про очевидные "на твой взгляд" вещи?

Читал много всего. Но помимо чтения, конечно же, ставили эксперименты и получали результаты.
А ты читал мои сообщения выше? Сильную разницу с советами в статье заметил? А сам-то статью внимательно читал?

S>Поэтому для этих целей ведущие собаководы выделяют все нужные буфера заранее.

Это пробегающие_мимо_высунув_язык собаководы так делают, а ведущие читают хотя бы на пару постов выше, чтобы не потерять контекст, перед тем, как делать серьёзное лицо. А то какой-то конфуз — объясняют мне то, что я сам оппоненту объяснял. Ну или надо было не на мой пост отвечать, для сохранения последовательности обсуждения.

И тут требуется уточнить — что значит "заранее"? Перед тем как пустить траффик по какому-нить из тысячи каналов? Или в процессе инициализации системы? Если первое, то так и есть, а если второе — то никак, ибо клиенты заходят по разным протоколам и в каждом протоколе свои особенности.


V>>Оно не возвращает, оно читает из сокета в наш предвыделенный буфер. После прочтения возвращает кол-во прочитанных байт. В пакете заголовок и собственно сами данные с неким смещением (зависит от заголовка). Данные обрабатываются прямо из этого буфера по указанной выше причине.
S>Поэтому в таких случаях ведущие собаководы применяют либо ансейф,

Ансейф без пиннинга никак, а насчет пиннинга отсылаю к своим сообщениям чуть выше или к статье по твоей ссылке.

S>либо трюк с джитом типа вот так:
S>

S>for(var i =0; i<buffer.Length; i++)
S>{
S>    if (i==iactualLength) // выходим из цикла
S>      break;
S>  PerformTerribleCalculationAgainst(buffer[i]);//здесь устранены проверки на выход за пределы buffer
S>}
S>

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

В любом случае, даже в случае подобных "сверхоптимизаций", заджитенный бинарный код весьма убог в тех местах, где речь идет об обращениях к массивам. И я могу себе позволить предположить почему: наверно есть какой-то "протокол" м/у джиттером и GC, чтобы GC не терял ссылочные значения, "затертые" в регистрах после всех оптимизаций. Компилированных бинарный кусок подобного С++ кода обычно раза в 2 короче. (в исходнике gthtперебор где-то так: while(array!=last) process( *array++); )

Учитывая, что голосовой буффер — это вполне счетное кол-во сэмплов (обычно 160 или 320), то неплохо на С++ на шаблонах смотрится раскрутка цикла "в плоскость".


V>>Обычная там фильтрация, ФНЧ/ФВЧ, алгоритм рекурсивного фильтра примитивен — это просто вычисление многочленов z1*a1+z2*a2+z3*a3+..., zi — элементы последовательности, ai — константы. Думаешь, я тебе вру о том, что затраты на доступ к массиву сопоставимы с полезными вычислениями?
S>Думаю, ты просто не вполне корректно готовишь собаку.

Ну думай. В общем, ввиду отсутствия предмета обсуждения позволю себе его задать: есть рекурсивные цифровые фильтры и нерекурсивные. С нерекурсивными в дотнет вообще беда из-за непосредственной реализации той приведенной мною формулы по верх массивов, и это выполняется на каждый отсчет... чтобы получить следующее фильтрованное значение, надо сделать приращение i+1 при Z, и пробежаться по окну снова, а размер окна бывает разный и почти никогда маленьким. Поэтому на практике фильтруем рекурсивными фильтрами, в которые подаются значения по 1-му, а кол-во промежуточных регистров фиксированно и зависит от порядка фильтра. В этом случае zi — переменные структуры и формула вычисляется вовсе в цикле.

------------
Чтобы далее не переливать из пустого в порожнее: на клиента идет по ClickOnce полностью safe managed код (благо там нагрузка — один канал всего). Так что была масса возможностей сравнить варианты по всему градиенту от нейтива до менейджед (сравнить аналогичную ф-сть клиента и сервера в протоколах и обработке сигнала).

Здравствуйте, vdimas, Вы писали:
V>А ты читал мои сообщения выше?
Да.
V>Сильную разницу с советами в статье заметил?
Нет.
V>А сам-то статью внимательно читал?
Да.

V>Это пробегающие_мимо_высунув_язык собаководы так делают, а ведущие читают хотя бы на пару постов выше, чтобы не потерять контекст, перед тем, как делать серьёзное лицо. А то какой-то конфуз — объясняют мне то, что я сам оппоненту объяснял. Ну или надо было не на мой пост отвечать, для сохранения последовательности обсуждения.
Оппонент не занимается проектированием VoIP сервера под дотнет. Поэтому ему статья была бы малоинтересна. Я же не из ехидства — а так, для общей полезности. Мало ли кто чего не прочитал в интернете.

V>И тут требуется уточнить — что значит "заранее"? Перед тем как пустить траффик по какому-нить из тысячи каналов? Или в процессе инициализации системы? Если первое, то так и есть, а если второе — то никак, ибо клиенты заходят по разным протоколам и в каждом протоколе свои особенности.
Ну, в статье более-менее написано что значит "заранее" в их контексте.
Перед каждым коннектом, я так понял, выделять уже поздно — потому, что нельзя пинить равномерно размазанные по памяти буфера.
С точки зрения менеджера буферов, все особенности протоколов сводятся к подходящему размеру буфера.

V>Ансейф без пиннинга никак, а насчет пиннинга отсылаю к своим сообщениям чуть выше или к статье по твоей ссылке.
Так штука в том, что сеть вообще без пиннинга никак — даже если сам его не делаешь, запись в сокет автоматически пинит буфер за тебя. Поэтому ансейфом больше/ансейфом меньше — особенной роли не играет.

V>В любом случае, даже в случае подобных "сверхоптимизаций", заджитенный бинарный код весьма убог в тех местах, где речь идет об обращениях к массивам. И я могу себе позволить предположить почему: наверно есть какой-то "протокол" м/у джиттером и GC, чтобы GC не терял ссылочные значения, "затертые" в регистрах после всех оптимизаций.
Не очень понятно, где там будет экономия — как только в цикле осталось только одно обращение к массиву, дальше начинается математика, и никаких указателей не остаётся.
Значит, джит лажает в математике, а не в указателях и GC.

V>Учитывая, что голосовой буффер — это вполне счетное кол-во сэмплов (обычно 160 или 320), то неплохо на С++ на шаблонах смотрится раскрутка цикла "в плоскость".
Ну, это верно. Шаблоны и раскрутка на С++ — это просто классика кун-фу.
Опытные падаваны делают это на шарпе вручную с ансейфом (ковыряния рефлектором в районе System.String и System.Array дают порой потрясающие впечатления).
Путь джедая — это разработка обобщенного фреймворка развертки циклов в рантайме. Путь полного джедая — это, конечно же, доработка этого обобщенного фреймворка до развёртки циклов в GPU


V>Ну думай. В общем, ввиду отсутствия предмета обсуждения позволю себе его задать: есть рекурсивные цифровые фильтры и нерекурсивные. С нерекурсивными в дотнет вообще беда из-за непосредственной реализации той приведенной мною формулы по верх массивов, и это выполняется на каждый отсчет... чтобы получить следующее фильтрованное значение, надо сделать приращение i+1 при Z, и пробежаться по окну снова, а размер окна бывает разный и почти никогда маленьким. Поэтому на практике фильтруем рекурсивными фильтрами, в которые подаются значения по 1-му, а кол-во промежуточных регистров фиксированно и зависит от порядка фильтра. В этом случае zi — переменные структуры и формула вычисляется вовсе в цикле.
Да это всё более-менее понятно. Можешь привести код такого фильтра, чтоб стало понятнее, куда оптимизировать?

V>Чтобы далее не переливать из пустого в порожнее: на клиента идет по ClickOnce полностью safe managed код (благо там нагрузка — один канал всего). Так что была масса возможностей сравнить варианты по всему градиенту от нейтива до менейджед (сравнить аналогичную ф-сть клиента и сервера в протоколах и обработке сигнала).
И как результат сравнения? Дает ли переход в ансейф прирост? Насколько переход в нейтив бъет ансейф?

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



V>>Ансейф без пиннинга никак, а насчет пиннинга отсылаю к своим сообщениям чуть выше или к статье по твоей ссылке.
S>Так штука в том, что сеть вообще без пиннинга никак — даже если сам его не делаешь, запись в сокет автоматически пинит буфер за тебя. Поэтому ансейфом больше/ансейфом меньше — особенной роли не играет.

Правильно, поэтому мы используем класс Socket только для инициализации (бо удобно очень), а потом берем хендл, и по UDP работаем не через класс сокета.


V>>В любом случае, даже в случае подобных "сверхоптимизаций", заджитенный бинарный код весьма убог в тех местах, где речь идет об обращениях к массивам. И я могу себе позволить предположить почему: наверно есть какой-то "протокол" м/у джиттером и GC, чтобы GC не терял ссылочные значения, "затертые" в регистрах после всех оптимизаций.
S>Не очень понятно, где там будет экономия — как только в цикле осталось только одно обращение к массиву, дальше начинается математика, и никаких указателей не остаётся.
S>Значит, джит лажает в математике, а не в указателях и GC.

Там какая-то возня по регистрам. Такое ощущение, в джит забили жесткие правила: такую-то адресацию делать так-то, другую так-то, и вот он вынужден жонглировать регистрами. Почему мне и показалось, что "протокол" соблюдают, дабы джит знал в каких регистрах искать ссылки.


V>>Учитывая, что голосовой буффер — это вполне счетное кол-во сэмплов (обычно 160 или 320), то неплохо на С++ на шаблонах смотрится раскрутка цикла "в плоскость".
S>Ну, это верно. Шаблоны и раскрутка на С++ — это просто классика кун-фу.
S>Опытные падаваны делают это на шарпе вручную с ансейфом (ковыряния рефлектором в районе System.String и System.Array дают порой потрясающие впечатления).

Разве не проще на С/С++?
Согласен, для первого такого случая это же так муторно: надо еще один проект создать, в нем файл export.def, завести у себя класс NativeMethods
Зато каждый следующий случай добавляется за считанные секунды без этих "звездных войн". По крайней мере отдача адекватна вложенному результату.

S>Путь джедая — это разработка обобщенного фреймворка развертки циклов в рантайме. Путь полного джедая — это, конечно же, доработка этого обобщенного фреймворка до развёртки циклов в GPU

Ха-ха по последнему.
Это должен быть путь не одинокого джедая, а как минимум серьёзного коллектива, т.к. сами оптимизации/развороты и прочее хоть и просты каждый в отдельности, но их охренительное кол-во, т.е. база знаний должна быть приличная.



S>Да это всё более-менее понятно. Можешь привести код такого фильтра, чтоб стало понятнее, куда оптимизировать?

нерекурсивный примерно такой (без оптимизаций):

// смещаем окно вдоль последовательности
// развернутый вариант
for(int i=0; i<buffLen-windowN; i++)
{
  float result = 
        array[i] * С1 +
        array[i+1] * С2 +
        ...
        array[i+N-1] * СN;
}

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

Рекурсивный более скромен в плане ресурсов:
// мемберы, линия задержки

float _z1;
float _z2;
float _z3;
flozt _z4;
...
for(int i=0; i<buffLen; i++)
{
    _z4 = _z1;
    _z3 = _z2 * C3;
    _z2 = _z1 * C2;
    _z1 = array[i] * C1;
    float result = z4 * C4 + _z1;
}

S>И как результат сравнения? Дает ли переход в ансейф прирост? Насколько переход в нейтив бъет ансейф?

Дабы не разбрасываться голословно, подготовлю и выложу тесты.

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

V>Правильно, поэтому мы используем класс Socket только для инициализации (бо удобно очень), а потом берем хендл, и по UDP работаем не через класс сокета.
И как вы работаете "не через класс"? Даже если напрямю ДллИмпортировать неуправляемые Send и Receive, маршалер один хрен выполнит тот же пиннинг на время вызова. Потому что иначе никак — злой GC переместит буфер и привет.

V>Там какая-то возня по регистрам. Такое ощущение, в джит забили жесткие правила: такую-то адресацию делать так-то, другую так-то, и вот он вынужден жонглировать регистрами. Почему мне и показалось, что "протокол" соблюдают, дабы джит знал в каких регистрах искать ссылки.
Ссылки — да. Там же register map. Но я тут во всё более-менее верю.

V>Разве не проще на С/С++?
V>Согласен, для первого такого случая это же так муторно: надо еще один проект создать, в нем файл export.def, завести у себя класс NativeMethods
V>Зато каждый следующий случай добавляется за считанные секунды без этих "звездных войн". По крайней мере отдача адекватна вложенному результату.

V>Ха-ха по последнему.
V>Это должен быть путь не одинокого джедая, а как минимум серьёзного коллектива, т.к. сами оптимизации/развороты и прочее хоть и просты каждый в отдельности, но их охренительное кол-во, т.е. база знаний должна быть приличная.
Не, если коллектив — то и падаванов хватит.



V>нерекурсивный примерно такой (без оптимизаций):
V>

V>// смещаем окно вдоль последовательности
V>// развернутый вариант
V>for(int i=0; i<buffLen-windowN; i++)
V>{
V>  float result = 
V>        array[i] * С1 +
V>        array[i+1] * С2 +
V>        ...
V>        array[i+N-1] * СN;
V>}
V>

Угу. То есть развертка — в отказе от C[j] в пользу Cj.
V>Но наложение окна — это общая и довольно частая операция в обработке сигналов, когда инициализируется некий кодек или препроцессор, то ему динамиччески параметры сигнала дают, и он выделяет буфера динамически, и наложение окна — это цикл в цикле получается.


V>Рекурсивный более скромен в плане ресурсов:
V>// мемберы, линия задержки
V>

V>float _z1;
V>float _z2;
V>float _z3;
V>flozt _z4;
V>...
V>for(int i=0; i<buffLen; i++)
V>{
V>    _z4 = _z1;
V>    _z3 = _z2 * C3;
V>    _z2 = _z1 * C2;
V>    _z1 = array[i] * C1;
V>    float result = z4 * C4 + _z1;
V>}
V>

А, ну я так и думал — то есть теперь есть два "окна", которые едут мимо друг друга.


V>Дабы не разбрасываться голословно, подготовлю и выложу тесты.
ОК. Кул.

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

Q>Насчёт быстрее в общем случае, чем Си — это вряд ли. В некоторых случаях может быть быстрее кода на Си, в этом месте как правило спешат привести хрестоматийный пример qsort vs. std::sort. Собственно, это была одной из целей Страуструпа — не сильно потерять в производительности. Но совсем этого избежать не получилось.

У С++ гораздо больше возможностей работы в compile time, поэтому не в некторых случаех, а практически всегда.

V>>И что за повторяющаяся ахинея насчет "более сложных абстракций"?

Q>Исключения, например, сильно мешают некоторым оптимизациям, приводят к громоздкому бинарному коду. Совсем же без исключений на C++ писать трудно, тем более что даже простой new может бросить std::bad_alloc.

Исключения можно не использовать в критических местах.

Q>Шаблоны могут привести к разбуханию и дублированию бинарного кода, что как минимум скажется на cache locality (C++FQA).

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