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

A>boost::function отлично выполняет эту функцию.

1. boost::function не является примитивом языка.
2. Он не компилируется на некоторых компиляторах, а значит доступен не везде.
3. Он имеет ряд проблем в применении.
4. Примеры с тем что ты называшь лямбдами вообще никуда не годятся.
5. Реализация этого дела ужасна. Она значительно увеличиывает время компиляции и ухудшает понятность сообщений об ошибках.

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

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

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

C>Есть свойства языка, которые можно выразить через другие свойства — это
C>сахар. Операции циклов — сахар над if/goto, а вот switch — уже нет, так
C>как это абстракция таблицы переходов.

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

C>Точно так же — в C++ не являются сахаром шаблоны, исключения,
C>автоматические классы, и т.п.

C>Сахар — это перегрузка операторов, implicit-преобразования и т.п.

А while и for тоже сахаром значит не являются?

C>В связи с (повторным) увлечением Emacs'ом, мне стало интересно как же
C>используются макросы в Emacs'е. Оказалось, что почти никак.

И? Я еще проще могу пример привести. У меня в телевизоре тоже скорее всего ни одого макроса.

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

Это проблемы твоей фантации. У нас на сабмит через раз приходят статьи "вроде сериализация на С++ — вариант 325" или "конечные автоматы на шаблонном метапрограммировании через зад автогеном". Потом вот тут рядом про буст говорили. В нем почти все резальтат метапрограммирования. Только сделанного через зад автогеном.

>> C>Понимаешь, свойство выглядит и ведет себя как член класса. На член
>> C>класса я могу взять ссылку (в С++).
>> Понимшь, С++ с его догами идет в лес.
C>Изначально IT привел отсутствие свойств как пример отстоев С++.

Если из С++ выбросить догмы и добавить нужный фанкционал, то олучился бы современный язык. Вот ИТ и говорил об этом.

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

FR>Не помню, помню только прагму: #pragma inline_recursion(on)

Это значит ключик? Не, так дело не пойдет. Давай я тоже такой же ключик задейстую? У меня он называется Memoize macro. И по соревнуемся.

При каком-то значении рекурсии ты получашь просто константу. Ясно, что предрассчитанный результат будет быстрее.

VD>>Того что GCC по полной обосрался — это как бы ничего не говорит? Тут ведь много трепачей ходит рассказывающих о мифической медленности дотнета. Может им на основании этого С++ хот разок по критиковать?

FR>Ну у gcc тоже много ключиков, надо поискать которые за инлайнинг отвечают.

Ну, так кайди. Или это неподемная задача?

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

Ну, что же даже если VC с разворотом рекурсии оказывается на высоте, то все равно четко видно, что никакого приемущества у С++ здесь нет, а дело в качестве оптимизации.

На маем ноуте Nemerle показывает 3.25 сек, а твой тест на VC 2.86. Другие компиляторы вообще сливают. Так о какой медленности менеджед-кода тут идет речь?

Твой же любимый Питон вообще лег на данной операции.

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

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

E>Это похоже на сравнение выпуска легковых автомобилей и аэробусов.

Не. Не похоже. Вы выпускаете не аэробусы, а программки ни чем не выдающиеся по сравнению с другими. Твой сервер приложений ни чем не лучше MSMQ или IBM-оского.

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

E>Да и ради бога. Лично мне нафиг Linux или FreeBSD на десктопе не нужен без того количества драйверов, которые есть под Windows. Зато мне нафиг не нужны форточки на сервере, для которого вполне достаточно bash, screen и ssh.

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

E>Есть такой класс систем -- банковский процессинг. Их продажи не могут исчисляться тысячами в принципе. Но не смотря на то, что у производителей процессинга клиентов едва переваливает за сотню, между самими производителями процессинга идет весьма серьезная конкуренция. И я очень сильно удивлюсь, если серьезные процессинговые системы для крупных банков (хотя бы уровня ведущих Московских банков, не говоря уже про европейские и американские), работающие под Windows.

У меня счета в двух банках. Везде Винда. Плюс еще в качестве банк-клиента ДОС.

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

Опять же. В офисе MTS на десктопе Винда.

E>Еще один пример. Есть такая платформа HP NonStop (бывший Tandem). Супер надежная, позиционируется как самая надежная платформа в мире и самая выгодная по соотношению цена/производительность для свого класса систем (хотя все это маркетинг и Sun, и Stratuss здесь приводят совершенно другие показатели). При этом машинка минимальной конфигурации стоит под $150K. И на этой платформе работают практически все крупнейшие банки США и Европы, все биржи в США, большинство европейских бирж, большинство сотовых операторов США. А крупнейший NonStop-ный кластер (вроде из 300 юнитов) работает в AOL.

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

