Re[28]: Работа - с чего начать: С++ или С#?
От: IID Россия  
Дата: 19.05.09 08:19
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Пример не приведу, ибо очень большо получится. Но основная суть в том, что в .NET можно генерировать код в рантайме.


Неужели кратко продемонстрировать скоростные возможности языка никак не получается ? Если уж сильно хочется генерировать код в рантайме и чтобы не скатываться в сторону "я сейчас наворочу динамическую кодогенерацию, её в С++ нет, и никто со мной связываться не захочет" можно поступить очень просто: берём (фиксируем) один любой, наперёд заданный, результат этой самой генерации, и меряем скорость.
kalsarikännit
Re[29]: Работа - с чего начать: С++ или С#?
От: samius Япония http://sams-tricks.blogspot.com
Дата: 19.05.09 08:29
Оценка:
Здравствуйте, IID, Вы писали:

IID>Неужели кратко продемонстрировать скоростные возможности языка никак не получается ?

Дело не в языке, а скорее в платформе.
IID>Если уж сильно хочется генерировать код в рантайме и чтобы не скатываться в сторону "я сейчас наворочу динамическую кодогенерацию, её в С++ нет, и никто со мной связываться не захочет" можно поступить очень просто: берём (фиксируем) один любой, наперёд заданный, результат этой самой генерации, и меряем скорость.

Я уже приводил в пример расчеты (пусть это будут пространственные запросы) по телам, ограниченными аналитически заданными поверхностями. На .net это возможно сделать через кодогенерацию. В C++ кодогенерация недоступна, следовательно использовать можно парсеры, интерпретаторы и т.п.
Хочется сравнивать скорость в этом примере? Если да, то от Вас требуется предоставить решение на С++, потом договоримся о конфигурации тел и померяем скорость...
Re[30]: Работа - с чего начать: С++ или С#?
От: hattab  
Дата: 19.05.09 08:39
Оценка:
Здравствуйте, samius, Вы писали:

S>Я уже приводил в пример расчеты (пусть это будут пространственные запросы) по телам, ограниченными аналитически заданными поверхностями. На .net это возможно сделать через кодогенерацию. В C++ кодогенерация недоступна, следовательно использовать можно парсеры, интерпретаторы и т.п.


Просто пример в тему: для нативной Delphi есть скриптеры с компиляцией в x86, есть компиляторы формул (похоже тема вообще популярная), есть в конце-концов бесплатные компиляторы командной строки . Не думаю, что у C++ с этим хуже.
Re[29]: Работа - с чего начать: С++ или С#?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.05.09 08:42
Оценка: -1 :))
Здравствуйте, IID, Вы писали:

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


G>>Пример не приведу, ибо очень большо получится. Но основная суть в том, что в .NET можно генерировать код в рантайме.


IID>Неужели кратко продемонстрировать скоростные возможности языка никак не получается ?

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

IID>Если уж сильно хочется генерировать код в рантайме и чтобы не скатываться в сторону "я сейчас наворочу динамическую кодогенерацию, её в С++ нет, и никто со мной связываться не захочет" можно поступить очень просто: берём (фиксируем) один любой, наперёд заданный, результат этой самой генерации, и меряем скорость.

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

ЗЫ. Я уже писал в этой теме тест, который меряет выделение памяти стандартным аллокатором. .NET выигрывает.
Re[31]: Работа - с чего начать: С++ или С#?
От: samius Япония http://sams-tricks.blogspot.com
Дата: 19.05.09 08:44
Оценка:
Здравствуйте, hattab, Вы писали:

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


S>>Я уже приводил в пример расчеты (пусть это будут пространственные запросы) по телам, ограниченными аналитически заданными поверхностями. На .net это возможно сделать через кодогенерацию. В C++ кодогенерация недоступна, следовательно использовать можно парсеры, интерпретаторы и т.п.


H>Просто пример в тему: для нативной Delphi есть скриптеры с компиляцией в x86, есть компиляторы формул (похоже тема вообще популярная), есть в конце-концов бесплатные компиляторы командной строки . Не думаю, что у C++ с этим хуже.


