Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, voxel3d, Вы писали:
VD>А от чего тошнит? Можешь разжевать? Я вот как-то чем дальше, тем больше вспоминаю о плюсах как о страшном сне.
Ну, я же сказал, субъективно это всё. Меня раздражает ихний сборщик мусора, если б я сам его написал, он мне бы нравился , меня раздражает отсутствие указателей, верннее их невостребованность, то что ссылки являются указателями, а не алиасами, то что отсутствуют хидеры, отсутствие адресной арифметики, до сих пор отсутствие шаблонов, невостребованность и отсутствие множественного наследия, то что не надо помнить мрачные правила преобразования типов, то что когда параллельно со мной работали дельфисты, они дерево изделия состоящее из 20 тысяч деталей читали из базы, строили в памяти структуру и выводили её в тривью за 20 секунд, а я за 4.. то что это уже не переносимый ассемблер и то что мне не требуется читать Мэйерса, Элджера и Александреску, да и Страуструпа тоже, после перечитывания которых каждый раз я понимал, что до этого С++ я не знал.. И вообще, я любил секс с непонятными глюками, дебаггер и профайлер были моими любимыми игрушками и я знал, что кроме меня баги никто победить не в состоянии будет, а здесь.. всё упростилось. Синтаксис изучил, с библиотекой классов ознакомился, всё. Идиомы гораздо проще.. Нету в шарпе духа, сдох он. И свободы в нём нет. Есть только один стиль написания программ -- правильный. Неинтересно. В С++ мои знания в глубину росли, а здесь я не понимаю вообще куда.. С шарпом с хорошим архитектором, очень умные программисты в 80% проектов не особо нужны бывают.. В С++ такой номер не прокатил бы..
Но ничего, я нашёл новую игрушку -- Linux, там С++ хоть отбавляй.
Ну, что же... отрадно, что ты перешел от заявлений к измерениям. Пускай не все получается, но все же это уже прогресс.
Итак, для начала определимся, что конкретно мы сравниваем. Сравнивать C++ и C# довольно бессмысленно, так как это всего лишь языки. Всегда можно найти плохой компилятор С++ который проиграет C#-у. Согласен?
Значит сравнивать нам нужно все же нечто иное. Я бы охарактеризовал бы это как ".NET vs. Оптимизирующие компиляторы". В качестве эталонного компилятора возьмем реализацию VC7-8 (обладающие лучшими характеристиками на сегодня). ОК? С C#-ом все еще проще, на сегодня есть только реализации от МС. Их доступно три: 1.0, 1.1 и 1.2 (Whidbey).
Теперь о том, как мы сравниваем. Сравнивать специализированную реализацию и универсальную не корректно. Если уж мы хотим получить ответ о качестве генерации кода.
Стало быть разберем оба примера по отдельности. Сначала С++-ый. Итак я создал прокт, поместил в него твой С++-код и скомпилировал его в двух вариантах: 1) для Win32 (Release), и 2) тоже с ключом /clr. Результаты оказались следующими (у меня Atlon 2100+):
Unmanaged-вариант: 751
Managed-вариант: 811
Таким образом, разница составила 7% и ее можно лекто списать на Interop возникающий при вызове unmanaged-функции memcpy (которая к тому же в unmanaged-варианте VC вообще превращается в ассемблерные инструкции).
Теперь зайдем с другого конца. Возьмем тест на C#-е и попытаемся переписать его на С++ без ручных оптимизаций. Как бы поступил средний программист встань пред ним подобная задача? Да очень просто... он воспользовался бы готовым классом. B VC предоставляет нам такой класс — это CString. Его ATL-версия как раз имеет вариант CStringW (работающий с Юникодом). Переписываем тест:
Запускаем... дожидаемся, окончания работы программы... и делаем выводы.
Выводы не утешительны. С++ вообще не пригоден для программирования.
Обман? Несомненно!
PS
Какой же вывод можно сделать из всего этого? Да очень простой. Разница в коде порождаемом JIT-ом .NET-а/Явы и кодом порождаемом оптимизирующим компилятором С++ ничтожна. Она конечно есть, и в большинстве случаев она не в пользу .NET-а, но намного больше на работу конечного приложения влияет правильность выбора алгоритма и грамотность реализации этого алгоритма.
Намек ясен?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, alexkro, Вы писали:
A>>Я почти уверен, что и C# версию можно достаточно соптимизировать. Кстати, вопрос на засыпку: чем определяется предел оптимизации для данного примерчика?
VD>Специализацией алгоритма и качеством инлайнинга методов. Остальные оптимизации у Шарпа и VC практически одинаковы.
Если даже применить все теоретически доступные оптимизации, то останется только одно ограничение — скорость доступа к памяти. Учитывая это, можно оценить насколько реализации использующие только стандартные компоненты далеки от идеально оптимизированного варианта. На моей машине P4 3GHz с памятью PC3200 максимальное, что я смог достичь, — это 0.45 сек. Есть основания думать, что используя SSE для прямой работы с кэшем (правильно используя на данном конкретном CPU), можно уменьшить время на 30%, что дает 0.3 сек. Теперь стандартные компоненты: std::wstring — 0.9, StringBuilder — 1.1. Отсюда вывод — стандартные комноненты достаточно хороши для данной задачи, чтобы не заботиться об специальной оптимизации (пока, конечно, это не станет основным bottleneck'ом в программе).
Здравствуйте, Sinclair, Вы писали:
S>Неправда. В этом языке нет метаданных. Ты не сможешь сделать, например, маршалинг автоматически. Существующие для С++ решения опираются на инструменты автоматической генерации исходного кода. MIDL — suxx.
Не так часто нужен маршаллинг, а когда нужен то ИМХО что-то типа MIDL в самый раз. Зачем собирать мусор со всего света и тащить его в язык?. Лучше узкоспециализированные веши порешать специальными заточенными тулзами. Тады все будет ОК. И свобода выбора останется. Вдруг понадобятся тебе специализированные метаданные и упресся ты в то, что намертво в НЕТ зашито, тады сразу вспомнишь старые добрые плюсы.
S>>>JIT, Metadata, User-Defined Metadata. Этого в С++ нет и быть не может. Некоторые из моментов поддаются эмуляции. Да и то она выглядит достаточно бледно по сравнению с тем, что есть в .Net. Одна возможность генерации кода на лету открывает совершенно новое измерение гибкости и комфорту.
S>Нельзя там сделать генерацию кода. Вся генерация кода заканчивается в compile-time. Оставаясь в рамках языка, ты не сможешь генерировать в рантайме исполняемый код. А зачем — для перформанса, вестимо. Ты про частичные вычисления слышал? Гуглить по фамилии "Ершов". Смысл в том, что компилятор ограничен знаниями, которые у него есть. В рантайме можно получить дополнительную информацию для семантической оптимизации. В рамках С++ ее использовать нельзя — код представляет собой монолит, и подправить его не выйдет.
В С++ тоже можно генерить код на лету. Таскай с собой бесплатный Ц-компилер. генери Ц-код, собирай в DLL грузи и выгружай. И не капассируй нам мозги про генерацию кода.
S>Про легко и ярко — ну я бы не сказал. Вон, в RSDN #5 есть статья "МЕтаданные своими руками". Ага. Эмуляция того, что встроено в .Net. Сложность и неудобство видны невооруженным взглядом.
Сложность где? Я вот идейку на вооружение взял, порешал то-что нужно и в макрос все завернул. Теперь добавляю в свои классцы по одной строчке на класс и не нарадуюсь. Все летает и гемороя не имею. И ограничений особых нет.
Здравствуйте, VladD2, Вы писали:
K>>Автоматическое управление памятью — это фатальный недостаток НЕТ. Программы которые манипулируют одновременно около 100000 обьектами связанными в сеть, писать на НЕТ просто нет смысла.
VD>100000? Я когда грид отлаживал как раз дерево из этго количества строил. Загружается молниеносно.
Из чего загружается ? Попробуй загрузить 100'000 объектов, которые указывают друг на друга, по пять-десять пропертей, из файла.
Hello, Plutonia!
You wrote on Sat, 13 Mar 2004 10:17:42 GMT:
PE>>> Нужно написать такой язык, отладить, протестировать, AVK>> XML + embedded C# или VB. PE> Не пойдет. Нужен специализированый язык, нечто вроде UML в PE> текстовом представлении, который будет прятать все, что не PE> относится к математике.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, <Аноним>, Вы писали:
А>>Так C++, за исключением шаблонов, более ограниченный язык. ВВ>C++-то как раз куда менее ограниченный чем C#.
Мы про язык? Тогда считаем:
1. Атрибуты.
2. Сборщик муссора.
3. Отражения.
4. foreach
5. Мощный строковый тип
6. Многомерные массивы, массивы массивов
7. Делегаты, цепочки делегатов.
8. События.
9. SEH.
10. Параметризованные/непараметризованные свойства + наследование свойств.
11. Тип 128-битный тип decimal
Еще раз: речь про язык.
ВВ>Зато вот Win32 куда более ограниченная платформа чем .NET
Да-да, крокодил больше длинный, чем зеленый... Проходили.
Здравствуйте, alexkro, Вы писали:
A>Здравствуйте, c-smile, Вы писали:
A>А std::wstring не проверял? Кстати, компилятор надо бы поновее взять. Еще вопрос: этот примерчик можно заоптимизировать до смерти, но какой в том смысл?
std::wstring как и String в С# — immutable classes — не предназначены для динамического склеивания строк.
Собственно оптимизирования никакого не проводилось. Такая задача не стояла.
Наоборот — работать только штатными стандартными средствами платформы.
wchar_t_buffer — исп. классичекую имплементацию динамического буфера в C++.
Это не делалось через std::vector, например, по причине наличия разных альтернативных имплементаций std::
Здравствуйте, VladD2, Вы писали:
VD>но намного больше на работу конечного приложения влияет правильность выбора алгоритма и грамотность реализации этого алгоритма. VD>Намек ясен?
Говорил бы уж сразу — от радиуса кривизны
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Аноним, Вы писали:
А>Ясно) Интересно, что у тебя за проект, и почему его решили на шарпе писать?)
Много всяких. От всякого бухгалтерского дерьма, систем обработки заказов, до оптимизаций грузоперевозок. Шарп используется, потому что на нём удобно проектировать сложные проекты. Я понимаю, что проектирование и язык программирования суть разные вещи, я имею ввиду в шарпе удобно спроектированные конструкции воплощать. Эвенты, делегаты, сборщик мусора, аттрибуты, большая библиотека классов и ограниченность языка по сравнению с С++ -- всё это делает проект дешевле. С другой стороны, меня тошнит уже. Но бизнес есть бизнес.
A>У меня у одного друга в фирме начали использовать .NET из-за легкости разработки UI. Вот это по-поему изврат.
Почему изврат?
Вот лично для меня аргументация:
Продукцию Борланда в расчёт не берём, не из религиозных предубеждений, которые если честно, имеются, а из-за того, что 1) там где я проживаю о ней почти не слышно, 2) после кидалова с OWL отношение к борланду -- нах-нах.
Что остаются под Windows?
Qt, fltk, wxWindow, MFC, WTL либо ещё какая неизвестная мне экзотика.
Qt -- 1) дорогая, но что более важно 2) в коллективе Qt могу только я.
fltk, wxWindow -- fltk -- мне незнакома, wxWindow могу только я, но UI на шарпе в студии делать проще.
MFC, WTL -- это уже вчерашний день по сравнению с шарпом, UI в шарпе делать проще.
Есть ещё Java и VB. Это активно используется.
UI на шарпе писать, в принципе, неплохой выбор.
А>У меня вроде что-то многуровневое и распределенное, наверно для этого и предполагается все это пользовать.
Ну, к ремотингу в дот нете надо ещё дофига всего дописывать -- голая технология в чистом виде сама по себе не нужна бывает.
Здравствуйте, naje, Вы писали:
N>это я и у микрософта читал только реальных подтверждений этому не видел
"суслика видишь? нет? а он есть!" (с)
... << RSDN@Home 1.1.3 beta 1 >>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Здравствуйте, naje, Вы писали:
N>Я хотел в качестве примера не проект (которых и на С++ достаточно), а особенность, N>которая сокращает сроки разработки
автоматическое управление памятью решает очень большую часть проблем N>и повышает читабельность.
отсутствие ужасного разделения между декларацией и дефиницией, которое заставляет при чтении непрерывно прыгать между .cpp и .h
Это не все. Но уже достаточно чтобы понять, откуда и куда дует ветер.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Kluev, Вы писали:
K>Не так часто нужен маршаллинг, а когда нужен то ИМХО что-то типа MIDL в самый раз.
Правильно. Как бы раком не стоять, лиш бы нового не изучать.
K> Зачем собирать мусор со всего света и тащить его в язык?. Лучше узкоспециализированные веши порешать специальными заточенными тулзами. Тады все будет ОК. И свобода выбора останется. Вдруг понадобятся тебе специализированные метаданные и упресся ты в то, что намертво в НЕТ зашито, тады сразу вспомнишь старые добрые плюсы.
Ага. Ведь в С++ вообще нет метаданных. Вот простор то для творчиства. А в дотнете как раз для расширения метаданных есть механизм атрибутов.
K>В С++ тоже можно генерить код на лету. Таскай с собой бесплатный Ц-компилер. генери Ц-код, собирай в DLL грузи и выгружай. И не капассируй нам мозги про генерацию кода.
Ты пробовал? Скорость компиляции плюсов просто никакая. Ждать окончания компиляции скрипта по минуте... А тот же эмит работате молниеносно. Да и компиляторы Шарпа/ВБ летают.
K>Сложность где?
— Вот у нас на предприятии говорят что воздух грязный... А мы по многу лет работем и ничего не замечаем, ничего не замечам, ничего не замечам, ничего не замечам, ничего не замечам...
(с)
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Hello, AndrewVK!
You wrote on Thu, 26 Feb 2004 10:37:06 GMT:
A> А у меня есть примеры когда сделали. Далеко ходить не надо — этот сайт, A> янус, RSDN NNTP.
Последний — замечательный пример Чаще не работает, чем работает.
Best regards,
Sergey.
Posted via RSDN NNTP Server 1.8 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
VD>Здравствуйте, naje, Вы писали:
VD>>>Хотел было что-то ответить, но умер со смежу. В общем, 5 балов... Я плякаль...
N>>лично мне твоё психическое состояние знать совсем не интересно, это помоему форум не по той теме форум
VD>Я как бы не тебе отвечал.
K>>В С++ вообще все user-defined. Конечно метаданные как в НЕТ не сделаешь, но ИМХО и потребности нет. S>Вот-вот. То же самое сорок лет назад говорили ассемблерщики про C.
Разное время, разные задачи, разные требования. Ассемлер был востребован именно для задач своего времени. Всякие плюсы и остальное гемор были действительно не особо нужны.
S>>>Ну щас прям. И сразу получи платформенную зависимость. Как минимум. А также необходимость таскать с собой запас хидеров для того, чтобы генеренный код мог взаимодействовать с другим кодом. В общем, ребята, солюшн с Ц-компилером даже на шутку не тянет. Потому его и не применяет никто и никогда. В отличие от той самой генерации кода в .Net.
Солюшн с цекомпилером — вындоуз и линукс например. Думаю что линукс более патформонезависимый, нежели дотнет. На скольки патформах доступен дотнет ?
Слишком большой CLR, что бы его портировать. За то время, пока Билл портировал CLR для БСД, линуксоилы освоили парочку платформ.
S>Короче, я никого не заставляю. .Net предлагает способ дешево делать хорошие программы. Альтернативы ему есть — та же Java.
Смотря для чего. Чтото игровая индустрия не особо то и спешит в сторону дотнета и жавы.
И здесь используются именно скрипт-машины на для С++.
Вот когда появится Офис полностью менеджед или другой тул поольше, тогда модно будет сравнить быстродействие. На нашем проекте дотнет очень сильно проигрывает в этом плане.
Зато не нем дешевле и проще.
Здравствуйте, Sinclair, Вы писали:
N>>я спрашивал что нового в .Net, как вобще можно сравнивать язык с фреймворком? S>Как хочешь — так и сравнивай. С++ тоже не только язык. Без стандартной библиотеки и рантайма он мертв.
Ты еще скажи, что С++ без компилера мертв. С++ нужно всего ничего — компилер, линкер и... все ! Есть АПИ — юзай его. Это только кажется, что мало что можно сделать.
На самом деле это очень много. В этом плане для дотнета нужно очень много.
S>Да нет проблем. Просто в C# делается все, что делается в .Net. В С++ этого нет. В нем нет делегатов, нет автоматического управления памятью, нет гарантий, что везде, где можно написать a<b можно написать и b>a, нет Reflection, нет модели безопасности, нет встроенной поддержки компонентности.
Делегатов нет — это точно. Автоматическое управление памятью не всегда то и нужно.
В с++ память кушается меньше и больше юзается стек. Моей тачки — 800мгц+512MB вполне хватает для всех плюсовых задач. А вот для дотнета очень слабо. Профайлер работает ой как долго.
Все от того, что памяти кушается слишком много.
Здравствуйте, Sinclair, Вы писали:
S>Может я чего не знаю, но что-то я не вижу способа просто и изящно передать параметры маршалинга в С++ библиотеку в непроцедурном стиле. Как ты объяснишь, что вот этот параметр надо маршалить по ссылке, а этот — по значению?
Только как я уже говорил иногда выгоднее использовать внешние описания и кодогенераторы. А аля маршаллинга лучше что-нить типа IDL
S>Да. Внутри там то же самое что и в других системах. Это не серебряная пуля, это просто способ повысить производительность и качество труда программистов.
Отдельно взятой категории программистов. Мою производительность он никак не способен повысить, задачи совсем другие.
S>Да нет проблем. Просто в C# делается все, что делается в .Net. В С++ этого нет. В нем нет делегатов, нет автоматического управления памятью, нет гарантий, что везде, где можно написать a<b можно написать и b>a, нет Reflection, нет модели безопасности, нет встроенной поддержки компонентности.
Автоматическое управление памятью — это фатальный недостаток НЕТ. Программы которые манипулируют одновременно около 100000 обьектами связанными в сеть, писать на НЕТ просто нет смысла.
А все осталное в свете этого — это как висит груша нельзя скушать. Возможности есть но из-за обших недостатков их не заюзаешь. Когда у вас пройдет эйфория поймете что у НЕТ есть свой скромный уголок, такой же как и у всех языков. Страуструп, вообще, всегда говорил что С++ — это язык номер 2.
S>Да, все это можно эмулировать. Впрочем, наследование тоже можно эмулировать на С. Проблема в том, что в рамках С++ нельзя научить компилятор валидировать введенные пользователем правила. И из-за отсутствия рефлексии нельзя это сделать и в рантайме. Поэтому у Versant есть свой препроцессор, который проверяет persistent классы на целостность и генерирует метаданные. Но это фактически другой язык. В C# работу, выполняемую этим препроцессором, можно делать в рамках языка. См. Rsdn.Framework.Data. Почему-то никто не написал подобного для С++!
Здравствуйте, AndrewVK, Вы писали:
AVK>Не, в 1.2 вроде бы МС++ можно для страничек пользовать.
МС++ можно было использовать для АСП еще в весрии 1.0 (раком правда, но все же). Но это МС++. На на обычном так вот просто хрена с два выйдет. Будут все те же проблемы С++.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Plutonia Experiment, Вы писали:
VD>Да никто и не спорит, что и С++ и даже С будут жить еще очень долго. Но с каждым годом системы вроде дотнета и явы будут совершенствоваться и вытеснять плюсы из все большего количества ниш.
VD>Рассказы о приемуществах С++ в скорости сильно приувеличены. А со временем этих приемуществ вообще не будет. Если сравнить скорость VC и дотнета (C#) вресий 7.0, 7.1, 8.0, то невооруженным взглядом видно, что разрыв потихоничку сокращается. Да и не так он велик. Без проблем в алгоритмах масимальный проигрыш в 2 раза. Если же учесть простоту и скорость разработки на дотнете, то становится понятно, что проще экономить время и тратить деньги на железо. Ну, а если учесть, что аысвободившееся время можно потратить на оптимизацию алгоритмов...
Например, на алгоритм сортировки. Или на алгоритм сложения 2 и 2.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Plutonia Experiment, Вы писали:
VD>Да никто и не спорит, что и С++ и даже С будут жить еще очень долго. Но с каждым годом системы вроде дотнета и явы будут совершенствоваться и вытеснять плюсы из все большего количества ниш.
Гы. плюсы тоже не стоят на месте. У плюсов нет единой библиотеки на разные случаи жизни. Все приходится по миру собирать. Это основная трудность. Было-бы что-нибудь типа QT нахаляву, тогда народ с плюсов выманить было-бы невозможно. А если появится многие вернутся обратно.
VD>Рассказы о приемуществах С++ в скорости сильно приувеличены. А со временем этих приемуществ вообще не будет.
Будут всегда. Сборка мусора всегда будет тянуть НЕТ на дно. От этого никуда не деться. Может далеть UI на НЕТ-е и просто, но работать со сложными структурами я бы на нем не стал.
VD>Если сравнить скорость VC и дотнета (C#) вресий 7.0, 7.1, 8.0, то невооруженным взглядом видно, что разрыв потихоничку сокращается. Да и не так он велик.
Смотря на чем сравнивать.
VD>Без проблем в алгоритмах масимальный проигрыш в 2 раза. Если же учесть простоту и скорость разработки на дотнете, то становится понятно, что проще экономить время и тратить деньги на железо. Ну, а если учесть, что аысвободившееся время можно потратить на оптимизацию алгоритмов...
Алгоритмы уже проблема. Возьми любую нетривиальную задачу — триангуляция поверхности, разбиение обьема и т.п. То что такие вещи неудобно делать с автоматической сборкой мусора, в языке без адрессной арифметики (или с образаной арифметикой), и без возможностей прочего хака ясно как дважды два четыре.
Здравствуйте, VladD2, Вы писали:
VD>>>Рассказы о приемуществах С++ в скорости сильно приувеличены. А со временем этих приемуществ вообще не будет.
K>>Будут всегда.
VD>Ошибаещся.
Вот интересно, зачем же тогда половина стринга написана на нативном С++ ? Стрингбилдер туда же. Да и вообще много че написано нативно, хотя можно было менеджед заимплементить.
Ведь можно его на шарпе реализовать полностью. Наверное Били решил таким способом замелить строку ?
K>> Сборка мусора всегда будет тянуть НЕТ на дно.
VD>А это ничего, что ЖЦ в Яве работает не медленнее чем стандартные хипы С++?
А это ничего, что аппликухе на нативном с++ хватает памяти, а дотнету — нет ?
K>> От этого никуда не деться. VD>Ты алгоритм ЖЦ знаешь? Что в нем может потенциально быть проблемным?
Он слишком долго отслеживает ссылки, если их слишком много.
K>> Может далеть UI на НЕТ-е и просто, но работать со сложными структурами я бы на нем не стал. VD>Что есть сложные структуры?
Модель сети например. Любая наукоемкая задача использует очень сложные стурктуры.
K>>Алгоритмы уже проблема. Возьми любую нетривиальную задачу — триангуляция поверхности, разбиение обьема и т.п.
VD>Ну, эти задачи уже давно в акселераторы зашиты. Но все равно потенциально проблем с их рассчетом на менеджед-языках нет.
В какие акселераторы ? Туда зашивают только то, что хорошо разжевано, канонизировано и стандартизировано. Окромя этого есть много алгоритмо оработки изображений. Распознавание например. А с оработкой звука как ? Реалиизуй алгоритм смены голоса диктора на шарпе (двумя способами — со словарем и без оного) , будем посмотреть.
Здравствуйте, VladD2, Вы писали:
PE>>Вот интересно, зачем же тогда половина стринга написана на нативном С++?
VD>Хороший вопрос. Особенно елси учесть тот факт, что этот код проигрывает аналогичному написанному на Шарпе.
А где это можно посмотреть ?
VD>Все требовательные к производительности фукнции стрингбилдера реализованы прямо в нем. Импортируются как раз не столь важные.
Копирование строки — нативная функция.
VD>Да на Шарпе все же по более будет. И самые медленные реализации как раз на С++ сделаны. Правда это не означает, что С++ никуда не годится. Просто на С++ обычно реализуются универсальные вещи, а они в принципе обычно тормозны.
Это точно. А ассемлерные программы всегда тормозные в принципе.
VD>Где? Вот у нас на сервере мс-сиквел и АСП.НЭТ. Так сиквелу памяти нехватает, а АСП вроде не кашляет.
А что, окромя сиквела и АСП нет других применений ?
PE>>Он слишком долго отслеживает ссылки, если их слишком много.
VD>Слишком много это сколько? Миллион отслеживает почти молниеносно. Да и делается это не постоянно.
Почти — растяжимое поняте. Минимум 8 секунд при 20000 референсов.
PE>>Модель сети например. Любая наукоемкая задача использует очень сложные стурктуры.
VD>Т.е. граф? Нда, куда уж сложнее. Нормально он будет с ней работать. Памяти возможно сожрет больше, но если ее хватает, то будет очень даже прилично работать.
Ой-ой. Мы год назад начали писать, сейчас первый релиз был. Это не просто граф. Это гиперграф.
Граф состоящий из графов. Всего различных объектов около 600. Вот они то и реализуют весь гиперграф.
PE>> Реалиизуй алгоритм смены голоса диктора на шарпе (двумя способами — со словарем и без оного) , будем посмотреть.
VD>Это давно решенные задачи. Если конечно велосипед не изобретать. Ну, и главно ошеломляюще быстрее на С++ их один фиг не решить. Ну попробуй хоятбы не медленнее и без нативных фичек.
Давно — это конечно. Осоенно если учесть, что это самая актуальная тема для диссеров.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Здравствуйте, AndrewVK, Вы писали:
AVK>>Рынок только у твоих знакомых ну очень маленький. PE>>>А на ноутуке твоем много железа с аппаратным преоразованием того же фурье ?
AVK>>Нет. А нафига оно мне?
PE>Запусти SoundForge или VCS Diamond и убедись, что весь звук обрабатывается программно.
PE>Обраотка звука — это не спецэффекты, которые в курточку засунуть можно. Это математика
профессиональное создание музыки это не SoundForge или VCS Diamond, там как-раз много чего апаратного (как впринципе и профессиональное слушанье )
Здравствуйте, AndrewVK, Вы писали:
AVK>Все это правильно, вот только что то мне кажется что меньше всего меня волнует скорость работы на шарпе алгоритма сжатия в mp3 или ogg. Потому как это мизерный процент решаемых с его помощью задач.
Звук тебя не интересует, математика тоже, видео туда же. Меня это интересует, я не буду пользваться винампом, который перепишут полностью на дотнете.
Кстати, а игрушки нынче все аппартаные ?
Процент мизерный, а используется повсеместно. Даже на твоем крутом ноутбуке весом в 2.8 кг.
PE>>Кстати, а рары, зипы, тары — тоже аппаратно жмут ?
AVK>Ты часто рары и зипы пишешь? Я нет.
С помощью раров и зипов меряется реальный перформанс процессоров.
Со временем конечно начнут писать ужималки, математику, моделирование, игры и тд и тд на дотнете полным ходом. Но не потому, что перформанс выше. Потому, что дешевле. Как только PI-PII-PIII устареют на столько, что самы распространенным процом будет PIV, тогда и рванет дотнет в небо. Ну и на 64битах конечно. Портировать на 64 бита гораздо проще дотнет и прилы под него, чем несколько миллионов прилаг.
Здравствуйте, AndrewVK, Вы писали:
PE>>Почему бы тебе на XML и программы тогда не писать? AVK>Потому что программы содержат в основном императивные инструкции.
Вот в чем дело. Взаимодействие объектов придется частично на этом же языке описывать.
PE>>Очень неплохо подходит.
AVK>Это тебе кажется удобнее, потому что ты на плюсах пишешь. Только ты то жаловался на то что те кто это должен писать — непрограммисты. А для них куда как проще декларативный стиль задания.
Проще, но не XML. XML сгодится в качестве промежуточного. Генератор должен XML примнимать, а вот человеку с XML работать не нужно. Слишком много текста и структура плохая.
AVK>Вот смотрел, потому и говорю. WSDL удобнее, более масштабируемо и мощнее.
Ничего тут не удобнее. Если один раз написать и забыть, то можно и XML,WSDL и все, что хочешь юзать.
А если ты постоянно будешь работать с языком, то XML тут не помощник.
Здравствуйте, AndrewVK, Вы писали:
PE>>Языки всякие например.
AVK>Я же тебе сказал — любая технология хороша в своей области. И не везде императивные языки лучше. Например для кодогенератора XSLT шаблон обычно значительно лаконичнее программы на том же шарпе или джаве.
Шаблон генерации в HTML очень похож на этот самый HTML. А если захочешь гнать XML в С#, то шаблон будет очень похож на C#.
PE>> их порядок,
AVK>Это вобще не нужно. Если у тебя что то зависит от порядка атрибутов то это очень криво.
Для XML нужны схемы данных. Это там порядок указывается и регистр.
AVK>Поэтому понять первый вариант не программисту заметно проще. А если еще к нему xsd написать и воспользоваться специализированным редактором, то редактировать данные в гриде сможет совсем уж далекий от программирования человек. Для второго же варианта нужно быть программистом, причем на С-like языке.
В том то и дело. Непрограммисты меня не интересуют вовсе. Наши индейцы(практически все) умеют писать кое что на C++, C# и Яве. Некоторые особо опасные индейцы даже питоном владеют(им так кажется).
В одном случае придется писать редактор, во втором — просто перегонять в XML, с которым и будет работать генератор. Но человеку XML не нужно знать.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>А в чем проблема?
PE>Собственно в валидации.
Ну так способ задания валидации при помощи схемы куда проще обработки ошибок в парсере.
PE>>>Вот и я про то. Надо помнить все подряд. А свой язык можно упростить очень сильно.
AVK>>Сильнее XML вряд ли получится
PE>Я уже говорил, что XML это примитивный язык. Простота — это немного другое.
Это все игра словами и ничего более.
AVK>>А, ну ну. Значит схему написать это жутко долго, а вот отпарсить язык плевое дело.
PE>Нет. Схему еще проще.
Причем намного. О том и речь.
PE> Для редактирования XML придется свой редактор писать. Вот я про что.
А для своего языка типа не надо? Впрочем меня пока XmlSpy устраивал по большей части.
AVK>>То что они делают только для учебных целей и годится. А на практике чтобы получить production quality парсер даже несложного языка надо изрядно попахать. Вот тот же XML, казалось бы там парсер можно за полдня на коленке написать, а на практике даже для такого парсера придется попахать от души.
PE>На практике пахать не нужно. Можно брать готовое.
Здравствуйте, Воронков Василий, Вы писали:
kuj>>Открываете спецификацию C# и убеждаетесь в его правоте. Все (кроме, разве что, отражений) вышеперечисленные понятия имеют непосредственное отношение к языку C#.
ВВ>При этом все это реализовано на уровне библиотек.
Свойства, атрибуты, отражения? Можно узнать урлы библиотек, реализующих это?
Да, а еще хотелось бы урл на полноценный эфемерный сборщик муссора с дефрагментацией кучи, масштабируемый на многопроцессорной системе и отдельной кучей для больших объектов. Можно? Буду очень признателен!
Здравствуйте, Воронков Василий, Вы писали:
kuj>>Так C++, за исключением шаблонов, более ограниченный язык.
ВВ>В ответ на что я написал, что это C# более ограниченный язык. А фичи C#, о которых вы говорите, являются фичам платформы .NET, и к языку имеют весьма опосредованное отношение.
На что я ответил, что они являются также и фичами языков, которые относятся к этой платформе и предложил Вам заглянуть в спецификацию C#.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Воронков Василий, Вы писали:
kuj>>>Так C++, за исключением шаблонов, более ограниченный язык.
ВВ>>В ответ на что я написал, что это C# более ограниченный язык. А фичи C#, о которых вы говорите, являются фичам платформы .NET, и к языку имеют весьма опосредованное отношение. kuj>На что я ответил, что они являются также и фичами языков, которые относятся к этой платформе и предложил Вам заглянуть в спецификацию C#.
Здравствуйте, Sinclair, Вы писали:
S>4. Василий отвечает ему, что в C# этих фич тоже нет.
Sinclair, а ты сам то давно читал спецификацию Шарпа? Как можно говорить, что чего-то нет в языке если это его часть?
S>5. Ты начинаешь ссылаться на спецификации С#
И правильно делает.
S>6. Василий намекает, что почти все из упомянутого, реализуется не C#, а библиотеками.
Да? Какой библиотечной функцией содается массив в Шареп? А какой определяется его длинна?
А как с помощью библиотеки в Шарпе определить делегат?
А в какой библиотеке лежит foreach? Ведь он зачастую разворачивается в аналог for.
S>7. Ты требуешь их предъявить. S>Ну вот я и предъявил. А теперь ты начинаешь делать вид, что говорил про библиотеки для С++. Не было такого.
Ну, задействуй их и попробуй получить в анменеджед-С++ все эти фичи.
И ответь, чем это все опровергает его слова о том, что Шарп более богатый язык?
Если считать по количеству фич, то это факт. Другое дело, что фичи вроде Шаблонов и МН могут многое перевесить.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Результаты для 10млн итераций (тест на машине Pentium III, 850мгц):
С++ - 1692 ms (+/- 10) С# — 2433 ms (+/- 50)
При этом GC в С# тестах не срабатывал. А в С++ в это время срабатывал лишний delete.
Если изменить политику переаллоцирования буфера в C++ (см ниже)
c _allocated *= 2; на, например, _allocated *= 3;
То цифры такие: С++ - 1422 ms (+/- 10)
Вот.
Содокладчики:
Со стороны С++ — c-smile
Со стороны С# — iLYA
C#
using System;
using System.Collections;
using System.Text;
using System.IO;
namespace Benchmark_CSharp
{
class BenchmarkCSharp
{
static DateTime startTime;
static DateTime stopTime;
static TimeSpan elapsedTime;
[STAThread]
static void Main(string[] args)
{
Console.WriteLine("Start C# benchmark");
long scTime = (long)sc2( 10000000 );
Console.WriteLine("End C# benchmark");
}
public static long sc2(int N)
{
long elapsedMilliseconds;
startTime = DateTime.Now;
if(N < 1) N = 1;
StringBuilder sb1 = new StringBuilder();
StringBuilder sb2 = new StringBuilder();
for (int i=0; i<N; i++)
{
if((i & 1) == 0)
sb1.Append("hello");
else
sb2.Append("hello!");
}
stopTime = DateTime.Now;
elapsedTime = stopTime.Subtract(startTime);
elapsedMilliseconds = (int)elapsedTime.TotalMilliseconds;
Console.WriteLine("String Concat. (fixed) elapsed time: " + elapsedMilliseconds + " ms");
return elapsedMilliseconds;
}
}
}
Здравствуйте, c-smile, Вы писали:
CS>Результаты для 10млн итераций (тест на машине Pentium III, 850мгц):
CS>С++ - 1692 ms (+/- 10) CS>С# — 2433 ms (+/- 50)
StringBuilder sb1 = new StringBuilder(50000000);
StringBuilder sb2 = new StringBuilder(50000000);
String Concat. (fixed) elapsed time: 1211 ms
Pentium III 1000mhz
) CS>И вербально по месту с iLYA.
CS>Два примера С# и С++ делающие следюущее:
...
А std::wstring не проверял? Кстати, компилятор надо бы поновее взять. Еще вопрос: этот примерчик можно заоптимизировать до смерти, но какой в том смысл?
Хочу еще раз подчеркнуть что данное исследование не ставит целью ответить на глупый вопрос типа "кто лучше — папа или мама?"
А просто понять какие классы задач луше делать на каждой из платформ.
Здравствуйте, c-smile, Вы писали:
CS>>>С++ - 590 ms (+/- 0) CS>>>С# — 1205 ms (+/- 5)
CS>Хочу еще раз подчеркнуть что данное исследование не ставит целью ответить на глупый вопрос типа "кто лучше — папа или мама?" CS>А просто понять какие классы задач луше делать на каждой из платформ.
Ты считаешь, что различия в быстродействии в 1.5 — 2 раза критично для значительного числа задач?
Здравствуйте, VladD2, Вы писали:
VD>Теперь зайдем с другого конца. Возьмем тест на C#-е и попытаемся переписать его на С++ без ручных оптимизаций. Как бы поступил средний программист встань пред ним подобная задача? Да очень просто... он воспользовался бы готовым классом. B VC предоставляет нам такой класс — это CString. Его ATL-версия как раз имеет вариант CStringW (работающий с Юникодом). Переписываем тест:...
Для тех кто в танке повторяю. class NET.String is immutable. То же самое и в stl
StringBuilder же это то что называется динамический буфер оптимизированный в первую очередь для append.
Использовать для этой цели CString/String/std::string — это даже не "средний программист", это хуже.
Или ты хочешь сказать что C# только для средних программистов?
Т.е. не надо передергивать. Работаем с динамическим буфером.
Вот исходники C#::StringBuilder::Append
Пример на С++ повторяет это с точностью до политики переаллоцирования
newCapacity = ( currentString.Capacity)*2; // To force a predicatable growth of 160,320 etc. for testing purposes
Кстати судя по скобкам там была другая формула изначально.
// Appends a copy of this string at the end of this string builder.
/// <include file='doc\StringBuilder.uex' path='docs/doc[@for="StringBuilder.Append2"]/*' />public StringBuilder Append(String value) {
//If the value being added is null, eat the null
//and return.if (value==null) {
return this;
}
int tid;
// hand inlining of GetThreadSafeString
String currentString = m_StringValue;
tid = InternalGetCurrentThread();
if (m_currentThread != tid)
currentString = String.GetStringForStringBuilder(currentString, currentString.Capacity);
int currentLength = currentString.Length;
int requiredLength = currentLength + value.Length;
if (NeedsAllocation(currentString,requiredLength)) {
String newString = GetNewString(currentString,requiredLength);
newString.AppendInPlace(value,currentLength);
ReplaceString(tid,newString);
} else {
currentString.AppendInPlace(value,currentLength);
ReplaceString(tid,currentString);
}
return this;
}
private String GetNewString(String currentString, int requiredLength) {
int newCapacity;
requiredLength++; //Include the terminating null.if (requiredLength > m_MaxCapacity) {
throw new ArgumentOutOfRangeException(Environment.GetResourceString("ArgumentOutOfRange_NegativeCapacity"),
"requiredLength");
}
newCapacity = ( currentString.Capacity)*2; // To force a predicatable growth of 160,320 etc. for testing purposesif (newCapacity<requiredLength) {
newCapacity = requiredLength;
}
if (newCapacity> m_MaxCapacity) {
newCapacity = m_MaxCapacity;
}
if (newCapacity<=0) {
throw new ArgumentOutOfRangeException(Environment.GetResourceString("ArgumentOutOfRange_NegativeCapacity"));
}
return String.GetStringForStringBuilder( currentString, newCapacity);
}
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, alexkro, Вы писали:
A>>Здравствуйте, c-smile, Вы писали:
A>>А std::wstring не проверял? Кстати, компилятор надо бы поновее взять. Еще вопрос: этот примерчик можно заоптимизировать до смерти, но какой в том смысл?
CS>std::wstring как и String в С# — immutable classes — не предназначены для динамического склеивания строк.
Кто тебе сказал, что wstring is immutable? Ссылочку на стандарт пожалуйте.
CS>Собственно оптимизирования никакого не проводилось. Такая задача не стояла. CS>Наоборот — работать только штатными стандартными средствами платформы.
Зачем тогда свой наворот на C++ писать? Штатное стандартное средство C++ — wstring.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, VladD2, Вы писали:
VD>>но намного больше на работу конечного приложения влияет правильность выбора алгоритма и грамотность реализации этого алгоритма. VD>>Намек ясен?
IT>Говорил бы уж сразу — от радиуса кривизны
Здравствуйте, c-smile, Вы писали:
CS>StringBuilder же это то что называется динамический буфер оптимизированный в первую очередь для append. CS>Использовать для этой цели CString/String/std::string — это даже не "средний программист", это хуже.
CStringT конечно-же sucks для этой цели, если посмотреть на реализацию. Но вот насчет std::string ты ошибся.
CS>Или ты хочешь сказать что C# только для средних программистов?
Я почти уверен, что и C# версию можно достаточно соптимизировать. Кстати, вопрос на засыпку: чем определяется предел оптимизации для данного примерчика?
Здравствуйте, c-smile, Вы писали:
CS>Для тех кто в танке повторяю.
То есть для тебя самого, что ли?
CS> class NET.String is immutable.
Видимо System.String или просто string. Ну, так про него речь и идет.
CS> То же самое и в stl
Про него тоже.
CS>StringBuilder же это то что называется динамический буфер оптимизированный в первую очередь для append. CS>Использовать для этой цели CString/String/std::string — это даже не "средний программист", это хуже.
Как раз CString для этого подходит. На малых объемах он довольно эффективен.
CS>Или ты хочешь сказать что C# только для средних программистов?
На С++ тоже не боги работают. И писать свой класс из-за того что нужо сканкатирировать строки большинство людей не будет. Так что рельное приложение на С++ с большой долей вероятности окажется менее эффективной.
CS>Вот исходники C#::StringBuilder::Append
CS>Пример на С++ повторяет это с точностью до политики переаллоцирования
Ничего он не повторяет. Код не иквивалентен. В таких быстрых алгоритмах даже пара лишних инструкций или выравнивание кода уже резко влияет на резултат.
Тебе уже показали, что если твой код перекомпиляровать с оцией /clr (т.е. в сделать его менеджед), то разница получается незначительная.
PS
Итак, давай попробуем еще раз подумать насклько справедливы твои слова о том, что на дотнете нельзя создать конкурентно-спосбоного кода? Ведь даже если взять самые мрачные прогнозы (отстование дотнетного кода в два раза) особых проблем как-то не видно.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alexkro, Вы писали:
CS>>Собственно оптимизирования никакого не проводилось. Такая задача не стояла. CS>>Наоборот — работать только штатными стандартными средствами платформы.
A>Зачем тогда свой наворот на C++ писать? Штатное стандартное средство C++ — .
Изменил в этотм тесте класс на wstring. Результат получился 1478. Против 1520 у C#.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
. Все остальное работает очень быстро особенно с Валуе типами.
По поводу приведенных тестов то они не корректны так как компилятор оптимизирует такие тесты до нельзя, и сравнение с компонентами Net тоже не очень. Например свои аналоги могут работать в 1.5 — 2 раза быстрее на том же C#. Скажем так нетовские компоненты не очень, усреднены, но для массового использования вполне пригодны.
Но никто не учитывает фрагментацию памяти итд.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alexkro, Вы писали:
A>Я почти уверен, что и C# версию можно достаточно соптимизировать. Кстати, вопрос на засыпку: чем определяется предел оптимизации для данного примерчика?
Специализацией алгоритма и качеством инлайнинга методов. Остальные оптимизации у Шарпа и VC практически одинаковы.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
. Ну, а тепрь можно обсудить кто из нас в танке и что эффективнее:
std::string s3 = s2 + s1;
Или StringBuilder.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Вопрос слегка не в тему
От:
Аноним
Дата:
24.02.04 10:47
Оценка:
Если есть люди, которые долго писали на плюсах, а потом срочно перешли только на шарп.
Какие были впечатления? Не хочется ли обратно?)
Мне вот сейчас как раз это предстоит.
Тем что основной процент респондентов использует самые не эффектиные операции для конкатинации строк. Так что средняя программа на С++ с очень большой вероятностью окажетсая медленнее чем аналогичная на Шарпе. И все рассуждения об качестве оптимизации и ЖЦ идут лесом.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, <Аноним>, Вы писали:
А>Если есть люди, которые долго писали на плюсах, а потом срочно перешли только на шарп. А>Какие были впечатления? Не хочется ли обратно?) А>Мне вот сейчас как раз это предстоит.
Перейти обратно?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Undying, Вы писали:
U>Ты считаешь, что различия в быстродействии в 1.5 — 2 раза критично для значительного числа задач?
Хотя обращение и не ко мне, но тем не менее.
Речь идёт о _некоторых_ задачах. Так вот в этих _некоторых_ задачах (как html рендеринг) — быстродействие, несомненно, нужно и важно. Офигительно важно.
.
A>>А чем оно показательно?
VD>Тем что основной процент респондентов использует самые не эффектиные операции для конкатинации строк. Так что средняя программа на С++ с очень большой вероятностью окажетсая медленнее чем аналогичная на Шарпе. И все рассуждения об качестве оптимизации и ЖЦ идут лесом.
Вобще средней программе и не нужна большая производительнгость конкатенации (тем более в приведенном тобой примере std::string s3 = s2 + s1), выигрышь стринг билдера начинается когда конкатенаций много, правильно? (как и в примере)
В этом голосовании я проголосовал за класс string, но насамом деле я голосвал за шаблон basic_string (тогда я думал что ты это подразумевал), так вот, что мне мешает сделать свой трейт и переопределить для него оператор+ так как нужно (типа стринг билдера)? Причём я уверен что таких решений уже немеренно (хотя спорить не буду, у меня таких задач пока не возникало)
Здравствуйте, Аноним, Вы писали:
А>Если есть люди, которые долго писали на плюсах, а потом срочно перешли только на шарп. А>Какие были впечатления? Не хочется ли обратно?) А>Мне вот сейчас как раз это предстоит.
Лично я разумом понимаю, что использование шарпа здорово удешевляет проект.. но, хочу обратно на плюсы.. Что-то тут утеряно что ли Ну, не нравится мне шарп, хотя надо признать вещь весьма достойная. На твой вопрос вряд ли будет объективный ответ.
best regards..
Re[3]: Вопрос слегка не в тему
От:
Аноним
Дата:
25.02.04 09:11
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, <Аноним>, Вы писали:
А>>Если есть люди, которые долго писали на плюсах, а потом срочно перешли только на шарп. А>>Какие были впечатления? Не хочется ли обратно?) А>>Мне вот сейчас как раз это предстоит.
VD>Перейти обратно?
Ну нет как раз на шарпе писать. Конечно первое время наверно будет интересно и ново, но вот что потом, я не могу предположить)
Re[3]: Вопрос слегка не в тему
От:
Аноним
Дата:
25.02.04 09:18
Оценка:
Здравствуйте, voxel3d, Вы писали:
V>Здравствуйте, Аноним, Вы писали:
А>>Если есть люди, которые долго писали на плюсах, а потом срочно перешли только на шарп. А>>Какие были впечатления? Не хочется ли обратно?) А>>Мне вот сейчас как раз это предстоит.
V>Лично я разумом понимаю, что использование шарпа здорово удешевляет проект.. но, хочу обратно на плюсы.. Что-то тут утеряно что ли Ну, не нравится мне шарп, хотя надо признать вещь весьма достойная. На твой вопрос вряд ли будет объективный ответ.
V>best regards..
Ясно) Интересно, что у тебя за проект, и почему его решили на шарпе писать?) У меня у одного друга в фирме начали использовать .NET из-за легкости разработки UI. Вот это по-поему изврат.
У меня вроде что-то многуровневое и распределенное, наверно для этого и предполагается все это пользовать.
Здравствуйте, Dimentiy, Вы писали:
U>>Ты считаешь, что различия в быстродействии в 1.5 — 2 раза критично для значительного числа задач?
D>Речь идёт о _некоторых_ задачах. Так вот в этих _некоторых_ задачах (как html рендеринг) — быстродействие, несомненно, нужно и важно. Офигительно важно.
И как часто в жизни встречаются задачи подобные html рендерингу?
Тем более, что скорей всего html рендеринг будет сравнительно небольшой частью общей задачи, т.е. даже, если действительно шарп здесь будет проигрывать в два раза, то рендеринг можно будет написать на MC++ и использовать в качестве библиотеки, т.е. все равно никто не мешает использовать в качестве основного языка.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Dimentiy, Вы писали:
U>>>Ты считаешь, что различия в быстродействии в 1.5 — 2 раза критично для значительного числа задач?
D>>Речь идёт о _некоторых_ задачах. Так вот в этих _некоторых_ задачах (как html рендеринг) — быстродействие, несомненно, нужно и важно. Офигительно важно.
U>И как часто в жизни встречаются задачи подобные html рендерингу? U>Тем более, что скорей всего html рендеринг будет сравнительно небольшой частью общей задачи, т.е. даже, если действительно шарп здесь будет проигрывать в два раза, то рендеринг можно будет написать на MC++ и использовать в качестве библиотеки, т.е. все равно никто не мешает использовать в качестве основного языка.
Здравствуйте, naje, Вы писали:
U>>И как часто в жизни встречаются задачи подобные html рендерингу? U>>Тем более, что скорей всего html рендеринг будет сравнительно небольшой частью общей задачи, т.е. даже, если действительно шарп здесь будет проигрывать в два раза, то рендеринг можно будет написать на MC++ и использовать в качестве библиотеки, т.е. все равно никто не мешает использовать в качестве основного языка.
N>что это даст? N>почему сразу не полностью на C++?
Значительно более короткий срок разработки и более читабельный код, даже при более низкой квалификации разработчиков.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, naje, Вы писали:
N>>почему сразу не полностью на C++?
U>Значительно более короткий срок разработки и более читабельный код, даже при более низкой квалификации разработчиков.
это я и у микрософта читал только реальных подтверждений этому не видел
Здравствуйте, _MarlboroMan_, Вы писали:
_MM_>Здравствуйте, naje, Вы писали:
N>>это я и у микрософта читал только реальных подтверждений этому не видел
_MM_>"суслика видишь? нет? а он есть!" (с)
Здравствуйте, naje, Вы писали:
U>>Значительно более короткий срок разработки и более читабельный код, даже при более низкой квалификации разработчиков.
N>это я и у микрософта читал только реальных подтверждений этому не видел
А Хоум тебе чем не пример? Пишет его туева хуча разработчиков совершенно разной квалификации, контроль над которыми очень слабый, но при этом проект живет и развивается, при чем по крайней мере на моей памяти в нем не было ни одной серьезной ошибки.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, naje, Вы писали:
U>>>Значительно более короткий срок разработки и более читабельный код, даже при более низкой квалификации разработчиков.
N>>это я и у микрософта читал только реальных подтверждений этому не видел
U>А Хоум тебе чем не пример? Пишет его туева хуча разработчиков совершенно разной квалификации, контроль над которыми очень слабый, но при этом проект живет и развивается, при чем по крайней мере на моей памяти в нем не было ни одной серьезной ошибки.
Я хотел в качестве примера не проект (которых и на С++ достаточно), а особенность, которая сокращает сроки разработки и повышает читабельность.
Здравствуйте, naje, Вы писали:
N>Вобще средней программе и не нужна большая производительнгость конкатенации (тем более в приведенном тобой примере std::string s3 = s2 + s1), выигрышь стринг билдера начинается когда конкатенаций много, правильно? (как и в примере) N>В этом голосовании я проголосовал за класс string, но насамом деле я голосвал за шаблон basic_string (тогда я думал что ты это подразумевал),
Логично, чет побери. Нужно было упоминать о том что конкатинации массовые.
N>так вот, что мне мешает сделать свой трейт и переопределить для него оператор+ так как нужно (типа стринг билдера)? Причём я уверен что таких решений уже немеренно (хотя спорить не буду, у меня таких задач пока не возникало)
Тебе? Ничего. Только вот не факт, что выдет быстрее чем wstring, и не совсем не факт, что основная масса программистов вообще задумается об оптимизации.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, <Аноним>, Вы писали:
А>Ну нет как раз на шарпе писать. Конечно первое время наверно будет интересно и ново, но вот что потом, я не могу предположить)
А потом... поймешь, что все это долгое время когда ты писал на плюсах ты занимался бесплатным виртуальным сэксом (в простонародье трахом) и только тогда ты поймешь, как много ты потерял... ведь жизнь без секса — это скушно.
Если серьзено, то после обвыкания на плюсы обратно уже не тянет. Нехватает конечно кое-чего. Но со временем привыкаешь.
Правда я переходил не резко. Но на плюсах до этого писал лет 10.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, naje, Вы писали:
N>Я хотел в качестве примера не проект (которых и на С++ достаточно), а особенность, которая сокращает сроки разработки и повышает читабельность.
И ссылку можно на аналог Хоума?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, naje, Вы писали:
N>>Я хотел в качестве примера не проект (которых и на С++ достаточно), а особенность, N>>которая сокращает сроки разработки S>автоматическое управление памятью решает очень большую часть проблем
на С++ огромный выбор сборщикров мусора, но они редко когда нужны, смарт поинтеров хватает вполне
N>>и повышает читабельность. S>отсутствие ужасного разделения между декларацией и дефиницией, которое заставляет при чтении непрерывно прыгать между .cpp и .h
а вот это, насколько я знаю, оснавная фишка из-за которой многим кажется что с С# работать легче, впринципе можно считать плюсом (я не считаю по многим причинам, никогда даже стабгенами не пользовался никакими), но не настолько большим чтоб считать С# языком более высокого уровня чем С++
S>Это не все. Но уже достаточно чтобы понять, откуда и куда дует ветер.
давай ещё
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, naje, Вы писали:
N>>Я хотел в качестве примера не проект (которых и на С++ достаточно), а особенность, которая сокращает сроки разработки и повышает читабельность.
VD>И ссылку можно на аналог Хоума?
мне стыдно, но я не знаю замечательных особенностей Хоума, и я надеюсь мы не будем тут начинать мерятся проектами
можно сравнить один проект сделаный на С# и на C++
вот например boost::spirit и spart
плюс в этом же топике давали ссылочку здесь
покажи мне хоть один проект выполненный на С++ который бы при портировании на C# улучшился
Здравствуйте, naje, Вы писали: N>на С++ огромный выбор сборщикров мусора, но они редко когда нужны, смарт поинтеров хватает вполне
Основная беда сборщиков мусора на С++ — невозможность заставить ими пользоваться. Единственный способ убедиться в том, что программист случайно или намеренно не вывел объект из-под управления GC — тщательный просмотр кода. Все. Эту тему я дальше не обсуждаю. S>>отсутствие ужасного разделения между декларацией и дефиницией, которое заставляет при чтении непрерывно прыгать между .cpp и .h N>а вот это, насколько я знаю, оснавная фишка из-за которой многим кажется что с С# работать легче, впринципе можно считать плюсом (я не считаю по многим причинам, никогда даже стабгенами не пользовался никакими), но не настолько большим чтоб считать С# языком более высокого уровня чем С++
Еще раз: про уровень мы не говорим. Мы говорим про сокращение сроков разработки. N>давай ещё
А зачем?
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, naje, Вы писали: N>>на С++ огромный выбор сборщикров мусора, но они редко когда нужны, смарт поинтеров хватает вполне S>Основная беда сборщиков мусора на С++ — невозможность заставить ими пользоваться. Единственный способ убедиться в том, что программист случайно или намеренно не вывел объект из-под управления GC — тщательный просмотр кода. Все. Эту тему я дальше не обсуждаю.
очень даже возможно, всё очень даже контролируется, ладно тему закрыли
S>>>отсутствие ужасного разделения между декларацией и дефиницией, которое заставляет при чтении непрерывно прыгать между .cpp и .h N>>а вот это, насколько я знаю, оснавная фишка из-за которой многим кажется что с С# работать легче, впринципе можно считать плюсом (я не считаю по многим причинам, никогда даже стабгенами не пользовался никакими), но не настолько большим чтоб считать С# языком более высокого уровня чем С++ S>Еще раз: про уровень мы не говорим. Мы говорим про сокращение сроков разработки.
ну в данном примере помоему повышается только скорость набора кода, зато начинает страдать реюсабельность, но насчёт этого лучше не спорить наверное N>>давай ещё S>А зачем?
просто хочу для себя понять, чем так замечателен этот язык, я ж не думаю что из-за того что микрософт на заборе что-то написало (они же непогрешимы и непостежимы)
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, naje, Вы писали:
N>>покажи мне хоть один проект выполненный на С++ который бы при портировании на C# улучшился
AVK>Чтобы вкусить преимущества дотнета в полной мере проект надо не портировать, а переписывать.
ну объясни мне чем отличаются эти понятия
покажи мне хоть один проект выполненный на С++ который бы при переписывании на C# улучшился
Здравствуйте, voxel3d, Вы писали:
V> И вообще, я любил секс с непонятными глюками, дебаггер и профайлер были моими любимыми игрушками и я знал, что кроме меня баги никто победить не в состоянии будет,
правильный общий для всей команды стиль программирование победит всё
V> а здесь.. всё упростилось. Синтаксис изучил, с библиотекой классов ознакомился, всё. Идиомы гораздо проще.. Нету в шарпе духа, сдох он. И свободы в нём нет. Есть только один стиль написания программ -- правильный. Неинтересно. В С++ мои знания в глубину росли, а здесь я не понимаю вообще куда.. С шарпом с хорошим архитектором, очень умные программисты в 80% проектов не особо нужны бывают.. В С++ такой номер не прокатил бы..
в большинстве случаев получается всё не так просто,
как потом оказывается (в пресрелизах микрософт этого не пишут) шарп просто создаёт илюзию простоты и безопасности и читабельности (и я далеко не един в этом мнении)
когда это понимается в крупной конторе уже поздно уже работает сотня "средних" прграммистов, которые уже съели немеренно денег, а стоещего и не глючного так ничево и не сделали (у меня есть примеры)
Здравствуйте, naje, Вы писали:
N>как потом оказывается (в пресрелизах микрософт этого не пишут) шарп просто создаёт илюзию простоты и безопасности и читабельности (и я далеко не един в этом мнении)
Устойчивая, надо сказать иллюзия, если после 2-лет и нескольких мег исходников пока держится . Хуже того, продолжает усиливаться.
N>когда это понимается в крупной конторе уже поздно уже работает сотня "средних" прграммистов, которые уже съели немеренно денег, а стоещего и не глючного так ничево и не сделали (у меня есть примеры)
А у меня есть примеры когда сделали. Далеко ходить не надо — этот сайт, янус, RSDN NNTP.
Здравствуйте, naje, Вы писали: N>ну в данном примере помоему повышается только скорость набора кода, зато начинает страдать реюсабельность, но насчёт этого лучше не спорить наверное
Гм. Я не вижу, каким образом единственность места для написания кода уменьшит reusability.
N>просто хочу для себя понять, чем так замечателен этот язык, я ж не думаю что из-за того что микрософт на заборе что-то написало (они же непогрешимы и непостежимы)
Практика показывает очень значительный рост производительности труда программистов при использовании этого языка вместо традиционных. Особенно это касается компонентных приложений со слабо связанными частями. Какие усилия нужны для того, чтобы класс на С++ вынести в DLL? А сделать динамическое подключение классов-реализаций (plug-in)? А если они теперь должны выполняться на удаленной машине? А через фаерволл? Нынче это типовые задачи программирования.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, naje, Вы писали:
N>>как потом оказывается (в пресрелизах микрософт этого не пишут) шарп просто создаёт илюзию простоты и безопасности и читабельности (и я далеко не един в этом мнении)
AVK>Устойчивая, надо сказать иллюзия, если после 2-лет и нескольких мег исходников пока держится . Хуже того, продолжает усиливаться.
N>>когда это понимается в крупной конторе уже поздно уже работает сотня "средних" прграммистов, которые уже съели немеренно денег, а стоещего и не глючного так ничево и не сделали (у меня есть примеры)
AVK>А у меня есть примеры когда сделали. Далеко ходить не надо — этот сайт, янус, RSDN NNTP.
ну наверное там были не "средние" программисты
я не хотел сказать что на C# невозможно сделать что-то стоещее, просто это не так просто как описывается
Здравствуйте, Sinclair, Вы писали:
N>>просто хочу для себя понять, чем так замечателен этот язык, я ж не думаю что из-за того что микрософт на заборе что-то написало (они же непогрешимы и непостежимы) S>Практика показывает очень значительный рост производительности труда программистов при использовании этого языка вместо традиционных.
S> Особенно это касается компонентных приложений со слабо связанными частями. Какие усилия нужны для того, чтобы класс на С++ вынести в DLL? А сделать динамическое подключение классов-реализаций (plug-in)? А если они теперь должны выполняться на удаленной машине? А через фаерволл? Нынче это типовые задачи программирования.
Я все эти задачи решаю на С++(и не только я, и нет в этом ничево такого сложного и страшного, и здеся я говорю не про микрософтовские технологии), практика показывает большой рост производительности при создании реюсабельного кода, а как бы там ни было благодаря шаблонам и большой степени свободы С++ больше для этого подходит, связаность действительно сильной получается, но если захотеть то всё что есть в .net реализуется один раз а потом постоянно спользуется так же легко как и в .net (а может легче)
Да причём тут всё это? мы же языки сравниваем?
Скажи мне хоть одну действительно новую технологию которая есть в .net
только не надо говорить что .net объеденил все эти технологии, помоему это скорее минус т.к. отсутствует возможность выбора и быстрого перехода на какую-нибудь лучшую технологию (которая есть или будет (и придумает её может и микрософт)))
Здравствуйте, naje, Вы писали: N>покажи мне хоть один проект выполненный на С++ который бы при переписывании на C# улучшился
N>так нормально?
У-у-у... У нас этих проектов — как грязи. Если бы мы могли с самого начала пользоваться .Net (ASP.NET+ADO.NET+WinForms), то некоторые вещи стоили бы нам очень намного дешевле, а некоторые хотя бы начали бы работать правильно.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, naje, Вы писали: N>>покажи мне хоть один проект выполненный на С++ который бы при переписывании на C# улучшился
N>>так нормально? S>У-у-у... У нас этих проектов — как грязи. Если бы мы могли с самого начала пользоваться .Net (ASP.NET+ADO.NET+WinForms), то некоторые вещи стоили бы нам очень намного дешевле, а некоторые хотя бы начали бы работать правильно.
я ж тебе не разказываю про наши проекты, ты дай мне то на что посмотреть можно
Здравствуйте, naje, Вы писали: N>Да причём тут всё это? мы же языки сравниваем?
И? На С++ нельзя написать библиотеку, которая даст мне возможность двумя строчками кода опубликовать объект в сети. А на .Net не только можно, но она уже написана! N>Скажи мне хоть одну действительно новую технологию которая есть в .net
JIT, Metadata, User-Defined Metadata. Этого в С++ нет и быть не может. Некоторые из моментов поддаются эмуляции. Да и то она выглядит достаточно бледно по сравнению с тем, что есть в .Net. Одна возможность генерации кода на лету открывает совершенно новое измерение гибкости и комфорту.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, naje, Вы писали: N>>Да причём тут всё это? мы же языки сравниваем? S>И? На С++ нельзя написать библиотеку, которая даст мне возможность двумя строчками кода опубликовать объект в сети. А на .Net не только можно, но она уже написана!
можно N>>Скажи мне хоть одну действительно новую технологию которая есть в .net S>JIT, Metadata, User-Defined Metadata. Этого в С++ нет и быть не может. Некоторые из моментов поддаются эмуляции. Да и то она выглядит достаточно бледно по сравнению с тем, что есть в .Net. Одна возможность генерации кода на лету открывает совершенно новое измерение гибкости и комфорту.
Эти технологии придумал не микрософт, а я спрашивал именно про то что придумал микософт.
Одна возможность генерации кода на лету открывает совершенно новое измерение в генерации ошибок. Один из плюсов С++ это работа которая делается в ct, и ты узнаешь об ошибках когда компилируешь программку, а не когда на твою техподдержку звонит оч нервный и разгневанный пользователь и читает тебе цифорки из окошка эксепшина.
Metadata и User-Defined Metadata легко и ярко реализуются в С++, причём и генерацию кода можно сделать, только зачем?
по поводу JIT , я не пойму почему микрософт сделала такой упор на него, почему во всех системах в которых есть возможность JIT'а и VM, выбор делается в пользу VM, я в этом вопросе не специалист, может ты специалист, так расскажи
Здравствуйте, naje, Вы писали:
AVK>>А у меня есть примеры когда сделали. Далеко ходить не надо — этот сайт, янус, RSDN NNTP.
N>ну наверное там были не "средние" программисты
В случае януса были всякие.
N>просто это не так просто как описывается
Здравствуйте, naje, Вы писали: N>я ж тебе не разказываю про наши проекты, ты дай мне то на что посмотреть можно
А как я дам тебе взглянуть внутрь того, чего у меня нету? Я как-то не занимался анализом путей совершенствования opensource проектов при помощи перехода на .Net
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, naje, Вы писали:
N>>>просто это не так просто как описывается
AVK>>Ну то есть я тебя обманываю, так? Зачем?
N>где я тебя в чём обвинял?
Просто логический вывод. После моих слов о том что на шарпе проще создавать проекты вот эти слова:
N>я не хотел сказать что на C# невозможно сделать что-то стоещее, просто это не так просто как описывается
явно подразумевают что я тебя обманул.
N>я может даже хочу чтоб меня переубедили
А как тебя переубедить? Я привел тебе примеры готовых проектов. По результатам могу сказать что на .NET в целом удалось затратить заметно меньше усилий чем если бы эти проекты писались на С++ или Дельфи.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, naje, Вы писали:
N>>>>просто это не так просто как описывается
AVK>>>Ну то есть я тебя обманываю, так? Зачем?
N>>где я тебя в чём обвинял?
AVK>Просто логический вывод. После моих слов о том что на шарпе проще создавать проекты вот эти слова:
N>>я не хотел сказать что на C# невозможно сделать что-то стоещее, просто это не так просто как описывается
AVK>явно подразумевают что я тебя обманул.
я имел ввиду как описывается в пресрелизах микрософт
N>>я может даже хочу чтоб меня переубедили
AVK>А как тебя переубедить? Я привел тебе примеры готовых проектов. По результатам могу сказать что на .NET в целом удалось затратить заметно меньше усилий чем если бы эти проекты писались на С++ или Дельфи.
ну я хочу знать почему, какие такие особенности позволяют сделать такие выводы
сразу говорю что я не согласен что скорость разработки сильно увеличивает CLR, remouting, reflection (так сразу всё и не вспомню)
то что много чего переложено на рантайм помоему замедляет разработку приложения(ну и его производительность), конечно даёт кучу преимуществ, но зачем они все нужны? это всё похоже больше на дешёвые пряники которыми программистов заманивают в .net
Здравствуйте, naje, Вы писали:
N>я имел ввиду как описывается в пресрелизах микрософт
Ну пресс-релизы всегда "слегка" преувеличивают. Не только у МС.
N>ну я хочу знать почему, какие такие особенности позволяют сделать такие выводы
Там целый комплекс особенностей. В янусе скажем максимально удалось съэкономить благодаря метаданным и веб-сервисам, благодаря внятным и по месту сообщениям об ошибках.
N>сразу говорю что я не согласен что скорость разработки сильно увеличивает CLR, remouting, reflection (так сразу всё и не вспомню) N>то что много чего переложено на рантайм помоему замедляет разработку приложения(ну и его производительность), конечно даёт кучу преимуществ, но зачем они все нужны? это всё похоже больше на дешёвые пряники которыми программистов заманивают в .net
Ну что тут можно сказать. Практика показала что все это реально работает, естественно если уметь применять. Так что тут таки вопрос доверия — либо ты мне веришь, либо нет .
Здравствуйте, naje, Вы писали: N>можно
Неправда. В этом языке нет метаданных. Ты не сможешь сделать, например, маршалинг автоматически. Существующие для С++ решения опираются на инструменты автоматической генерации исходного кода. MIDL — suxx. N>>>Скажи мне хоть одну действительно новую технологию которая есть в .net S>>JIT, Metadata, User-Defined Metadata. Этого в С++ нет и быть не может. Некоторые из моментов поддаются эмуляции. Да и то она выглядит достаточно бледно по сравнению с тем, что есть в .Net. Одна возможность генерации кода на лету открывает совершенно новое измерение гибкости и комфорту.
N>Эти технологии придумал не микрософт, а я спрашивал именно про то что придумал микософт.
Ага, давай теперь вопрос подменять. Ты спрашивал совершенно конкретно — чего нет в С++, а есть в .Net. Я тебе ответил. Если тебе интересна история программирования — это не сюда. Это туда, где обсуждают, кто же таки изобрел радио — Попов или Маркони. N>Metadata и User-Defined Metadata легко и ярко реализуются в С++, причём и генерацию кода можно сделать, только зачем?
Нельзя там сделать генерацию кода. Вся генерация кода заканчивается в compile-time. Оставаясь в рамках языка, ты не сможешь генерировать в рантайме исполняемый код. А зачем — для перформанса, вестимо. Ты про частичные вычисления слышал? Гуглить по фамилии "Ершов". Смысл в том, что компилятор ограничен знаниями, которые у него есть. В рантайме можно получить дополнительную информацию для семантической оптимизации. В рамках С++ ее использовать нельзя — код представляет собой монолит, и подправить его не выйдет.
Про легко и ярко — ну я бы не сказал. Вон, в RSDN #5 есть статья "МЕтаданные своими руками". Ага. Эмуляция того, что встроено в .Net. Сложность и неудобство видны невооруженным взглядом. N>по поводу JIT , я не пойму почему микрософт сделала такой упор на него, почему во всех системах в которых есть возможность JIT'а и VM, выбор делается в пользу VM, я в этом вопросе не специалист, может ты специалист, так расскажи
Это про какие такие системы ты говоришь? Я вот не знаю ни одной системы, которая бы выбрала VM.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Kluev, Вы писали: K>Не так часто нужен маршаллинг, а когда нужен то ИМХО что-то типа MIDL в самый раз.
Э-э, парень... MIDL — сакс. После напишу почему. K>Зачем собирать мусор со всего света и тащить его в язык?. Лучше узкоспециализированные веши порешать специальными заточенными тулзами. Тады все будет ОК. И свобода выбора останется. Вдруг понадобятся тебе специализированные метаданные и упресся ты в то, что намертво в НЕТ зашито, тады сразу вспомнишь старые добрые плюсы.
Вот как раз для этого и сделали User-defined metadata! Так что лично я никогда не упрусь. K>В С++ тоже можно генерить код на лету. Таскай с собой бесплатный Ц-компилер. генери Ц-код, собирай в DLL грузи и выгружай. И не капассируй нам мозги про генерацию кода.
Ну щас прям. И сразу получи платформенную зависимость. Как минимум. А также необходимость таскать с собой запас хидеров для того, чтобы генеренный код мог взаимодействовать с другим кодом. В общем, ребята, солюшн с Ц-компилером даже на шутку не тянет. Потому его и не применяет никто и никогда. В отличие от той самой генерации кода в .Net.
K>Сложность где? Я вот идейку на вооружение взял, порешал то-что нужно и в макрос все завернул. Теперь добавляю в свои классцы по одной строчке на класс и не нарадуюсь. Все летает и гемороя не имею. И ограничений особых нет.
А что именно летает, позвольте спросить? Функционал какой?
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Kluev, Вы писали: K>>Не так часто нужен маршаллинг, а когда нужен то ИМХО что-то типа MIDL в самый раз. S>Э-э, парень... MIDL — сакс. После напишу почему.
Я имел ввиду не конкретную поделку от микровсоса, а сам способ. Можно и самому написать что нибудь подобное или выбрать между тем-же MIDL-СОМ или СОRBA и т.п.
S>Вот как раз для этого и сделали User-defined metadata! Так что лично я никогда не упрусь.
В С++ вообще все user-defined. Конечно метаданные как в НЕТ не сделаешь, но ИМХО и потребности нет.
K>>В С++ тоже можно генерить код на лету. Таскай с собой бесплатный Ц-компилер. генери Ц-код, собирай в DLL грузи и выгружай. И не капассируй нам мозги про генерацию кода. S>Ну щас прям. И сразу получи платформенную зависимость. Как минимум. А также необходимость таскать с собой запас хидеров для того, чтобы генеренный код мог взаимодействовать с другим кодом. В общем, ребята, солюшн с Ц-компилером даже на шутку не тянет. Потому его и не применяет никто и никогда. В отличие от той самой генерации кода в .Net.
В научной среде сплошь и к ряду, сам видел когда ишшо в институте учился. А чем плохо? быстродействие будет — закачаешься. А остальные проблемы при грамотном подходе и не проблеммы вообще. К тому же есть компилеры и кроссплатформенные.
А если быстродействие особое не нужно, то прикрутить скрипт-машину к плюсовой программе нет проблемм. Генери в скрипт и не жалуйся. ИМХО, надуманная проблемма вообще.
K>>Сложность где? Я вот идейку на вооружение взял, порешал то-что нужно и в макрос все завернул. Теперь добавляю в свои классцы по одной строчке на класс и не нарадуюсь. Все летает и гемороя не имею. И ограничений особых нет. S>А что именно летает, позвольте спросить? Функционал какой?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, naje, Вы писали: N>>можно S>Неправда. В этом языке нет метаданных. Ты не сможешь сделать, например, маршалинг автоматически. Существующие для С++ решения опираются на инструменты автоматической генерации исходного кода. MIDL — suxx.
я не имел ввиду idl, можно всё сделать на чистом С++ без тулзов кодогенерации, правда стиль програмирования будет похож на функциональный (но что в этом плохого, плохо что только похож) (кстати буква M в слове MIDL уже говорит о многом, у тебя всё замыкается на ms)
N>>>>Скажи мне хоть одну действительно новую технологию которая есть в .net S>>>JIT, Metadata, User-Defined Metadata. Этого в С++ нет и быть не может. Некоторые из моментов поддаются эмуляции. Да и то она выглядит достаточно бледно по сравнению с тем, что есть в .Net. Одна возможность генерации кода на лету открывает совершенно новое измерение гибкости и комфорту.
N>>Эти технологии придумал не микрософт, а я спрашивал именно про то что придумал микософт. S>Ага, давай теперь вопрос подменять. Ты спрашивал совершенно конкретно — чего нет в С++, а есть в .Net.
я спрашивал что нового в .Net, как вобще можно сравнивать язык с фреймворком?
S> Я тебе ответил. Если тебе интересна история программирования — это не сюда. Это туда, где обсуждают, кто же таки изобрел радио — Попов или Маркони.
причём тут это
я хотел скахать что ничево в .net выдающегося нет
N>>Metadata и User-Defined Metadata легко и ярко реализуются в С++, причём и генерацию кода можно сделать, только зачем? S>Нельзя там сделать генерацию кода. Вся генерация кода заканчивается в compile-time. Оставаясь в рамках языка, ты не сможешь генерировать в рантайме исполняемый код. А зачем — для перформанса, вестимо. Ты про частичные вычисления слышал? Гуглить по фамилии "Ершов". Смысл в том, что компилятор ограничен знаниями, которые у него есть. В рантайме можно получить дополнительную информацию для семантической оптимизации. В рамках С++ ее использовать нельзя — код представляет собой монолит, и подправить его не выйдет.
можно сделать, есть немеренно всяких промежуточных представлений для програм (это тоже не микрософтовская технология)
объясни чем могут помочь частичные вычисления в rt, это можно и в ct делать в большинстве случаев, именно для повышения производительности, не хочешь?, тогда спасёт компилятор с промежуточным представлением, но это не особенность языка, а мы обсуждаем C++ против C#
S>Про легко и ярко — ну я бы не сказал. Вон, в RSDN #5 есть статья "МЕтаданные своими руками". Ага. Эмуляция того, что встроено в .Net. Сложность и неудобство видны невооруженным взглядом. N>>по поводу JIT , я не пойму почему микрософт сделала такой упор на него, почему во всех системах в которых есть возможность JIT'а и VM, выбор делается в пользу VM, я в этом вопросе не специалист, может ты специалист, так расскажи S>Это про какие такие системы ты говоришь? Я вот не знаю ни одной системы, которая бы выбрала VM.
Не, мне интересны просто аналоги... Их наличие и возможности...
N>можно сравнить один проект сделаный на С# и на C++ N>вот например boost::spirit
Не вижу что тут сравнивать.
N> и spart
К сожалению не знаком с таковым.
N>плюс в этом же топике давали ссылочку здесь
Ну, то что это чушь тут тоже не раз говорилось. Там даже Ява быстрее дотнета, а это просто бред.
N>покажи мне хоть один проект выполненный на С++ который бы при портировании на C# улучшился
Портировании? Да на С++ просто нет сравнимых проектов.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, naje, Вы писали:
N>я ж тебе не разказываю про наши проекты, ты дай мне то на что посмотреть можно
Кстати, очень показательным примером является эволюция АСП. Первое АСП было написано на С/С++. АСП.НЭТ написано на Шарпе. При этом оно и работает быстрее, и функциональнее, и надежнее.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, c-smile, Вы писали:
CS>С++ - 1692 ms (+/- 10) CS>С# — 2433 ms (+/- 50)
Со строками несколько проблем. Их тип — (ANSI или UNICODE) и оптимизации всякие.
Потому результаты будут разные. Строки в шарпе очень хитрые, больше всего похожи... ни на что !!!
Это действительно так. Гляньте в исходники ротора и все будет видно.
Потому строки дотнетовские успешно конкурируют со строками в С++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, naje, Вы писали:
N>>мне стыдно, но я не знаю замечательных особенностей Хоума,
VD>Это не сложно: http://rsdn.ru/?janus/article/article.xml
N>> и я надеюсь мы не будем тут начинать мерятся проектами
VD>Не, мне интересны просто аналоги... Их наличие и возможности...
я никогда не занимался этим направлением
N>>можно сравнить один проект сделаный на С# и на C++ N>>вот например boost::spirit
VD>Не вижу что тут сравнивать.
N>> и spart
это генератор парсеров с ct, для того чтоб написать парсер не нужены кокоры, яки и бизоны, всё делается с ct (в варианте C++ конечно), таким же образом можно и idl заменить (вспоминался в этом топике), а на C# этого сделать нельзя, прийдётся ждать когда в С# встроят генератор парсеров
N>>плюс в этом же топике давали ссылочку здесь
VD>Ну, то что это чушь тут тоже не раз говорилось. Там даже Ява быстрее дотнета, а это просто бред.
так проверь, может и не чушь? напиши статью по этому поводу, как обманывают, враги
N>>покажи мне хоть один проект выполненный на С++ который бы при портировании на C# улучшился
VD>Портировании? Да на С++ просто нет сравнимых проектов.
И конечно все самые несравненные проекты на C# написал Ты.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, naje, Вы писали:
N>>я ж тебе не разказываю про наши проекты, ты дай мне то на что посмотреть можно
VD>Кстати, очень показательным примером является эволюция АСП. Первое АСП было написано на С/С++. АСП.НЭТ написано на Шарпе. При этом оно и работает быстрее, и функциональнее, и надежнее.
Здравствуйте, naje, Вы писали:
N>spart это переписанный boost::spirit
N>это генератор парсеров с ct, для того чтоб написать парсер не нужены кокоры, яки и бизоны, всё делается с ct (в варианте C++ конечно), таким же образом можно и idl заменить (вспоминался в этом топике), а на C# этого сделать нельзя, прийдётся ждать когда в С# встроят генератор парсеров
Понял. Ну, мне как-то коко больше нравится. И синтаксис по-чище и скорость приличная. А главное, писать на Шарпе неимеверно проще. Плюс почти нет отладки.
N>так проверь, может и не чушь? напиши статью по этому поводу, как обманывают, враги
Да и опыт работы и на там, и на другом. На плюсах пишу уже лет 10, на Шарпе два года (даже больше, с появления первой бэты).
N>И конечно все самые несравненные проекты на C# написал Ты.
Не все. Но аналог Хоума мы искали и ничего приличного не нашли. За то за время существования этого проекта сто раз слышали о том, как Вася Пупкин завтра перепишет его на: С++, Дельфи (нужное подчеркнуть/вписать). Но все эти слова так и остались словами.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, naje, Вы писали:
VD>>Хотел было что-то ответить, но умер со смежу. В общем, 5 балов... Я плякаль...
N>лично мне твоё психическое состояние знать совсем не интересно, это помоему форум не по той теме форум
Я как бы не тебе отвечал.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Теперь зайдем с другого конца. Возьмем тест на C#-е и попытаемся переписать его на С++ без ручных оптимизаций. Как бы поступил средний программист встань пред ним подобная задача? Да очень просто... он воспользовался бы готовым классом. B VC предоставляет нам такой класс — это CString. Его ATL-версия как раз имеет вариант CStringW (работающий с Юникодом). Переписываем тест:
Сравнивать нетовский стринг с CStringT (который уже потом CStringW) есть жульничество.
Нетовский стринг очень сильно отличается от CString, хоть и похож организацией данных.
Для конкатенации в нетовском стринге перегружено куча методов. На два аргумента, на три, на четыре и на мессив.
А что мы имеем в CStringT в этом случае?
Для компарации испоьзуется также особо хитрый механизм. А что с CStringT ?
Там вызывается ::CompareStringW исходный код которой на порядки!!! больше из за ее универсальности. Размер файла строкового АПИ в выне 132 килобайта.
Посему уместно сравнить нетовскую реализацию строк с такой же, выдраной из ротора, но на нативном С++.
Для этого надо взять и адаптировать файлы comstring.h и comstring.cpp. Из этих файлов выбросить весь лишний, читай нетовский, мусор и тогда, думаю, разница нас всех удивит.
Еще можно соптимизировать — развернуть циклы, как это делается в выне, на 8 итераций.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, naje, Вы писали:
N>>осталось только винду на шарпе переписать
VD>Будешь смеяться, но над этим уже работают.
VD>В Лонгхорне почти все новые АПИ будут на дотнете. И вообще огромная часть ОС станет менеджед.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, naje, Вы писали:
N>>spart это переписанный boost::spirit
N>>это генератор парсеров с ct, для того чтоб написать парсер не нужены кокоры, яки и бизоны, всё делается с ct (в варианте C++ конечно), таким же образом можно и idl заменить (вспоминался в этом топике), а на C# этого сделать нельзя, прийдётся ждать когда в С# встроят генератор парсеров
VD>Понял. Ну, мне как-то коко больше нравится. И синтаксис по-чище и скорость приличная. А главное, писать на Шарпе неимеверно проще. Плюс почти нет отладки.
а некоторым idl больше нравится (не мне)
на C++ если в ct побольше запихать то тоже отладчик не нужен будет
N>>так проверь, может и не чушь? напиши статью по этому поводу, как обманывают, враги
VD>Враги? А статья кое-какая давное есть: http://rsdn.ru/?summary/590.xml
VD>Да и опыт работы и на там, и на другом. На плюсах пишу уже лет 10, на Шарпе два года (даже больше, с появления первой бэты).
у меня опыт на шарпе маленький, могу поделится своим вариантом ощущений, ощущения можно сравнить с теми когда нужно что-то от руки написать, и когда психологически чуствуешь что на клавиатуре всё это можно написать быстрее и это немного напрягает
Здравствуйте, naje, Вы писали:
N>а некоторым idl больше нравится (не мне) N>на C++ если в ct побольше запихать то тоже отладчик не нужен будет
А если еще по больше, то и компьютер.
N>у меня опыт на шарпе маленький, могу поделится своим вариантом ощущений, ощущения можно сравнить с теми когда нужно что-то от руки написать, и когда психологически чуствуешь что на клавиатуре всё это можно написать быстрее и это немного напрягает
Это с непривычки.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Посему уместно сравнить нетовскую реализацию строк с такой же, выдраной из ротора, но на нативном С++. PE>Для этого надо взять и адаптировать файлы comstring.h и comstring.cpp. Из этих файлов выбросить весь лишний, читай нетовский, мусор и тогда, думаю, разница нас всех удивит.
Займись, удивись. Только учти, что прийдется не выбрасывать мусор, а добавлять.
PE>Еще можно соптимизировать — развернуть циклы, как это делается в выне, на 8 итераций.
Может просто сравнить с временем создания константы?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kluev, Вы писали: K>Я имел ввиду не конкретную поделку от микровсоса, а сам способ. Можно и самому написать что нибудь подобное или выбрать между тем-же MIDL-СОМ или СОRBA и т.п.
О боже. Я имел в виду как раз вообще концепцию IDL и промежуточные компиляторы. Стоимость подобного генератора для custom-задачи настолько высока, что их практически никогда не разрабатывают. Конечно, если ты работаешь в NASA, и решаешь сверхзадачи, то и С++ и .NET выглядят настолько маленькими, что можно сразу начинать писать свой язык — на финальную стоимость это почти не повлияет. Но мы-то живем в реальном мире! K>В С++ вообще все user-defined. Конечно метаданные как в НЕТ не сделаешь, но ИМХО и потребности нет.
Вот-вот. То же самое сорок лет назад говорили ассемблерщики про C. S>>Ну щас прям. И сразу получи платформенную зависимость. Как минимум. А также необходимость таскать с собой запас хидеров для того, чтобы генеренный код мог взаимодействовать с другим кодом. В общем, ребята, солюшн с Ц-компилером даже на шутку не тянет. Потому его и не применяет никто и никогда. В отличие от той самой генерации кода в .Net. K>В научной среде сплошь и к ряду, сам видел когда ишшо в институте учился. А чем плохо? быстродействие будет — закачаешься. А остальные проблемы при грамотном подходе и не проблеммы вообще. К тому же есть компилеры и кроссплатформенные.
Вот именно — в научной среде. Практического применения эта техника не имеет. От быстродействия я действительно закачаюсь. Сколько времени у меня займет компиляция нового класса в рантайме? Учитывая, что в него придется скормить тысяч двести строк хидеров? И не пойдет ли пользователь курить? Обрати внимание — в JSP и ASP применяют compile on demand. Как ты думаешь, почему не существует C++SP? K>А если быстродействие особое не нужно, то прикрутить скрипт-машину к плюсовой программе нет проблемм. Генери в скрипт и не жалуйся. ИМХО, надуманная проблемма вообще.
Ребята, это тупиковый подход. Прикручивание скрипт-машины к плюсовой программе имеет несколько существенных недостатков, основной из которых — высокая стоимость. K>Мультиметоды, в основном.
Тем не менее, трудоемкость прикручивания даже мультиметодов по сравнению с .Net слишком высока.
Короче, я никого не заставляю. .Net предлагает способ дешево делать хорошие программы. Альтернативы ему есть — та же Java. Более старые технологии позволяют делать либо хорошие, либо дешевые программы. Точка. Не хотите — не надо.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, naje, Вы писали: N>я не имел ввиду idl, можно всё сделать на чистом С++ без тулзов кодогенерации, правда стиль програмирования будет похож на функциональный (но что в этом плохого, плохо что только похож) (кстати буква M в слове MIDL уже говорит о многом, у тебя всё замыкается на ms)
Может я чего не знаю, но что-то я не вижу способа просто и изящно передать параметры маршалинга в С++ библиотеку в непроцедурном стиле. Как ты объяснишь, что вот этот параметр надо маршалить по ссылке, а этот — по значению? N>я спрашивал что нового в .Net, как вобще можно сравнивать язык с фреймворком?
Как хочешь — так и сравнивай. С++ тоже не только язык. Без стандартной библиотеки и рантайма он мертв. N>причём тут это N>я хотел скахать что ничево в .net выдающегося нет
Да. Внутри там то же самое что и в других системах. Это не серебряная пуля, это просто способ повысить производительность и качество труда программистов. N>можно сделать, есть немеренно всяких промежуточных представлений для програм (это тоже не микрософтовская технология)
Нету этого. Нету. Где оно? Покажите мне такую систему. Ни один из популярных компиляторов этого не умеет. А непопулярные — извините, ребята, низкое качество их кода съест все преимущества от специализации. N>объясни чем могут помочь частичные вычисления в rt, это можно и в ct делать в большинстве случаев, именно для повышения производительности, не хочешь?, тогда спасёт компилятор с промежуточным представлением, но это не особенность языка, а мы обсуждаем C++ против C#
Да нет проблем. Просто в C# делается все, что делается в .Net. В С++ этого нет. В нем нет делегатов, нет автоматического управления памятью, нет гарантий, что везде, где можно написать a<b можно написать и b>a, нет Reflection, нет модели безопасности, нет встроенной поддержки компонентности.
Да, все это можно эмулировать. Впрочем, наследование тоже можно эмулировать на С. Проблема в том, что в рамках С++ нельзя научить компилятор валидировать введенные пользователем правила. И из-за отсутствия рефлексии нельзя это сделать и в рантайме. Поэтому у Versant есть свой препроцессор, который проверяет persistent классы на целостность и генерирует метаданные. Но это фактически другой язык. В C# работу, выполняемую этим препроцессором, можно делать в рамках языка. См. Rsdn.Framework.Data. Почему-то никто не написал подобного для С++! N>>>по поводу JIT , я не пойму почему микрософт сделала такой упор на него, почему во всех системах в которых есть возможность JIT'а и VM, выбор делается в пользу VM, я в этом вопросе не специалист, может ты специалист, так расскажи N>погугли по JIT и VM (без microsoft и java)
Честно попробовал. Времени нет особо сканировать google. Тенденция ясна — слово Virtual Machine встречается в контексте либо распределенных вычислений, либо VMWare и прочих эмуляторов железа. Да, там где JIT недоступен, его не применяют. Ты можешь показать хоть на одну коммерчески применимую реализацию, в которой сознательно выбрали VM? Из двух известных мне систем обе выбрали JIT. Вообще говоря, уже этого достаточно для опровержения твоего всеобъемлющего утверждения. А поскольку исходная посылка неверна, вопрос придется снять.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, naje, Вы писали: N>>я не имел ввиду idl, можно всё сделать на чистом С++ без тулзов кодогенерации, правда стиль програмирования будет похож на функциональный (но что в этом плохого, плохо что только похож) (кстати буква M в слове MIDL уже говорит о многом, у тебя всё замыкается на ms)
по поводу idl S>Может я чего не знаю, но что-то я не вижу способа просто и изящно передать параметры маршалинга в С++ библиотеку в непроцедурном стиле. Как ты объяснишь, что вот этот параметр надо маршалить по ссылке, а этот — по значению?
что-то типа boost::tuples поможет?
N>>можно сделать, есть немеренно всяких промежуточных представлений для програм (это тоже не микрософтовская технология) S>Нету этого. Нету. Где оно? Покажите мне такую систему. Ни один из популярных компиляторов этого не умеет. А непопулярные — извините, ребята, низкое качество их кода съест все преимущества от специализации.
gcc не популярный компилятор? (gnu rtl даже в микрософтовских лекциях по созданию компиляторов на .net упоминается) N>>объясни чем могут помочь частичные вычисления в rt, это можно и в ct делать в большинстве случаев, именно для повышения производительности, не хочешь?, тогда спасёт компилятор с промежуточным представлением, но это не особенность языка, а мы обсуждаем C++ против C# S>Да нет проблем. Просто в C# делается все, что делается в .Net. В С++ этого нет. В нем нет делегатов, нет автоматического управления памятью, нет гарантий, что везде, где можно написать a<b можно написать и b>a, нет Reflection, нет модели безопасности, нет встроенной поддержки компонентности. S>Да, все это можно эмулировать. Впрочем, наследование тоже можно эмулировать на С. Проблема в том, что в рамках С++ нельзя научить компилятор валидировать введенные пользователем правила. И из-за отсутствия рефлексии нельзя это сделать и в рантайме. Поэтому у Versant есть свой препроцессор, который проверяет persistent классы на целостность и генерирует метаданные. Но это фактически другой язык. В C# работу, выполняемую этим препроцессором, можно делать в рамках языка. См. Rsdn.Framework.Data. Почему-то никто не написал подобного для С++!
какие правила? boost::concept_check поможет?
или это тоже другой язык?
по поводу других языков немного, я тут уже приводил пример с генераторами парсеров, когда генераторы парсеров появятся в C#?, это просто один из примеров
N>>>>по поводу JIT , я не пойму почему микрософт сделала такой упор на него, почему во всех системах в которых есть возможность JIT'а и VM, выбор делается в пользу VM, я в этом вопросе не специалист, может ты специалист, так расскажи N>>погугли по JIT и VM (без microsoft и java) S>Честно попробовал. Времени нет особо сканировать google. Тенденция ясна — слово Virtual Machine встречается в контексте либо распределенных вычислений, либо VMWare и прочих эмуляторов железа. Да, там где JIT недоступен, его не применяют. Ты можешь показать хоть на одну коммерчески применимую реализацию, в которой сознательно выбрали VM? Из двух известных мне систем обе выбрали JIT. Вообще говоря, уже этого достаточно для опровержения твоего всеобъемлющего утверждения. А поскольку исходная посылка неверна, вопрос придется снять.
комерческие реализации не ограничиваются этими двумя
впринципе наверное смог бы показать, но тоже времени особо нет, поэтому отложим
Здравствуйте, VladD2, Вы писали:
VD>Займись, удивись. Только учти, что прийдется не выбрасывать мусор, а добавлять.
PE>>Еще можно соптимизировать — развернуть циклы, как это делается в выне, на 8 итераций.
VD>Может просто сравнить с временем создания константы?
В виндовских исходниках частенько присутсвует оптимизация в таком и другом виде.
Здравствуйте, naje, Вы писали: N>что-то типа boost::tuples поможет?
Не вижу, как бы оно мне помогло. Какие параметры ты в этот Tuple передашь? Ты не мог бы мне привести пример пользовательского кода, в котором декларируется метод
class B {
A([MarshalAs(UnmanagedType.Int8)] int g)
{};
}
? Заодно было бы неплохо сравнить объем библиотечного кода, который надо написать для такого применения. S>>Нету этого. Нету. Где оно? Покажите мне такую систему. Ни один из популярных компиляторов этого не умеет. А непопулярные — извините, ребята, низкое качество их кода съест все преимущества от специализации. N>gcc не популярный компилятор? (gnu rtl даже в микрософтовских лекциях по созданию компиляторов на .net упоминается)
А что, в gcc я могу делать какое-то промежуточное представление, которое позволит мне в него вносить изменения в run-time и получать специфичный код? N>>>объясни чем могут помочь частичные вычисления в rt, это можно и в ct делать в большинстве случаев, именно для повышения производительности, не хочешь?, тогда спасёт компилятор с промежуточным представлением, но это не особенность языка, а мы обсуждаем C++ против C# N>какие правила? boost::concept_check поможет?
Не поможет. В его рамках нельзя потребовать отсутствия чего-либо. Да, можно потребовать приводимости типов, и поддержки операторов. Но нельзя запретить, например, иметь публичные поля заданного типа. N>по поводу других языков немного, я тут уже приводил пример с генераторами парсеров, когда генераторы парсеров появятся в C#?, это просто один из примеров
Гм. Я что-то пропустил этот постинг. При чем тут генераторы парсеров? Это же всего лишь приложения. Если я правильно понимаю, то тебе надо читать вот сюда Когда в С++ появятся RegExp, которые компиляются в КА при первом использовании? N>комерческие реализации не ограничиваются этими двумя N>впринципе наверное смог бы показать, но тоже времени особо нет, поэтому отложим
ok.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, naje, Вы писали: N>>что-то типа boost::tuples поможет? S>Не вижу, как бы оно мне помогло. Какие параметры ты в этот Tuple передашь? Ты не мог бы мне привести пример пользовательского кода, в котором декларируется метод S>
S>class B {
S> A([MarshalAs(UnmanagedType.Int8)] int g)
S> {};
S>}
S>
S>? Заодно было бы неплохо сравнить объем библиотечного кода, который надо написать для такого применения.
нихочу тебя ни в чём переубеждать да и времени нету, просто поверь у меня всё это работает, не на boost::tuples, но работает
S>>>Нету этого. Нету. Где оно? Покажите мне такую систему. Ни один из популярных компиляторов этого не умеет. А непопулярные — извините, ребята, низкое качество их кода съест все преимущества от специализации. N>>gcc не популярный компилятор? (gnu rtl даже в микрософтовских лекциях по созданию компиляторов на .net упоминается) S>А что, в gcc я могу делать какое-то промежуточное представление, которое позволит мне в него вносить изменения в run-time и получать специфичный код?
ну чтобы в rt надо с собой кусок gcc такскать, впринципе такая идея была, но потом победило мнение что ничево в rt не нужно N>>>>объясни чем могут помочь частичные вычисления в rt, это можно и в ct делать в большинстве случаев, именно для повышения производительности, не хочешь?, тогда спасёт компилятор с промежуточным представлением, но это не особенность языка, а мы обсуждаем C++ против C# N>>какие правила? boost::concept_check поможет? S>Не поможет. В его рамках нельзя потребовать отсутствия чего-либо. Да, можно потребовать приводимости типов, и поддержки операторов. Но нельзя запретить, например, иметь публичные поля заданного типа.
ну нельзя
а зачем?
единый стиль, по особому заданные публичные поля
и всё N>>по поводу других языков немного, я тут уже приводил пример с генераторами парсеров, когда генераторы парсеров появятся в C#?, это просто один из примеров S>Гм. Я что-то пропустил этот постинг. При чем тут генераторы парсеров? Это же всего лишь приложения. Если я правильно понимаю, то тебе надо читать вот сюда
Генераторы парсеров приложение, а вот парсеры уже можно сказать нет, да я и написал там только для примера, чтоб показать что всё на idl не заканчивается, и всего в язык всё-равно не впихнёшь S>Когда в С++ появятся RegExp, которые компиляются в КА при первом использовании?
а при втором? зачем их компилить в rt я не понимаю, если ты регэксп задаёшь в rt, то какая вераятность что он у тебя будет использоватся больше одного раза, и как часто они будут встречатся?, а если в ct то в ct всё оч даже компилится, туда куда надо, да и причём тут регэкспы (ты ссылку повтори пожалуста чтоб я смог прочитать то что мне надо), ты мне сейчас весь фреймворк перечислять будешь?
Здравствуйте, naje, Вы писали:
N>нихочу тебя ни в чём переубеждать да и времени нету, просто поверь у меня всё это работает, не на boost::tuples, но работает
Пиши статью Дело-то хорошее. Плюсы еще очень много где применимы. Так что best practices по ним завсегда нужны. N>ну чтобы в rt надо с собой кусок gcc такскать, впринципе такая идея была, но потом победило мнение что ничево в rt не нужно
Ага. Просто когда я все определяю в compile time, оно и без Runtime прекрасно работает. Нам не нужен кузнец, потому что нам не нужен кузнец. S>>Не поможет. В его рамках нельзя потребовать отсутствия чего-либо. Да, можно потребовать приводимости типов, и поддержки операторов. Но нельзя запретить, например, иметь публичные поля заданного типа. N>ну нельзя N>а зачем? N>единый стиль, по особому заданные публичные поля
- В C нельзя запретить прямое обращение к членам структуры, минуя функции-аксессоры.
— Ну нельзя. А зачем? Единый стиль, по особому заданные функции...
Ничего не напоминает? N>Генераторы парсеров приложение, а вот парсеры уже можно сказать нет, да я и написал там только для примера, чтоб показать что всё на idl не заканчивается, и всего в язык всё-равно не впихнёшь N>а при втором? зачем их компилить в rt я не понимаю, если ты регэксп задаёшь в rt, то какая вераятность что он у тебя будет использоватся больше одного раза, и как часто они будут встречатся?, N>а если в ct то в ct всё оч даже компилится, туда куда надо,
Да ну? Вот так прямо регекспы компиляются в CT? И все в рамках С++? N>да и причём тут регэкспы (ты ссылку повтори пожалуста чтоб я смог прочитать то что мне надо), ты мне сейчас весь фреймворк перечислять будешь?
Как причем? Если ты мне приводишь в качестве аргумента некие приложения, написанные на С++, и результаты их работы, то я тебе в ответ напишу библиотеки, написанные на C#, и результаты их использования.
А ссылка — вот здесь.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>О боже. Я имел в виду как раз вообще концепцию IDL и промежуточные компиляторы. Стоимость подобного генератора для custom-задачи настолько высока, что их практически никогда не разрабатывают.
Я сам лично разработал 2. Правда не для маршалинга. А насчет стоимости полная ерунда, если надо быстро и дешево то XML вполне подойдет. К тому-же можно заюзать готовые фичи типа autogen.
Конечно, если ты работаешь в NASA, и решаешь сверхзадачи, то и С++ и .NET выглядят настолько маленькими, что можно сразу начинать писать свой язык — на финальную стоимость это почти не повлияет. Но мы-то живем в реальном мире!
Реальный мир гораздо больше чем тебе кажется. Многие программы никогда не покидали стены учереждений где были разработаны. А многие настолько специализированны, что о них мало кто слышал. То что продается на рынке это только вершина айсберга. Наверное больше 80% софта закрыто для посторонних глаз.
K>>В С++ вообще все user-defined. Конечно метаданные как в НЕТ не сделаешь, но ИМХО и потребности нет. S>Вот-вот. То же самое сорок лет назад говорили ассемблерщики про C.
S>Вот именно — в научной среде. Практического применения эта техника не имеет. От быстродействия я действительно закачаюсь. Сколько времени у меня займет компиляция нового класса в рантайме? Учитывая, что в него придется скормить тысяч двести строк хидеров?
Одного хидера вполне хватит. Ты же не будешь генерить ГУЙ на лету? Это безумие. А какой-нибудь вычислительный алгоритм так скомпильнуть нет проблем. Потеряешь секунду на компиляции зато сэкономишь часы на расчете.
А в ненаучной среде я не вижу потребности в таких задачах. Может приведешь пример?
S> И не пойдет ли пользователь курить? Обрати внимание — в JSP и ASP применяют compile on demand. Как ты думаешь, почему не существует C++SP?
Потому что С++ это не скрипт язык. Все должно применятся там где это нужно.
K>>А если быстродействие особое не нужно, то прикрутить скрипт-машину к плюсовой программе нет проблемм. Генери в скрипт и не жалуйся. ИМХО, надуманная проблемма вообще. S>Ребята, это тупиковый подход. Прикручивание скрипт-машины к плюсовой программе имеет несколько существенных недостатков, основной из которых — высокая стоимость.
Какая такая стоимость? Я скрипт машину за неделю с нуля напишу, а уж готовую прикрутить. не вижу проблем вообще.
S>Короче, я никого не заставляю. .Net предлагает способ дешево делать хорошие программы. Альтернативы ему есть — та же Java. Более старые технологии позволяют делать либо хорошие, либо дешевые программы. Точка. Не хотите — не надо.
Либо позволяют делать программы которые на НЕТ ну никак. Все что интенсивно пользует память, все расчетные задачи, все задачи моделирования и проектирования не для НЕТ по определению
Здравствуйте, Kluev, Вы писали:
K>Какая такая стоимость? Я скрипт машину за неделю с нуля напишу, а уж готовую прикрутить. не вижу проблем вообще.
С этим кнечно все просто. Проблемы не со скрипт-машиной и ее прокручиванием.
Пролемы с отображением модели данных например в скрипт.
К слову — этиже пролемы есть и в шарпе. Причем очень хитрые, не сразу и догадаешься.
Кое какие ушли. Кое какие добавились. За счет экономии времени на написание кода и на отладку есть время обходить косяки дотнетовские.
K>Либо позволяют делать программы которые на НЕТ ну никак. Все что интенсивно пользует память, все расчетные задачи, все задачи моделирования и проектирования не для НЕТ по определению
Именно ! Мы поимели печальный опыт дотнета. Кастомер ппросил увеличить перформанс в два-три раза. От плюсовой версии, к примеру, все торчали.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, naje, Вы писали:
N>>нихочу тебя ни в чём переубеждать да и времени нету, просто поверь у меня всё это работает, не на boost::tuples, но работает S>Пиши статью Дело-то хорошее. Плюсы еще очень много где применимы. Так что best
practices по ним завсегда нужны.
та надо
S>
S>- В C нельзя запретить прямое обращение к членам структуры, минуя функции-аксессоры.
S>- Ну нельзя. А зачем? Единый стиль, по особому заданные функции...
S>Ничего не напоминает?
в С врядли получится генерить ct-ошибки, по каким-то семантическим правилам
S>Да ну? Вот так прямо регекспы компиляются в CT? И все в рамках С++?
, там правда не в автомат выражение собирается, но можно сделать чтоб в автомат, это пример просто чтоб показать что можно сделать.
N>>да и причём тут регэкспы (ты ссылку повтори пожалуста чтоб я смог прочитать то что мне надо), ты мне сейчас весь фреймворк перечислять будешь? S>Как причем? Если ты мне приводишь в качестве аргумента некие приложения, написанные на С++, и результаты их работы, то я тебе в ответ напишу библиотеки, написанные на C#, и результаты их использования.
сравнивать регулярные выражения и генератор парсеров?
это ж как бы разные как бы порядки (разницу между контестно свободными и регулярными языками знаешь?)
S>А ссылка — вот здесь.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Здравствуйте, Kluev, Вы писали:
PE>Именно ! Мы поимели печальный опыт дотнета. Кастомер ппросил увеличить перформанс в два-три раза. От плюсовой версии, к примеру, все торчали.
зря ты это сказал, щас они тебе начнут про радиус кривизны зачитывать,
я просто не знаю какой велечины должен быть специалист чтоб на нете нормальные проги писать
Здравствуйте, naje, Вы писали:
PE>>Именно ! Мы поимели печальный опыт дотнета. Кастомер ппросил увеличить перформанс в два-три раза. От плюсовой версии, к примеру, все торчали.
N>зря ты это сказал, щас они тебе начнут про радиус кривизны зачитывать, N>я просто не знаю какой велечины должен быть специалист чтоб на нете нормальные проги писать
Распределенные прилы, бызы данных, все, что свебов связано — запросто. А в ряде областей очень геморройно получается.
Но что выйдет в конце концов ? Пользователи будут ставить по 1гигу памяти и по 2 гигагерца процессор.
Первые, вторые, третьи пни отомрут. Четверные и пятые будут рулить. Но это со временем. А пока спрос неслабый на нативные прилы.
Дотнет нормально будет развиваться на 64х битах. Есть кастомеры, которым нужна совместимость с вынь95. Отчего ? А железо сложно обновить.
Здравствуйте, Kluev, Вы писали:
K>Реальный мир гораздо больше чем тебе кажется. Многие программы никогда не покидали стены учереждений где были разработаны. А многие настолько специализированны, что о них мало кто слышал. То что продается на рынке это только вершина айсберга. Наверное больше 80% софта закрыто для посторонних глаз.
Я совершенно с этим согласен. Просто я 5 лет работаю в Custom Software Development, и в нашем случае рулят скорость и цена разработки. Нету здесь ни огромного бюджета, как у Microsoft Office, ни бесконечного срока разработки, как в TeX. K>Одного хидера вполне хватит. Ты же не будешь генерить ГУЙ на лету? Это безумие. А какой-нибудь вычислительный алгоритм так скомпильнуть нет проблем. Потеряешь секунду на компиляции зато сэкономишь часы на расчете.
Гм. А чем будет пользоваться этот вычислительный алгоритм? Сколько весит хидер для библмотеки классов, которая ему нужна? K>А в ненаучной среде я не вижу потребности в таких задачах. Может приведешь пример?
Rsdn.Framework.Data подойдет? Там еще много есть куда копать. K>Потому что С++ это не скрипт язык. Все должно применятся там где это нужно.
Классное объяснение. А Java что — уже скрипт язык?
K>Какая такая стоимость? Я скрипт машину за неделю с нуля напишу, а уж готовую прикрутить. не вижу проблем вообще.
Очень интересно. Может так оно и есть.
S>>Короче, я никого не заставляю. .Net предлагает способ дешево делать хорошие программы. Альтернативы ему есть — та же Java. Более старые технологии позволяют делать либо хорошие, либо дешевые программы. Точка. Не хотите — не надо. K>Либо позволяют делать программы которые на НЕТ ну никак. Все что интенсивно пользует память, все расчетные задачи, все задачи моделирования и проектирования не для НЕТ по определению
Да. Действительно, это так.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>В виндовских исходниках частенько присутсвует оптимизация в таком и другом виде.
Те коды могли писаться сто лет назад или для платформ гед компилятор вообще оптимизаций не делает. В тестах же где итерации делаются для того чтобы уменьшить погрешность измерения разворот циклов — это нечесный хак.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, naje, Вы писали:
N>зря ты это сказал, щас они тебе начнут про радиус кривизны зачитывать, N>я просто не знаю какой велечины должен быть специалист чтоб на нете нормальные проги писать
А зачем? Вы похоже уже это усвоили.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Да никто и не спорит, что и С++ и даже С будут жить еще очень долго. Но с каждым годом системы вроде дотнета и явы будут совершенствоваться и вытеснять плюсы из все большего количества ниш.
Рассказы о приемуществах С++ в скорости сильно приувеличены. А со временем этих приемуществ вообще не будет. Если сравнить скорость VC и дотнета (C#) вресий 7.0, 7.1, 8.0, то невооруженным взглядом видно, что разрыв потихоничку сокращается. Да и не так он велик. Без проблем в алгоритмах масимальный проигрыш в 2 раза. Если же учесть простоту и скорость разработки на дотнете, то становится понятно, что проще экономить время и тратить деньги на железо. Ну, а если учесть, что аысвободившееся время можно потратить на оптимизацию алгоритмов...
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kluev, Вы писали:
K>Автоматическое управление памятью — это фатальный недостаток НЕТ. Программы которые манипулируют одновременно около 100000 обьектами связанными в сеть, писать на НЕТ просто нет смысла.
100000? Я когда грид отлаживал как раз дерево из этго количества строил. Загружается молниеносно.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>JIT, Metadata, User-Defined Metadata. Этого в С++ нет и быть не может. Некоторые из моментов поддаются эмуляции. Да и то она выглядит достаточно бледно по сравнению с тем, что есть в .Net. Одна возможность генерации кода на лету открывает совершенно новое измерение гибкости и комфорту.
Ну почему, не может. Никаких принципиальных трудностей реализовать и компиляцию в IL, и генерацию метаданных нет. Да, собственно говоря, а что такое C++/CLI?
Здравствуйте, Шахтер, Вы писали:
Ш>Например, на алгоритм сортировки. Или на алгоритм сложения 2 и 2.
В дотнете та же сортировка для структур по умолчанию никуда не годиться. А если она используется в узком месте, то можно ускорить приложение в разы.
Но можно конечно фигней не заниматься. Взять С++ и все начнет летать сама. На фиг алгоритмы, безопастность... Можно же биты двигать...
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: C++ versus C#
От:
Аноним
Дата:
28.02.04 12:48
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, naje, Вы писали:
VD>Так он на Шарп портирован. Ты ведь вроде спрашивал есть ли генераторы на Шарпе. Или ты том же самом на шаблонах?
сам генератор, это уж не такая сапер штука, фишка именно в том же самом
VD>Кстати, вот добьем R# поглядим у кого больше гибкость.
давай вы напишите, а потом смотреть будем
я это время лучше потрачу на оптимизацию алгоритмов
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, naje, Вы писали:
VD>>Так он на Шарп портирован. Ты ведь вроде спрашивал есть ли генераторы на Шарпе. Или ты том же самом на шаблонах? А>сам генератор, это уж не такая сапер штука, фишка именно в том же самом
VD>>Кстати, вот добьем R# поглядим у кого больше гибкость.
А>давай вы напишите, а потом смотреть будем А>я это время лучше потрачу на оптимизацию алгоритмов
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Sergey, Вы писали:
S>>Последний — замечательный пример Чаще не работает, чем работает.
VD>Да уж ННТП у нас еще та бяка.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Kluev, Вы писали:
K>>Автоматическое управление памятью — это фатальный недостаток НЕТ. Программы которые манипулируют одновременно около 100000 обьектами связанными в сеть, писать на НЕТ просто нет смысла.
VD>100000? Я когда грид отлаживал как раз дерево из этго количества строил. Загружается молниеносно.
Загружается всегда молниеносно, Этим никого не озадачишь. Попробуй протестировать постоянно добавляя и удаля узлы из дерева. Самое смешно начнется когда забудешь где нибудь ссылку обнулить. А ведь структуры могут быть очень сложными. ИМХО в задачах где интенсивно используются (перестраиваются) деревья, графы, сети и т.р. сборка мусора является проклятьем.
Здравствуйте, VladD2, Вы писали:
PE>>В виндовских исходниках частенько присутсвует оптимизация в таком и другом виде.
VD>Те коды могли писаться сто лет назад или для платформ гед компилятор вообще оптимизаций не делает. В тестах же где итерации делаются для того чтобы уменьшить погрешность измерения разворот циклов — это нечесный хак.
При чем здесь тесты ? Строковые операции — сравнение, конкатенация, длина и тд очень сильно влияют на производительность прилаги. Так что тут раскручивание цикла имеет смысл.
Процессоры нынче не умееют предсказываться ветвления на 100%. Частичный разворот цикла дает неслабый прирост на маленьких строках, коих большинство.
Здравствуйте, VladD2, Вы писали:
VD>Рассказы о приемуществах С++ в скорости сильно приувеличены. А со временем этих приемуществ вообще не будет. Если сравнить скорость VC и дотнета (C#) вресий 7.0, 7.1, 8.0, то невооруженным взглядом видно, что разрыв потихоничку сокращается. Да и не так он велик. Без проблем в алгоритмах масимальный проигрыш в 2 раза. Если же учесть простоту и скорость разработки на дотнете, то становится понятно, что проще экономить время и тратить деньги на железо. Ну, а если учесть, что аысвободившееся время можно потратить на оптимизацию алгоритмов...
В 2 раза. На плюсах наши алгоритмы работали и от нескольких дней до двух неделью В два раза это от недели до месяца. Очень хороший подход.
Железо реального преимущества не даст. ПО и так дорогое, а с железом его и купить то будет некому. Сколько памяти не ставь — два гигабайта на процесс это мало для дотнета.
PE>В 2 раза. На плюсах наши алгоритмы работали и от нескольких дней до двух неделью В два раза это от недели до месяца. Очень хороший подход.
2 — это самый худший случай. К тому же просто уверен, что скорость болеш зависит от качества проработки алгоритмов. За счет упрощения реализации и ускорения ее создания ты можешь потратить лишние деньги на новый сервер(ы), а время на прспараллеливание.
PE>Железо реального преимущества не даст.
Это почему? У вас все до одного вычисления последовательны?
PE> ПО и так дорогое, а с железом его и купить то будет некому. Сколько памяти не ставь — два гигабайта на процесс это мало для дотнета.
С чего ты это взял?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kluev, Вы писали:
K>Гы. плюсы тоже не стоят на месте. У плюсов нет единой библиотеки на разные случаи жизни. Все приходится по миру собирать. Это основная трудность. Было-бы что-нибудь типа QT нахаляву, тогда народ с плюсов выманить было-бы невозможно. А если появится многие вернутся обратно.
QT стоит не дорого. И те кто его купили далеки от восторга. С ВинФормс — это точто сравнить нельзя.
VD>>Рассказы о приемуществах С++ в скорости сильно приувеличены. А со временем этих приемуществ вообще не будет.
K>Будут всегда.
Ошибаещся.
K> Сборка мусора всегда будет тянуть НЕТ на дно.
А это ничего, что ЖЦ в Яве работает не медленнее чем стандартные хипы С++?
K> От этого никуда не деться.
Ты алгоритм ЖЦ знаешь? Что в нем может потенциально быть проблемным?
K> Может далеть UI на НЕТ-е и просто, но работать со сложными структурами я бы на нем не стал.
Что есть сложные структуры?
K>Смотря на чем сравнивать.
Да на тех самых повседневных задачах. Именно за них идет бой. А супер навороты для мэйнфрэймов и сейчас на Фортране зачастую делают.
K>Алгоритмы уже проблема. Возьми любую нетривиальную задачу — триангуляция поверхности, разбиение обьема и т.п.
Ну, эти задачи уже давно в акселераторы зашиты. Но все равно потенциально проблем с их рассчетом на менеджед-языках нет.
K> То что такие вещи неудобно делать с автоматической сборкой мусора, в языке без адрессной арифметики (или с образаной арифметикой), и без возможностей прочего хака ясно как дважды два четыре.
А я вот так не считаю. И интересно было бы услышать обоснование последнего утверждения.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>В 2 раза. На плюсах наши алгоритмы работали и от нескольких дней до двух неделью В два раза это от недели до месяца. Очень хороший подход. PE>Железо реального преимущества не даст. ПО и так дорогое, а с железом его и купить то будет некому. Сколько памяти не ставь — два гигабайта на процесс это мало для дотнета.
Да, кстати... а ты не задумывался на тему, что выбрав неверную фунцию или компилятор (который идеален, но вот одна комбинация, встречающаяся у тебя в узких местах, тормозная) можно проиграть в скорости и больше чем в два раза?
Заметь, старый код был в основном быстрее современного. Но компиляторы то с тех пор стали только быстрее.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Из чего загружается ? Попробуй загрузить 100'000 объектов, которые указывают друг на друга, по пять-десять пропертей, из файла.
Комик, блин. Какая разница откуда грузить? Хотя загрузка ста тысяч объектов из файла по одному — это уже нехилая операция.
Короче, вот результаты теста не 100 тысяч объектов, а для 100 00 000 (ста миллионов):
C:\MyProjects\hreh\GcTest1\GcTest1\bin\Release>GcTest1.exe
Ver 1.1.4322.573
Iteration count 10000000
Start test 1 (simple list)...Finish test 1. Elapsed time is 0.2884803
GC for test 1 ...Finish GC for test 1. Elapsed time is 0.000477435
Start test 2 ...Finish test 2. Elapsed time is 0.5040096
GC for test 2 ...Finish GC for test 2. Elapsed time is 0.02037103
А вот, сам код:
using System;
class A
{
public A ref1;
public A ref2;
public A ref3;
public A ref4;
public A ref5;
}
class Class1
{
const int iterCount = 10000000;
static void Test1()
{
PerfCounter timer = new PerfCounter();
Console.Write("Start test 1 (simple list)...");
timer.Start();
A root;
A curr = root = new A();
for (int i = 0; i < iterCount; i++)
{
curr.ref1 = new A();
curr.ref1 = curr;
}
Console.WriteLine("Finish test 1. Elapsed time is {0}", timer.Finish());
}
static void Test2()
{
PerfCounter timer = new PerfCounter();
Console.Write("Start test 2 ...");
timer.Start();
A root;
A curr = root = new A();
for (int i = 0; i < iterCount; i++)
{
A tmp1 = new A();
curr.ref1 = tmp1;
curr.ref1 = curr;
tmp1 = curr.ref1.ref1;
if (tmp1 != null)
{
tmp1.ref2 = curr;
tmp1 = tmp1.ref1;
if (tmp1 != null)
{
tmp1.ref3 = curr;
tmp1 = tmp1.ref1;
if (tmp1 != null)
{
tmp1.ref4 = curr;
tmp1 = tmp1.ref1;
if (tmp1 != null)
{
tmp1.ref5 = curr;
tmp1 = tmp1.ref1;
}
}
}
}
}
Console.WriteLine("Finish test 2. Elapsed time is {0}", timer.Finish());
}
static void GcTime(int testNum)
{
PerfCounter timer = new PerfCounter();
Console.Write("GC for test {0} ...", testNum);
timer.Start();
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
Console.WriteLine("Finish GC for test {1}. Elapsed time is {0}",
timer.Finish(), testNum);
}
static void Main(string[] args)
{
Console.WriteLine("Ver " + Environment.Version.ToString());
Console.WriteLine("Iteration count {0}", iterCount);
for (int i = 0; i < 10000; i++)
;
Test1();
GcTime(1);
for (int i = 0; i < 10000; i++)
;
Test2();
GcTime(2);
//Console.ReadLine();
}
}
Здравствуйте, Kluev, Вы писали:
K>Загружается всегда молниеносно, Этим никого не озадачишь. Попробуй протестировать постоянно добавляя и удаля узлы из дерева. Самое смешно начнется когда забудешь где нибудь ссылку обнулить. А ведь структуры могут быть очень сложными. ИМХО в задачах где интенсивно используются (перестраиваются) деревья, графы, сети и т.р. сборка мусора является проклятьем.
Ты знаешь? Пробовал... Нельзя сказать, что у дотнета в этих задачах приемущество, но и серьезных недостатков нет.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>При чем здесь тесты ? Строковые операции — сравнение, конкатенация, длина и тд очень сильно влияют на производительность прилаги. Так что тут раскручивание цикла имеет смысл. PE>Процессоры нынче не умееют предсказываться ветвления на 100%. Частичный разворот цикла дает неслабый прирост на маленьких строках, коих большинство.
Притом, что речь шла о тестах. И в них расрутка (елси сам цикл сделан для увеличения объемов вычислений) — это нечестныое сравнение. На практике раскрутка может и замедлить скорость алгоритма. Погдяди второго шустрика. Там как раз был gcc с раскруткой и без.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, naje, Вы писали:
N>а чё такое, нет в нете ннтп? N>обыдно, да?
В нете? А в С++ есть?
Речь идет о нашем ННТП-сервере написанном нами же для нас же. Жрет сабака время и память. Ну, да это просто не очень качественная реализация. Тот же Хоум раядом ведет себя очень прилично.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
K>> Сборка мусора всегда будет тянуть НЕТ на дно. VD>А это ничего, что ЖЦ в Яве работает не медленнее чем стандартные хипы С++?
Когда задача очень большая, то и хип нам не друг. В таких случаях делается пул и хип и ГЦ остаются далеко позади. Никакой ГЦ не сможет работать быстрее чем пул. Особенно в стрессовых условиях: ведь программа может легко работать несколько дней подряд, а в ГЦ я слышал что если обьект пережил пару сборок мусора то он уже не удаляется никогда.
В С++ оператор new перегрузил, перевел обьект из хипа в пул и вот уже перфоманс совсем другой, а что в жаве или в НЕТе делать будем? Наверное на С++ переписывать будем
VD>Ты алгоритм ЖЦ знаешь? Что в нем может потенциально быть проблемным?
Представь что программа на каждой итерации создает и освобождает ~200К обьектов. Частично или полностью (перестройка сетки). В обьектах от 10 до 30 указателей. Т.е. структура весьма ветвистая. Пул отрабатывает мгновенно. Хип, не спорю будет тормозить. А как ГЦ будет себя вести?
VD>Ну, эти задачи уже давно в акселераторы зашиты. Но все равно потенциально проблем с их рассчетом на менеджед-языках нет.
Далеко не все. Для С++ еще полным-полно работы. Может клиента БД на нем и нет смысла писать, но есть и другие программы. Можешь показать хотя-бы один CAD написаный на яве или на шарпе?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Kluev, Вы писали:
K>>Загружается всегда молниеносно, Этим никого не озадачишь. Попробуй протестировать постоянно добавляя и удаля узлы из дерева. Самое смешно начнется когда забудешь где нибудь ссылку обнулить. А ведь структуры могут быть очень сложными. ИМХО в задачах где интенсивно используются (перестраиваются) деревья, графы, сети и т.р. сборка мусора является проклятьем.
VD>Ты знаешь? Пробовал... Нельзя сказать, что у дотнета в этих задачах приемущество, но и серьезных недостатков нет.
Деревья, графы, сети на дотнете превращаются в сплошной геморрой. Степень геморроя пропорциооняльна среднему количесву референсов на объект.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Plutonia Experiment, Вы писали:
PE>>Из чего загружается ? Попробуй загрузить 100'000 объектов, которые указывают друг на друга, по пять-десять пропертей, из файла.
VD>Комик, блин. Какая разница откуда грузить? Хотя загрузка ста тысяч объектов из файла по одному — это уже нехилая операция.
VD>Короче, вот результаты теста не 100 тысяч объектов, а для 100 00 000 (ста миллионов):
Я кидал ссылку про O(n**2) поведение мультикастделегата. При десерилизации происходит затык при рассылке OnDeserilizationCallback. 50000 — еще реально ждать. 100000 — уже нет.
Возьми и пощупай сам. А та синтетика, которую ты здесь показал, никакого отношения к сетям не имеет.
VD>
VD>C:\MyProjects\hreh\GcTest1\GcTest1\bin\Release>GcTest1.exe
VD>Ver 1.1.4322.573
VD>Iteration count 10000000
VD>Start test 1 (simple list)...Finish test 1. Elapsed time is 0.2884803
VD>GC for test 1 ...Finish GC for test 1. Elapsed time is 0.000477435
VD>Start test 2 ...Finish test 2. Elapsed time is 0.5040096
VD>GC for test 2 ...Finish GC for test 2. Elapsed time is 0.02037103
VD>
Здравствуйте, VladD2, Вы писали:
VD>Да, кстати... а ты не задумывался на тему, что выбрав неверную фунцию или компилятор (который идеален, но вот одна комбинация, встречающаяся у тебя в узких местах, тормозная) можно проиграть в скорости и больше чем в два раза?
Узкие места целиком и полностью в дотнете и Шарпе.
VD>Заметь, старый код был в основном быстрее современного. Но компиляторы то с тех пор стали только быстрее.
Вот когда будет релиз шарпа с дженериками, тогда можно будет посмотреть. А пока мы зашли в тупик. Оптимизировать уже нечего...
Здравствуйте, VladD2, Вы писали:
PE>>При чем здесь тесты ? Строковые операции — сравнение, конкатенация, длина и тд очень сильно влияют на производительность прилаги. Так что тут раскручивание цикла имеет смысл. PE>>Процессоры нынче не умееют предсказываться ветвления на 100%. Частичный разворот цикла дает неслабый прирост на маленьких строках, коих большинство.
VD>Притом, что речь шла о тестах. И в них расрутка (елси сам цикл сделан для увеличения объемов вычислений) — это нечестныое сравнение. На практике раскрутка может и замедлить скорость алгоритма. Погдяди второго шустрика. Там как раз был gcc с раскруткой и без.
Шустрики смотреть неинтересно, ибо реальные замеры на наших аппликациях показывают совсем не то.
Здравствуйте, VladD2, Вы писали:
PE>>Из чего загружается ? Попробуй загрузить 100'000 объектов, которые указывают друг на друга, по пять-десять пропертей, из файла.
VD>Комик, блин. Какая разница откуда грузить? Хотя загрузка ста тысяч объектов из файла по одному — это уже нехилая операция.
Нехилая — очень емкное слово. Главное понять, что под этим подразумевается.
Вот ответ на причину тормозов при десерилизации. Это проблемы дотнета, возможно ее пофиксят.
Но есть масса других проблем — стато мелких поросят.
using System;
namespace ConsoleApplication1
{
class TestClass
{
public static int count = 0;
public static DateTime t0;
public delegate void EventHandler(int i);
public event EventHandler OnEvent;
public void OnEventOccured(int i)
{
}
static void Main(string[] args)
{
new TestClass().TestMethode();
}
public void TestMethode()
{
// Try different values; performance hits the ceiling
// for > 15000for(int j=0; j<100000; ++j)
{
OnEvent += new EventHandler(OnEventOccured);
}
t0 = DateTime.Now;
OnEvent(1);
// Total elapsed
Console.WriteLine( "Time : " + (DateTime.Now - t0) );
Console.ReadLine();
}
}
}
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Узкие места целиком и полностью в дотнете и Шарпе.
А мне кажется в основном в руках и головах.
PE>Вот когда будет релиз шарпа с дженериками, тогда можно будет посмотреть. А пока мы зашли в тупик. Оптимизировать уже нечего...
Вы — возможно. Я — нет. Дженерики это конечно удобно. И кое где они позволят более просто создавать более эффектиные алгоритмы, но и сейчас можно писать очень даже эффективный код.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kluev, Вы писали:
K>Когда задача очень большая, то и хип нам не друг.
И есть документальное подтверждение на которое можно дать ссылку?
K> В таких случаях делается пул и хип и ГЦ остаются далеко позади.
Да качественный ЖЦ и есть по сути пул.
K> Никакой ГЦ не сможет работать быстрее чем пул.
Согласен, но велика ли разница? И так ли часто ты пользуешся пулом и другими тонкими оптимизациями?
K> Особенно в стрессовых условиях: ведь программа может легко работать несколько дней подряд, а в ГЦ я слышал что если обьект пережил пару сборок мусора то он уже не удаляется никогда.
Удаляется... если памяти нехватает и если на объект нет ссылок. А если хватает, то ради чего его удалять? Чтобы процессор занять?
K>В С++ оператор new перегрузил, перевел обьект из хипа в пул и вот уже перфоманс совсем другой, а что в жаве или в НЕТе делать будем?
Код прикладной писать. А производительность ЖЦ проблемы МС и Сана. Если уж очень нужно, то в дотнете можно пользоваться структурами и хранить их в массиве. Считай тот же пул.
K> Наверное на С++ переписывать будем
Ни разу пока не нужно было. Но если я пийду к выводу, что на С++ я смогу ускорить ту или иную часть приложения и это действительно нужно, то я сделаю это не задумываясь. А почему бы и нет? Но ради скорости одного-двух фрагментов кода тратить столько сил и времени... зачем?
VD>>Ты алгоритм ЖЦ знаешь? Что в нем может потенциально быть проблемным? K>Представь что программа на каждой итерации создает и освобождает ~200К обьектов.
Это очень выгодный для ЖЦ сценарий. Дон Бокс даже демонстрировал приемущества ЖЦ над хипом С++ создавайя в цикле объект и уничтожая его.
K> Частично или полностью (перестройка сетки). В обьектах от 10 до 30 указателей. Т.е. структура весьма ветвистая. Пул отрабатывает мгновенно. Хип, не спорю будет тормозить. А как ГЦ будет себя вести?
В ЖЦ есть специальные оптимизации на такой случай. Все эти объекты попадут в первое поколение и будут очень эффективно освобождены. Причем тогда когда процессор будет свободен, ане во время алгоритма.
Да и все разговоры о пуле — это теория. На практике осннвные массы таких фич не используют. И выходит не быстрее чем с ЖЦ.
K>Далеко не все. Для С++ еще полным-полно работы.
Для ассемблера тоже в принципе есть. Вот только дорого его использовать.
K> Может клиента БД на нем и нет смысла писать, но есть и другие программы. Можешь показать хотя-бы один CAD написаный на яве или на шарпе?
А сколько нужно писать КАД? И сколько контор этим занимется? Дотнет то всего два года как вылупился. Погу показать примеры от D3D 9. Там есть примеры как на Шарпе, так и на анменеджед-С++. Разницы никакой. Так что делать можно. И когда нибудь сделают. Другое дело, что из-за того, что переписывать море кода на С++ на Шарп глупо скорее всго по началу языки вроде Шарпа и Явы появятся в них как средства автоматизации. А потом, когда народ поймет, что нет особой разницы все большешие и большие части будут дописываться/переписываться на дотнетных языках.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Вот интересно, зачем же тогда половина стринга написана на нативном С++?
Хороший вопрос. Особенно елси учесть тот факт, что этот код проигрывает аналогичному написанному на Шарпе.
Дуамаю, тут два аспекта. 1. Универсальные алгоритмы проще было взять в С++ чем переписывать (особенное если они нужны для назных типов). 2. Фрэймвор унаследован от Явы и много кода писалось еще в те времена, когда еще небыло качественного джита. Сейчас такой фигней уже не занимаются.
PE> Стрингбилдер туда же.
Все требовательные к производительности фукнции стрингбилдера реализованы прямо в нем. Импортируются как раз не столь важные.
PE> Да и вообще много че написано нативно, хотя можно было менеджед заимплементить.
Возми моно. Там почти все на Шарпе. Тот же компилятор. Причем компилирует очень шустро.
PE>Ведь можно его на шарпе реализовать полностью. Наверное Били решил таким способом замелить строку ?
Да на Шарпе все же по более будет. И самые медленные реализации как раз на С++ сделаны. Правда это не означает, что С++ никуда не годится. Просто на С++ обычно реализуются универсальные вещи, а они в принципе обычно тормозны.
VD>>А это ничего, что ЖЦ в Яве работает не медленнее чем стандартные хипы С++? PE>А это ничего, что аппликухе на нативном с++ хватает памяти, а дотнету — нет ?
Где? Вот у нас на сервере мс-сиквел и АСП.НЭТ. Так сиквелу памяти нехватает, а АСП вроде не кашляет.
PE>Он слишком долго отслеживает ссылки, если их слишком много.
Слишком много это сколько? Миллион отслеживает почти молниеносно. Да и делается это не постоянно.
PE>Модель сети например. Любая наукоемкая задача использует очень сложные стурктуры.
Т.е. граф? Нда, куда уж сложнее. Нормально он будет с ней работать. Памяти возможно сожрет больше, но если ее хватает, то будет очень даже прилично работать.
PE>В какие акселераторы ?
В видео.
PE> Туда зашивают только то, что хорошо разжевано,
Напомню о чем речь: K>>>Возьми любую нетривиальную задачу — триангуляция поверхности
PE>А с оработкой звука как ?
У меня на одной машие SB Live, а на другой SB Audidgy 2.
PE> Реалиизуй алгоритм смены голоса диктора на шарпе (двумя способами — со словарем и без оного) , будем посмотреть.
Это давно решенные задачи. Если конечно велосипед не изобретать. Ну, и главно ошеломляюще быстрее на С++ их один фиг не решить.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Деревья, графы, сети на дотнете превращаются в сплошной геморрой. Степень геморроя пропорциооняльна среднему количесву референсов на объект.
Пустой треп.
PE>Серилизация это вообще отдельный случай.
Реализация по умолчанию не быстрая. Но в С++ ее вообще нет, так что сравнивать не с чем. А реализовать ее быстро можно и там, и там.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Я кидал ссылку про O(n**2) поведение мультикастделегата. При десерилизации происходит затык при рассылке OnDeserilizationCallback. 50000 — еще реально ждать. 100000 — уже нет.
Напиши свой алгоритм сериализации. На С++ ты же тоже не будешь иметь готового. Я уже писал об этом. Тот же нетовский дадасет у меня сериализовался со скоростью поросячего визга.
PE>Возьми и пощупай сам. А та синтетика, которую ты здесь показал, никакого отношения к сетям не имеет.
И в чем разница?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Вот ответ на причину тормозов при десерилизации. Это проблемы дотнета, возможно ее пофиксят. PE>Но есть масса других проблем — стато мелких поросят.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Шустрики смотреть неинтересно, ибо реальные замеры на наших аппликациях показывают совсем не то.
А уверен, что это не руки? На Хоум тоже говорили память жрет... торомзит... а когда стали разбираться, то выяснили, что основное время и память сжерает Эксес.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
PE>>Вот когда будет релиз шарпа с дженериками, тогда можно будет посмотреть. А пока мы зашли в тупик. Оптимизировать уже нечего...
VD>Вы — возможно. Я — нет. Дженерики это конечно удобно. И кое где они позволят более просто создавать более эффектиные алгоритмы, но и сейчас можно писать очень даже эффективный код.
Сейчас у нас каждый объект порождает пять сущностей:
Класс
2 вида коллекции — копипейст.
Основной интерфейс (для SAX Basic)
Класс/методы для валидации
Этого, мягко говоря, слишком много. Если есть темплейты, как на C++, то необходимо только класс и валидатор. Кроме того есть еще много вспомогатеьных классов, которые чтото кешируют(атрибуты, суррогаты, рефлексию и тд.). Генерировать код не представляет возможным, ибо неясно, как его отлаживать при внесении изменений в модель.
Здравствуйте, VladD2, Вы писали:
PE>>Деревья, графы, сети на дотнете превращаются в сплошной геморрой. Степень геморроя пропорциооняльна среднему количесву референсов на объект.
VD>Пустой треп.
Конечно. Не буду же я тебе мегабайты кода слать.
PE>>Серилизация это вообще отдельный случай.
VD>Реализация по умолчанию не быстрая. Но в С++ ее вообще нет, так что сравнивать не с чем. А реализовать ее быстро можно и там, и там.
Можно, никто не спорит, вопрос в том, как именно. Дяди за МС по нашему поводу пока ничего не отвечают. Даже общих рекомендаций дать не могут.
Здравствуйте, VladD2, Вы писали:
PE>>Шустрики смотреть неинтересно, ибо реальные замеры на наших аппликациях показывают совсем не то.
VD>А уверен, что это не руки? На Хоум тоже говорили память жрет... торомзит... а когда стали разбираться, то выяснили, что основное время и память сжерает Эксес.
Конечно руки ! Ты, как линуксоид, уверяешь меня что всему виной руки.
В шустриках пока одна синтетика. Пока там не будет реальных алгоритмов типа упаковки, распаковки, вычислений, обработка видео, звука, изображения нечего и говорить.
Здравствуйте, VladD2, Вы писали:
PE>>Я кидал ссылку про O(n**2) поведение мультикастделегата. При десерилизации происходит затык при рассылке OnDeserilizationCallback. 50000 — еще реально ждать. 100000 — уже нет.
VD>Напиши свой алгоритм сериализации. На С++ ты же тоже не будешь иметь готового. Я уже писал об этом. Тот же нетовский дадасет у меня сериализовался со скоростью поросячего визга.
И у меня быстрее будут делегаты работать ? Придется без них изобретать дополнительный геморрой. Для этого нам надо фактически передрать бинариформаттер и адаптировать его под свою модель. Другие форматтеры работают еще дольше. Простым форматтером здесь не обойтись.
PE>>Возьми и пощупай сам. А та синтетика, которую ты здесь показал, никакого отношения к сетям не имеет.
VD>И в чем разница?
Разница в том, что в сетях среднее количество референсов на один оъект около 30. Распространение эвента занимает существенное время. Конкатенация строк выполняется гораздо быстрее. Кроме того, некоторые базовые механизмы приходится делать с использованием рефлекшна.
Если ты силен в теории оптических сетей — милости просим, будем рады услышать мнения по дизайну модели.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Конечно руки ! Ты, как линуксоид, уверяешь меня что всему виной руки.
Я как честный линуксоид отвергаю все инсинуации.
PE>В шустриках пока одна синтетика. Пока там не будет реальных алгоритмов типа упаковки, распаковки, вычислений, обработка видео, звука, изображения нечего и говорить.
Алгоритмы там самые обыкновенные. Большое же приложение просто не получится перенести на стлько язяков без ошибок и за разумное время. Если только авто-генирилкой воспользоваться...
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Этого, мягко говоря, слишком много. Если есть темплейты, как на C++, то необходимо только класс и валидатор. Кроме того есть еще много вспомогатеьных классов, которые чтото кешируют(атрибуты, суррогаты, рефлексию и тд.). Генерировать код не представляет возможным, ибо неясно, как его отлаживать при внесении изменений в модель.
Здравствуйте, Plutonia Experiment, Вы писали:
VD>>Хороший вопрос. Особенно елси учесть тот факт, что этот код проигрывает аналогичному написанному на Шарпе.
PE>А где это можно посмотреть ?
Здесь http://rsdn.ru/mag/0603/Collections.XML
VD>>Все требовательные к производительности фукнции стрингбилдера реализованы прямо в нем. Импортируются как раз не столь важные.
PE>Копирование строки — нативная функция.
Она и в С++ на асме написана обычно. МемМув лучше всего реализуется командой mov ассемблера.
VD>>Да на Шарпе все же по более будет. И самые медленные реализации как раз на С++ сделаны. Правда это не означает, что С++ никуда не годится. Просто на С++ обычно реализуются универсальные вещи, а они в принципе обычно тормозны.
PE>Это точно. А ассемлерные программы всегда тормозные в принципе.
Не стоит передергивать. Если бы ты сам попытался разобраться, то поразился бы этим фактом.
PE>А что, окромя сиквела и АСП нет других применений ?
Есть еще ннтп и почта. ННТП криво написан, а почта почти ничего не жрет. Так что за ресурсы дерется дотнет и сиквел. Но причем тут это?
PE>Почти — растяжимое поняте. Минимум 8 секунд при 20000 референсов.
8 милисекунд будет более точной цифрой. Просто там кроме отслеживания еще много чего делается. А 8 сек. ЖЦ я в жизни не видел.
PE>Ой-ой. Мы год назад начали писать, сейчас первый релиз был. Это не просто граф. Это гиперграф. PE>Граф состоящий из графов. Всего различных объектов около 600. Вот они то и реализуют весь гиперграф.
И есть эквивалентные реализации для дотнета и С++?
PE>Давно — это конечно. Осоенно если учесть, что это самая актуальная тема для диссеров.
Для дисеров? Ну, это не ко мне. А приличный звук и видео у меня уже лет 5.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Можно, никто не спорит, вопрос в том, как именно. Дяди за МС по нашему поводу пока ничего не отвечают. Даже общих рекомендаций дать не могут.
А профайлер по этому поводу что говорит?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>И у меня быстрее будут делегаты работать ?
Нет. Только ифы и свитчи.
PE> Придется без них изобретать дополнительный геморрой.
Интерфейсы?
PE> Для этого нам надо фактически передрать бинариформаттер и адаптировать его под свою модель. Другие форматтеры работают еще дольше. Простым форматтером здесь не обойтись.
Это не так. ХМЛ-форматер работает быстрее. Если для вас сериализация критична по времени, то стоит вообще сделать свой фрэймворк по этому поводу. В отличии от плюсов для этого вдотнете все есть.
PE>Разница в том, что в сетях среднее количество референсов на один оъект около 30.
Ну, модернезируй пример до этого. У меня выдумки не хватает. Но вряд ли скорость от этого изменится. Еще раз повторяю, проверка графа относительно шустрая операция.
PE>Распространение эвента занимает существенное время. Конкатенация строк выполняется гораздо быстрее. Кроме того, некоторые базовые механизмы приходится делать с использованием рефлекшна.
Ну, так ты сам знаешь чего не надо делать. Остается только сделать как надо используя быстрые подходы.
PE>Если ты силен в теории оптических сетей — милости просим, будем рады услышать мнения по дизайну модели.
Оптических? Вряд ли. Но не думаю что граф от этого станет другим.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если бы вы меня спросли как с эитм быть, я бы ответил — делайте собственный фрэймворк сериализации и не возитесь с этим. Или ждите видби и оркас. Там обещали разогнать сериализацию.
Кстит, если хочешь сделай тест демонстрирующий тормоза, а я прогоню его на видби.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Я как честный линуксоид отвергаю все инсинуации.
PE>>В шустриках пока одна синтетика. Пока там не будет реальных алгоритмов типа упаковки, распаковки, вычислений, обработка видео, звука, изображения нечего и говорить.
VD>Алгоритмы там самые обыкновенные. Большое же приложение просто не получится перенести на стлько язяков без ошибок и за разумное время. Если только авто-генирилкой воспользоваться...
Можно попробовать хотя бы преобразование фурье набомбить.
Здравствуйте, VladD2, Вы писали:
PE>>Этого, мягко говоря, слишком много. Если есть темплейты, как на C++, то необходимо только класс и валидатор. Кроме того есть еще много вспомогатеьных классов, которые чтото кешируют(атрибуты, суррогаты, рефлексию и тд.). Генерировать код не представляет возможным, ибо неясно, как его отлаживать при внесении изменений в модель.
VD>Согласен, неудобно. Но скрость то тут причем? А над удобством мы уже рабьотаем: http://rsdn.ru/?article/rsharp/rsharp.xml
Неудбоно — с этим можно мириться, если проект небольшой.
На данный момент у нас 12 мегов шарпового кода. Минус комментарии, заголовки получтся 8.
В этом коде дублирование очень неслабое.
А что бы отказаться от дублирования пришлось подключить рефлексию. Для ускорения пришлось писать кеши для всего — аттрибуты, проперти, имена методов и тд.
А вот как ускорит создани делегатов неизвестно. Это занимает ровно половину времени десерилизации. Колбек интерфейсы влекут массу геморроя за собой. Усложнять не хотелось бы.
С десекрилизацией проще, но тогда будет с серилизацией проблемы — это увеличит кличество ссылок на объект, что повлечет усложнение суррогатов и создание излишнебольшого количества WriteObjectInfo.
Re[13]: C++ versus C#
От:
Аноним
Дата:
03.03.04 08:14
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Здравствуйте, VladD2, Вы писали:
VD>>Я как честный линуксоид отвергаю все инсинуации.
PE>>>В шустриках пока одна синтетика. Пока там не будет реальных алгоритмов типа упаковки, распаковки, вычислений, обработка видео, звука, изображения нечего и говорить.
VD>>Алгоритмы там самые обыкновенные. Большое же приложение просто не получится перенести на стлько язяков без ошибок и за разумное время. Если только авто-генирилкой воспользоваться...
PE>Можно попробовать хотя бы преобразование фурье набомбить.
Здравствуйте, VladD2, Вы писали:
VD>>>Все требовательные к производительности фукнции стрингбилдера реализованы прямо в нем. Импортируются как раз не столь важные.
PE>>Копирование строки — нативная функция.
VD>Она и в С++ на асме написана обычно. МемМув лучше всего реализуется командой mov ассемблера.
Угу. В файле strcat.c из CRT есть такое
/***
*char *strcpy(dst, src) - copy one string over another
*
*Purpose:
* Copies the string src into the spot specified by
* dest; assumes enough room.
*
*Entry:
* char * dst - string over which "src" is to be copied
* const char * src - string to be copied over "dst"
*
*Exit:
* The address of "dst"
*
*Exceptions:
*******************************************************************************/char * __cdecl strcpy(char * dst, const char * src)
{
char * cp = dst;
while( *cp++ = *src++ )
; /* Copy src over dst */return( dst );
}
Такого ассемлера я не знаю.
VD>Есть еще ннтп и почта. ННТП криво написан, а почта почти ничего не жрет. Так что за ресурсы дерется дотнет и сиквел. Но причем тут это?
Да при том, что С# и дотнет не является панацеей. Универсальность и дешевизна разработки. Но в некоторых областях производительность важнее.
PE>>Почти — растяжимое поняте. Минимум 8 секунд при 20000 референсов.
VD> 8 милисекунд будет более точной цифрой. Просто там кроме отслеживания еще много чего делается. А 8 сек. ЖЦ я в жизни не видел.
Так профайлер говорит.
PE>>Ой-ой. Мы год назад начали писать, сейчас первый релиз был. Это не просто граф. Это гиперграф. PE>>Граф состоящий из графов. Всего различных объектов около 600. Вот они то и реализуют весь гиперграф.
VD>И есть эквивалентные реализации для дотнета и С++?
Есть. Все писали мы. Искренне жаль, но конкурентов до прошлого года у нас не было.
Re[2]: Вопрос слегка не в тему
От:
Аноним
Дата:
03.03.04 08:27
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Если есть люди, которые долго писали на плюсах, а потом срочно перешли только на шарп. А>Какие были впечатления? Не хочется ли обратно?) А>Мне вот сейчас как раз это предстоит.
Перешёл на C# год назад, в бэкграунде остались около 4 лет программирования на С++.
Впечатления — большей частью положительные. Насчёт обратно — нет, не хочется,
больно уж быстро и безошибочно удаётся прогать , особенно n-звенные системы, GUI,
работа с БД. Единственное, что пока немного
огорчает — это отсутствие релизных CRL и компилятора, поддерживающих generics (тоскую по
шаблонам С++, и жду релиза, бетами не хочется пользоваться , хотя и понимаю, что
извратов на шаблонах, которыми баловался на С++, уже не сотворить — оно может и к лучшему ). Ещё не хватает STL, причём — честно говоря, иногда даже очень сильно
А насчёт множественного наследования — так оно мне за 6 лет прогания только 2 раза
пригодилось , так что в принципе — и без него жить можно .
Хотя иногда( а это происходит всё реже и реже, надо сказать ), тёмными вечерами — прогаю на чистом ISO/IEC 14882 С++. Ностальгирую, так сказать .
P.S.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Kluev, Вы писали:
K>>Когда задача очень большая, то и хип нам не друг. VD>И есть документальное подтверждение на которое можно дать ссылку?
Пжста: http://qform3d.com/index.php?lang=ru
Вся работа с памятью сделана ручками, ибо не хватает ее родимой. Все 1.5 гига которые можно реально урвать на процесс расписаны и поделены. Плюс решатель в отдельном процессе 800МБ кушает.
K>> В таких случаях делается пул и хип и ГЦ остаются далеко позади. VD>Да качественный ЖЦ и есть по сути пул.
Пул он при любых условиях пул. А ГЦ с какогото момента уже не пул, а проклятье.
K>> Никакой ГЦ не сможет работать быстрее чем пул. VD>Согласен, но велика ли разница? И так ли часто ты пользуешся пулом и другими тонкими оптимизациями?
дальше продолжать?
VD>Удаляется... если памяти нехватает и если на объект нет ссылок. А если хватает, то ради чего его удалять? Чтобы процессор занять?
А если не хватает?
VD>Код прикладной писать. А производительность ЖЦ проблемы МС и Сана. Если уж очень нужно, то в дотнете можно пользоваться структурами и хранить их в массиве. Считай тот же пул.
Это наверное, шутка?
K>> Наверное на С++ переписывать будем
VD>Ни разу пока не нужно было. Но если я пийду к выводу, что на С++ я смогу ускорить ту или иную часть приложения и это действительно нужно, то я сделаю это не задумываясь. А почему бы и нет? Но ради скорости одного-двух фрагментов кода тратить столько сил и времени... зачем?
А если эти фрагменты 80% кода. Можно конечно остальные 20 (ГУЙ и прочее) на НЕТ перевести, но какой смысл? Я не вижу.
K>>Представь что программа на каждой итерации создает и освобождает ~200К обьектов. VD>Это очень выгодный для ЖЦ сценарий. Дон Бокс даже демонстрировал приемущества ЖЦ над хипом С++ создавайя в цикле объект и уничтожая его.
То что показал бокс — это какая-то пародия на тест. Могу написать реальный на котором ГЦ заткнется. А С++ будет летать.
VD>В ЖЦ есть специальные оптимизации на такой случай. Все эти объекты попадут в первое поколение и будут очень эффективно освобождены. Причем тогда когда процессор будет свободен, ане во время алгоритма.
Это когда же он будет свободен если алгоритм несколько дней работает?
VD>Да и все разговоры о пуле — это теория. На практике осннвные массы таких фич не используют. И выходит не быстрее чем с ЖЦ.
Для кого-то теория, а для меня обычная повседневность жизни. А фичи эти не используют пока все устраивает. А как только появляется узкое место, то прикрутить пул пустяковое дело. Тогда все начинает летать. Что и видно невооруженным глазом.
VD>. А потом, когда народ поймет, что нет особой разницы все большешие и большие части будут дописываться/переписываться на дотнетных языках.
А если нет особой разницы то зачем куда-то переходить? Только ради ГУЯ? А во всем остальном иметь мучения.
block* alloc_() {
block *p = cur_->free;
if ( p ) { // идеальный случай
cur_->free = p->next;
cur_->used_n++;
return p;
}
// неидеальный происходит один раз в несколько тысяч раз (в зависимости от размеров и настроек)
chunk *c = first_;
for ( ; c; c = c->next ) {
p = c->free;
if ( p ) {
cur_ = c;
cur_->free = p->next;
cur_->used_n++;
return p;
}
}
c = chunk_alloc_();
if ( c ) {
p = c->free;
cur_ = c;
cur_->free = p->next;
cur_->used_n++;
return p;
}
return (block*)Tr::out_of_mem();
}
Здравствуйте, VladD2, Вы писали:
PE>> Придется без них изобретать дополнительный геморрой.
VD>Интерфейсы?
И это тоже. Но дженерик подход дается большим оверхедом или маленьким рефлекшном.
Только модель данных занимает 7 мегов в 700 файлах. Комментариев правда довольно много.
Классов очень много. Интерфейсов еще больше. Вот такие дела.
VD>Это не так. ХМЛ-форматер работает быстрее. Если для вас сериализация критична по времени, то стоит вообще сделать свой фрэймворк по этому поводу. В отличии от плюсов для этого вдотнете все есть.
Быстрее, но для графа он неприменим.
PE>>Распространение эвента занимает существенное время. Конкатенация строк выполняется гораздо быстрее. Кроме того, некоторые базовые механизмы приходится делать с использованием рефлекшна. VD>Ну, так ты сам знаешь чего не надо делать. Остается только сделать как надо используя быстрые подходы.
Тогда это копипейст и размножение классов.
PE>>Если ты силен в теории оптических сетей — милости просим, будем рады услышать мнения по дизайну модели.
VD>Оптических? Вряд ли. Но не думаю что граф от этого станет другим.
Просто прочувствй масштаб. Тот граф о котором говорят в книгах, имеет два типа объекта — вершина и ребро. Иногда еще связка между ними. У нас есть еще подграфы различные, различные типы вершин, ребер и тд. Всего около 600 разновидностей. И это толкьо основные классы. Еще сотня или две вспомогательных и тд.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Plutonia Experiment, Вы писали:
PE>>Можно, никто не спорит, вопрос в том, как именно. Дяди за МС по нашему поводу пока ничего не отвечают. Даже общих рекомендаций дать не могут.
VD>А профайлер по этому поводу что говорит?
VD>Если бы вы меня спросли как с эитм быть, я бы ответил — делайте собственный фрэймворк сериализации и не возитесь с этим. Или ждите видби и оркас. Там обещали разогнать сериализацию.
Это в планах, но на это нужно много времени.
VD>Кстит, если хочешь сделай тест демонстрирующий тормоза, а я прогоню его на видби.
Мне придется половину проекта выдрать. Все маленькие летают по сравнению с теми, что побольше.
Здравствуйте, VladD2, Вы писали:
PE>>Можно, никто не спорит, вопрос в том, как именно. Дяди за МС по нашему поводу пока ничего не отвечают. Даже общих рекомендаций дать не могут.
VD>А профайлер по этому поводу что говорит?
На загрузке тормоза в CreateDelegate и RaizeDeserilizationEvent.
На сохранение — создается в разы больше WriteObjectInfo чем это надо.
Далее — SerilizationInfo.AddValue подтормаживает.
Я думаю, что нормальный путь — выдрать сериалайзер из ротора и кой какие пместа оптимизировать. Но неясно, как это толкнуть в обиход. Это есть нарушение.
А нам чу что придется написать примерно такой же форматтер.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Можно попробовать хотя бы преобразование фурье набомбить.
Честно говоря преобразование фурье лично меня волнует мало, поскольку последние лет пять ничем похожим заниматься не приходилось, а когда приходилось то алгоритмы эти реализовывались в железке.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>В какие акселераторы ? Туда зашивают только то, что хорошо разжевано, канонизировано и стандартизировано. Окромя этого есть много алгоритмо оработки изображений. Распознавание например. А с оработкой звука как ?
Здравствуйте, AndrewVK, Вы писали:
AVK>Честно говоря преобразование фурье лично меня волнует мало, поскольку последние лет пять ничем похожим заниматься не приходилось, а когда приходилось то алгоритмы эти реализовывались в железке.
Послушаешь тебя и Влада — все алгоритмы в железе...Интересно, как у меня работают проги звуковые, еси стоит только кодек AC97 ?
Не пойму, чем мои знакомые прогреры-звукари занимаются — http://audio4fun.com/.
Все ведь в железе. Наверное в инсталятор входит и звуковуха мега-профессиональная.
Качаешь из инета, а при инсталяции программно втыкается в PCI слот.
А на ноутуке твоем много железа с аппаратным преоразованием того же фурье ?
Тогда питч-шифт заимплементи, если фурье не нравится.
Здравствуйте, AndrewVK, Вы писали:
PE>>В какие акселераторы ? Туда зашивают только то, что хорошо разжевано, канонизировано и стандартизировано. Окромя этого есть много алгоритмо оработки изображений. Распознавание например. А с оработкой звука как ?
AVK>FPGA тебя спасет
Да понятно. А Саундфорджем или Диаммондом от audio4fun он тоже идет ?
Здравствуйте, Sinclair, Вы писали:
S>С вашего позволения:
Спасибо, а я и не догадался отформатировать.
Жирным отмечены точки, которые невозможно оптимизировать в силу некоторых особенностей.
SetValidatableProperty — автоматическая валидация. Тут рефлексия.
GetPropertyDescriptionMapInternal — создаются тучи делегатов.
set_Name — имя объекта должно быть уникальным, следовательно нужно сообщеть буде это не так.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Plutonia Experiment, Вы писали:
PE>>В какие акселераторы ? Туда зашивают только то, что хорошо разжевано, канонизировано и стандартизировано. Окромя этого есть много алгоритмо оработки изображений. Распознавание например. А с оработкой звука как ?
AVK>FPGA тебя спасет
HandleC, SystemC
в нашей конторе железки разрабатываются на С++(не HandleC, не SystemC) со спец. фреймворком, а потом с помощью одного же кода всё тестируется, генерится синтезабельный vhdl и програмки для верефикации уже готовых девайсов (код пишется один раз), на С# такого фреймворка сделать нельзя
так что тут аргумент в пользу С++
Здравствуйте, naje, Вы писали:
N>HandleC, SystemC N>в нашей конторе железки разрабатываются на С++(не HandleC, не SystemC) со спец. фреймворком, а потом с помощью одного же кода всё тестируется, генерится синтезабельный vhdl и програмки для верефикации уже готовых девайсов (код пишется один раз), на С# такого фреймворка сделать нельзя N>так что тут аргумент в пользу С++
Фремворк на шарпе создать еще проще. НО ! В программах обработки звука для простых обывателей никогда не было, нет и никогда не бует аппаратных алгоритмов. Продвинутый программный алгоритм всегда будет раотать быстрее железа. Фурье — довольно меденный агоритм.
Применения в ПО его избегают именно из за тормознутости. Можно быстрее — но больше памяти сожрешь. А вот в железо фурие закатать — проще не придумаешь. Но не всегда можно использовать аппаратные воможности. Для вывода звука на колонки можно кое что впихнуть в звуковуху.
Но чтото я ни разу не видел в продаже аппратный ужиматель(USB или PCI или PCMCIA) в МП3, ОГГ к примеру для моего компутера. И не просто ужиматели, а чтобы можно было гибко настраивать, психоаккустику менять и тд. и тд.
Так что всякие FPGA можно сразу засунуть в одно место.
Здравствуйте, AndrewVK, Вы писали:
PE>>Да понятно. А Саундфорджем или Диаммондом от audio4fun он тоже идет ?
AVK>Обычно наоборот — дивайс идет в комплекте с ними.
Это понятно. Но как это чуду раотает с кодеком AC97 ? Не программно ли ?
обрабатывать кусок файла в сто мегов очень накладно на железяке. Дорого это. А недавно и вовсе невозможно было.
Пример — из песни выдрать вокал, или шум убрать, или эквалайзить некисло, или психоаккустику наложить, или вока этот самый заменить на другой.
Громкость сменить, нормализировать, клики поубирать, тишину вырезать, искажения выровнять.
Все это есть в железе ? Все это делается именно программно и не просто программно, а на С++. Иногда еще ассемблер подключается для особохитрых операций.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Здравствуйте, naje, Вы писали:
PE> Фремворк на шарпе создать еще проще. НО !
такой как тут невозможно просто на шарпе, нужно разрабатывать ещё один язык для нета, впринципе одно из решений
PE> В программах обработки звука для простых обывателей никогда не было, нет и никогда не бует аппаратных алгоритмов. Продвинутый программный алгоритм всегда будет раотать быстрее железа. Фурье — довольно меденный агоритм.
что значит продвинутый? PE>Применения в ПО его избегают именно из за тормознутости. Можно быстрее — но больше памяти сожрешь. А вот в железо фурие закатать — проще не придумаешь. Но не всегда можно использовать аппаратные воможности. Для вывода звука на колонки можно кое что впихнуть в звуковуху. PE>Но чтото я ни разу не видел в продаже аппратный ужиматель(USB или PCI или PCMCIA) в МП3, ОГГ к примеру для моего компутера. И не просто ужиматели, а чтобы можно было гибко настраивать, психоаккустику менять и тд. и тд.
кодеков G.7xx немеренно всяких, и вабще DSP'эшек выполненных в железе (не на DSP контроллерах) немеренно всяких, и в последнее время всё больше появляется
PE>Так что всякие FPGA можно сразу засунуть в одно место.
это зря, гораздо дешевле и эффективнее поставить в какой-нибудь голосовой сервер(например) парочку fpga'шников (по 200 дол+стоимость шины), чем штуки 4 (а скорее всего больше) лишних процессора(+шина гораздо больше стоить будет чем для fpga)
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Это понятно. Но как это чуду раотает с кодеком AC97 ? Не программно ли ? PE>обрабатывать кусок файла в сто мегов очень накладно на железяке. Дорого это.
Вот потому и говорю что FPGA рулит. Универсальная и недорогая железка. Менее универсально для обработки звука я бы использовал DSP. Стоимость — единицы долларов.
PE>Пример — из песни выдрать вокал, или шум убрать, или эквалайзить некисло, или психоаккустику наложить, или вока этот самый заменить на другой. PE>Громкость сменить, нормализировать, клики поубирать, тишину вырезать, искажения выровнять.
PE>Все это есть в железе ?
Да.
PE> Все это делается именно программно и не просто программно, а на С++.
Знаешь, эти задачки на АС97 ничто иное как баловство. Обсуждать промышленные платформы в аспекте баловства неинтересно.
Здравствуйте, AndrewVK, Вы писали:
AVK>Рынок только у твоих знакомых ну очень маленький. PE>>А на ноутуке твоем много железа с аппаратным преоразованием того же фурье ?
AVK>Нет. А нафига оно мне?
Запусти SoundForge или VCS Diamond и убедись, что весь звук обрабатывается программно.
Обраотка звука — это не спецэффекты, которые в курточку засунуть можно. Это математика
Здравствуйте, AndrewVK, Вы писали:
PE>>Не пойму, чем мои знакомые прогреры-звукари занимаются — http://audio4fun.com/. AVK>Рынок только у твоих знакомых ну очень маленький.
Т.е. ты винампоп не пользуешься ? Филмы не смотришь ? Эквалайзер в винампе не крутишь ?
И слушаешь только вавки, а не мп3 и не огг ?
Здравствуйте, AndrewVK, Вы писали:
PE>>На данный момент у нас 12 мегов шарпового кода. Минус комментарии, заголовки получтся 8.
AVK>Заголовки в шарповом коде это что то интересное.
Очень смешно, рядовой Шуник. Каждый файл имеет в коментариях описание, список авторов, копирайт и тд и тд.
PE>>А вот как ускорит создани делегатов неизвестно. AVK>Почему? Заменить их на интерфейсы.
Тогда в другом месте тормоза.
PE>>Колбек интерфейсы влекут массу геморроя за собой. AVK>Например?
Все это нужно писать руками. Объект может быть подписан на хрензнает сколько эвентов жругих объектов. Придется писать весь этот механизм.
Всего 7 типов эвентов. Объект может быть подписан в среднем на 20...30 других объектов и коллекций. Если делать колбеками, то ...
Здравствуйте, Plutonia Experiment, Вы писали:
PE>>>А вот как ускорит создани делегатов неизвестно. AVK>>Почему? Заменить их на интерфейсы. PE>Тогда в другом месте тормоза.
Приниматься за оптимизацию другого места. Тормоза то будут всегда, но приложение твое будет работать все быстрее и быстрее.
PE>>>Колбек интерфейсы влекут массу геморроя за собой. AVK>>Например?
PE>Все это нужно писать руками. Объект может быть подписан на хрензнает сколько эвентов жругих объектов. Придется писать весь этот механизм.
Не, ну ты сам выбрал схему на эвентах, не поинтересовавшись производительностью делегатов.
PE>Всего 7 типов эвентов. Объект может быть подписан в среднем на 20...30 других объектов и коллекций. Если делать колбеками, то ...
То что? Чем принципиально отличается реализация интерфейса от написания обработчика?
Hello, AndrewVK!
You wrote on Wed, 03 Mar 2004 12:36:28 GMT:
A> Вот потому и говорю что FPGA рулит. Универсальная и недорогая железка.
А еще универсальней — С++
A> Менее универсально для обработки звука я бы использовал DSP. Стоимость - A> единицы долларов.
У весьма тормозных в партии от 10000 штук . Прибавь стоимость разработки интерфейса с компутером, PCB, сборки железяки, написания драйверов и прочего, включая доставку железяки енд-юзеру. Да и цена "вхождения" в разработку будет весьма не малая.
PE>> Пример — из песни выдрать вокал, или шум убрать, или эквалайзить PE>> некисло, или психоаккустику наложить, или вока этот самый заменить на PE>> другой. Громкость сменить, нормализировать, клики поубирать, тишину PE>> вырезать, искажения выровнять.
PE>> Все это есть в железе ?
A> Да.
Наверное, кто-то полагает, что FPGA программировать сильно проще, чем на плюсах
Best regards,
Sergey.
Posted via RSDN NNTP Server 1.8 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
A>> Вот потому и говорю что FPGA рулит. Универсальная и недорогая железка.
S>А еще универсальней — С++
Тока результат хуже.
A>> Менее универсально для обработки звука я бы использовал DSP. Стоимость - A>> единицы долларов.
S>У весьма тормозных
Весьма тормозные спокойно уделают на задачках обработки звука дорогущие ЦП.
S> в партии от 10000 штук . Прибавь стоимость разработки интерфейса с компутером, PCB, сборки железяки, написания драйверов и прочего, включая доставку железяки енд-юзеру. Да и цена "вхождения" в разработку будет весьма не малая.
А кто сказал что будет легко. Только кто то тут говорил про серьезные задачи? А баловство вроде винампа конечно проще писать без DSP, только там и к производительности таких требований нет.
A>> Да.
S>Наверное, кто-то полагает, что FPGA программировать сильно проще, чем на плюсах
Ох как у нас любят считать себя умнее других. Я этим занимался, так что можешь не гримасничать.
Hello, AndrewVK!
You wrote on Wed, 03 Mar 2004 14:30:38 GMT:
A> Весьма тормозные спокойно уделают на задачках обработки звука дорогущие A> ЦП.
Во-первых, ЦП здесь бесплатный, потому что за него все равно уже уплачено и, самое главное, сопровождать его как железяку не надо — об этом пусть у продавца компьютера голова болит. Во-вторых, конкретные примеры, где плисы уделывают четвертый пень в студию, плиз.
S>> в партии от 10000 штук . Прибавь стоимость разработки интерфейса с S>> компутером, PCB, сборки железяки, написания драйверов и прочего, S>> включая доставку железяки енд-юзеру. Да и цена "вхождения" в разработку S>> будет весьма не малая.
A> А кто сказал что будет легко. Только кто то тут говорил про серьезные A> задачи? А баловство вроде винампа конечно проще писать без DSP, только A> там и к производительности таких требований нет.
Каких именно требований? Насколько я понял, речь шла о задачах, вполне решаемых на мало-мальски современном железе в звуке — всякими саунфорджами и в обработке изображений — маями и прочими лайтвэйвами.
S>> Наверное, кто-то полагает, что FPGA программировать сильно проще, чем S>> на плюсах
A> Ох как у нас любят считать себя умнее других.
Да, я заметил.
A> Я этим занимался, так что можешь не гримасничать.
Ну вот и сравни, не кривлясь, стоимость разработки для какой-нибудь альтеры vs С++, ну, скажем, для рэйтрэсинга. Или хотя бы для перестраиваемого КИХ-фильтра, раз уж о звуке речь пошла — тока не на DSP, а именно на FPGA.
Best regards,
Sergey.
Posted via RSDN NNTP Server 1.8 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, naje, Вы писали:
PE>>Так что всякие FPGA можно сразу засунуть в одно место.
N>это зря, гораздо дешевле и эффективнее поставить в какой-нибудь голосовой сервер(например) парочку fpga'шников (по 200 дол+стоимость шины), чем штуки 4 (а скорее всего больше) лишних процессора(+шина гораздо больше стоить будет чем для fpga)
Интересно. Купил я себе комп за 200 рублей, захотел МП3 послушать. Где мне найти кодек для этого ? А если компакт диск ужать ? А если DVD ужать ?
Девайсы покупать ваши ?
Все делается программно и на С++ или Паскале.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Здравствуйте, naje, Вы писали:
N>>это зря, гораздо дешевле и эффективнее поставить в какой-нибудь голосовой сервер(например) парочку fpga'шников (по 200 дол+стоимость шины), чем штуки 4 (а скорее всего больше) лишних процессора(+шина гораздо больше стоить будет чем для fpga)
PE>Интересно. Купил я себе комп за 200 рублей, захотел МП3 послушать. Где мне найти кодек для этого ? А если компакт диск ужать ? А если DVD ужать ? PE>Девайсы покупать ваши ? PE>Все делается программно и на С++ или Паскале.
я тебе про домашнее использование говорил?
ты себе домой голосовой сервер покупать будешь, тут речь идёт не о 200 р, а о десятках-сотнях тысяч долларов?
ps лично у меня есть доска с fpga'шничком дома, для игр, обошлась мне порядка 300 долларов
Здравствуйте, AndrewVK, Вы писали:
PE>>Пример — из песни выдрать вокал, или шум убрать, или эквалайзить некисло, или психоаккустику наложить, или вока этот самый заменить на другой. PE>>Громкость сменить, нормализировать, клики поубирать, тишину вырезать, искажения выровнять.
PE>>Все это есть в железе ?
AVK>Да.
Ну ну. Какая именно звуковая карта жмет звук в ОГГ и МП3 И ВМА.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>И это тоже. Но дженерик подход дается большим оверхедом или маленьким рефлекшном. PE>Только модель данных занимает 7 мегов в 700 файлах. Комментариев правда довольно много. PE>Классов очень много. Интерфейсов еще больше. Вот такие дела.
Вы их генерируете что ли?
PE>Быстрее, но для графа он неприменим.
Ну, так пишите свою. Других выходов нет.
PE>Тогда это копипейст и размножение классов.
Почему? Можно и на ОО-проехаться.
PE>Просто прочувствй масштаб. Тот граф о котором говорят в книгах, имеет два типа объекта — вершина и ребро. Иногда еще связка между ними. У нас есть еще подграфы различные, различные типы вершин, ребер и тд. Всего около 600 разновидностей. И это толкьо основные классы. Еще сотня или две вспомогательных и тд.
Ну, незнаю. Въезжатьв вашу специфику — это уже перебор для меня.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
PE>>Всего 7 типов эвентов. Объект может быть подписан в среднем на 20...30 других объектов и коллекций. Если делать колбеками, то ...
AVK>То что? Чем принципиально отличается реализация интерфейса от написания обработчика?
Реализовать нудно не просто интерфейс. Мне придется агрегировать реализацию интерфейса стольо раз, сколько объектов слушает объект. Обработчик — это одна функция.
Еще нужно писать механизм, который в COM реализуется с помощью
IConnectionPointContainer/IConnectionPoint
Это не хухры мухры.
В среднем на объект держится около 30 референсов. Один объект может держать примерно столькоже референсов.
Выписывать такой код самоубийство.
Жирным я выделил то, что пишу с использованием делегатов и эвентов.
Есть разница ?
class A
{
public A()
{
m_event1 = new Event1(this);
...
...
}
class Event1:IEvent
{
void OnEvent()
{
}
}
sink1 m_event1;
...
class sinkN:ISink
{
void OnSink()
{
}
}
sink1 m_sinkN;
}
Но это не все. В методе set каждой проперти нужно освобождать старый объект, подписываться на новый. Причем на все эвенты !
Мы юзаем эвенты и рефлексию. НО ! всеравно текста, который просто размножался копипейстом(два типа коллекций на каждый объект, валидатор, интерфейс основной) море !!!
Если генерировать код, то возникают проблемы с отладкой. Ошибки из компайлтайм переносятся в рантайм.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Plutonia Experiment, Вы писали:
PE>>И это тоже. Но дженерик подход дается большим оверхедом или маленьким рефлекшном. PE>>Только модель данных занимает 7 мегов в 700 файлах. Комментариев правда довольно много. PE>>Классов очень много. Интерфейсов еще больше. Вот такие дела.
VD>Вы их генерируете что ли?
А как еще ? Из УМЛ в C# и вперед.
PE>>Тогда это копипейст и размножение классов. VD>Почему? Можно и на ОО-проехаться.
Проехались уже.
PE>>Просто прочувствй масштаб. Тот граф о котором говорят в книгах, имеет два типа объекта — вершина и ребро. Иногда еще связка между ними. У нас есть еще подграфы различные, различные типы вершин, ребер и тд. Всего около 600 разновидностей. И это толкьо основные классы. Еще сотня или две вспомогательных и тд. VD>Ну, незнаю. Въезжатьв вашу специфику — это уже перебор для меня.
С этого нужно было и начинать А то завеи разговор про панацею.
Здравствуйте, naje, Вы писали:
N>я тебе про домашнее использование говорил? N>ты себе домой голосовой сервер покупать будешь, тут речь идёт не о 200 р, а о десятках-сотнях тысяч долларов?
Мы говорим про массовый рынок.
N>ps лично у меня есть доска с fpga'шничком дома, для игр, обошлась мне порядка 300 долларов
Здравствуйте, AndrewVK, Вы писали:
PE>>Ну ну. Какая именно звуковая карта жмет звук в ОГГ и МП3 И ВМА.
AVK>Почему звуковая? Покупай платку с DSP и вперед
Т.е. у тех, у кого нет DSP, не получится жать звук ? Как же они жмут то ?
На счет ОГГ я сумлеваюсь — его плейерах железных то по большому счету нет.
Многие задачи обработки звука требуют охрененного количества ресурсов.
Никакое железо тут не поможет.
Посему я предлагаю сравнить быстродейсвие на самых популярных ужималках.
Кстати, а рары, зипы, тары — тоже аппаратно жмут ?
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Здравствуйте, naje, Вы писали:
N>>я тебе про домашнее использование говорил? N>>ты себе домой голосовой сервер покупать будешь, тут речь идёт не о 200 р, а о десятках-сотнях тысяч долларов?
PE>Мы говорим про массовый рынок.
а кто где это оговорил?
вобще обычно такая штучка ставится в средненьких офисах (~1000 чел), не такой уж и редкий случай
массовый рынок винампами не ограничивается
Здравствуйте, naje, Вы писали:
N>профессиональное создание музыки это не SoundForge или VCS Diamond, там как-раз много чего апаратного (как впринципе и профессиональное слушанье )
Почти все пользоватли компьютера используют проигрыватели МП3. Разве это аппаратно ?
А программы для оработки звука после грабления — например изменение психоаккустической модели на компактдиске. Это всякие расширения стереобазы и тд. и тд. ТОже аппаратно делается ?
Это всегда делается программо. На массовом рынке рулит ПО! Будь иначе, рынка по вооще не было бы.
Здравствуйте, naje, Вы писали:
N>а кто где это оговорил? N>вобще обычно такая штучка ставится в средненьких офисах (~1000 чел), не такой уж и редкий случай N>массовый рынок винампами не ограничивается
Винам — конечно нет. Но вообще очень много программ имеют отношение к обработке звука. Именно программно. Того железа, о которым вы говорите с AVK, я не нашел вообще.
Ну нет кодеров в MP3 массовых. Кое где используется, но я ы не сказал, что массово. Этот формат постоянно улучшает психоаккустику. В железе старье постоянно удет. А пока прошиву поменяешь, глядишь надо новой ждать, потому что уже улучшили снова.
Так что на компе все делается программно.
Вот я и предлагаю сравнить быстродейсвие нативной ужималки и менеджед.
Разница удет хорошо замента уже на преоразовании фурье.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Здравствуйте, naje, Вы писали:
N>>профессиональное создание музыки это не SoundForge или VCS Diamond, там как-раз много чего апаратного (как впринципе и профессиональное слушанье )
PE>Почти все пользоватли компьютера используют проигрыватели МП3. Разве это аппаратно ?
PE>А программы для оработки звука после грабления — например изменение психоаккустической модели на компактдиске. Это всякие расширения стереобазы и тд. и тд. ТОже аппаратно делается ? PE>Это всегда делается программо. На массовом рынке рулит ПО! Будь иначе, рынка по вооще не было бы.
а концертное, клубное оборудование, скажи что это не массовый рынок, пусть такого обарудования меньше надо, но винам бесплатный, а оно дорогое
мы сейчас разговариваем с точки зрения пользователей, или с точки зрения производителей, которые на этом деньги зарабатывают?
Здравствуйте, naje, Вы писали:
N>а концертное, клубное оборудование, скажи что это не массовый рынок, пусть такого обарудования меньше надо, но винам бесплатный, а оно дорогое N>мы сейчас разговариваем с точки зрения пользователей, или с точки зрения производителей, которые на этом деньги зарабатывают?
С точки зрения работающих экземпляров ПО или харда.
Если все пользователи жмут музыку, файло, видео аппаратно — нечего и сравнивать дотнет с нативом. Если это не так — есть смысл сравнить ыстродействие на одинаковых алгоритмах.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Реализовать нудно не просто интерфейс. Мне придется агрегировать реализацию интерфейса стольо раз, сколько объектов слушает объект.
Зачем? Сложно реализовать подобие мультикаст делегата для интерфейсов?
PE>Еще нужно писать механизм, который в COM реализуется с помощью PE>IConnectionPointContainer/IConnectionPoint
Давай СОМ не будем приплетать, совершенно понятно что дотнет не лучший способ с ним взаимодействия.
PE>Выписывать такой код самоубийство.
Зачем выписывать? Вы же вроде генерите? Ну так и генерите наздоровье. Руками нужно будет только пару хелперов написать.
PE>Жирным я выделил то, что пишу с использованием делегатов и эвентов. PE>Есть разница ?
Честно говоря чего то не вьехал что ты хотел показать. Зачем класс Event1?
PE>Но это не все. В методе set каждой проперти нужно освобождать старый объект, подписываться на новый. Причем на все эвенты !
Опять не понял. Эвент на самом деле просто приватное поле класса с двумя функциями для подписки и отписки. С использованием интерфейсов ты можешь сделать ровно тоже самое. Не так красиво как операторы +-=, но больше ничем не оличается. Просто вместо подписки определенного метода ты тем же классом реализуешь интерфейс и передаешь не делегата, а сам класс.
PE>Мы юзаем эвенты и рефлексию. НО ! всеравно текста, который просто размножался копипейстом(два типа коллекций на каждый объект, валидатор, интерфейс основной) море !!!
Значит что то не так. Причем явно не так.
PE>Если генерировать код, то возникают проблемы с отладкой. Ошибки из компайлтайм переносятся в рантайм.
Ну так генерировать надо тоже с умом, чтобы в рантайме они легко отлавливались. При наличии нормального стектрейса и соблюдении определенных правил ничего страшного в рантайм-ошибках нет.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Почему звуковая? Покупай платку с DSP и вперед
PE>Т.е. у тех, у кого нет DSP, не получится жать звук ? Как же они жмут то ?
PE>На счет ОГГ я сумлеваюсь — его плейерах железных то по большому счету нет. PE>Многие задачи обработки звука требуют охрененного количества ресурсов. PE>Никакое железо тут не поможет.
Все это правильно, вот только что то мне кажется что меньше всего меня волнует скорость работы на шарпе алгоритма сжатия в mp3 или ogg. Потому как это мизерный процент решаемых с его помощью задач.
PE>Кстати, а рары, зипы, тары — тоже аппаратно жмут ?
Здравствуйте, AndrewVK, Вы писали:
AVK>Зачем? Сложно реализовать подобие мультикаст делегата для интерфейсов?
Вот предложи свой вариант на C# без дженериков.
PE>>IConnectionPointContainer/IConnectionPoint AVK>Давай СОМ не будем приплетать, совершенно понятно что дотнет не лучший способ с ним взаимодействия.
Дело не в COM а в спосое взаимодействии клиентов.
PE>>Выписывать такой код самоубийство.
AVK>Зачем выписывать? Вы же вроде генерите? Ну так и генерите наздоровье. Руками нужно будет только пару хелперов написать.
В том то и дело что генерим мы только коллекции. А тут придется писать еще и генератор наших классов.Хорошего в этом мало — генереный код периодически приходится перегенерировать, чтобы внести изменения.
PE>>Жирным я выделил то, что пишу с использованием делегатов и эвентов. PE>>Есть разница ?
AVK>Честно говоря чего то не вьехал что ты хотел показать. Зачем класс Event1?
Класс, который реализует интерфейс обратной связи с другим объектом.
Для каждого члена класса нужно писать свою имплементацию интерфейса обратного вызова.
PE>>Но это не все. В методе set каждой проперти нужно освобождать старый объект, подписываться на новый. Причем на все эвенты !
AVK>Опять не понял. Эвент на самом деле просто приватное поле класса с двумя функциями для подписки и отписки. С использованием интерфейсов ты можешь сделать ровно тоже самое. Не так красиво как операторы +-=, но больше ничем не оличается. Просто вместо подписки определенного метода ты тем же классом реализуешь интерфейс и передаешь не делегата, а сам класс.
Я имею в виду, что вначале нужно оптисаться от пары тройки уведомлений, а потом подписаться на все заново у другого объекта.
PE>>Мы юзаем эвенты и рефлексию. НО ! всеравно текста, который просто размножался копипейстом(два типа коллекций на каждый объект, валидатор, интерфейс основной) море !!! AVK>Значит что то не так. Причем явно не так.
Конечно не так. Пролема в том, что нам навязали С#. Без дженериков никуда.
AVK>Ну так генерировать надо тоже с умом, чтобы в рантайме они легко отлавливались. При наличии нормального стектрейса и соблюдении определенных правил ничего страшного в рантайм-ошибках нет.
Легко на маленьгких прилах. А если алгоритм сутки работает ?
В любом случае перенос ошибок из компайлтайма в рантайм замедляет разработку.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Все это нужно писать руками. Объект может быть подписан на хрензнает сколько эвентов жругих объектов. Придется писать весь этот механизм. PE>Всего 7 типов эвентов. Объект может быть подписан в среднем на 20...30 других объектов и коллекций. Если делать колбеками, то ...
Десериализация графа проблема вроде изученная. Делается на банальной хэштаблице. Вам вообще можно написать ручной механизм и бует все летать.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Еще нужно писать механизм, который в COM реализуется с помощью PE>IConnectionPointContainer/IConnectionPoint
Не нужно. Не приплитай сюда еще и ком. Там борьба с ЭддРефами коих в дотнете нет.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Короче, где-то на следующей недели будет готов парсер R#-а. Там и до генератора не долего. Думаю, с его помощью все что тебе нужно можно будет сделать влет.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ты по ссылке то ходил? Это по твоему подтверждение. Ну, тогда вот опровержение: www.rsdn.ru
K>Вся работа с памятью сделана ручками, ибо не хватает ее родимой. Все 1.5 гига которые можно реально урвать на процесс расписаны и поделены. Плюс решатель в отдельном процессе 800МБ кушает.
2003-ий этерпрайз не пробовали ставить? Там можно урвать 3 гига вроде.
K>Пул он при любых условиях пул. А ГЦ с какогото момента уже не пул, а проклятье.
С точки зрения расхода памяти пул проклятье еще то...
VD>>Согласен, но велика ли разница? И так ли часто ты пользуешся пулом и другими тонкими оптимизациями? K>дальше продолжать?
На вопрос ты так и не ответил.
K>А если не хватает?
Ну, если твои задачи и в правду на рпеделе 32-х бытных технологих живут, то тебе даже над ассемблерной оптимизацией подумать не грех. Только это очень редкое исключение. 90% людей имеют несколько менее масштабные задачи.
Да и несколько смущает, то что есть и другие кады и им хватает куда меньше памяти.
VD>>Код прикладной писать. А производительность ЖЦ проблемы МС и Сана. Если уж очень нужно, то в дотнете можно пользоваться структурами и хранить их в массиве. Считай тот же пул. K>Это наверное, шутка?
Отнюдь.
K>А если эти фрагменты 80% кода. Можно конечно остальные 20 (ГУЙ и прочее) на НЕТ перевести, но какой смысл? Я не вижу.
Сомневаюсь я как-то. Скорее это уже дизайн.
K>То что показал бокс — это какая-то пародия на тест. Могу написать реальный на котором ГЦ заткнется. А С++ будет летать.
Я и сам могу. Но в среднем он очень даже ничего.
K>Это когда же он будет свободен если алгоритм несколько дней работает?
Значит несколько минут из этих нескольких дней потарахтит. Тут это вообще не критично.
K>Для кого-то теория, а для меня обычная повседневность жизни. А фичи эти не используют пока все устраивает.
Так большинство как раз все и устраиват. Мы говорим о непримененмости дотнета в редких экстримальных случаях или в массовмо производстве софта?
K> А как только появляется узкое место, то прикрутить пул пустяковое дело. Тогда все начинает летать. Что и видно невооруженным глазом.
Несколько дней — это "летать"? Странная логик.
K>А если нет особой разницы то зачем куда-то переходить? Только ради ГУЯ? А во всем остальном иметь мучения.
Так разницы нет только в скорости работы программы. А в скорости ее разработки она очень даже есть.
K>З.Ы. Кстати еще про пул. (Исходник здесь: http://rsdn.ru/File/16157/mem_mgr.h)
Здравствуйте, Plutonia Experiment, Вы писали:
VD>>Она и в С++ на асме написана обычно. МемМув лучше всего реализуется командой mov ассемблера.
PE>Угу. В файле strcat.c из CRT есть такое PE>... PE>Такого ассемлера я не знаю.
Хорошо у тебя еще не хватило воображения по *.cpp поискать.
Смотри crt\src\intel\strcat.asm или меняй компилятор.
page
;***
;char *strcpy(dst, src) - copy one string over another
;
;Purpose:
; Copies the string src into the spot specified by
; dest; assumes enough room.
;
; Algorithm:
; char * strcpy (char * dst, char * src)
; {
; char * cp = dst;
;
; while( *cp++ = *src++ )
; ; /* Copy src over dst */
; return( dst );
; }
;
;Entry:
; char * dst - string over which "src" is to be copied
; const char * src - string to be copied over "dst"
;
;Exit:
; The address of "dst" in EAX
;
;Uses:
; EAX, ECX
;
;Exceptions:
;*******************************************************************************
CODESEG
% public strcat, strcpy ; make both functions available
strcpy proc
push edi ; preserve edi
mov edi,[esp+8] ; edi points to dest string
jmp short copy_start
strcpy endp
align 16
strcat proc
.FPO ( 0, 2, 0, 0, 0, 0 )
mov ecx,[esp+4] ; ecx -> dest string
push edi ; preserve edi
test ecx,3 ; test if string is aligned on 32 bits
je short find_end_of_dest_string_loop
dest_misaligned: ; simple byte loop until string is aligned
mov al,byte ptr [ecx]
add ecx,1
test al,al
je short start_byte_3
test ecx,3
jne short dest_misaligned
align 4
find_end_of_dest_string_loop:
mov eax,dword ptr [ecx] ; read 4 bytes
mov edx,7efefeffh
add edx,eax
xor eax,-1
xor eax,edx
add ecx,4
test eax,81010100h
je short find_end_of_dest_string_loop
; found zero byte in the loop
mov eax,[ecx - 4]
test al,al ; is it byte 0
je short start_byte_0
test ah,ah ; is it byte 1
je short start_byte_1
test eax,00ff0000h ; is it byte 2
je short start_byte_2
test eax,0ff000000h ; is it byte 3
je short start_byte_3
jmp short find_end_of_dest_string_loop
; taken if bits 24-30 are clear and bit
; 31 is set
start_byte_3:
lea edi,[ecx - 1]
jmp short copy_start
start_byte_2:
lea edi,[ecx - 2]
jmp short copy_start
start_byte_1:
lea edi,[ecx - 3]
jmp short copy_start
start_byte_0:
lea edi,[ecx - 4]
; jmp short copy_start
; edi points to the end of dest string.
copy_start::
mov ecx,[esp+0ch] ; ecx -> sorc string
test ecx,3 ; test if string is aligned on 32 bits
je short main_loop_entrance
src_misaligned: ; simple byte loop until string is aligned
mov dl,byte ptr [ecx]
add ecx,1
test dl,dl
je short byte_0
mov [edi],dl
add edi,1
test ecx,3
jne short src_misaligned
jmp short main_loop_entrance
main_loop: ; edx contains first dword of sorc string
mov [edi],edx ; store one more dword
add edi,4 ; kick dest pointer
main_loop_entrance:
mov edx,7efefeffh
mov eax,dword ptr [ecx] ; read 4 bytes
add edx,eax
xor eax,-1
xor eax,edx
mov edx,[ecx] ; it's in cache now
add ecx,4 ; kick dest pointer
test eax,81010100h
je short main_loop
; found zero byte in the loop
; main_loop_end:
test dl,dl ; is it byte 0
je short byte_0
test dh,dh ; is it byte 1
je short byte_1
test edx,00ff0000h ; is it byte 2
je short byte_2
test edx,0ff000000h ; is it byte 3
je short byte_3
jmp short main_loop ; taken if bits 24-30 are clear and bit
; 31 is set
byte_3:
mov [edi],edx
mov eax,[esp+8] ; return in eax pointer to dest string
pop edi
ret
byte_2:
mov [edi],dx
mov eax,[esp+8] ; return in eax pointer to dest string
mov byte ptr [edi+2],0
pop edi
ret
byte_1:
mov [edi],dx
mov eax,[esp+8] ; return in eax pointer to dest string
pop edi
ret
byte_0:
mov [edi],dl
mov eax,[esp+8] ; return in eax pointer to dest string
pop edi
ret
strcat endp
end
PE>Да при том, что С# и дотнет не является панацеей. Универсальность и дешевизна разработки. Но в некоторых областях производительность важнее.
Так оно и есть. Вот только оценка этих областей за частую не верная.
PE>>>Почти — растяжимое поняте. Минимум 8 секунд при 20000 референсов.
VD>> 8 милисекунд будет более точной цифрой. Просто там кроме отслеживания еще много чего делается. А 8 сек. ЖЦ я в жизни не видел.
PE>Так профайлер говорит.
PE>>>Ой-ой. Мы год назад начали писать, сейчас первый релиз был. Это не просто граф. Это гиперграф. PE>>>Граф состоящий из графов. Всего различных объектов около 600. Вот они то и реализуют весь гиперграф.
VD>>И есть эквивалентные реализации для дотнета и С++?
PE>Есть. Все писали мы. Искренне жаль, но конкурентов до прошлого года у нас не было.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Жирным отмечены точки, которые невозможно оптимизировать в силу некоторых особенностей. PE>SetValidatableProperty — автоматическая валидация. Тут рефлексия. PE>GetPropertyDescriptionMapInternal — создаются тучи делегатов. PE>set_Name — имя объекта должно быть уникальным, следовательно нужно сообщеть буде это не так.
А что означают в конкретные колонки?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Я думаю, что нормальный путь — выдрать сериалайзер из ротора и кой какие пместа оптимизировать. Но неясно, как это толкнуть в обиход. Это есть нарушение. PE>А нам чу что придется написать примерно такой же форматтер.
Это очень сложно. Он там на мертво врос.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
VD>>Вы их генерируете что ли?
PE>А как еще ? Из УМЛ в C# и вперед.
Да только генераторами можно зафигачить такое количество кода. При ручной реализации его на порядок меньше будет.
PE>С этого нужно было и начинать А то завеи разговор про панацею.
Да про панацею никто и не говорит. Но дать совет не зная внутренних проблем невозможно. А разбираться для этого еще с одной наукой — это крыза.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Звук тебя не интересует, математика тоже, видео туда же. Меня это интересует,
Осталось определится в процентном соотношении таких как я и ты
PE> я не буду пользваться винампом, который перепишут полностью на дотнете.
Ты чего то наверное не понял цель шустриков. Они не для пользователей, они для программистов.
AVK>>Ты часто рары и зипы пишешь? Я нет.
PE>С помощью раров и зипов меряется реальный перформанс процессоров.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Зачем? Сложно реализовать подобие мультикаст делегата для интерфейсов?
PE>Вот предложи свой вариант на C# без дженериков.
Вариант не предложу, это все таки работа немаленькая, а вот какие то прикидки можно. Вот два примера простого мультикаст события и его аналога на интерфейсах. Вариант с событием разверну чтобы идея была понятнее.
public delegate SomeEventHandler(object sender, SomeEventArgs e);
public class EventProvider
{
private SomeEventHandler _someEvent;
public event SomeEventHandler SomeEvent
{
add
{
_someEventHandler += value;
}
remove
{
_someEventHandler -= value;
}
}
protected void OnSomeEvent(SomeEventArgs e)
{
if (_someEvent != null)
_someEvent(this, e);
}
}
public class EventConsumer
{
private EventProvider _eventProvider;
public EventConsumer(EventProvider ep)
{
_eventProvider = ep;
_eventProvider.SomeEvent += new SomeEventHandler(Handle);
}
~EventConsumer()
{
_eventProvider.SomeEvent -= new SomeEventHandler(Handle);
}
private void Handle(object sender, SomeEventArgs e)
{
// ...
}
}
Вариант с интерфейсом
public interface ISomeEventHandler
{
void Handle(object sender, SomeEventArgs e);
}
public class EventProvider
{
private ArrayList _eventConsumers = new ArrayList();
public void AddSomeEventHandler(ISomeEventHandler h)
{
_eventConsumers.Add(h);
}
public void RemoveSomeEventHandler(ISomeEventHandler h)
{
_eventConsumers.Remove(h);
}
protected void OnSomeEvent(SomeEventArgs e)
{
foreach (ISomeEventHandler h in _eventConsumers)
h.Handle(this, e);
}
}
public class EventConsumer : ISomeEventHandler
{
private EventProvider _eventProvider;
public EventConsumer(EventProvider ep)
{
_eventProvider = ep;
_eventProvider.AddSomeEventHandler(this);
}
~EventConsumer()
{
_eventProvider.RemoveSomeEventHandler(this);
}
void ISomeEventHandler.Handle(object sender, SomeEventArgs e)
{
// ...
}
}
В варианте с интерфейсом есть еще один плюс — ArrayList можно заменить на список с WeakReference, тем самым подписка на событие не будет блокировать работу GC.
PE>>>IConnectionPointContainer/IConnectionPoint AVK>>Давай СОМ не будем приплетать, совершенно понятно что дотнет не лучший способ с ним взаимодействия. PE>Дело не в COM а в спосое взаимодействии клиентов.
Вот и давай про СОМ забудем.
AVK>>Зачем выписывать? Вы же вроде генерите? Ну так и генерите наздоровье. Руками нужно будет только пару хелперов написать.
AVK>>Честно говоря чего то не вьехал что ты хотел показать. Зачем класс Event1?
PE>Класс, который реализует интерфейс обратной связи с другим объектом.
Не надо там никаких дополнительных классов. Класс-потребитель должен сам этот интерфейс реализовать.
PE>Для каждого члена класса нужно писать свою имплементацию интерфейса обратного вызова.
Это практически равносильно написанию обработчика события.
PE>Я имею в виду, что вначале нужно оптисаться от пары тройки уведомлений, а потом подписаться на все заново у другого объекта.
Ну и где здесь разница? Вместо +-= будут вызовы Add/Remove. Не думаю что такая замена сильно скажется на объеме работ.
PE>>>Мы юзаем эвенты и рефлексию. НО ! всеравно текста, который просто размножался копипейстом(два типа коллекций на каждый объект, валидатор, интерфейс основной) море !!! AVK>>Значит что то не так. Причем явно не так.
PE>Конечно не так. Пролема в том, что нам навязали С#. Без дженериков никуда.
Ах вон оно что. Значит навязали, а мы все равно пишем по старому .
AVK>>Ну так генерировать надо тоже с умом, чтобы в рантайме они легко отлавливались. При наличии нормального стектрейса и соблюдении определенных правил ничего страшного в рантайм-ошибках нет. PE>Легко на маленьгких прилах. PE> А если алгоритм сутки работает ?
Ты что думаешь, один ты тут большие программы пишешь? У нас вот тоже сервер 24х7. Только там не один алгоритм а целое их море.
PE>В любом случае перенос ошибок из компайлтайма в рантайм замедляет разработку.
AVK>В варианте с интерфейсом есть еще один плюс — ArrayList можно заменить на список с WeakReference, тем самым подписка на событие не будет блокировать работу GC.
Интересный момент. Где про это почитать можно ?
PE>>Дело не в COM а в спосое взаимодействии клиентов. AVK>Вот и давай про СОМ забудем.
А при чем здесь COM ? Я описываю в дотнете интерфейсы, который диктуют аналогичную функциональность. Вот и все. А с COM скрещивать я ничего не собираюсь.
PE>>Класс, который реализует интерфейс обратной связи с другим объектом. AVK>Не надо там никаких дополнительных классов. Класс-потребитель должен сам этот интерфейс реализовать.
Вот это я тебе и хотел показать.
PE>>Для каждого члена класса нужно писать свою имплементацию интерфейса обратного вызова. AVK>Это практически равносильно написанию обработчика события.
Вовсе нет. Интерфейс нужно объявлять полностью. А обработчики ты можешь вовсе опустить.
Еще нужна инициализация хитрая в конструкторах. С обработчиками этого нет.
PE>>Я имею в виду, что вначале нужно оптисаться от пары тройки уведомлений, а потом подписаться на все заново у другого объекта.
AVK>Ну и где здесь разница? Вместо +-= будут вызовы Add/Remove. Не думаю что такая замена сильно скажется на объеме работ.
А конструкторы ?
PE>>Конечно не так. Пролема в том, что нам навязали С#. Без дженериков никуда. AVK>Ах вон оно что. Значит навязали, а мы все равно пишем по старому .
Нет. Мы пишет так, что бы избежать копипейста и генерации текста(коллекции, интерфейсы). Это самая главная проблема.
копи
ошибках нет. PE>>Легко на маленьгких прилах. PE>> А если алгоритм сутки работает ?
AVK>Ты что думаешь, один ты тут большие программы пишешь? У нас вот тоже сервер 24х7. Только там не один алгоритм а целое их море.
PE>>В любом случае перенос ошибок из компайлтайма в рантайм замедляет разработку. AVK>К счастью на шарпе не сильно.
Что бы воспроивести ошибку может понадобиться писать скрипт на саксе ии руками кликать полчаса. Есть выход — винраннер подключить. Но для него тож скрипт нужен.
Здравствуйте, AndrewVK, Вы писали:
PE>>Звук тебя не интересует, математика тоже, видео туда же. Меня это интересует, AVK>Осталось определится в процентном соотношении таких как я и ты
Звук и ужималки это то, с чем сталкиваются почти все пользователи к компьютера.
Видео — туда же. Математика — это, конечно, узкая область.
PE>> я не буду пользваться винампом, который перепишут полностью на дотнете. AVK>Ты чего то наверное не понял цель шустриков. Они не для пользователей, они для программистов.
Вот и хотелось бы узнать, есть ли разница в производительности двух прилаг, писаных на дотнете и нативных. Ибо тормозное глюкало писать не хочется.
PE>>С помощью раров и зипов меряется реальный перформанс процессоров. AVK>И при чем тут перформанс процессора?
При том, что алгоритмы реальные и работают повсеместно, в отличие он синтетических шустриков.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>>>Звук тебя не интересует, математика тоже, видео туда же. Меня это интересует, AVK>>Осталось определится в процентном соотношении таких как я и ты PE>Звук и ужималки это то, с чем сталкиваются почти все пользователи к компьютера.
А причем тут пользователи? Речь о программистах.
AVK>>Ты чего то наверное не понял цель шустриков. Они не для пользователей, они для программистов.
PE>Вот и хотелось бы узнать, есть ли разница в производительности двух прилаг, писаных на дотнете и нативных.
Компилятором оно определяется в последнюю очередь. Если интересна производительность конкретного софта то ее и надо сравнивать, а не компиляторы, на которых оно компилировалось.
PE> Ибо тормозное глюкало писать не хочется.
Т.е. какие то компиляторы всегда делают тормозное глюкало?
PE>>>С помощью раров и зипов меряется реальный перформанс процессоров. AVK>>И при чем тут перформанс процессора?
PE>При том, что алгоритмы реальные и работают повсеместно,
Так алгоритмы или процессоры? Какое имеет отношение сравнение производительности процессоров к сравнению производительности компиляторов?
Здравствуйте, Plutonia Experiment, Вы писали:
PE>все это отлично. Только непонятно, что я буду делать вот в таком случае.
Честно говоря не понял в чем проблема.
PE>Интересный момент. Где про это почитать можно ?
В MSDN. Класс WeakReference
PE>>>Дело не в COM а в спосое взаимодействии клиентов. AVK>>Вот и давай про СОМ забудем.
PE>А при чем здесь COM ?
Вот и я о том же.
PE> Я описываю в дотнете интерфейсы, который диктуют аналогичную функциональность. Вот и все. А с COM скрещивать я ничего не собираюсь.
Тогда какое это имеет отношение к замене событий интерфейсами?
PE>>>Класс, который реализует интерфейс обратной связи с другим объектом. AVK>>Не надо там никаких дополнительных классов. Класс-потребитель должен сам этот интерфейс реализовать.
PE>Вот это я тебе и хотел показать.
При помощи еще одного класса? Странный однако ты выбрал способ сделать это.
PE>>>Для каждого члена класса нужно писать свою имплементацию интерфейса обратного вызова. AVK>>Это практически равносильно написанию обработчика события.
PE>Вовсе нет. Интерфейс нужно объявлять полностью.
Что значит объявлять полностью?
PE> А обработчики ты можешь вовсе опустить.
Не, чего то я тебя не пойму. Если тебе обработчики нужно опустить ты и интерфейс не реализуй.
PE>Еще нужна инициализация хитрая в конструкторах.
Что то в моем примере никакой хитрой инициализации нет. Ты о чем вобще?
AVK>>Ну и где здесь разница? Вместо +-= будут вызовы Add/Remove. Не думаю что такая замена сильно скажется на объеме работ.
PE>А конструкторы ?
Что конструкторы?
PE>>>В любом случае перенос ошибок из компайлтайма в рантайм замедляет разработку. AVK>>К счастью на шарпе не сильно.
PE>Что бы воспроивести ошибку может понадобиться писать скрипт на саксе ии руками кликать полчаса.
Так надо так строить приложение чтобы легко было имитировать внешнюю среду для отдельных блоков. Еще юнит тестирование в таких случаях рулит.
PE> Есть выход — винраннер подключить.
Не знаю кто такой.
PE> Но для него тож скрипт нужен.
А вы как вобще отлаживаетесь? Или вы сразу без ошибок пишете?
Здравствуйте, AndrewVK, Вы писали:
PE>>>>Звук тебя не интересует, математика тоже, видео туда же. Меня это интересует, AVK>>>Осталось определится в процентном соотношении таких как я и ты PE>>Звук и ужималки это то, с чем сталкиваются почти все пользователи к компьютера.
AVK>А причем тут пользователи? Речь о программистах.
Т.е. пользователи сук и быдло и не могут интесеваться производительностью ПО за которое платят деньги ?
Программисты пишут не просто так, а для конкретных людей.
PE>>Вот и хотелось бы узнать, есть ли разница в производительности двух прилаг, писаных на дотнете и нативных.
AVK>Компилятором оно определяется в последнюю очередь. Если интересна производительность конкретного софта то ее и надо сравнивать, а не компиляторы, на которых оно компилировалось.
Вот я и хочу сравнить перформанс двух прилаг — нативной ужималки и такой же, но менеджед.
Мне дают диск на двадцать минут. Есть возможность взять прилу подешевле, но менеджед, или подороже, но нативную. Какой ужималкой я смогу ужать за 20 минут весь аудиодиск?
PE>> Ибо тормозное глюкало писать не хочется. AVK>Т.е. какие то компиляторы всегда делают тормозное глюкало?
Конечно. Но не только компилеры. Среда тоже может "помочь".
PE>>При том, что алгоритмы реальные и работают повсеместно,
AVK>Так алгоритмы или процессоры? Какое имеет отношение сравнение производительности процессоров к сравнению производительности компиляторов?
Нужно перегнать DVD в MPEG4.
Ты платишь за время бабло — 3$ в час допустим.
И есть выбор в железе, в компилерах, в среде, в джите, если есть.
Задача — определить, на какой конфигурации можно получить минимальные временные затраты.
Вот и выбирай (P3, P4) (пямяти 256) (прага нативная, дотнетовская, жава)
1. Процессор кривой — время большое будет.
2. Среда кривая — время большое.
3. Компилер кривой — время большое.
4. Джит кривой — время большое.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>А причем тут пользователи? Речь о программистах.
PE>Т.е. пользователи сук и быдло
Я этого не говорил.
PE> и не могут интесеваться производительностью ПО
Может. Но шустрики не для него.
PE> за которое платят деньги ?
Пользователь платит деньги за компиляторы? Это что то новенькое.
AVK>>Компилятором оно определяется в последнюю очередь. Если интересна производительность конкретного софта то ее и надо сравнивать, а не компиляторы, на которых оно компилировалось.
PE>Вот я и хочу сравнить перформанс двух прилаг — нативной ужималки и такой же, но менеджед. PE>Мне дают диск на двадцать минут. Есть возможность взять прилу подешевле, но менеджед, или подороже, но нативную. PE> Какой ужималкой я смогу ужать за 20 минут весь аудиодиск?
Думается мне что реализация и алгоритмы в данной ситуации значительно важнее нежели использованные компиляторы. Ты вот навскидку, не гляда скажи — на каком компиляторе скомпилирован декодер винампа? Наверняка не ответишь. Я вот точно не знаю. Потому что мне пофигу. А уж среднестатистический пользователь просто не сможет на этот вопрос ответить.
PE>>> Ибо тормозное глюкало писать не хочется. AVK>>Т.е. какие то компиляторы всегда делают тормозное глюкало?
PE>Конечно. Но не только компилеры. Среда тоже может "помочь".
Среда выполнения в смысле? Ну то есть на дотнете можно написать только тормозное глюкало, ты это хочешь сказать? Я твою мысль понял. Т.е. из ненависти к дотнету, на котором тебя заставляют писать глупые начальники ты очень хочешь добавитьтакой тест чтобы дотнет на нем выглядет как можно хуже. Так что ли?
AVK>>Так алгоритмы или процессоры? Какое имеет отношение сравнение производительности процессоров к сравнению производительности компиляторов?
PE>Нужно перегнать DVD в MPEG4. PE>Ты платишь за время бабло — 3$ в час допустим. PE>И есть выбор в железе, в компилерах, в среде, в джите, если есть. PE>Задача — определить, на какой конфигурации можно получить минимальные временные затраты.
Так, понятно чем ты на работе в качестве программиста занимаешься.
Напоминаю в который уже раз — в шустриках никто не тестирует и не будет тестировать процессоры и прочее железо, а так же конкретный прикладной софт для обработки звука и видео. Там тестировали и тестируют компиляторы.
Здравствуйте, AndrewVK, Вы писали:
PE>>не могут интесеваться производительностью ПО за которое платят деньги ? AVK>Пользователь платит деньги за компиляторы? Это что то новенькое.
Компилятор влияет на производительность ПО. Так понятнее. И не выдергивай слова из фразы.Это не к лицу модератору.
PE>>Вот я и хочу сравнить перформанс двух прилаг — нативной ужималки и такой же, но менеджед. PE>>Мне дают диск на двадцать минут. Есть возможность взять прилу подешевле, но менеджед, или подороже, но нативную. PE>> Какой ужималкой я смогу ужать за 20 минут весь аудиодиск?
AVK>Думается мне что реализация и алгоритмы в данной ситуации значительно важнее нежели использованные компиляторы. Ты вот навскидку, не гляда скажи — на каком компиляторе скомпилирован декодер винампа? Наверняка не ответишь. Я вот точно не знаю. Потому что мне пофигу. А уж среднестатистический пользователь просто не сможет на этот вопрос ответить.
Конечно. Но все пользуются именно винампом, потому, что он не такой тормозной, как многие его конкуренты.
PE>>>> Ибо тормозное глюкало писать не хочется. AVK>>>Т.е. какие то компиляторы всегда делают тормозное глюкало?
Конечно. Это в ваших шустриках и написано, что одни компилеры дают шустрый код, другие тормозной.
AVK>Среда выполнения в смысле? Ну то есть на дотнете можно написать только тормозное глюкало, ты это хочешь сказать? Я твою мысль понял. Т.е. из ненависти к дотнету, на котором тебя заставляют писать глупые начальники ты очень хочешь добавитьтакой тест чтобы дотнет на нем выглядет как можно хуже. Так что ли?
Нет. Мне интересно, стоит ли браться за написание проги по звуку на дотнете или на нативном С++, если за нее заплатят деньги и при этом критичен перформанс.
PE>>Нужно перегнать DVD в MPEG4. PE>>Ты платишь за время бабло — 3$ в час допустим. PE>>И есть выбор в железе, в компилерах, в среде, в джите, если есть. PE>>Задача — определить, на какой конфигурации можно получить минимальные временные затраты. AVK>Напоминаю в который уже раз — в шустриках никто не тестирует и не будет тестировать процессоры и прочее железо, а так же конкретный прикладной софт для обработки звука и видео. Там тестировали и тестируют компиляторы.
Отлично. Сделаем по твоему. Процессоры одинаковые и железо одинаковое.
Осталось сравнить три продукта (нативный, дотнетовский, жавовский).
Здравствуйте, AndrewVK, Вы писали:
PE>>А при чем здесь COM ? AVK>Вот и я о том же.
Про COM ты сам вспомнил. Я ничего не говорил. Я предложил идею реализации, аналогичную комовской.
PE>> Я описываю в дотнете интерфейсы, который диктуют аналогичную функциональность. Вот и все. А с COM скрещивать я ничего не собираюсь.
AVK>Тогда какое это имеет отношение к замене событий интерфейсами?
Это ты предложил интерфейсы и даже собственную реализацию привел.
PE>>Вот это я тебе и хотел показать. AVK>При помощи еще одного класса? Странный однако ты выбрал способ сделать это.
PE>>>>Для каждого члена класса нужно писать свою имплементацию интерфейса обратного вызова. AVK>>>Это практически равносильно написанию обработчика события.
PE>>Вовсе нет. Интерфейс нужно объявлять полностью.
AVK>Что значит объявлять полностью?
PE>> А обработчики ты можешь вовсе опустить.
AVK>Не, чего то я тебя не пойму. Если тебе обработчики нужно опустить ты и интерфейс не реализуй.
PE>>Еще нужна инициализация хитрая в конструкторах.
AVK>Что то в моем примере никакой хитрой инициализации нет. Ты о чем вобще?
AVK>>>Ну и где здесь разница? Вместо +-= будут вызовы Add/Remove. Не думаю что такая замена сильно скажется на объеме работ.
PE>>А конструкторы ? AVK>Что конструкторы?
А в конструкторах по твоему методу нужно приинициализировать все инстанцы, которые заведуют оработкой событий от объекта i-ой проперти. Им нужно this сообщить.
PE>>>>В любом случае перенос ошибок из компайлтайма в рантайм замедляет разработку. AVK>>>К счастью на шарпе не сильно.
AVK>Так надо так строить приложение чтобы легко было имитировать внешнюю среду для отдельных блоков. Еще юнит тестирование в таких случаях рулит.
Для сетевой модели сложность написания тестов O(n**2). Вперед !
Так что внешние тесты подходят только на начальной стадии разработки, когда реализются базовые механизмы:
1. Коллекции
2. Механизм отписки-подписки
3. Простую валидацию
Загрузку и сохранение уже не протестируешь не говоря об самых маленьких алгоритмах.
PE>> Есть выход — винраннер подключить. AVK>Не знаю кто такой.
Это прила для тестирования других прил
PE>> Но для него тож скрипт нужен. AVK>А вы как вобще отлаживаетесь? Или вы сразу без ошибок пишете?
Конечно отлаживаемся. Но перенос отлов ошибок в ранайме достает неслабо.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>>>не могут интесеваться производительностью ПО за которое платят деньги ? AVK>>Пользователь платит деньги за компиляторы? Это что то новенькое.
PE>Компилятор влияет на производительность ПО.
Влияет. Только шустрики не об этом.
PE>И не выдергивай слова из фразы.Это не к лицу модератору.
Во-первых это демагогия. Во-вторых я как нибудь сам определюсь что мне к лицу. В-третьих тот кто это письмо читает наверняка читал предыдущее, а если нет то без проблем прочитает, так что оверквотинг разводить не имеет смысла.
PE>Конечно. Но все пользуются именно винампом, потому, что он не такой тормозной, как многие его конкуренты.
Вот только шустрики не о производительности декодеров mp3.
AVK>>>>Т.е. какие то компиляторы всегда делают тормозное глюкало?
PE>Конечно. Это в ваших шустриках и написано, что одни компилеры дают шустрый код, другие тормозной.
А про глюки там тоже написано или ты для красного словца?
PE>Нет. Мне интересно, стоит ли браться за написание проги по звуку на дотнете или на нативном С++,
На этот вопрос сможешь ответить только ты сам.
AVK>>Напоминаю в который уже раз — в шустриках никто не тестирует и не будет тестировать процессоры и прочее железо, а так же конкретный прикладной софт для обработки звука и видео. Там тестировали и тестируют компиляторы.
PE>Отлично. Сделаем по твоему. Процессоры одинаковые и железо одинаковое. PE>Осталось сравнить три продукта (нативный, дотнетовский, жавовский).
Вот и возвращаемся к исходному вопросу — нафига там тестировать алгоритмы упаковки звука, если процент программистов, на которых эта статья нацелена, занимающихся звуком весьма мал?
Здравствуйте, Plutonia Experiment, Вы писали:
PE>>>А при чем здесь COM ? AVK>>Вот и я о том же.
PE>Про COM ты сам вспомнил.
Ага, и Влад тоже, синхронно со мной. А ты как бы про него даже не писал.
PE> Я ничего не говорил.
Цитату привести?
AVK>>Тогда какое это имеет отношение к замене событий интерфейсами? PE>Это ты предложил интерфейсы и даже собственную реализацию привел.
Предложил не я. Я тебе ответил на вопрос как примерно это можно реализовать.
[оверквотинг поскипан] (ты кстати, если не отвечаешь то не цитируй простыни)
Я так понимаю что по лишним классам вопросов нет?
PE>>>А конструкторы ? AVK>>Что конструкторы?
PE>А в конструкторах по твоему методу нужно приинициализировать все инстанцы, которые заведуют оработкой событий от объекта i-ой проперти. Им нужно this сообщить.
Чего то я не понял. Инициализировать ничего не нужно. this нужен при подписке на событие. Нужен он притом в обоих вариантах, просто в случае с делегатом компилятор втыкает его неявно. Что то я не вижу тут никакой разницы.
AVK>>Так надо так строить приложение чтобы легко было имитировать внешнюю среду для отдельных блоков. Еще юнит тестирование в таких случаях рулит.
PE>Для сетевой модели сложность написания тестов O(n**2).
Сам придумал? Сложность тестов зависит не от структуры данных, а от структуры приложения. Те баги о которых шла речь к трудноулавливаемым не относятся. Кроме того я что то не пойму — а вы сейчас вобще не тестируете?
PE> Вперед !
Да у меня то как раз никаких проблем. Вон в дизайнере нашем очень даже сетевая структура и очень даже много генеренного кода. И ничего, как то справляемся.
PE>Загрузку и сохранение уже не протестируешь
Чего так? Ты ж учти — кодогенератор генерирует все одинаково. Если ты отладишь самый сложный класс, то остальные автоматом так же будут отлажены, правишь то ты генератор, а не конкретный класс. Так что в итоге задачка сводится не к отладке моря кода, который генерится, а к отладке единственного генератора.
PE> не говоря об самых маленьких алгоритмах.
А при чем тут генератор? Ручные алгоритмы надо отлаживать в любой ситуации, генеришь ты код или руками пишешь неважно.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Plutonia Experiment, Вы писали:
PE>>>>не могут интесеваться производительностью ПО за которое платят деньги ? AVK>>>Пользователь платит деньги за компиляторы? Это что то новенькое.
PE>>Компилятор влияет на производительность ПО.
AVK>Влияет. Только шустрики не об этом.
PE>>И не выдергивай слова из фразы.Это не к лицу модератору.
AVK>Во-первых это демагогия.
Вот моя интерпретация
"производительностью ПО за которое платят деньги"
Вот твоя
"ПО за которое платят деньги"+ "Пользователь платит деньги за компиляторы? "
PE>>Конечно. Но все пользуются именно винампом, потому, что он не такой тормозной, как многие его конкуренты.
AVK>Вот только шустрики не о производительности декодеров mp3.
Наконец то. А о чем ? Обо всем, что некасается этого ? Не верю !
AVK>>>>>Т.е. какие то компиляторы всегда делают тормозное глюкало? PE>>Конечно. Это в ваших шустриках и написано, что одни компилеры дают шустрый код, другие тормозной.
AVK>А про глюки там тоже написано или ты для красного словца?
Глюкало было в контексте в отношении двух подопытных. Ссылку дать ?
PE>>Нет. Мне интересно, стоит ли браться за написание проги по звуку на дотнете или на нативном С++, AVK>На этот вопрос сможешь ответить только ты сам.
Этот вопрос интересует не только меня. Глядя на вашу синтетику, я могу сказать, что на синтетике дотнет немеряно крут. если вы писали синтетику ради синтетики в академических интересах — у меня вопросов нет более.
PE>>Отлично. Сделаем по твоему. Процессоры одинаковые и железо одинаковое. PE>>Осталось сравнить три продукта (нативный, дотнетовский, жавовский).
AVK>Вот и возвращаемся к исходному вопросу — нафига там тестировать алгоритмы упаковки звука, если процент программистов, на которых эта статья нацелена, занимающихся звуком весьма мал?
Отвечаю в который раз — хочется выяснить область применения дотнета. Для того и тестируют, чтобы знать, какой выбор делать.
Если ты считаешь,что программисты пишут только распределенные корпоративные системы, то глубоко заблуждаешься.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>>>Компилятор влияет на производительность ПО.
AVK>>Влияет. Только шустрики не об этом.
PE>>>И не выдергивай слова из фразы.Это не к лицу модератору.
AVK>>Во-первых это демагогия.
Т.е. это тот кусок к которому у тебя притензии? Ага, интересно. И что же я выкинул из цитаты?
PE>>>Конечно. Но все пользуются именно винампом, потому, что он не такой тормозной, как многие его конкуренты.
AVK>>Вот только шустрики не о производительности декодеров mp3.
PE>Наконец то. А о чем ? Обо всем, что некасается этого ? Не верю !
Ты наверное будешь удивлен, но о компиляторах.
PE>>>Нет. Мне интересно, стоит ли браться за написание проги по звуку на дотнете или на нативном С++, AVK>>На этот вопрос сможешь ответить только ты сам. PE>Этот вопрос интересует не только меня.
А кого еще? Только не надо про пользователей.
PE> Глядя на вашу синтетику, я могу сказать, что на синтетике дотнет немеряно крут. если вы писали синтетику ради синтетики в академических интересах — у меня вопросов нет более.
Предложи алгоритмы, используемые значительной частью программистов. Программистов, заметь, не пользователей.
AVK>>Вот и возвращаемся к исходному вопросу — нафига там тестировать алгоритмы упаковки звука, если процент программистов, на которых эта статья нацелена, занимающихся звуком весьма мал?
PE>Отвечаю в который раз — хочется выяснить область применения дотнета.
Напоминаю в который раз что шустрики не об этом. Если хочешь — протестируй сам и напиши свою статью о компиляторах в обработке звука, мы ее с удовольствием опубликуем.
PE>Если ты считаешь,что программисты пишут только распределенные корпоративные системы, то глубоко заблуждаешься.
Нет конечно, но очень приличное количество их. Можешь провести опрос кто чем занимается.
Здравствуйте, AndrewVK, Вы писали:
PE>>>>А при чем здесь COM ? AVK>>>Вот и я о том же. PE>>Про COM ты сам вспомнил. AVK>Ага, и Влад тоже, синхронно со мной. А ты как бы про него даже не писал.
Я предложил реализовать механизм, аналогичный IConnectionPointContainer.
PE>> Я ничего не говорил. AVK>Цитату привести?
Давай.
AVK>>>Тогда какое это имеет отношение к замене событий интерфейсами? PE>>Это ты предложил интерфейсы и даже собственную реализацию привел.
AVK>Предложил не я. Я тебе ответил на вопрос как примерно это можно реализовать.
Вот в этой примерной реализации и были интерфейсы.
AVK>[оверквотинг поскипан] (ты кстати, если не отвечаешь то не цитируй простыни) AVK>Я так понимаю что по лишним классам вопросов нет?
PE>>>>А конструкторы ? AVK>>>Что конструкторы?
PE>>А в конструкторах по твоему методу нужно приинициализировать все инстанцы, которые заведуют оработкой событий от объекта i-ой проперти. Им нужно this сообщить.
AVK>Чего то я не понял. Инициализировать ничего не нужно. this нужен при подписке на событие. Нужен он притом в обоих вариантах, просто в случае с делегатом компилятор втыкает его неявно. Что то я не вижу тут никакой разницы.
PE>>Для сетевой модели сложность написания тестов O(n**2).
AVK>Сам придумал? Сложность тестов зависит не от структуры данных, а от структуры приложения. Те баги о которых шла речь к трудноулавливаемым не относятся.
Структура модели данных — гиперграф это и есть аппликация, если тестируешь только это. Это отдельная часть проекта.
Вот для него то сложность тестирования и равна O(n**2)
Баги, про которые я сказал, естественно не относятся к трудноулавливаемым. Но объемы тестирования очень велики.
PE>> Вперед !
AVK>Да у меня то как раз никаких проблем. Вон в дизайнере нашем очень даже сетевая структура и очень даже много генеренного кода. И ничего, как то справляемся.
Сетевая какой сложности ? Давай сравним.
PE>>Загрузку и сохранение уже не протестируешь
AVK>Чего так? Ты ж учти — кодогенератор генерирует все одинаково. Если ты отладишь самый сложный класс, то остальные автоматом так же будут отлажены, правишь то ты генератор, а не конкретный класс. Так что в итоге задачка сводится не к отладке моря кода, который генерится, а к отладке единственного генератора.
Мы именно так и делаем. Только речь шла про тесты. Каким это кодогенератором ты пртестируешь загрузку-сохранение модели ?
PE>> не говоря об самых маленьких алгоритмах.
AVK>А при чем тут генератор? Ручные алгоритмы надо отлаживать в любой ситуации, генеришь ты код или руками пишешь неважно.
Вот тут то и проблема. Для графа с количеством узлов N надо перебрать O(N**2) ситуаций для тестирования алгоритма. Если это делать отдельно от прилаги основном, то ты просто повесишься.
Сама прила берет на себя чоень многое. Тестируется все чз. винраннер и скрипты.
Версия тестируется примерно 10000...50000 часов. Баги проверяются уже на отловленых специфичных ситуациях.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Сам придумал? Сложность тестов зависит не от структуры данных, а от структуры приложения. Те баги о которых шла речь к трудноулавливаемым не относятся.
PE>Структура модели данных — гиперграф это и есть аппликация, если тестируешь только это. Это отдельная часть проекта. PE>Вот для него то сложность тестирования и равна O(n**2)
Но речь то не о тестировании гиперграфа, который при любом раскладе тестировать нужно. Речь о тестировании генератора.
AVK>>Да у меня то как раз никаких проблем. Вон в дизайнере нашем очень даже сетевая структура и очень даже много генеренного кода. И ничего, как то справляемся.
PE>Сетевая какой сложности ? Давай сравним.
Пиписьками мерятся? И в чем сложность оценивать? В численных характеристиках? Несколько десятков сущностей, до 1 млн. экземпляров.
PE>Мы именно так и делаем. Только речь шла про тесты. Каким это кодогенератором ты пртестируешь загрузку-сохранение модели ?
Речь шла о том что перенесение части ошибок в рантайм из-за использования генератора не так уж и страшна.
AVK>>А при чем тут генератор? Ручные алгоритмы надо отлаживать в любой ситуации, генеришь ты код или руками пишешь неважно.
PE>Вот тут то и проблема. Для графа с количеством узлов N надо перебрать O(N**2) ситуаций для тестирования алгоритма. Если это делать отдельно от прилаги основном, то ты просто повесишься.
А смысл? Стоимость перебора вариантов всегда очень высока. Обычно обходятся использованием стабильных и предсказуемых алгоритмов и тестирования характерных случаев.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Во-первых это демагогия.
AVK>Т.е. это тот кусок к которому у тебя притензии? Ага, интересно. И что же я выкинул из цитаты?
слово "производительность" ты оставил на верхней строчке и ответил на последнюю часть фразы без слова производительность. Это в корне меняет ситуацию.
AVK>>А причем тут пользователи? Речь о программистах.
PE>Т.е. пользователи сук и быдло
Я этого не говорил.
PE> и не могут интесеваться производительностью ПО
Может. Но шустрики не для него.
PE> за которое платят деньги ?
Пользователь платит деньги за компиляторы? Это что то новенькое.
Как из моей фразы следует утверждение "Пользователь платит деньги за компиляторы." ?
Компилятор влияет на производительность ПО за которое пользователи платят деньги.
PE>>>>Нет. Мне интересно, стоит ли браться за написание проги по звуку на дотнете или на нативном С++, AVK>>>На этот вопрос сможешь ответить только ты сам. PE>>Этот вопрос интересует не только меня.
AVK>А кого еще? Только не надо про пользователей.
PE>> Глядя на вашу синтетику, я могу сказать, что на синтетике дотнет немеряно крут. если вы писали синтетику ради синтетики в академических интересах — у меня вопросов нет более.
AVK>Предложи алгоритмы, используемые значительной частью программистов. Программистов, заметь, не пользователей.
Почти все мои одногруптики раобтают на госпредприятиях. Основная часть — военка, моделирование и всякая математика. Многие работают со звком. Сжатие звука для передачи по модемным сетям хитрым. Сжатие для тел станций. Запись под диктовку, верификация и тд. Имитация шумов. Распознавание изображений(выделение номеров машин). Много чего. Достаточно ?
С БД работают очень мало.
Здравствуйте, AndrewVK, Вы писали:
PE>>Структура модели данных — гиперграф это и есть аппликация, если тестируешь только это. Это отдельная часть проекта. PE>>Вот для него то сложность тестирования и равна O(n**2)
AVK>Но речь то не о тестировании гиперграфа, который при любом раскладе тестировать нужно. Речь о тестировании генератора.
Ну протестирую я генератор колекций, и что с того ? Колекции — это пыль, их по одному шалону в ЕА создаем. Написали генератор текста(на жаве ) и все пучком.
Генерировать нужно совсем другое.
AVK>>>Да у меня то как раз никаких проблем. Вон в дизайнере нашем очень даже сетевая структура и очень даже много генеренного кода. И ничего, как то справляемся.
А новые люди сколько в этом разбираются ?
PE>>Сетевая какой сложности ? Давай сравним.
AVK>Пиписьками мерятся? И в чем сложность оценивать? В численных характеристиках? Несколько десятков сущностей, до 1 млн. экземпляров.
Если ваша с сеть однороная, то хоть миллиарды. У нас примерно 600 классов, писаных от руки.
Все классы очень сильно отличаются друг от друга. Это представление сети на разных уровнях.
Сети, сегменты, подсети, узлы, связи, волокна, траффик, пути, таблицы различные (не коллекции). Технологии, информация об оборудовании, информация о конфигурации этого оборудования. Каждый элемент должен имеет тип, имя, описание. Каждый имеет свой рисунок.
По какому принципу генерировать — непонятно. Все это описывается в соответсвующих разделах теории оптических сетей.
AVK>А смысл? Стоимость перебора вариантов всегда очень высока. Обычно обходятся использованием стабильных и предсказуемых алгоритмов и тестирования характерных случаев.
Каждый случай в графе это характерный. Если есть подозрение, что алгоритм генерирует неоптимальное решение, то очень сложно выявить ошибку. Иногда такие ошибки ищутся месяцами.
Это ты реалзовал простейший случай. В одном классе может быть несколько консумеров.
Вот во что это превращается реально. Этот вариант мы уже отрабатывали.
AVK>public class EventConsumer
AVK>{
выделенные фрагменты кода при наличии дженериков или рефлексии можно услать в базовый класс.
без дженериков или рефлексии мне нужна информация о типе
[Serialized]
class Property1EventProviderHolder : ISomeEventHandler
{
// от этого никуда не деться.public void OnChanging(object sender, ChangingEventArgs args)
{
EventProvider ep = (EventProvider)sender;
if(m_THIS.PropertyN == somevalue) args.Cancel = true;
if(...)
}
public void OnChanged(object sender, ChangedEventArgs args)
{
Do Anything
or
m_THIS.DeleteSelf();
}
public void OnDisposing(object sender, DisposingEventArgs args)
{
EventProvider ep = (EventProvider)sender;
if(m_THIS.PropertyN == somevalue) args.Cancel = true;
if(...)
}
public void OnDisposed(object sender, DisposedEventArgs args)
{
m_value = null;
or
m_THIS.DeleteSelf();
}
public void Validate(EventProvider val)
{
EventConsumer.Validators.ValidateProperty1(m_THIS, val);
}public void Set(Property1EventProviderHolder THIS, EventProvider value)
{
m_THIS = THIS;
Validate(value); // здесь бросается эксцепшн.if(value == m_value)
return;
if(propertyName == null)
throw new ArgumentNullException("Property1");
if(m_value != null)
{
m_value.RemoveSomeEventHandler(this);
if(m_bComposite)
m_value.DeleteSelf();
}
if(value != null)
value.AddSomeEventHandler(this);
value = m_value;
}
EventProvider m_value = null;
Property1EventProviderHolder THIS=null;
}
Property1EventProviderHolder m_property1;
public EventProviderHolder Property1
{
get{ return m_property1.m_value;}
set
{ m_property1.Set(this,value); }
}
}
}
После того, как ты разобрался, умножь это все на 20 — именно столько пропертей может слушаться одновременно. Еще 10 пропроще.
Если писать в одном интерфейсе аж 4 эвента, то получается классов нужно оъявлять меньше.
Но тогда будет много методов пустых.
Если интерфейсы из одного метода, то получится тоже самое, что и у нас сейчас, только кода побольше будет.
Нам удалось сделать так, что в большинстве случаев оработчики либо пустые (их вовсе нет) либо по одному-два.
Но это еще не все.
При серилизации увеличивается время — количество ссылок на оъект увеличивается примерно в три раза !
Сейчас у меня 1 пропертя — одна ссылка.
В такой схеме — m_property,m_value и обратная ссылка — 3.
При десерилизации экономится немного времени на создание делегатов. Количество объектов увеличивается в 1.5 ... 2 и из за O(n**2) десерилизации все это малозаметно. Больше двх раз не может быть — по одному на каждую пропертю.
А вот будь у меня дженерики... Десерилизация и серилизация все равно будут тормозить. Но зато количесво рефлекшна уменьшится очень сильно ! Итого — нужно писать сериалайзер.
ИТОГО: Кода в твоем случае получается поболее... C эвентами и рефлекшном нам удалось
Здравствуйте, VladD2, Вы писали:
PE>>Я думаю, что нормальный путь — выдрать сериалайзер из ротора и кой какие пместа оптимизировать. Но неясно, как это толкнуть в обиход. Это есть нарушение. PE>>А нам чу что придется написать примерно такой же форматтер.
VD>Это очень сложно. Он там на мертво врос.
Это очень просто ! Выдираешь исходники форматтера, ObjectIDGenerator, подсовываешь свои заглушки для ресурсов и кой каких фейковых классов, комментируешь дебаговую муть и юзаешь.
Здравствуйте, Plutonia Experiment, Вы писали:
PE> PE>Это очень просто ! Выдираешь исходники форматтера, ObjectIDGenerator, подсовываешь свои заглушки для ресурсов и кой каких фейковых классов, комментируешь дебаговую муть и юзаешь.
PE>Могу выслать готовый проект.
Давай. Это даже интересно.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
PE>> PE>>Это очень просто ! Выдираешь исходники форматтера, ObjectIDGenerator, подсовываешь свои заглушки для ресурсов и кой каких фейковых классов, комментируешь дебаговую муть и юзаешь.
PE>>Могу выслать готовый проект.
VD>Давай. Это даже интересно.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Т.е. это тот кусок к которому у тебя притензии? Ага, интересно. И что же я выкинул из цитаты?
PE>слово "производительность" ты оставил на верхней строчке
Блин, уписаться можно. Я уже не так отформатировал. Вобщем демагогия. Нечего сказать начинаешь придираться к тому что на какой строчке расположено.
AVK>>Предложи алгоритмы, используемые значительной частью программистов. Программистов, заметь, не пользователей.
PE>Почти все мои одногруптики раобтают на госпредприятиях.
Несчастные. А у меня наверное уже никто не работает.
PE> Основная часть — военка, моделирование и всякая математика. Многие работают со звком. Сжатие звука для передачи по модемным сетям хитрым. Сжатие для тел станций. Запись под диктовку, верификация и тд. Имитация шумов. Распознавание изображений(выделение номеров машин). Много чего. PE>Достаточно ?
Нет. Почему ты решил что твои одногрупники являются основной аудиторией сайта и журнала?
Здравствуйте, Plutonia Experiment, Вы писали:
PE> [Serialized]
Serializable?
PE> class Property1EventProviderHolder : ISomeEventHandler
Опять какая то ерунда. Зачем на каждое свойство заводить отдельный класс?
PE>После того, как ты разобрался, умножь это все на 20 — именно столько пропертей может слушаться одновременно. Еще 10 пропроще.
Не, ну до маразма что угодно можно довести.
PE>Если писать в одном интерфейсе аж 4 эвента, то получается классов нужно оъявлять меньше.
Зачем? Ты опять чего то не понял. 1 интерфейс = 1 тип эвента. Если класс подписывается на несколько разных типов эвентов он реализует несколько интерфейсов.
PE>Если интерфейсы из одного метода, то получится тоже самое, что и у нас сейчас, только кода побольше будет.
О том и речь.
PE>ИТОГО: Кода в твоем случае получается поболее...
Побольше, в основном в источнике события, а вот в потребителе даже поменьше получается.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Ну протестирую я генератор колекций, и что с того ?
То что генеренный код после этого при изменении входных данных особо тестировать не надо.
AVK>>>>Да у меня то как раз никаких проблем. Вон в дизайнере нашем очень даже сетевая структура и очень даже много генеренного кода. И ничего, как то справляемся.
PE>А новые люди сколько в этом разбираются ?
Нету у нас таких.
AVK>>Пиписьками мерятся? И в чем сложность оценивать? В численных характеристиках? Несколько десятков сущностей, до 1 млн. экземпляров.
PE>Если ваша с сеть однороная, то хоть миллиарды.
Я же написал — несколько десятков сущностей. Какая она однородная? Связи тоже нескольких типов.
Да, естественно ни о какой автоматической сериализации я даже не думал. Запись целиком собственная, в БД, с кешированием и сериализацией только измененных частей. Иначе это при любом варианте автоматической тормоза. А мне надо чтобы сохранение изменений занимало не более 1-2 секунд.
PE> У нас примерно 600 классов, писаных от руки.
Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.
PE>По какому принципу генерировать — непонятно.
Принцип очень простой. Как бы они ни были неоднородны, если ты их обрабатываешь где то по одинаковым правилам (ну сериализуешь к примеру), значит что то общее в них есть. Вот тебе и основа для генератора.
PE>Каждый случай в графе это характерный. Если есть подозрение, что алгоритм генерирует неоптимальное решение, то очень сложно выявить ошибку. Иногда такие ошибки ищутся месяцами.
ИМХО это сигнал для серьезного пересмотра дизайна программы.
Здравствуйте, AndrewVK, Вы писали:
PE>> Основная часть — военка, моделирование и всякая математика. Многие работают со звком. Сжатие звука для передачи по модемным сетям хитрым. Сжатие для тел станций. Запись под диктовку, верификация и тд. Имитация шумов. Распознавание изображений(выделение номеров машин). Много чего. PE>>Достаточно ?
AVK>Нет. Почему ты решил что твои одногрупники являются основной аудиторией сайта и журнала?
К сайту и журналу они никакого отношения не имеют. У троих только инет есть.
А журнал в Минске... лучше изредка оффлайновые версии посматривать.
Здравствуйте, AndrewVK, Вы писали:
PE>> [Serialized] AVK>Serializable?
Да.
PE>> class Property1EventProviderHolder : ISomeEventHandler
AVK>Опять какая то ерунда. Зачем на каждое свойство заводить отдельный класс?
А как по другому ? Объект одновременно и подписчик десятков эвентов и консумер стольких.
А еще есть эвенты от коллекций например.
PE>>После того, как ты разобрался, умножь это все на 20 — именно столько пропертей может слушаться одновременно. Еще 10 пропроще.
AVK>Не, ну до маразма что угодно можно довести.
Сложность задачи определяет кастомер, а не мы.
Конечно, с твоей точки зрения это маразм, потому что ты не представляешь модели оптической сети. Заказчики наши это не рядовые предприятия и тд. Это отдельные государства, крупные корпорации. Для такого мастшаба требуется гораздо сложнее модель, чем у нас.
Мы лишь упростили максимально. Но в люом случае сложность очень высокая.
PE>>Если интерфейсы из одного метода, то получится тоже самое, что и у нас сейчас, только кода побольше будет. AVK>О том и речь.
Так а зачем лишний код ? Нам и так пролему приходится решать с нынешним количесвом.
PE>>ИТОГО: Кода в твоем случае получается поболее... AVK>Побольше, в основном в источнике события, а вот в потребителе даже поменьше получается.
Вот что я прикинул на счет ссылок и объектов(вчера я неправильно оценил). Если вводить один объект на пропертю, количество объектов для серелизации увеличится на количество пропертей. Сериалайзер этого не вынесет. И десериалайзер тоже.
Количество ссылок удваивается — опят же геморрой. Будет ли быстрее работать алгоритм — сложный вопрос. Кое где экономия есть, но цепочки взаимодействия длинне.
И если один слой мадели будет сохряняться десятки минут — это все геморрой.
Единственный плюс твоего подхода в том, что можно легко перейти к схеме с частично загрузкой.
Над этим работаем.
Здравствуйте, AndrewVK, Вы писали:
PE>>Ну протестирую я генератор колекций, и что с того ? AVK>То что генеренный код после этого при изменении входных данных особо тестировать не надо.
То же самое имеем мы и сейчас. Колекция тестируется один раз. Все остальные идентичны, иначе это дело даже не скомпилится.
PE>>А новые люди сколько в этом разбираются ? AVK> Нету у нас таких.
Когда будут — расскажешь.
PE>>Если ваша с сеть однороная, то хоть миллиарды.
AVK>Я же написал — несколько десятков сущностей. Какая она однородная? Связи тоже нескольких типов.
У нас не несколько десятков а 6 сотен. К следующей версии будет около тысячи.
AVK>Да, естественно ни о какой автоматической сериализации я даже не думал. Запись целиком собственная, в БД, с кешированием и сериализацией только измененных частей. Иначе это при любом варианте автоматической тормоза. А мне надо чтобы сохранение изменений занимало не более 1-2 секунд.
PE>> У нас примерно 600 классов, писаных от руки.
AVK>Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.
Это хорошо. Ты никогда не задумывался, как можно генерировать код дотнетфреймворка ?
Аналогия та же самая.
PE>>По какому принципу генерировать — непонятно.
AVK>Принцип очень простой. Как бы они ни были неоднородны, если ты их обрабатываешь где то по одинаковым правилам (ну сериализуешь к примеру), значит что то общее в них есть. Вот тебе и основа для генератора.
PE>>Каждый случай в графе это характерный. Если есть подозрение, что алгоритм генерирует неоптимальное решение, то очень сложно выявить ошибку. Иногда такие ошибки ищутся месяцами.
AVK>ИМХО это сигнал для серьезного пересмотра дизайна программы.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Опять какая то ерунда. Зачем на каждое свойство заводить отдельный класс?
PE>А как по другому ? Объект одновременно и подписчик десятков эвентов и консумер стольких.
Одновременно и одинаковых? Так у тебя же sender есть, по нему и разруливай.
AVK>>Не, ну до маразма что угодно можно довести.
PE>Сложность задачи определяет кастомер, а не мы. PE>Конечно, с твоей точки зрения это маразм, потому что ты не представляешь модели оптической сети.
Маразм не в модели оптической сети, а в создании классов на каждую подписку.
PE>>>Если интерфейсы из одного метода, то получится тоже самое, что и у нас сейчас, только кода побольше будет. AVK>>О том и речь.
PE>Так а зачем лишний код ?
Чтобы не тормозило, ты же этого хотел?
PE>Количество ссылок удваивается — опят же геморрой. Будет ли быстрее работать алгоритм — сложный вопрос.
Нет тут никакой сложности. Быстрее, причем очень заметно быстрее.
PE>Единственный плюс твоего подхода в том, что можно легко перейти к схеме с частично загрузкой.
Зная размер модели я бы это делал с самого начала.
Здравствуйте, AndrewVK, Вы писали:
AVK>Принцип очень простой. Как бы они ни были неоднородны, если ты их обрабатываешь где то по одинаковым правилам (ну сериализуешь к примеру), значит что то общее в них есть. Вот тебе и основа для генератора.
Серилизацию мы не пишем. На все написано два суррогата.
PE>>Каждый случай в графе это характерный. Если есть подозрение, что алгоритм генерирует неоптимальное решение, то очень сложно выявить ошибку. Иногда такие ошибки ищутся месяцами.
AVK>ИМХО это сигнал для серьезного пересмотра дизайна программы.
Это научная задача. Передизайн тебе не поможет в принципе. Для исправения ошибки часто нужно исследования провести или кучу реальных замеров, проконсультироваться в университетах и тд.
Это вычисления, тесты тебе не помогут. Тест — это другая научная задача такой же, если не большей, сложности.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Опять какая то ерунда. Зачем на каждое свойство заводить отдельный класс? PE>>А как по другому ? Объект одновременно и подписчик десятков эвентов и консумер стольких. AVK>Одновременно и одинаковых? Так у тебя же sender есть, по нему и разруливай.
Одновременно. Могут быть разных типов. Могут быть одинаковых типов.
Сендер у нас один — в базовом классе. А приемников нужно столько, сколько пропертей.
PE>>Сложность задачи определяет кастомер, а не мы. PE>>Конечно, с твоей точки зрения это маразм, потому что ты не представляешь модели оптической сети.
AVK>Маразм не в модели оптической сети, а в создании классов на каждую подписку.
Подписка — это не просто обратная связь. Это кусочек математики, которую придется выпонять при возникновении эвента. Для каждой проперти она своя.
PE>>Так а зачем лишний код ? AVK>Чтобы не тормозило, ты же этого хотел?
PE>>Количество ссылок удваивается — опят же геморрой. Будет ли быстрее работать алгоритм — сложный вопрос.
AVK>Нет тут никакой сложности. Быстрее, причем очень заметно быстрее.
Серилизация и десерилизация умрет вообще.
PE>>Единственный плюс твоего подхода в том, что можно легко перейти к схеме с частично загрузкой. AVK>Зная размер модели я бы это делал с самого начала.
Это очень сложный механизм.
Перформанс для алгоритмов будет никакой. Сеть набивать будет побыстрее, конечо и сохранять побыстрее, но основная цель — это результаты работы алгоритмов.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>То что генеренный код после этого при изменении входных данных особо тестировать не надо.
PE>То же самое имеем мы и сейчас. Колекция тестируется один раз. Все остальные идентичны, иначе это дело даже не скомпилится.
Ну вот, значит нужно продолжать двигаться в том же направлении.
AVK>>Я же написал — несколько десятков сущностей. Какая она однородная? Связи тоже нескольких типов.
PE>У нас не несколько десятков а 6 сотен. К следующей версии будет около тысячи.
Ну так тем более. Я то сразу делал собственную загрузку/выгрузку. И в вашем случае поступил бы точно так же, вне зависимости от того какой язык и платформу я использую.
AVK>>Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.
PE>Это хорошо. Ты никогда не задумывался, как можно генерировать код дотнетфреймворка ?
Здравствуйте, AndrewVK, Вы писали:
PE>>То же самое имеем мы и сейчас. Колекция тестируется один раз. Все остальные идентичны, иначе это дело даже не скомпилится.
AVK>Ну вот, значит нужно продолжать двигаться в том же направлении.
На дженериках мы первое, что сделаем, это повыбрасываем все коллекции.
PE>>У нас не несколько десятков а 6 сотен. К следующей версии будет около тысячи. AVK>Ну так тем более. Я то сразу делал собственную загрузку/выгрузку. И в вашем случае поступил бы точно так же, вне зависимости от того какой язык и платформу я использую.
Если использовать оптимизированый вариант форматтера из ротора, то все пучком. Остается устранить лишние WriteObjectInfo(их столько, сколько ссылок на объект — в 20...30 раз больше). Опосля доработать напильником, убрать лишнее в смысле, и обфусцировать.
AVK>>>Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.
PE>>Это хорошо. Ты никогда не задумывался, как можно генерировать код дотнетфреймворка ? AVK>В смысле?
Я к тому, что большая часть кода у нас самописная. Это математика. Коллекции и кой какие базовые механизмы это не самое страшное.
Мне вот в свете вышесказанного еще интересно как приживется C++ CLI
Ведь писать на нем будет практически также просто как и на C# а возможностей побольше будет
все таки.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Про COM ты сам вспомнил. Я ничего не говорил. Я предложил идею реализации, аналогичную комовской.
Вот тебе и сказали, что он тут не причем. Конекшон-поинты в ком нужны для избавления от проблемы циклической ссылки. В дотнете она или вообще не стоит или решается вик-реверенсами.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.
Полностью согласен.
AVK>Принцип очень простой. Как бы они ни были неоднородны, если ты их обрабатываешь где то по одинаковым правилам (ну сериализуешь к примеру), значит что то общее в них есть. Вот тебе и основа для генератора.
Как минимум все они состоят из свойст и коллекций. Так что уж сериализацию то точно можно автоаматизировать если не придерживаться собственных догм и не упавать на собственную не последовательность.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>На дженериках мы первое, что сделаем, это повыбрасываем все коллекции.
И получите прирост в 5% мксимум, а то и тормоза (если не додумаетесь свои коллекции реализовать).
PE>Если использовать оптимизированый вариант форматтера из ротора, то все пучком. Остается устранить лишние WriteObjectInfo(их столько, сколько ссылок на объект — в 20...30 раз больше). Опосля доработать напильником, убрать лишнее в смысле, и обфусцировать.
И все же. Ты все время говоришь о количестве классов в вашем фреймворке. Но не разу не скзал, о среднем и максимальном количестве объектов в графе подлежещем сериализации. А именно это число важно для оценки. Так же интересно, что считается приемлемым временем сериализации, когда она происходит...
PE>Я к тому, что большая часть кода у нас самописная. Это математика. Коллекции и кой какие базовые механизмы это не самое страшное.
Ты, знаешь, мы конечно в твоей прикладной области не разбирались, и заключения дать не можем. Но соглесен с АВК в том, что при числе классов в 6 сотен слабо верится, что в них нет общей системы и что их производство нельзя автоматизировать.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Серилизацию мы не пишем. На все написано два суррогата.
Вот тебе и говорят, что это и есть ошибка. Стандартная сериализация скорее всего не для вас. Вы забили на ручную сериализацию, а потом ты еще на этом основании делаешь выводы о приемуществах С++ в этой области. Посмотри как выглядит твоя логика со стороны! "Сериализация в дотнете медленная, а в С++ ее вообще нет и мы можем написать ее оптимальнее чем в дотнете. Значит дотнет тормоз, а С++ рулез."
PE>Это научная задача. Передизайн тебе не поможет в принципе. Для исправения ошибки часто нужно исследования провести или кучу реальных замеров, проконсультироваться в университетах и тд. PE>Это вычисления, тесты тебе не помогут. Тест — это другая научная задача такой же, если не большей, сложности.
Тоже неплохое основание для признания бессмысленности создания собственной системы сериализации. Я правельно понял тормоза у вас в этом, а не в вычислениях?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Так а зачем лишний код ? Нам и так пролему приходится решать с нынешним количесвом.
Ты ведь говорил, что у вас сериализация тормзит изза использования делегатов. Вот он тебе и посоветовал решение.
PE>И если один слой мадели будет сохряняться десятки минут — это все геморрой.
Назови все же объем средней и большой модели в количестве экхемлпяров объектов учавствующих в грфе.
PE>Единственный плюс твоего подхода в том, что можно легко перейти к схеме с частично загрузкой. PE>Над этим работаем.
Он тебе предлагал вообще-то сериализацию вручную написать, возможно с генератором кода. Это училичит производительность в разы, а то и десятки раз.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Серилизация и десерилизация умрет вообще.
...
PE>Это очень сложный механизм. PE>Перформанс для алгоритмов будет никакой. Сеть набивать будет побыстрее, конечо и сохранять побыстрее, но основная цель — это результаты работы алгоритмов.
Блин, ну ты уперся. Тебе говорят об известно факте! Скорость рабты через ссылки на интерфейсы в 5-10 раз выше чем в случае с делегатом и в десятки выше в случае прямых вызовов (опять же по сравнению сделегатами).
ЗЫ
Вот только тормоза сериализатора далеко не только в событиях заключаются.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Фремворк на шарпе создать еще проще. НО ! В программах обработки звука для простых обывателей никогда не было, нет и никогда не бует аппаратных алгоритмов. Продвинутый программный алгоритм всегда будет раотать быстрее железа. Фурье — довольно меденный агоритм. PE>Применения в ПО его избегают именно из за тормознутости. Можно быстрее — но больше памяти сожрешь. А вот в железо фурие закатать — проще не придумаешь. Но не всегда можно использовать аппаратные воможности. Для вывода звука на колонки можно кое что впихнуть в звуковуху. PE>Но чтото я ни разу не видел в продаже аппратный ужиматель(USB или PCI или PCMCIA) в МП3, ОГГ к примеру для моего компутера. И не просто ужиматели, а чтобы можно было гибко настраивать, психоаккустику менять и тд. и тд. PE>Так что всякие FPGA можно сразу засунуть в одно место.
Да в половине ресиверов подобные функции зашиты. Просто если хватает ЦП, то и нефига делать спец. решения.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, naje, Вы писали:
N>такой как тут невозможно просто на шарпе, нужно разрабатывать ещё один язык для нета, впринципе одно из решений
И? На поверку это может оказаться проще, чем извращаться на плюсах. Обычно нужен не новый язык, а специализированный генератор кода. Его и эмулируют на новеших возможностей шаблонов.
Вот интересно, ваш код компилируется на VC6? И уверен ли ты в том, что если бы в воспользовались, например, вот этим, у вас не плучилось бы все проще, надежнее и быстрее?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, maq, Вы писали:
maq>Мне вот в свете вышесказанного еще интересно как приживется C++ CLI maq>Ведь писать на нем будет практически также просто как и на C# а возможностей побольше будет maq>все таки.
maq>Что народ думает?
Я думаю, что возможностей особо больше не будет. А читать и присать на Шарпе удобнее уже. Так что C++ CLI станет тем же чем Дельфи.НЭТ — средством вербовки в веру дотнета программистов плохо хранящим излишнюю приверженность своим привычкам.
Единственное что мне действительно нехвататет из С++ на сегодня — это средств метапрограммирования. Но они и в С++ очень слабы. Сдается мне, что будущее за вот такими расширениями
Здравствуйте, VladD2, Вы писали:
PE>>Написали генератор текста(на жаве ) и все пучком. VD> Для продукта на дотнете? Ну, вы блин даете...
А что делать ? Генераторы текста, которыми обладают всякие UML-тулы, весьма кривые. Мы написали постпроцесор. То, что нагенерировал UML, обрабатывается постпроцесором, и мы имеем файл, в котором нужно только функции заполнить. С коллекциями свой случай — они сделаны чз. copy-paste-replace. Другой способ, когда мы задавали этот вопрос, никто не смог предложить.
Здравствуйте, VladD2, Вы писали:
AVK>>Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает. VD>Полностью согласен.
AVK>>Принцип очень простой. Как бы они ни были неоднородны, если ты их обрабатываешь где то по одинаковым правилам (ну сериализуешь к примеру), значит что то общее в них есть. Вот тебе и основа для генератора. VD>Как минимум все они состоят из свойст и коллекций. Так что уж сериализацию то точно можно автоаматизировать если не придерживаться собственных догм и не упавать на собственную не последовательность.
Проблема с серилизацией не самая емкая проблема. Мы использовали бинариформаттер. Нам это стоило сотни две строк вместе с суррогатами. Сейчас избавимся от гемора с RaiseDesirilizationEvent и все пучком.
Здравствуйте, VladD2, Вы писали:
VD>И получите прирост в 5% мксимум, а то и тормоза (если не додумаетесь свои коллекции реализовать).
Лучше 50% тормозов, чем сотня коллекций copy-paste-replace.
VD>И все же. Ты все время говоришь о количестве классов в вашем фреймворке. Но не разу не скзал, о среднем и максимальном количестве объектов в графе подлежещем сериализации. А именно это число важно для оценки. Так же интересно, что считается приемлемым временем сериализации, когда она происходит...
Для рабочего проекта от 20000. Верхняя планка не ограничена. Серилизация должна выполняться за секунды...десятки секунд. У нас 30 секунд...6 минут.
Осталась одна пролема — WriteObjectInfo создается в раз 20...30 больше, чем объектов.
PE>>Я к тому, что большая часть кода у нас самописная. Это математика. Коллекции и кой какие базовые механизмы это не самое страшное.
VD>Ты, знаешь, мы конечно в твоей прикладной области не разбирались, и заключения дать не можем. Но соглесен с АВК в том, что при числе классов в 6 сотен слабо верится, что в них нет общей системы и что их производство нельзя автоматизировать.
Общая система есть. Все, что однотипно и тд, сделано в базовой сборке. Копипейста нет.
Все, что межно сделать — всю матмодель писать в виде метамодели на специальном языке. На выходе будем иметь те же самые классы. Хороший способ. Нужно написать такой язык, отладить, протестировать, научить всех людей писать на нем. При этом неясно, хватит и нам ресурсов PIII-PIV или нет.
Здравствуйте, VladD2, Вы писали:
VD>Вот тебе и говорят, что это и есть ошибка. Стандартная сериализация скорее всего не для вас. Вы забили на ручную сериализацию, а потом ты еще на этом основании делаешь выводы о приемуществах С++ в этой области. Посмотри как выглядит твоя логика со стороны! "Сериализация в дотнете медленная, а в С++ ее вообще нет и мы можем написать ее оптимальнее чем в дотнете. Значит дотнет тормоз, а С++ рулез."
Уже все сильно. RaiseDeserilizationEvent победили — сделать можно в обход кое как. Если дадут добро на использование кастрированого форматтера из ротора — все пучком. В дотнете мне не нравится подход Микрософта. ObjectManager используется во многих классах. Класс публиный. Почему бы не дать возможность использовать наследники от этого ObjectManager ? SerilizationInfo — нет возможности изменить размер внутреннего массива. SerilizationInfo.AddValue вызывает в среднем 4-5 операций расширения массива. Это большие тормоза, с учетом того, что WriteObjectInfo создается на ссылку, а не объект.
Это только два момента. Если будет возможность поработать напильником, эти два узких места будут спилены и модель будет рулить при серилизации!
PE>>Это научная задача. Передизайн тебе не поможет в принципе. Для исправения ошибки часто нужно исследования провести или кучу реальных замеров, проконсультироваться в университетах и тд. PE>>Это вычисления, тесты тебе не помогут. Тест — это другая научная задача такой же, если не большей, сложности.
VD>Тоже неплохое основание для признания бессмысленности создания собственной системы сериализации. Я правельно понял тормоза у вас в этом, а не в вычислениях?
Тормоза с серилизацией мы уже проехали. Модель нужна не для серилизации, а для расчета сети.
В общем случае тесты вообще непригодны. Сидят люди и проверяют правильность расчетов. Если можно написать скрипт для проверки — пишут. Нельзя — проверяется вручную.
Здравствуйте, VladD2, Вы писали:
PE>>Так а зачем лишний код ? Нам и так пролему приходится решать с нынешним количесвом. VD>Ты ведь говорил, что у вас сериализация тормзит изза использования делегатов. Вот он тебе и посоветовал решение.
Уже решено другим способом и без делегатов.
PE>>И если один слой мадели будет сохряняться десятки минут — это все геморрой. VD>Назови все же объем средней и большой модели в количестве экхемлпяров объектов учавствующих в грфе.
Средняя модель 20K...40K объектов. После запуска алгорима расчета моджет быть и 100К...200К.
PE>>Единственный плюс твоего подхода в том, что можно легко перейти к схеме с частично загрузкой. PE>>Над этим работаем. VD>Он тебе предлагал вообще-то сериализацию вручную написать, возможно с генератором кода. Это училичит производительность в разы, а то и десятки раз.
Это понятно. Но для этого нужен передизайн. И особого выигрыша это не даст.
Мы решили вообще отказаться от серилизации.
Здравствуйте, VladD2, Вы писали:
PE>>Так что всякие FPGA можно сразу засунуть в одно место.
VD>Да в половине ресиверов подобные функции зашиты. Просто если хватает ЦП, то и нефига делать спец. решения.
В том то и дело, что применени очень ограниченное. В твоем винампе, ламе(если ты в мп3 гонишь диски), дсп и тд. программных алгоритмов на порядки раз больше.
VD>Блин, ну ты уперся. Тебе говорят об известно факте! Скорость рабты через ссылки на интерфейсы в 5-10 раз выше чем в случае с делегатом и в десятки выше в случае прямых вызовов (опять же по сравнению сделегатами).
Интересно откуда у тебя такие результаты. Если не использовать рефлешного DinamicInvoke то типизированный делегат всего процентов 10 уступает интерфейсам.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Лучше 50% тормозов, чем сотня коллекций copy-paste-replace.
copy-paste-replace то зачем? Ну, да тебе решать.
PE>Для рабочего проекта от 20000.
Это просто копейки. Это только для стандартного сериалайзера проблемой может стать.
PE> Верхняя планка не ограничена.
Так не бывает. Всегда можно рассчитать разумный максимум.
PE> Серилизация должна выполняться за секунды...десятки секунд. У нас 30 секунд...6 минут. PE>Осталась одна пролема — WriteObjectInfo создается в раз 20...30 больше, чем объектов.
Могу только сравнить с данными по R#-у. Количество типов в иерархии его CodeDom-а ~ 150 штук. Добавил пдсчет статистики в парсер R#-а. Прогнал на проекте Хоума. Получилось создание ~130 000 объектов. Время 1.2 сек. При этом еще есть огромный простор для оптимизации. Для просто огромного проекта Моно результат таков:
Максимальное количество AST-веток в одном файле: 40 099
Общее количество AST-веток во всех файлах: 2 400 460
Общее время: 13.10397 сек.
В R# правда не строится сложный граф (только даг). Но я просто уверен, что дело тут не в характере графа, а в качестве сериализации. В R# ведь производится полноценный парсинг и генерация текста по AST.
...
Ты можешь классифицировать свои объекты и выделить основные их подклассы?
PE>Общая система есть. Все, что однотипно и тд, сделано в базовой сборке. Копипейста нет. PE>Все, что межно сделать — всю матмодель писать в виде метамодели на специальном языке. На выходе будем иметь те же самые классы. Хороший способ. Нужно написать такой язык, отладить, протестировать, научить всех людей писать на нем. При этом неясно, хватит и нам ресурсов PIII-PIV или нет.
Ну, про ресурсы это ты уже лишку хватил. А про спех язык описания... почему бы и нет? Можно было или ХМЛ припахать. Или взять генератор компиляторов и с его помощью сделать генератон объектов.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>>>Написали генератор текста(на жаве ) и все пучком. VD>> Для продукта на дотнете? Ну, вы блин даете...
PE>А что делать ? Г
А почему не на том же Шарпе? Странен не сам генератор, а то что он на Яве для дотнетного проекта.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
VD>>Блин, ну ты уперся. Тебе говорят об известно факте! Скорость рабты через ссылки на интерфейсы в 5-10 раз выше чем в случае с делегатом и в десятки выше в случае прямых вызовов (опять же по сравнению сделегатами).
S> Интересно откуда у тебя такие результаты. Если не использовать рефлешного DinamicInvoke то типизированный делегат всего процентов 10 уступает интерфейсам.
Измерял. И кстати, тут где-то резултаты приводил. 10% — фигня.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
PE>>Лучше 50% тормозов, чем сотня коллекций copy-paste-replace. VD>copy-paste-replace то зачем? Ну, да тебе решать.
Для типизированых коллекций. Подскажи способ лучше.
VD>Могу только сравнить с данными по R#-у. Количество типов в иерархии его CodeDom-а ~ 150 штук.
Хорошо, но немного не то. Типы разные бывают.
Вот попробуй что нибудь предложить для моего случая.
Сеть из узлов и линков между ними.
Количество узлов всего 50. Всего два типа узлов — 25 каждого. Все узлы, независиме от типа, связаны на все остальные 49 через линки(их три типа). Линк соединен с узлами чз промежуточные концы(их два типа).
Узлы — тип1 и тип2
Концы — тип1 и тип2
Линк тип1 — тип1, тип2-тип2, смешаные типы.
Естественно, что каждый тип это свой набор пропертей и тд. и тд.
Каждый объект должен держать уведомления от того, на кого указывает.Т.е. объект выставляет эвенты — на изменение пропертей и на удаление. Каждая операция может быть отменена(Changing) и выполнена(Changed). Тот, кто хранит ссылку на этот объект, должен подписаться на эвенты удаления в обязательном порядке. Линк, узел, конец — все выставляют одни и теже эвенты. Линк подписан на эвенты конца. Конец хранит ссылку на узел и подписан на эвента узла. Сам узел хранит коллекцию всех концов и подписан на эвенты каждого из них. Еще есть объект сеть, который является владельцем всех узлов и линков. Он подписан на все их эвенты.
Т.е всего то нужно описать алгоритм, который будет создавать узлы, связывать их линками.
Потом берешь и серилизуешь или десерилизуешь. Меряешь время.
Всего объекв Nузлов*2+(Nузлов*(Nузлов-1)/2)*3 это, влом считать, примерно 4000 объектов.
В объекте хорошо бы предусмотреть возможность удаления объктов, валидации своих пропертей и своего состояния и расширение пропертей(простых типов) этого самого объекта с помощью механизмов.
Для удаления нужно учесть типы объектов. Удаление узла(принудительное) должно влечь за собой удаление концов и линков.Удаление линка влечет за сосбой удаление концов. Кроме того, если узел соединен с узлом, для удаления нужно сначала удалить линк(безопастное), а уже потом узел. Это потому, что неосторожная манипуляция пользователя может снести всю сеть. В любой момент времени в модели не должно быть висящих концов, узлов, линков без владельца и тд. При любом изменении нужно иметь способ оповестить всех, кто прямо или косвенно связан с объектом.
Вот очень-очень примитивная модель — одномерная. Есть двумерная — сети соедины между собой. Есть трехмерная — сеть состоит из уже из сетей, соединенныйх между собой.
У нас трехмерная многоуровневая модель.
После задания сети запускается алгоритм или алгоритмы, во время которого сеть обрастает другими оъектами(тоже источниками событий) — роутинги, трифики и тд. и тд.
VD>Ты можешь классифицировать свои объекты и выделить основные их подклассы?
Это уже сделано.
VD>Ну, про ресурсы это ты уже лишку хватил. А про спех язык описания... почему бы и нет? Можно было или ХМЛ припахать. Или взять генератор компиляторов и с его помощью сделать генератон объектов.
Для этого надо чтобы наши топменеджеры осваивали все эти технологии.
На оффшоре хорошо сидеть. А вот как научить этому американца(, который пишет алгоритм, вместо наследования использует хештейблы для расширения атрибутов объекта, не знает, что такое интерфейс, виртуальный метод, ) я не знаю. Так что выбор невелик.
Re[52]: C++ versus C#
От:
Аноним
Дата:
13.03.04 10:17
Оценка:
Здравствуйте, VladD2, Вы писали:
PE>>>>Написали генератор текста(на жаве ) и все пучком. VD>>> Для продукта на дотнете? Ну, вы блин даете... PE>>А что делать ? Г VD>А почему не на том же Шарпе? Странен не сам генератор, а то что он на Яве для дотнетного проекта.
А там было проще парсить код языка. Такой библиотеки мы не нашли для нета.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
VD>>>Блин, ну ты уперся. Тебе говорят об известно факте! Скорость рабты через ссылки на интерфейсы в 5-10 раз выше чем в случае с делегатом и в десятки выше в случае прямых вызовов (опять же по сравнению сделегатами).
S>> Интересно откуда у тебя такие результаты. Если не использовать рефлешного DinamicInvoke то типизированный делегат всего процентов 10 уступает интерфейсам.
VD>Измерял. И кстати, тут где-то резултаты приводил. 10% — фигня.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Кстати метаклассы в том числе намного упрощают проблему сериализации и десиреализации.
VD>Ага. Языком.
Ну зачем же так грубо. Нет в Delphi часто используют и я в том числе.
У каждого типа есть конструктор FromStream, а у каждого объекта метод ToStream. Но в Net на рефлексии легко развернуть все методы на этапе компиляции в MSIL а не не этапе сериализации десиреализации, в том числе и для объетов неизвестного типа. VD>Проблема сериализации в дотнете заключается в кривых руках тех кто ее писал.
Согласен.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>>>XML + embedded C# или VB.
PE>>Не пойдет.
AVK>Почему?
На C# можно сделать так, но гораздо удобнее сделать это в специаизированом языке.
PE>> Нужен специализированый язык, нечто вроде UML в текстовом представлении, который будет прятать все, что не относится к математике.
AVK>Вот и построй его на основе XML.
На основе XML неудобно. Я думаю, что это может быть нечто вроде С-подобного языка такого плана.
Здравствуйте, VladD2, Вы писали:
PE>>Это очень сложный механизм. PE>>Перформанс для алгоритмов будет никакой. Сеть набивать будет побыстрее, конечо и сохранять побыстрее, но основная цель — это результаты работы алгоритмов.
VD>Блин, ну ты уперся. Тебе говорят об известно факте! Скорость рабты через ссылки на интерфейсы в 5-10 раз выше чем в случае с делегатом и в десятки выше в случае прямых вызовов (опять же по сравнению сделегатами).
В случае эвентов очень легко скриптовых клиентов уведомлять. Без этого никуда.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Здравствуйте, VladD2, Вы писали:
PE>>>Лучше 50% тормозов, чем сотня коллекций copy-paste-replace. VD>>copy-paste-replace то зачем? Ну, да тебе решать.
PE>Для типизированых коллекций. Подскажи способ лучше.
Сколько ж можно? Тебе говорят, что генераторы кода для коллекций использовать надо. Ими весь Инет завален.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Почему?
PE>На C# можно сделать так, но гораздо удобнее сделать это в специаизированом языке.
Не, я с тебя писяюсь . Почему не сделали спец. язык? Потому что слишком долго его делать. А почему не воспользоваться XML+C#? Потому что свой удобнее.
AVK>>Вот и построй его на основе XML.
PE>На основе XML неудобно.
Не знаю, не знаю. Вон ASP.NET показывает что очень даже ничего.
PE> Я думаю, что это может быть нечто вроде С-подобного языка такого плана.
С-подобный язык плохо подходит для декларативного описания, а правильный генератор на 90% управляется декларативно.
PE>XML сгодится на первое время. Вся проблема в том, что модель слишком сложная.
Любая сложная модель может быть упрощена за счет дополнительных абстракций. Я конечно ничего не могу сказать по поводу твоей задачки, но все подобные проблемы что мне встречались в итоге решались довольно просто, нужно было лишь тщательно разработать описательную модель.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не, я с тебя писяюсь . Почему не сделали спец. язык? Потому что слишком долго его делать. А почему не воспользоваться XML+C#? Потому что свой удобнее.
Ой как умно, господин модератор. Перечитай ветку и не дури мне головы.
Предложи свой вариант на XML+С#, чтобы было столько же кода и столько же функциональности.
PE>>На основе XML неудобно. AVK>Не знаю, не знаю. Вон ASP.NET показывает что очень даже ничего.
Почему бы тебе на XML и программы тогда не писать ? Ты никогда не думал, что вместо C# можно и так писать
AVK>С-подобный язык плохо подходит для декларативного описания, а правильный генератор на 90% управляется декларативно.
Очень неплохо подходит. Смотри в IDL. Но это не единсвенное решение.
AVK>Любая сложная модель может быть упрощена за счет дополнительных абстракций. Я конечно ничего не могу сказать по поводу твоей задачки, но все подобные проблемы что мне встречались в итоге решались довольно просто, нужно было лишь тщательно разработать описательную модель.
Упрощено все, что можно упростить. Нельзя сделать просто, если нужен и мастшаб большой и высокая степень детализации.
Здравствуйте, VladD2, Вы писали:
PE>>>>Лучше 50% тормозов, чем сотня коллекций copy-paste-replace. VD>>>copy-paste-replace то зачем? Ну, да тебе решать.
PE>>Для типизированых коллекций. Подскажи способ лучше.
VD>Сколько ж можно? Тебе говорят, что генераторы кода для коллекций использовать надо. Ими весь Инет завален.
Я уже сто раз говорил про это — неудобно. Генерировать лучше текст. Туда и бряк можно поставить легко и какую колекцию подменить, чтобы отладку упростить , и новому человеку проще дебажить. Много плюсов.
Создание такой коллекции — минутное дело.
Я не виду никаких преимуществ, кроме меньшего размера теста программы.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не знаю, не знаю. Вон ASP.NET показывает что очень даже ничего.
У нас есть кой какой опыт в этом. Один объект описать на XML(статическая часть модели хранится в БД) — это примерно 3 кб текста. Это касается только загрузки.
При чем текст не читабельный и слишком плотный. Могу послать кусочек, если интересно, но в форум не могу постить.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Ой как умно, господин модератор. Перечитай ветку и не дури мне головы.
PE>>>На основе XML неудобно. AVK>>Не знаю, не знаю. Вон ASP.NET показывает что очень даже ничего.
PE>Почему бы тебе на XML и программы тогда не писать?
Потому что программы содержат в основном императивные инструкции.
AVK>>С-подобный язык плохо подходит для декларативного описания, а правильный генератор на 90% управляется декларативно.
PE>Очень неплохо подходит.
Это тебе кажется удобнее, потому что ты на плюсах пишешь. Только ты то жаловался на то что те кто это должен писать — непрограммисты. А для них куда как проще декларативный стиль задания.
PE> Смотри в IDL.
Вот смотрел, потому и говорю. WSDL удобнее, более масштабируемо и мощнее.
PE>Нельзя сделать просто, если нужен и мастшаб большой и высокая степень детализации.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Потому что программы содержат в основном императивные инструкции.
PE>Вот в чем дело. Взаимодействие объектов придется частично на этом же языке описывать.
Взаимодействие тоже можно выразить декларативно.
PE>Проще, но не XML. XML сгодится в качестве промежуточного. Генератор должен XML примнимать, а вот человеку с XML работать не нужно. Слишком много текста и структура плохая.
Практика показывает что стороннему человеку намного проще понимать XML, SQL и прочая, нежели императивный язык. В свое время была задачка обработки потока видео — декларативный стиль описания сети обработчиков инженерам был намного понятнее императивного.
AVK>>Вот смотрел, потому и говорю. WSDL удобнее, более масштабируемо и мощнее.
PE>Ничего тут не удобнее. Если один раз написать и забыть, то можно и XML,WSDL и все, что хочешь юзать.
На вкус и цвет. Мой опыт показывает что С-подобный синтаксис крайне неудобен для декларативного описания, особенно человеку, незнакомому с программированием.
Здравствуйте, AndrewVK, Вы писали:
PE>>Вот в чем дело. Взаимодействие объектов придется частично на этом же языке описывать.
AVK>Взаимодействие тоже можно выразить декларативно.
На XML это неудобно. Не наглядно. Слишком громоздко. Не для этого XML содан.
AVK>Практика показывает что стороннему человеку намного проще понимать XML, SQL и прочая, нежели императивный язык. В свое время была задачка обработки потока видео — декларативный стиль описания сети обработчиков инженерам был намного понятнее императивного.
Понятнее — слишком растяжимо. Могу послать пример на почту.
Достоинства XML в том, что много парсеров написано, он станартизирован и распространен.
На счет понятности — очень спорно. Если текста более, чем на страницу, XML очень трудно читать.
Перепиши мой пример на XML и сам все поймешь.
PE>>Ничего тут не удобнее. Если один раз написать и забыть, то можно и XML,WSDL и все, что хочешь юзать. AVK>На вкус и цвет. Мой опыт показывает что С-подобный синтаксис крайне неудобен для декларативного описания, особенно человеку, незнакомому с программированием.
XML — не простое, а примитивное решение. Все должно быть просто, но не примитивно.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>>Посмотри
VD>Та особо не начто смотреть. В обще, я тебе уже сказал. Сделай поиск... погляди.
Ну да в этих тестах делегаты прогрывают доступ к полю максимум в 5 раз от доступа объекта, и максимально проигрывают интерфейсу в 2 раза.
А у тебя в 5-10 раз к интерфейсу. Причем эти методы тратят время только на вызов не говоря о сложных методах где эта разница будет сведена к нулю. А подумай сам как он может так прогирывать если делает всего 2-3 лишних движения??? Кстати в Delphi нативная крнструкция Procedure of Object работает быстрее виртуального метода (Native), а в случае с интерфейсами это вообще двойная виртуальность.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Взаимодействие тоже можно выразить декларативно.
PE>На XML это неудобно. Не наглядно.
А по мне так куда удобнее и нагляднее чем то что ты тут приводил.
PE> Слишком громоздко. Не для этого XML содан.
А для чего?
PE>Понятнее — слишком растяжимо. Могу послать пример на почту. PE>Достоинства XML в том, что много парсеров написано, он станартизирован и распространен.
Именно. Особенно подчеркну "стандартизован".
PE>Перепиши мой пример на XML и сам все поймешь.
У меня таких примеров в текущем проекте море. Ничего такого пока не понял. Если слишком много и сложно то и в С-стиле тоже будет малочитаемо, нужно писать специализированный редактор. Просто ты привык к чтению больших объемов С-кода, потому тебе кажется что так проще. На самом же деле при больших объемах проще xml за счет большей структурированности. А учитывая то что для XML уже есть готовые редакторы незнакомому с С человеку он куда предпочтительнее.
PE>XML — не простое, а примитивное решение.
Интересно, на основании чего ты такие выводы делаешь.
Здравствуйте, AndrewVK, Вы писали:
PE>> Слишком громоздко. Не для этого XML содан. AVK>А для чего?
Это не ко мне.
AVK>Именно. Особенно подчеркну "стандартизован". PE>>Перепиши мой пример на XML и сам все поймешь.
AVK>У меня таких примеров в текущем проекте море. Ничего такого пока не понял. Если слишком много и сложно то и в С-стиле тоже будет малочитаемо, нужно писать специализированный редактор. Просто ты привык к чтению больших объемов С-кода, потому тебе кажется что так проще. На самом же деле при больших объемах проще xml за счет большей структурированности. А учитывая то что для XML уже есть готовые редакторы незнакомому с С человеку он куда предпочтительнее.
Редакторы есть какие то. Нет редактора, который отобразит структуру нашей модели.
PE>>XML — не простое, а примитивное решение. AVK>Интересно, на основании чего ты такие выводы делаешь.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>>> Слишком громоздко. Не для этого XML содан. AVK>>А для чего?
PE>Это не ко мне.
Почему? Ты же утверждаешь что не для этого. Вот и интересно тогда для чего.
AVK>>У меня таких примеров в текущем проекте море. Ничего такого пока не понял. Если слишком много и сложно то и в С-стиле тоже будет малочитаемо, нужно писать специализированный редактор. Просто ты привык к чтению больших объемов С-кода, потому тебе кажется что так проще. На самом же деле при больших объемах проще xml за счет большей структурированности. А учитывая то что для XML уже есть готовые редакторы незнакомому с С человеку он куда предпочтительнее.
PE>Редакторы есть какие то. Нет редактора, который отобразит структуру нашей модели.
Редакторы, поддерживающие xsd отображают в соответствии с xsd. Это как минимум базовые взаимосвязи и валидация значений. Для более сложных случаев можешь поглядеть на InfoPath. Для совсем запущенных случаев придется писать свой редактор, а в таком варианте XML безусловно удобнее.
PE>>>XML — не простое, а примитивное решение. AVK>>Интересно, на основании чего ты такие выводы делаешь.
PE>На основании того, что уже сделано.
Ну вобщем поступай как знаешь. Я на основании своего опыта тебе примерное направление показал.
Здравствуйте, AndrewVK, Вы писали:
PE>>>> Слишком громоздко. Не для этого XML содан. AVK>>>А для чего?
PE>>Это не ко мне.
AVK>Почему? Ты же утверждаешь что не для этого. Вот и интересно тогда для чего.
Для хранения, передачи данных например. Но не для декларации сущностей.
AVK>Редакторы, поддерживающие xsd отображают в соответствии с xsd. Это как минимум базовые взаимосвязи и валидация значений. Для более сложных случаев можешь поглядеть на InfoPath. Для совсем запущенных случаев придется писать свой редактор, а в таком варианте XML безусловно удобнее.
Будь все так просто, рулил бы С#+XML или Java+XML. А посмотри, какие тененции — в жаву и нет пихают все, что не лень.
PE>>На основании того, что уже сделано. AVK>Ну вобщем поступай как знаешь. Я на основании своего опыта тебе примерное направление показал.
Я же сказал, что XML для промежуточных данных подходит. А человеку удобнее работать с языком, в котором меньшая избыточность будет и специализированые фичи.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Редакторы, поддерживающие xsd отображают в соответствии с xsd. Это как минимум базовые взаимосвязи и валидация значений. Для более сложных случаев можешь поглядеть на InfoPath. Для совсем запущенных случаев придется писать свой редактор, а в таком варианте XML безусловно удобнее.
PE>Будь все так просто, рулил бы С#+XML или Java+XML.
А он и рулит. Для определенных задач. JSP и ASP.NET к примеру почти что оно и есть. А XAML точно оно.
PE> А посмотри, какие тененции — в жаву и нет пихают все, что не лень.
В смысле?
PE>Я же сказал, что XML для промежуточных данных подходит.
Ну а мой опыт говорит об обратном. Почему не подходит я от тебя так и не услышал. Аргументы типа "не для этого создан" не катят. Для чего он создан написано на w3c.org.
PE> А человеку удобнее работать с языком, в котором меньшая избыточность будет и специализированые фичи.
Не все так просто. Твой специальный язык человеку придется специально изучать. + неизбежные глюки при самопальной реализации. + необходимость в обязательном порядке собственного редактора. Вобщем специальный язык это крайне дорогое решение, как при разработке так и при использовании.
Здравствуйте, AndrewVK, Вы писали:
PE>>Будь все так просто, рулил бы С#+XML или Java+XML. AVK>А он и рулит. Для определенных задач. JSP и ASP.NET к примеру почти что оно и есть. А XAML точно оно.
PE>> А посмотри, какие тененции — в жаву и нет пихают все, что не лень. AVK>В смысле?
Языки всякие например.
PE>> А человеку удобнее работать с языком, в котором меньшая избыточность будет и специализированые фичи.
AVK>Не все так просто. Твой специальный язык человеку придется специально изучать. + неизбежные глюки при самопальной реализации. + необходимость в обязательном порядке собственного редактора. Вобщем специальный язык это крайне дорогое решение, как при разработке так и при использовании.
Сам XML изучать не нужно. Но нужно будет запоминать все аттрибуты, их порядок, регистр, значения атрибутов и ограничения всякие.
Сравни
Здравствуйте, Plutonia Experiment, Вы писали:
PE>>> А посмотри, какие тененции — в жаву и нет пихают все, что не лень. AVK>>В смысле?
PE>Языки всякие например.
Я же тебе сказал — любая технология хороша в своей области. И не везде императивные языки лучше. Например для кодогенератора XSLT шаблон обычно значительно лаконичнее программы на том же шарпе или джаве. В общем случае чем менее универсально инструментальное средство тем выгоднее декларативное представление. Если в общем случае основная часть модели требует императивного выражения, однако есть и части, которые можно задать декларативно обычно добавляют средства декларативного программирования в императивный язык. Например атрибуты в дотнете. Если же ситуация обратная в декларативное описание добавляют код. Например, как я уже говорил, ASP.NET. Причем, обрати внимание, там есть два разных способа добавления императивной части — embedded код и code behind. Второе применяется когда необходим большой объем кода.
В случае генераторов как правило основная часть исходных данных задается декларативно, иначе просто генератор лишен смысла. Отсюда и XML обычно очень неплохо подходит для этих целей.
AVK>>Не все так просто. Твой специальный язык человеку придется специально изучать. + неизбежные глюки при самопальной реализации. + необходимость в обязательном порядке собственного редактора. Вобщем специальный язык это крайне дорогое решение, как при разработке так и при использовании.
PE>Сам XML изучать не нужно.
Основные принципы XML можно изложить на одной страничке. Кроме того, как ты правильно написал, это стандарт. Поэтому есть немалый шанс что человек уже будет с ним знаком.
PE> Но нужно будет запоминать все аттрибуты,
Нет конечно, это справочная информация.
PE> их порядок,
Это вобще не нужно. Если у тебя что то зависит от порядка атрибутов то это очень криво.
PE> регистр, значения атрибутов и ограничения всякие. PE>Сравни
PE>
Сравнил. Второй вариант для стороннего человека однозначно сложнее. Ты опять делаешь ту же самую ошибку — это для тебя ; в конце строки естественна и не вызывает вопросов. Это для тебя . отделяет классы от атрибутов. Это для тебя применение {} для блоков интуитивно понятно.
Поэтому понять первый вариант не программисту заметно проще. А если еще к нему xsd написать и воспользоваться специализированным редактором, то редактировать данные в гриде сможет совсем уж далекий от программирования человек. Для второго же варианта нужно быть программистом, причем на С-like языке.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Я же тебе сказал — любая технология хороша в своей области. И не везде императивные языки лучше. Например для кодогенератора XSLT шаблон обычно значительно лаконичнее программы на том же шарпе или джаве.
PE>Шаблон генерации в HTML очень похож на этот самый HTML. А если захочешь гнать XML в С#, то шаблон будет очень похож на C#.
Я тебе говорю про C#. ПО факту XSLT намного удобнее в таких задачах.
AVK>>Это вобще не нужно. Если у тебя что то зависит от порядка атрибутов то это очень криво.
PE>Для XML нужны схемы данных.
Необязательно.
PE> Это там порядок указывается и регистр.
Только по желанию. А регистр как таковой вобще не указывается, XML чувствителен к регистру.
PE>В одном случае придется писать редактор, во втором — просто перегонять в XML, с которым и будет работать генератор.
С точностью до наоборот. Твой самопальный язык придется редактировать в ноутпаде, без подсветки синтаксиса. А xml можно редактировать в каком нибудь XmlSpy с куда большим комфортом.
PE> Но человеку XML не нужно знать.
Я помнится уже говорил что знаний там на страничку не наберется.
Здравствуйте, AndrewVK, Вы писали:
PE>>Шаблон генерации в HTML очень похож на этот самый HTML. А если захочешь гнать XML в С#, то шаблон будет очень похож на C#. AVK>Я тебе говорю про C#. ПО факту XSLT намного удобнее в таких задачах.
Удобнее, но не в нашей.
AVK>>>Это вобще не нужно. Если у тебя что то зависит от порядка атрибутов то это очень криво.
PE>>Для XML нужны схемы данных.
AVK>Необязательно.
Это как же ты собираешь подсунуть челу редактировать XML без схем ?
AVK>Только по желанию. А регистр как таковой вобще не указывается, XML чувствителен к регистру.
Вот и я про то. Надо помнить все подряд. А свой язык можно упростить очень сильно.
AVK>С точностью до наоборот. Твой самопальный язык придется редактировать в ноутпаде, без подсветки синтаксиса. А xml можно редактировать в каком нибудь XmlSpy с куда большим комфортом.
Почему в нотепаде ? Парсинг языка вроде Паскаля — плевое дело. На третьем курсе студенты это делают.
Могу выслать компилер Модулы. Гы.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Я тебе говорю про C#. ПО факту XSLT намного удобнее в таких задачах.
PE>Удобнее, но не в нашей.
Тебе виднее.
AVK>>Необязательно.
PE>Это как же ты собираешь подсунуть челу редактировать XML без схем ?
А в чем проблема?
AVK>>Только по желанию. А регистр как таковой вобще не указывается, XML чувствителен к регистру.
PE>Вот и я про то. Надо помнить все подряд. А свой язык можно упростить очень сильно.
Сильнее XML вряд ли получится
AVK>>С точностью до наоборот. Твой самопальный язык придется редактировать в ноутпаде, без подсветки синтаксиса. А xml можно редактировать в каком нибудь XmlSpy с куда большим комфортом.
PE>Почему в нотепаде ? Парсинг языка вроде Паскаля — плевое дело.
А, ну ну. Значит схему написать это жутко долго, а вот отпарсить язык плевое дело.
PE> На третьем курсе студенты это делают.
То что они делают только для учебных целей и годится. А на практике чтобы получить production quality парсер даже несложного языка надо изрядно попахать. Вот тот же XML, казалось бы там парсер можно за полдня на коленке написать, а на практике даже для такого парсера придется попахать от души.
Здравствуйте, AndrewVK, Вы писали:
PE>>Это как же ты собираешь подсунуть челу редактировать XML без схем ? AVK>А в чем проблема?
Собственно в валидации.
AVK>>>Только по желанию. А регистр как таковой вообще не указывается, XML чувствителен к регистру.
PE>>Вот и я про то. Надо помнить все подряд. А свой язык можно упростить очень сильно.
AVK>Сильнее XML вряд ли получится
Я уже говорил, что XML это примитивный язык. Простота — это немного другое.
PE>>Почему в нотепаде ? Парсинг языка вроде Паскаля — плевое дело. AVK>А, ну ну. Значит схему написать это жутко долго, а вот отпарсить язык плевое дело.
Нет. Схему еще проще. Для редактирования XML придется свой редактор писать. Вот я про что.
AVK>То что они делают только для учебных целей и годится. А на практике чтобы получить production quality парсер даже несложного языка надо изрядно попахать. Вот тот же XML, казалось бы там парсер можно за полдня на коленке написать, а на практике даже для такого парсера придется попахать от души.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну так способ задания валидации при помощи схемы куда проще обработки ошибок в парсере.
Проще, но толку ? Нагляднее XML от этого не станет.
PE>>Я уже говорил, что XML это примитивный язык. Простота — это немного другое. AVK>Это все игра словами и ничего более.
Я уже приводил примеры. Ты разницу видел. Наш продукт — объектная модель данных(результат работы генератора), а не редактор или XML или еще что.
Посему лучше использовать специализированое средство.
AVK>>>А, ну ну. Значит схему написать это жутко долго, а вот отпарсить язык плевое дело.
PE>>Нет. Схему еще проще.
AVK>Причем намного. О том и речь.
PE>> Для редактирования XML придется свой редактор писать. Вот я про что. AVK>А для своего языка типа не надо? Впрочем меня пока XmlSpy устраивал по большей части.
Для своего языка мне хватит аддона для VS, который красить будет.
PE>>На практике пахать не нужно. Можно брать готовое. AVK>А готовое и есть XML.
Ну ты просто фанат по XML. Всему свое место. XML это не панацея. Читать его ез специфического редактора вообще невозможно. Аддон для студии и специализированый редактор XML — разные вещи.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Ну так способ задания валидации при помощи схемы куда проще обработки ошибок в парсере.
PE>Проще, но толку ? Нагляднее XML от этого не станет.
Я тебе уже два раза говорил — наглядность понятие субъективное.
PE>>>Я уже говорил, что XML это примитивный язык. Простота — это немного другое. AVK>>Это все игра словами и ничего более.
PE>Я уже приводил примеры. Ты разницу видел.
Видел. XML вариант мне понравился куда больше.
PE>Посему лучше использовать специализированое средство.
Которое не используется потому что его слишком долго делать. А вместо этого 600 классов написано руками. Мягко говоря странная у тебя логика.
PE>>> Для редактирования XML придется свой редактор писать. Вот я про что. AVK>>А для своего языка типа не надо? Впрочем меня пока XmlSpy устраивал по большей части.
PE>Для своего языка мне хватит аддона для VS, который красить будет.
Ты XmlSpy видел? Покраска синтаксиса это мизер по сравнению с ним.
PE>>>На практике пахать не нужно. Можно брать готовое. AVK>>А готовое и есть XML.
PE>Ну ты просто фанат по XML.
Нет, скорее ты С++.
PE> Всему свое место. XML это не панацея.
Нет, я об этом и не говорил. Но в качестве исходных данных для генераторов подходит очень хорошо.
PE> Читать его ез специфического редактора вообще невозможно.
Тебе. Мне например вполне возможно читать и в студийном редакторе и в браузере.
PE> Аддон для студии и специализированый редактор XML — разные вещи.
Если тебе так хочется аддон для студии, то XmlSpy умеет работать и таким манером.
Здравствуйте, AndrewVK, Вы писали:
PE>>Проще, но толку ? Нагляднее XML от этого не станет.
AVK>Я тебе уже два раза говорил — наглядность понятие субъективное.
Ты сказал, что XML с редактором удобнее для непрограммиста. Таких у нас не будет, ибо средство для внутреннего использования. Посему такие удобства сомнительны.
AVK>Видел. XML вариант мне понравился куда больше.
Это самы простой пример, что пришел в голову.
Для описания импорта-экспорта XML понимает только тот чел, который писал этот импорт-экспорт.
Вот такие дела.
AVK>Которое не используется потому что его слишком долго делать. А вместо этого 600 классов написано руками. Мягко говоря странная у тебя логика.
Здесь все сильно. Пока не прочувствуешь, что такое модель трехмерная, непонятно, как ее автоматизировать.
У нас был подход простой — примитивный генератор текста(интерфейсы, колекции, части классов и тд.)
PE>>Для своего языка мне хватит аддона для VS, который красить будет. AVK>Ты XmlSpy видел? Покраска синтаксиса это мизер по сравнению с ним.
Три года как вижу. Не подходит он никак для этого дела.
PE>> Всему свое место. XML это не панацея. AVK>Нет, я об этом и не говорил. Но в качестве исходных данных для генераторов подходит очень хорошо.
Для генератора — да. Для человека — нет.
AVK>Тебе. Мне например вполне возможно читать и в студийном редакторе и в браузере.
Количество текста играет существенную роль. 3 кб плотного текста есть отстой, а это средний размер для описания одной сущности.
PE>> Аддон для студии и специализированый редактор XML — разные вещи. AVK>Если тебе так хочется аддон для студии, то XmlSpy умеет работать и таким манером.
Мне нужно все лишь раскраска текста. А XML никак не сможет помочь. Если ты заметил, язык будет с объектнориентированым уклоном. Какие преимущества здесь XML дает, extends="BaseClass" ?
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Ты сказал, что XML с редактором удобнее для непрограммиста. Таких у нас не будет, ибо средство для внутреннего использования. Посему такие удобства сомнительны.
Тебе виднее.
AVK>>Видел. XML вариант мне понравился куда больше.
PE>Это самы простой пример, что пришел в голову. PE>Для описания импорта-экспорта XML понимает только тот чел, который писал этот импорт-экспорт. PE>Вот такие дела.
Я писал. Вот такие дела.
PE>Мне нужно все лишь раскраска текста. А XML никак не сможет помочь. Если ты заметил, язык будет с объектнориентированым уклоном. Какие преимущества здесь XML дает, extends="BaseClass" ?
И все таки я тебя не пойму. XML тебе не нравится, потому что слишком примитивно. Свой язык не нравится потому что слишком сложно. В итоге ты выбрал самое худшее из возможных решений — написание классов ручками.
Здравствуйте, AndrewVK, Вы писали:
PE>>Это самы простой пример, что пришел в голову. PE>>Для описания импорта-экспорта XML понимает только тот чел, который писал этот импорт-экспорт. PE>>Вот такие дела.
AVK>Я писал. Вот такие дела.
Писать можно, не спорю.
PE>>Мне нужно все лишь раскраска текста. А XML никак не сможет помочь. Если ты заметил, язык будет с объектнориентированым уклоном. Какие преимущества здесь XML дает, extends="BaseClass" ?
AVK>И все таки я тебя не пойму. XML тебе не нравится, потому что слишком примитивно. Свой язык не нравится потому что слишком сложно. В итоге ты выбрал самое худшее из возможных решений — написание классов ручками.
Я не выбирал. Я девелопер. Сверху сказали — .Net+C#.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Для генератора? Странные у тебя начальники.
PE>Для проекта.
Я вобще то про генератор все это время говорил, а не про проект.
PE> Наш продукт повторяю, объектная модель сети. Фреймворк неслабый.
Не, ну такое ощущение что ты один серьезные вещи пишешь, а остальные дурака валяют. Сложности есть везде. И в возможность их решать как раз и есть один из главных скиллов программиста.
Здравствуйте, AndrewVK, Вы писали:
PE>> Наш продукт повторяю, объектная модель сети. Фреймворк неслабый. AVK>Не, ну такое ощущение что ты один серьезные вещи пишешь, а остальные дурака валяют. Сложности есть везде. И в возможность их решать как раз и есть один из главных скиллов программиста.
Ого, куда тебя понесло. Я просто повторил на том случай, если ты не понял, что не генератор и редактор текста являются продуктами.
Язык должен четко отражать предметную область. Просто набор ключевых слов не годится.
Поскольку фреймворк достаточно большой, особых преимуществ в XML я не вижу.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Ого, куда тебя понесло. Я просто повторил на том случай, если ты не понял, что не генератор и редактор текста являются продуктами.
Тем более непонятно при чем тут требование начальства.
PE>Язык должен четко отражать предметную область. Просто набор ключевых слов не годится. PE>Поскольку фреймворк достаточно большой, особых преимуществ в XML я не вижу.
Поэтому пишете все руками вместо написания генератора?
Здравствуйте, AndrewVK, Вы писали:
PE>>Ого, куда тебя понесло. Я просто повторил на том случай, если ты не понял, что не генератор и редактор текста являются продуктами.
AVK>Тем более непонятно при чем тут требование начальства.
Сам продукт должен быть на дотнете. Начальство затребовало С#. Вот и все. Непонятно — дам мыло, спросишь у них сам.
PE>>Язык должен четко отражать предметную область. Просто набор ключевых слов не годится. PE>>Поскольку фреймворк достаточно большой, особых преимуществ в XML я не вижу.
AVK>Поэтому пишете все руками вместо написания генератора?
Частично руками. То, что не получается генерировать, руками. На XML не намного то и меньше.
Здравствуйте, Plutonia Experiment, Вы писали:
AVK>>Тем более непонятно при чем тут требование начальства.
PE>Сам продукт должен быть на дотнете. Начальство затребовало С#. Вот и все.
Нет, мне непонятно другое — при чем тут это если речь о генераторе и данных для него?
AVK>>Поэтому пишете все руками вместо написания генератора? PE>Частично руками. То, что не получается генерировать, руками.
А как же тогда 600 ручных классов? Больно много что то у вас получается руками.
PE> На XML не намного то и меньше.
Здравствуйте, AndrewVK, Вы писали:
AVK>Нет, мне непонятно другое — при чем тут это если речь о генераторе и данных для него?
Вот с чего началось
AVK>И все таки я тебя не пойму. XML тебе не нравится, потому что слишком примитивно. Свой язык не нравится потому что слишком сложно. В итоге ты выбрал самое худшее из возможных решений — написание классов ручками.
Я не выбирал. Я девелопер. Сверху сказали — .Net+C#.
Написание классов на C# руками это не мой выбор.
Имея С++, генерировать текст и использовать рефлекшн приходится в разы меньше, а то и вовсе без этого обходиться.
Сейчас, поскольку базовые классы уже на С#, С++ уже нет смысла использовать. Теперь я пробую оформить генерацию модели в Шарп. Модель задавать на XML громоздко, посему его думаю юзать лишь как промежуточный язык — его орабатывать проще.
Так понятно ?
Здравствуйте, AndrewVK, Вы писали:
AVK>А как же тогда 600 ручных классов? Больно много что то у вас получается руками.
Блин. Все классы создавались по UML. Потом на них был напущет постпроцессор жавовский.
На выходе поимели коллекции, и кучу кода, который не нужно руками писать.
Потом заполнили кой-какие методы и все.
Hello, Plutonia!
You wrote on Mon, 22 Mar 2004 18:07:43 GMT:
PE> 011>Modelica? PE> Нечто вроде. Только Моделика слишком сложная. А в нашей PE> области ничего нет такого.
Она не сложнее, чем C++. Правда, к ней шароварных компиляторов не найти. Был проект OpenModelics, но кажется умер.
PE> P.S. Откуда музыку достаешь ?
Приносят. &)
Regards,
011.
Winamp 5.0 (playing): Papa Roach — Between Angels And Insects
Здравствуйте, 011, Вы писали:
PE>> 011>Modelica? PE>> Нечто вроде. Только Моделика слишком сложная. А в нашей PE>> области ничего нет такого.
011>Она не сложнее, чем C++. Правда, к ней шароварных компиляторов не найти. Был проект OpenModelics, но кажется умер.
По сравнению с С++ это совсем просто. Все дело именно в компиляторе и внешнем интерфейсе.
Вот это и есть засада.
Хорошо, что ты пришел, а то AVK заладил про XML.
PE>> P.S. Откуда музыку достаешь ? 011>Приносят. &)
Здравствуйте, Kluev, Вы писали:
K>>>В С++ тоже можно генерить код на лету. Таскай с собой бесплатный Ц-компилер. генери Ц-код, собирай в DLL грузи и выгружай. И не капассируй нам мозги про генерацию кода. S>>Ну щас прям. И сразу получи платформенную зависимость. Как минимум. А также необходимость таскать с собой запас хидеров для того, чтобы генеренный код мог взаимодействовать с другим кодом. В общем, ребята, солюшн с Ц-компилером даже на шутку не тянет. Потому его и не применяет никто и никогда. В отличие от той самой генерации кода в .Net. K>В научной среде сплошь и к ряду, сам видел когда ишшо в институте учился. А чем плохо? быстродействие будет — закачаешься. А остальные проблемы при грамотном подходе и не проблеммы вообще. К тому же есть компилеры и кроссплатформенные.
Я так делал. Только компилятор не бесплатный. Но я этого не говорил . И МATLAB с той программой рядом не лежал. (по скорости, естестно ).
А еще машкоды в памяти. Но это уже не совсем ++
Сделать человеку приятное очень просто. Не сделайте ему гадость и ему будет приятно!
Баг — это клоп. Таpакан — это, видимо, фича.
Re[12]: C++ versus C#
От:
Аноним
Дата:
08.04.04 14:45
Оценка:
S>отсутствие ужасного разделения между декларацией и дефиницией, которое заставляет при чтении непрерывно прыгать между .cpp и .h
Так это и чертовски удобно — отладил модуль и используешь его. Реализация не мешает (дурацкие редакторы в VS.NET ). Я уж промолчу про зависимости для компилляции/линковки.
А вообще по C# — полная очередная чушь от MS. C++ переносится между компилляторами (был опыт переноса с Borland C++ на C++ Builder а потом на Visual C++). И проект не маленький. Попробуйте сделать тоже с C#
Здравствуйте, <Аноним>, Вы писали: А>Так это и чертовски удобно — отладил модуль и используешь его.
А что мешает в шарпе отладить и использовать? А>Реализация не мешает (дурацкие редакторы в VS.NET ). Я уж промолчу про зависимости для компилляции/линковки.
Это ты правильно придумал. Насчет помолчать. Ибо парсинг хидера в плюсах подороже, чем парсинг полного класса с шарпе обходится. А>А вообще по C# — полная очередная чушь от MS. C++ переносится между компилляторами (был опыт переноса с Borland C++ на C++ Builder а потом на Visual C++). И проект не маленький. Попробуйте сделать тоже с C#
Легко. Пока что все наличные компиляторы C# прекрасно компилируют код. И, в отличие от переносов между борланд/микрософт, нет никаких проблем с различиями в библиотеках.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: C++ versus C#
От:
Аноним
Дата:
09.04.04 05:54
Оценка:
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, <Аноним>, Вы писали: А>>Так это и чертовски удобно — отладил модуль и используешь его. S>А что мешает в шарпе отладить и использовать?
Извини, хотел сказать, что для использования класса мне нет надобности смотреть его реализацию. Лично мне кажется, что это удобнее — код не мешает.
Здравствуйте, <Аноним>, Вы писали: А>Извини, хотел сказать, что для использования класса мне нет надобности смотреть его реализацию. Лично мне кажется, что это удобнее — код не мешает.
В шарпе для использования класса обычно его реализацию тоже никто не смотрит. Заголовочную информацию показывает Object Explorer. Причем в значительно более удобном, нежели С++, виде. Для библиотечных классов в исходники ты так просто и не залезешь. Исходник виден только для тех файлов, которые ты разрабатываешь. Так что претензия высосана из пальца.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Вопрос слегка не в тему
От:
Аноним
Дата:
18.04.04 16:33
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Если есть люди, которые долго писали на плюсах, а потом срочно перешли только на шарп.
Есть. А>Какие были впечатления? Не хочется ли обратно?)
В основном положительные.Обратно не хочется. А>Мне вот сейчас как раз это предстоит.
Ну, всяко лучше, чем с C# на C++ или, не дай бог, на Object Pascal
Re[3]: Вопрос слегка не в тему
От:
Аноним
Дата:
18.04.04 16:35
Оценка:
Здравствуйте, voxel3d, Вы писали:
А>>Если есть люди, которые долго писали на плюсах, а потом срочно перешли только на шарп. А>>Какие были впечатления? Не хочется ли обратно?) А>>Мне вот сейчас как раз это предстоит.
V>Лично я разумом понимаю, что использование шарпа здорово удешевляет проект.. но, хочу обратно на плюсы.. Что-то тут утеряно что ли
Ну да. Шаблоны утеряны. Но в C# 2 будут тебе шаблоны. V>Ну, не нравится мне шарп, хотя надо признать вещь весьма достойная. На твой вопрос вряд ли будет объективный ответ.
А чем он тебе не нравится?
Re[5]: Вопрос слегка не в тему
От:
Аноним
Дата:
18.04.04 16:39
Оценка:
Здравствуйте, voxel3d, Вы писали:
А>>Ясно) Интересно, что у тебя за проект, и почему его решили на шарпе писать?)
V>Много всяких. От всякого бухгалтерского дерьма, систем обработки заказов, до оптимизаций грузоперевозок. Шарп используется, потому что на нём удобно проектировать сложные проекты. Я понимаю, что проектирование и язык программирования суть разные вещи, я имею ввиду в шарпе удобно спроектированные конструкции воплощать. Эвенты, делегаты, сборщик мусора, аттрибуты, большая библиотека классов и ограниченность языка по сравнению с С++ -- всё это
делает проект дешевле. С другой стороны, меня тошнит уже. Но бизнес есть бизнес.
Так C++, за исключением шаблонов, более ограниченный язык.
Здравствуйте, <Аноним>, Вы писали:
А>Так C++, за исключением шаблонов, более ограниченный язык.
C++-то как раз куда менее ограниченный чем C#. Зато вот Win32 куда более ограниченная платформа чем .NET
... << RSDN@Home 1.1.3 stable >>
Re[5]: Вопрос слегка не в тему
От:
Аноним
Дата:
18.04.04 16:47
Оценка:
Здравствуйте, voxel3d, Вы писали:
V>Ну, я же сказал, субъективно это всё. Меня раздражает ихний сборщик мусора, если б я сам его написал, он мне бы нравился ,
Чем раздражает? Если грамотно писать, то проблем с ним не бывает.
V>меня раздражает отсутствие указателей, верннее их невостребованность, то что ссылки являются указателями, а не
А какая тебе разница? Это в духе: меня раздражает, что у меня в квартире теперь нет тараканов...
V>алиасами, то что отсутствуют хидеры,
А зачем тебе хидеры при наличии namespace`ов, нормальных сред разработки и самодокументированного кода?
V>отсутствие адресной арифметики,
Она вообще-то есть, равно как и указатели. См. unsafe и см. fixed
V>до сих пор отсутствие шаблонов,
Это единственное, с чем я соглашусь. Ждем C# 2. Уже скоро.
V>невостребованность и отсутствие множественного наследия,
Есть множественное интерфейсное наследование — большего не надо, а если надо, значит ошибка проектирования.
V>то что не надо помнить мрачные правила преобразования типов, то что когда параллельно со мной работали дельфисты, они дерево изделия состоящее из 20 тысяч деталей читали из базы, строили в памяти структуру и выводили её в тривью за 20 секунд, а я за 4..
Мсье таки мазохист?
V>то что это уже не переносимый ассемблер и то что мне не требуется читать Мэйерса, Элджера и Александреску, да и Страуструпа тоже, после перечитывания которых каждый раз я понимал, что до этого С++ я не знал.. И вообще, я любил секс с непонятными глюками, дебаггер и профайлер были моими любимыми игрушками и я знал, что кроме меня баги никто победить не в состоянии будет, а здесь.. всё упростилось. Синтаксис изучил, с библиотекой классов ознакомился, всё. Идиомы гораздо проще.. Нету в шарпе духа, сдох он. И свободы в нём нет. Есть только один стиль написания программ -- правильный. Неинтересно. В С++ мои знания в глубину росли, а здесь я не понимаю вообще куда.. С шарпом с хорошим архитектором, очень умные программисты в 80% проектов не особо нужны бывают.. В С++ такой номер не прокатил бы..
Демагогия.
Re[12]: Вопрос слегка не в тему
От:
Аноним
Дата:
18.04.04 16:51
Оценка:
Здравствуйте, naje, Вы писали:
N>сразу говорю что я не согласен что скорость разработки сильно увеличивает CLR, remouting, reflection (так сразу всё и не вспомню) N>то что много чего переложено на рантайм помоему замедляет разработку приложения(ну и его производительность), конечно даёт кучу преимуществ, но зачем они все нужны?
Затем, что время — деньги. А время программиста — большие деньги. Да и лишней сложности свойственно порождать лишние баги — человеческий фактор.
Re: C++ versus C#
От:
Аноним
Дата:
19.04.04 10:40
Оценка:
Здравствуйте, c-smile, Вы писали:
CS>Два примера С# и С++ делающие следюущее:
CS>
Здравствуйте, <Аноним>, Вы писали:
ВВ>>C++-то как раз куда менее ограниченный чем C#. А>Мы про язык? Тогда считаем: А>1. Атрибуты. А>2. Сборщик муссора. А>3. Отражения. А>4. foreach А>5. Мощный строковый тип А>6. Многомерные массивы, массивы массивов А>7. Делегаты, цепочки делегатов. А>8. События. А>9. SEH. А>10. Параметризованные/непараметризованные свойства + наследование свойств. А>11. Тип 128-битный тип decimal
Большая часть из того, что вы перечислили к _языку_ C# имеет весьма опосредованное отношение, а то и не имеет вовсе.
ВВ>>Зато вот Win32 куда более ограниченная платформа чем .NET А>Да-да, крокодил больше длинный, чем зеленый... Проходили.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>C++-то как раз куда менее ограниченный чем C#. А>>Мы про язык? Тогда считаем: А>>1. Атрибуты. А>>2. Сборщик муссора. А>>3. Отражения. А>>4. foreach А>>5. Мощный строковый тип А>>6. Многомерные массивы, массивы массивов А>>7. Делегаты, цепочки делегатов. А>>8. События. А>>9. SEH. А>>10. Параметризованные/непараметризованные свойства + наследование свойств. А>>11. Тип 128-битный тип decimal
ВВ>Большая часть из того, что вы перечислили к _языку_ C# имеет весьма опосредованное отношение, а то и не имеет вовсе.
Открываете спецификацию C# и убеждаетесь в его правоте. Все (кроме, разве что, отражений) вышеперечисленные понятия имеют непосредственное отношение к языку C#.
Здравствуйте, kuj, Вы писали:
kuj>Открываете спецификацию C# и убеждаетесь в его правоте. Все (кроме, разве что, отражений) вышеперечисленные понятия имеют непосредственное отношение к языку C#.
Здравствуйте, kuj, Вы писали: kuj>Свойства, атрибуты, отражения? Можно узнать урлы библиотек, реализующих это?
Свойства — нет, это фича компилятора.
System.Attribute лежит в Mscorlib.dll
System.Reflection.* — там же
System.String — там же
System.Array — там же
System.Delegate — там же
System.Decimal — там же. kuj>Да, а еще хотелось бы урл на полноценный эфемерный сборщик муссора с дефрагментацией кучи, масштабируемый на многопроцессорной системе и отдельной кучей для больших объектов. Можно? Буду очень признателен!
.NET Framework Redistributable. Ты думаешь если из него снести csc.exe, то сборщик мусора работать перестанет?
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Воронков Василий, Вы писали:
kuj>>>Открываете спецификацию C# и убеждаетесь в его правоте. Все (кроме, разве что, отражений) вышеперечисленные понятия имеют непосредственное отношение к языку C#.
ВВ>>При этом все это реализовано на уровне библиотек. kuj>Свойства,
Ну свойства это язык
kuj>атрибуты,
System.Attribute (mscorlib.dll)
kuj>отражения?
System.Reflection.* (mscorlib.dll)
kuj>Да, а еще хотелось бы урл на полноценный эфемерный сборщик муссора с дефрагментацией кучи, масштабируемый на многопроцессорной системе и отдельной кучей для больших объектов.
Здравствуйте, Воронков Василий, Вы писали:
kuj>>>>Открываете спецификацию C# и убеждаетесь в его правоте. Все (кроме, разве что, отражений) вышеперечисленные понятия имеют непосредственное отношение к языку C#.
ВВ>>>При этом все это реализовано на уровне библиотек. kuj>>Свойства, ВВ>Ну свойства это язык
kuj>>атрибуты, ВВ>System.Attribute (mscorlib.dll)
Стоп-стоп! Речь ведь о C++, а не о managed C++. Это два разных языка. А managed языки отличаются очень незначительно.
ВВ>8. События. ВВ>Реализованы на делегатах
Но поддержка со стороны языка в виде ключевого слова event.
Здравствуйте, Sinclair, Вы писали:
kuj>>Свойства, атрибуты, отражения? Можно узнать урлы библиотек, реализующих это? S>Свойства — нет, это фича компилятора. S>System.Attribute лежит в Mscorlib.dll
Хм , если бы Вы внимательно перечитали тред, то заметили бы, что на протяжении всего треда речь шла о сопоставлении "unmanaged" C++ и C#. Естественно, managed C++ от C# функционально почти не отличается. С этим никто по-моему и не спорил.
Здравствуйте, kuj, Вы писали:
kuj>>>атрибуты, ВВ>>System.Attribute (mscorlib.dll) kuj>Стоп-стоп! Речь ведь о C++, а не о managed C++. Это два разных языка. А managed языки отличаются очень незначительно.
Здравствуйте, Воронков Василий, Вы писали:
kuj>>>>атрибуты, ВВ>>>System.Attribute (mscorlib.dll) kuj>>Стоп-стоп! Речь ведь о C++, а не о managed C++. Это два разных языка. А managed языки отличаются очень незначительно.
ВВ>A причем здесь вообще С++? Мы же о C# говорим.
А>>Ясно) Интересно, что у тебя за проект, и почему его решили на шарпе писать?)
V>Много всяких. От всякого бухгалтерского дерьма, систем обработки заказов, до оптимизаций грузоперевозок. Шарп используется, потому что на нём удобно проектировать сложные проекты. Я понимаю, что проектирование и язык программирования суть разные вещи, я имею ввиду в шарпе удобно спроектированные конструкции воплощать. Эвенты, делегаты, сборщик мусора, аттрибуты, большая библиотека классов и ограниченность языка по сравнению с С++ -- всё это
делает проект дешевле. С другой стороны, меня тошнит уже. Но бизнес есть бизнес.
Так C++, за исключением шаблонов, более ограниченный язык.
Здравствуйте, kuj, Вы писали:
kuj>Так C++, за исключением шаблонов, более ограниченный язык.
В ответ на что я написал, что это C# более ограниченный язык. А фичи C#, о которых вы говорите, являются фичам платформы .NET, и к языку имеют весьма опосредованное отношение.
Здравствуйте, kuj, Вы писали: kuj>Хм , если бы Вы внимательно перечитали тред, то заметили бы, что на протяжении всего треда речь шла о сопоставлении "unmanaged" C++ и C#. Естественно, managed C++ от C# функционально почти не отличается. С этим никто по-моему и не спорил.
Я вообще ничего про managed мы unmanaged не говорил. Вы спросили урл библиотеки, которая реализует функциональность, предоставленную (по вашему мнению) C#. Вот я вам его и дал.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
kuj>>Хм , если бы Вы внимательно перечитали тред, то заметили бы, что на протяжении всего треда речь шла о сопоставлении "unmanaged" C++ и C#. Естественно, managed C++ от C# функционально почти не отличается. С этим никто по-моему и не спорил. S>Я вообще ничего про managed мы unmanaged не говорил. Вы спросили урл библиотеки, которая реализует функциональность, предоставленную (по вашему мнению) C#. Вот я вам его и дал.
Спасибо конечно, но, боюсь, что unmanaged (который ANSI) C++ эту библиотеку не поймет. Так что ваш ответ, мягко говоря, был э-э-э.. "мимо тазика".
Здравствуйте, kuj, Вы писали: kuj>Спасибо конечно, но, боюсь, что unmanaged (который ANSI) C++ эту библиотеку не поймет. Так что ваш ответ, мягко говоря, был э-э-э.. "мимо тазика".
Так, проблемы с reading skills. Попробую объяснить поподробнее:
1. Спор зашел о том, какой из языков более ограничен
2. Василий утверждает, что C#.
3. Аноним пытется привести в опровержение список фич, которых нет в С++
4. Василий отвечает ему, что в C# этих фич тоже нет.
5. Ты начинаешь ссылаться на спецификации С#
6. Василий намекает, что почти все из упомянутого, реализуется не C#, а библиотеками.
7. Ты требуешь их предъявить.
Ну вот я и предъявил. А теперь ты начинаешь делать вид, что говорил про библиотеки для С++. Не было такого.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>В ответ на что я написал, что это C# более ограниченный язык. А фичи C#, о которых вы говорите, являются фичам платформы .NET, и к языку имеют весьма опосредованное отношение.
А что есть Шарп не под дотнет? Считай дотнет рантаймом Шарпа. Что это изменит. Ведь без CRT в VC невозможно даже глобальные переменные проинициализировать.
Безспорно реализация многих фич дотнета связана с CLR и FCL, но ведь язык от этого языком быть не перестает.
Я так полностью согласен с тем, что Шарп богаче С++. Есть только несколько фич которых нет в Шарпе, но есть в С++:
1. Деструкторы (так они ненужны, да и кое что есть)
2. Множественное наследование (приятная фича для подключения реализаций)
3. Шаблоны (частично будут компенсированы в Шарпе 2)
4. Const для как ограничитель модифицируемости переменных (в общем фигня, жить не мешает, даже упрощает жизнь).
5. Возможность пергружать оператор "=" (реально больше вред, чем полезная фича)
6. Возможно перегрузки операторов << >> не для сдвигов (со вторым параметром не равным int). (опять же сделано чтобы люди не использовали средсва языка не по их назначению, хотя это как раз уже спроное решение)
7. typedef
8. Сложные макросы
9. Большая совместимость с С.
Больше я ничего не помню.
Все остальное в Шаре или лучше, или больше. Ну, и что, что даже строгая типизация — это тоже заслуга CLR? Она же есть? А в С++ ее нет.
Причем список то далеко не полон. Есть еще:
1. Интерфейсы
2. Безопасные функции с переменным количеством параметров
3. Встроенные массивы
4. Боксинг/анбоксинг.
5. Полная типобезопастность в сэйф-режиме.
6. Модульность. (а значит большая отчуждаемость и скорость компиляции)
7. Компнентность.
8. finally
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>System.Attribute лежит в Mscorlib.dll
Атрибуты тоже фича копилятора. Мало ли что они требуют поддрежки CLR. S>System.Reflection.* — там же
Пожалй единственное польностью не относящееся к языку. S>System.String — там же
Фиг. Это всего лишь реализация. string описан в спецификации Шарпп. Так что это язык. S>System.Array — там же
Тоже опиман в стандатре. Но массивы — это не System.Array. Это встроенные в язык средства работы с ними. А они все описаны в спецификации. Джагед-массивы так вообще фича уникальная для шарпа. S>System.Delegate — там же
И они описаны. Вы все время путаете понятия требует поддержки рантайма и является частью языка. Есть ключевое слово delegate. Оно в спецификации. Ну, как можно рассуждать о том, что оно не оно не отностися к языку? S>System.Decimal — там же.
Что тоже? Его нет в специяикации? Компилятор требует отдельного класса для организации вычисления с ним?
kuj>>Да, а еще хотелось бы урл на полноценный эфемерный сборщик муссора с дефрагментацией кучи, масштабируемый на многопроцессорной системе и отдельной кучей для больших объектов. Можно? Буду очень признателен! S>.NET Framework Redistributable. Ты думаешь если из него снести csc.exe, то сборщик мусора работать перестанет?
Кстати, без Шарпа дотнет не заработает. Все что написано не на С++ написанно именно на нем. Но думаю он спрашивал о подобных библиотеках для С++.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Безспорно реализация многих фич дотнета связана с CLR и FCL, но ведь язык от этого языком быть не перестает.
VD>Я так полностью согласен с тем, что Шарп богаче С++. Есть только несколько фич которых нет в Шарпе, но есть в С++: VD>1. Деструкторы (так они ненужны, да и кое что есть)
Есть и в C#. Даже синтаксис такой же. VD>2. Множественное наследование (приятная фича для подключения реализаций)
Есть множественное интерфейсное наследование. VD>3. Шаблоны (частично будут компенсированы в Шарпе 2)
Почему частично? VD>4. Const для как ограничитель модифицируемости переменных (в общем фигня, жить не мешает, даже упрощает жизнь).
const тоже есть. VD>7. typedef
А зачем? VD>8. Сложные макросы
Зачем? VD>9. Большая совместимость с С.
Здравствуйте, VladD2, Вы писали:
VD>Если считать по количеству фич, то это факт. Другое дело, что фичи вроде Шаблонов и МН могут многое перевесить.
По поводу шаблонов абсолютно согласен. Но есть ведь МИН. Зачем еще обычное МН? Нет, не спорю, МН может пригодится, но так ли часто? К тому же, само по себе оно весь небезопасно...
Здравствуйте, kuj, Вы писали:
kuj>По поводу шаблонов абсолютно согласен. Но есть ведь МИН. Зачем еще обычное МН? Нет, не спорю, МН может пригодится, но так ли часто? К тому же, само по себе оно весь небезопасно...
Я не знаю что значит И в МИН. А по поводу МН... дорого яичко к христову дню. Само МН не в полном объеме может и не нужно. А вот подключение готовых реализаций (совместно с шаблонами) которое оно позволяет делать очень даже полезно. Правда в R#-е это уже делается и без МН. Да и других способов обхъода проблемы много, но в C# их нет. Вернее есть самые некрасивые и трудоемкие решения.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, kuj, Вы писали:
VD>>1. Деструкторы (так они ненужны, да и кое что есть) kuj>Есть и в C#. Даже синтаксис такой же.
Синтаксис то такой же, но семантика разная. В Шарпе — это финалайзер. Может вызваться черт знает когда, а десртуктор всегда при вызоде из области видимости.
Лично я бы оставил эту фичу для структур.
VD>>2. Множественное наследование (приятная фича для подключения реализаций) kuj>Есть множественное интерфейсное наследование.
Это разные вещи. Реализацию таким образом не подключишь.
VD>>3. Шаблоны (частично будут компенсированы в Шарпе 2) kuj>Почему частично?
Потому что возможности шаблонов С++ намного шире чем дженериков. Правда с точки зрения чистоты и простоты языка — это даже плюс. Но ограничение на лицо.
VD>>4. Const для как ограничитель модифицируемости переменных (в общем фигня, жить не мешает, даже упрощает жизнь). kuj>const тоже есть.
Опять же есть, да не тот. Попробуй в шарпе вот такое написать:
int f(const int i) const
{
const k = i + 3;
// k++; // вот тут бы компилятор послал бы на фиг
// _classMember++; // и тут тожеreturn k;
}
VD>>7. typedef kuj>А зачем?
Хотя бы за тем, чтобы HDC нельзя было присвоить к HWND. А вообще, это позволяет иногда существенно сократить объем кода и очень полезно в сочетании с шаблонами.
VD>>8. Сложные макросы kuj>Зачем?
Тут я согласен, что в том виде в каком они есть в С++ лучше бы их и вовсе небыло. Ну, есть же!
VD>>9. Большая совместимость с С. kuj>
Опять же я тоже считаю это скорее недостатком, но это факт.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
kuj>>По поводу шаблонов абсолютно согласен. Но есть ведь МИН. Зачем еще обычное МН? Нет, не спорю, МН может пригодится, но так ли часто? К тому же, само по себе оно весь небезопасно...
VD>Я не знаю что значит И в МИН.
Интерфейсное — множественное интерфейсное наследование. Или под МН подразумевалось нечто иное? VD>А по поводу МН... дорого яичко к христову дню. Само МН не в полном объеме может и не нужно. А вот подключение готовых реализаций (совместно с шаблонами) которое оно позволяет делать очень даже полезно.
Э-э, реализаций чего? VD>Правда в R#-е это уже делается и без МН. Да и других способов обхъода проблемы много, но в C# их нет. Вернее есть самые некрасивые и трудоемкие решения.
Еще раз, МН — множественное наследование?
Здравствуйте, AndrewVK, Вы писали:
PE>> Смотри в IDL.
AVK>Вот смотрел, потому и говорю. WSDL удобнее, более масштабируемо и мощнее.
WSDL то удобнее? Не, ну, ты уже просто пухнеш от этого эксемеля. Блни, эдак и к ассемблеру можно привыкнуть.
Я конечно согласен, что его проблемы нужно решать декларациямии и генератором по ним, но так же соглашусь с Plutonia, что декларировать будет куда удобнее на декларативной части С-подобного языка. Она кстати, тоже исключительно для деклараций предназначена. А если это будет Шарп с его атрибутами, то и проблем не будет.
ЗЫ
2Plutonia: Може правда возмешь R# и попробуешь что-нить на нем слабать? За одно мне идей подкинешь...
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
PE>>Ну ты просто фанат по XML.
AVK>Нет, скорее ты С++.
Не деритесь, я вас рассужу...
Вы оба фанаты. Один С(с чем-нить), другой ХМЛ-я.
И спорить любите.
По сути вы пришли к главному выводу: схему лучше описывать декларативно, а код генерировать.
Что исопльзовать для описания ХМЛ или некий дургой язык не так важно.
Если пользователь будет программистом, то конечно предпочтительнее свой языкх.
Если нет, то возможно вообще лучшим выходом будет создание БД для хранения описания и генеарция кода на ее базе.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
PE>>На основе XML неудобно. Я думаю, что это может быть нечто вроде С-подобного языка такого плана. VD>Кстати, R# уже кое-как работает. Так что можешь попробовать его.
Здравствуйте, VladD2, Вы писали:
VD>ЗЫ
VD>2Plutonia: Може правда возмешь R# и попробуешь что-нить на нем слабать? За одно мне идей подкинешь...
Что-нить понятие весьма растяжимое. Я не знаю, что тебя интересует, но успел уяснить, что области у нас с тобой и АВК совершенно различные. У меня десктоп приложения, модель данных и тд. Еще вот серилизацией занялись.
Здравствуйте, Plutonia Experiment, Вы писали:
VD>>Кстати, R# уже кое-как работает. Так что можешь попробовать его.
PE>Опробовать можно, почему бы и нет ?
Могу подключить к ЦВС.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Что-нить понятие весьма растяжимое. Я не знаю, что тебя интересует, но успел уяснить, что области у нас с тобой и АВК совершенно различные. У меня десктоп приложения, модель данных и тд. Еще вот серилизацией занялись.
R# — это не область. Это универсальная технология.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>А без ЦВС нельзя ? У меня нет доступа на внешние ЦВС. Только если из дому, то там у меня канал очень тонкий. PE>Вообще, попробовать можно, .
Ну, если только по почте отдельную версию. Но проект постоянно изменяется.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
PE>>Вообще, попробовать можно, .
VD>Ну, если только по почте отдельную версию. Но проект постоянно изменяется.
Тогда сделаем таким образом, если не возражаешь. Ты высылаешь на почту(ту, на которуй подписка отправляется), последнюю версию. Ну и напиши, что надо написать с помощью R#. Я так понял некое тестовое приложение ? Это лучше сюда.
А потом я попробую прикруть домой интернет нормальный.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Тогда сделаем таким образом, если не возражаешь. Ты высылаешь на почту(ту, на которуй подписка отправляется), последнюю версию. Ну и напиши, что надо написать с помощью R#. Я так понял некое тестовое приложение ? Это лучше сюда.
Вот пишу издому. Вроде все пучком. Надо полагать, что ЦВС пройдеть.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>>>C++-то как раз куда менее ограниченный чем C#. А>>>Мы про язык? Тогда считаем:
1. Атрибуты.
2. Сборщик муссора.
3. Отражения. ( очень частично RTTI + метаклассы)
4. foreach
5. Мощный строковый тип (есть)
6. Многомерные массивы, массивы массивов (есть)
7. Делегаты, цепочки делегатов.(есть, цепочек нет но реализовать несложно)
8. События.(есть)
9. SEH.(есть)
10. Параметризованные/непараметризованные свойства + наследование свойств.(есть)
11. Тип 128-битный тип decimal
ВВ>>Большая часть из того, что вы перечислили к _языку_ C# имеет весьма опосредованное отношение, а то и не имеет вовсе. kuj>Открываете спецификацию C# и убеждаетесь в его правоте. Все (кроме, разве что, отражений) вышеперечисленные понятия имеют непосредственное отношение к языку C#.
А теперь сравниваем с Delphi. Сам себе же и противоречишь
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
ВВ>>>>>C++-то как раз куда менее ограниченный чем C#. А>>>>Мы про язык? Тогда считаем: S>1. Атрибуты. S>2. Сборщик муссора. S>3. Отражения. ( очень частично RTTI + метаклассы) Очень частично. S>4. foreach S>5. Мощный строковый тип (есть)
Где? В MFC — не дотягивает. В ATL — аналогично. В STL — аналогично. А встроенного и единого так вообще нет. S>6. Многомерные массивы, массивы массивов (есть)
В языке? Нету. Точнее есть, но только при условии, что для n-1 из n измерений известны размерности. Иначе работа с таким массивом выраждается в адресную арифметику. Вредность последнего очевидна. Согласны? S>7. Делегаты, цепочки делегатов.(есть, цепочек нет но реализовать несложно)
В языке нету. S>8. События.(есть)
В языке нету. S>9. SEH.(есть)
В языке нету. S>10. Параметризованные/непараметризованные свойства + наследование свойств.(есть)
В языке нету. В COM`е выраждается в доступ по аксессорам (методы get_, set_).
ВВ>>>Большая часть из того, что вы перечислили к _языку_ C# имеет весьма опосредованное отношение, а то и не имеет вовсе. kuj>>Открываете спецификацию C# и убеждаетесь в его правоте. Все (кроме, разве что, отражений) вышеперечисленные понятия имеют непосредственное отношение к языку C#. S> А теперь сравниваем с Delphi. Сам себе же и противоречишь
В чем? Разве кто-то из "сишников" с голым языком работает? Нет. А для модели COM (ATL) все вышеозначенное (кроме сборщика муссора и отражений) не ново.
Здравствуйте, VladD2, Вы писали:
PE>>А когда ты отписал ? Вчера(пятница) вечером еще ничего не было. А сейчас я к почте доступа не имею. VD>Я уж и не помню. Ну, да пробуй так. Пароль я тот что в письме был взял. Модуль называется /rsharp.
Все пучком, просто почта долго шла почему то. Сегодня попробую