E>И знаешь, что объединяет все приведенные примеры -- высокие требования к надежности и отказоустойчивости. Это какой-нибудь хостер может выпасть на пару часов в осадок. А вот банк не может остановить свой процессинг. Мобильный оператор не может перестать обслуживать своих абонентов.

Это решается другими средствами. Железо на сегодня не так трудно сделать надежным. А вот софт есть софт. И будучи написанным на С++ он скорее выпаст в осадок.

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

Их еденицы и они никого кроме себя не волнуют. Никакая вся индустрия тут не требуется. Это узкий сегмент рынка не видный в микроском. Прибыльный наверно, но очень узкий.

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

VD>Ну, что же даже если VC с разворотом рекурсии оказывается на высоте, то все равно четко видно, что никакого приемущества у С++ здесь нет, а дело в качестве оптимизации.
+1

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

А вот Memoize в Nemerle это пример умной и хорошо подходящей для данного случая оптимизации. И выигрыш по сравнению с разворотом рекурсии просто огромный — в десятки раз. И естественно не зависит от особенностей конкретного железа и прогноза погоды.

На C++ без изменения кода самой функции такое просто не написать, если не использовать грязные и небезопасные методы вроде препроцессора.

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

VK>В Nemerle с этим кстати проблем нет. Только вместо out параметра нужно передавать функцию-setter.

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

Andrei N.Sobchuck,

ANS>"Ниччё не понимаю" (с) следствие ведут колобки. Я таки настаиваю на объяснении сути свойств. А то пока я только понял, что у них синтаксис удобный, а отчего, почему — не ясно.

Потому что синтаксический сахар does matter. Даже если убрать лишнюю пару скобок, то это уже существенно повлияет на нагруженность синтаксиса при систематическом применении.

Программы тэ пишутся людьми и для людей.

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

ANS>>"Ниччё не понимаю" (с) следствие ведут колобки. Я таки настаиваю на объяснении сути свойств. А то пока я только понял, что у них синтаксис удобный, а отчего, почему — не ясно.

LCR>Потому что синтаксический сахар does matter.

В данном случае мы столкнулись с феноменом непонимания этого простого факта. Видимо этот феномен витает и в комитете стандартизации C++

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

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

A>>boost::function отлично выполняет эту функцию.

VD>1. boost::function не является примитивом языка.
VD>2. Он не компилируется на некоторых компиляторах, а значит доступен не везде.
VD>3. Он имеет ряд проблем в применении.
VD>4. Примеры с тем что ты называшь лямбдами вообще никуда не годятся.
VD>5. Реализация этого дела ужасна. Она значительно увеличиывает время компиляции и ухудшает понятность сообщений об ошибках.

Мне всегда хотелось узнать, какие претензии программисты на C# имеют к boost::function. Спасибо за исчерпывающий список.

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

VD>У меня счета в двух банках. Везде Винда. Плюс еще в качестве банк-клиента ДОС.

Ты бывал в серверных этих банков? Или только видел терминалы в банковских РКЦ?

Если эти сообщения читают мужики из Питерского OpenWay или Магнитогорского КомпасПлюс, то они сейчас, наверное, широко улыбаются.

VD>Опять же. В офисе MTS на десктопе Винда.

Ага, и девочка из офиса МТС со своего десктопа непосредственно софтом SMS-центра управляет.

VD>Да, да. Вот например НАСДАК видимо именно на этом сервере Винду ганяет. А главное, что все его брокеры конечно из под нее пашут. Короче качай выдумывать. Банки работают на разном софте. И у нас, и у них.

А я и не утверждал, что используется только одна платформа и только одна ОС. Однако, для критически важной функциональности (а не для клиентских мест) используются дорогие серверные платформы. На которых пока Windows не видно.

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

На счет громче всех, то ты с рекламой Windows и пропагандой Nemerle здесь вообще вне конкуренции. Так что не обвиняй других участников форума в собственных грехах.

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

VD>А вот софт есть софт. И будучи написанным на С++ он скорее выпаст в осадок.

На этом месте я всегда плачу...

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

VD>Их еденицы и они никого кроме себя не волнуют. Никакая вся индустрия тут не требуется. Это узкий сегмент рынка не видный в микроском. Прибыльный наверно, но очень узкий.

Так я не понял, в темах с твоим участием про этот сегмент рынка вообще заикаться нельзя?

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

E>>Это похоже на сравнение выпуска легковых автомобилей и аэробусов.