Ну так-то конечно, на худой конец можно на C++ нагенерить и выполнить код с помощью .net-а
Re[32]: Работа - с чего начать: С++ или С#?
От: hattab  
Дата: 19.05.09 08:47
Оценка:
Здравствуйте, samius, Вы писали:

S>>>Я уже приводил в пример расчеты (пусть это будут пространственные запросы) по телам, ограниченными аналитически заданными поверхностями. На .net это возможно сделать через кодогенерацию. В C++ кодогенерация недоступна, следовательно использовать можно парсеры, интерпретаторы и т.п.


H>>Просто пример в тему: для нативной Delphi есть скриптеры с компиляцией в x86, есть компиляторы формул (похоже тема вообще популярная), есть в конце-концов бесплатные компиляторы командной строки . Не думаю, что у C++ с этим хуже.


S>Ну так-то конечно, на худой конец можно на C++ нагенерить и выполнить код с помощью .net-а


Это не к вопросу перформанса, это к вопросу о плюсах платформы
Re[30]: Работа - с чего начать: С++ или С#?
От: IID Россия  
Дата: 19.05.09 08:48
Оценка:
Здравствуйте, samius, Вы писали:

S>Я уже приводил в пример расчеты (пусть это будут пространственные запросы) по телам, ограниченными аналитически заданными поверхностями. На .net это возможно сделать через кодогенерацию. В C++ кодогенерация недоступна, следовательно использовать можно парсеры, интерпретаторы и т.п.


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

Давай тогда я пример приведу, раз от тебя внятного и короткого семпла не добиться: будем мерять скорость md5. По 64 раунда стандартного алгоритма на блок. Сложностей это закодить нет никаких, не надо ни парсеры писать, ни предметную область изучать. Жду реализацию на .NET
kalsarikännit
Re[30]: Работа - с чего начать: С++ или С#?
От: hattab  
Дата: 19.05.09 08:51
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

G>ЗЫ. Я уже писал в этой теме тест, который меряет выделение памяти стандартным аллокатором. .NET выигрывает.


Ты так часто это повторяешь, что скоро и сам поверишь...
Re[31]: Работа - с чего начать: С++ или С#?
От: samius Япония http://sams-tricks.blogspot.com
Дата: 19.05.09 08:52
Оценка: +1
Здравствуйте, IID, Вы писали:

IID>Давай тогда я пример приведу, раз от тебя внятного и короткого семпла не добиться: будем мерять скорость md5. По 64 раунда стандартного алгоритма на блок. Сложностей это закодить нет никаких, не надо ни парсеры писать, ни предметную область изучать. Жду реализацию на .NET


Ты просил пример, где программа на C++ сольет в разы. Я привел. Пример, где сольет дотнет я не просил. Доказывать что md5 на С будет немного быстрее C# мне не надо.
Re[30]: Работа - с чего начать: С++ или С#?
От: IID Россия  
Дата: 19.05.09 08:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

IID>>Если уж сильно хочется генерировать код в рантайме и чтобы не скатываться в сторону "я сейчас наворочу динамическую кодогенерацию, её в С++ нет, и никто со мной связываться не захочет" можно поступить очень просто: берём (фиксируем) один любой, наперёд заданный, результат этой самой генерации, и меряем скорость.

G>Не надо жопой вилять. Как раз динамическая кодогенерация позволяет написать программу так чтобы она работала в общем случае быстрее нативной.
G>Если взять один конкретный случай (набор входных данных), то смотри выше про ассемблер.

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

G>Самообман — думать что C++ всегда быстрее.


так потрудись привести пример, подтверждающий твои слова. Если бы ты сказал что-то вроде "наивно думать что на С++ всё реализуется с такой же лёгкостью/гибкостью как в .NET" — не было бы таких вопросов к тебе. Раз заикнулся о скорости — давай говорить предметно. Измеряя скорость конструкций языка, а не скорость подсистем ввода вывода/сторонних парсеров/спутников на орбите/etc.
kalsarikännit
Re[38]: Работа - с чего начать: С++ или С#?
От: vdimas Россия  
Дата: 19.05.09 08:59
Оценка: 5 (2) +2
Здравствуйте, gandjustas, Вы писали:

