Здравствуйте, criosray, Вы писали:
C>А с чего Вы решили, что он "некомпилябельный"?
вообще-то я спрашивал не вас, а автора поста. Вот конкретные вопросы:
— что такое body ?
— в с каким шагом изменяется пара (x,y) вдоль интервалов ?
И, чтобы не было разногласий, я хочу чтобы результат можно было легко проверить: генерируем цвета в массив. Сравниваем массивы.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, samius, Вы писали:
IID>Не увидел где там string.Replace, но тем не менее код (как тестовая платформа) мне по душе. Только модифицируйте его до компилябельного состояния.
Это не код, это способ задания поверхностей в рамках некоторого DSL. string.Replace как раз модифицирует его до компилябельного состояния. Предлагаю не заморачиваться на конкретном синтаксисе, а сделать любой удобный, но с тем чтобы на нем можно было описать аналогичный набор поверхностей.
IID>с каким шагом изменяется пара (x,y) ? Давайте так: законченный код на С#, генерирующий некоторый массив значений. По идентичности массивов можно судить о эквивалентности C# <=> C++ реализаций.
Шаг вычисляется из размеров окна программы, хотя можно его зафиксировать в целях сравнения, идентичность массивов не нужна, достаточно похожесть картинок на глаз. Это же не продукт, а пруф концепт 2002-го года из которого можно еще выжать скорость оптимизацией под инлайнинг.
А вот код пока я не дам. Да там и нет ничего интересного, позор один. string.Replace преобразует описание поверхностей в исходник, потом исходник компилится и создается экземпляр класса, реализующего некоторый интерфейс, с помощью которого можно спрашивать цвет указанной точки пространства.
S>>Непременное условие — возможность изменения описания поверхностей в рантайме.
IID>Это пока опустим, для простоты. Фактически, мы зафиксировали один из вариантов описания поверхностей, теперь посмотрим на скорость рендеринга по нему. Если очень хочется — можно померять две реализации, с вынесом констант в некоторую структуру "настроек".
Можно и опустить, главное чтобы описание поверхностей было "текстовым", например ресурсом или внешним файлом.
Реально собрался интерпретировать?
IID>Не такая, но и не в несколько процентов, как уверяют одепты .NET Для интереса можно и этим "померяться".
не интересно.
Здравствуйте, IID, Вы писали:
IID> IID>> так потрудись привести пример, подтверждающий твои слова. Если бы ты сказал что-то вроде "наивно думать что на С++ всё реализуется с такой же лёгкостью/гибкостью как в .NET" — не было бы таких вопросов к тебе. Раз заикнулся о скорости — давай говорить предметно. Измеряя скорость конструкций языка, а не скорость подсистем ввода вывода/сторонних парсеров/спутников на орбите/etc.
IID> M>Это все синтетика.
IID> Все тесты по сути синтетика.
Можно предложить решение реальной задачи. Например, WideFinder
IID> M>Как можно сравнивать if с if'ом?
IID> Не передёргивай Имелось ввиду измерение скорости самодостаточного алгоритма, который есс-но, описан этими самыми конструкциями. Алгоритма, а не сторонних библиотек/парсеров/сервисов ОС/и т.д.
Это какой-то сферовакуумный конь получается
IID> M>Вон, в «декларативном программировании» привели пример считывания файлов таки. Ленивый Хаскель всех порвал.
IID> Понятно, что ничего не делать можно за бесконечно малое время.
Я ошибся, там сравнивались алгоритмы внутри хаскеля, а не в сравнении с С++
Здравствуйте, gandjustas, Вы писали:
G>Если не рассматривать способ получения этого кода, то такие рассуждения не нужны. G>Это сродни тому что на ассемблере можно написать программу которая будет быстрее любой программы на любом языке.
Именно! Поэтому изначальная фраза, про то что С++ не может оказаться быстрее — глупость. Иными словами C++ всегда может работать НЕ МЕДЛЕНЕЕ дотнета.
Любопытно другое — на С++ можно написать код, который как не пыжься, на дотнете с одинаковой производительностью не повторить. (md5 например)
G>Тольео практика этот тезис не подтверждает.
Философствование насчёт практики — это выше по треду, когда коробочные продукты просили .NETовские показать. И пришли к выводу что практика это всё-таки С++. (VladD2 даже ввёл атрибут "тиражируемый" для С++ софта). Хотя у каждого "практика" может иметь собственный смысл.
В любом случае, мне рассуждения в таком ключе не интересны. Было желание увидеть "волшебный" .NET код, обгоняющий C++. А в итоге скатились на банальщину. И ещё раз подтвердили тот факт что С++ таки уделывает .NET по скорости.
Здравствуйте, samius, Вы писали:
IID>>Не увидел где там string.Replace, но тем не менее код (как тестовая платформа) мне по душе. Только модифицируйте его до компилябельного состояния. S>Это не код, это способ задания поверхностей в рамках некоторого DSL. string.Replace как раз модифицирует его до компилябельного состояния. Предлагаю не заморачиваться на конкретном синтаксисе, а сделать любой удобный, но с тем чтобы на нем можно было описать аналогичный набор поверхностей.
Компилябельность мне нужна для себя. Чтобы я мог на своём железе собрать оба варианта и померять скорость. Ибо твоё железо явно от моего отличается, и замеры по отдельности бессмысленны. Поэтому, чтобы не заморачиваться с рисованием картинок и предлагаю писать в массив. А шаг установить одинаковых для обоих вариантов.
Здравствуйте, IID, Вы писали:
IID>Философствование насчёт практики — это выше по треду, когда коробочные продукты просили .NETовские показать. И пришли к выводу что практика это всё-таки С++. (VladD2 даже ввёл атрибут "тиражируемый" для С++ софта). Хотя у каждого "практика" может иметь собственный смысл.
IID>В любом случае, мне рассуждения в таком ключе не интересны. Было желание увидеть "волшебный" .NET код, обгоняющий C++. А в итоге скатились на банальщину. И ещё раз подтвердили тот факт что С++ таки уделывает .NET по скорости.
Да, в идеальном мире, где время, человеко-часы, персональный скилл программистов — величины безграничные, а платформа только одна.
К сожалению (для вас), мы живем в вовсе не таком идеальном мире.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, gandjustas, Вы писали:
G>>Если не рассматривать способ получения этого кода, то такие рассуждения не нужны. G>>Это сродни тому что на ассемблере можно написать программу которая будет быстрее любой программы на любом языке.
IID>Именно! Поэтому изначальная фраза, про то что С++ не может оказаться быстрее — глупость.
А кто такое говорил?
IID> Иными словами C++ всегда может работать НЕ МЕДЛЕНЕЕ дотнета.
Не всегда, за счет динамической кодогенерации прога на .NET может работать быстрее аналогичной прогри на C++.
А вообще второе твое утверждение не эквивалентно первому, изучай логику.
IID>Любопытно другое — на С++ можно написать код, который как не пыжься, на дотнете с одинаковой производительностью не повторить. (md5 например)
Только это будет не C++, а голый С. Все фичи, которые тут обсасываются сторонниками С++ идут лесом.
G>>Тольео практика этот тезис не подтверждает.
IID>Философствование насчёт практики — это выше по треду, когда коробочные продукты просили .NETовские показать. И пришли к выводу что практика это всё-таки С++. (VladD2 даже ввёл атрибут "тиражируемый" для С++ софта). Хотя у каждого "практика" может иметь собственный смысл.
Почитай еще раз тему, очень много объяснений почему тиражируемый софт на С++ делается. IID>В любом случае, мне рассуждения в таком ключе не интересны. Было желание увидеть "волшебный" .NET код, обгоняющий C++. А в итоге скатились на банальщину. И ещё раз подтвердили тот факт что С++ таки уделывает .NET по скорости.
Здравствуйте, IID, Вы писали:
IID>Компилябельность мне нужна для себя. Чтобы я мог на своём железе собрать оба варианта и померять скорость. Ибо твоё железо явно от моего отличается, и замеры по отдельности бессмысленны. Поэтому, чтобы не заморачиваться с рисованием картинок и предлагаю писать в массив. А шаг установить одинаковых для обоих вариантов.
Компилябельность конкретного синтаксиса есть (после Replace-а). А вот чтобы в массив загнать — придется малость подкрутить. Что не обещаю сделать сегодня.
Если не секрет, что собрался сравнивать? Интерпретацию?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, IID, Вы писали:
IID>>Здравствуйте, gandjustas, Вы писали:
G>>>Если не рассматривать способ получения этого кода, то такие рассуждения не нужны. G>>>Это сродни тому что на ассемблере можно написать программу которая будет быстрее любой программы на любом языке.
IID>>Именно! Поэтому изначальная фраза, про то что С++ не может оказаться быстрее — глупость. G>А кто такое говорил?
IID>> Иными словами C++ всегда может работать НЕ МЕДЛЕНЕЕ дотнета. G>Не всегда, за счет динамической кодогенерации прога на .NET может работать быстрее аналогичной прогри на C++.
Ну вот давай возьмём некоторый конкретный выхлоп этой кодогенерации, перепишем на С++, и удивимся, что он работает быстрее.
Если рассматривать С# как быстрый скриптер — то очень близко к правде, он правда быстр. Но это не единственный возможный вариант для скриптинга. Например, Lua + JIT не сильно отстаёт по скорости, а по расходу памяти так и вообще впереди C#. Оставим пока скриптинг в стороне. Это, конечно, важная штука, но не везде она юзается и уж точно в одну кучу всё мешать не нужно.
G>А вообще второе твое утверждение не эквивалентно первому, изучай логику.
Первое выражение (твоё, кстати) — ложно. Чтобы сделать его истинным — применим отрицание. Что получим ?
!(C++ _никогда_ _не может_ _быстрее_) == С++ _всегда_ _может_ _не медленнее_
Или ты отрицание от С++ пытаешься взять ? :D
IID>>Любопытно другое — на С++ можно написать код, который как не пыжься, на дотнете с одинаковой производительностью не повторить. (md5 например) G>Только это будет не C++, а голый С. Все фичи, которые тут обсасываются сторонниками С++ идут лесом.
голый С это подмножество С++. Так что "это будет не С++", мягко говоря, ложь.
G>>>Тольео практика этот тезис не подтверждает.
IID>>Философствование насчёт практики — это выше по треду, когда коробочные продукты просили .NETовские показать. И пришли к выводу что практика это всё-таки С++. (VladD2 даже ввёл атрибут "тиражируемый" для С++ софта). Хотя у каждого "практика" может иметь собственный смысл. G>Почитай еще раз тему, очень много объяснений почему тиражируемый софт на С++ делается.
Была где-то хорошая мысль: если бы преимущества управляемой среды были бы действительно значимыми — переписали бы. Получается их значимость, как минимум, недостаточна.
Здравствуйте, IID, Вы писали:
IID>Ну вот давай возьмём некоторый конкретный выхлоп этой кодогенерации, перепишем на С++, и удивимся, что он работает быстрее.
Здравствуйте, samius, Вы писали:
S>Если не секрет, что собрался сравнивать? Интерпретацию?
Нет конечно C++ вариант соберу Intel C++ Compiler 11.0.072, померяю скорость. Результаты, ключи компиляции и EXE выложу куда-нибудь. C# буду собирать VS2008 (вроде бы SP1, но не уверен). Ключи компиляции, версия CLR/языка, любые другие особенности сборки — как ты сам скажешь. Результаты тоже опубликую.
Здравствуйте, criosray, Вы писали:
C>Откройте документацию по xUnit.NET, откройте документацию по RhinoMocks и почитайте. Заниматься восполнением пробелов в Вашем образовании не намерен
Т.е. обсуждать на форуме эти возможности ты не в состоянии? Так я и думал.
V>>Не надоело рефлексировать и показывать в очередной раз свой поверхностный взгляд? Все твои вызовы мокков ради ассертов, собственно и сделаны. И хоть они теперь не в фас, а в профиль — они были и есть цель любого автоматического теста (не обязательно юнит...) C>"Все твои вызовы мокков ради ассертов, собственно и сделаны" — это напоминает генератор цепей Маркова. Взять два умных слова, и связать их между собой связующими. Получается билеберда, но звучит вроде как умно для стороннего человека.
Не смотря на выделенное ключевое слово, ты не понял, о чем речь. Хоть честно признался, что для тебя это билеберда.
C>Так вот, ликбез: мокинг выполняется с целью изолировать тестируемый объект от внешних зависимостей.
Странно, а я думал, что лет 40 до этого эту ф-ию выполняли заглушки... Или они нужны были для "чего-то другого"?
Блин, ты как только проснулся, что-то увидел, проникся и стал "вещать"... В отрыве от предыстории и сравнения различных способов достичь аналогичных целей ты будешь оставаться в своей роли проповедника хари кришны. А если будешь готов поговорить более предметно, надеюсь поймешь, что за деревьями потерял лес.
C>Что означает, что ожидается, что будет вызван databaseManager.BeginTransaction(), а потом в любом порядке будут вызваны Withdraw и Deposit.
И что сказать хотел? Ты ведь примитивизм какой-то приводишь... Который, кстати на АОП куда как прикольней выглядит, и не требует проверки на 4 после 2*2.
C>Ассерты и моки не цель. Это средство и ключевой механизм реализации юнит тестов.
Опять ошибка, это ср-во автоматизации тестирования в первую очередь. Интеграционному и регрессионному тестированию так же помогают и заглушки и изоляция и весь суповой набор и используются те же ср-ва автоматизации, наподобии xUnit.
C>При чем тесты ни коим образом не захламляют код. Все тесты находятся в отдельной сборке, которая "видит" (и только она одна) внутренности тестируемых сборок.
Это более чем не принципиально. Мы вот делим тестирующие сборки на "пояса безопасности", так удобнее (знаешь что это?). В общем, по-прежнему разговор ни о чем.
V>>Любую динамическую среду/заглушки, которые генерят переменный по насыщенности траффик или сообщения с разной задержкой и произвольным наполнением. Фишка в том, что реальных задержек-то и нет, текущее время эмулируется, но тестирующая последовательность слишком длинная, чтобы записывать её ручками, она генерируется программой. А таких последовательностей/программ у меня — мама не горюй.
C>Еще один ликбез: описанное Вами не является модульными тестами. Это т.н. integration tests. При чем ничего невозможного в реализации этого нет — описанное реализуется элементарно в .NET.
Ты наверно плохо прочитал описанное Мною, тестируется работоспособность ровно одного юнита.
Ты попался в ту же ловушку, как и большинство, ратующих за строгую изоляцию юнит-тестов от интеграционных, не понимая сути вещей. Ответь здесь
насчет использования классов фреймворка в процессе юнит-тестирования. Гена тебе разжевал и практически в рот положил то, что должен был понять сам давно, но ты отмахнулся и поскакал дальше.
V>>Далее, обмен сложными структурами данных заглушки и тестируемого объекта, у объекта приличное пространство состояний, на что заглушка должна грамотно реагировать, т.е. приличная иногда логика на if-ах и case-ах. C>Элементарно средствами RhinoMocks.
Во-первых, мне гораздо больше по душе TypeMock, по сравнению с которым рино курит, во вторых даже на нем это не элементарно.
V>>В декларативном синтаксисе мокков это выглядит как удаление гландов через Ж, и чем осмысленнее логика — тем более глубокое погружение в эту Ж. А если процедура внешняя, то это лишняя тестирующая сущность и все такое.
C>Демагогия.
C>Выглядит преотлично. На много лучше, чем то, что у вас есть (а точнее нет) в unmanaged C++. lambda выражения и fluent interface дают прекрасную читабельность.
Как раз в С++ можно поинтересней синтаксис придумать для такого примера, и даже на проперти не через тектовый токен сослаться (что сакс)... Проблема-то там не в этом, а в бинарной совместимости. Тут уже написал по этой теме (последние 3 абзаца): http://www.rsdn.ru/Forum/message/3395444.1.aspx
V>>А теперь смотри что получается: автомоками удобно пользоваться для оформления относительно несложных тестов, где внешние условия и реакцию на них вполне можно описать декларативно и синтаксис все еще не будет раздражать. C>Модульные или unit тесты ОБЯЗАНЫ быть несложными. В этом их СУТЬ.
Беда-беда... Ты же сам где-то правильно говорил, что есть модульные тесты, а теперь несешь отсебятину. Тесты должны быть в первую очередь адекватны задаче и коду, а сложные/несложные — разговор в пользу бедных. Ты еще начни тут вещать, что "код тоже всегда простой", сразу можно будет пожизненно в сайтостроители оформлять.
V>>Ах да, чуть не забыл... разумеется без них практически никак, если у кого-то был неудержимый понос на Ынтерфейсы в период дизайна. Собственно для них в первую очередь оно и есть. C>Нет, не для них. Вам не надоело ламерствовать?
Развлекаюсь, пока мне интересно. Например, ты опять нихрена не понял. Когда упоминают тучи интерфейсов, то имеют ввиду сильную связанность дизайна. А теперь прочитай твои собственные обрывки, где ты говорил для чего, по-твоему, нужны моки. И кто теперь ламер?
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, samius, Вы писали:
S>>Если не секрет, что собрался сравнивать? Интерпретацию?
IID>Нет конечно C++ вариант соберу Intel C++ Compiler 11.0.072, померяю скорость. Результаты, ключи компиляции и EXE выложу куда-нибудь. C# буду собирать VS2008 (вроде бы SP1, но не уверен). Ключи компиляции, версия CLR/языка, любые другие особенности сборки — как ты сам скажешь. Результаты тоже опубликую.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, IID, Вы писали:
IID>>Здравствуйте, samius, Вы писали:
S>>>Если не секрет, что собрался сравнивать? Интерпретацию?
IID>>Нет конечно C++ вариант соберу Intel C++ Compiler 11.0.072, померяю скорость. Результаты, ключи компиляции и EXE выложу куда-нибудь. C# буду собирать VS2008 (вроде бы SP1, но не уверен). Ключи компиляции, версия CLR/языка, любые другие особенности сборки — как ты сам скажешь. Результаты тоже опубликую.
S>Это не решение задачи.
С точки зрения оценки производительности — нормально. Если я буду рендерить картинку сгенерированным .NET кодом час, а плюсовым — пару минут этого более чем достаточно. Как приду домой — замеряю.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, IID, Вы писали:
IID>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Если не рассматривать способ получения этого кода, то такие рассуждения не нужны. G>>>>Это сродни тому что на ассемблере можно написать программу которая будет быстрее любой программы на любом языке.
IID>>>Именно! Поэтому изначальная фраза, про то что С++ не может оказаться быстрее — глупость. G>>А кто такое говорил?
IID>ты говорил =) вот здесь
Ну тупи. "Не всегда быстрее" = "иногда медленее". Сам себе что-то придумываешь, а потом непонятно кому доказываешь.
IID>>> Иными словами C++ всегда может работать НЕ МЕДЛЕНЕЕ дотнета. G>>Не всегда, за счет динамической кодогенерации прога на .NET может работать быстрее аналогичной прогри на C++.
IID>Ну вот давай возьмём некоторый конкретный выхлоп этой кодогенерации, перепишем на С++, и удивимся, что он работает быстрее.
Ну и что?
G>>А вообще второе твое утверждение не эквивалентно первому, изучай логику.
IID>Первое выражение (твоё, кстати) — ложно. Чтобы сделать его истинным — применим отрицание. Что получим ? IID>!(C++ _никогда_ _не может_ _быстрее_) == С++ _всегда_ _может_ _не медленнее_ IID>Или ты отрицание от С++ пытаешься взять ? :D
Бред ты пишешь.
Если формально рассуждать, что мое утверждение выглядит как: !(ForAll(программы) реализация на C++ -> самая быстрая), ! — отрицание, -> — импликация, ForAll(программы) — квантор всеобщности.
Если спустить отрицание, то получится (Exists(программы) !(реализация на С++ -> самая быстрая)), где Exists — квантор существования.
Отрицание имликации истинно (сама импликация ложна) только в том случае, когда посылка истина, а следствие ложно.
В итоге по-русски можно написать "сществуют программы, для которых реализация на С++ окажется не самой быстрой", что совсем по-русски звучит как "иногда программы на С++ медленее", а не то что ты придумал.
Иди ботай логику, потом возвращайся. А то тебя в КСВ будут за шеридана держать.
IID>>>Любопытно другое — на С++ можно написать код, который как не пыжься, на дотнете с одинаковой производительностью не повторить. (md5 например) G>>Только это будет не C++, а голый С. Все фичи, которые тут обсасываются сторонниками С++ идут лесом. IID>голый С это подмножество С++. Так что "это будет не С++", мягко говоря, ложь.
Это как раз правда.
Более того, голый C практически является подмножеством C#, за исключением некоторых детаей работы с указателями.
IID>Была где-то хорошая мысль: если бы преимущества управляемой среды были бы действительно значимыми — переписали бы. Получается их значимость, как минимум, недостаточна.
Страшная бредятина. С экономической тоочки зрения переписывать готовый продукт под другую платформу невыгодно совсем, несмотря на любые преимущества платформы.
А вообще если бы С++ был так крут как о нем тут пишут, то .NET даже не появился бы.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, samius, Вы писали:
S>>Это не решение задачи.
IID>С точки зрения оценки производительности — нормально. Если я буду рендерить картинку сгенерированным .NET кодом час, а плюсовым — пару минут этого более чем достаточно. Как приду домой — замеряю.
Задача не в том чтобы картинку срендерить, а в том, чтобы предоставить интерактивный рендерер/считалку, который позволяет изменять описание поверхностей в рантайме.
То что ты соберешь под Intel C++ Compiler 11.0.072, меня не волнует, пока ты не включить его в свою программу.
Здравствуйте, gandjustas, Вы писали:
G>То что С++ (именно с плюсами) нах не нужен. Для быстрых числомолотилок берем код на C и нормально зовем его из любого языка.
Я уже не первый раз вижу это мнение, но не могу понять мотивы, может объяснишь? Наилучшие по оптимизации компиляторы — это С++, и они умеют коомпилировать С-код. Вот смысл мне не пользоваться возможностями более высокоуровневого языка, если у мня все-равно будет использован компилятор, который прекрасно компилит оба языка. Смотри: в чистом С ссылочный тип не строго типизирован, нет инлайна, нет инициализации по месту, недоступна ОО-декомпозиция (а в этом миксере участвует около десятка классов, и кое-какая шаблонность есть, правда без претензий на МП) и т.д и т.п. Поэтому поинт не понятен совершенно, по мне С++ в стиле "С с классами" все равно гораздо мощнее С. Я бы советовал ровно наоборот, там где можно, вместо С использовать С++.
G>Для более высоких абстракций берем более подходящие языки.
Дело в вышине абстракций, а вычислительной модели. Для задачи надо брать подходящую вычислительную модель. Да, на GC многие задачи решаются проще, даже если брать языки с убогим синтаксисом просто в силу подходящей вычислительной модели.
G>Кроме того уже не за горами запуск числомолотилок на GPU, там тоже высокоуровневые языки будут более уместны, так как позволят генерить код для GPU в рантайме.
Фиг его знает, что будет. При количестве ядер, больше 16/32/64, сам факт наличия GPU будет под вопросом. В любом случае, обсуждать сегодня то, что может быть завтра, в контексте сделанной вчера задачи — юморно.
G>Ну тупи. "Не всегда быстрее" = "иногда медленее". Сам себе что-то придумываешь, а потом непонятно кому доказываешь.
Примера этого "иногда медленее" я так и не увидел, между прочим.
G>В итоге по-русски можно написать "сществуют программы, для которых реализация на С++ окажется не самой быстрой", что совсем по-русски звучит как "иногда программы на С++ медленее", а не то что ты придумал.
Ой как хорошо. Т.к. мы рассуждаем о .NET-е, то ОЧЕНЬ хочется посмотреть на такую .NET программу, для которой реализация на C++ окажется не самой быстрой. И не заваливайся в сторону "всё другие языки vs C++", мы готоврим только о .NET vs C++.
g> В итоге по-русски можно написать "сществуют программы, для которых реализация на С++ окажется не самой быстрой", что совсем по-русски звучит как "иногда программы на С++ медленее", а не то что ты придумал.
Кстати, а есть таки примеры, где это так? Вроде, где-то в КСВ приводили примеры, я сейчас не найду
g> В итоге по-русски можно написать "сществуют программы, для которых реализация на С++ окажется не самой быстрой", что совсем по-русски звучит как "иногда программы на С++ медленее", а не то что ты придумал.
Кстати, а есть таки примеры, где это так? Вроде, где-то в КСВ приводили примеры, я сейчас не найду