VD>Не. Не похоже. Вы выпускаете не аэробусы, а программки ни чем не выдающиеся по сравнению с другими. Твой сервер приложений ни чем не лучше MSMQ или IBM-оского.

Какой изящный переход на личности

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

FR>>Не помню, помню только прагму: #pragma inline_recursion(on)

VD>Это значит ключик? Не, так дело не пойдет. Давай я тоже такой же ключик задейстую? У меня он называется Memoize macro. И по соревнуемся.

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

VD>При каком-то значении рекурсии ты получашь просто константу. Ясно, что предрассчитанный результат будет быстрее.

Нет, я проверял со вводом числа из командной строки и смотрел ассемблерный листинг.

VD>>>Того что GCC по полной обосрался — это как бы ничего не говорит? Тут ведь много трепачей ходит рассказывающих о мифической медленности дотнета. Может им на основании этого С++ хот разок по критиковать?

FR>>Ну у gcc тоже много ключиков, надо поискать которые за инлайнинг отвечают.

VD>Ну, так кайди. Или это неподемная задача?

Жарко, охота в тенечке лежать а не за компом сидеть

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

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

VD>Ну, что же даже если VC с разворотом рекурсии оказывается на высоте, то все равно четко видно, что никакого приемущества у С++ здесь нет, а дело в качестве оптимизации.

Ну конечно если что-то обошло мой любимый язык, это никакое ни преимущество а так случайное недоразумение

VD>На маем ноуте Nemerle показывает 3.25 сек, а твой тест на VC 2.86. Другие компиляторы вообще сливают. Так о какой медленности менеджед-кода тут идет речь?

VD>Твой же любимый Питон вообще лег на данной операции.

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

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

А почему бы и не сравнивать если я как раз и использую связку python + С++.

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

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

VD>>Ну, что же даже если VC с разворотом рекурсии оказывается на высоте, то все равно четко видно, что никакого приемущества у С++ здесь нет, а дело в качестве оптимизации.
VK>+1

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

Что-то не верится я асм. листинг смотрел.

VK>А вот Memoize в Nemerle это пример умной и хорошо подходящей для данного случая оптимизации. И выигрыш по сравнению с разворотом рекурсии просто огромный — в десятки раз. И естественно не зависит от особенностей конкретного железа и прогноза погоды.

В питоне та же оптимизация тоже очень легко делается.

VK>На C++ без изменения кода самой функции такое просто не написать, если не использовать грязные и небезопасные методы вроде препроцессора.

Еще можно на ассемблерных вставках сделать

Дьяченко Александр wrote:
> C>К полю. А вообще, для defval придуманы были конструкторы (в том числе и
> C>анонимные).
> Ну к полю это еще туда сюда (Дизайнер должен сам догадываться к которому
> полю, или опять соглашение?).
Зачем дизайнеру о чем-то догадываться? Он или ищет поле по какому-то
атрибуту, или ему его указывает пользователь.

> А с конструктором это вобще не катит — например класc Color у каждого
> Control-а несколько разных Color-ов и че в конструкторе?

public class Blah
{
    public int someInt=123;
    public double someDbl;
    {
        someDbl=Math.sin(Something);
    }
    
    Blah()
    {
        //Тут someDbl уже будет иметь нужное значение
    }
};

> C>В этом примере все просто — а в более сложных случаях получается
> C>сложнее. Особенно когда нельзя (или трудоемко) четко разделять на
> C>вычислямые данные и исходные.
> Пример нарисуешь? А то у меня че-то не приходит в голову ничего.
Система рассчета налогов, например, (привет kan_izh!). Связи между
полями могут быть весьма сложными.

>> > 3. Осуществлять присвоение только в случае другого значения (обычно
>> > так и делается). Т.е.:
> C>Ага, только тогда теряем гарантию семантической целостности графа. Тоже
> C>неприятно.
> В смысле? Нафига че-то делать если там и так тоже самое значение?
Теряем автоматическое обнаружение ошибок. Кроме того, здесь это не
поможет — ошибка происходит из-за того, что нужное для вычислений поле
еще не загружено.

> C>В Java есть простое соглашение — для доступа к данным используются
> C>методы без параметра с префиксом "get" (или "is" для булевских типов),
> C>для присвоения — методы с префиксом "set" и одним параметром.
> Я же говорил что как концепция свойство все равно есть.
Так все get/set-методы можно "свойствами" обозвать.

> Плюс такое раздвоение усложняет рефакторинг.
Де-факто, не усложняет.

> Или ты против отображения этой концепции в синтаксисе языка?
Да. Так как отображение противоречиво и концептуально неправильно.