V>>Садись, два.

V>>Роутеры и маршрутизаторы с этой же точки зрения тоже разные вещи, использующиеся в разных местах сети.

G>http://www.martinfowler.com/articles/mocksArentStubs.html — курить до просветления.


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

Вот смотри, самое формальное, что у него там есть:

- Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.
Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.


Может ли мок не являться заглушкой даже в этой предложенной терминологии? После ответа на этот вопрос вышеприведённым уже можно подтереться...
Кстати, а как тебе выделенное курсивом? Товарищ явно сочуствует XP и TDD и не в состоянии скрыть этого факта даже в формулировках.

А вообще, странные пошли времена... Вместо кратких формулировок теперь надо давать ссылки на воду? Ты так хочешь чувствовать себя одним из миллионнов лемингов?

Свернув всю статью и убрав очередные его сопли о TDD, Фаулер просто предлагает называть моками класс тестовых объектов в которые встроены ассерты/логирования, работающие во время вызовов методов, а не постфактум. Использовали раньше эти приемы, до выхода мок-фреймворков? — разумеется, ни один более- менее сложный тест без этого не обходился и не обходится. И как нашей русскоязычной терминологии такие тестовые объекты назывались, так и называются заглушками. Так что, когда появится термин с формальным определением, приходи еще раз.

А пока можно лишь сублиммировать преценденты использования термина, что вовсе не сложно. Т.к. термин относительно новый, можно сказать, что только формируется, нужно "читать" его формирователей, а это доки к ср-вам автомокостроения, форумы и статьи по этим ср-вам. Очевидное в том, что эти ср-ва одинаково позволяют строить как moks так и stubs в терминологии Фаулера, причем явно и декларативно отличить одно от другого можно лишь по совокупности и характеру декларируемых ассертов (опять же в терминологии Фаулера ). Так же, наблюдая обсуждения по этой теме в Сети и просматривая множество статей на эту тему, убедился, что всевозможные авторы пользуются термином "мок" вовсе без того характерного отличия на котором настаивает автор по ссылке. Наиболее частое употребление термина мок на сегодня относится к тестовому объекту, построенному автоматически, имеющему бинарную совместимость с мимикрируемым объектом и снабженному возможностью декларативно/полудекларативно задавать поведение и проверки. ВсЁ, остальное — от лукавого, и разговоры в пользу бедных, по крайней в данный момент жизни этого термина.

Я лично могу поставить на то, что ключевым в формулировке останется "автоматически, имеющему совместимость с мимикрируемым ...", а то термин насколько пошел в массы, что рукописные заглушки стали называть рукописными моками, что малость бред. Бред хотя бы потому, что когда заглушки пишут руками (как было раньше), вот этих "характерных" отличий, на которых настаивает Фаулер просто быть не могло, ибо руками — оно и в Африке руками, т.е. можно написать всё, что необходимо — любые сценарии тестирования. А эти "характерности" сегодня идут от возможностей ср-в автоматизации тестирования, которые, в отличие от рукописного подхода, вовсе не безграничны. С другой стороны, перевод на русский "макет/подражание" — весьма неплох, так что возможна замена одного термина другим, но навряд ли одновременное использование в разных смыслах (ибо термин заглушки и так широк — шире не куда).


G>Как провсетление наступит можно выложить сюда реализацию моков на С++


Все замечания относительно реализации автомоков на С++ уже были сделаны здесь: http://www.rsdn.ru/forum/message/3393322.1.aspx
Автор: vdimas
Дата: 18.05.09


