Здравствуйте Геннадий Васильев, Вы писали:
AVK>>В джаве есть аналоги примитивных типов но классы, и вот преобразования туда и оттуда это просто так. В С++ тоже самое. А вот дотнет в этом отношении намного лучше — любой тип может быть приведен к object.
ГВ>Софистика и демагогия чистой воды. Например, в C++ преобразования "туда и оттуда" совсем не аналогичны Javа, сам это прекрасно знаешь. И чем в данном случае .NET намного лучше? Вообще — как это всё логически связано?
Ну, ты бы хоть показал в чем тут демогоия/софистика? А то внешне выглядит как раз что это от тебя исходят рассуждения основанные на неверных предпосылках.
Вот тебе код на Шарпе:
int i = 123;
object o = i;
double d = (double)o; // Здесь в рантайме будет исключение
Write(d);
А вот аналог на С++:
int i = 123;
void * o = &i;
double & d = *((double*)o);
Write(d); // Здесь в рантайме будет проход по памяти :)
Теперь о том о чем говорил AVK...
Если приметивный тип является объектом, то можно писать код проверяющий тип объекта и делающий те или иные действия в зависимости от результаотв проверки. Код приведенный мною выше как раз демонстрирует такую возможность в C# и отстуствие такой возможности в С++. Идем дальше...
C++:
void Write(...) { }
С#
void Write(ParamArray object[] pa) { } // Точно синтаксиса не помню, но что-то в этом духе
В С++ такая функция невозможно так как нет информации ни о количестве параметров, ни их типах. Отсюда и раждается уродливый printf и его ошибки типа printf("%d", DoubleVar). И что характерно никакие шаблоны не спасут. Хваленая типобезапастность првращается на поверку в полную опастность.
В C# каждый парамет ссылка на базовый класс обжект которая имеет полное самоописание в рантайме. Это позволяет реализовать printf так printf("{0}", DoubleVar). Внутри метода мы будем иметь массив (тоже самоописываемый) с известным количеством элементов содержащий нужные парамтры. Так как параметры типизированы (хотя и в рантайме) отподает нужда указывать тпм черз %х, а параметр можно использовать внутри описания несколько раз printf("{0} ... {0}", DoubleVar) (ноль в данном случае номер параметра).
Теперь о боксинге. Если параметр не является экземпляром класса, то в языках типа С++ и Явы его нужно запоковать в класс-обертку которая будет предоставлять описание вложенного типа. Вот такая запаковка и распаковка называется боксингом и анбоксингом. Она есть и в Яве и в С++ (просто потому, что это делается вручную). Шарп же делает такую запаковку автоматически и программист может рассуждать в терминах чистой абстракции не задумываяс является ли переменная ссылкой на класс, примитивом или структурой.
Так что это твои предпосылки неверны, а стало быть именно ты занимаешся софистикой.
ГВ>С твоей точки зрения — "больше решает", с моей — "больше создаёт". Частичное подтверждение моей точки зрения я нашёл в твоих словах ниже о непредсказуемости задержек.
Вот это уже форменная демогогия. Какое поддтверждение? Вырвал из контекста... и сделал подтверждением.
AVK>>Естественно, у них же vtbl нету. Структура она и есть структура. Кусок памяти просто.
ГВ>Обрати внимание не терминологию — она сугубо "сишная". Это просто наблюдение...
А ты хотел чтобы она была какая? Оба языка произошли от С и структуры взяли от туда же. Причем я бы даже сказал, что С# их взял намного ближе к оригиналу.
ГВ>Про realtime-системы совершенно согласен. (Стакан в студию!) Я именно непрогнозируемость задержек и имел ввиду. Кстати, я не думаю, что это критично в любом приложении, но нервов может попортить много. Кстати, управление технологическим процессом я бы такой системе не доверил.
А ты не задумывался, что в ОС типа NT или Линукса вообще нельзя писать реалтаймные задачи? Ведь они в любой момент могут отнять управления. Да и хипы их написаны так что не могут обеспечить гарантированного времени доступа. Так что луче не рассуждать о том что не трогает. Иначе договоримся что ДОС лучшая ОС, так как в ней можно делать риалтайм-задачи.
AVK>>Подумай хотя бы о том что произойдет если базовый класс в одной dll а потомок в другой.
ГВ>Здесь ограничения в самом деле получаются подобными COM-овским. Однако, я не утверждаю (и не буду утверждать), что каждый класс обязан быть подгружаемым компонентом.
Вот она демогогия в чистом виде. Я бы на твоем месте все же почитал Бокса. Он очень популярно изложил почему нльзя использовть длл + классы С++ для организации компонентов. Там все просто как неучить уроков... просто нет бинарного стандарта на описание, бинарную форму и экспорт класса. Другими словами это решение будет несовместимо не только с другими языками (что важно для компонентных технологий не завязанных на один язык), но и между компиляторами разных производителей.
ГВ>Компоненты — это deployment.
Ага. Т.е. строительство дома — это deployment. Они ведь там тоже из компонентов все лабают... Это даже не демогогия, это откровенное незнание предмета обсуждения. Ты уж извени.
AVK>>>>Сервисы ты эти как реализовывать будешь? ГВ>>>Как часть App-сервера и комплект драйверов. Под "сервисами" я имею ввиду сугубо системные аспекты — коммуникации, систему безопасности и т.п.
Вот и подумай, как ты будешь выкручиваться когда сервис должен подключаться к уже имеющейся системе. И о том как потребитель сервиса должен получать информацию о сервисе и взаимодействовать с сервисом? Вот тут-то компонентные технологии и тот самый COM просто незаменимы. Вот тут-то они и дают огромное упрощение реализации (не смотря на свою сложность). А так как используются сервисы куда чаще чем создатся, то время портаченное на их компонентизацию окупается с лихвой. Ну, а .NET это просто следующий шаг, позволяющий понизить сложность реализации этих компонентных архитектур. Несомненно компоненты нужны не везде, но что плохого если без какого то нибыло оверхэда ты получаешь возможность работать с любым экземпляром объекта как с компонентом?
ГВ>То, о чём ты сказал — не самое интересное. Самое интересное, ИМХО, — сохранение состояний интерфейса пользователя между вызовами.
Да... вот это проблема. Глянь на ASP.NET. Там это все не просто решено... там это еще и визуально решено. Ты, кстати, сейчас сидишь на форуме который это дело пользует постоянно. Вот только не ясно как это к разговору отностися.
ГВ>ИМХО, очень хреново, если на верхнем уровне проектирования присутствует разделение понятий Web-интерфейс и Windows-интерфейс. Краткое обоснование я уже приводил.
А ты сам пробывал делать нечто обеспечивающее и то и другое и еще чтобы без уродства и прочих безобразий? Уверен что нет. Так вот логика делится на логику приложения, логику обработки данных и презентационную логику. Последняя в виду сильно разнящихся подходов получатся совершенно разной для Web- и GUI-интерфейса. По-этому, обычно выделяют слой логики, а интерфейсы делают разные.
AVK>>ВОт ты попробуй воплотить свои красивые и правильные идеи в жизнь, а потом и будешь всем тут рассказывать как что и почему. До сих пор все попытки привести веб-интерфейсы к GUI оканчивались печально. Что то получилось у MS с вебформсами, но это еще далековато до реального написания приложения которое будет переключаться прозрачно с веб-интерфейса на GUI. Пока что все ограничивается общим ядром, а интерфейс пишется под гуй отдельно, под веб отдельно.
ГВ>Это можно считать аргументом? Если да, то он неправомерен, поскольку сие — аргумент к коллективу.
А что ты хоть один (по этому поводу) привел? Ну смотри мои аргументы (выше).
ГВ>Предлагаю постановить, что доводы типа: "а ты попробуй, знаешь как это трудно!" — не котируются
А я тебе предложил бы пропробывать. Тогда охота спорить с совершенно очевидными вещами у тебя отпадет сама собой.
ГВ>..., если не снабжены дополнительными разъяснениями о том, что именно считается трудным. Я во всяком случае на подобные выпады больше отвечать не буду. Понимаешь ли, для меня выражение "трудно, но можно" означает, что я так и сделаю, потому что "можно".
А что для тебя будет аргументом? Он тебе привел доводы, что как минимум скорости работы разные. Уж можно было домыслить, что в условиях низкой скорости и высокой латентности соеденения нужно делать интерфейсы отличные от применяемых в случаях когда нет задержек.
К тому же при создании Web-варианта ты можешь пользоваться мошными функциями реализованными Web-сервером. А в локальном режиме тебе придется все далать вручную или другими методами. Или ты хочешь делать как в анкдоте про кипячение чайника программистом?
ГВ>В корень зришь! ASP — это не "полная фигня" ни в коем случае, но уже тепло.
Полностью поддержива все сказанные слова...
SS>Я тоже с ностальгией вспоминаю времена, когда сидя в DOC на Borland C++ 2.0, поковыряв программу в TurboProfiler, можно было сделать умное выражение лица, написать asm{..}, поднапрячь интелект, решив сложную комбинаторную задачу, по хитрому соптимизировать какую нибудь сортировку,распихать по регистрам, ... и с чувством глубокого удовлетворения наблюдать как прога стала "летать". Теперь такой уровень ни кому не нужен.
А вот сдесь хочу поспорить. Задачи оптимизации и сейчас временами выжны. Особенно когда делаешь компоненты которые могут использоватся в суровых условиях. Но как раз .NET и даем пеханизм решения таких проблем. Правда не встроенный asm-блок, но можно написать кусок кода на том самом С++ причем там додут и по памяти пройтись и по химичить в доволь. Ну и в крайнем случае есть MSIL. На нем можно все до байта вылезать. Ну, а Jit даст оптимальный код на платформе конечного потребителя.
Я думаю, что пока что приимущество Джита еще не так видно. Все же и времени на оптимизацию этого самого джито моло было и проблем с переносимостью хватает. Но в будующем мы еще услышим как управляемый код обгоняет неуправляемый. Вот только пусть шаблоны введут.
SS>А для более высокого уровня C++ не приспособлен.
Это точно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Геннадий Васильев, Вы писали:
ГВ>В прикладную логику с подключённой "толстой" интерфейсной прослойкой. То есть, в то, во что она и должна превратиться в этом случае.
Что ты понимаешь под словом "толстой"?
SS>>Вот мне бы это и хотелось услышать от противников .NET,С#,Java примерно такую фразу: SS>>"реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET"
ГВ>Это от объёма задачи зависит. Чем она больше — тем важнее унификация внутренней структуры и глубина проработки абстракций. Тем адекватнее там C++.
Софистика чистой воды.
И вообще ты все время здесь всех лечишь правильной организацией больших програм и что для этого компоненты не нужны, а сам с тудом можешь объяснить что такое. Сдесь все с тобой не спорют, что грамотное проектирование и декомпозиции важная составляющая успеха. Вот только речь то не о том.
ГВ>Концептуально — частный случай, фактически — COM и ORB распространены очень широко. Теперь к ним добавляется .NET. Но это ничего не меняет.
Чего? Твоего отношения сложившегося из-за нежелания разобраться в критикуемых тобой технологиях?
ГВ>Да C++-то доживёт. А вот доживёт ли .NET не мутировав во что-то ещё "очень новое" — абсолютно не уверен.
Доживет. Как C и asm. А .NET конечно мутирует. Или сдохнет. Например, ему точно нужна мутация в области дженерик-программирования.
SS>>Тут спор не в синтаксисе языков а в уровне абстракции.
ГВ>Да, только уровень абстракции — человеческая прерогатива. Язык — это просто инструмент. Более или менее удобный. Который тем или иным образом влияет на пользователя. Об том и все эти споры.
Вот ты и даказал своей реализацией делегатов, что С++ хреновый инструмент для реализации абстракций. Помнишь свое описание метода? Да и переносимость кода доказал замечательно. Иди скомпилируй свой код где-нибудь под Sun-ом.
Тебе не кажется, что твоя реализация просто монстроидальна и что она явно проигрывает тому что было на дремучем С (как по краткости и элегантности, так и по эффективности)?
ГВ>По аналогии с филологической лингвистикой (извини за тавтологию), по отношению к программистской лингвистике можно, ИМХО, постулировать, что язык определяет набор абстракций, которыми человек оперирует при удовлетворении своих интеллектуальных потребностей. Есть только одна закавыка — набор абстракций должен быть инструментом попрождения работающей системы. Вот тебе и связка и переход между "уровнем абстракции человека" и "уровнем абстракции от аппаратуры".
И вот же умеют люди сказать простую фразу, так что ничерта не понятно.
ГВ>Интересно, рефлексия в форумах наверное никогда не прекратится. Не, ребята, я больше в мыльных операх не участвую.
Гы-гы.
SS>>А для более высокого уровня C++ не приспособлен.
ГВ>А это очень похоже на формулу аутотренинга. Повторять утром и вечером! Чтобы не подумалось иначе.
Не... это ты себе повтояешь. И не хочишь открыть глаза и увидить, что все не так как на самом деле.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Sergey, Вы писали:
S>Дак и у С++ нет тех недостатков, о которых вы говорите. О тех, которые у него на самом деле есть и жить мешают, все почему-то молчат. S>Да и говорил я вовсе не о недостатках нета, а о том, что быстродействие много где требуется.
Ты прикидываешься или действительно не понял, что IT тебе говорил о том, что Шарп не медленнее чем С++?
S>Дык это смотря как тестировать. Я надеюсь, ты не станешь утверждать, что виртуальные функции вызываются быстрее обычных? Аналогия понятна? Блин, "антишустрика" написать, что ли...
Давай. Только не прибегай к тестированию интеропа. Ты давй на вычислительных задачах... Очем и говорил. А тестировть будем С# супротив VC6 (все же самы распространненный на сегодня... ведь устраивает же его скорость большиство народу).
S>Если серьезной игрушкой считать Quake II, так там даже и плюсами не пахнет. Голимый "пуре Це"
Ну, а Анрыл на С++ написан. Да он вообще на половину на своем встроеном интерпретаторе написан. И почему там вместо него Шарп нельзя использовать?
S>...C++ кардинально отличается от нетовских языков тем, что в C++ GC или иной способ управления памятью можно реализовать с куда меньшим геморроем, чем в нетовских языках организовать собственное управление памятью.
Вот Мишка.Нэт уже пытался это сделать. Может и ты попробуешь? Если удастся без гемороя я тебе $300 подарю.
S>Причем, что характерно, если мне этот код портировать вдруг понадобится, я просто поменяю пару дефайнов и на отличных от винды платформах будет работать все тот же std::stringstream — медленно, но будет. Пока нативный аллокатор не напишу S>В нете такое практически нереализуемо.
Т.е. в нете условной компиляции нет? Или там нельзя свои классы писать (или от имеющихся наследоваться)?
S>Дело тут может быть только в том, что программист(ы), писавшие эту С++ программу, плохо владели инструментом. Им и правда надо на .Net сваливать.
А мы в отличии от них круты как вареные яйца и неправильных решений не принимаем !
IT>>Правильно, в правильном дизайне и применении вспомогательных технологий, никак не связанных с самим языком.
S>Во-во, сравнивают плохой сишный код с хорошим нетовским и говорят, что второе — быстрее. Так кто ж спорит, я вполне могу написать программу на С++, которая будет работать медленне бэйсиковского аналога, мною же написанного.
В Шустриках сравнен одинаковый код, но он тебе не нарвится потому что не дает С++ глобального превосходства.
Ну, тогда задумайся хоть над тем, что на Шарпе просто проще писать "хороший" код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте IT, Вы писали:
IT>И вся графика ручками написана без всяких DirectX. Или я не прав? Может и не прав, но вот в Doom точно без DirectX обошлись. И что, ты станешь сейчас в неё играть когда уже есть Tournament?
Уже есть Анрыл 2.
IT>Ну вот опять Я надеюсь ты знаешь кое что об интерфейсах. В дотнете я могу написать свой форматер и передавать данные между стандартными объектами по своему доморощенносму протоколу и всё будет летать. А вот на C++ вместе с COM'ом такого не сделаешь.
Сделаешь. Но пока будешь делать летать это будет.
IT>Да ладно Всё это мы уже слышали про крутых C++ программеров и даже сами так кричали по всем фидошным эхам в своё время. Но я надеюсь ты не думаешь, что если кто-то был хорошим программером только потому что он писал на C++, и вдруг сразу стал плохим так как начал писать на C#
К разговору на таком уровне Петька был не готов (с)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Sergey, Вы писали:
S>>Дак и у С++ нет тех недостатков, о которых вы говорите. О тех, которые у него на самом деле есть и жить мешают, все почему-то молчат. S>>Да и говорил я вовсе не о недостатках нета, а о том, что быстродействие много где требуется.
VD>Ты прикидываешься или действительно не понял, что IT тебе говорил о том, что Шарп не медленнее чем С++?
Это IT и ты не поняли, что я говорил не про C#, а отвечал вот на это:
"Я тоже с ностальгией вспоминаю времена, когда сидя в DOC на Borland C++ 2.0, поковыряв программу в TurboProfiler, можно было сделать умное выражение лица, написать asm{..}, поднапрячь интелект, решив сложную комбинаторную задачу, по хитрому соптимизировать какую нибудь сортировку,распихать по регистрам, ... и с чувством глубокого удовлетворения наблюдать как прога стала "летать". Теперь такой уровень ни кому не нужен."
Да знаю я, где твои шустрики лежат.
S>>Дык это смотря как тестировать. Я надеюсь, ты не станешь утверждать, что виртуальные функции вызываются быстрее обычных? Аналогия понятна? Блин, "антишустрика" написать, что ли...
VD>Давай. Только не прибегай к тестированию интеропа. Ты давй на вычислительных задачах... Очем и говорил. А тестировть будем С# супротив VC6 (все же самы распространненный на сегодня... ведь устраивает же его скорость большиство народу).
Угу, только на С++ я кой-чего сделаю с шаблонами, а на шарпе придется выкручиваться без них.
S>>Если серьезной игрушкой считать Quake II, так там даже и плюсами не пахнет. Голимый "пуре Це"
VD>Ну, а Анрыл на С++ написан. Да он вообще на половину на своем встроеном интерпретаторе написан. И почему там вместо него Шарп нельзя использовать?
Я анриловских исходников не видел и про него ничего сказать не могу.
S>>...C++ кардинально отличается от нетовских языков тем, что в C++ GC или иной способ управления памятью можно реализовать с куда меньшим геморроем, чем в нетовских языках организовать собственное управление памятью.
VD>
VD>Вот Мишка.Нэт уже пытался это сделать. Может и ты попробуешь? Если удастся без гемороя я тебе $300 подарю.
Маловато будет Mishka<T> изначально поставил неправильную цель — обеспечить запрет создания некоторых классов не GC-методами. Вот оттуда и геморрой.
S>>Причем, что характерно, если мне этот код портировать вдруг понадобится, я просто поменяю пару дефайнов и на отличных от винды платформах будет работать все тот же std::stringstream — медленно, но будет. Пока нативный аллокатор не напишу S>>В нете такое практически нереализуемо.
VD>Т.е. в нете условной компиляции нет? Или там нельзя свои классы писать (или от имеющихся наследоваться)?
Аллокатор быстрый, не гарбадж-коллекнутый там не слишком легко сделать
VD>В Шустриках сравнен одинаковый код, но он тебе не нарвится потому что не дает С++ глобального превосходства.
Там примитивный код, в жизни такой редко нужен.
VD>Ну, тогда задумайся хоть над тем, что на Шарпе просто проще писать "хороший" код.
Без шаблонов неизбежны либо повторы кода, либо падение быстродействия (если избегать повторов через делегаты).
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте IT, Вы писали:
IT>>>А разве в серьёзных игрушках используется стандартный C++ хип?
S>>Если серьезной игрушкой считать Quake II, так там даже и плюсами не пахнет. Голимый "пуре Це"
IT>И вся графика ручками написана без всяких DirectX. Или я не прав? Может и не прав, но вот в Doom точно без DirectX обошлись. И что, ты станешь сейчас в неё играть когда уже есть Tournament?
Там по выбору или OpenGL юзается, или "ручками написанная" графика. Не знаю, на чем написана третья квака, но думаю не сильно внутри от второй отличается — так ее движек сейчас в половине игр используется.
S>>И при чем тут, собственно, хип? Быстродействие не только от него зависит. C++ кардинально отличается от нетовских языков тем, что в C++ GC или иной способ управления памятью можно реализовать с куда меньшим геморроем, чем в нетовских языках организовать собственное управление памятью. Да и никто не заставляет в C++ всегда пользоваться евойным хипом, при необходимости можно и системные функции подергать. Тормозил у меня, например, std::stringstream — так я написал свой стримбуфер со своим аллокатором, стало просто летать. Причем, что характерно, если мне этот код портировать вдруг понадобится, я просто поменяю пару дефайнов и на отличных от винды платформах будет работать все тот же std::stringstream — медленно, но будет. Пока нативный аллокатор не напишу S>>В нете такое практически нереализуемо.
IT>Ну вот опять Я надеюсь ты знаешь кое что об интерфейсах. В дотнете я могу написать свой форматер и передавать данные между стандартными объектами по своему доморощенносму протоколу и всё будет летать. А вот на C++ вместе с COM'ом такого не сделаешь.
Я не совсем понял, о чем ты. Какой форматтер, зачем? Я вообще про выделение памяти и гибкость шаблонов в С++ говорил.
IT>Давай не будем приводить в качестве аргумента частные решения.
А без них одно пустозвонство получается. Про молоко и воду, недетерминированные компьютеры и т.д.
IT>Как я уже говорил всё зависит от дизайна и прямости рук. У меня вообще может возникнуть вполне законный вопрос — а нафига тебе понадобился стримбуфер, неужели нельзя было обойтись без него
А удобно. Объект сериализуется в стандартный стрим — хоть в файл пишется, хоть по сети передается, хоть через COM в виде BSTR, хоть через IStream — код один и тот же, только стримы разные. Или вообще в виде base64 в HTML страницу.
IT>>>Сомневаюсь, наверняка там своя подсистема управления памятью. Что-нибудь подобное придумают и для C#. Т.е всё это приходящее.
S>>Вот именно, приходящее и уходящее. Когда еще придумают то. А работать сейчас надо.
IT>Если ты занимаешься игрушками, то используй C++ и "голимый Це", никто тебя в .NET не тянет. Твоё время пока не пришло
Не, я датамайнингом занимаюсь. И вижу — таки не пришло еще время на шарп пересаживаться.
IT>>>Что же касается полей в базе данных... Был проект написанный на C++ и занимающийся обработкой данных. На один двух-гигабайтный файл уходило до 57 часов. Всё это хозяйство было переписано на C#, время сократилось до 40 минут. В чём дело, спросите вы?
S>>Дело тут может быть только в том, что программист(ы), писавшие эту С++ программу, плохо владели инструментом. Им и правда надо на .Net сваливать.
IT>Опять ты не понял. Ни программисты, ни C++, ни C# тут ни при чём. Парсер был перенесён один в один из C++ в C#.
Ну вот — язык, оказывается, не причем. Тогда к чему было об этом говорить?
IT>Разница была лишь в методе вставки данных в базу данных. Во втором случае использовался BULK INSERT, который сам по себе работает в десятки раз быстрее.
А что мешало его использовать его в программе на С++?
IT>>>Правильно, в правильном дизайне и применении вспомогательных технологий, никак не связанных с самим языком.
S>>Во-во, сравнивают плохой сишный код с хорошим нетовским и говорят, что второе — быстрее. Так кто ж спорит, я вполне могу написать программу на С++, которая будет работать медленне бэйсиковского аналога, мною же написанного.
IT>Да ладно Всё это мы уже слышали про крутых C++ программеров и даже сами так кричали по всем фидошным эхам в своё время. Но я надеюсь ты не думаешь, что если кто-то был хорошим программером только потому что он писал на C++, и вдруг сразу стал плохим так как начал писать на C#
Нет, конечно.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте Sergey, Вы писали:
IT>>Ну вот опять Я надеюсь ты знаешь кое что об интерфейсах. В дотнете я могу написать свой форматер и передавать данные между стандартными объектами по своему доморощенносму протоколу и всё будет летать. А вот на C++ вместе с COM'ом такого не сделаешь.
S>Я не совсем понял, о чем ты. Какой форматтер, зачем? Я вообще про выделение памяти и гибкость шаблонов в С++ говорил.
А я не понял причём тут твой стримбуфер.
IT>>Давай не будем приводить в качестве аргумента частные решения.
S>А без них одно пустозвонство получается. Про молоко и воду, недетерминированные компьютеры и т.д.
А с ними только кульные частности, которые всё равно никто проверить не может.
S>Не, я датамайнингом занимаюсь. И вижу — таки не пришло еще время на шарп пересаживаться.
А что это такое, может там шарпу самое место?
IT>>Опять ты не понял. Ни программисты, ни C++, ни C# тут ни при чём. Парсер был перенесён один в один из C++ в C#.
S>Ну вот — язык, оказывается, не причем. Тогда к чему было об этом говорить?
Как раз потому что язык тут не при чём. Твои слова?:
S>Прикинь потребную вычислительную мощь. Жаба/нет тут не катят
Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, Вы писали:
IT>Здравствуйте Sergey, Вы писали:
IT>>>Ну вот опять Я надеюсь ты знаешь кое что об интерфейсах. В дотнете я могу написать свой форматер и передавать данные между стандартными объектами по своему доморощенносму протоколу и всё будет летать. А вот на C++ вместе с COM'ом такого не сделаешь.
S>>Я не совсем понял, о чем ты. Какой форматтер, зачем? Я вообще про выделение памяти и гибкость шаблонов в С++ говорил.
IT>А я не понял причём тут твой стримбуфер.
Еще раз повторяю — я не понял, о чем ты говоришь, а вовсе не спрашиваю, при чем тут форматтер.
IT>>>Давай не будем приводить в качестве аргумента частные решения.
S>>А без них одно пустозвонство получается. Про молоко и воду, недетерминированные компьютеры и т.д.
IT>А с ними только кульные частности, которые всё равно никто проверить не может.
Ну давай тогда опять про сферического коня в вакууме... Работа, она из частностей складывается. А насчет проверить — если что-то вызывает сомнения, готов выслать компилябельный кусочек кода. Другое дело — если никто не желает ни верить на слово, ни проверять
S>>Не, я датамайнингом занимаюсь. И вижу — таки не пришло еще время на шарп пересаживаться.
IT>А что это такое, может там шарпу самое место?
Ну, сходи на www.kdnuggets.com, посмотри, почитай.
IT>>>Опять ты не понял. Ни программисты, ни C++, ни C# тут ни при чём. Парсер был перенесён один в один из C++ в C#.
S>>Ну вот — язык, оказывается, не причем. Тогда к чему было об этом говорить?
IT>Как раз потому что язык тут не при чём. Твои слова?:
Ты вроде взялся языки сравнивать?
S>>Прикинь потребную вычислительную мощь. Жаба/нет тут не катят
IT>Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting.
Насчет того, что .NET ни чуть не медленнее чем C++ код — все зависит от задачи.
Например, есть примерно такой сишный код:
struct A
{
A(int a, int b) : _a(a), _b(b) {}
int _a;
int _b;
static bool less_by_a(const A &x, const A &y) const
{ return x._a < y._a; }
bool less_by_b(const A &x, const A &y) const
{ return x._b < y._b; }
....//Куча всяких полезностей, которые на сравнение не влияют
};
struct B : public A
{
B(int a, int b, int c, int d) : A(a, b), _c(c), _d(d) {}
int _c;
int _d;
bool less_by_d(const B &x, const B &y) const
{ return x._d < y._d; }
....//Куча других полезностей, которые на сравнение тоже не влияют
};
void foo()
{
std::vector<A> as;
size_t i;
const size_t vs = 100000;
as.reserve(vs);
for (i = 0; i < vs; ++i)
. as.push_back(A(rand(), rand()));
std::vector<B> bs;
bs.reserve(vs);
for (i = 0; i < vs; ++i)
. bs.push_back(B(rand(), rand(), rand(), rand()));
std::sort(as.begin(), as.end(), &A::less_by_a);
std::sort(as.begin(), as.end(), &A::less_by_b);
std::sort(bs.begin(), bs.end(), &B::less_by_d);
}
Вот мне почему то кажется, что на аналоги на нетовских языках будет выполнять foo гораздо медленней. Будет немного свободного времени, обязательно проверю
Насчет того, что GC работает быстрее чем сишный хип — ты уверен, что это справедливо для любого сишного рантайма и самописных хипов? На любых задачах? Речь вроде не шла о конкретном компиляторе.
И с каких это пор DCOM является единственным средством IPC/RPC/других коммуникаций?
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте IT, Вы писали:
IT>Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting.
Я думаю что если использовать TcpChannel и BinaryFormatter то сравнение будет не в пользу первого. Плюс у ремоутинга гибкость и удобство использования в разы больше.
Здравствуйте Sergey, Вы писали:
IT>>А с ними только кульные частности, которые всё равно никто проверить не может.
S>Ну давай тогда опять про сферического коня в вакууме... Работа, она из частностей складывается. А насчет проверить — если что-то вызывает сомнения, готов выслать компилябельный кусочек кода. Другое дело — если никто не желает ни верить на слово, ни проверять
Ладно, завязываем с этим, всё равно кроме пререканий ничего не будет.
S>>>Не, я датамайнингом занимаюсь. И вижу — таки не пришло еще время на шарп пересаживаться.
IT>>А что это такое, может там шарпу самое место?
S>Ну, сходи на www.kdnuggets.com, посмотри, почитай.
Что-то я там не нашёл внятного определения
IT>>Как раз потому что язык тут не при чём. Твои слова?:
S>Ты вроде взялся языки сравнивать?
Ты меня путаешь с кем-то другим. Я языки не сравнивал и не собираюсь, я наоборот утверждал что это бессмысленно, особенно в отрыве от окружения.
S>>>Прикинь потребную вычислительную мощь. Жаба/нет тут не катят
S>Насчет того, что .NET ни чуть не медленнее чем C++ код — все зависит от задачи. S>Например, есть примерно такой сишный код:
[skip]
S>Вот мне почему то кажется, что на аналоги на нетовских языках будет выполнять foo гораздо медленней. Будет немного свободного времени, обязательно проверю
Проверь. А я хочу проверить так же работу БД провайдеров из C# и C++. Тоже будет интересно. Ты кажется базами занимаешься. Вот и узнаем сколько ты выиграешь на сортировке (если выиграешь) и сколько проиграешь на доступе к базе.
S>Насчет того, что GC работает быстрее чем сишный хип — ты уверен, что это справедливо для любого сишного рантайма и самописных хипов? На любых задачах? Речь вроде не шла о конкретном компиляторе.
Я сравниваю с тем, чем я пользуюсь каждый день и сменить это на что-то другое мне никто не позволит. Виндовый хип, кстати, тоже медленнее работает. Насчёт самописных хипов я ничего не говорил, можно написать такой (и уже написаны), что ему будут никакие GC ни по чём. Только вопрос, чем ты за это платить будешь? Всей памятью твоей машины? А если это сервер и у меня на нём таких задач не одна крутится?
S>И с каких это пор DCOM является единственным средством IPC/RPC/других коммуникаций?
Я явой не пользуюсь, корба как-то тоже на винде не прижилась, а низкоуровневые вещи типа сокетов я не использую по причине — шоли мне больше нечем заняться. Остаётся DCOM, вполне нормальная штука, меня устраивала.
Если нам не помогут, то мы тоже никого не пощадим.
S>Это IT и ты не поняли, что я говорил не про C#, а отвечал вот на это: S>"Я тоже с ностальгией вспоминаю времена, когда сидя в DOC на Borland C++ 2.0, поковыряв программу в TurboProfiler, можно было сделать умное выражение лица, написать asm{..}, поднапрячь интелект, решив сложную комбинаторную задачу, по хитрому соптимизировать какую нибудь сортировку,распихать по регистрам, ... и с чувством глубокого удовлетворения наблюдать как прога стала "летать". Теперь такой уровень ни кому не нужен."
Вообще-то это был не вопрос, а ответ. Подколка, тык сызыть.
S>Угу, только на С++ я кой-чего сделаю с шаблонами, а на шарпе придется выкручиваться без них.
Ну, это ты зря. Шаблоны в шарпе все равно в ближайшее время появятся. Ты же про вычисления говоришь? Или я тебя не правильно понял?
S>Я анриловских исходников не видел и про него ничего сказать не могу.
Ну, я куски видел. А на интерперетаторе можешь и сам пописать. Открой их редактор, там он почти везде есть.
VD>>Вот Мишка.Нэт уже пытался это сделать. Может и ты попробуешь? Если удастся без гемороя я тебе $300 подарю.
S>Маловато будет
Ладно 350.99
S>Mishka<T> изначально поставил неправильную цель — обеспечить запрет создания некоторых классов не GC-методами. Вот оттуда и геморрой.
Он такой цели не ставил. Ты его статью читал? У него как раз попытка реализации GC средствами C++. Кстит, на VC6 он тоже забил (шаблон слабые...).
VD>>Т.е. в нете условной компиляции нет? Или там нельзя свои классы писать (или от имеющихся наследоваться)?
S>Аллокатор быстрый, не гарбадж-коллекнутый там не слишком легко сделать
Про value-типы слышал? Вот они как раз для оптимизации добавленны. К тому же ты не правильно себе понимаель .NET и возможности MSIL. На том же C# в ансэйф-режиме ты можешь занимать память где угодно и делать с ней что угодно. В том же шустрике есть пример быстрой сортировки на базе указателей.
VD>>В Шустриках сравнен одинаковый код, но он тебе не нарвится потому что не дает С++ глобального превосходства.
S>Там примитивный код, в жизни такой редко нужен.
В жизни код еще приметивней. Просто его много. Не думаю, что ты каждый день пишишь крутые алгоритмы. По крайней мнер 99 их процентов уже давно написаны.
VD>>Ну, тогда задумайся хоть над тем, что на Шарпе просто проще писать "хороший" код.
S>Без шаблонов неизбежны либо повторы кода, либо падение быстродействия (если избегать повторов через делегаты).
Тут ты прав. Но, во-первых, не настолько уж он замедляется, и, во-вторых, судя по всему такое положение вещей скоро изменится. Слышал, что для Ротора (CLI) шаблоны уже сделаны и доступны для скачивания?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Sergey, Вы писали:
IT>>Как я уже говорил всё зависит от дизайна и прямости рук. У меня вообще может возникнуть вполне законный вопрос — а нафига тебе понадобился стримбуфер, неужели нельзя было обойтись без него
S>А удобно. Объект сериализуется в стандартный стрим — хоть в файл пишется, хоть по сети передается, хоть через COM в виде BSTR, хоть через IStream — код один и тот же, только стримы разные. Или вообще в виде base64 в HTML страницу.
А ты думаешь в нете что-то по другому? Там все тоже самое, тольк проще на порядок возможностей больше (тот-же ремоутинг).
S>Не, я датамайнингом занимаюсь. И вижу — таки не пришло еще время на шарп пересаживаться.
И в чем рельная загвоздка? А с временем оно так... не время... не времяя.. рано еще... ра. Ой поздно!
S>Ну вот — язык, оказывается, не причем. Тогда к чему было об этом говорить?
В том, что при стольк малой разнице в производительности нет смысла говорить о том, что .NET небя сдерживает в этом аспекте. Все равно скорость определит качество твоего кода. А на том же Шарпе под нет намног проще писать качественный код, чем на С++ и врукопашную (естественно если задача не по указателям шарить).
IT>>Разница была лишь в методе вставки данных в базу данных. Во втором случае использовался BULK INSERT, который сам по себе работает в десятки раз быстрее.
S>А что мешало его использовать его в программе на С++?
А ты найди нужый кусок без профайлера, или там где он не пременим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Sergey, Вы писали:
S>Насчет того, что GC работает быстрее чем сишный хип — ты уверен, что это справедливо для любого сишного рантайма и самописных хипов? На любых задачах? Речь вроде не шла о конкретном компиляторе.
Вот смотри! Ты сказал ключевые слова "любого сишного рантайма". Т.е. ты и сам понимаешь, что многие рантаймы могут оказаться менее эффективным.
А пример твой и проверить то тяжело, так как ты рандом используешь. а рандом в .NET и STL разный (я уже не говрю о разных реализациях STL).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте IT, Вы писали:
IT>>Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting. AVK>Я думаю что если использовать TcpChannel и BinaryFormatter то сравнение будет не в пользу первого. Плюс у ремоутинга гибкость и удобство использования в разы больше.
Первым, кстати, был .NET.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
IT>>>Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting.
AVK>>Я думаю что если использовать TcpChannel и BinaryFormatter то сравнение будет не в пользу первого. Плюс у ремоутинга гибкость и удобство использования в разы больше.
VD>Первым, кстати, был .NET.
Откуда такие сведения, Ты проверял уже? Дай посмотреть результаты.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, Вы писали:
IT>Здравствуйте VladD2, Вы писали:
IT>>>>Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting.
AVK>>>Я думаю что если использовать TcpChannel и BinaryFormatter то сравнение будет не в пользу первого. Плюс у ремоутинга гибкость и удобство использования в разы больше.
VD>>Первым, кстати, был .NET.
IT>Откуда такие сведения, Ты проверял уже? Дай посмотреть результаты.
Я имею в виду, что AVK сказал "то сравнение будет не в пользу первого", а первым у него был .NET.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>>>Первым, кстати, был .NET. ;)
IT>>Откуда такие сведения, Ты проверял уже? Дай посмотреть результаты.
VD>Я имею в виду, что AVK сказал "то сравнение будет не в пользу первого", а первым у него был .NET. :)
Ы, ты всё прикалываешься. Мне бы сейчас где-нибудь надыбать нормальное честное сравнение DCOM и Remoting для применения этого хозяйства в борьбе с остатками неверующих, точнее не хотящих и цепляющихся за последнее :)
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Геннадий Васильев, Вы писали:
ГВ>>В прикладную логику с подключённой "толстой" интерфейсной прослойкой. То есть, в то, во что она и должна превратиться в этом случае.
VD>Что ты понимаешь под словом "толстой"?
Я понимаю под эти словом объём кода, который будет заниматься трансляцией COM-овских соглашений и типов данных в данные и соглашения, принятые при разработке прикладной логики.
SS>>>Вот мне бы это и хотелось услышать от противников .NET,С#,Java примерно такую фразу: SS>>>"реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET"
ГВ>>Это от объёма задачи зависит. Чем она больше — тем важнее унификация внутренней структуры и глубина проработки абстракций. Тем адекватнее там C++.
VD>Софистика чистой воды.
Почему? Помнишь шуточное правило "всякую программу можно сократить на одну команду"? Чем больше программа, тем больше вероятность появления в ней "типовых" кусков, с которыми можно бороться либо никак (copy/paste), либо "рыбами" (copy/paste из общего источника), либо выделением их в функции/классы/модули — т.е., запоздалым выделением абстракций, либо — превентивным анализом и структурированием абстракций. Последний вариант — ИМХО, самый разумный как раз в контексте большой программы (ну, или такой программы, от которой ожидается, что она станет большой). C++ как раз и адекватен, поскольку у него, в частности, развиты механизмы комбинирования абстракций и средства оптимизации (inline).
VD>И вообще ты все время здесь всех лечишь правильной организацией больших програм и что для этого компоненты не нужны, а сам с тудом можешь объяснить что такое. Сдесь все с тобой не спорют, что грамотное проектирование и декомпозиции важная составляющая успеха. Вот только речь то не о том.
Ну, только не передёргивай, я говорил о том, что а) COM — не единственный в своём роде способ реализации компонентного подхода к deployment; б) соглашения COM устанавливают очень неприятные и глупые ограничения для программистов на C++; в) что нет необходимости каждый класс программы делать компонентом в смысле компонентов/объектов COM/CORBA; г) что нет нужды ради "компонентизации" корёжить хороший язык C++.
Теперь о том, о чём "речь не о том" . Речь как раз о привлекательности C++ потому что а) язык позволяет очень глубоко структурировать программу, что в контексте неоспоримого довода о важности декомпозиции и проектировании выглядит очень привлекательным; б) этого никогда не позволят "компонентные технологии", базирующиеся на унификации языковой модели; в) он очень привлекателен как средство "работающей" реализации сложных идей.
В твоих словах сквозит попытка смешать понятия "COM" (или "CLR"?) и "компонентные технологии вообще". Поправь меня, если я ошибаюсь. Если же нет, тогда скажу, что хотя в каком-то контексте такое смешение и возможно (особенно — в контексте маркетингового оболванивания), но не в даннном споре (я не позволю ). Это — неправомерное смешение понятий. Конкретно, смешивается концепция ("компоненты") и конкретная спецификация (COM).
И ещё. Объясни, плиз., что именно я с трудом могу объяснить?
ГВ>>Концептуально — частный случай, фактически — COM и ORB распространены очень широко. Теперь к ним добавляется .NET. Но это ничего не меняет.
VD>Чего? Твоего отношения сложившегося из-за нежелания разобраться в критикуемых тобой технологиях?
Нет, не только моего мнения. Это не меняет того, что COM/ORB/.NET/<вписать> являются частными случаями реализации компонентного (модульного с описанными выше расширениями) подхода.
ГВ>>Да C++-то доживёт. А вот доживёт ли .NET не мутировав во что-то ещё "очень новое" — абсолютно не уверен.
VD>Доживет. Как C и asm. А .NET конечно мутирует. Или сдохнет. Например, ему точно нужна мутация в области дженерик-программирования.
Ну вот, мутирует, там и посмотрим Только, ИМХО, он ещё и в плане рантайма мутировать будет. То-то веселуха начнётся с бинарной совместимостью. Впрочем, последнее — злостный стёб. Ничего архисложного в JIT-компиляции старого кода в новый нет.
SS>>>Тут спор не в синтаксисе языков а в уровне абстракции.
ГВ>>Да, только уровень абстракции — человеческая прерогатива. Язык — это просто инструмент. Более или менее удобный. Который тем или иным образом влияет на пользователя. Об том и все эти споры.
VD>Вот ты и даказал своей реализацией делегатов, что С++ хреновый инструмент для реализации абстракций. Помнишь свое описание метода? Да и переносимость кода доказал замечательно. Иди скомпилируй свой код где-нибудь под Sun-ом.
Интересно ты выводы делаешь Ты мне говорил, что аналога делегатов C# на C++ сделать нельзя, я предметно доказал обратное. ИМХО, доказав гибкость C++ как инструментального средства. Реализацию можно сделать и по-другому, вопросов нет. Можешь сам этим заняться, если интересно. Мне лично — уже нет, по причинам, изложенным чуть ниже. Кстати, об "описании метода". Я думаю, что если бы ты почитал реальное описание того, как работает CLR — то выводов класса "ужас", "монстр" и т.п. сделал бы ещё больше.
У меня тут появилась замечательная мысль, которая ускользала на протяжении всех этих баталий. А на хрена в C++ вообще делегаты с евентами нужны? Всё, что можно сделать делегатами/евентами зашибись как решается интерфейсом с единственным методом, принимающим объект-сообщение нужного типа плюс множественным наследованием объекта-приёмника от нужного набора таких интерфейсов (можно — с частичной реализацией оных). От ипостаси "евентов" как от варианта диспетчера сообщений никуда не денешься, но зачем тянуть за собой процедурно-ориентированный интерфейс? Это же совсем не объектный стиль в принципе!
То есть, оцени прикол: я что-то доказываю тебе, ты — мне, тогда как сам по себе объект обсуждения выбран некорректно! Если слегка перефразировать твоё высказывание, то это не "C++ — хреновый инструмент", абстракция хреновая. Так что, признаюсь, что кое в чём я сам повёлся на удочку. И, кстати, теперь я чуть больше, чем раньше согласен с теми высказываниями, которые сопоставляют C# и "чистый" C. Он-таки на самом деле близок к C!
VD>Тебе не кажется, что твоя реализация просто монстроидальна и что она явно проигрывает тому что было на дремучем С (как по краткости и элегантности, так и по эффективности)?
Нет проблем — можно поманипулировать с регистрами, можно и от типобезопасности избавиться. Только я этого делать не буду. Если считать void* верхом достижения программистской мысли, то это не есть правильное считание.
ГВ>>По аналогии с филологической лингвистикой (извини за тавтологию), по отношению к программистской лингвистике можно, ИМХО, постулировать, что язык определяет набор абстракций, которыми человек оперирует при удовлетворении своих интеллектуальных потребностей. Есть только одна закавыка — набор абстракций должен быть инструментом попрождения работающей системы. Вот тебе и связка и переход между "уровнем абстракции человека" и "уровнем абстракции от аппаратуры".
VD>И вот же умеют люди сказать простую фразу, так что ничерта не понятно.
Ну, перечитай ещё раз. А если без стёба, то сформулируй вопрос — отвечу.
ГВ>>Интересно, рефлексия в форумах наверное никогда не прекратится. Не, ребята, я больше в мыльных операх не участвую. VD>Гы-гы.
Banzai!
SS>>>А для более высокого уровня C++ не приспособлен.
ГВ>>А это очень похоже на формулу аутотренинга. Повторять утром и вечером! Чтобы не подумалось иначе.
VD>Не... это ты себе повтояешь. И не хочишь открыть глаза и увидить, что все не так как на самом деле.
Да, я понимаю, что здесь мне не тут.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Они ведь там тоже из компонентов все лабают... Это даже не демогогия, это откровенное незнание предмета обсуждения. Ты уж извени.
Помнишь свое описание метода? Да и переносимость кода доказал замечательно. Иди скомпилируй свой код где-нибудь под Sun-ом.
Если нам не помогут, то мы тоже никого не пощадим.