>> > Ну использовать через задницу можно почти все .
> C>А если это "что-то" специально предназначалось для такого использования?
> В смысле?
Свойства и задумывались ради side-эффектов.

> C>Концепетуальную сложность мы, наоборот, увеличиваем. Так как появляются
> C>два типа синтаксически одинаковых, но семантически неэквивалентных
> C>конструкций.
> В смысле? В C# напрямую нельзя вызвать get/set. Или ты про что?
Я про то, что обращение к полю выглядит точно так же, как и обращение к
свойству. Но свойство нельзя передать как out-параметр и операция
присвоения свойству имеет непредсказуемые характеристики.

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

>> Ну к полю это еще туда сюда (Дизайнер должен сам догадываться к которому
>> полю, или опять соглашение?).
C>Зачем дизайнеру о чем-то догадываться? Он или ищет поле по какому-то
C>атрибуту, или ему его указывает пользователь.

В случае просто публичного поля все и так ясно. А в случае свойства как просто набора get/set к чему?

>> А с конструктором это вобще не катит — например класc Color у каждого
>> Control-а несколько разных Color-ов и че в конструкторе?
C>

Код вырезан
C>

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

>> Пример нарисуешь? А то у меня че-то не приходит в голову ничего.
C>Система рассчета налогов, например, (привет kan_izh!). Связи между
C>полями могут быть весьма сложными.

C финансами не общался, поэтому все может быть. Хотя мне казалось что входные данные там выделяются очень прозрачно, там вобще почти все вычисляемое (Входными данными я думаю там будут доход + некоторый набор признаков). Ну да ладно зная наше правительсво, там может и есть где репу почесать.

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

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

>> C>В Java есть простое соглашение — для доступа к данным используются
>> C>методы без параметра с префиксом "get" (или "is" для булевских типов),
>> C>для присвоения — методы с префиксом "set" и одним параметром.
>> Я же говорил что как концепция свойство все равно есть.
C>Так все get/set-методы можно "свойствами" обозвать.

И что? В Framework-е не такуж и много таких функций особенно с параметрами.

>> Плюс такое раздвоение усложняет рефакторинг.
C>Де-факто, не усложняет.

Ну ладно пусть не усложняет (что-то придумать ничего не могу спать охота).

>> Или ты против отображения этой концепции в синтаксисе языка?
C>Да. Так как отображение противоречиво и концептуально неправильно.

Можешь предложить лучше?

>> В смысле?
C>Свойства и задумывались ради side-эффектов.

Ну side-эфект понятие растяжимое. Плюс мне почему-то кажется что side-эффект это не основное ради чеего они задумывались.

>> В смысле? В C# напрямую нельзя вызвать get/set. Или ты про что?
C>Я про то, что обращение к полю выглядит точно так же, как и обращение к
C>свойству. Но свойство нельзя передать как out-параметр и операция
C>присвоения свойству имеет непредсказуемые характеристики.

Ну так и метод тоже имеет те же самые характеристики. И что? Не делай из этого трагедии и страшного секрета и все будет нормально.

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

A>Мне всегда хотелось узнать, какие претензии программисты на C# имеют к boost::function. Спасибо за исчерпывающий список.

На С++ я программировал 13 лет. На C# 4 года. Так что это еще большой вопрос кто из нас на чем программист. И кстати, boost::function появился уже тогда когда С++ стал становиться мне менее и менее интересен.

Список, кстати, не исчерпывающий. Одну из важнеших проблем я упустил. boost::function не компонентая вещ. Ее нельзя передать между двумя ДЛЛ-ями. В прочем, то уже проблемы всего С++ в целом. Ну, да и boost::function это чисто его порождение. Такого извращения нет ни в одном языке.

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

VD>>Ну, что же даже если VC с разворотом рекурсии оказывается на высоте, то все равно четко видно, что никакого приемущества у С++ здесь нет, а дело в качестве оптимизации.

FR>Ну конечно если что-то обошло мой любимый язык, это никакое ни преимущество а так случайное недоразумение

А что и кого обошло? GCC слил? VC6 тоже сольет. У Vermicious Knid вот и VC на машине сливает. Твоеи любимые языки сольют так что мама не горюй. Так чем ты тут пыташся подколоть?

Вопрос повышения качества оптимизации управляемых сред — это вопрос времени.

FR>Ну и что, я его для такой дурости не использую

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

FR>Да и не так и лег если на нем оказалось несложно повторить без всяких макросов легендарный и всемогущий Memoize

Да, лег, лег. (3, 12) не выполнится вообще.

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

FR>А почему бы и не сравнивать если я как раз и использую связку python + С++.

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