Для С++ нет проблем декларативно описать поведение и ассерты мока, есть проблемы с автоматическим построением бинарных заместителей. Могу еще раз упомянуть, что для COM возможно автоматическое построение "заместителей", если сигнатуры методов являются OLE-совместимыми. В остальных случаях, до принятия единого ABI, автоматическое построение заместителей возможно лишь в компайлтайм, либо глубоко завязанное на конкретный компилятор и формат его PDB. Так что, как я уже сказал — возможно, но пока что слишком трудозатратно. И говорил уже, что для С++ есть свои наработки для тестирования, т.к. есть возможности, которых нет у управляемых платформ, и обратно тоже верно. Поэтому никто идиотизмом не занимаются, а используют наиболее подходящие ср-ва для своей платформы.

Как я делаю иногда на С++, когда мне надо "вклиниться" в реальный объект в тестовых/проверочных целях? Пользуюсь тем, что декларация и реализация обычно лежат по разным файлам, реализация разных методов классов тоже может находится по разным cpp-файлам, и собирается это вместе только при линковке. Таким образом, в тестовый бинарник вполне можно частично или полностью прилинковывать тестовую имплементацию классов, вместо основной. Но и это не самая популярная мера, скорее вынужденная, когда тестовый код значителен и сложен. Самый популярный вид тестирования в С++ — это использование в качестве моков не заместителей, а самих реальных объектов, именно! Такая технология доступна из-за препроцессинга и условной компиляции. В нужных местах после каждого чиха может стоять куча проверок, которые работают, например, только в дебаг-конфигурации, но отсутствуют в релизе. Это могут быть проверки или логгирование или и то и другое и т.д. На какой стороне это работает? Что там получается, стабы или моки в терминологии Фаулера? Да на любой стороне это работает, на той стороне, где ТРЕБУЕТСЯ проверка. Как насчет изолированности при тестах? То бишь как насчет выключения лишнего "тяжелого" кода, не являющегося целевым для тестирования? Опять же, с помощью условной компиляции делается изоляция любого уровня.

Удобнее такой подход, в сравнении с подходом управляемых платформ или скриптовых языков? Фиг там можно сказать однозначно, можно найти кучу как плюсов, так и минусов и там и там, поэтому сами по себе подобные споры — чистейшей воды холивар. Мне, например, импонирует, что простые тесты можно писать прямо одновременно с кодом в С++, не размазывая функциональность. К тому же, подобные тесты прямо в строках кода являются своего рода документацией, задающей граничные или какие другие условия/ограничения. В общем, тема серьезная, и не на том уровне это надо обсуждать, какой навязывает criosray.
Re[39]: Работа - с чего начать: С++ или С#?
От: vdimas Россия  
Дата: 19.05.09 09:03
Оценка:
Здравствуйте, criosray, Вы писали:

C>vdimas: Вас, однако, mock`нули.


Тебе лучше было бы ответить на свои банальности, выдаваемые за откровения, относительно CLR и фреймворков здесь
Автор: vdimas
Дата: 18.05.09
.
Re[32]: Работа - с чего начать: С++ или С#?
От: IID Россия  
Дата: 19.05.09 09:04
Оценка:
Здравствуйте, samius, Вы писали:

S>Ты просил пример, где программа на C++ сольет в разы. Я привел. Пример, где сольет дотнет я не просил.


Ссылку с C# кодом подтрудись привести, в ворохе твоих сообщений сходу не нашёл. И учти, я не буду писать абсолютно идентичный вариант, если используется кодогенерация. Мне моё время дорого. Раз этого не хочешь сделать ты — я сам зафиксирую один (произвольный) вариант исполнения алгоритма. Не факт что он будет оптимальным для тебя.

S>Доказывать что md5 на С будет немного быстрее C# мне не надо.


НЕМНОГО ?!! Ты уверен что это действительно будет НЕМНОГО? (кстати, что такое НЕМНОГО? пара процентов ? или, может быть, разы ?)
kalsarikännit
Re[31]: Работа - с чего начать: С++ или С#?
От: criosray  
Дата: 19.05.09 09:16
Оценка:
Здравствуйте, IID, Вы писали:

IID>Т.е. товарищ всеръез считает, что можно написать на .NET программу, которая окажется быстрее чем С++. Мой же поинт в том, что С++ всё-таки быстрее (уж во всяком случае точно не медленнее).


Можно написать. У каждой проблемы существует множество решений. Более экспрессивные средства и инструменты дотнет позволяют писать код на много быстрее, уделяя больше времени качеству кода, продуманности дизайна и выбора алгоритмов, ну и наконец быстро профилировать, выявлять узкие места и ликвидировать их.
Re[31]: Работа - с чего начать: С++ или С#?
От: MxKazan Португалия  
Дата: 19.05.09 09:22
Оценка:
Здравствуйте, IID, Вы писали:

IID>C++ код изначально компилируется. Так что непонятно, что "волшебного" даст "компиляция при первом вызове", особенно если не забывать про ограничения по времени на эту компиляцию. Рассматриваем пока в контексте одинакового железа для выполнения, не скатываясь к "потенциальным оптимизациям в будушем под свежее железо". На этот случай, например, есть GCC + LLVM. Но речь о другом.

Никакого волшебства. Просто если функция вызывается 1000 раз, компилироваться она будет только 1 раз, остальные 999 будет работать машинный код. Чтобы снова не было придирок: я не утверждаю, что эти 999 работают быстрее, чем аналогичный код на С++. А для особо волнующихся, есть NGen.
Re[33]: Работа - с чего начать: С++ или С#?
От: samius Япония http://sams-tricks.blogspot.com
Дата: 19.05.09 09:26
Оценка: 5 (3)
Здравствуйте, IID, Вы писали:

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


S>>Ты просил пример, где программа на C++ сольет в разы. Я привел. Пример, где сольет дотнет я не просил.


IID>Ссылку с C# кодом подтрудись привести, в ворохе твоих сообщений сходу не нашёл. И учти, я не буду писать абсолютно идентичный вариант, если используется кодогенерация. Мне моё время дорого. Раз этого не хочешь сделать ты — я сам зафиксирую один (произвольный) вариант исполнения алгоритма. Не факт что он будет оптимальным для тебя.

Собрался доказывать что интерпретируемый вариант быстрее компилированного? Маньяк!
Ссылки на исходники небыло.

Вобщем так:
Примерно такого рода DSL, придуманный под string.Replace, чтобы без парсинга
function Сфера { return x*x + y*y + z*z; }
function XPlaneFunc { return x;}
function YPlaneFunc { return y;}
function ZZZFunc
{
    double xmy = x - y; return xmy - Math.Round(xmy, 1);
}
function Спираль
{
    double xk=x*20; double a=0.2; double b=1.5;
    double y1=y*b-a*Math.Sin(xk);
    double z1=z*b-a*Math.Cos(xk);
    return y1*y1 + z1*z1;
}
body Голова
{
    return XPlaneFunc(p) < 0.0 && Сфера(p) < 1.0 && !Шлиц;
}
body Spiral
{
    return  XPlaneFunc(p) > 0.0 && XPlaneFunc(p) < 1.75 && Math.Abs(Спираль(p)) < 0.5;
}
body Шлиц
{
    return XPlaneFunc(p) < -0.4 && YPlaneFunc(p) < 0.1 && YPlaneFunc(p) > -0.1;
}
body Strokes
{
    return (Math.Abs(0.5 - XPlaneFunc(p)) < 0.02
     || (XPlaneFunc(p) > 0.5 && Math.Abs(ZZZFunc(p)) < 0.005))
    && !Spiral && !Голова;
}
body All
{
    return Голова || Spiral || Strokes || Wall;
}
body Wall
{
    return XPlaneFunc(p) > 0.5 && !Strokes && !Spiral;
}
colors GetColor
{
    if(Голова) return Color.Blue;
    if(Spiral)return Color.Red;
    if(Strokes)return Color.Black;
    if(Wall)return Color.Gray;
    return Color.Transparent;
}


Далее рисуем на растре плоскость Z = 0 в квадрате -1<x<2; -1.5<y<1.5
Должно получиться что-то типа болта, вкрученного в стену.

Непременное условие — возможность изменения описания поверхностей в рантайме.

Примерная скорость реализации на шарпе 5.9 млн запросов по цвету в секунду на одном ядре.
На днях выложу картинку в блоге.

Учти, твое время я оплачивать не буду!

S>>Доказывать что md5 на С будет немного быстрее C# мне не надо.


IID>НЕМНОГО ?!! Ты уверен что это действительно будет НЕМНОГО? (кстати, что такое НЕМНОГО? пара процентов ? или, может быть, разы ?)

Уверен, что разница будет не такая, как между выполнением кода и интерпретацией
Re[31]: Работа - с чего начать: С++ или С#?
От: criosray  
Дата: 19.05.09 09:28
Оценка:
Здравствуйте, hattab, Вы писали:

S>>Я уже приводил в пример расчеты (пусть это будут пространственные запросы) по телам, ограниченными аналитически заданными поверхностями. На .net это возможно сделать через кодогенерацию. В C++ кодогенерация недоступна, следовательно использовать можно парсеры, интерпретаторы и т.п.


H>Просто пример в тему: для нативной Delphi есть скриптеры с компиляцией в x86, есть компиляторы формул (похоже тема вообще популярная), есть в конце-концов бесплатные компиляторы командной строки . Не думаю, что у C++ с этим хуже.


Скриптеры будут заведомо менее производительны. Даже такие продвинутые как Lua — даже они в разы медленнее машинного кода, генерируемого CLR. Это конечно не значит, что их производительности не будет хватать на многих задачах — уверен, что будет, но здесь многие переживают за невидимые такты и неслышимые байты оверхеда (юношеский максимализм — что поделаешь...).
Re[31]: Работа - с чего начать: С++ или С#?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.05.09 09:31
Оценка:
Здравствуйте, IID, Вы писали:

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


IID>>>Если уж сильно хочется генерировать код в рантайме и чтобы не скатываться в сторону "я сейчас наворочу динамическую кодогенерацию, её в С++ нет, и никто со мной связываться не захочет" можно поступить очень просто: берём (фиксируем) один любой, наперёд заданный, результат этой самой генерации, и меряем скорость.

G>>Не надо жопой вилять. Как раз динамическая кодогенерация позволяет написать программу так чтобы она работала в общем случае быстрее нативной.
G>>Если взять один конкретный случай (набор входных данных), то смотри выше про ассемблер.

IID>Я говорил не проконкретный набор входных данных, а про фиксацию алгоритма, скорость которого будем сравнивать. Ещё раз, для прапорщиков: раз ты утверждал что:


IID>

G>>Самообман — думать что C++ всегда быстрее.


IID>так потрудись привести пример, подтверждающий твои слова. Если бы ты сказал что-то вроде "наивно думать что на С++ всё реализуется с такой же лёгкостью/гибкостью как в .NET" — не было бы таких вопросов к тебе. Раз заикнулся о скорости — давай говорить предметно. Измеряя скорость конструкций языка, а не скорость подсистем ввода вывода/сторонних парсеров/спутников на орбите/etc.


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

Как же тогда померить скорость lisp, там из конструкций языка только скобки?
Re[31]: Работа - с чего начать: С++ или С#?
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.05.09 09:32
Оценка: :))
Здравствуйте, hattab, Вы писали:

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


G>>ЗЫ. Я уже писал в этой теме тест, который меряет выделение памяти стандартным аллокатором. .NET выигрывает.


H>Ты так часто это повторяешь, что скоро и сам поверишь...


Зачем мне верить, у меня результаты тестов есть.

Это вот плюсистам надо верить что их код всегда быстрее.
Re[34]: Работа - с чего начать: С++ или С#?
От: samius Япония http://sams-tricks.blogspot.com
Дата: 19.05.09 09:34
Оценка:
Здравствуйте, samius, Вы писали:

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


S>На днях выложу картинку в блоге.


А чего томить, примерно так это выглядит:


Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.