Re[4]: Вопрос слегка не в тему
От: voxel3d  
Дата: 26.02.04 09:39
Оценка: 5 (3) +1 :))
Здравствуйте, VladD2, Вы писали:

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


VD>А от чего тошнит? Можешь разжевать? Я вот как-то чем дальше, тем больше вспоминаю о плюсах как о страшном сне.


Ну, я же сказал, субъективно это всё. Меня раздражает ихний сборщик мусора, если б я сам его написал, он мне бы нравился , меня раздражает отсутствие указателей, верннее их невостребованность, то что ссылки являются указателями, а не алиасами, то что отсутствуют хидеры, отсутствие адресной арифметики, до сих пор отсутствие шаблонов, невостребованность и отсутствие множественного наследия, то что не надо помнить мрачные правила преобразования типов, то что когда параллельно со мной работали дельфисты, они дерево изделия состоящее из 20 тысяч деталей читали из базы, строили в памяти структуру и выводили её в тривью за 20 секунд, а я за 4.. то что это уже не переносимый ассемблер и то что мне не требуется читать Мэйерса, Элджера и Александреску, да и Страуструпа тоже, после перечитывания которых каждый раз я понимал, что до этого С++ я не знал.. И вообще, я любил секс с непонятными глюками, дебаггер и профайлер были моими любимыми игрушками и я знал, что кроме меня баги никто победить не в состоянии будет, а здесь.. всё упростилось. Синтаксис изучил, с библиотекой классов ознакомился, всё. Идиомы гораздо проще.. Нету в шарпе духа, сдох он. И свободы в нём нет. Есть только один стиль написания программ -- правильный. Неинтересно. В С++ мои знания в глубину росли, а здесь я не понимаю вообще куда.. С шарпом с хорошим архитектором, очень умные программисты в 80% проектов не особо нужны бывают.. В С++ такой номер не прокатил бы..

Но ничего, я нашёл новую игрушку -- Linux, там С++ хоть отбавляй.

best regards..
Re: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 19.02.04 23:28
Оценка: 3 (1) +1
Здравствуйте, c-smile, Вы писали:

CS>Навеяно спорами с VladD2 (http://www.rsdn.ru/Forum/Message.aspx?mid=538145&only=1
Автор:
Дата: 13.02.04
)

CS>И вербально по месту с iLYA.

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

Итак, для начала определимся, что конкретно мы сравниваем. Сравнивать 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 (работающий с Юникодом). Переписываем тест:

#include "stdafx.h"
#include "atlstr.h"
#include <time.h>
#include <stdlib.h>

int _tmain()
{
    double elapsedTime;
    clock_t stopTime;
    clock_t startTime = clock();

    int i;
    CStringW buf1;
    CStringW buf2;

    for (i = 0; i < 10000000; i++ )
    {
        if((i & 1) == 0)
            buf1.Append(L"hello", 5);
        else
            buf2.Append(L"hello!", 6);
    }
    stopTime = clock();
    elapsedTime = (stopTime - startTime) /  (CLOCKS_PER_SEC / (double) 1000.0);
    printf("String Concat. Elapsed time: %1.0f\n", elapsedTime);//, strbuf);

    return 0;
}



Запускаем... дожидаемся, окончания работы программы... и делаем выводы.

Выводы не утешительны. С++ вообще не пригоден для программирования.

Обман? Несомненно!

PS

Какой же вывод можно сделать из всего этого? Да очень простой. Разница в коде порождаемом JIT-ом .NET-а/Явы и кодом порождаемом оптимизирующим компилятором С++ ничтожна. Она конечно есть, и в большинстве случаев она не в пользу .NET-а, но намного больше на работу конечного приложения влияет правильность выбора алгоритма и грамотность реализации этого алгоритма.

Намек ясен?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: C++ versus C#
От: IT Россия linq2db.com
Дата: 20.02.04 04:04
Оценка: :))
Здравствуйте, c-smile, Вы писали:

CS>Использовать для этой цели CString/String/std::string — это даже не "средний программист", это хуже.


Индус?
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: C++ versus C#
От: alexkro  
Дата: 23.02.04 06:44
Оценка: +2
Здравствуйте, 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'ом в программе).
Re[20]: C++ versus C#
От: Kluev  
Дата: 26.02.04 13:58
Оценка: +1 -1
Здравствуйте, Sinclair, Вы писали:

S>Неправда. В этом языке нет метаданных. Ты не сможешь сделать, например, маршалинг автоматически. Существующие для С++ решения опираются на инструменты автоматической генерации исходного кода. MIDL — suxx.


Не так часто нужен маршаллинг, а когда нужен то ИМХО что-то типа MIDL в самый раз. Зачем собирать мусор со всего света и тащить его в язык?. Лучше узкоспециализированные веши порешать специальными заточенными тулзами. Тады все будет ОК. И свобода выбора останется. Вдруг понадобятся тебе специализированные метаданные и упресся ты в то, что намертво в НЕТ зашито, тады сразу вспомнишь старые добрые плюсы.

S>>>JIT, Metadata, User-Defined Metadata. Этого в С++ нет и быть не может. Некоторые из моментов поддаются эмуляции. Да и то она выглядит достаточно бледно по сравнению с тем, что есть в .Net. Одна возможность генерации кода на лету открывает совершенно новое измерение гибкости и комфорту.


S>Нельзя там сделать генерацию кода. Вся генерация кода заканчивается в compile-time. Оставаясь в рамках языка, ты не сможешь генерировать в рантайме исполняемый код. А зачем — для перформанса, вестимо. Ты про частичные вычисления слышал? Гуглить по фамилии "Ершов". Смысл в том, что компилятор ограничен знаниями, которые у него есть. В рантайме можно получить дополнительную информацию для семантической оптимизации. В рамках С++ ее использовать нельзя — код представляет собой монолит, и подправить его не выйдет.


В С++ тоже можно генерить код на лету. Таскай с собой бесплатный Ц-компилер. генери Ц-код, собирай в DLL грузи и выгружай. И не капассируй нам мозги про генерацию кода.

S>Про легко и ярко — ну я бы не сказал. Вон, в RSDN #5 есть статья "МЕтаданные своими руками". Ага. Эмуляция того, что встроено в .Net. Сложность и неудобство видны невооруженным взглядом.


Сложность где? Я вот идейку на вооружение взял, порешал то-что нужно и в макрос все завернул. Теперь добавляю в свои классцы по одной строчке на класс и не нарадуюсь. Все летает и гемороя не имею. И ограничений особых нет.
Re[24]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.03.04 10:10
Оценка: -1 :)
Здравствуйте, VladD2, Вы писали:

K>>Автоматическое управление памятью — это фатальный недостаток НЕТ. Программы которые манипулируют одновременно около 100000 обьектами связанными в сеть, писать на НЕТ просто нет смысла.


VD>100000? Я когда грид отлаживал как раз дерево из этго количества строил. Загружается молниеносно.


Из чего загружается ? Попробуй загрузить 100'000 объектов, которые указывают друг на друга, по пять-десять пропертей, из файла.
Re[57]: C++ versus C#
От: 011  
Дата: 22.03.04 18:01
Оценка: 3 (1)
Hello, Plutonia!
You wrote on Sat, 13 Mar 2004 10:17:42 GMT:

PE>>> Нужно написать такой язык, отладить, протестировать,

AVK>> XML + embedded C# или VB.
PE> Не пойдет. Нужен специализированый язык, нечто вроде UML в
PE> текстовом представлении, который будет прятать все, что не
PE> относится к математике.

Modelica?

Regards,
011.

Winamp 5.0 (playing): Kylie Minogue — Celebration (remix)
Posted via RSDN NNTP Server 1.8 beta
Re[7]: Вопрос слегка не в тему
От: Аноним  
Дата: 19.04.04 18:02
Оценка: 3 (1)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, <Аноним>, Вы писали:


А>>Так C++, за исключением шаблонов, более ограниченный язык.

ВВ>C++-то как раз куда менее ограниченный чем C#.
Мы про язык? Тогда считаем:
1. Атрибуты.
2. Сборщик муссора.
3. Отражения.
4. foreach
5. Мощный строковый тип
6. Многомерные массивы, массивы массивов
7. Делегаты, цепочки делегатов.
8. События.
9. SEH.
10. Параметризованные/непараметризованные свойства + наследование свойств.
11. Тип 128-битный тип decimal

Еще раз: речь про язык.

ВВ>Зато вот Win32 куда более ограниченная платформа чем .NET

Да-да, крокодил больше длинный, чем зеленый... Проходили.
Re[31]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.03.04 11:25
Оценка: 1 (1)
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Здравствуйте, VladD2...

С вашего позволения:

Routine Name                                         Time           Time with Children  Shared Time          Hit Count

DatasetStorageEngine::Load                           0.00665421125  18.7413820525       0.0355054458169608      36
ProductLibraryManager::LoadProdLibWorker             0              17.78354583875      0                        1
ProductLibDataSetPersist::DsLoad                     0.00084167625  16.797909685        0.00501060111515893      1
DataSetLoader::Load                                  0.00016143625  16.3967278325       0.000984563820593623     1
TabInfo::Load                                        1.44434606875  16.38647400125      8.81425783630952        77
<Garbage Collector>                                 11.63491199375  11.63491199375    100                      308
<JIT Compiler>                                      11.48328216     11.485244375       99.9829153395789      13864
ZipStorageEngine::Load                               3.43084997875   8.962737435       38.2790414606182      5
PersistManager::Load                                 6.76625E-6      8.9577977525       7.55347484610448E-5  4
PropInfo::Load                                       1.00993600125   8.8353232525      11.430662720396       59387
DocumentManager::GetNetworkObject                    3.855E-6        8.7928121725       4.38426287787282E-5  2
ValidatableEventSource::SetValidatableProperty       0.32878773      7.88257587         4.1710696531488      43581
EventSourceObject::GetPropertyDescriptionInternal    0.10383751375   7.5208579025       1.3806604924085      87539
EventSourceObject::BuildPropertyDescriptionMap       6.34245147625   7.469254285       84.9141190572012      15229
EventSourceObject::GetPropertyDescriptionMapInternal 0.0282405075    7.4341745525       0.379874151468547    88041
IndexableNamedObject::set_Name                       0.1251015475    7.386138655        1.69373407870313     12125
EventSourceObject::GetPropertyDescription            0.0155469175    6.36041299         0.244432516008681    62998
AppController::RunWizard                             0.00045296125   6.18196760125      0.00732713723553664      1
ScriptManager::ExecuteFile                           0.00122776      6.17574920875      0.0198803409675456       1
ScriptManager::ExecuteString                         3.77125E-5      6.16964905875      0.00061125843043722      1
SAXEngine::VPI.NC.Scripting.IScriptEngine.Execute    1.365692915     6.1415065075      22.2370995346535          1
DocumentManager::SaveDocument                        6.206E-5        5.70805727375      0.00108723506131235      1
DocumentManager::Save                                0.00057522625   5.69897192         0.0100935091113767       1
ZipStorageEngine::Store                              2.32114413375   4.8816617725      47.548237504404           6
PersistManager::Store                                3.919625E-5     4.881230335        0.00080299939379935      4
DocumentManager::OpenDocument                        0.05199691375   3.13453559625      1.65883947249495         1
DocumentManager::OpenDoc                             0.00052821      2.9891938675       0.017670650463423        1
BaseCollection::.ctor                                0.000103765     2.0311321375       0.00510872720116172   7892
ReadOnlyBaseCollection::.ctor                        0.011396135     2.027203835        0.56216029208528      7892
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: C++ versus C#
От: c-smile Канада http://terrainformatica.com
Дата: 19.02.04 18:13
Оценка: :)
Здравствуйте, alexkro, Вы писали:

A>Здравствуйте, c-smile, Вы писали:


A>А std::wstring не проверял? Кстати, компилятор надо бы поновее взять. Еще вопрос: этот примерчик можно заоптимизировать до смерти, но какой в том смысл?


std::wstring как и String в С# — immutable classes — не предназначены для динамического склеивания строк.

Собственно оптимизирования никакого не проводилось. Такая задача не стояла.
Наоборот — работать только штатными стандартными средствами платформы.

wchar_t_buffer — исп. классичекую имплементацию динамического буфера в C++.
Это не делалось через std::vector, например, по причине наличия разных альтернативных имплементаций std::
Re[2]: C++ versus C#
От: IT Россия linq2db.com
Дата: 20.02.04 01:16
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>но намного больше на работу конечного приложения влияет правильность выбора алгоритма и грамотность реализации этого алгоритма.

VD>Намек ясен?

Говорил бы уж сразу — от радиуса кривизны
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Вопрос слегка не в тему
От: voxel3d  
Дата: 25.02.04 11:44
Оценка: +1
Здравствуйте, Аноним, Вы писали:

А>Ясно) Интересно, что у тебя за проект, и почему его решили на шарпе писать?)


Много всяких. От всякого бухгалтерского дерьма, систем обработки заказов, до оптимизаций грузоперевозок. Шарп используется, потому что на нём удобно проектировать сложные проекты. Я понимаю, что проектирование и язык программирования суть разные вещи, я имею ввиду в шарпе удобно спроектированные конструкции воплощать. Эвенты, делегаты, сборщик мусора, аттрибуты, большая библиотека классов и ограниченность языка по сравнению с С++ -- всё это делает проект дешевле. С другой стороны, меня тошнит уже. Но бизнес есть бизнес.

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 на шарпе писать, в принципе, неплохой выбор.

А>У меня вроде что-то многуровневое и распределенное, наверно для этого и предполагается все это пользовать.


Ну, к ремотингу в дот нете надо ещё дофига всего дописывать -- голая технология в чистом виде сама по себе не нужна бывает.

best regards..
Re[9]: C++ versus C#
От: _MarlboroMan_ Россия  
Дата: 25.02.04 13:40
Оценка: :)
Здравствуйте, naje, Вы писали:

N>это я и у микрософта читал только реальных подтверждений этому не видел


"суслика видишь? нет? а он есть!" (с)
... << RSDN@Home 1.1.3 beta 1 >>

— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Re[11]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 25.02.04 21:17
Оценка: +1
Здравствуйте, naje, Вы писали:

N>Я хотел в качестве примера не проект (которых и на С++ достаточно), а особенность,

N>которая сокращает сроки разработки
автоматическое управление памятью решает очень большую часть проблем
N>и повышает читабельность.
отсутствие ужасного разделения между декларацией и дефиницией, которое заставляет при чтении непрерывно прыгать между .cpp и .h

Это не все. Но уже достаточно чтобы понять, откуда и куда дует ветер.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 15:43
Оценка: -1
Здравствуйте, Kluev, Вы писали:

K>Не так часто нужен маршаллинг, а когда нужен то ИМХО что-то типа MIDL в самый раз.


Правильно. Как бы раком не стоять, лиш бы нового не изучать.

K> Зачем собирать мусор со всего света и тащить его в язык?. Лучше узкоспециализированные веши порешать специальными заточенными тулзами. Тады все будет ОК. И свобода выбора останется. Вдруг понадобятся тебе специализированные метаданные и упресся ты в то, что намертво в НЕТ зашито, тады сразу вспомнишь старые добрые плюсы.


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

K>В С++ тоже можно генерить код на лету. Таскай с собой бесплатный Ц-компилер. генери Ц-код, собирай в DLL грузи и выгружай. И не капассируй нам мозги про генерацию кода.


Ты пробовал? Скорость компиляции плюсов просто никакая. Ждать окончания компиляции скрипта по минуте... А тот же эмит работате молниеносно. Да и компиляторы Шарпа/ВБ летают.

K>Сложность где?


— Вот у нас на предприятии говорят что воздух грязный... А мы по многу лет работем и ничего не замечаем, ничего не замечам, ничего не замечам, ничего не замечам, ничего не замечам...
(с)

... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 16:10
Оценка: +1
Здравствуйте, naje, Вы писали:

Да, мужик. У тебя еще и с юмором плохо.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 16:10
Оценка: +1
Здравствуйте, naje, Вы писали:

N>я имел ввиду как описывается в пресрелизах микрософт


В пресрелизах МС дотнет — это средство создания вэб-сервисов. Их вообще читать не стоит.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Вопрос слегка не в тему
От: Sergey Россия  
Дата: 26.02.04 16:36
Оценка: :)
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 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[8]: Вопрос слегка не в тему
От: naje  
Дата: 26.02.04 16:49
Оценка: :)
Здравствуйте, VladD2, Вы писали:

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

VD>>>Хотел было что-то ответить, но умер со смежу. В общем, 5 балов... Я плякаль...


N>>лично мне твоё психическое состояние знать совсем не интересно, это помоему форум не по той теме форум


VD>Я как бы не тебе отвечал.


странно
Re[24]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.02.04 08:29
Оценка: +1
Здравствуйте, Sinclair, Вы писали:


K>>В С++ вообще все user-defined. Конечно метаданные как в НЕТ не сделаешь, но ИМХО и потребности нет.

S>Вот-вот. То же самое сорок лет назад говорили ассемблерщики про C.

Разное время, разные задачи, разные требования. Ассемлер был востребован именно для задач своего времени. Всякие плюсы и остальное гемор были действительно не особо нужны.

S>>>Ну щас прям. И сразу получи платформенную зависимость. Как минимум. А также необходимость таскать с собой запас хидеров для того, чтобы генеренный код мог взаимодействовать с другим кодом. В общем, ребята, солюшн с Ц-компилером даже на шутку не тянет. Потому его и не применяет никто и никогда. В отличие от той самой генерации кода в .Net.


Солюшн с цекомпилером — вындоуз и линукс например. Думаю что линукс более патформонезависимый, нежели дотнет. На скольки патформах доступен дотнет ?
Слишком большой CLR, что бы его портировать. За то время, пока Билл портировал CLR для БСД, линуксоилы освоили парочку платформ.

S>Короче, я никого не заставляю. .Net предлагает способ дешево делать хорошие программы. Альтернативы ему есть — та же Java.


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

Вот когда появится Офис полностью менеджед или другой тул поольше, тогда модно будет сравнить быстродействие. На нашем проекте дотнет очень сильно проигрывает в этом плане.
Зато не нем дешевле и проще.
Re[22]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.02.04 08:41
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

N>>я спрашивал что нового в .Net, как вобще можно сравнивать язык с фреймворком?

S>Как хочешь — так и сравнивай. С++ тоже не только язык. Без стандартной библиотеки и рантайма он мертв.

Ты еще скажи, что С++ без компилера мертв. С++ нужно всего ничего — компилер, линкер и... все ! Есть АПИ — юзай его. Это только кажется, что мало что можно сделать.
На самом деле это очень много. В этом плане для дотнета нужно очень много.

S>Да нет проблем. Просто в C# делается все, что делается в .Net. В С++ этого нет. В нем нет делегатов, нет автоматического управления памятью, нет гарантий, что везде, где можно написать a<b можно написать и b>a, нет Reflection, нет модели безопасности, нет встроенной поддержки компонентности.


Делегатов нет — это точно. Автоматическое управление памятью не всегда то и нужно.
В с++ память кушается меньше и больше юзается стек. Моей тачки — 800мгц+512MB вполне хватает для всех плюсовых задач. А вот для дотнета очень слабо. Профайлер работает ой как долго.
Все от того, что памяти кушается слишком много.
Re[22]: C++ versus C#
От: Kluev  
Дата: 27.02.04 10:36
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Может я чего не знаю, но что-то я не вижу способа просто и изящно передать параметры маршалинга в С++ библиотеку в непроцедурном стиле. Как ты объяснишь, что вот этот параметр надо маршалить по ссылке, а этот — по значению?


Обьяснишь легко. С помошью шаблонов:
template <class T>
struct arg_info {
     enum { marshal_type = value };
};

template <class T>
struct arg_info<T&> {
     enum { marshal_type = ref };
};

template <class T>
struct arg_info<T*> {
     enum { marshal_type = ptr };
};
// намек понятен?


Только как я уже говорил иногда выгоднее использовать внешние описания и кодогенераторы. А аля маршаллинга лучше что-нить типа IDL

S>Да. Внутри там то же самое что и в других системах. Это не серебряная пуля, это просто способ повысить производительность и качество труда программистов.


Отдельно взятой категории программистов. Мою производительность он никак не способен повысить, задачи совсем другие.

S>Да нет проблем. Просто в C# делается все, что делается в .Net. В С++ этого нет. В нем нет делегатов, нет автоматического управления памятью, нет гарантий, что везде, где можно написать a<b можно написать и b>a, нет Reflection, нет модели безопасности, нет встроенной поддержки компонентности.


Автоматическое управление памятью — это фатальный недостаток НЕТ. Программы которые манипулируют одновременно около 100000 обьектами связанными в сеть, писать на НЕТ просто нет смысла.
А все осталное в свете этого — это как висит груша нельзя скушать. Возможности есть но из-за обших недостатков их не заюзаешь. Когда у вас пройдет эйфория поймете что у НЕТ есть свой скромный уголок, такой же как и у всех языков. Страуструп, вообще, всегда говорил что С++ — это язык номер 2.

S>Да, все это можно эмулировать. Впрочем, наследование тоже можно эмулировать на С. Проблема в том, что в рамках С++ нельзя научить компилятор валидировать введенные пользователем правила. И из-за отсутствия рефлексии нельзя это сделать и в рантайме. Поэтому у Versant есть свой препроцессор, который проверяет persistent классы на целостность и генерирует метаданные. Но это фактически другой язык. В C# работу, выполняемую этим препроцессором, можно делать в рамках языка. См. Rsdn.Framework.Data. Почему-то никто не написал подобного для С++!


Это я не восвсем понял? О каких правилах речь?
Re[25]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.04 00:22
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

AVK>Не, в 1.2 вроде бы МС++ можно для страничек пользовать.


МС++ можно было использовать для АСП еще в весрии 1.0 (раком правда, но все же). Но это МС++. На на обычном так вот просто хрена с два выйдет. Будут все те же проблемы С++.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: C++ versus C#
От: Шахтер Интернет  
Дата: 28.02.04 03:09
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


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


VD>Рассказы о приемуществах С++ в скорости сильно приувеличены. А со временем этих приемуществ вообще не будет. Если сравнить скорость VC и дотнета (C#) вресий 7.0, 7.1, 8.0, то невооруженным взглядом видно, что разрыв потихоничку сокращается. Да и не так он велик. Без проблем в алгоритмах масимальный проигрыш в 2 раза. Если же учесть простоту и скорость разработки на дотнете, то становится понятно, что проще экономить время и тратить деньги на железо. Ну, а если учесть, что аысвободившееся время можно потратить на оптимизацию алгоритмов...


Например, на алгоритм сортировки. Или на алгоритм сложения 2 и 2.
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[24]: C++ versus C#
От: naje  
Дата: 28.02.04 12:56
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


K>>Обьяснишь легко. С помошью шаблонов:

K>>
K>>template <class T>
K>>struct arg_info {
K>>     enum { marshal_type = value };
K>>};

K>>template <class T>
K>>struct arg_info<T&> {
K>>     enum { marshal_type = ref };
K>>};

K>>template <class T>
K>>struct arg_info<T*> {
K>>     enum { marshal_type = ptr };
K>>};
K>>// намек понятен?
K>>


VD>Ты не пытался сравнить это с декларацией на Шарпе?


помоему это не декларация
это намёк, написали же тебе
Re[28]: C++ versus C#
От: Kluev  
Дата: 01.03.04 10:22
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


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


Гы. плюсы тоже не стоят на месте. У плюсов нет единой библиотеки на разные случаи жизни. Все приходится по миру собирать. Это основная трудность. Было-бы что-нибудь типа QT нахаляву, тогда народ с плюсов выманить было-бы невозможно. А если появится многие вернутся обратно.

VD>Рассказы о приемуществах С++ в скорости сильно приувеличены. А со временем этих приемуществ вообще не будет.


Будут всегда. Сборка мусора всегда будет тянуть НЕТ на дно. От этого никуда не деться. Может далеть UI на НЕТ-е и просто, но работать со сложными структурами я бы на нем не стал.

VD>Если сравнить скорость VC и дотнета (C#) вресий 7.0, 7.1, 8.0, то невооруженным взглядом видно, что разрыв потихоничку сокращается. Да и не так он велик.


Смотря на чем сравнивать.

VD>Без проблем в алгоритмах масимальный проигрыш в 2 раза. Если же учесть простоту и скорость разработки на дотнете, то становится понятно, что проще экономить время и тратить деньги на железо. Ну, а если учесть, что аысвободившееся время можно потратить на оптимизацию алгоритмов...


Алгоритмы уже проблема. Возьми любую нетривиальную задачу — триангуляция поверхности, разбиение обьема и т.п. То что такие вещи неудобно делать с автоматической сборкой мусора, в языке без адрессной арифметики (или с образаной арифметикой), и без возможностей прочего хака ясно как дважды два четыре.
Re[30]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.03.04 11:22
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>>>Рассказы о приемуществах С++ в скорости сильно приувеличены. А со временем этих приемуществ вообще не будет.


K>>Будут всегда.


VD>Ошибаещся.


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


K>> Сборка мусора всегда будет тянуть НЕТ на дно.


VD>А это ничего, что ЖЦ в Яве работает не медленнее чем стандартные хипы С++?

А это ничего, что аппликухе на нативном с++ хватает памяти, а дотнету — нет ?

K>> От этого никуда не деться.

VD>Ты алгоритм ЖЦ знаешь? Что в нем может потенциально быть проблемным?

Он слишком долго отслеживает ссылки, если их слишком много.

K>> Может далеть UI на НЕТ-е и просто, но работать со сложными структурами я бы на нем не стал.

VD>Что есть сложные структуры?

Модель сети например. Любая наукоемкая задача использует очень сложные стурктуры.


K>>Алгоритмы уже проблема. Возьми любую нетривиальную задачу — триангуляция поверхности, разбиение обьема и т.п.


VD>Ну, эти задачи уже давно в акселераторы зашиты. Но все равно потенциально проблем с их рассчетом на менеджед-языках нет.


В какие акселераторы ? Туда зашивают только то, что хорошо разжевано, канонизировано и стандартизировано. Окромя этого есть много алгоритмо оработки изображений. Распознавание например. А с оработкой звука как ? Реалиизуй алгоритм смены голоса диктора на шарпе (двумя способами — со словарем и без оного) , будем посмотреть.
Re[32]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.03.04 17:32
Оценка: +1
Здравствуйте, VladD2, Вы писали:

PE>>Вот интересно, зачем же тогда половина стринга написана на нативном С++?


VD>Хороший вопрос. Особенно елси учесть тот факт, что этот код проигрывает аналогичному написанному на Шарпе.


А где это можно посмотреть ?

VD>Все требовательные к производительности фукнции стрингбилдера реализованы прямо в нем. Импортируются как раз не столь важные.


Копирование строки — нативная функция.

VD>Да на Шарпе все же по более будет. И самые медленные реализации как раз на С++ сделаны. Правда это не означает, что С++ никуда не годится. Просто на С++ обычно реализуются универсальные вещи, а они в принципе обычно тормозны.


Это точно. А ассемлерные программы всегда тормозные в принципе.

VD>Где? Вот у нас на сервере мс-сиквел и АСП.НЭТ. Так сиквелу памяти нехватает, а АСП вроде не кашляет.


А что, окромя сиквела и АСП нет других применений ?

PE>>Он слишком долго отслеживает ссылки, если их слишком много.


VD>Слишком много это сколько? Миллион отслеживает почти молниеносно. Да и делается это не постоянно.


Почти — растяжимое поняте. Минимум 8 секунд при 20000 референсов.

PE>>Модель сети например. Любая наукоемкая задача использует очень сложные стурктуры.


VD>Т.е. граф? Нда, куда уж сложнее. Нормально он будет с ней работать. Памяти возможно сожрет больше, но если ее хватает, то будет очень даже прилично работать.


Ой-ой. Мы год назад начали писать, сейчас первый релиз был. Это не просто граф. Это гиперграф.
Граф состоящий из графов. Всего различных объектов около 600. Вот они то и реализуют весь гиперграф.

PE>> Реалиизуй алгоритм смены голоса диктора на шарпе (двумя способами — со словарем и без оного) , будем посмотреть.


VD>Это давно решенные задачи. Если конечно велосипед не изобретать. Ну, и главно ошеломляюще быстрее на С++ их один фиг не решить. Ну попробуй хоятбы не медленнее и без нативных фичек.


Давно — это конечно. Осоенно если учесть, что это самая актуальная тема для диссеров.
Re[35]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.03.04 12:16
Оценка: -1
Здравствуйте, Plutonia Experiment, Вы писали:

PE>На данный момент у нас 12 мегов шарпового кода. Минус комментарии, заголовки получтся 8.


Заголовки в шарповом коде это что то интересное.

PE>А вот как ускорит создани делегатов неизвестно.


Почему? Заменить их на интерфейсы.

PE>Колбек интерфейсы влекут массу геморроя за собой.


Например?
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[17]: C++ versus C#
От: naje  
Дата: 03.03.04 13:43
Оценка: :)
Здравствуйте, Plutonia Experiment, Вы писали:

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


AVK>>Рынок только у твоих знакомых ну очень маленький.

PE>>>А на ноутуке твоем много железа с аппаратным преоразованием того же фурье ?

AVK>>Нет. А нафига оно мне?


PE>Запусти SoundForge или VCS Diamond и убедись, что весь звук обрабатывается программно.


PE>Обраотка звука — это не спецэффекты, которые в курточку засунуть можно. Это математика


профессиональное создание музыки это не SoundForge или VCS Diamond, там как-раз много чего апаратного (как впринципе и профессиональное слушанье )
Re[40]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 16:43
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

AVK>Все это правильно, вот только что то мне кажется что меньше всего меня волнует скорость работы на шарпе алгоритма сжатия в mp3 или ogg. Потому как это мизерный процент решаемых с его помощью задач.


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

Процент мизерный, а используется повсеместно. Даже на твоем крутом ноутбуке весом в 2.8 кг.

PE>>Кстати, а рары, зипы, тары — тоже аппаратно жмут ?


AVK>Ты часто рары и зипы пишешь? Я нет.


С помощью раров и зипов меряется реальный перформанс процессоров.

Со временем конечно начнут писать ужималки, математику, моделирование, игры и тд и тд на дотнете полным ходом. Но не потому, что перформанс выше. Потому, что дешевле. Как только PI-PII-PIII устареют на столько, что самы распространенным процом будет PIV, тогда и рванет дотнет в небо. Ну и на 64битах конечно. Портировать на 64 бита гораздо проще дотнет и прилы под него, чем несколько миллионов прилаг.
Re[62]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.03.04 09:15
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

PE>>Почему бы тебе на XML и программы тогда не писать?

AVK>Потому что программы содержат в основном императивные инструкции.

Вот в чем дело. Взаимодействие объектов придется частично на этом же языке описывать.

PE>>Очень неплохо подходит.


AVK>Это тебе кажется удобнее, потому что ты на плюсах пишешь. Только ты то жаловался на то что те кто это должен писать — непрограммисты. А для них куда как проще декларативный стиль задания.


Проще, но не XML. XML сгодится в качестве промежуточного. Генератор должен XML примнимать, а вот человеку с XML работать не нужно. Слишком много текста и структура плохая.


AVK>Вот смотрел, потому и говорю. WSDL удобнее, более масштабируемо и мощнее.


Ничего тут не удобнее. Если один раз написать и забыть, то можно и XML,WSDL и все, что хочешь юзать.
А если ты постоянно будешь работать с языком, то XML тут не помощник.
Re[72]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.03.04 15:35
Оценка: +1
Здравствуйте, AndrewVK, Вы писали:

PE>>Языки всякие например.


AVK>Я же тебе сказал — любая технология хороша в своей области. И не везде императивные языки лучше. Например для кодогенератора XSLT шаблон обычно значительно лаконичнее программы на том же шарпе или джаве.


Шаблон генерации в HTML очень похож на этот самый HTML. А если захочешь гнать XML в С#, то шаблон будет очень похож на C#.

PE>> их порядок,


AVK>Это вобще не нужно. Если у тебя что то зависит от порядка атрибутов то это очень криво.


Для XML нужны схемы данных. Это там порядок указывается и регистр.


AVK>Поэтому понять первый вариант не программисту заметно проще. А если еще к нему xsd написать и воспользоваться специализированным редактором, то редактировать данные в гриде сможет совсем уж далекий от программирования человек. Для второго же варианта нужно быть программистом, причем на С-like языке.


В том то и дело. Непрограммисты меня не интересуют вовсе. Наши индейцы(практически все) умеют писать кое что на C++, C# и Яве. Некоторые особо опасные индейцы даже питоном владеют(им так кажется).

В одном случае придется писать редактор, во втором — просто перегонять в XML, с которым и будет работать генератор. Но человеку XML не нужно знать.
Re[77]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.03.04 08:24
Оценка: -1
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>А в чем проблема?


PE>Собственно в валидации.


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

PE>>>Вот и я про то. Надо помнить все подряд. А свой язык можно упростить очень сильно.


AVK>>Сильнее XML вряд ли получится


PE>Я уже говорил, что XML это примитивный язык. Простота — это немного другое.


Это все игра словами и ничего более.

AVK>>А, ну ну. Значит схему написать это жутко долго, а вот отпарсить язык плевое дело.


PE>Нет. Схему еще проще.


Причем намного. О том и речь.

PE> Для редактирования XML придется свой редактор писать. Вот я про что.


А для своего языка типа не надо? Впрочем меня пока XmlSpy устраивал по большей части.

AVK>>То что они делают только для учебных целей и годится. А на практике чтобы получить production quality парсер даже несложного языка надо изрядно попахать. Вот тот же XML, казалось бы там парсер можно за полдня на коленке написать, а на практике даже для такого парсера придется попахать от души.


PE>На практике пахать не нужно. Можно брать готовое.


А готовое и есть XML.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[11]: Вопрос слегка не в тему
От: kuj  
Дата: 20.04.04 17:30
Оценка: :)
Здравствуйте, Воронков Василий, Вы писали:

kuj>>Открываете спецификацию C# и убеждаетесь в его правоте. Все (кроме, разве что, отражений) вышеперечисленные понятия имеют непосредственное отношение к языку C#.


ВВ>При этом все это реализовано на уровне библиотек.

Свойства, атрибуты, отражения? Можно узнать урлы библиотек, реализующих это?
Да, а еще хотелось бы урл на полноценный эфемерный сборщик муссора с дефрагментацией кучи, масштабируемый на многопроцессорной системе и отдельной кучей для больших объектов. Можно? Буду очень признателен!
... << RSDN@Home 1.1.3 stable >>
Re[17]: Вопрос слегка не в тему
От: kuj  
Дата: 20.04.04 19:22
Оценка: +1
Здравствуйте, Воронков Василий, Вы писали:

kuj>>Так C++, за исключением шаблонов, более ограниченный язык.


ВВ>В ответ на что я написал, что это C# более ограниченный язык. А фичи C#, о которых вы говорите, являются фичам платформы .NET, и к языку имеют весьма опосредованное отношение.

На что я ответил, что они являются также и фичами языков, которые относятся к этой платформе и предложил Вам заглянуть в спецификацию C#.
... << RSDN@Home 1.1.3 stable >>
Re[18]: Вопрос слегка не в тему
От: Воронков Василий Россия  
Дата: 20.04.04 19:34
Оценка: +1
Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, Воронков Василий, Вы писали:


kuj>>>Так C++, за исключением шаблонов, более ограниченный язык.


ВВ>>В ответ на что я написал, что это C# более ограниченный язык. А фичи C#, о которых вы говорите, являются фичам платформы .NET, и к языку имеют весьма опосредованное отношение.

kuj>На что я ответил, что они являются также и фичами языков, которые относятся к этой платформе и предложил Вам заглянуть в спецификацию C#.

Понятно. А вот это здесь
Автор: kuj
Дата: 20.04.04
сообщение ты написал видно под принуждением.
... << RSDN@Home 1.1.3 stable >>
Re[17]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.04.04 03:40
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

S>4. Василий отвечает ему, что в C# этих фич тоже нет.


Sinclair, а ты сам то давно читал спецификацию Шарпа? Как можно говорить, что чего-то нет в языке если это его часть?

S>5. Ты начинаешь ссылаться на спецификации С#


И правильно делает.

S>6. Василий намекает, что почти все из упомянутого, реализуется не C#, а библиотеками.


Да? Какой библиотечной функцией содается массив в Шареп? А какой определяется его длинна?

А как с помощью библиотеки в Шарпе определить делегат?

А в какой библиотеке лежит foreach? Ведь он зачастую разворачивается в аналог for.

S>7. Ты требуешь их предъявить.

S>Ну вот я и предъявил. А теперь ты начинаешь делать вид, что говорил про библиотеки для С++. Не было такого.

Ну, задействуй их и попробуй получить в анменеджед-С++ все эти фичи.

И ответь, чем это все опровергает его слова о том, что Шарп более богатый язык?

Если считать по количеству фич, то это факт. Другое дело, что фичи вроде Шаблонов и МН могут многое перевесить.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
C++ versus C#
От: c-smile Канада http://terrainformatica.com
Дата: 18.02.04 19:26
Оценка:
Навеяно спорами с VladD2 (http://www.rsdn.ru/Forum/Message.aspx?mid=538145&amp;only=1
Автор:
Дата: 13.02.04
)
И вербально по месту с iLYA.

Два примера С# и С++ делающие следюущее:

for (int i=0; i<N; i++) 
{
  if((i & 1) == 0)
     StringBuffer1.Append("hello");
  else
     StringBuffer2.Append("hello!");
}


Результаты для 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++
#include <time.h>
#include <stdlib.h>

namespace aux {

// wchar_t_buffer class - in-memory dynamic buffer.
  class wchar_t_buffer 
  {
    wchar_t*        _body;
    size_t          _allocated;
    size_t          _size;

    wchar_t *reserve(size_t size)
    {
      if((_size + size) > _allocated) 
      {
        // not bad, huh?
        _allocated *= 2;
        wchar_t *newbody = new wchar_t[_allocated];
        memcpy(newbody,_body,_size * sizeof(wchar_t));
        delete[] _body;
        _body = newbody;
      }
      return _body + _size;
    }

  public:

    wchar_t_buffer():_size(0)     { _body = new wchar_t[_allocated = 256]; }
    ~wchar_t_buffer()             { delete[] _body;  }

    const wchar_t * data()  {  
             if(_size == _allocated) reserve(1); 
             _body[_size] = 0; return _body; }

    size_t length() const         { return _size; }

    void push(wchar_t c)    { *reserve(1) = c; ++_size; }
    void push(const wchar_t *pc, size_t sz) 
    { 
      memcpy(reserve(sz),pc,sz*sizeof(wchar_t)); 
      _size += sz; 
    }
  };
}

int  main() 
{
    double elapsedTime;
    clock_t stopTime;
    clock_t startTime = clock();

    int i;
  aux::wchar_t_buffer buf1;
  aux::wchar_t_buffer buf2;
    
    for (i=0; i < 10000000; i++ )
    {
    if((i & 1) == 0)
      buf1.push(L"hello",5);
    else
      buf2.push(L"hello!",6);
    }
    stopTime = clock();
    elapsedTime = (stopTime - startTime) /  (CLOCKS_PER_SEC / (double) 1000.0);
    printf("String Concat. Elapsed time: %1.0f\n", elapsedTime);//, strbuf);

  return 0;
}


C++ — VC++ 6.0
Re: C++ versus C#
От: DMach Россия http://www.1Gb.ru
Дата: 19.02.04 08:28
Оценка:
Здравствуйте, 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
... << RSDN@Home 1.1.2 beta 2 >>
Re: C++ versus C#
От: alexkro  
Дата: 19.02.04 08:39
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Навеяно спорами с VladD2 (http://www.rsdn.ru/Forum/Message.aspx?mid=538145&amp;only=1
Автор:
Дата: 13.02.04
)

CS>И вербально по месту с iLYA.

CS>Два примера С# и С++ делающие следюущее:

...

А std::wstring не проверял? Кстати, компилятор надо бы поновее взять. Еще вопрос: этот примерчик можно заоптимизировать до смерти, но какой в том смысл?
Re[2]: C++ versus C#
От: c-smile Канада http://terrainformatica.com
Дата: 19.02.04 18:53
Оценка:
Здравствуйте, DMach, Вы писали:


DM>
DM>            StringBuilder sb1 = new StringBuilder(50000000);
DM>            StringBuilder sb2 = new StringBuilder(50000000);
DM>


Результаты для 10млн итераций c полностью преаллоцированным буфером

c#
StringBuilder sb1 = new StringBuilder(50000000);
StringBuilder sb2 = new StringBuilder(60000000);


c++

int i;
aux::wchar_t_buffer buf1(50000000);
aux::wchar_t_buffer buf2(60000000);
    
for (i=0; i < 10000000; i++ )
{
  if((i & 1) == 0)
    buf1.push(L"hello",5);
  else
    buf2.push(L"hello!",6);
}


(тест на машине Pentium III, 850мгц):

CS>>С++ - 590 ms (+/- 0)

CS>>С#1205 ms (+/- 5)

Эти результаты в общем и целом согласуются с результатами Константина Книжнижника на его реальных
имплементациях СУБД: http://www.garret.ru/~knizhnik/dybase/doc/dybase.html#comparison

Хочу еще раз подчеркнуть что данное исследование не ставит целью ответить на глупый вопрос типа "кто лучше — папа или мама?"
А просто понять какие классы задач луше делать на каждой из платформ.
Re[3]: C++ versus C#
От: Undying Россия  
Дата: 19.02.04 22:04
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>>>С++ - 590 ms (+/- 0)

CS>>>С#1205 ms (+/- 5)

CS>Хочу еще раз подчеркнуть что данное исследование не ставит целью ответить на глупый вопрос типа "кто лучше — папа или мама?"

CS>А просто понять какие классы задач луше делать на каждой из платформ.

Ты считаешь, что различия в быстродействии в 1.5 — 2 раза критично для значительного числа задач?
... << RSDN@Home 1.1 beta 2 >>
Re[2]: C++ versus C#
От: c-smile Канада http://terrainformatica.com
Дата: 20.02.04 02:14
Оценка:
Здравствуйте, 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 purposes

            if (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);
        }



"Намек ясен? "
Re[3]: C++ versus C#
От: alexkro  
Дата: 20.02.04 04:31
Оценка:
Здравствуйте, c-smile, Вы писали:

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


A>>Здравствуйте, c-smile, Вы писали:


A>>А std::wstring не проверял? Кстати, компилятор надо бы поновее взять. Еще вопрос: этот примерчик можно заоптимизировать до смерти, но какой в том смысл?


CS>std::wstring как и String в С# — immutable classes — не предназначены для динамического склеивания строк.


Кто тебе сказал, что wstring is immutable? Ссылочку на стандарт пожалуйте.

CS>Собственно оптимизирования никакого не проводилось. Такая задача не стояла.

CS>Наоборот — работать только штатными стандартными средствами платформы.

Зачем тогда свой наворот на C++ писать? Штатное стандартное средство C++ — wstring.
Re[3]: C++ versus C#
От: naje  
Дата: 20.02.04 07:40
Оценка:
Здравствуйте, IT, Вы писали:

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


VD>>но намного больше на работу конечного приложения влияет правильность выбора алгоритма и грамотность реализации этого алгоритма.

VD>>Намек ясен?

IT>Говорил бы уж сразу — от радиуса кривизны


Т.б. у Книжника этот радиус большой?
Re[3]: C++ versus C#
От: alexkro  
Дата: 20.02.04 10:49
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>StringBuilder же это то что называется динамический буфер оптимизированный в первую очередь для append.

CS>Использовать для этой цели CString/String/std::string — это даже не "средний программист", это хуже.

CStringT конечно-же sucks для этой цели, если посмотреть на реализацию. Но вот насчет std::string ты ошибся.

CS>Или ты хочешь сказать что C# только для средних программистов?


Я почти уверен, что и C# версию можно достаточно соптимизировать. Кстати, вопрос на засыпку: чем определяется предел оптимизации для данного примерчика?
Re: C++ versus C#
От: alexkro  
Дата: 20.02.04 10:51
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>При этом GC в С# тестах не срабатывал. А в С++ в это время срабатывал лишний delete.


... который здесь никакой роли не играет .
Re[3]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.02.04 14:00
Оценка:
Здравствуйте, 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.02.04 14:00
Оценка:
Здравствуйте, alexkro, Вы писали:

CS>>Собственно оптимизирования никакого не проводилось. Такая задача не стояла.

CS>>Наоборот — работать только штатными стандартными средствами платформы.

A>Зачем тогда свой наворот на C++ писать? Штатное стандартное средство C++ — .


Изменил в этотм тесте класс на wstring. Результат получился 1478. Против 1520 у C#.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: C++ versus C#
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 20.02.04 14:07
Оценка:
Здравствуйте, c-smile, Вы писали:

В C# есть проблемы с GC http://www.rsdn.ru/forum/?mid=390648
Автор: Serginio1
Дата: 23.09.03
. Все остальное работает очень быстро особенно с Валуе типами.
По поводу приведенных тестов то они не корректны так как компилятор оптимизирует такие тесты до нельзя, и сравнение с компонентами Net тоже не очень. Например свои аналоги могут работать в 1.5 — 2 раза быстрее на том же C#. Скажем так нетовские компоненты не очень, усреднены, но для массового использования вполне пригодны.
Но никто не учитывает фрагментацию памяти итд.
и солнце б утром не вставало, когда бы не было меня
Re[4]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.02.04 14:39
Оценка:
Здравствуйте, alexkro, Вы писали:

A>Я почти уверен, что и C# версию можно достаточно соптимизировать. Кстати, вопрос на засыпку: чем определяется предел оптимизации для данного примерчика?


Специализацией алгоритма и качеством инлайнинга методов. Остальные оптимизации у Шарпа и VC практически одинаковы.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.02.04 23:04
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Для тех кто в танке повторяю.


Глянь на вот это голосование
Автор: VladD2
Дата: 20.02.04
Вопрос: Какие классы или функции вы используете для конкатинации строк в своих программах на С++? (не С++-ников просьба не голосовать).
. Ну, а тепрь можно обсудить кто из нас в танке и что эффективнее:
std::string s3 = s2 + s1;


Или StringBuilder.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Вопрос слегка не в тему
От: Аноним  
Дата: 24.02.04 10:47
Оценка:
Если есть люди, которые долго писали на плюсах, а потом срочно перешли только на шарп.
Какие были впечатления? Не хочется ли обратно?)
Мне вот сейчас как раз это предстоит.
Re[4]: C++ versus C#
От: achp  
Дата: 24.02.04 10:58
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Глянь на вот это голосование
Автор: VladD2
Дата: 20.02.04
Вопрос: Какие классы или функции вы используете для конкатинации строк в своих программах на С++? (не С++-ников просьба не голосовать).
.


А чем оно показательно?
Re[5]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.02.04 18:11
Оценка:
Здравствуйте, achp, Вы писали:

VD>>Глянь на вот это голосование
Автор: VladD2
Дата: 20.02.04
Вопрос: Какие классы или функции вы используете для конкатинации строк в своих программах на С++? (не С++-ников просьба не голосовать).
.


A>А чем оно показательно?


Тем что основной процент респондентов использует самые не эффектиные операции для конкатинации строк. Так что средняя программа на С++ с очень большой вероятностью окажетсая медленнее чем аналогичная на Шарпе. И все рассуждения об качестве оптимизации и ЖЦ идут лесом.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.02.04 18:11
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Если есть люди, которые долго писали на плюсах, а потом срочно перешли только на шарп.

А>Какие были впечатления? Не хочется ли обратно?)
А>Мне вот сейчас как раз это предстоит.

Перейти обратно?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: C++ versus C#
От: Dimentiy Россия  
Дата: 24.02.04 18:22
Оценка:
Здравствуйте, Undying, Вы писали:

U>Ты считаешь, что различия в быстродействии в 1.5 — 2 раза критично для значительного числа задач?


Хотя обращение и не ко мне, но тем не менее.

Речь идёт о _некоторых_ задачах. Так вот в этих _некоторых_ задачах (как html рендеринг) — быстродействие, несомненно, нужно и важно. Офигительно важно.
Re[6]: C++ versus C#
От: naje  
Дата: 25.02.04 08:52
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>Глянь на вот это голосование
Автор: VladD2
Дата: 20.02.04
Вопрос: Какие классы или функции вы используете для конкатинации строк в своих программах на С++? (не С++-ников просьба не голосовать).
.


A>>А чем оно показательно?


VD>Тем что основной процент респондентов использует самые не эффектиные операции для конкатинации строк. Так что средняя программа на С++ с очень большой вероятностью окажетсая медленнее чем аналогичная на Шарпе. И все рассуждения об качестве оптимизации и ЖЦ идут лесом.


Вобще средней программе и не нужна большая производительнгость конкатенации (тем более в приведенном тобой примере std::string s3 = s2 + s1), выигрышь стринг билдера начинается когда конкатенаций много, правильно? (как и в примере)
В этом голосовании я проголосовал за класс string, но насамом деле я голосвал за шаблон basic_string (тогда я думал что ты это подразумевал), так вот, что мне мешает сделать свой трейт и переопределить для него оператор+ так как нужно (типа стринг билдера)? Причём я уверен что таких решений уже немеренно (хотя спорить не буду, у меня таких задач пока не возникало)
Re[2]: Вопрос слегка не в тему
От: voxel3d  
Дата: 25.02.04 09:06
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Если есть люди, которые долго писали на плюсах, а потом срочно перешли только на шарп.

А>Какие были впечатления? Не хочется ли обратно?)
А>Мне вот сейчас как раз это предстоит.

Лично я разумом понимаю, что использование шарпа здорово удешевляет проект.. но, хочу обратно на плюсы.. Что-то тут утеряно что ли Ну, не нравится мне шарп, хотя надо признать вещь весьма достойная. На твой вопрос вряд ли будет объективный ответ.

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. Вот это по-поему изврат.
У меня вроде что-то многуровневое и распределенное, наверно для этого и предполагается все это пользовать.
Re[5]: C++ versus C#
От: Undying Россия  
Дата: 25.02.04 12:08
Оценка:
Здравствуйте, Dimentiy, Вы писали:

U>>Ты считаешь, что различия в быстродействии в 1.5 — 2 раза критично для значительного числа задач?


D>Речь идёт о _некоторых_ задачах. Так вот в этих _некоторых_ задачах (как html рендеринг) — быстродействие, несомненно, нужно и важно. Офигительно важно.


И как часто в жизни встречаются задачи подобные html рендерингу?
Тем более, что скорей всего html рендеринг будет сравнительно небольшой частью общей задачи, т.е. даже, если действительно шарп здесь будет проигрывать в два раза, то рендеринг можно будет написать на MC++ и использовать в качестве библиотеки, т.е. все равно никто не мешает использовать в качестве основного языка.
... << RSDN@Home 1.1.2 stable >>
Re[6]: C++ versus C#
От: naje  
Дата: 25.02.04 12:25
Оценка:
Здравствуйте, Undying, Вы писали:

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


U>>>Ты считаешь, что различия в быстродействии в 1.5 — 2 раза критично для значительного числа задач?


D>>Речь идёт о _некоторых_ задачах. Так вот в этих _некоторых_ задачах (как html рендеринг) — быстродействие, несомненно, нужно и важно. Офигительно важно.


U>И как часто в жизни встречаются задачи подобные html рендерингу?

U>Тем более, что скорей всего html рендеринг будет сравнительно небольшой частью общей задачи, т.е. даже, если действительно шарп здесь будет проигрывать в два раза, то рендеринг можно будет написать на MC++ и использовать в качестве библиотеки, т.е. все равно никто не мешает использовать в качестве основного языка.

что это даст?
почему сразу не полностью на C++?
Re[7]: C++ versus C#
От: Undying Россия  
Дата: 25.02.04 12:52
Оценка:
Здравствуйте, naje, Вы писали:

U>>И как часто в жизни встречаются задачи подобные html рендерингу?

U>>Тем более, что скорей всего html рендеринг будет сравнительно небольшой частью общей задачи, т.е. даже, если действительно шарп здесь будет проигрывать в два раза, то рендеринг можно будет написать на MC++ и использовать в качестве библиотеки, т.е. все равно никто не мешает использовать в качестве основного языка.

N>что это даст?

N>почему сразу не полностью на C++?

Значительно более короткий срок разработки и более читабельный код, даже при более низкой квалификации разработчиков.
... << RSDN@Home 1.1.2 stable >>
Re[8]: C++ versus C#
От: naje  
Дата: 25.02.04 12:54
Оценка:
Здравствуйте, Undying, Вы писали:

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


N>>почему сразу не полностью на C++?


U>Значительно более короткий срок разработки и более читабельный код, даже при более низкой квалификации разработчиков.


это я и у микрософта читал только реальных подтверждений этому не видел
Re[10]: C++ versus C#
От: naje  
Дата: 25.02.04 13:48
Оценка:
Здравствуйте, _MarlboroMan_, Вы писали:

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


N>>это я и у микрософта читал только реальных подтверждений этому не видел


_MM_>"суслика видишь? нет? а он есть!" (с)


Знатоки теологии подключились?
Замечательно.
Re[9]: C++ versus C#
От: Undying Россия  
Дата: 25.02.04 14:04
Оценка:
Здравствуйте, naje, Вы писали:

U>>Значительно более короткий срок разработки и более читабельный код, даже при более низкой квалификации разработчиков.


N>это я и у микрософта читал только реальных подтверждений этому не видел


А Хоум тебе чем не пример? Пишет его туева хуча разработчиков совершенно разной квалификации, контроль над которыми очень слабый, но при этом проект живет и развивается, при чем по крайней мере на моей памяти в нем не было ни одной серьезной ошибки.
... << RSDN@Home 1.1.2 stable >>
Re[10]: C++ versus C#
От: naje  
Дата: 25.02.04 14:11
Оценка:
Здравствуйте, Undying, Вы писали:

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


U>>>Значительно более короткий срок разработки и более читабельный код, даже при более низкой квалификации разработчиков.


N>>это я и у микрософта читал только реальных подтверждений этому не видел


U>А Хоум тебе чем не пример? Пишет его туева хуча разработчиков совершенно разной квалификации, контроль над которыми очень слабый, но при этом проект живет и развивается, при чем по крайней мере на моей памяти в нем не было ни одной серьезной ошибки.


Я хотел в качестве примера не проект (которых и на С++ достаточно), а особенность, которая сокращает сроки разработки и повышает читабельность.
Re[7]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.02.04 20:46
Оценка:
Здравствуйте, naje, Вы писали:

N>Вобще средней программе и не нужна большая производительнгость конкатенации (тем более в приведенном тобой примере std::string s3 = s2 + s1), выигрышь стринг билдера начинается когда конкатенаций много, правильно? (как и в примере)

N>В этом голосовании я проголосовал за класс string, но насамом деле я голосвал за шаблон basic_string (тогда я думал что ты это подразумевал),

Логично, чет побери. Нужно было упоминать о том что конкатинации массовые.

N>так вот, что мне мешает сделать свой трейт и переопределить для него оператор+ так как нужно (типа стринг билдера)? Причём я уверен что таких решений уже немеренно (хотя спорить не буду, у меня таких задач пока не возникало)


Тебе? Ничего. Только вот не факт, что выдет быстрее чем wstring, и не совсем не факт, что основная масса программистов вообще задумается об оптимизации.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.02.04 20:46
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Ну нет как раз на шарпе писать. Конечно первое время наверно будет интересно и ново, но вот что потом, я не могу предположить)


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

Если серьзено, то после обвыкания на плюсы обратно уже не тянет. Нехватает конечно кое-чего. Но со временем привыкаешь.

Правда я переходил не резко. Но на плюсах до этого писал лет 10.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.02.04 20:46
Оценка:
Здравствуйте, voxel3d, Вы писали:

А от чего тошнит? Можешь разжевать? Я вот как-то чем дальше, тем больше вспоминаю о плюсах как о страшном сне.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 02:35
Оценка:
Здравствуйте, naje, Вы писали:

N>Я хотел в качестве примера не проект (которых и на С++ достаточно), а особенность, которая сокращает сроки разработки и повышает читабельность.


И ссылку можно на аналог Хоума?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: C++ versus C#
От: naje  
Дата: 26.02.04 08:05
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


N>>Я хотел в качестве примера не проект (которых и на С++ достаточно), а особенность,

N>>которая сокращает сроки разработки
S>автоматическое управление памятью решает очень большую часть проблем
на С++ огромный выбор сборщикров мусора, но они редко когда нужны, смарт поинтеров хватает вполне

N>>и повышает читабельность.

S>отсутствие ужасного разделения между декларацией и дефиницией, которое заставляет при чтении непрерывно прыгать между .cpp и .h

а вот это, насколько я знаю, оснавная фишка из-за которой многим кажется что с С# работать легче, впринципе можно считать плюсом (я не считаю по многим причинам, никогда даже стабгенами не пользовался никакими), но не настолько большим чтоб считать С# языком более высокого уровня чем С++

S>Это не все. Но уже достаточно чтобы понять, откуда и куда дует ветер.

давай ещё
Re[12]: C++ versus C#
От: naje  
Дата: 26.02.04 08:13
Оценка:
Здравствуйте, VladD2, Вы писали:

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


N>>Я хотел в качестве примера не проект (которых и на С++ достаточно), а особенность, которая сокращает сроки разработки и повышает читабельность.


VD>И ссылку можно на аналог Хоума?


мне стыдно, но я не знаю замечательных особенностей Хоума, и я надеюсь мы не будем тут начинать мерятся проектами
можно сравнить один проект сделаный на С# и на C++
вот например boost::spirit и spart
плюс в этом же топике давали ссылочку здесь

покажи мне хоть один проект выполненный на С++ который бы при портировании на C# улучшился
Re[8]: C++ versus C#
От: naje  
Дата: 26.02.04 08:16
Оценка:
VD> и не совсем не факт, что основная масса программистов вообще задумается об оптимизации.

задумаются, только когда нужно будет
Re[13]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.02.04 08:57
Оценка:
Здравствуйте, naje, Вы писали:
N>на С++ огромный выбор сборщикров мусора, но они редко когда нужны, смарт поинтеров хватает вполне
Основная беда сборщиков мусора на С++ — невозможность заставить ими пользоваться. Единственный способ убедиться в том, что программист случайно или намеренно не вывел объект из-под управления GC — тщательный просмотр кода. Все. Эту тему я дальше не обсуждаю.
S>>отсутствие ужасного разделения между декларацией и дефиницией, которое заставляет при чтении непрерывно прыгать между .cpp и .h
N>а вот это, насколько я знаю, оснавная фишка из-за которой многим кажется что с С# работать легче, впринципе можно считать плюсом (я не считаю по многим причинам, никогда даже стабгенами не пользовался никакими), но не настолько большим чтоб считать С# языком более высокого уровня чем С++
Еще раз: про уровень мы не говорим. Мы говорим про сокращение сроков разработки.
N>давай ещё
А зачем?
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: C++ versus C#
От: naje  
Дата: 26.02.04 09:10
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

N>>на С++ огромный выбор сборщикров мусора, но они редко когда нужны, смарт поинтеров хватает вполне
S>Основная беда сборщиков мусора на С++ — невозможность заставить ими пользоваться. Единственный способ убедиться в том, что программист случайно или намеренно не вывел объект из-под управления GC — тщательный просмотр кода. Все. Эту тему я дальше не обсуждаю.

очень даже возможно, всё очень даже контролируется, ладно тему закрыли

S>>>отсутствие ужасного разделения между декларацией и дефиницией, которое заставляет при чтении непрерывно прыгать между .cpp и .h

N>>а вот это, насколько я знаю, оснавная фишка из-за которой многим кажется что с С# работать легче, впринципе можно считать плюсом (я не считаю по многим причинам, никогда даже стабгенами не пользовался никакими), но не настолько большим чтоб считать С# языком более высокого уровня чем С++
S>Еще раз: про уровень мы не говорим. Мы говорим про сокращение сроков разработки.
ну в данном примере помоему повышается только скорость набора кода, зато начинает страдать реюсабельность, но насчёт этого лучше не спорить наверное
N>>давай ещё
S>А зачем?

просто хочу для себя понять, чем так замечателен этот язык, я ж не думаю что из-за того что микрософт на заборе что-то написало (они же непогрешимы и непостежимы)
Re[13]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.02.04 09:40
Оценка:
Здравствуйте, naje, Вы писали:

N>покажи мне хоть один проект выполненный на С++ который бы при портировании на C# улучшился


Чтобы вкусить преимущества дотнета в полной мере проект надо не портировать, а переписывать.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[5]: Вопрос слегка не в тему
От: voxel3d  
Дата: 26.02.04 09:42
Оценка:
Здравствуйте, voxel3d, Вы писали:

наследования, сорри за ошибки.
Re[14]: C++ versus C#
От: naje  
Дата: 26.02.04 09:44
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


N>>покажи мне хоть один проект выполненный на С++ который бы при портировании на C# улучшился


AVK>Чтобы вкусить преимущества дотнета в полной мере проект надо не портировать, а переписывать.


ну объясни мне чем отличаются эти понятия

покажи мне хоть один проект выполненный на С++ который бы при переписывании на C# улучшился

так нормально?
Re[5]: Вопрос слегка не в тему
От: naje  
Дата: 26.02.04 10:14
Оценка:
Здравствуйте, voxel3d, Вы писали:

V> И вообще, я любил секс с непонятными глюками, дебаггер и профайлер были моими любимыми игрушками и я знал, что кроме меня баги никто победить не в состоянии будет,


правильный общий для всей команды стиль программирование победит всё

V> а здесь.. всё упростилось. Синтаксис изучил, с библиотекой классов ознакомился, всё. Идиомы гораздо проще.. Нету в шарпе духа, сдох он. И свободы в нём нет. Есть только один стиль написания программ -- правильный. Неинтересно. В С++ мои знания в глубину росли, а здесь я не понимаю вообще куда.. С шарпом с хорошим архитектором, очень умные программисты в 80% проектов не особо нужны бывают.. В С++ такой номер не прокатил бы..


в большинстве случаев получается всё не так просто,
как потом оказывается (в пресрелизах микрософт этого не пишут) шарп просто создаёт илюзию простоты и безопасности и читабельности (и я далеко не един в этом мнении)
когда это понимается в крупной конторе уже поздно уже работает сотня "средних" прграммистов, которые уже съели немеренно денег, а стоещего и не глючного так ничево и не сделали (у меня есть примеры)
Re[15]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.02.04 10:20
Оценка:
Здравствуйте, naje, Вы писали:

N>покажи мне хоть один проект выполненный на С++ который бы при переписывании на C# улучшился


Я к сожалению не был близко знаком с проектами, переписанными с С++ на дотнет.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[6]: Вопрос слегка не в тему
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.02.04 10:37
Оценка:
Здравствуйте, naje, Вы писали:

N>как потом оказывается (в пресрелизах микрософт этого не пишут) шарп просто создаёт илюзию простоты и безопасности и читабельности (и я далеко не един в этом мнении)


Устойчивая, надо сказать иллюзия, если после 2-лет и нескольких мег исходников пока держится . Хуже того, продолжает усиливаться.

N>когда это понимается в крупной конторе уже поздно уже работает сотня "средних" прграммистов, которые уже съели немеренно денег, а стоещего и не глючного так ничево и не сделали (у меня есть примеры)


А у меня есть примеры когда сделали. Далеко ходить не надо — этот сайт, янус, RSDN NNTP.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[15]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.02.04 10:37
Оценка:
Здравствуйте, naje, Вы писали:
N>ну в данном примере помоему повышается только скорость набора кода, зато начинает страдать реюсабельность, но насчёт этого лучше не спорить наверное
Гм. Я не вижу, каким образом единственность места для написания кода уменьшит reusability.

N>просто хочу для себя понять, чем так замечателен этот язык, я ж не думаю что из-за того что микрософт на заборе что-то написало (они же непогрешимы и непостежимы)

Практика показывает очень значительный рост производительности труда программистов при использовании этого языка вместо традиционных. Особенно это касается компонентных приложений со слабо связанными частями. Какие усилия нужны для того, чтобы класс на С++ вынести в DLL? А сделать динамическое подключение классов-реализаций (plug-in)? А если они теперь должны выполняться на удаленной машине? А через фаерволл? Нынче это типовые задачи программирования.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Вопрос слегка не в тему
От: naje  
Дата: 26.02.04 10:41
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


N>>как потом оказывается (в пресрелизах микрософт этого не пишут) шарп просто создаёт илюзию простоты и безопасности и читабельности (и я далеко не един в этом мнении)


AVK>Устойчивая, надо сказать иллюзия, если после 2-лет и нескольких мег исходников пока держится . Хуже того, продолжает усиливаться.


N>>когда это понимается в крупной конторе уже поздно уже работает сотня "средних" прграммистов, которые уже съели немеренно денег, а стоещего и не глючного так ничево и не сделали (у меня есть примеры)


AVK>А у меня есть примеры когда сделали. Далеко ходить не надо — этот сайт, янус, RSDN NNTP.


ну наверное там были не "средние" программисты
я не хотел сказать что на C# невозможно сделать что-то стоещее, просто это не так просто как описывается
Re[16]: C++ versus C#
От: naje  
Дата: 26.02.04 10:58
Оценка:
Здравствуйте, Sinclair, Вы писали:

N>>просто хочу для себя понять, чем так замечателен этот язык, я ж не думаю что из-за того что микрософт на заборе что-то написало (они же непогрешимы и непостежимы)

S>Практика показывает очень значительный рост производительности труда программистов при использовании этого языка вместо традиционных.


S> Особенно это касается компонентных приложений со слабо связанными частями. Какие усилия нужны для того, чтобы класс на С++ вынести в DLL? А сделать динамическое подключение классов-реализаций (plug-in)? А если они теперь должны выполняться на удаленной машине? А через фаерволл? Нынче это типовые задачи программирования.


Я все эти задачи решаю на С++(и не только я, и нет в этом ничево такого сложного и страшного, и здеся я говорю не про микрософтовские технологии), практика показывает большой рост производительности при создании реюсабельного кода, а как бы там ни было благодаря шаблонам и большой степени свободы С++ больше для этого подходит, связаность действительно сильной получается, но если захотеть то всё что есть в .net реализуется один раз а потом постоянно спользуется так же легко как и в .net (а может легче)

Да причём тут всё это? мы же языки сравниваем?

Скажи мне хоть одну действительно новую технологию которая есть в .net
только не надо говорить что .net объеденил все эти технологии, помоему это скорее минус т.к. отсутствует возможность выбора и быстрого перехода на какую-нибудь лучшую технологию (которая есть или будет (и придумает её может и микрософт)))
Re[15]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.02.04 11:17
Оценка:
Здравствуйте, naje, Вы писали:
N>покажи мне хоть один проект выполненный на С++ который бы при переписывании на C# улучшился

N>так нормально?

У-у-у... У нас этих проектов — как грязи. Если бы мы могли с самого начала пользоваться .Net (ASP.NET+ADO.NET+WinForms), то некоторые вещи стоили бы нам очень намного дешевле, а некоторые хотя бы начали бы работать правильно.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: C++ versus C#
От: naje  
Дата: 26.02.04 11:20
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

N>>покажи мне хоть один проект выполненный на С++ который бы при переписывании на C# улучшился

N>>так нормально?

S>У-у-у... У нас этих проектов — как грязи. Если бы мы могли с самого начала пользоваться .Net (ASP.NET+ADO.NET+WinForms), то некоторые вещи стоили бы нам очень намного дешевле, а некоторые хотя бы начали бы работать правильно.

я ж тебе не разказываю про наши проекты, ты дай мне то на что посмотреть можно
Re[17]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.02.04 11:27
Оценка:
Здравствуйте, naje, Вы писали:
N>Да причём тут всё это? мы же языки сравниваем?
И? На С++ нельзя написать библиотеку, которая даст мне возможность двумя строчками кода опубликовать объект в сети. А на .Net не только можно, но она уже написана!
N>Скажи мне хоть одну действительно новую технологию которая есть в .net
JIT, Metadata, User-Defined Metadata. Этого в С++ нет и быть не может. Некоторые из моментов поддаются эмуляции. Да и то она выглядит достаточно бледно по сравнению с тем, что есть в .Net. Одна возможность генерации кода на лету открывает совершенно новое измерение гибкости и комфорту.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: C++ versus C#
От: naje  
Дата: 26.02.04 11:41
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

N>>Да причём тут всё это? мы же языки сравниваем?
S>И? На С++ нельзя написать библиотеку, которая даст мне возможность двумя строчками кода опубликовать объект в сети. А на .Net не только можно, но она уже написана!
можно
N>>Скажи мне хоть одну действительно новую технологию которая есть в .net
S>JIT, Metadata, User-Defined Metadata. Этого в С++ нет и быть не может. Некоторые из моментов поддаются эмуляции. Да и то она выглядит достаточно бледно по сравнению с тем, что есть в .Net. Одна возможность генерации кода на лету открывает совершенно новое измерение гибкости и комфорту.

Эти технологии придумал не микрософт, а я спрашивал именно про то что придумал микософт.
Одна возможность генерации кода на лету открывает совершенно новое измерение в генерации ошибок. Один из плюсов С++ это работа которая делается в ct, и ты узнаешь об ошибках когда компилируешь программку, а не когда на твою техподдержку звонит оч нервный и разгневанный пользователь и читает тебе цифорки из окошка эксепшина.
Metadata и User-Defined Metadata легко и ярко реализуются в С++, причём и генерацию кода можно сделать, только зачем?
по поводу JIT , я не пойму почему микрософт сделала такой упор на него, почему во всех системах в которых есть возможность JIT'а и VM, выбор делается в пользу VM, я в этом вопросе не специалист, может ты специалист, так расскажи
Re[8]: Вопрос слегка не в тему
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.02.04 11:50
Оценка:
Здравствуйте, naje, Вы писали:

AVK>>А у меня есть примеры когда сделали. Далеко ходить не надо — этот сайт, янус, RSDN NNTP.


N>ну наверное там были не "средние" программисты


В случае януса были всякие.

N>просто это не так просто как описывается


Ну то есть я тебя обманываю, так? Зачем?
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[9]: Вопрос слегка не в тему
От: naje  
Дата: 26.02.04 11:55
Оценка:
Здравствуйте, AndrewVK, Вы писали:

N>>просто это не так просто как описывается


AVK>Ну то есть я тебя обманываю, так? Зачем?


где я тебя в чём обвинял?
я высказал своё мнение, у тебя своё есть, и это хорошо
я не настаиваю на своём
я может даже хочу чтоб меня переубедили
Re[17]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.02.04 12:17
Оценка:
Здравствуйте, naje, Вы писали:
N>я ж тебе не разказываю про наши проекты, ты дай мне то на что посмотреть можно
А как я дам тебе взглянуть внутрь того, чего у меня нету? Я как-то не занимался анализом путей совершенствования opensource проектов при помощи перехода на .Net
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Вопрос слегка не в тему
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.02.04 12:20
Оценка:
Здравствуйте, naje, Вы писали:

N>>>просто это не так просто как описывается


AVK>>Ну то есть я тебя обманываю, так? Зачем?


N>где я тебя в чём обвинял?


Просто логический вывод. После моих слов о том что на шарпе проще создавать проекты вот эти слова:

N>я не хотел сказать что на C# невозможно сделать что-то стоещее, просто это не так просто как описывается


явно подразумевают что я тебя обманул.

N>я может даже хочу чтоб меня переубедили


А как тебя переубедить? Я привел тебе примеры готовых проектов. По результатам могу сказать что на .NET в целом удалось затратить заметно меньше усилий чем если бы эти проекты писались на С++ или Дельфи.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[11]: Вопрос слегка не в тему
От: naje  
Дата: 26.02.04 12:37
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


N>>>>просто это не так просто как описывается


AVK>>>Ну то есть я тебя обманываю, так? Зачем?


N>>где я тебя в чём обвинял?


AVK>Просто логический вывод. После моих слов о том что на шарпе проще создавать проекты вот эти слова:


N>>я не хотел сказать что на C# невозможно сделать что-то стоещее, просто это не так просто как описывается


AVK>явно подразумевают что я тебя обманул.


я имел ввиду как описывается в пресрелизах микрософт

N>>я может даже хочу чтоб меня переубедили


AVK>А как тебя переубедить? Я привел тебе примеры готовых проектов. По результатам могу сказать что на .NET в целом удалось затратить заметно меньше усилий чем если бы эти проекты писались на С++ или Дельфи.


ну я хочу знать почему, какие такие особенности позволяют сделать такие выводы

сразу говорю что я не согласен что скорость разработки сильно увеличивает CLR, remouting, reflection (так сразу всё и не вспомню)
то что много чего переложено на рантайм помоему замедляет разработку приложения(ну и его производительность), конечно даёт кучу преимуществ, но зачем они все нужны? это всё похоже больше на дешёвые пряники которыми программистов заманивают в .net
Re[12]: Вопрос слегка не в тему
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.02.04 13:00
Оценка:
Здравствуйте, naje, Вы писали:

N>я имел ввиду как описывается в пресрелизах микрософт


Ну пресс-релизы всегда "слегка" преувеличивают. Не только у МС.

N>ну я хочу знать почему, какие такие особенности позволяют сделать такие выводы


Там целый комплекс особенностей. В янусе скажем максимально удалось съэкономить благодаря метаданным и веб-сервисам, благодаря внятным и по месту сообщениям об ошибках.

N>сразу говорю что я не согласен что скорость разработки сильно увеличивает CLR, remouting, reflection (так сразу всё и не вспомню)

N>то что много чего переложено на рантайм помоему замедляет разработку приложения(ну и его производительность), конечно даёт кучу преимуществ, но зачем они все нужны? это всё похоже больше на дешёвые пряники которыми программистов заманивают в .net

Ну что тут можно сказать. Практика показала что все это реально работает, естественно если уметь применять. Так что тут таки вопрос доверия — либо ты мне веришь, либо нет .
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[19]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.02.04 13:36
Оценка:
Здравствуйте, 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 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 26.02.04 14:48
Оценка:
Здравствуйте, Kluev, Вы писали:
K>Не так часто нужен маршаллинг, а когда нужен то ИМХО что-то типа MIDL в самый раз.
Э-э, парень... MIDL — сакс. После напишу почему.
K>Зачем собирать мусор со всего света и тащить его в язык?. Лучше узкоспециализированные веши порешать специальными заточенными тулзами. Тады все будет ОК. И свобода выбора останется. Вдруг понадобятся тебе специализированные метаданные и упресся ты в то, что намертво в НЕТ зашито, тады сразу вспомнишь старые добрые плюсы.
Вот как раз для этого и сделали User-defined metadata! Так что лично я никогда не упрусь.
K>В С++ тоже можно генерить код на лету. Таскай с собой бесплатный Ц-компилер. генери Ц-код, собирай в DLL грузи и выгружай. И не капассируй нам мозги про генерацию кода.
Ну щас прям. И сразу получи платформенную зависимость. Как минимум. А также необходимость таскать с собой запас хидеров для того, чтобы генеренный код мог взаимодействовать с другим кодом. В общем, ребята, солюшн с Ц-компилером даже на шутку не тянет. Потому его и не применяет никто и никогда. В отличие от той самой генерации кода в .Net.

K>Сложность где? Я вот идейку на вооружение взял, порешал то-что нужно и в макрос все завернул. Теперь добавляю в свои классцы по одной строчке на класс и не нарадуюсь. Все летает и гемороя не имею. И ограничений особых нет.

А что именно летает, позвольте спросить? Функционал какой?
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: C++ versus C#
От: Kluev  
Дата: 26.02.04 15:14
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

K>>Не так часто нужен маршаллинг, а когда нужен то ИМХО что-то типа MIDL в самый раз.
S>Э-э, парень... MIDL — сакс. После напишу почему.
Я имел ввиду не конкретную поделку от микровсоса, а сам способ. Можно и самому написать что нибудь подобное или выбрать между тем-же MIDL-СОМ или СОRBA и т.п.

S>Вот как раз для этого и сделали User-defined metadata! Так что лично я никогда не упрусь.

В С++ вообще все user-defined. Конечно метаданные как в НЕТ не сделаешь, но ИМХО и потребности нет.

K>>В С++ тоже можно генерить код на лету. Таскай с собой бесплатный Ц-компилер. генери Ц-код, собирай в DLL грузи и выгружай. И не капассируй нам мозги про генерацию кода.

S>Ну щас прям. И сразу получи платформенную зависимость. Как минимум. А также необходимость таскать с собой запас хидеров для того, чтобы генеренный код мог взаимодействовать с другим кодом. В общем, ребята, солюшн с Ц-компилером даже на шутку не тянет. Потому его и не применяет никто и никогда. В отличие от той самой генерации кода в .Net.

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

А если быстродействие особое не нужно, то прикрутить скрипт-машину к плюсовой программе нет проблемм. Генери в скрипт и не жалуйся. ИМХО, надуманная проблемма вообще.

K>>Сложность где? Я вот идейку на вооружение взял, порешал то-что нужно и в макрос все завернул. Теперь добавляю в свои классцы по одной строчке на класс и не нарадуюсь. Все летает и гемороя не имею. И ограничений особых нет.

S>А что именно летает, позвольте спросить? Функционал какой?

Мультиметоды, в основном.
Re[20]: C++ versus C#
От: naje  
Дата: 26.02.04 15:18
Оценка:
Здравствуйте, 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.

погугли по JIT и VM (без microsoft и java)
Re[13]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 15:43
Оценка:
Здравствуйте, naje, Вы писали:

N>мне стыдно, но я не знаю замечательных особенностей Хоума,


Это не сложно: http://rsdn.ru/?janus/article/article.xml

N> и я надеюсь мы не будем тут начинать мерятся проектами


Не, мне интересны просто аналоги... Их наличие и возможности...

N>можно сравнить один проект сделаный на С# и на C++

N>вот например boost::spirit

Не вижу что тут сравнивать.

N> и spart


К сожалению не знаком с таковым.

N>плюс в этом же топике давали ссылочку здесь


Ну, то что это чушь тут тоже не раз говорилось. Там даже Ява быстрее дотнета, а это просто бред.

N>покажи мне хоть один проект выполненный на С++ который бы при портировании на C# улучшился


Портировании? Да на С++ просто нет сравнимых проектов.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 15:43
Оценка:
Здравствуйте, naje, Вы писали:

N>я ж тебе не разказываю про наши проекты, ты дай мне то на что посмотреть можно


Кстати, очень показательным примером является эволюция АСП. Первое АСП было написано на С/С++. АСП.НЭТ написано на Шарпе. При этом оно и работает быстрее, и функциональнее, и надежнее.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 15:43
Оценка:
Здравствуйте, naje, Вы писали:

N>на С++ огромный выбор сборщикров мусора, но они редко когда нужны, смарт поинтеров хватает вполне




Да если бы хоть один из них можно было бы использовать на практике и не материться при этом, то про смарпоинтеры все бы уже давно забыли.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 15:47
Оценка:
Хотел было что-то ответить, но умер со смежу. В общем, 5 балов... Я плякаль...
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.02.04 15:57
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>С++ - 1692 ms (+/- 10)

CS>С#2433 ms (+/- 50)

Со строками несколько проблем. Их тип — (ANSI или UNICODE) и оптимизации всякие.
Потому результаты будут разные. Строки в шарпе очень хитрые, больше всего похожи... ни на что !!!
Это действительно так. Гляньте в исходники ротора и все будет видно.
Потому строки дотнетовские успешно конкурируют со строками в С++.
Re[14]: C++ versus C#
От: naje  
Дата: 26.02.04 16:02
Оценка:
Здравствуйте, VladD2, Вы писали:

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


N>>мне стыдно, но я не знаю замечательных особенностей Хоума,


VD>Это не сложно: http://rsdn.ru/?janus/article/article.xml


N>> и я надеюсь мы не будем тут начинать мерятся проектами


VD>Не, мне интересны просто аналоги... Их наличие и возможности...


я никогда не занимался этим направлением

N>>можно сравнить один проект сделаный на С# и на C++

N>>вот например boost::spirit

VD>Не вижу что тут сравнивать.


N>> и spart


spart это переписанный boost::spirit

это генератор парсеров с ct, для того чтоб написать парсер не нужены кокоры, яки и бизоны, всё делается с ct (в варианте C++ конечно), таким же образом можно и idl заменить (вспоминался в этом топике), а на C# этого сделать нельзя, прийдётся ждать когда в С# встроят генератор парсеров

N>>плюс в этом же топике давали ссылочку здесь


VD>Ну, то что это чушь тут тоже не раз говорилось. Там даже Ява быстрее дотнета, а это просто бред.


так проверь, может и не чушь? напиши статью по этому поводу, как обманывают, враги

N>>покажи мне хоть один проект выполненный на С++ который бы при портировании на C# улучшился


VD>Портировании? Да на С++ просто нет сравнимых проектов.


И конечно все самые несравненные проекты на C# написал Ты.
Re[18]: C++ versus C#
От: naje  
Дата: 26.02.04 16:04
Оценка:
Здравствуйте, VladD2, Вы писали:

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


N>>я ж тебе не разказываю про наши проекты, ты дай мне то на что посмотреть можно


VD>Кстати, очень показательным примером является эволюция АСП. Первое АСП было написано на С/С++. АСП.НЭТ написано на Шарпе. При этом оно и работает быстрее, и функциональнее, и надежнее.


осталось только винду на шарпе переписать
Re[6]: Вопрос слегка не в тему
От: naje  
Дата: 26.02.04 16:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Хотел было что-то ответить, но умер со смежу. В общем, 5 балов... Я плякаль...


лично мне твоё психическое состояние знать совсем не интересно, это помоему форум не по той теме форум
Re[19]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 16:46
Оценка:
Здравствуйте, naje, Вы писали:

N>осталось только винду на шарпе переписать


Будешь смеяться, но над этим уже работают.

В Лонгхорне почти все новые АПИ будут на дотнете. И вообще огромная часть ОС станет менеджед.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 16:46
Оценка:
Здравствуйте, naje, Вы писали:

N>spart это переписанный boost::spirit


N>это генератор парсеров с ct, для того чтоб написать парсер не нужены кокоры, яки и бизоны, всё делается с ct (в варианте C++ конечно), таким же образом можно и idl заменить (вспоминался в этом топике), а на C# этого сделать нельзя, прийдётся ждать когда в С# встроят генератор парсеров


Понял. Ну, мне как-то коко больше нравится. И синтаксис по-чище и скорость приличная. А главное, писать на Шарпе неимеверно проще. Плюс почти нет отладки.

N>так проверь, может и не чушь? напиши статью по этому поводу, как обманывают, враги


Враги? А статья кое-какая давное есть: http://rsdn.ru/?summary/590.xml

Да и опыт работы и на там, и на другом. На плюсах пишу уже лет 10, на Шарпе два года (даже больше, с появления первой бэты).

N>И конечно все самые несравненные проекты на C# написал Ты.


Не все. Но аналог Хоума мы искали и ничего приличного не нашли. За то за время существования этого проекта сто раз слышали о том, как Вася Пупкин завтра перепишет его на: С++, Дельфи (нужное подчеркнуть/вписать). Но все эти слова так и остались словами.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 16:46
Оценка:
Здравствуйте, naje, Вы писали:

VD>>Хотел было что-то ответить, но умер со смежу. В общем, 5 балов... Я плякаль...


N>лично мне твоё психическое состояние знать совсем не интересно, это помоему форум не по той теме форум


Я как бы не тебе отвечал.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.02.04 16:47
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Теперь зайдем с другого конца. Возьмем тест на C#-е и попытаемся переписать его на С++ без ручных оптимизаций. Как бы поступил средний программист встань пред ним подобная задача? Да очень просто... он воспользовался бы готовым классом. B VC предоставляет нам такой класс — это CString. Его ATL-версия как раз имеет вариант CStringW (работающий с Юникодом). Переписываем тест:


Сравнивать нетовский стринг с CStringT (который уже потом CStringW) есть жульничество.
Нетовский стринг очень сильно отличается от CString, хоть и похож организацией данных.

Для конкатенации в нетовском стринге перегружено куча методов. На два аргумента, на три, на четыре и на мессив.
А что мы имеем в CStringT в этом случае?

Для компарации испоьзуется также особо хитрый механизм. А что с CStringT ?
Там вызывается ::CompareStringW исходный код которой на порядки!!! больше из за ее универсальности. Размер файла строкового АПИ в выне 132 килобайта.

Посему уместно сравнить нетовскую реализацию строк с такой же, выдраной из ротора, но на нативном С++.
Для этого надо взять и адаптировать файлы comstring.h и comstring.cpp. Из этих файлов выбросить весь лишний, читай нетовский, мусор и тогда, думаю, разница нас всех удивит.
Еще можно соптимизировать — развернуть циклы, как это делается в выне, на 8 итераций.
Re[20]: C++ versus C#
От: naje  
Дата: 26.02.04 16:50
Оценка:
Здравствуйте, VladD2, Вы писали:

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


N>>осталось только винду на шарпе переписать


VD>Будешь смеяться, но над этим уже работают.


VD>В Лонгхорне почти все новые АПИ будут на дотнете. И вообще огромная часть ОС станет менеджед.


вот тогда и посмотрим
Re[16]: C++ versus C#
От: naje  
Дата: 26.02.04 16:58
Оценка:
Здравствуйте, 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, на Шарпе два года (даже больше, с появления первой бэты).


у меня опыт на шарпе маленький, могу поделится своим вариантом ощущений, ощущения можно сравнить с теми когда нужно что-то от руки написать, и когда психологически чуствуешь что на клавиатуре всё это можно написать быстрее и это немного напрягает
Re[9]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 18:36
Оценка:
Здравствуйте, naje, Вы писали:

N>странно


Ты на дерево погляди... Я вот на это Re[4]: Вопрос слегка не в тему
Автор: voxel3d
Дата: 26.02.04
отвечал.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 18:36
Оценка:
Здравствуйте, naje, Вы писали:

N>а некоторым idl больше нравится (не мне)

N>на C++ если в ct побольше запихать то тоже отладчик не нужен будет

А если еще по больше, то и компьютер.

N>у меня опыт на шарпе маленький, могу поделится своим вариантом ощущений, ощущения можно сравнить с теми когда нужно что-то от руки написать, и когда психологически чуствуешь что на клавиатуре всё это можно написать быстрее и это немного напрягает


Это с непривычки.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.02.04 18:36
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Посему уместно сравнить нетовскую реализацию строк с такой же, выдраной из ротора, но на нативном С++.

PE>Для этого надо взять и адаптировать файлы comstring.h и comstring.cpp. Из этих файлов выбросить весь лишний, читай нетовский, мусор и тогда, думаю, разница нас всех удивит.

Займись, удивись. Только учти, что прийдется не выбрасывать мусор, а добавлять.

PE>Еще можно соптимизировать — развернуть циклы, как это делается в выне, на 8 итераций.


Может просто сравнить с временем создания константы?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.02.04 06:26
Оценка:
Здравствуйте, 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 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.02.04 06:26
Оценка:
Здравствуйте, 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 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: C++ versus C#
От: naje  
Дата: 27.02.04 07:12
Оценка:
Здравствуйте, 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. Вообще говоря, уже этого достаточно для опровержения твоего всеобъемлющего утверждения. А поскольку исходная посылка неверна, вопрос придется снять.

комерческие реализации не ограничиваются этими двумя
впринципе наверное смог бы показать, но тоже времени особо нет, поэтому отложим
Re[24]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 27.02.04 07:40
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Как ты думаешь, почему не существует C++SP?


Не, в 1.2 вроде бы МС++ можно для страничек пользовать.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[4]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.02.04 08:12
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Займись, удивись. Только учти, что прийдется не выбрасывать мусор, а добавлять.


PE>>Еще можно соптимизировать — развернуть циклы, как это делается в выне, на 8 итераций.


VD>Может просто сравнить с временем создания константы?


В виндовских исходниках частенько присутсвует оптимизация в таком и другом виде.
Re[23]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.02.04 08:17
Оценка:
Здравствуйте, 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 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.02.04 08:27
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Не, в 1.2 вроде бы МС++ можно для страничек пользовать.
Ну мы же оба понимаем, что это не С++
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: C++ versus C#
От: naje  
Дата: 27.02.04 08:41
Оценка:
Здравствуйте, 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 всё оч даже компилится, туда куда надо, да и причём тут регэкспы (ты ссылку повтори пожалуста чтоб я смог прочитать то что мне надо), ты мне сейчас весь фреймворк перечислять будешь?
Re[25]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.02.04 09:57
Оценка:
Здравствуйте, 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 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: C++ versus C#
От: Kluev  
Дата: 27.02.04 09:59
Оценка:
Здравствуйте, 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. Более старые технологии позволяют делать либо хорошие, либо дешевые программы. Точка. Не хотите — не надо.


Либо позволяют делать программы которые на НЕТ ну никак. Все что интенсивно пользует память, все расчетные задачи, все задачи моделирования и проектирования не для НЕТ по определению
Re[26]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.02.04 10:05
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Пиши статью Дело-то хорошее. Плюсы еще очень много где применимы. Так что best practices по ним завсегда нужны.


Еще и ассемблер не вымер. Дотнет и жава не смогут столкнуть нативные прилы на С++. Рынок нативных прил конечно потеснится, но...
Re[25]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.02.04 10:10
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Какая такая стоимость? Я скрипт машину за неделю с нуля напишу, а уж готовую прикрутить. не вижу проблем вообще.


С этим кнечно все просто. Проблемы не со скрипт-машиной и ее прокручиванием.
Пролемы с отображением модели данных например в скрипт.
К слову — этиже пролемы есть и в шарпе. Причем очень хитрые, не сразу и догадаешься.
Кое какие ушли. Кое какие добавились. За счет экономии времени на написание кода и на отладку есть время обходить косяки дотнетовские.

K>Либо позволяют делать программы которые на НЕТ ну никак. Все что интенсивно пользует память, все расчетные задачи, все задачи моделирования и проектирования не для НЕТ по определению


Именно ! Мы поимели печальный опыт дотнета. Кастомер ппросил увеличить перформанс в два-три раза. От плюсовой версии, к примеру, все торчали.
Re[26]: C++ versus C#
От: naje  
Дата: 27.02.04 10:22
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


N>>нихочу тебя ни в чём переубеждать да и времени нету, просто поверь у меня всё это работает, не на boost::tuples, но работает

S>Пиши статью Дело-то хорошее. Плюсы еще очень много где применимы. Так что best
practices по ним завсегда нужны.

та надо

S>

S>- В C нельзя запретить прямое обращение к членам структуры, минуя функции-аксессоры.
S>- Ну нельзя. А зачем? Единый стиль, по особому заданные функции...

S>Ничего не напоминает?

в С врядли получится генерить ct-ошибки, по каким-то семантическим правилам

S>Да ну? Вот так прямо регекспы компиляются в CT? И все в рамках С++?


ну например здесь
Автор: TepMuHyc
Дата: 13.11.03
, там правда не в автомат выражение собирается, но можно сделать чтоб в автомат, это пример просто чтоб показать что можно сделать.

N>>да и причём тут регэкспы (ты ссылку повтори пожалуста чтоб я смог прочитать то что мне надо), ты мне сейчас весь фреймворк перечислять будешь?

S>Как причем? Если ты мне приводишь в качестве аргумента некие приложения, написанные на С++, и результаты их работы, то я тебе в ответ напишу библиотеки, написанные на C#, и результаты их использования.

сравнивать регулярные выражения и генератор парсеров?
это ж как бы разные как бы порядки (разницу между контестно свободными и регулярными языками знаешь?)

S>А ссылка — вот здесь.


они кокор используют
ну и что?
Re[26]: C++ versus C#
От: naje  
Дата: 27.02.04 10:24
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

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


PE>Именно ! Мы поимели печальный опыт дотнета. Кастомер ппросил увеличить перформанс в два-три раза. От плюсовой версии, к примеру, все торчали.


зря ты это сказал, щас они тебе начнут про радиус кривизны зачитывать,
я просто не знаю какой велечины должен быть специалист чтоб на нете нормальные проги писать
Re[27]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.02.04 10:31
Оценка:
Здравствуйте, naje, Вы писали:

PE>>Именно ! Мы поимели печальный опыт дотнета. Кастомер ппросил увеличить перформанс в два-три раза. От плюсовой версии, к примеру, все торчали.


N>зря ты это сказал, щас они тебе начнут про радиус кривизны зачитывать,

N>я просто не знаю какой велечины должен быть специалист чтоб на нете нормальные проги писать

Распределенные прилы, бызы данных, все, что свебов связано — запросто. А в ряде областей очень геморройно получается.
Но что выйдет в конце концов ? Пользователи будут ставить по 1гигу памяти и по 2 гигагерца процессор.
Первые, вторые, третьи пни отомрут. Четверные и пятые будут рулить. Но это со временем. А пока спрос неслабый на нативные прилы.
Дотнет нормально будет развиваться на 64х битах. Есть кастомеры, которым нужна совместимость с вынь95. Отчего ? А железо сложно обновить.
Re[25]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.02.04 11:37
Оценка:
Здравствуйте, 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 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.02.04 23:25
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>В виндовских исходниках частенько присутсвует оптимизация в таком и другом виде.


Те коды могли писаться сто лет назад или для платформ гед компилятор вообще оптимизаций не делает. В тестах же где итерации делаются для того чтобы уменьшить погрешность измерения разворот циклов — это нечесный хак.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.04 00:22
Оценка:
Здравствуйте, naje, Вы писали:

N>зря ты это сказал, щас они тебе начнут про радиус кривизны зачитывать,

N>я просто не знаю какой велечины должен быть специалист чтоб на нете нормальные проги писать

А зачем? Вы похоже уже это усвоили.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.04 00:22
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

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

Рассказы о приемуществах С++ в скорости сильно приувеличены. А со временем этих приемуществ вообще не будет. Если сравнить скорость VC и дотнета (C#) вресий 7.0, 7.1, 8.0, то невооруженным взглядом видно, что разрыв потихоничку сокращается. Да и не так он велик. Без проблем в алгоритмах масимальный проигрыш в 2 раза. Если же учесть простоту и скорость разработки на дотнете, то становится понятно, что проще экономить время и тратить деньги на железо. Ну, а если учесть, что аысвободившееся время можно потратить на оптимизацию алгоритмов...
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.04 00:22
Оценка:
Здравствуйте, naje, Вы писали:

N>они кокор используют

N>ну и что?

Так он на Шарп портирован. Ты ведь вроде спрашивал есть ли генераторы на Шарпе. Или ты том же самом на шаблонах?

Кстати, вот добьем R# поглядим у кого больше гибкость.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.04 00:22
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Обьяснишь легко. С помошью шаблонов:

K>
K>template <class T>
K>struct arg_info {
K>     enum { marshal_type = value };
K>};

K>template <class T>
K>struct arg_info<T&> {
K>     enum { marshal_type = ref };
K>};

K>template <class T>
K>struct arg_info<T*> {
K>     enum { marshal_type = ptr };
K>};
K>// намек понятен?
K>


Ты не пытался сравнить это с декларацией на Шарпе?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.04 00:22
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Автоматическое управление памятью — это фатальный недостаток НЕТ. Программы которые манипулируют одновременно около 100000 обьектами связанными в сеть, писать на НЕТ просто нет смысла.


100000? Я когда грид отлаживал как раз дерево из этго количества строил. Загружается молниеносно.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.04 00:28
Оценка:
Здравствуйте, Sergey, Вы писали:

S>Последний — замечательный пример Чаще не работает, чем работает.


Да уж ННТП у нас еще та бяка.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Вопрос слегка не в тему
От: Шахтер Интернет  
Дата: 28.02.04 02:40
Оценка:
Здравствуйте, voxel3d, Вы писали:

V>Есть только один стиль написания программ -- правильный.


Есть мнение, что правильных стилей не бывает. Просто ещё не успели придумать пачку-другую "неправильных".
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[18]: C++ versus C#
От: Шахтер Интернет  
Дата: 28.02.04 03:00
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>JIT, Metadata, User-Defined Metadata. Этого в С++ нет и быть не может. Некоторые из моментов поддаются эмуляции. Да и то она выглядит достаточно бледно по сравнению с тем, что есть в .Net. Одна возможность генерации кода на лету открывает совершенно новое измерение гибкости и комфорту.


Ну почему, не может. Никаких принципиальных трудностей реализовать и компиляцию в IL, и генерацию метаданных нет. Да, собственно говоря, а что такое C++/CLI?
... << RSDN@Home 1.1.0 stable >>
В XXI век с CCore.
Копай Нео, копай -- летать научишься. © Matrix. Парадоксы
Re[19]: C++ versus C#
От: alexkro  
Дата: 28.02.04 06:32
Оценка:
Здравствуйте, Шахтер, Вы писали:

Ш>Да, собственно говоря, а что такое C++/CLI?


Binding between C++ and CLI. http://www.msdn.microsoft.com/visualc/homepageheadlines/ecma/default.aspx

Блог Липпмана на эту тему: http://blogs.msdn.com/slippman/
Re[29]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.04 09:57
Оценка:
Здравствуйте, Шахтер, Вы писали:

Ш>Например, на алгоритм сортировки. Или на алгоритм сложения 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# поглядим у кого больше гибкость.


давай вы напишите, а потом смотреть будем
я это время лучше потрачу на оптимизацию алгоритмов
Re[29]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.02.04 12:51
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>давай вы напишите, а потом смотреть будем

А>я это время лучше потрачу на оптимизацию алгоритмов

Крылья, ноги... главное хвост!
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: C++ versus C#
От: naje  
Дата: 28.02.04 12:53
Оценка:
Здравствуйте, Аноним, Вы писали:

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


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


VD>>Так он на Шарп портирован. Ты ведь вроде спрашивал есть ли генераторы на Шарпе. Или ты том же самом на шаблонах?

А>сам генератор, это уж не такая сапер штука, фишка именно в том же самом

VD>>Кстати, вот добьем R# поглядим у кого больше гибкость.


А>давай вы напишите, а потом смотреть будем

А>я это время лучше потрачу на оптимизацию алгоритмов

сори, залогинется забыл
Re[9]: Вопрос слегка не в тему
От: naje  
Дата: 28.02.04 13:00
Оценка:
Здравствуйте, VladD2, Вы писали:

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


S>>Последний — замечательный пример Чаще не работает, чем работает.


VD>Да уж ННТП у нас еще та бяка.


а чё такое, нет в нете ннтп?
обыдно, да?
Re[24]: C++ versus C#
От: Kluev  
Дата: 01.03.04 08:59
Оценка:
Здравствуйте, VladD2, Вы писали:

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


K>>Автоматическое управление памятью — это фатальный недостаток НЕТ. Программы которые манипулируют одновременно около 100000 обьектами связанными в сеть, писать на НЕТ просто нет смысла.


VD>100000? Я когда грид отлаживал как раз дерево из этго количества строил. Загружается молниеносно.


Загружается всегда молниеносно, Этим никого не озадачишь. Попробуй протестировать постоянно добавляя и удаля узлы из дерева. Самое смешно начнется когда забудешь где нибудь ссылку обнулить. А ведь структуры могут быть очень сложными. ИМХО в задачах где интенсивно используются (перестраиваются) деревья, графы, сети и т.р. сборка мусора является проклятьем.
Re[6]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.03.04 09:19
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>В виндовских исходниках частенько присутсвует оптимизация в таком и другом виде.


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


При чем здесь тесты ? Строковые операции — сравнение, конкатенация, длина и тд очень сильно влияют на производительность прилаги. Так что тут раскручивание цикла имеет смысл.
Процессоры нынче не умееют предсказываться ветвления на 100%. Частичный разворот цикла дает неслабый прирост на маленьких строках, коих большинство.
Re[28]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.03.04 10:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Рассказы о приемуществах С++ в скорости сильно приувеличены. А со временем этих приемуществ вообще не будет. Если сравнить скорость VC и дотнета (C#) вресий 7.0, 7.1, 8.0, то невооруженным взглядом видно, что разрыв потихоничку сокращается. Да и не так он велик. Без проблем в алгоритмах масимальный проигрыш в 2 раза. Если же учесть простоту и скорость разработки на дотнете, то становится понятно, что проще экономить время и тратить деньги на железо. Ну, а если учесть, что аысвободившееся время можно потратить на оптимизацию алгоритмов...



В 2 раза. На плюсах наши алгоритмы работали и от нескольких дней до двух неделью В два раза это от недели до месяца. Очень хороший подход.
Железо реального преимущества не даст. ПО и так дорогое, а с железом его и купить то будет некому. Сколько памяти не ставь — два гигабайта на процесс это мало для дотнета.
Re[29]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.04 21:16
Оценка:
PE>В 2 раза. На плюсах наши алгоритмы работали и от нескольких дней до двух неделью В два раза это от недели до месяца. Очень хороший подход.

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

PE>Железо реального преимущества не даст.


Это почему? У вас все до одного вычисления последовательны?

PE> ПО и так дорогое, а с железом его и купить то будет некому. Сколько памяти не ставь — два гигабайта на процесс это мало для дотнета.


С чего ты это взял?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.04 21:16
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Гы. плюсы тоже не стоят на месте. У плюсов нет единой библиотеки на разные случаи жизни. Все приходится по миру собирать. Это основная трудность. Было-бы что-нибудь типа QT нахаляву, тогда народ с плюсов выманить было-бы невозможно. А если появится многие вернутся обратно.


QT стоит не дорого. И те кто его купили далеки от восторга. С ВинФормс — это точто сравнить нельзя.

VD>>Рассказы о приемуществах С++ в скорости сильно приувеличены. А со временем этих приемуществ вообще не будет.


K>Будут всегда.


Ошибаещся.

K> Сборка мусора всегда будет тянуть НЕТ на дно.


А это ничего, что ЖЦ в Яве работает не медленнее чем стандартные хипы С++?

K> От этого никуда не деться.


Ты алгоритм ЖЦ знаешь? Что в нем может потенциально быть проблемным?

K> Может далеть UI на НЕТ-е и просто, но работать со сложными структурами я бы на нем не стал.


Что есть сложные структуры?

K>Смотря на чем сравнивать.


Да на тех самых повседневных задачах. Именно за них идет бой. А супер навороты для мэйнфрэймов и сейчас на Фортране зачастую делают.

K>Алгоритмы уже проблема. Возьми любую нетривиальную задачу — триангуляция поверхности, разбиение обьема и т.п.


Ну, эти задачи уже давно в акселераторы зашиты. Но все равно потенциально проблем с их рассчетом на менеджед-языках нет.

K> То что такие вещи неудобно делать с автоматической сборкой мусора, в языке без адрессной арифметики (или с образаной арифметикой), и без возможностей прочего хака ясно как дважды два четыре.


А я вот так не считаю. И интересно было бы услышать обоснование последнего утверждения.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.04 21:16
Оценка:
Здравствуйте, naje, Вы писали:

VD>>Ты не пытался сравнить это с декларацией на Шарпе?


N>помоему это не декларация

N>это намёк, написали же тебе

Только по-твоему. Посмотри выще... так как раз исходная версия на Шарпе.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.04 21:16
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>В 2 раза. На плюсах наши алгоритмы работали и от нескольких дней до двух неделью В два раза это от недели до месяца. Очень хороший подход.

PE>Железо реального преимущества не даст. ПО и так дорогое, а с железом его и купить то будет некому. Сколько памяти не ставь — два гигабайта на процесс это мало для дотнета.

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

Заметь, старый код был в основном быстрее современного. Но компиляторы то с тех пор стали только быстрее.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.04 21:16
Оценка:
Здравствуйте, 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();
    }
}


На всякий пожарный: PerfCounter
Автор: VladD2
Дата: 23.04.03
.

Погляди на разницу между одной ссылкой и множественными.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[25]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.04 21:16
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Загружается всегда молниеносно, Этим никого не озадачишь. Попробуй протестировать постоянно добавляя и удаля узлы из дерева. Самое смешно начнется когда забудешь где нибудь ссылку обнулить. А ведь структуры могут быть очень сложными. ИМХО в задачах где интенсивно используются (перестраиваются) деревья, графы, сети и т.р. сборка мусора является проклятьем.


Ты знаешь? Пробовал... Нельзя сказать, что у дотнета в этих задачах приемущество, но и серьезных недостатков нет.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.04 21:37
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>При чем здесь тесты ? Строковые операции — сравнение, конкатенация, длина и тд очень сильно влияют на производительность прилаги. Так что тут раскручивание цикла имеет смысл.

PE>Процессоры нынче не умееют предсказываться ветвления на 100%. Частичный разворот цикла дает неслабый прирост на маленьких строках, коих большинство.

Притом, что речь шла о тестах. И в них расрутка (елси сам цикл сделан для увеличения объемов вычислений) — это нечестныое сравнение. На практике раскрутка может и замедлить скорость алгоритма. Погдяди второго шустрика. Там как раз был gcc с раскруткой и без.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.04 21:37
Оценка:
Здравствуйте, naje, Вы писали:

N>а чё такое, нет в нете ннтп?

N>обыдно, да?

В нете? А в С++ есть?

Речь идет о нашем ННТП-сервере написанном нами же для нас же. Жрет сабака время и память. Ну, да это просто не очень качественная реализация. Тот же Хоум раядом ведет себя очень прилично.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: C++ versus C#
От: Kluev  
Дата: 02.03.04 09:38
Оценка:
Здравствуйте, VladD2, Вы писали:

K>> Сборка мусора всегда будет тянуть НЕТ на дно.

VD>А это ничего, что ЖЦ в Яве работает не медленнее чем стандартные хипы С++?

Когда задача очень большая, то и хип нам не друг. В таких случаях делается пул и хип и ГЦ остаются далеко позади. Никакой ГЦ не сможет работать быстрее чем пул. Особенно в стрессовых условиях: ведь программа может легко работать несколько дней подряд, а в ГЦ я слышал что если обьект пережил пару сборок мусора то он уже не удаляется никогда.

В С++ оператор new перегрузил, перевел обьект из хипа в пул и вот уже перфоманс совсем другой, а что в жаве или в НЕТе делать будем? Наверное на С++ переписывать будем

VD>Ты алгоритм ЖЦ знаешь? Что в нем может потенциально быть проблемным?

Представь что программа на каждой итерации создает и освобождает ~200К обьектов. Частично или полностью (перестройка сетки). В обьектах от 10 до 30 указателей. Т.е. структура весьма ветвистая. Пул отрабатывает мгновенно. Хип, не спорю будет тормозить. А как ГЦ будет себя вести?

VD>Ну, эти задачи уже давно в акселераторы зашиты. Но все равно потенциально проблем с их рассчетом на менеджед-языках нет.


Далеко не все. Для С++ еще полным-полно работы. Может клиента БД на нем и нет смысла писать, но есть и другие программы. Можешь показать хотя-бы один CAD написаный на яве или на шарпе?
Re[26]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.03.04 10:40
Оценка:
Здравствуйте, VladD2, Вы писали:

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


K>>Загружается всегда молниеносно, Этим никого не озадачишь. Попробуй протестировать постоянно добавляя и удаля узлы из дерева. Самое смешно начнется когда забудешь где нибудь ссылку обнулить. А ведь структуры могут быть очень сложными. ИМХО в задачах где интенсивно используются (перестраиваются) деревья, графы, сети и т.р. сборка мусора является проклятьем.


VD>Ты знаешь? Пробовал... Нельзя сказать, что у дотнета в этих задачах приемущество, но и серьезных недостатков нет.


Деревья, графы, сети на дотнете превращаются в сплошной геморрой. Степень геморроя пропорциооняльна среднему количесву референсов на объект.

Серилизация это вообще отдельный случай.
Re[26]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.03.04 10:44
Оценка:
Здравствуйте, 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>
Re[30]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.03.04 10:48
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Узкие места целиком и полностью в дотнете и Шарпе.

VD>Заметь, старый код был в основном быстрее современного. Но компиляторы то с тех пор стали только быстрее.


Вот когда будет релиз шарпа с дженериками, тогда можно будет посмотреть. А пока мы зашли в тупик. Оптимизировать уже нечего...
Re[8]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.03.04 10:50
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>При чем здесь тесты ? Строковые операции — сравнение, конкатенация, длина и тд очень сильно влияют на производительность прилаги. Так что тут раскручивание цикла имеет смысл.

PE>>Процессоры нынче не умееют предсказываться ветвления на 100%. Частичный разворот цикла дает неслабый прирост на маленьких строках, коих большинство.

VD>Притом, что речь шла о тестах. И в них расрутка (елси сам цикл сделан для увеличения объемов вычислений) — это нечестныое сравнение. На практике раскрутка может и замедлить скорость алгоритма. Погдяди второго шустрика. Там как раз был gcc с раскруткой и без.


Шустрики смотреть неинтересно, ибо реальные замеры на наших аппликациях показывают совсем не то.
Re[26]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.03.04 11:35
Оценка:
Здравствуйте, 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 > 15000
            for(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();
        }
    }
}
Re[31]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 17:09
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Узкие места целиком и полностью в дотнете и Шарпе.


А мне кажется в основном в руках и головах.

PE>Вот когда будет релиз шарпа с дженериками, тогда можно будет посмотреть. А пока мы зашли в тупик. Оптимизировать уже нечего...


Вы — возможно. Я — нет. Дженерики это конечно удобно. И кое где они позволят более просто создавать более эффектиные алгоритмы, но и сейчас можно писать очень даже эффективный код.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 17:09
Оценка:
Здравствуйте, 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 17:09
Оценка:
Здравствуйте, 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 17:09
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Деревья, графы, сети на дотнете превращаются в сплошной геморрой. Степень геморроя пропорциооняльна среднему количесву референсов на объект.


Пустой треп.

PE>Серилизация это вообще отдельный случай.


Реализация по умолчанию не быстрая. Но в С++ ее вообще нет, так что сравнивать не с чем. А реализовать ее быстро можно и там, и там.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 17:09
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Я кидал ссылку про O(n**2) поведение мультикастделегата. При десерилизации происходит затык при рассылке OnDeserilizationCallback. 50000 — еще реально ждать. 100000 — уже нет.


Напиши свой алгоритм сериализации. На С++ ты же тоже не будешь иметь готового. Я уже писал об этом. Тот же нетовский дадасет у меня сериализовался со скоростью поросячего визга.

PE>Возьми и пощупай сам. А та синтетика, которую ты здесь показал, никакого отношения к сетям не имеет.


И в чем разница?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 17:09
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Вот ответ на причину тормозов при десерилизации. Это проблемы дотнета, возможно ее пофиксят.

PE>Но есть масса других проблем — стато мелких поросят.


PE>
PE>            for(int j=0; j<100000; ++j) 
PE>            {
PE>                OnEvent += new EventHandler(OnEventOccured);
PE>            }
PE>


А зачем может понадобиться добавлять обработчик события 100000 в одино место?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 17:09
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Шустрики смотреть неинтересно, ибо реальные замеры на наших аппликациях показывают совсем не то.


А уверен, что это не руки? На Хоум тоже говорили память жрет... торомзит... а когда стали разбираться, то выяснили, что основное время и память сжерает Эксес.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[32]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.03.04 17:25
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>Вот когда будет релиз шарпа с дженериками, тогда можно будет посмотреть. А пока мы зашли в тупик. Оптимизировать уже нечего...


VD>Вы — возможно. Я — нет. Дженерики это конечно удобно. И кое где они позволят более просто создавать более эффектиные алгоритмы, но и сейчас можно писать очень даже эффективный код.


Сейчас у нас каждый объект порождает пять сущностей:

Класс
2 вида коллекции — копипейст.
Основной интерфейс (для SAX Basic)
Класс/методы для валидации

Этого, мягко говоря, слишком много. Если есть темплейты, как на C++, то необходимо только класс и валидатор. Кроме того есть еще много вспомогатеьных классов, которые чтото кешируют(атрибуты, суррогаты, рефлексию и тд.). Генерировать код не представляет возможным, ибо неясно, как его отлаживать при внесении изменений в модель.
Re[28]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.03.04 17:52
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>Деревья, графы, сети на дотнете превращаются в сплошной геморрой. Степень геморроя пропорциооняльна среднему количесву референсов на объект.


VD>Пустой треп.


Конечно. Не буду же я тебе мегабайты кода слать.

PE>>Серилизация это вообще отдельный случай.


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


Можно, никто не спорит, вопрос в том, как именно. Дяди за МС по нашему поводу пока ничего не отвечают. Даже общих рекомендаций дать не могут.
Re[28]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.03.04 17:55
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>
PE>>            for(int j=0; j<100000; ++j) 
PE>>            {
PE>>                OnEvent += new EventHandler(OnEventOccured);
PE>>            }
PE>>


VD>А зачем может понадобиться добавлять обработчик события 100000 в одино место?


Загляни а серилизацию. Там аккурит такой случай.

http://www.rsdn.ru/Forum/Message.aspx?mid=546331&amp;only=1
Автор: Plutonia Experiment
Дата: 20.02.04
Re[10]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.03.04 17:57
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>Шустрики смотреть неинтересно, ибо реальные замеры на наших аппликациях показывают совсем не то.


VD>А уверен, что это не руки? На Хоум тоже говорили память жрет... торомзит... а когда стали разбираться, то выяснили, что основное время и память сжерает Эксес.


Конечно руки ! Ты, как линуксоид, уверяешь меня что всему виной руки.

В шустриках пока одна синтетика. Пока там не будет реальных алгоритмов типа упаковки, распаковки, вычислений, обработка видео, звука, изображения нечего и говорить.
Re[28]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.03.04 18:02
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>Я кидал ссылку про O(n**2) поведение мультикастделегата. При десерилизации происходит затык при рассылке OnDeserilizationCallback. 50000 — еще реально ждать. 100000 — уже нет.


VD>Напиши свой алгоритм сериализации. На С++ ты же тоже не будешь иметь готового. Я уже писал об этом. Тот же нетовский дадасет у меня сериализовался со скоростью поросячего визга.


И у меня быстрее будут делегаты работать ? Придется без них изобретать дополнительный геморрой. Для этого нам надо фактически передрать бинариформаттер и адаптировать его под свою модель. Другие форматтеры работают еще дольше. Простым форматтером здесь не обойтись.

PE>>Возьми и пощупай сам. А та синтетика, которую ты здесь показал, никакого отношения к сетям не имеет.


VD>И в чем разница?


Разница в том, что в сетях среднее количество референсов на один оъект около 30. Распространение эвента занимает существенное время. Конкатенация строк выполняется гораздо быстрее. Кроме того, некоторые базовые механизмы приходится делать с использованием рефлекшна.

Если ты силен в теории оптических сетей — милости просим, будем рады услышать мнения по дизайну модели.
Re[11]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 19:08
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Конечно руки ! Ты, как линуксоид, уверяешь меня что всему виной руки.


Я как честный линуксоид отвергаю все инсинуации.

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


Алгоритмы там самые обыкновенные. Большое же приложение просто не получится перенести на стлько язяков без ошибок и за разумное время. Если только авто-генирилкой воспользоваться...
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 19:08
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Этого, мягко говоря, слишком много. Если есть темплейты, как на C++, то необходимо только класс и валидатор. Кроме того есть еще много вспомогатеьных классов, которые чтото кешируют(атрибуты, суррогаты, рефлексию и тд.). Генерировать код не представляет возможным, ибо неясно, как его отлаживать при внесении изменений в модель.


Согласен, неудобно. Но скрость то тут причем? А над удобством мы уже рабьотаем: http://rsdn.ru/?article/rsharp/rsharp.xml
Автор(ы): Чистяков Влад (VladD2)
Дата: 28.01.2004
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 19:08
Оценка:
Здравствуйте, 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 19:08
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Можно, никто не спорит, вопрос в том, как именно. Дяди за МС по нашему поводу пока ничего не отвечают. Даже общих рекомендаций дать не могут.


А профайлер по этому поводу что говорит?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 19:08
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>И у меня быстрее будут делегаты работать ?


Нет. Только ифы и свитчи.

PE> Придется без них изобретать дополнительный геморрой.


Интерфейсы?

PE> Для этого нам надо фактически передрать бинариформаттер и адаптировать его под свою модель. Другие форматтеры работают еще дольше. Простым форматтером здесь не обойтись.


Это не так. ХМЛ-форматер работает быстрее. Если для вас сериализация критична по времени, то стоит вообще сделать свой фрэймворк по этому поводу. В отличии от плюсов для этого вдотнете все есть.

PE>Разница в том, что в сетях среднее количество референсов на один оъект около 30.


Ну, модернезируй пример до этого. У меня выдумки не хватает. Но вряд ли скорость от этого изменится. Еще раз повторяю, проверка графа относительно шустрая операция.

PE>Распространение эвента занимает существенное время. Конкатенация строк выполняется гораздо быстрее. Кроме того, некоторые базовые механизмы приходится делать с использованием рефлекшна.


Ну, так ты сам знаешь чего не надо делать. Остается только сделать как надо используя быстрые подходы.

PE>Если ты силен в теории оптических сетей — милости просим, будем рады услышать мнения по дизайну модели.


Оптических? Вряд ли. Но не думаю что граф от этого станет другим.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[29]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.03.04 19:08
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Загляни а серилизацию. Там аккурит такой случай.


PE>http://www.rsdn.ru/Forum/Message.aspx?mid=546331&amp;only=1
Автор: Plutonia Experiment
Дата: 20.02.04


Если бы вы меня спросли как с эитм быть, я бы ответил — делайте собственный фрэймворк сериализации и не возитесь с этим. Или ждите видби и оркас. Там обещали разогнать сериализацию.

Кстит, если хочешь сделай тест демонстрирующий тормоза, а я прогоню его на видби.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 08:06
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я как честный линуксоид отвергаю все инсинуации.


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


VD>Алгоритмы там самые обыкновенные. Большое же приложение просто не получится перенести на стлько язяков без ошибок и за разумное время. Если только авто-генирилкой воспользоваться...


Можно попробовать хотя бы преобразование фурье набомбить.
Re[34]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 08:13
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>Этого, мягко говоря, слишком много. Если есть темплейты, как на C++, то необходимо только класс и валидатор. Кроме того есть еще много вспомогатеьных классов, которые чтото кешируют(атрибуты, суррогаты, рефлексию и тд.). Генерировать код не представляет возможным, ибо неясно, как его отлаживать при внесении изменений в модель.


VD>Согласен, неудобно. Но скрость то тут причем? А над удобством мы уже рабьотаем: http://rsdn.ru/?article/rsharp/rsharp.xml
Автор(ы): Чистяков Влад (VladD2)
Дата: 28.01.2004


Неудбоно — с этим можно мириться, если проект небольшой.
На данный момент у нас 12 мегов шарпового кода. Минус комментарии, заголовки получтся 8.
В этом коде дублирование очень неслабое.

А что бы отказаться от дублирования пришлось подключить рефлексию. Для ускорения пришлось писать кеши для всего — аттрибуты, проперти, имена методов и тд.
А вот как ускорит создани делегатов неизвестно. Это занимает ровно половину времени десерилизации. Колбек интерфейсы влекут массу геморроя за собой. Усложнять не хотелось бы.
С десекрилизацией проще, но тогда будет с серилизацией проблемы — это увеличит кличество ссылок на объект, что повлечет усложнение суррогатов и создание излишнебольшого количества WriteObjectInfo.
Re[13]: C++ versus C#
От: Аноним  
Дата: 03.03.04 08:14
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

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


VD>>Я как честный линуксоид отвергаю все инсинуации.


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


VD>>Алгоритмы там самые обыкновенные. Большое же приложение просто не получится перенести на стлько язяков без ошибок и за разумное время. Если только авто-генирилкой воспользоваться...


PE>Можно попробовать хотя бы преобразование фурье набомбить.


Во...Хорошее предложение
Re[34]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 08:25
Оценка:
Здравствуйте, 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.
Re[32]: C++ versus C#
От: Kluev  
Дата: 03.03.04 08:53
Оценка:
Здравствуйте, VladD2, Вы писали:

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


K>>Когда задача очень большая, то и хип нам не друг.

VD>И есть документальное подтверждение на которое можно дать ссылку?
Пжста: http://qform3d.com/index.php?lang=ru
Вся работа с памятью сделана ручками, ибо не хватает ее родимой. Все 1.5 гига которые можно реально урвать на процесс расписаны и поделены. Плюс решатель в отдельном процессе 800МБ кушает.

K>> В таких случаях делается пул и хип и ГЦ остаются далеко позади.

VD>Да качественный ЖЦ и есть по сути пул.
Пул он при любых условиях пул. А ГЦ с какогото момента уже не пул, а проклятье.

K>> Никакой ГЦ не сможет работать быстрее чем пул.

VD>Согласен, но велика ли разница? И так ли часто ты пользуешся пулом и другими тонкими оптимизациями?

static mem_mgr<CNode,QMemTraits>    CNode_mm;

void* CNode::operator new( size_t sz ) {
    return CNode_mm.alloc();
}

void CNode::operator delete( void *p ) {
    CNode_mm.free( p );
}

дальше продолжать?

VD>Удаляется... если памяти нехватает и если на объект нет ссылок. А если хватает, то ради чего его удалять? Чтобы процессор занять?

А если не хватает?

VD>Код прикладной писать. А производительность ЖЦ проблемы МС и Сана. Если уж очень нужно, то в дотнете можно пользоваться структурами и хранить их в массиве. Считай тот же пул.

Это наверное, шутка?

K>> Наверное на С++ переписывать будем


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

А если эти фрагменты 80% кода. Можно конечно остальные 20 (ГУЙ и прочее) на НЕТ перевести, но какой смысл? Я не вижу.

K>>Представь что программа на каждой итерации создает и освобождает ~200К обьектов.

VD>Это очень выгодный для ЖЦ сценарий. Дон Бокс даже демонстрировал приемущества ЖЦ над хипом С++ создавайя в цикле объект и уничтожая его.

То что показал бокс — это какая-то пародия на тест. Могу написать реальный на котором ГЦ заткнется. А С++ будет летать.

VD>В ЖЦ есть специальные оптимизации на такой случай. Все эти объекты попадут в первое поколение и будут очень эффективно освобождены. Причем тогда когда процессор будет свободен, ане во время алгоритма.

Это когда же он будет свободен если алгоритм несколько дней работает?

VD>Да и все разговоры о пуле — это теория. На практике осннвные массы таких фич не используют. И выходит не быстрее чем с ЖЦ.

Для кого-то теория, а для меня обычная повседневность жизни. А фичи эти не используют пока все устраивает. А как только появляется узкое место, то прикрутить пул пустяковое дело. Тогда все начинает летать. Что и видно невооруженным глазом.

VD>. А потом, когда народ поймет, что нет особой разницы все большешие и большие части будут дописываться/переписываться на дотнетных языках.


А если нет особой разницы то зачем куда-то переходить? Только ради ГУЯ? А во всем остальном иметь мучения.

З.Ы. Кстати еще про пул. (Исходник здесь: http://rsdn.ru/File/16157/mem_mgr.h)
Операция выделения:

    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();
    }

удаление:
    void free_( void *p ) {
        block *pb = (block*)p;
        chunk *c = (chunk*)((size_t)p & (size_t)chunk_mask_);
        pb->next = c->free;
        c->free = pb;
        c->used_n--;
    }


Ну и какой ГЦ сможет с этим потягатся?
Re[30]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 08:55
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>> Придется без них изобретать дополнительный геморрой.


VD>Интерфейсы?


И это тоже. Но дженерик подход дается большим оверхедом или маленьким рефлекшном.
Только модель данных занимает 7 мегов в 700 файлах. Комментариев правда довольно много.
Классов очень много. Интерфейсов еще больше. Вот такие дела.

VD>Это не так. ХМЛ-форматер работает быстрее. Если для вас сериализация критична по времени, то стоит вообще сделать свой фрэймворк по этому поводу. В отличии от плюсов для этого вдотнете все есть.


Быстрее, но для графа он неприменим.

PE>>Распространение эвента занимает существенное время. Конкатенация строк выполняется гораздо быстрее. Кроме того, некоторые базовые механизмы приходится делать с использованием рефлекшна.

VD>Ну, так ты сам знаешь чего не надо делать. Остается только сделать как надо используя быстрые подходы.

Тогда это копипейст и размножение классов.

PE>>Если ты силен в теории оптических сетей — милости просим, будем рады услышать мнения по дизайну модели.


VD>Оптических? Вряд ли. Но не думаю что граф от этого станет другим.


Просто прочувствй масштаб. Тот граф о котором говорят в книгах, имеет два типа объекта — вершина и ребро. Иногда еще связка между ними. У нас есть еще подграфы различные, различные типы вершин, ребер и тд. Всего около 600 разновидностей. И это толкьо основные классы. Еще сотня или две вспомогательных и тд.
Re[30]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 08:56
Оценка:
Здравствуйте, VladD2, Вы писали:

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


PE>>Можно, никто не спорит, вопрос в том, как именно. Дяди за МС по нашему поводу пока ничего не отвечают. Даже общих рекомендаций дать не могут.


VD>А профайлер по этому поводу что говорит?



Routine Name    Time    Time with Children    Shared Time    Hit Count
DatasetStorageEngine::Load    0.00665421125    18.7413820525    0.0355054458169608    36
ProductLibraryManager::LoadProdLibWorker    0    17.78354583875    0    1
ProductLibDataSetPersist::DsLoad    0.00084167625    16.797909685    0.00501060111515893    1
DataSetLoader::Load    0.00016143625    16.3967278325    0.000984563820593623    1
TabInfo::Load    1.44434606875    16.38647400125    8.81425783630952    77
<Garbage Collector>    11.63491199375    11.63491199375    100    308
<JIT Compiler>    11.48328216    11.485244375    99.9829153395789    13864
ZipStorageEngine::Load    3.43084997875    8.962737435    38.2790414606182    5
PersistManager::Load    6.76625E-6    8.9577977525    7.55347484610448E-5    4
PropInfo::Load    1.00993600125    8.8353232525    11.430662720396    59387
DocumentManager::GetNetworkObject    3.855E-6    8.7928121725    4.38426287787282E-5    2
ValidatableEventSource::SetValidatableProperty    0.32878773    7.88257587    4.1710696531488    43581
EventSourceObject::GetPropertyDescriptionInternal    0.10383751375    7.5208579025    1.3806604924085    87539
EventSourceObject::BuildPropertyDescriptionMap    6.34245147625    7.469254285    84.9141190572012    15229
EventSourceObject::GetPropertyDescriptionMapInternal    0.0282405075    7.4341745525    0.379874151468547    88041
IndexableNamedObject::set_Name    0.1251015475    7.386138655    1.69373407870313    12125
EventSourceObject::GetPropertyDescription    0.0155469175    6.36041299    0.244432516008681    62998
AppController::RunWizard    0.00045296125    6.18196760125    0.00732713723553664    1
ScriptManager::ExecuteFile    0.00122776    6.17574920875    0.0198803409675456    1
ScriptManager::ExecuteString    3.77125E-5    6.16964905875    0.00061125843043722    1
SAXEngine::VPI.NC.Scripting.IScriptEngine.Execute    1.365692915    6.1415065075    22.2370995346535    1
DocumentManager::SaveDocument    6.206E-5    5.70805727375    0.00108723506131235    1
DocumentManager::Save    0.00057522625    5.69897192    0.0100935091113767    1
ZipStorageEngine::Store    2.32114413375    4.8816617725    47.548237504404    6
PersistManager::Store    3.919625E-5    4.881230335    0.00080299939379935    4
DocumentManager::OpenDocument    0.05199691375    3.13453559625    1.65883947249495    1
DocumentManager::OpenDoc    0.00052821    2.9891938675    0.017670650463423    1
BaseCollection::.ctor    0.000103765    2.0311321375    0.00510872720116172    7892
ReadOnlyBaseCollection::.ctor    0.011396135    2.027203835    0.56216029208528    7892
Re[30]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 08:59
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>http://www.rsdn.ru/Forum/Message.aspx?mid=546331&amp;only=1
Автор: Plutonia Experiment
Дата: 20.02.04


VD>Если бы вы меня спросли как с эитм быть, я бы ответил — делайте собственный фрэймворк сериализации и не возитесь с этим. Или ждите видби и оркас. Там обещали разогнать сериализацию.


Это в планах, но на это нужно много времени.

VD>Кстит, если хочешь сделай тест демонстрирующий тормоза, а я прогоню его на видби.


Мне придется половину проекта выдрать. Все маленькие летают по сравнению с теми, что побольше.
Re[30]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 09:10
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>Можно, никто не спорит, вопрос в том, как именно. Дяди за МС по нашему поводу пока ничего не отвечают. Даже общих рекомендаций дать не могут.


VD>А профайлер по этому поводу что говорит?


На загрузке тормоза в CreateDelegate и RaizeDeserilizationEvent.
На сохранение — создается в разы больше WriteObjectInfo чем это надо.
Далее — SerilizationInfo.AddValue подтормаживает.

Я думаю, что нормальный путь — выдрать сериалайзер из ротора и кой какие пместа оптимизировать. Но неясно, как это толкнуть в обиход. Это есть нарушение.
А нам чу что придется написать примерно такой же форматтер.
Re[13]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.03.04 11:36
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Можно попробовать хотя бы преобразование фурье набомбить.


Честно говоря преобразование фурье лично меня волнует мало, поскольку последние лет пять ничем похожим заниматься не приходилось, а когда приходилось то алгоритмы эти реализовывались в железке.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[31]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.03.04 11:44
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>В какие акселераторы ? Туда зашивают только то, что хорошо разжевано, канонизировано и стандартизировано. Окромя этого есть много алгоритмо оработки изображений. Распознавание например. А с оработкой звука как ?


FPGA тебя спасет
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[14]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 11:47
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Честно говоря преобразование фурье лично меня волнует мало, поскольку последние лет пять ничем похожим заниматься не приходилось, а когда приходилось то алгоритмы эти реализовывались в железке.


Послушаешь тебя и Влада — все алгоритмы в железе...Интересно, как у меня работают проги звуковые, еси стоит только кодек AC97 ?
Не пойму, чем мои знакомые прогреры-звукари занимаются — http://audio4fun.com/.
Все ведь в железе. Наверное в инсталятор входит и звуковуха мега-профессиональная.
Качаешь из инета, а при инсталяции программно втыкается в PCI слот.
А на ноутуке твоем много железа с аппаратным преоразованием того же фурье ?

Тогда питч-шифт заимплементи, если фурье не нравится.
Re[32]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 11:50
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>В какие акселераторы ? Туда зашивают только то, что хорошо разжевано, канонизировано и стандартизировано. Окромя этого есть много алгоритмо оработки изображений. Распознавание например. А с оработкой звука как ?


AVK>FPGA тебя спасет


Да понятно. А Саундфорджем или Диаммондом от audio4fun он тоже идет ?
Re[32]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 11:53
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>С вашего позволения:


Спасибо, а я и не догадался отформатировать.

Жирным отмечены точки, которые невозможно оптимизировать в силу некоторых особенностей.
SetValidatableProperty — автоматическая валидация. Тут рефлексия.
GetPropertyDescriptionMapInternal — создаются тучи делегатов.
set_Name — имя объекта должно быть уникальным, следовательно нужно сообщеть буде это не так.


S>
S>Routine Name                                         Time           Time with Children  Shared Time          Hit Count

S>DatasetStorageEngine::Load                           0.00665421125  18.7413820525       0.0355054458169608      36
S>ProductLibraryManager::LoadProdLibWorker             0              17.78354583875      0                        1
S>ProductLibDataSetPersist::DsLoad                     0.00084167625  16.797909685        0.00501060111515893      1
S>DataSetLoader::Load                                  0.00016143625  16.3967278325       0.000984563820593623     1
S>TabInfo::Load                                        1.44434606875  16.38647400125      8.81425783630952        77

S><Garbage Collector>                                 11.63491199375  11.63491199375    100                      308
S><JIT Compiler>                                      11.48328216     11.485244375       99.9829153395789      13864
S>ZipStorageEngine::Load                               3.43084997875   8.962737435       38.2790414606182      5
S>PersistManager::Load                                 6.76625E-6      8.9577977525       7.55347484610448E-5  4
S>PropInfo::Load                                       1.00993600125   8.8353232525      11.430662720396       59387
S>DocumentManager::GetNetworkObject                    3.855E-6        8.7928121725       4.38426287787282E-5  2
S>ValidatableEventSource::SetValidatableProperty       0.32878773      7.88257587         4.1710696531488      43581
S>EventSourceObject::GetPropertyDescriptionInternal    0.10383751375   7.5208579025       1.3806604924085      87539
S>EventSourceObject::BuildPropertyDescriptionMap       6.34245147625   7.469254285       84.9141190572012      15229
S>EventSourceObject::GetPropertyDescriptionMapInternal 0.0282405075    7.4341745525       0.379874151468547    88041
S>IndexableNamedObject::set_Name                       0.1251015475    7.386138655        1.69373407870313     12125
S>EventSourceObject::GetPropertyDescription            0.0155469175    6.36041299         0.244432516008681    62998
S>AppController::RunWizard                             0.00045296125   6.18196760125      0.00732713723553664      1
S>ScriptManager::ExecuteFile                           0.00122776      6.17574920875      0.0198803409675456       1
S>ScriptManager::ExecuteString                         3.77125E-5      6.16964905875      0.00061125843043722      1
S>SAXEngine::VPI.NC.Scripting.IScriptEngine.Execute    1.365692915     6.1415065075      22.2370995346535          1
S>DocumentManager::SaveDocument                        6.206E-5        5.70805727375      0.00108723506131235      1
S>DocumentManager::Save                                0.00057522625   5.69897192         0.0100935091113767       1
S>ZipStorageEngine::Store                              2.32114413375   4.8816617725      47.548237504404           6
S>PersistManager::Store                                3.919625E-5     4.881230335        0.00080299939379935      4
S>DocumentManager::OpenDocument                        0.05199691375   3.13453559625      1.65883947249495         1
S>DocumentManager::OpenDoc                             0.00052821      2.9891938675       0.017670650463423        1
S>BaseCollection::.ctor                                0.000103765     2.0311321375       0.00510872720116172   7892
S>ReadOnlyBaseCollection::.ctor                        0.011396135     2.027203835        0.56216029208528      7892
S>
Re[32]: C++ versus C#
От: naje  
Дата: 03.03.04 11:58
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Plutonia Experiment, Вы писали:


PE>>В какие акселераторы ? Туда зашивают только то, что хорошо разжевано, канонизировано и стандартизировано. Окромя этого есть много алгоритмо оработки изображений. Распознавание например. А с оработкой звука как ?


AVK>FPGA тебя спасет


HandleC, SystemC
в нашей конторе железки разрабатываются на С++(не HandleC, не SystemC) со спец. фреймворком, а потом с помощью одного же кода всё тестируется, генерится синтезабельный vhdl и програмки для верефикации уже готовых девайсов (код пишется один раз), на С# такого фреймворка сделать нельзя
так что тут аргумент в пользу С++
Re[33]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.03.04 12:06
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Да понятно. А Саундфорджем или Диаммондом от audio4fun он тоже идет ?


Обычно наоборот — дивайс идет в комплекте с ними.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[33]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 12:06
Оценка:
Здравствуйте, naje, Вы писали:

N>HandleC, SystemC

N>в нашей конторе железки разрабатываются на С++(не HandleC, не SystemC) со спец. фреймворком, а потом с помощью одного же кода всё тестируется, генерится синтезабельный vhdl и програмки для верефикации уже готовых девайсов (код пишется один раз), на С# такого фреймворка сделать нельзя
N>так что тут аргумент в пользу С++

Фремворк на шарпе создать еще проще. НО ! В программах обработки звука для простых обывателей никогда не было, нет и никогда не бует аппаратных алгоритмов. Продвинутый программный алгоритм всегда будет раотать быстрее железа. Фурье — довольно меденный агоритм.
Применения в ПО его избегают именно из за тормознутости. Можно быстрее — но больше памяти сожрешь. А вот в железо фурие закатать — проще не придумаешь. Но не всегда можно использовать аппаратные воможности. Для вывода звука на колонки можно кое что впихнуть в звуковуху.
Но чтото я ни разу не видел в продаже аппратный ужиматель(USB или PCI или PCMCIA) в МП3, ОГГ к примеру для моего компутера. И не просто ужиматели, а чтобы можно было гибко настраивать, психоаккустику менять и тд. и тд.
Так что всякие FPGA можно сразу засунуть в одно место.
Re[34]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 12:11
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Да понятно. А Саундфорджем или Диаммондом от audio4fun он тоже идет ?


AVK>Обычно наоборот — дивайс идет в комплекте с ними.


Это понятно. Но как это чуду раотает с кодеком AC97 ? Не программно ли ?
обрабатывать кусок файла в сто мегов очень накладно на железяке. Дорого это. А недавно и вовсе невозможно было.

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

Все это есть в железе ? Все это делается именно программно и не просто программно, а на С++. Иногда еще ассемблер подключается для особохитрых операций.
Re[33]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.03.04 12:16
Оценка:
Здравствуйте, naje, Вы писали:

N>так что тут аргумент в пользу С++


Нет, это аргумент в пользу выбора подходящего решения.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[15]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.03.04 12:16
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Не пойму, чем мои знакомые прогреры-звукари занимаются — http://audio4fun.com/.


Рынок только у твоих знакомых ну очень маленький.

PE>А на ноутуке твоем много железа с аппаратным преоразованием того же фурье ?


Нет. А нафига оно мне?
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[34]: C++ versus C#
От: naje  
Дата: 03.03.04 12:22
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

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



PE> Фремворк на шарпе создать еще проще. НО !


такой как тут невозможно просто на шарпе, нужно разрабатывать ещё один язык для нета, впринципе одно из решений

PE> В программах обработки звука для простых обывателей никогда не было, нет и никогда не бует аппаратных алгоритмов. Продвинутый программный алгоритм всегда будет раотать быстрее железа. Фурье — довольно меденный агоритм.

что значит продвинутый?
PE>Применения в ПО его избегают именно из за тормознутости. Можно быстрее — но больше памяти сожрешь. А вот в железо фурие закатать — проще не придумаешь. Но не всегда можно использовать аппаратные воможности. Для вывода звука на колонки можно кое что впихнуть в звуковуху.
PE>Но чтото я ни разу не видел в продаже аппратный ужиматель(USB или PCI или PCMCIA) в МП3, ОГГ к примеру для моего компутера. И не просто ужиматели, а чтобы можно было гибко настраивать, психоаккустику менять и тд. и тд.

кодеков G.7xx немеренно всяких, и вабще DSP'эшек выполненных в железе (не на DSP контроллерах) немеренно всяких, и в последнее время всё больше появляется

PE>Так что всякие FPGA можно сразу засунуть в одно место.


это зря, гораздо дешевле и эффективнее поставить в какой-нибудь голосовой сервер(например) парочку fpga'шников (по 200 дол+стоимость шины), чем штуки 4 (а скорее всего больше) лишних процессора(+шина гораздо больше стоить будет чем для fpga)
Re[35]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.03.04 12:36
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Это понятно. Но как это чуду раотает с кодеком AC97 ? Не программно ли ?

PE>обрабатывать кусок файла в сто мегов очень накладно на железяке. Дорого это.

Вот потому и говорю что FPGA рулит. Универсальная и недорогая железка. Менее универсально для обработки звука я бы использовал DSP. Стоимость — единицы долларов.

PE>Пример — из песни выдрать вокал, или шум убрать, или эквалайзить некисло, или психоаккустику наложить, или вока этот самый заменить на другой.

PE>Громкость сменить, нормализировать, клики поубирать, тишину вырезать, искажения выровнять.

PE>Все это есть в железе ?


Да.

PE> Все это делается именно программно и не просто программно, а на С++.


Знаешь, эти задачки на АС97 ничто иное как баловство. Обсуждать промышленные платформы в аспекте баловства неинтересно.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[16]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 13:33
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Рынок только у твоих знакомых ну очень маленький.

PE>>А на ноутуке твоем много железа с аппаратным преоразованием того же фурье ?

AVK>Нет. А нафига оно мне?


Запусти SoundForge или VCS Diamond и убедись, что весь звук обрабатывается программно.

Обраотка звука — это не спецэффекты, которые в курточку засунуть можно. Это математика
Re[16]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 13:36
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Не пойму, чем мои знакомые прогреры-звукари занимаются — http://audio4fun.com/.

AVK>Рынок только у твоих знакомых ну очень маленький.

Т.е. ты винампоп не пользуешься ? Филмы не смотришь ? Эквалайзер в винампе не крутишь ?
И слушаешь только вавки, а не мп3 и не огг ?
Re[36]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 13:40
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>На данный момент у нас 12 мегов шарпового кода. Минус комментарии, заголовки получтся 8.


AVK>Заголовки в шарповом коде это что то интересное.


Очень смешно, рядовой Шуник. Каждый файл имеет в коментариях описание, список авторов, копирайт и тд и тд.

PE>>А вот как ускорит создани делегатов неизвестно.

AVK>Почему? Заменить их на интерфейсы.
Тогда в другом месте тормоза.

PE>>Колбек интерфейсы влекут массу геморроя за собой.

AVK>Например?

Все это нужно писать руками. Объект может быть подписан на хрензнает сколько эвентов жругих объектов. Придется писать весь этот механизм.
Всего 7 типов эвентов. Объект может быть подписан в среднем на 20...30 других объектов и коллекций. Если делать колбеками, то ...
Re[37]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.03.04 13:56
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>>>А вот как ускорит создани делегатов неизвестно.

AVK>>Почему? Заменить их на интерфейсы.
PE>Тогда в другом месте тормоза.

Приниматься за оптимизацию другого места. Тормоза то будут всегда, но приложение твое будет работать все быстрее и быстрее.

PE>>>Колбек интерфейсы влекут массу геморроя за собой.

AVK>>Например?

PE>Все это нужно писать руками. Объект может быть подписан на хрензнает сколько эвентов жругих объектов. Придется писать весь этот механизм.


Не, ну ты сам выбрал схему на эвентах, не поинтересовавшись производительностью делегатов.

PE>Всего 7 типов эвентов. Объект может быть подписан в среднем на 20...30 других объектов и коллекций. Если делать колбеками, то ...


То что? Чем принципиально отличается реализация интерфейса от написания обработчика?
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[36]: C++ versus C#
От: Sergey Россия  
Дата: 03.03.04 14:14
Оценка:
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 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[37]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.03.04 14:30
Оценка:
Здравствуйте, Sergey, Вы писали:

A>> Вот потому и говорю что FPGA рулит. Универсальная и недорогая железка.


S>А еще универсальней — С++


Тока результат хуже.

A>> Менее универсально для обработки звука я бы использовал DSP. Стоимость -

A>> единицы долларов.

S>У весьма тормозных


Весьма тормозные спокойно уделают на задачках обработки звука дорогущие ЦП.

S> в партии от 10000 штук . Прибавь стоимость разработки интерфейса с компутером, PCB, сборки железяки, написания драйверов и прочего, включая доставку железяки енд-юзеру. Да и цена "вхождения" в разработку будет весьма не малая.


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

A>> Да.


S>Наверное, кто-то полагает, что FPGA программировать сильно проще, чем на плюсах


Ох как у нас любят считать себя умнее других. Я этим занимался, так что можешь не гримасничать.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[38]: C++ versus C#
От: Sergey Россия  
Дата: 03.03.04 15:03
Оценка:
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 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[35]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 15:20
Оценка:
Здравствуйте, naje, Вы писали:

PE>>Так что всякие FPGA можно сразу засунуть в одно место.


N>это зря, гораздо дешевле и эффективнее поставить в какой-нибудь голосовой сервер(например) парочку fpga'шников (по 200 дол+стоимость шины), чем штуки 4 (а скорее всего больше) лишних процессора(+шина гораздо больше стоить будет чем для fpga)


Интересно. Купил я себе комп за 200 рублей, захотел МП3 послушать. Где мне найти кодек для этого ? А если компакт диск ужать ? А если DVD ужать ?
Девайсы покупать ваши ?
Все делается программно и на С++ или Паскале.
Re[36]: C++ versus C#
От: naje  
Дата: 03.03.04 15:31
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

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


N>>это зря, гораздо дешевле и эффективнее поставить в какой-нибудь голосовой сервер(например) парочку fpga'шников (по 200 дол+стоимость шины), чем штуки 4 (а скорее всего больше) лишних процессора(+шина гораздо больше стоить будет чем для fpga)


PE>Интересно. Купил я себе комп за 200 рублей, захотел МП3 послушать. Где мне найти кодек для этого ? А если компакт диск ужать ? А если DVD ужать ?

PE>Девайсы покупать ваши ?
PE>Все делается программно и на С++ или Паскале.

я тебе про домашнее использование говорил?
ты себе домой голосовой сервер покупать будешь, тут речь идёт не о 200 р, а о десятках-сотнях тысяч долларов?

ps лично у меня есть доска с fpga'шничком дома, для игр, обошлась мне порядка 300 долларов
Re[36]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 15:38
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Пример — из песни выдрать вокал, или шум убрать, или эквалайзить некисло, или психоаккустику наложить, или вока этот самый заменить на другой.

PE>>Громкость сменить, нормализировать, клики поубирать, тишину вырезать, искажения выровнять.

PE>>Все это есть в железе ?


AVK>Да.

Ну ну. Какая именно звуковая карта жмет звук в ОГГ и МП3 И ВМА.
Re[31]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.04 15:51
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>И это тоже. Но дженерик подход дается большим оверхедом или маленьким рефлекшном.

PE>Только модель данных занимает 7 мегов в 700 файлах. Комментариев правда довольно много.
PE>Классов очень много. Интерфейсов еще больше. Вот такие дела.

Вы их генерируете что ли?

PE>Быстрее, но для графа он неприменим.


Ну, так пишите свою. Других выходов нет.

PE>Тогда это копипейст и размножение классов.


Почему? Можно и на ОО-проехаться.

PE>Просто прочувствй масштаб. Тот граф о котором говорят в книгах, имеет два типа объекта — вершина и ребро. Иногда еще связка между ними. У нас есть еще подграфы различные, различные типы вершин, ребер и тд. Всего около 600 разновидностей. И это толкьо основные классы. Еще сотня или две вспомогательных и тд.


Ну, незнаю. Въезжатьв вашу специфику — это уже перебор для меня.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[38]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 15:53
Оценка:
Здравствуйте, 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 каждой проперти нужно освобождать старый объект, подписываться на новый. Причем на все эвенты !

Мы юзаем эвенты и рефлексию. НО ! всеравно текста, который просто размножался копипейстом(два типа коллекций на каждый объект, валидатор, интерфейс основной) море !!!
Если генерировать код, то возникают проблемы с отладкой. Ошибки из компайлтайм переносятся в рантайм.
Re[32]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 15:59
Оценка:
Здравствуйте, VladD2, Вы писали:

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


PE>>И это тоже. Но дженерик подход дается большим оверхедом или маленьким рефлекшном.

PE>>Только модель данных занимает 7 мегов в 700 файлах. Комментариев правда довольно много.
PE>>Классов очень много. Интерфейсов еще больше. Вот такие дела.

VD>Вы их генерируете что ли?


А как еще ? Из УМЛ в C# и вперед.

PE>>Тогда это копипейст и размножение классов.

VD>Почему? Можно и на ОО-проехаться.

Проехались уже.

PE>>Просто прочувствй масштаб. Тот граф о котором говорят в книгах, имеет два типа объекта — вершина и ребро. Иногда еще связка между ними. У нас есть еще подграфы различные, различные типы вершин, ребер и тд. Всего около 600 разновидностей. И это толкьо основные классы. Еще сотня или две вспомогательных и тд.

VD>Ну, незнаю. Въезжатьв вашу специфику — это уже перебор для меня.

С этого нужно было и начинать А то завеи разговор про панацею.
Re[37]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 16:00
Оценка:
Здравствуйте, naje, Вы писали:

N>я тебе про домашнее использование говорил?

N>ты себе домой голосовой сервер покупать будешь, тут речь идёт не о 200 р, а о десятках-сотнях тысяч долларов?

Мы говорим про массовый рынок.

N>ps лично у меня есть доска с fpga'шничком дома, для игр, обошлась мне порядка 300 долларов
Re[37]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.03.04 16:01
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>Да.

PE>Ну ну. Какая именно звуковая карта жмет звук в ОГГ и МП3 И ВМА.

Почему звуковая? Покупай платку с DSP и вперед
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[38]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 16:04
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Ну ну. Какая именно звуковая карта жмет звук в ОГГ и МП3 И ВМА.


AVK>Почему звуковая? Покупай платку с DSP и вперед


Т.е. у тех, у кого нет DSP, не получится жать звук ? Как же они жмут то ?
На счет ОГГ я сумлеваюсь — его плейерах железных то по большому счету нет.
Многие задачи обработки звука требуют охрененного количества ресурсов.
Никакое железо тут не поможет.

Посему я предлагаю сравнить быстродейсвие на самых популярных ужималках.
Кстати, а рары, зипы, тары — тоже аппаратно жмут ?
Re[38]: C++ versus C#
От: naje  
Дата: 03.03.04 16:05
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

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


N>>я тебе про домашнее использование говорил?

N>>ты себе домой голосовой сервер покупать будешь, тут речь идёт не о 200 р, а о десятках-сотнях тысяч долларов?

PE>Мы говорим про массовый рынок.


а кто где это оговорил?
вобще обычно такая штучка ставится в средненьких офисах (~1000 чел), не такой уж и редкий случай
массовый рынок винампами не ограничивается
Re[18]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 16:10
Оценка:
Здравствуйте, naje, Вы писали:

N>профессиональное создание музыки это не SoundForge или VCS Diamond, там как-раз много чего апаратного (как впринципе и профессиональное слушанье )


Почти все пользоватли компьютера используют проигрыватели МП3. Разве это аппаратно ?

А программы для оработки звука после грабления — например изменение психоаккустической модели на компактдиске. Это всякие расширения стереобазы и тд. и тд. ТОже аппаратно делается ?
Это всегда делается программо. На массовом рынке рулит ПО! Будь иначе, рынка по вооще не было бы.
Re[39]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 16:13
Оценка:
Здравствуйте, naje, Вы писали:

N>а кто где это оговорил?

N>вобще обычно такая штучка ставится в средненьких офисах (~1000 чел), не такой уж и редкий случай
N>массовый рынок винампами не ограничивается

Винам — конечно нет. Но вообще очень много программ имеют отношение к обработке звука. Именно программно. Того железа, о которым вы говорите с AVK, я не нашел вообще.
Ну нет кодеров в MP3 массовых. Кое где используется, но я ы не сказал, что массово. Этот формат постоянно улучшает психоаккустику. В железе старье постоянно удет. А пока прошиву поменяешь, глядишь надо новой ждать, потому что уже улучшили снова.
Так что на компе все делается программно.

Вот я и предлагаю сравнить быстродейсвие нативной ужималки и менеджед.
Разница удет хорошо замента уже на преоразовании фурье.
Re[19]: C++ versus C#
От: naje  
Дата: 03.03.04 16:17
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

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


N>>профессиональное создание музыки это не SoundForge или VCS Diamond, там как-раз много чего апаратного (как впринципе и профессиональное слушанье )


PE>Почти все пользоватли компьютера используют проигрыватели МП3. Разве это аппаратно ?


PE>А программы для оработки звука после грабления — например изменение психоаккустической модели на компактдиске. Это всякие расширения стереобазы и тд. и тд. ТОже аппаратно делается ?

PE>Это всегда делается программо. На массовом рынке рулит ПО! Будь иначе, рынка по вооще не было бы.

а концертное, клубное оборудование, скажи что это не массовый рынок, пусть такого обарудования меньше надо, но винам бесплатный, а оно дорогое
мы сейчас разговариваем с точки зрения пользователей, или с точки зрения производителей, которые на этом деньги зарабатывают?
Re[20]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 16:25
Оценка:
Здравствуйте, naje, Вы писали:

N>а концертное, клубное оборудование, скажи что это не массовый рынок, пусть такого обарудования меньше надо, но винам бесплатный, а оно дорогое

N>мы сейчас разговариваем с точки зрения пользователей, или с точки зрения производителей, которые на этом деньги зарабатывают?

С точки зрения работающих экземпляров ПО или харда.
Если все пользователи жмут музыку, файло, видео аппаратно — нечего и сравнивать дотнет с нативом. Если это не так — есть смысл сравнить ыстродействие на одинаковых алгоритмах.
Re[39]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.03.04 16:31
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Реализовать нудно не просто интерфейс. Мне придется агрегировать реализацию интерфейса стольо раз, сколько объектов слушает объект.


Зачем? Сложно реализовать подобие мультикаст делегата для интерфейсов?

PE>Еще нужно писать механизм, который в COM реализуется с помощью

PE>IConnectionPointContainer/IConnectionPoint

Давай СОМ не будем приплетать, совершенно понятно что дотнет не лучший способ с ним взаимодействия.

PE>Выписывать такой код самоубийство.


Зачем выписывать? Вы же вроде генерите? Ну так и генерите наздоровье. Руками нужно будет только пару хелперов написать.

PE>Жирным я выделил то, что пишу с использованием делегатов и эвентов.

PE>Есть разница ?

Честно говоря чего то не вьехал что ты хотел показать. Зачем класс Event1?

PE>Но это не все. В методе set каждой проперти нужно освобождать старый объект, подписываться на новый. Причем на все эвенты !


Опять не понял. Эвент на самом деле просто приватное поле класса с двумя функциями для подписки и отписки. С использованием интерфейсов ты можешь сделать ровно тоже самое. Не так красиво как операторы +-=, но больше ничем не оличается. Просто вместо подписки определенного метода ты тем же классом реализуешь интерфейс и передаешь не делегата, а сам класс.

PE>Мы юзаем эвенты и рефлексию. НО ! всеравно текста, который просто размножался копипейстом(два типа коллекций на каждый объект, валидатор, интерфейс основной) море !!!


Значит что то не так. Причем явно не так.

PE>Если генерировать код, то возникают проблемы с отладкой. Ошибки из компайлтайм переносятся в рантайм.


Ну так генерировать надо тоже с умом, чтобы в рантайме они легко отлавливались. При наличии нормального стектрейса и соблюдении определенных правил ничего страшного в рантайм-ошибках нет.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[39]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 03.03.04 16:31
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>Почему звуковая? Покупай платку с DSP и вперед


PE>Т.е. у тех, у кого нет DSP, не получится жать звук ? Как же они жмут то ?


PE>На счет ОГГ я сумлеваюсь — его плейерах железных то по большому счету нет.

PE>Многие задачи обработки звука требуют охрененного количества ресурсов.
PE>Никакое железо тут не поможет.

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

PE>Кстати, а рары, зипы, тары — тоже аппаратно жмут ?


Ты часто рары и зипы пишешь? Я нет.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[40]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.03.04 16:54
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Зачем? Сложно реализовать подобие мультикаст делегата для интерфейсов?


Вот предложи свой вариант на C# без дженериков.


PE>>IConnectionPointContainer/IConnectionPoint

AVK>Давай СОМ не будем приплетать, совершенно понятно что дотнет не лучший способ с ним взаимодействия.
Дело не в COM а в спосое взаимодействии клиентов.

PE>>Выписывать такой код самоубийство.


AVK>Зачем выписывать? Вы же вроде генерите? Ну так и генерите наздоровье. Руками нужно будет только пару хелперов написать.


В том то и дело что генерим мы только коллекции. А тут придется писать еще и генератор наших классов.Хорошего в этом мало — генереный код периодически приходится перегенерировать, чтобы внести изменения.

PE>>Жирным я выделил то, что пишу с использованием делегатов и эвентов.

PE>>Есть разница ?

AVK>Честно говоря чего то не вьехал что ты хотел показать. Зачем класс Event1?


Класс, который реализует интерфейс обратной связи с другим объектом.
Для каждого члена класса нужно писать свою имплементацию интерфейса обратного вызова.


PE>>Но это не все. В методе set каждой проперти нужно освобождать старый объект, подписываться на новый. Причем на все эвенты !


AVK>Опять не понял. Эвент на самом деле просто приватное поле класса с двумя функциями для подписки и отписки. С использованием интерфейсов ты можешь сделать ровно тоже самое. Не так красиво как операторы +-=, но больше ничем не оличается. Просто вместо подписки определенного метода ты тем же классом реализуешь интерфейс и передаешь не делегата, а сам класс.


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


PE>>Мы юзаем эвенты и рефлексию. НО ! всеравно текста, который просто размножался копипейстом(два типа коллекций на каждый объект, валидатор, интерфейс основной) море !!!

AVK>Значит что то не так. Причем явно не так.

Конечно не так. Пролема в том, что нам навязали С#. Без дженериков никуда.


AVK>Ну так генерировать надо тоже с умом, чтобы в рантайме они легко отлавливались. При наличии нормального стектрейса и соблюдении определенных правил ничего страшного в рантайм-ошибках нет.

Легко на маленьгких прилах. А если алгоритм сутки работает ?
В любом случае перенос ошибок из компайлтайма в рантайм замедляет разработку.
Re[35]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.04 21:31
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

А нельзя вообще обойтись без кобэков?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[37]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.04 21:31
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Все это нужно писать руками. Объект может быть подписан на хрензнает сколько эвентов жругих объектов. Придется писать весь этот механизм.

PE>Всего 7 типов эвентов. Объект может быть подписан в среднем на 20...30 других объектов и коллекций. Если делать колбеками, то ...

Десериализация графа проблема вроде изученная. Делается на банальной хэштаблице. Вам вообще можно написать ручной механизм и бует все летать.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[39]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.04 21:31
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Еще нужно писать механизм, который в COM реализуется с помощью

PE>IConnectionPointContainer/IConnectionPoint

Не нужно. Не приплитай сюда еще и ком. Там борьба с ЭддРефами коих в дотнете нет.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.04 21:31
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

Короче, где-то на следующей недели будет готов парсер R#-а. Там и до генератора не долего. Думаю, с его помощью все что тебе нужно можно будет сделать влет.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.04 21:31
Оценка:
Здравствуйте, Kluev, Вы писали:

K>Пжста: http://qform3d.com/index.php?lang=ru


Ты по ссылке то ходил? Это по твоему подтверждение. Ну, тогда вот опровержение: 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)


Спасибо за просветление
Автор(ы): Чистяков Владислав
Дата: 26.11.2002


K>Ну и какой ГЦ сможет с этим потягатся?


Да в общем то грамотно написанный как раз должен смочь. Жаль у МС это с первого раза не удалось.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.04 22:10
Оценка:
Здравствуйте, 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.04 22:10
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

VD>>А профайлер по этому поводу что говорит?



PE>
PE>Routine Name    Time    Time with Children    Shared Time    Hit Count
PE>


В такой каше трудно разобраться.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.04 22:10
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Жирным отмечены точки, которые невозможно оптимизировать в силу некоторых особенностей.

PE>SetValidatableProperty — автоматическая валидация. Тут рефлексия.
PE>GetPropertyDescriptionMapInternal — создаются тучи делегатов.
PE>set_Name — имя объекта должно быть уникальным, следовательно нужно сообщеть буде это не так.

А что означают в конкретные колонки?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[31]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.04 22:10
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Я думаю, что нормальный путь — выдрать сериалайзер из ротора и кой какие пместа оптимизировать. Но неясно, как это толкнуть в обиход. Это есть нарушение.

PE>А нам чу что придется написать примерно такой же форматтер.

Это очень сложно. Он там на мертво врос.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.04 22:11
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

VD>>Вы их генерируете что ли?


PE>А как еще ? Из УМЛ в C# и вперед.


Да только генераторами можно зафигачить такое количество кода. При ручной реализации его на порядок меньше будет.

PE>С этого нужно было и начинать А то завеи разговор про панацею.


Да про панацею никто и не говорит. Но дать совет не зная внутренних проблем невозможно. А разбираться для этого еще с одной наукой — это крыза.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.03.04 22:11
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Можно попробовать хотя бы преобразование фурье набомбить.


А чем хуже вычисление точек из последнего float-теста?

Ну, да давай по приличнее реализацию (по переносимее), сделаем.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[41]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.03.04 09:37
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Звук тебя не интересует, математика тоже, видео туда же. Меня это интересует,


Осталось определится в процентном соотношении таких как я и ты

PE> я не буду пользваться винампом, который перепишут полностью на дотнете.


Ты чего то наверное не понял цель шустриков. Они не для пользователей, они для программистов.

AVK>>Ты часто рары и зипы пишешь? Я нет.


PE>С помощью раров и зипов меряется реальный перформанс процессоров.


И при чем тут перформанс процессора?
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[41]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.03.04 09:37
Оценка:
Здравствуйте, 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>В любом случае перенос ошибок из компайлтайма в рантайм замедляет разработку.


К счастью на шарпе не сильно.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[42]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.03.04 10:17
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>
AVK>public delegate SomeEventHandler(object sender, SomeEventArgs e);

AVK>public class EventProvider
AVK>{
AVK>}

AVK>public class EventConsumer
AVK>{
AVK>}
AVK>


AVK>Вариант с интерфейсом

AVK>
AVK>public interface ISomeEventHandler
AVK>{
AVK>    void Handle(object sender, SomeEventArgs e);
AVK>}

AVK>public class EventProvider
AVK>{
AVK>}

AVK>public class EventConsumer : ISomeEventHandler
AVK>{
AVK>}
AVK>


все это отлично. Только непонятно, что я буду делать вот в таком случае.
Я пишу так, как у нас.

class BaseClass
{
}

class Derived1 : BaseClass
{
public Derived2 Property1
{
get;
set { UnsuscribeSubscribeAndAssign("Property1",value); };
}

private Derived2 m_Property1=null;

void OnProperty1Disposing(EventArgs args);
void OnProperty1Disposed(EventArgs args);
void OnProperty1Changing(EventArgs args);
void OnProperty1Changed(EventArgs args);

...

// N = 1..60
public Derived2 PropertyN
{
get;
set { UnsuscribeSubscribeAndAssign("PropertyN",value); };
}

private Derived2 m_PropertyN=null;

void OnPropertyNDisposing(EventArgs args);
void OnPropertyNDisposed(EventArgs args);
void OnPropertyNPropertyChanging(EventArgs args);
void OnPropertyNPropertyChanged(EventArgs args);


public DerivedXXXCollection XXXs
{
get;
}

private DerivedXXXCollection m_XXXs;

void OnXXXsItemAdding(EventArgs args);
void OnXXXsItemAdded(EventArgs args);
void OnXXXsItemRemoving(EventArgs args);
void OnXXXsItemRemoved(EventArgs args);
...
}


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>К счастью на шарпе не сильно.

Что бы воспроивести ошибку может понадобиться писать скрипт на саксе ии руками кликать полчаса. Есть выход — винраннер подключить. Но для него тож скрипт нужен.
Re[42]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.03.04 10:23
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Звук тебя не интересует, математика тоже, видео туда же. Меня это интересует,

AVK>Осталось определится в процентном соотношении таких как я и ты
Звук и ужималки это то, с чем сталкиваются почти все пользователи к компьютера.
Видео — туда же. Математика — это, конечно, узкая область.


PE>> я не буду пользваться винампом, который перепишут полностью на дотнете.

AVK>Ты чего то наверное не понял цель шустриков. Они не для пользователей, они для программистов.

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

PE>>С помощью раров и зипов меряется реальный перформанс процессоров.

AVK>И при чем тут перформанс процессора?

При том, что алгоритмы реальные и работают повсеместно, в отличие он синтетических шустриков.
Re[43]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.03.04 10:40
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>>>Звук тебя не интересует, математика тоже, видео туда же. Меня это интересует,

AVK>>Осталось определится в процентном соотношении таких как я и ты
PE>Звук и ужималки это то, с чем сталкиваются почти все пользователи к компьютера.

А причем тут пользователи? Речь о программистах.

AVK>>Ты чего то наверное не понял цель шустриков. Они не для пользователей, они для программистов.


PE>Вот и хотелось бы узнать, есть ли разница в производительности двух прилаг, писаных на дотнете и нативных.


Компилятором оно определяется в последнюю очередь. Если интересна производительность конкретного софта то ее и надо сравнивать, а не компиляторы, на которых оно компилировалось.

PE> Ибо тормозное глюкало писать не хочется.


Т.е. какие то компиляторы всегда делают тормозное глюкало?

PE>>>С помощью раров и зипов меряется реальный перформанс процессоров.

AVK>>И при чем тут перформанс процессора?

PE>При том, что алгоритмы реальные и работают повсеместно,


Так алгоритмы или процессоры? Какое имеет отношение сравнение производительности процессоров к сравнению производительности компиляторов?
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[43]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.03.04 10:50
Оценка:
Здравствуйте, 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> Но для него тож скрипт нужен.


А вы как вобще отлаживаетесь? Или вы сразу без ошибок пишете?
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[44]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.03.04 11:19
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>>>Звук тебя не интересует, математика тоже, видео туда же. Меня это интересует,

AVK>>>Осталось определится в процентном соотношении таких как я и ты
PE>>Звук и ужималки это то, с чем сталкиваются почти все пользователи к компьютера.

AVK>А причем тут пользователи? Речь о программистах.


Т.е. пользователи сук и быдло и не могут интесеваться производительностью ПО за которое платят деньги ?
Программисты пишут не просто так, а для конкретных людей.


PE>>Вот и хотелось бы узнать, есть ли разница в производительности двух прилаг, писаных на дотнете и нативных.


AVK>Компилятором оно определяется в последнюю очередь. Если интересна производительность конкретного софта то ее и надо сравнивать, а не компиляторы, на которых оно компилировалось.


Вот я и хочу сравнить перформанс двух прилаг — нативной ужималки и такой же, но менеджед.
Мне дают диск на двадцать минут. Есть возможность взять прилу подешевле, но менеджед, или подороже, но нативную. Какой ужималкой я смогу ужать за 20 минут весь аудиодиск?

PE>> Ибо тормозное глюкало писать не хочется.

AVK>Т.е. какие то компиляторы всегда делают тормозное глюкало?

Конечно. Но не только компилеры. Среда тоже может "помочь".

PE>>При том, что алгоритмы реальные и работают повсеместно,


AVK>Так алгоритмы или процессоры? Какое имеет отношение сравнение производительности процессоров к сравнению производительности компиляторов?


Нужно перегнать DVD в MPEG4.
Ты платишь за время бабло — 3$ в час допустим.
И есть выбор в железе, в компилерах, в среде, в джите, если есть.
Задача — определить, на какой конфигурации можно получить минимальные временные затраты.

Вот и выбирай (P3, P4) (пямяти 256) (прага нативная, дотнетовская, жава)

1. Процессор кривой — время большое будет.
2. Среда кривая — время большое.
3. Компилер кривой — время большое.
4. Джит кривой — время большое.
Re[45]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.03.04 11:40
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>А причем тут пользователи? Речь о программистах.


PE>Т.е. пользователи сук и быдло


Я этого не говорил.

PE> и не могут интесеваться производительностью ПО


Может. Но шустрики не для него.

PE> за которое платят деньги ?


Пользователь платит деньги за компиляторы? Это что то новенькое.

AVK>>Компилятором оно определяется в последнюю очередь. Если интересна производительность конкретного софта то ее и надо сравнивать, а не компиляторы, на которых оно компилировалось.


PE>Вот я и хочу сравнить перформанс двух прилаг — нативной ужималки и такой же, но менеджед.

PE>Мне дают диск на двадцать минут. Есть возможность взять прилу подешевле, но менеджед, или подороже, но нативную.
PE> Какой ужималкой я смогу ужать за 20 минут весь аудиодиск?

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

PE>>> Ибо тормозное глюкало писать не хочется.

AVK>>Т.е. какие то компиляторы всегда делают тормозное глюкало?

PE>Конечно. Но не только компилеры. Среда тоже может "помочь".


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

AVK>>Так алгоритмы или процессоры? Какое имеет отношение сравнение производительности процессоров к сравнению производительности компиляторов?


PE>Нужно перегнать DVD в MPEG4.

PE>Ты платишь за время бабло — 3$ в час допустим.
PE>И есть выбор в железе, в компилерах, в среде, в джите, если есть.
PE>Задача — определить, на какой конфигурации можно получить минимальные временные затраты.

Так, понятно чем ты на работе в качестве программиста занимаешься.
Напоминаю в который уже раз — в шустриках никто не тестирует и не будет тестировать процессоры и прочее железо, а так же конкретный прикладной софт для обработки звука и видео. Там тестировали и тестируют компиляторы.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[46]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.03.04 11:55
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>не могут интесеваться производительностью ПО за которое платят деньги ?

AVK>Пользователь платит деньги за компиляторы? Это что то новенькое.

Компилятор влияет на производительность ПО. Так понятнее.
И не выдергивай слова из фразы.Это не к лицу модератору.

PE>>Вот я и хочу сравнить перформанс двух прилаг — нативной ужималки и такой же, но менеджед.

PE>>Мне дают диск на двадцать минут. Есть возможность взять прилу подешевле, но менеджед, или подороже, но нативную.
PE>> Какой ужималкой я смогу ужать за 20 минут весь аудиодиск?

AVK>Думается мне что реализация и алгоритмы в данной ситуации значительно важнее нежели использованные компиляторы. Ты вот навскидку, не гляда скажи — на каком компиляторе скомпилирован декодер винампа? Наверняка не ответишь. Я вот точно не знаю. Потому что мне пофигу. А уж среднестатистический пользователь просто не сможет на этот вопрос ответить.


Конечно. Но все пользуются именно винампом, потому, что он не такой тормозной, как многие его конкуренты.

PE>>>> Ибо тормозное глюкало писать не хочется.

AVK>>>Т.е. какие то компиляторы всегда делают тормозное глюкало?

Конечно. Это в ваших шустриках и написано, что одни компилеры дают шустрый код, другие тормозной.

AVK>Среда выполнения в смысле? Ну то есть на дотнете можно написать только тормозное глюкало, ты это хочешь сказать? Я твою мысль понял. Т.е. из ненависти к дотнету, на котором тебя заставляют писать глупые начальники ты очень хочешь добавитьтакой тест чтобы дотнет на нем выглядет как можно хуже. Так что ли?


Нет. Мне интересно, стоит ли браться за написание проги по звуку на дотнете или на нативном С++, если за нее заплатят деньги и при этом критичен перформанс.


PE>>Нужно перегнать DVD в MPEG4.
PE>>Ты платишь за время бабло — 3$ в час допустим.
PE>>И есть выбор в железе, в компилерах, в среде, в джите, если есть.
PE>>Задача — определить, на какой конфигурации можно получить минимальные временные затраты.

AVK>Напоминаю в который уже раз — в шустриках никто не тестирует и не будет тестировать процессоры и прочее железо, а так же конкретный прикладной софт для обработки звука и видео. Там тестировали и тестируют компиляторы.

Отлично. Сделаем по твоему. Процессоры одинаковые и железо одинаковое.
Осталось сравнить три продукта (нативный, дотнетовский, жавовский).
Re[44]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.03.04 11:57
Оценка:
Здравствуйте, 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>А вы как вобще отлаживаетесь? Или вы сразу без ошибок пишете?

Конечно отлаживаемся. Но перенос отлов ошибок в ранайме достает неслабо.
Re[47]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.03.04 12:10
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>>>не могут интесеваться производительностью ПО за которое платят деньги ?

AVK>>Пользователь платит деньги за компиляторы? Это что то новенькое.

PE>Компилятор влияет на производительность ПО.


Влияет. Только шустрики не об этом.

PE>И не выдергивай слова из фразы.Это не к лицу модератору.


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

PE>Конечно. Но все пользуются именно винампом, потому, что он не такой тормозной, как многие его конкуренты.


Вот только шустрики не о производительности декодеров mp3.

AVK>>>>Т.е. какие то компиляторы всегда делают тормозное глюкало?


PE>Конечно. Это в ваших шустриках и написано, что одни компилеры дают шустрый код, другие тормозной.


А про глюки там тоже написано или ты для красного словца?

PE>Нет. Мне интересно, стоит ли браться за написание проги по звуку на дотнете или на нативном С++,


На этот вопрос сможешь ответить только ты сам.

AVK>>Напоминаю в который уже раз — в шустриках никто не тестирует и не будет тестировать процессоры и прочее железо, а так же конкретный прикладной софт для обработки звука и видео. Там тестировали и тестируют компиляторы.


PE>Отлично. Сделаем по твоему. Процессоры одинаковые и железо одинаковое.

PE>Осталось сравнить три продукта (нативный, дотнетовский, жавовский).

Вот и возвращаемся к исходному вопросу — нафига там тестировать алгоритмы упаковки звука, если процент программистов, на которых эта статья нацелена, занимающихся звуком весьма мал?
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[45]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.03.04 12:20
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>>>А при чем здесь COM ?

AVK>>Вот и я о том же.

PE>Про COM ты сам вспомнил.


Ага, и Влад тоже, синхронно со мной. А ты как бы про него даже не писал.

PE> Я ничего не говорил.


Цитату привести?

AVK>>Тогда какое это имеет отношение к замене событий интерфейсами?

PE>Это ты предложил интерфейсы и даже собственную реализацию привел.

Предложил не я. Я тебе ответил на вопрос как примерно это можно реализовать.

[оверквотинг поскипан] (ты кстати, если не отвечаешь то не цитируй простыни)

Я так понимаю что по лишним классам вопросов нет?

PE>>>А конструкторы ?

AVK>>Что конструкторы?

PE>А в конструкторах по твоему методу нужно приинициализировать все инстанцы, которые заведуют оработкой событий от объекта i-ой проперти. Им нужно this сообщить.


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


AVK>>Так надо так строить приложение чтобы легко было имитировать внешнюю среду для отдельных блоков. Еще юнит тестирование в таких случаях рулит.


PE>Для сетевой модели сложность написания тестов O(n**2).


Сам придумал? Сложность тестов зависит не от структуры данных, а от структуры приложения. Те баги о которых шла речь к трудноулавливаемым не относятся. Кроме того я что то не пойму — а вы сейчас вобще не тестируете?

PE> Вперед !


Да у меня то как раз никаких проблем. Вон в дизайнере нашем очень даже сетевая структура и очень даже много генеренного кода. И ничего, как то справляемся.

PE>Загрузку и сохранение уже не протестируешь


Чего так? Ты ж учти — кодогенератор генерирует все одинаково. Если ты отладишь самый сложный класс, то остальные автоматом так же будут отлажены, правишь то ты генератор, а не конкретный класс. Так что в итоге задачка сводится не к отладке моря кода, который генерится, а к отладке единственного генератора.

PE> не говоря об самых маленьких алгоритмах.


А при чем тут генератор? Ручные алгоритмы надо отлаживать в любой ситуации, генеришь ты код или руками пишешь неважно.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[48]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.03.04 12:21
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Plutonia Experiment, Вы писали:


PE>>>>не могут интесеваться производительностью ПО за которое платят деньги ?

AVK>>>Пользователь платит деньги за компиляторы? Это что то новенькое.

PE>>Компилятор влияет на производительность ПО.


AVK>Влияет. Только шустрики не об этом.


PE>>И не выдергивай слова из фразы.Это не к лицу модератору.


AVK>Во-первых это демагогия.


Вот моя интерпретация
"производительностью ПО за которое платят деньги"
Вот твоя
"ПО за которое платят деньги"+ "Пользователь платит деньги за компиляторы? "


PE>>Конечно. Но все пользуются именно винампом, потому, что он не такой тормозной, как многие его конкуренты.


AVK>Вот только шустрики не о производительности декодеров mp3.


Наконец то. А о чем ? Обо всем, что некасается этого ? Не верю !

AVK>>>>>Т.е. какие то компиляторы всегда делают тормозное глюкало?

PE>>Конечно. Это в ваших шустриках и написано, что одни компилеры дают шустрый код, другие тормозной.

AVK>А про глюки там тоже написано или ты для красного словца?

Глюкало было в контексте в отношении двух подопытных. Ссылку дать ?

PE>>Нет. Мне интересно, стоит ли браться за написание проги по звуку на дотнете или на нативном С++,

AVK>На этот вопрос сможешь ответить только ты сам.

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

PE>>Отлично. Сделаем по твоему. Процессоры одинаковые и железо одинаковое.

PE>>Осталось сравнить три продукта (нативный, дотнетовский, жавовский).

AVK>Вот и возвращаемся к исходному вопросу — нафига там тестировать алгоритмы упаковки звука, если процент программистов, на которых эта статья нацелена, занимающихся звуком весьма мал?


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

Если ты считаешь,что программисты пишут только распределенные корпоративные системы, то глубоко заблуждаешься.
Re[49]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.03.04 12:40
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>>>Компилятор влияет на производительность ПО.


AVK>>Влияет. Только шустрики не об этом.


PE>>>И не выдергивай слова из фразы.Это не к лицу модератору.


AVK>>Во-первых это демагогия.


Т.е. это тот кусок к которому у тебя притензии? Ага, интересно. И что же я выкинул из цитаты?


PE>>>Конечно. Но все пользуются именно винампом, потому, что он не такой тормозной, как многие его конкуренты.


AVK>>Вот только шустрики не о производительности декодеров mp3.


PE>Наконец то. А о чем ? Обо всем, что некасается этого ? Не верю !


Ты наверное будешь удивлен, но о компиляторах.


PE>>>Нет. Мне интересно, стоит ли браться за написание проги по звуку на дотнете или на нативном С++,

AVK>>На этот вопрос сможешь ответить только ты сам.
PE>Этот вопрос интересует не только меня.

А кого еще? Только не надо про пользователей.

PE> Глядя на вашу синтетику, я могу сказать, что на синтетике дотнет немеряно крут. если вы писали синтетику ради синтетики в академических интересах — у меня вопросов нет более.


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

AVK>>Вот и возвращаемся к исходному вопросу — нафига там тестировать алгоритмы упаковки звука, если процент программистов, на которых эта статья нацелена, занимающихся звуком весьма мал?


PE>Отвечаю в который раз — хочется выяснить область применения дотнета.


Напоминаю в который раз что шустрики не об этом. Если хочешь — протестируй сам и напиши свою статью о компиляторах в обработке звука, мы ее с удовольствием опубликуем.

PE>Если ты считаешь,что программисты пишут только распределенные корпоративные системы, то глубоко заблуждаешься.


Нет конечно, но очень приличное количество их. Можешь провести опрос кто чем занимается.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[46]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.03.04 12:52
Оценка:
Здравствуйте, 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 часов. Баги проверяются уже на отловленых специфичных ситуациях.
Re[47]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 04.03.04 13:51
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>Сам придумал? Сложность тестов зависит не от структуры данных, а от структуры приложения. Те баги о которых шла речь к трудноулавливаемым не относятся.


PE>Структура модели данных — гиперграф это и есть аппликация, если тестируешь только это. Это отдельная часть проекта.

PE>Вот для него то сложность тестирования и равна O(n**2)

Но речь то не о тестировании гиперграфа, который при любом раскладе тестировать нужно. Речь о тестировании генератора.

AVK>>Да у меня то как раз никаких проблем. Вон в дизайнере нашем очень даже сетевая структура и очень даже много генеренного кода. И ничего, как то справляемся.


PE>Сетевая какой сложности ? Давай сравним.


Пиписьками мерятся? И в чем сложность оценивать? В численных характеристиках? Несколько десятков сущностей, до 1 млн. экземпляров.

PE>Мы именно так и делаем. Только речь шла про тесты. Каким это кодогенератором ты пртестируешь загрузку-сохранение модели ?


Речь шла о том что перенесение части ошибок в рантайм из-за использования генератора не так уж и страшна.

AVK>>А при чем тут генератор? Ручные алгоритмы надо отлаживать в любой ситуации, генеришь ты код или руками пишешь неважно.


PE>Вот тут то и проблема. Для графа с количеством узлов N надо перебрать O(N**2) ситуаций для тестирования алгоритма. Если это делать отдельно от прилаги основном, то ты просто повесишься.


А смысл? Стоимость перебора вариантов всегда очень высока. Обычно обходятся использованием стабильных и предсказуемых алгоритмов и тестирования характерных случаев.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[50]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.03.04 16:11
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>>>Во-первых это демагогия.


AVK>Т.е. это тот кусок к которому у тебя притензии? Ага, интересно. И что же я выкинул из цитаты?


слово "производительность" ты оставил на верхней строчке и ответил на последнюю часть фразы без слова производительность. Это в корне меняет ситуацию.

AVK>>А причем тут пользователи? Речь о программистах.
PE>Т.е. пользователи сук и быдло
Я этого не говорил.
PE> и не могут интесеваться производительностью ПО
Может. Но шустрики не для него.
PE> за которое платят деньги ?
Пользователь платит деньги за компиляторы? Это что то новенькое.


Как из моей фразы следует утверждение "Пользователь платит деньги за компиляторы." ?
Компилятор влияет на производительность ПО за которое пользователи платят деньги.


PE>>>>Нет. Мне интересно, стоит ли браться за написание проги по звуку на дотнете или на нативном С++,

AVK>>>На этот вопрос сможешь ответить только ты сам.
PE>>Этот вопрос интересует не только меня.

AVK>А кого еще? Только не надо про пользователей.


PE>> Глядя на вашу синтетику, я могу сказать, что на синтетике дотнет немеряно крут. если вы писали синтетику ради синтетики в академических интересах — у меня вопросов нет более.


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


Почти все мои одногруптики раобтают на госпредприятиях. Основная часть — военка, моделирование и всякая математика. Многие работают со звком. Сжатие звука для передачи по модемным сетям хитрым. Сжатие для тел станций. Запись под диктовку, верификация и тд. Имитация шумов. Распознавание изображений(выделение номеров машин). Много чего. Достаточно ?
С БД работают очень мало.
Re[48]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.03.04 17:00
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Структура модели данных — гиперграф это и есть аппликация, если тестируешь только это. Это отдельная часть проекта.

PE>>Вот для него то сложность тестирования и равна O(n**2)

AVK>Но речь то не о тестировании гиперграфа, который при любом раскладе тестировать нужно. Речь о тестировании генератора.


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

AVK>>>Да у меня то как раз никаких проблем. Вон в дизайнере нашем очень даже сетевая структура и очень даже много генеренного кода. И ничего, как то справляемся.


А новые люди сколько в этом разбираются ?

PE>>Сетевая какой сложности ? Давай сравним.


AVK>Пиписьками мерятся? И в чем сложность оценивать? В численных характеристиках? Несколько десятков сущностей, до 1 млн. экземпляров.


Если ваша с сеть однороная, то хоть миллиарды. У нас примерно 600 классов, писаных от руки.
Все классы очень сильно отличаются друг от друга. Это представление сети на разных уровнях.
Сети, сегменты, подсети, узлы, связи, волокна, траффик, пути, таблицы различные (не коллекции). Технологии, информация об оборудовании, информация о конфигурации этого оборудования. Каждый элемент должен имеет тип, имя, описание. Каждый имеет свой рисунок.
По какому принципу генерировать — непонятно. Все это описывается в соответсвующих разделах теории оптических сетей.

AVK>А смысл? Стоимость перебора вариантов всегда очень высока. Обычно обходятся использованием стабильных и предсказуемых алгоритмов и тестирования характерных случаев.


Каждый случай в графе это характерный. Если есть подозрение, что алгоритм генерирует неоптимальное решение, то очень сложно выявить ошибку. Иногда такие ошибки ищутся месяцами.
Re[42]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.03.04 18:06
Оценка:
Здравствуйте, AndrewVK, Вы писали:


Кусочек для наглядности

AVK>Вариант с интерфейсом

AVK>
AVK>public interface ISomeEventHandler
AVK>{
AVK>    void Handle(object sender, SomeEventArgs e);
AVK>}

AVK>public class EventProvider
AVK>{
AVK>    private ArrayList _eventConsumers = new ArrayList();
    
AVK>    public void AddSomeEventHandler(ISomeEventHandler h)
AVK>    {
AVK>        _eventConsumers.Add(h);
AVK>    }
    
AVK>    public void RemoveSomeEventHandler(ISomeEventHandler h)
AVK>    {
AVK>        _eventConsumers.Remove(h);
AVK>    }
    
AVK>    protected void OnSomeEvent(SomeEventArgs e)
AVK>    {
AVK>        foreach (ISomeEventHandler h in _eventConsumers)
AVK>            h.Handle(this, e);
AVK>    }
AVK>}

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 эвентами и рефлекшном нам удалось
Re[32]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.03.04 18:09
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>Я думаю, что нормальный путь — выдрать сериалайзер из ротора и кой какие пместа оптимизировать. Но неясно, как это толкнуть в обиход. Это есть нарушение.

PE>>А нам чу что придется написать примерно такой же форматтер.

VD>Это очень сложно. Он там на мертво врос.


Это очень просто !
Выдираешь исходники форматтера, ObjectIDGenerator, подсовываешь свои заглушки для ресурсов и кой каких фейковых классов, комментируешь дебаговую муть и юзаешь.

Могу выслать готовый проект.
Re[33]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.03.04 19:19
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>

PE>Это очень просто !
Выдираешь исходники форматтера, ObjectIDGenerator, подсовываешь свои заглушки для ресурсов и кой каких фейковых классов, комментируешь дебаговую муть и юзаешь.

PE>Могу выслать готовый проект.


Давай. Это даже интересно.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.03.04 07:17
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>

PE>>Это очень просто !
Выдираешь исходники форматтера, ObjectIDGenerator, подсовываешь свои заглушки для ресурсов и кой каких фейковых классов, комментируешь дебаговую муть и юзаешь.

PE>>Могу выслать готовый проект.


VD>Давай. Это даже интересно.


В форуме "Исходники".
Re[51]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.03.04 08:36
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>Т.е. это тот кусок к которому у тебя притензии? Ага, интересно. И что же я выкинул из цитаты?


PE>слово "производительность" ты оставил на верхней строчке


Блин, уписаться можно. Я уже не так отформатировал. Вобщем демагогия. Нечего сказать начинаешь придираться к тому что на какой строчке расположено.

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


PE>Почти все мои одногруптики раобтают на госпредприятиях.


Несчастные. А у меня наверное уже никто не работает.

PE> Основная часть — военка, моделирование и всякая математика. Многие работают со звком. Сжатие звука для передачи по модемным сетям хитрым. Сжатие для тел станций. Запись под диктовку, верификация и тд. Имитация шумов. Распознавание изображений(выделение номеров машин). Много чего.

PE>Достаточно ?

Нет. Почему ты решил что твои одногрупники являются основной аудиторией сайта и журнала?
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[43]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.03.04 08:36
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE> [Serialized]


Serializable?

PE> class Property1EventProviderHolder : ISomeEventHandler


Опять какая то ерунда. Зачем на каждое свойство заводить отдельный класс?

PE>После того, как ты разобрался, умножь это все на 20 — именно столько пропертей может слушаться одновременно. Еще 10 пропроще.


Не, ну до маразма что угодно можно довести.

PE>Если писать в одном интерфейсе аж 4 эвента, то получается классов нужно оъявлять меньше.


Зачем? Ты опять чего то не понял. 1 интерфейс = 1 тип эвента. Если класс подписывается на несколько разных типов эвентов он реализует несколько интерфейсов.

PE>Если интерфейсы из одного метода, то получится тоже самое, что и у нас сейчас, только кода побольше будет.


О том и речь.

PE>ИТОГО: Кода в твоем случае получается поболее...


Побольше, в основном в источнике события, а вот в потребителе даже поменьше получается.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[49]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.03.04 08:36
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Ну протестирую я генератор колекций, и что с того ?


То что генеренный код после этого при изменении входных данных особо тестировать не надо.

AVK>>>>Да у меня то как раз никаких проблем. Вон в дизайнере нашем очень даже сетевая структура и очень даже много генеренного кода. И ничего, как то справляемся.


PE>А новые люди сколько в этом разбираются ?


Нету у нас таких.

AVK>>Пиписьками мерятся? И в чем сложность оценивать? В численных характеристиках? Несколько десятков сущностей, до 1 млн. экземпляров.


PE>Если ваша с сеть однороная, то хоть миллиарды.


Я же написал — несколько десятков сущностей. Какая она однородная? Связи тоже нескольких типов.
Да, естественно ни о какой автоматической сериализации я даже не думал. Запись целиком собственная, в БД, с кешированием и сериализацией только измененных частей. Иначе это при любом варианте автоматической тормоза. А мне надо чтобы сохранение изменений занимало не более 1-2 секунд.

PE> У нас примерно 600 классов, писаных от руки.


Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.

PE>По какому принципу генерировать — непонятно.


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

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


ИМХО это сигнал для серьезного пересмотра дизайна программы.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[52]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.03.04 09:44
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>> Основная часть — военка, моделирование и всякая математика. Многие работают со звком. Сжатие звука для передачи по модемным сетям хитрым. Сжатие для тел станций. Запись под диктовку, верификация и тд. Имитация шумов. Распознавание изображений(выделение номеров машин). Много чего.

PE>>Достаточно ?

AVK>Нет. Почему ты решил что твои одногрупники являются основной аудиторией сайта и журнала?


К сайту и журналу они никакого отношения не имеют. У троих только инет есть.
А журнал в Минске... лучше изредка оффлайновые версии посматривать.
Re[44]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.03.04 09:59
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>> [Serialized]

AVK>Serializable?

Да.

PE>> class Property1EventProviderHolder : ISomeEventHandler


AVK>Опять какая то ерунда. Зачем на каждое свойство заводить отдельный класс?


А как по другому ? Объект одновременно и подписчик десятков эвентов и консумер стольких.
А еще есть эвенты от коллекций например.

PE>>После того, как ты разобрался, умножь это все на 20 — именно столько пропертей может слушаться одновременно. Еще 10 пропроще.


AVK>Не, ну до маразма что угодно можно довести.


Сложность задачи определяет кастомер, а не мы.
Конечно, с твоей точки зрения это маразм, потому что ты не представляешь модели оптической сети. Заказчики наши это не рядовые предприятия и тд. Это отдельные государства, крупные корпорации. Для такого мастшаба требуется гораздо сложнее модель, чем у нас.
Мы лишь упростили максимально. Но в люом случае сложность очень высокая.

PE>>Если интерфейсы из одного метода, то получится тоже самое, что и у нас сейчас, только кода побольше будет.

AVK>О том и речь.

Так а зачем лишний код ? Нам и так пролему приходится решать с нынешним количесвом.

PE>>ИТОГО: Кода в твоем случае получается поболее...

AVK>Побольше, в основном в источнике события, а вот в потребителе даже поменьше получается.


Вот что я прикинул на счет ссылок и объектов(вчера я неправильно оценил). Если вводить один объект на пропертю, количество объектов для серелизации увеличится на количество пропертей. Сериалайзер этого не вынесет. И десериалайзер тоже.
Количество ссылок удваивается — опят же геморрой. Будет ли быстрее работать алгоритм — сложный вопрос. Кое где экономия есть, но цепочки взаимодействия длинне.
И если один слой мадели будет сохряняться десятки минут — это все геморрой.

Единственный плюс твоего подхода в том, что можно легко перейти к схеме с частично загрузкой.
Над этим работаем.
Re[50]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.03.04 10:08
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Ну протестирую я генератор колекций, и что с того ?

AVK>То что генеренный код после этого при изменении входных данных особо тестировать не надо.

То же самое имеем мы и сейчас. Колекция тестируется один раз. Все остальные идентичны, иначе это дело даже не скомпилится.

PE>>А новые люди сколько в этом разбираются ?

AVK> Нету у нас таких.

Когда будут — расскажешь.

PE>>Если ваша с сеть однороная, то хоть миллиарды.


AVK>Я же написал — несколько десятков сущностей. Какая она однородная? Связи тоже нескольких типов.


У нас не несколько десятков а 6 сотен. К следующей версии будет около тысячи.

AVK>Да, естественно ни о какой автоматической сериализации я даже не думал. Запись целиком собственная, в БД, с кешированием и сериализацией только измененных частей. Иначе это при любом варианте автоматической тормоза. А мне надо чтобы сохранение изменений занимало не более 1-2 секунд.


PE>> У нас примерно 600 классов, писаных от руки.


AVK>Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.


Это хорошо. Ты никогда не задумывался, как можно генерировать код дотнетфреймворка ?
Аналогия та же самая.

PE>>По какому принципу генерировать — непонятно.


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


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


AVK>ИМХО это сигнал для серьезного пересмотра дизайна программы.
Re[45]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.03.04 10:10
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>Опять какая то ерунда. Зачем на каждое свойство заводить отдельный класс?


PE>А как по другому ? Объект одновременно и подписчик десятков эвентов и консумер стольких.


Одновременно и одинаковых? Так у тебя же sender есть, по нему и разруливай.

AVK>>Не, ну до маразма что угодно можно довести.


PE>Сложность задачи определяет кастомер, а не мы.

PE>Конечно, с твоей точки зрения это маразм, потому что ты не представляешь модели оптической сети.

Маразм не в модели оптической сети, а в создании классов на каждую подписку.


PE>>>Если интерфейсы из одного метода, то получится тоже самое, что и у нас сейчас, только кода побольше будет.

AVK>>О том и речь.

PE>Так а зачем лишний код ?


Чтобы не тормозило, ты же этого хотел?

PE>Количество ссылок удваивается — опят же геморрой. Будет ли быстрее работать алгоритм — сложный вопрос.


Нет тут никакой сложности. Быстрее, причем очень заметно быстрее.

PE>Единственный плюс твоего подхода в том, что можно легко перейти к схеме с частично загрузкой.


Зная размер модели я бы это делал с самого начала.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[50]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.03.04 10:11
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


Серилизацию мы не пишем. На все написано два суррогата.

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


AVK>ИМХО это сигнал для серьезного пересмотра дизайна программы.


Это научная задача. Передизайн тебе не поможет в принципе. Для исправения ошибки часто нужно исследования провести или кучу реальных замеров, проконсультироваться в университетах и тд.
Это вычисления, тесты тебе не помогут. Тест — это другая научная задача такой же, если не большей, сложности.
Re[46]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.03.04 10:17
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>>>Опять какая то ерунда. Зачем на каждое свойство заводить отдельный класс?

PE>>А как по другому ? Объект одновременно и подписчик десятков эвентов и консумер стольких.
AVK>Одновременно и одинаковых? Так у тебя же sender есть, по нему и разруливай.

Одновременно. Могут быть разных типов. Могут быть одинаковых типов.
Сендер у нас один — в базовом классе. А приемников нужно столько, сколько пропертей.

PE>>Сложность задачи определяет кастомер, а не мы.

PE>>Конечно, с твоей точки зрения это маразм, потому что ты не представляешь модели оптической сети.

AVK>Маразм не в модели оптической сети, а в создании классов на каждую подписку.


Подписка — это не просто обратная связь. Это кусочек математики, которую придется выпонять при возникновении эвента. Для каждой проперти она своя.


PE>>Так а зачем лишний код ?

AVK>Чтобы не тормозило, ты же этого хотел?

PE>>Количество ссылок удваивается — опят же геморрой. Будет ли быстрее работать алгоритм — сложный вопрос.


AVK>Нет тут никакой сложности. Быстрее, причем очень заметно быстрее.

Серилизация и десерилизация умрет вообще.

PE>>Единственный плюс твоего подхода в том, что можно легко перейти к схеме с частично загрузкой.

AVK>Зная размер модели я бы это делал с самого начала.

Это очень сложный механизм.
Перформанс для алгоритмов будет никакой. Сеть набивать будет побыстрее, конечо и сохранять побыстрее, но основная цель — это результаты работы алгоритмов.
Re[51]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 05.03.04 12:56
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>То что генеренный код после этого при изменении входных данных особо тестировать не надо.


PE>То же самое имеем мы и сейчас. Колекция тестируется один раз. Все остальные идентичны, иначе это дело даже не скомпилится.


Ну вот, значит нужно продолжать двигаться в том же направлении.

AVK>>Я же написал — несколько десятков сущностей. Какая она однородная? Связи тоже нескольких типов.


PE>У нас не несколько десятков а 6 сотен. К следующей версии будет около тысячи.


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

AVK>>Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.


PE>Это хорошо. Ты никогда не задумывался, как можно генерировать код дотнетфреймворка ?


В смысле?
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[52]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.03.04 13:59
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>То же самое имеем мы и сейчас. Колекция тестируется один раз. Все остальные идентичны, иначе это дело даже не скомпилится.


AVK>Ну вот, значит нужно продолжать двигаться в том же направлении.


На дженериках мы первое, что сделаем, это повыбрасываем все коллекции.

PE>>У нас не несколько десятков а 6 сотен. К следующей версии будет около тысячи.

AVK>Ну так тем более. Я то сразу делал собственную загрузку/выгрузку. И в вашем случае поступил бы точно так же, вне зависимости от того какой язык и платформу я использую.

Если использовать оптимизированый вариант форматтера из ротора, то все пучком. Остается устранить лишние WriteObjectInfo(их столько, сколько ссылок на объект — в 20...30 раз больше). Опосля доработать напильником, убрать лишнее в смысле, и обфусцировать.

AVK>>>Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.


PE>>Это хорошо. Ты никогда не задумывался, как можно генерировать код дотнетфреймворка ?

AVK>В смысле?

Я к тому, что большая часть кода у нас самописная. Это математика. Коллекции и кой какие базовые механизмы это не самое страшное.
Re: C++ versus C#
От: maq Россия http://www.maqdev.com
Дата: 09.03.04 16:22
Оценка:
Мне вот в свете вышесказанного еще интересно как приживется C++ CLI
Ведь писать на нем будет практически также просто как и на C# а возможностей побольше будет
все таки.

Что народ думает?
Re[45]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.03.04 23:00
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Про COM ты сам вспомнил. Я ничего не говорил. Я предложил идею реализации, аналогичную комовской.


Вот тебе и сказали, что он тут не причем. Конекшон-поинты в ком нужны для избавления от проблемы циклической ссылки. В дотнете она или вообще не стоит или решается вик-реверенсами.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[47]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.03.04 23:00
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Я предложил реализовать механизм, аналогичный IConnectionPointContainer.


Зачем (вот это-то и странно)? Тебе ведь сказали, что механизма вроде ссылки на интерфейс за глаза хватит.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.03.04 23:00
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Написали генератор текста(на жаве ) и все пучком.


Для продукта на дотнете? Ну, вы блин даете...
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[50]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.03.04 23:00
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.


Полностью согласен.

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


Как минимум все они состоят из свойст и коллекций. Так что уж сериализацию то точно можно автоаматизировать если не придерживаться собственных догм и не упавать на собственную не последовательность.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[53]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.03.04 23:00
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>На дженериках мы первое, что сделаем, это повыбрасываем все коллекции.


И получите прирост в 5% мксимум, а то и тормоза (если не додумаетесь свои коллекции реализовать).

PE>Если использовать оптимизированый вариант форматтера из ротора, то все пучком. Остается устранить лишние WriteObjectInfo(их столько, сколько ссылок на объект — в 20...30 раз больше). Опосля доработать напильником, убрать лишнее в смысле, и обфусцировать.


И все же. Ты все время говоришь о количестве классов в вашем фреймворке. Но не разу не скзал, о среднем и максимальном количестве объектов в графе подлежещем сериализации. А именно это число важно для оценки. Так же интересно, что считается приемлемым временем сериализации, когда она происходит...

PE>Я к тому, что большая часть кода у нас самописная. Это математика. Коллекции и кой какие базовые механизмы это не самое страшное.


Ты, знаешь, мы конечно в твоей прикладной области не разбирались, и заключения дать не можем. Но соглесен с АВК в том, что при числе классов в 6 сотен слабо верится, что в них нет общей системы и что их производство нельзя автоматизировать.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[51]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.03.04 23:00
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Серилизацию мы не пишем. На все написано два суррогата.


Вот тебе и говорят, что это и есть ошибка. Стандартная сериализация скорее всего не для вас. Вы забили на ручную сериализацию, а потом ты еще на этом основании делаешь выводы о приемуществах С++ в этой области. Посмотри как выглядит твоя логика со стороны! "Сериализация в дотнете медленная, а в С++ ее вообще нет и мы можем написать ее оптимальнее чем в дотнете. Значит дотнет тормоз, а С++ рулез."

PE>Это научная задача. Передизайн тебе не поможет в принципе. Для исправения ошибки часто нужно исследования провести или кучу реальных замеров, проконсультироваться в университетах и тд.

PE>Это вычисления, тесты тебе не помогут. Тест — это другая научная задача такой же, если не большей, сложности.

Тоже неплохое основание для признания бессмысленности создания собственной системы сериализации. Я правельно понял тормоза у вас в этом, а не в вычислениях?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[45]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.03.04 23:00
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Так а зачем лишний код ? Нам и так пролему приходится решать с нынешним количесвом.


Ты ведь говорил, что у вас сериализация тормзит изза использования делегатов. Вот он тебе и посоветовал решение.

PE>И если один слой мадели будет сохряняться десятки минут — это все геморрой.


Назови все же объем средней и большой модели в количестве экхемлпяров объектов учавствующих в грфе.

PE>Единственный плюс твоего подхода в том, что можно легко перейти к схеме с частично загрузкой.

PE>Над этим работаем.

Он тебе предлагал вообще-то сериализацию вручную написать, возможно с генератором кода. Это училичит производительность в разы, а то и десятки раз.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[47]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.03.04 23:00
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Серилизация и десерилизация умрет вообще.

...

PE>Это очень сложный механизм.

PE>Перформанс для алгоритмов будет никакой. Сеть набивать будет побыстрее, конечо и сохранять побыстрее, но основная цель — это результаты работы алгоритмов.

Блин, ну ты уперся. Тебе говорят об известно факте! Скорость рабты через ссылки на интерфейсы в 5-10 раз выше чем в случае с делегатом и в десятки выше в случае прямых вызовов (опять же по сравнению сделегатами).

ЗЫ

Вот только тормоза сериализатора далеко не только в событиях заключаются.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[34]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.03.04 23:00
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Фремворк на шарпе создать еще проще. НО ! В программах обработки звука для простых обывателей никогда не было, нет и никогда не бует аппаратных алгоритмов. Продвинутый программный алгоритм всегда будет раотать быстрее железа. Фурье — довольно меденный агоритм.

PE>Применения в ПО его избегают именно из за тормознутости. Можно быстрее — но больше памяти сожрешь. А вот в железо фурие закатать — проще не придумаешь. Но не всегда можно использовать аппаратные воможности. Для вывода звука на колонки можно кое что впихнуть в звуковуху.
PE>Но чтото я ни разу не видел в продаже аппратный ужиматель(USB или PCI или PCMCIA) в МП3, ОГГ к примеру для моего компутера. И не просто ужиматели, а чтобы можно было гибко настраивать, психоаккустику менять и тд. и тд.
PE>Так что всякие FPGA можно сразу засунуть в одно место.

Да в половине ресиверов подобные функции зашиты. Просто если хватает ЦП, то и нефига делать спец. решения.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.03.04 23:00
Оценка:
Здравствуйте, naje, Вы писали:

N>такой как тут невозможно просто на шарпе, нужно разрабатывать ещё один язык для нета, впринципе одно из решений


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

Вот интересно, ваш код компилируется на VC6? И уверен ли ты в том, что если бы в воспользовались, например, вот этим, у вас не плучилось бы все проще, надежнее и быстрее?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.03.04 23:00
Оценка:
Здравствуйте, maq, Вы писали:

maq>Мне вот в свете вышесказанного еще интересно как приживется C++ CLI

maq>Ведь писать на нем будет практически также просто как и на C# а возможностей побольше будет
maq>все таки.

maq>Что народ думает?


Я думаю, что возможностей особо больше не будет. А читать и присать на Шарпе удобнее уже. Так что C++ CLI станет тем же чем Дельфи.НЭТ — средством вербовки в веру дотнета программистов плохо хранящим излишнюю приверженность своим привычкам.

Единственное что мне действительно нехвататет из С++ на сегодня — это средств метапрограммирования. Но они и в С++ очень слабы. Сдается мне, что будущее за вот такими расширениями
Автор(ы): Чистяков Влад (VladD2)
Дата: 28.01.2004
языков. И по сему предлагаю не ждать от моря погоды, а присоеденяться к проекту.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[50]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.03.04 07:54
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>Написали генератор текста(на жаве ) и все пучком.

VD> Для продукта на дотнете? Ну, вы блин даете...

А что делать ? Генераторы текста, которыми обладают всякие UML-тулы, весьма кривые. Мы написали постпроцесор. То, что нагенерировал UML, обрабатывается постпроцесором, и мы имеем файл, в котором нужно только функции заполнить. С коллекциями свой случай — они сделаны чз. copy-paste-replace. Другой способ, когда мы задавали этот вопрос, никто не смог предложить.
Re[51]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.03.04 07:57
Оценка:
Здравствуйте, VladD2, Вы писали:

AVK>>Да, я уже после 10 начинаю задумываться о генераторе. А при 600 у меня даже желания обойтись без него не возникает.

VD>Полностью согласен.

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

VD>Как минимум все они состоят из свойст и коллекций. Так что уж сериализацию то точно можно автоаматизировать если не придерживаться собственных догм и не упавать на собственную не последовательность.

Проблема с серилизацией не самая емкая проблема. Мы использовали бинариформаттер. Нам это стоило сотни две строк вместе с суррогатами. Сейчас избавимся от гемора с RaiseDesirilizationEvent и все пучком.
Re[54]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.03.04 08:13
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>И получите прирост в 5% мксимум, а то и тормоза (если не додумаетесь свои коллекции реализовать).


Лучше 50% тормозов, чем сотня коллекций copy-paste-replace.

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


Для рабочего проекта от 20000. Верхняя планка не ограничена. Серилизация должна выполняться за секунды...десятки секунд. У нас 30 секунд...6 минут.
Осталась одна пролема — WriteObjectInfo создается в раз 20...30 больше, чем объектов.

PE>>Я к тому, что большая часть кода у нас самописная. Это математика. Коллекции и кой какие базовые механизмы это не самое страшное.


VD>Ты, знаешь, мы конечно в твоей прикладной области не разбирались, и заключения дать не можем. Но соглесен с АВК в том, что при числе классов в 6 сотен слабо верится, что в них нет общей системы и что их производство нельзя автоматизировать.


Общая система есть. Все, что однотипно и тд, сделано в базовой сборке. Копипейста нет.
Все, что межно сделать — всю матмодель писать в виде метамодели на специальном языке. На выходе будем иметь те же самые классы. Хороший способ. Нужно написать такой язык, отладить, протестировать, научить всех людей писать на нем. При этом неясно, хватит и нам ресурсов PIII-PIV или нет.
Re[52]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.03.04 08:28
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Вот тебе и говорят, что это и есть ошибка. Стандартная сериализация скорее всего не для вас. Вы забили на ручную сериализацию, а потом ты еще на этом основании делаешь выводы о приемуществах С++ в этой области. Посмотри как выглядит твоя логика со стороны! "Сериализация в дотнете медленная, а в С++ ее вообще нет и мы можем написать ее оптимальнее чем в дотнете. Значит дотнет тормоз, а С++ рулез."


Уже все сильно. RaiseDeserilizationEvent победили — сделать можно в обход кое как. Если дадут добро на использование кастрированого форматтера из ротора — все пучком. В дотнете мне не нравится подход Микрософта. ObjectManager используется во многих классах. Класс публиный. Почему бы не дать возможность использовать наследники от этого ObjectManager ? SerilizationInfo — нет возможности изменить размер внутреннего массива. SerilizationInfo.AddValue вызывает в среднем 4-5 операций расширения массива. Это большие тормоза, с учетом того, что WriteObjectInfo создается на ссылку, а не объект.
Это только два момента. Если будет возможность поработать напильником, эти два узких места будут спилены и модель будет рулить при серилизации!

PE>>Это научная задача. Передизайн тебе не поможет в принципе. Для исправения ошибки часто нужно исследования провести или кучу реальных замеров, проконсультироваться в университетах и тд.

PE>>Это вычисления, тесты тебе не помогут. Тест — это другая научная задача такой же, если не большей, сложности.

VD>Тоже неплохое основание для признания бессмысленности создания собственной системы сериализации. Я правельно понял тормоза у вас в этом, а не в вычислениях?


Тормоза с серилизацией мы уже проехали. Модель нужна не для серилизации, а для расчета сети.
В общем случае тесты вообще непригодны. Сидят люди и проверяют правильность расчетов. Если можно написать скрипт для проверки — пишут. Нельзя — проверяется вручную.
Re[46]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.03.04 08:33
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>Так а зачем лишний код ? Нам и так пролему приходится решать с нынешним количесвом.

VD>Ты ведь говорил, что у вас сериализация тормзит изза использования делегатов. Вот он тебе и посоветовал решение.
Уже решено другим способом и без делегатов.


PE>>И если один слой мадели будет сохряняться десятки минут — это все геморрой.

VD>Назови все же объем средней и большой модели в количестве экхемлпяров объектов учавствующих в грфе.

Средняя модель 20K...40K объектов. После запуска алгорима расчета моджет быть и 100К...200К.

PE>>Единственный плюс твоего подхода в том, что можно легко перейти к схеме с частично загрузкой.

PE>>Над этим работаем.
VD>Он тебе предлагал вообще-то сериализацию вручную написать, возможно с генератором кода. Это училичит производительность в разы, а то и десятки раз.

Это понятно. Но для этого нужен передизайн. И особого выигрыша это не даст.
Мы решили вообще отказаться от серилизации.
Re[35]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.03.04 08:39
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>Так что всякие FPGA можно сразу засунуть в одно место.


VD>Да в половине ресиверов подобные функции зашиты. Просто если хватает ЦП, то и нефига делать спец. решения.


В том то и дело, что применени очень ограниченное. В твоем винампе, ламе(если ты в мп3 гонишь диски), дсп и тд. программных алгоритмов на порядки раз больше.
Re[48]: C++ versus C#
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.03.04 11:14
Оценка:
Здравствуйте, VladD2, Вы писали:



VD>Блин, ну ты уперся. Тебе говорят об известно факте! Скорость рабты через ссылки на интерфейсы в 5-10 раз выше чем в случае с делегатом и в десятки выше в случае прямых вызовов (опять же по сравнению сделегатами).


Интересно откуда у тебя такие результаты. Если не использовать рефлешного DinamicInvoke то типизированный делегат всего процентов 10 уступает интерфейсам.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Re[48]: C++ versus C#
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 12.03.04 11:28
Оценка:
Здравствуйте, VladD2, Вы писали:

Кстати метаклассы в том числе намного упрощают проблему сериализации и десиреализации.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Re[55]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 12.03.04 14:43
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Нужно написать такой язык, отладить, протестировать,


XML + embedded C# или VB.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[55]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.03.04 21:39
Оценка:
Здравствуйте, 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[51]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.03.04 21:39
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>>>Написали генератор текста(на жаве ) и все пучком.

VD>> Для продукта на дотнете? Ну, вы блин даете...

PE>А что делать ? Г


А почему не на том же Шарпе? Странен не сам генератор, а то что он на Яве для дотнетного проекта.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.03.04 21:39
Оценка:
Здравствуйте, Serginio1, Вы писали:

VD>>Блин, ну ты уперся. Тебе говорят об известно факте! Скорость рабты через ссылки на интерфейсы в 5-10 раз выше чем в случае с делегатом и в десятки выше в случае прямых вызовов (опять же по сравнению сделегатами).


S> Интересно откуда у тебя такие результаты. Если не использовать рефлешного DinamicInvoke то типизированный делегат всего процентов 10 уступает интерфейсам.


Измерял. И кстати, тут где-то резултаты приводил. 10% — фигня.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 12.03.04 21:39
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Кстати метаклассы в том числе намного упрощают проблему сериализации и десиреализации.


Ага. Языком.

Проблема сериализации в дотнете заключается в кривых руках тех кто ее писал.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[56]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.03.04 10:03
Оценка:
Здравствуйте, 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>А почему не на том же Шарпе? Странен не сам генератор, а то что он на Яве для дотнетного проекта.

А там было проще парсить код языка. Такой библиотеки мы не нашли для нета.
Re[56]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 13.03.04 10:17
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Нужно написать такой язык, отладить, протестировать,


AVK>XML + embedded C# или VB.


Не пойдет. Нужен специализированый язык, нечто вроде UML в текстовом представлении, который будет прятать все, что не относится к математике.
Re[57]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.03.04 07:21
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>>>Нужно написать такой язык, отладить, протестировать,


AVK>>XML + embedded C# или VB.


PE>Не пойдет.


Почему?

PE> Нужен специализированый язык, нечто вроде UML в текстовом представлении, который будет прятать все, что не относится к математике.


Вот и построй его на основе XML.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[50]: C++ versus C#
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 15.03.04 10:28
Оценка:
Здравствуйте, VladD2, Вы писали:

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


VD>>>Блин, ну ты уперся. Тебе говорят об известно факте! Скорость рабты через ссылки на интерфейсы в 5-10 раз выше чем в случае с делегатом и в десятки выше в случае прямых вызовов (опять же по сравнению сделегатами).


S>> Интересно откуда у тебя такие результаты. Если не использовать рефлешного DinamicInvoke то типизированный делегат всего процентов 10 уступает интерфейсам.


VD>Измерял. И кстати, тут где-то резултаты приводил. 10% — фигня.


Посмотри

http://www.rsdn.ru/Forum/Message.aspx?mid=410955&amp;only=1
Автор: Serginio1
Дата: 15.10.03

Но это примеры со свойствами. Здесь замедление в 2 раза по сравнению с интерфейсами, и более в 3 раза с свойствами класса.
Если сравнивать методы.
http://www.rsdn.ru/Forum/Message.aspx?mid=395620&amp;only=1
Автор: Serginio1
Дата: 29.09.03

http://www.rsdn.ru/Forum/Message.aspx?mid=408345&amp;only=1
Автор: Serginio1
Дата: 13.10.03
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Re[50]: C++ versus C#
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 15.03.04 10:39
Оценка:
Здравствуйте, VladD2, Вы писали:

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


S>> Кстати метаклассы в том числе намного упрощают проблему сериализации и десиреализации.


VD>Ага. Языком.

Ну зачем же так грубо. Нет в Delphi часто используют и я в том числе.
У каждого типа есть конструктор FromStream, а у каждого объекта метод ToStream. Но в Net на рефлексии легко развернуть все методы на этапе компиляции в MSIL а не не этапе сериализации десиреализации, в том числе и для объетов неизвестного типа.
VD>Проблема сериализации в дотнете заключается в кривых руках тех кто ее писал.
Согласен.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Re[58]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.03.04 17:33
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>>>XML + embedded C# или VB.


PE>>Не пойдет.


AVK>Почему?


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

PE>> Нужен специализированый язык, нечто вроде UML в текстовом представлении, который будет прятать все, что не относится к математике.


AVK>Вот и построй его на основе XML.


На основе XML неудобно. Я думаю, что это может быть нечто вроде С-подобного языка такого плана.

entity Mesh : BaseGraph
{
owner collection<Link> Links;
owner collection<Node> Nodes;
}

entity Node : BaseVertex
{
auto collection<End> Ends;
}

entity Link : BaseEdge
{
owner readonly property<End> EndA;
owner readonly property<End> EndB;
}

entity End : BaseObject
{
readonly property<Node> Node;
}


XML сгодится на первое время. Вся проблема в том, что модель слишком сложная.
Re[48]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.03.04 17:35
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>Это очень сложный механизм.

PE>>Перформанс для алгоритмов будет никакой. Сеть набивать будет побыстрее, конечо и сохранять побыстрее, но основная цель — это результаты работы алгоритмов.

VD>Блин, ну ты уперся. Тебе говорят об известно факте! Скорость рабты через ссылки на интерфейсы в 5-10 раз выше чем в случае с делегатом и в десятки выше в случае прямых вызовов (опять же по сравнению сделегатами).


В случае эвентов очень легко скриптовых клиентов уведомлять. Без этого никуда.
Re[59]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.03.04 17:50
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

Вот более адекватное описание. Все это относится к тому примеру, что я описал для Влада.

PE>
PE>entity Mesh : BaseGraph
PE>{
PE>owner collection<Link> Links;
PE>owner collection<Node> Nodes;
PE>}

PE>entity Node : BaseVertex
PE>{
PE>auto collection<End> Ends;
PE>}

PE>entity Link : BaseEdge
PE>{
PE>critical owner readonly property<End> EndA;
PE>critical owner readonly property<End> EndB;
PE>}

PE>entity End : BaseObject
PE>{
PE>critical readonly property<Node> Node;
PE>}
PE>
Re[57]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.03.04 21:10
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

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


PE>>>Лучше 50% тормозов, чем сотня коллекций copy-paste-replace.

VD>>copy-paste-replace то зачем? Ну, да тебе решать.

PE>Для типизированых коллекций. Подскажи способ лучше.


Сколько ж можно? Тебе говорят, что генераторы кода для коллекций использовать надо. Ими весь Инет завален.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[51]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.03.04 21:10
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Посмотри


Та особо не начто смотреть. В обще, я тебе уже сказал. Сделай поиск... погляди.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[51]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.03.04 21:10
Оценка:
Здравствуйте, Serginio1, Вы писали:

VD>>Проблема сериализации в дотнете заключается в кривых руках тех кто ее писал.

S> Согласен.

И что тогда рассуждать о высших материях?

Будь метаклассы в нете, что у многих сразу рук ибы выпрямились?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[59]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.03.04 07:51
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>Почему?


PE>На C# можно сделать так, но гораздо удобнее сделать это в специаизированом языке.


Не, я с тебя писяюсь . Почему не сделали спец. язык? Потому что слишком долго его делать. А почему не воспользоваться XML+C#? Потому что свой удобнее.

AVK>>Вот и построй его на основе XML.


PE>На основе XML неудобно.


Не знаю, не знаю. Вон ASP.NET показывает что очень даже ничего.

PE> Я думаю, что это может быть нечто вроде С-подобного языка такого плана.


С-подобный язык плохо подходит для декларативного описания, а правильный генератор на 90% управляется декларативно.

PE>XML сгодится на первое время. Вся проблема в том, что модель слишком сложная.


Любая сложная модель может быть упрощена за счет дополнительных абстракций. Я конечно ничего не могу сказать по поводу твоей задачки, но все подобные проблемы что мне встречались в итоге решались довольно просто, нужно было лишь тщательно разработать описательную модель.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[60]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.03.04 08:23
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Не, я с тебя писяюсь . Почему не сделали спец. язык? Потому что слишком долго его делать. А почему не воспользоваться XML+C#? Потому что свой удобнее.


Ой как умно, господин модератор. Перечитай ветку и не дури мне головы.

Предложи свой вариант на XML+С#, чтобы было столько же кода и столько же функциональности.

PE>>На основе XML неудобно.

AVK>Не знаю, не знаю. Вон ASP.NET показывает что очень даже ничего.

Почему бы тебе на XML и программы тогда не писать ? Ты никогда не думал, что вместо C# можно и так писать

<class name="Table" derived="DataTable" implements="SomeInterface">
<property type="Type" visibility="public">propertyname</property>
</class>



AVK>С-подобный язык плохо подходит для декларативного описания, а правильный генератор на 90% управляется декларативно.


Очень неплохо подходит. Смотри в IDL. Но это не единсвенное решение.

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


Упрощено все, что можно упростить. Нельзя сделать просто, если нужен и мастшаб большой и высокая степень детализации.
Re[58]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.03.04 08:27
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>>>Лучше 50% тормозов, чем сотня коллекций copy-paste-replace.

VD>>>copy-paste-replace то зачем? Ну, да тебе решать.

PE>>Для типизированых коллекций. Подскажи способ лучше.


VD>Сколько ж можно? Тебе говорят, что генераторы кода для коллекций использовать надо. Ими весь Инет завален.


Я уже сто раз говорил про это — неудобно. Генерировать лучше текст. Туда и бряк можно поставить легко и какую колекцию подменить, чтобы отладку упростить , и новому человеку проще дебажить. Много плюсов.
Создание такой коллекции — минутное дело.
Я не виду никаких преимуществ, кроме меньшего размера теста программы.
Re[60]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.03.04 08:34
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Не знаю, не знаю. Вон ASP.NET показывает что очень даже ничего.


У нас есть кой какой опыт в этом. Один объект описать на XML(статическая часть модели хранится в БД) — это примерно 3 кб текста. Это касается только загрузки.
При чем текст не читабельный и слишком плотный. Могу послать кусочек, если интересно, но в форум не могу постить.
Re[61]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.03.04 08:51
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Ой как умно, господин модератор. Перечитай ветку и не дури мне головы.




PE>>>На основе XML неудобно.

AVK>>Не знаю, не знаю. Вон ASP.NET показывает что очень даже ничего.

PE>Почему бы тебе на XML и программы тогда не писать?


Потому что программы содержат в основном императивные инструкции.

AVK>>С-подобный язык плохо подходит для декларативного описания, а правильный генератор на 90% управляется декларативно.


PE>Очень неплохо подходит.


Это тебе кажется удобнее, потому что ты на плюсах пишешь. Только ты то жаловался на то что те кто это должен писать — непрограммисты. А для них куда как проще декларативный стиль задания.

PE> Смотри в IDL.


Вот смотрел, потому и говорю. WSDL удобнее, более масштабируемо и мощнее.

PE>Нельзя сделать просто, если нужен и мастшаб большой и высокая степень детализации.


Ошибаешься.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[63]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.03.04 09:31
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>Потому что программы содержат в основном императивные инструкции.


PE>Вот в чем дело. Взаимодействие объектов придется частично на этом же языке описывать.


Взаимодействие тоже можно выразить декларативно.

PE>Проще, но не XML. XML сгодится в качестве промежуточного. Генератор должен XML примнимать, а вот человеку с XML работать не нужно. Слишком много текста и структура плохая.


Практика показывает что стороннему человеку намного проще понимать XML, SQL и прочая, нежели императивный язык. В свое время была задачка обработки потока видео — декларативный стиль описания сети обработчиков инженерам был намного понятнее императивного.

AVK>>Вот смотрел, потому и говорю. WSDL удобнее, более масштабируемо и мощнее.


PE>Ничего тут не удобнее. Если один раз написать и забыть, то можно и XML,WSDL и все, что хочешь юзать.


На вкус и цвет. Мой опыт показывает что С-подобный синтаксис крайне неудобен для декларативного описания, особенно человеку, незнакомому с программированием.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[64]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.03.04 09:48
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Вот в чем дело. Взаимодействие объектов придется частично на этом же языке описывать.


AVK>Взаимодействие тоже можно выразить декларативно.


На XML это неудобно. Не наглядно. Слишком громоздко. Не для этого XML содан.

AVK>Практика показывает что стороннему человеку намного проще понимать XML, SQL и прочая, нежели императивный язык. В свое время была задачка обработки потока видео — декларативный стиль описания сети обработчиков инженерам был намного понятнее императивного.


Понятнее — слишком растяжимо. Могу послать пример на почту.
Достоинства XML в том, что много парсеров написано, он станартизирован и распространен.
На счет понятности — очень спорно. Если текста более, чем на страницу, XML очень трудно читать.
Перепиши мой пример на XML и сам все поймешь.

PE>>Ничего тут не удобнее. Если один раз написать и забыть, то можно и XML,WSDL и все, что хочешь юзать.

AVK>На вкус и цвет. Мой опыт показывает что С-подобный синтаксис крайне неудобен для декларативного описания, особенно человеку, незнакомому с программированием.

XML — не простое, а примитивное решение. Все должно быть просто, но не примитивно.
Re[52]: C++ versus C#
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 16.03.04 10:09
Оценка:
Здравствуйте, VladD2, Вы писали:

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


S>>Посмотри


VD>Та особо не начто смотреть. В обще, я тебе уже сказал. Сделай поиск... погляди.

Ну да в этих тестах делегаты прогрывают доступ к полю максимум в 5 раз от доступа объекта, и максимально проигрывают интерфейсу в 2 раза.
А у тебя в 5-10 раз к интерфейсу. Причем эти методы тратят время только на вызов не говоря о сложных методах где эта разница будет сведена к нулю. А подумай сам как он может так прогирывать если делает всего 2-3 лишних движения??? Кстати в Delphi нативная крнструкция Procedure of Object работает быстрее виртуального метода (Native), а в случае с интерфейсами это вообще двойная виртуальность.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Re[65]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.03.04 10:21
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>Взаимодействие тоже можно выразить декларативно.


PE>На XML это неудобно. Не наглядно.


А по мне так куда удобнее и нагляднее чем то что ты тут приводил.

PE> Слишком громоздко. Не для этого XML содан.


А для чего?

PE>Понятнее — слишком растяжимо. Могу послать пример на почту.

PE>Достоинства XML в том, что много парсеров написано, он станартизирован и распространен.

Именно. Особенно подчеркну "стандартизован".

PE>Перепиши мой пример на XML и сам все поймешь.


У меня таких примеров в текущем проекте море. Ничего такого пока не понял. Если слишком много и сложно то и в С-стиле тоже будет малочитаемо, нужно писать специализированный редактор. Просто ты привык к чтению больших объемов С-кода, потому тебе кажется что так проще. На самом же деле при больших объемах проще xml за счет большей структурированности. А учитывая то что для XML уже есть готовые редакторы незнакомому с С человеку он куда предпочтительнее.

PE>XML — не простое, а примитивное решение.


Интересно, на основании чего ты такие выводы делаешь.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[66]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.03.04 11:35
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>> Слишком громоздко. Не для этого XML содан.

AVK>А для чего?

Это не ко мне.

AVK>Именно. Особенно подчеркну "стандартизован".

PE>>Перепиши мой пример на XML и сам все поймешь.

AVK>У меня таких примеров в текущем проекте море. Ничего такого пока не понял. Если слишком много и сложно то и в С-стиле тоже будет малочитаемо, нужно писать специализированный редактор. Просто ты привык к чтению больших объемов С-кода, потому тебе кажется что так проще. На самом же деле при больших объемах проще xml за счет большей структурированности. А учитывая то что для XML уже есть готовые редакторы незнакомому с С человеку он куда предпочтительнее.


Редакторы есть какие то. Нет редактора, который отобразит структуру нашей модели.

PE>>XML — не простое, а примитивное решение.

AVK>Интересно, на основании чего ты такие выводы делаешь.

На основании того, что уже сделано.
Re[67]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.03.04 11:51
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>>> Слишком громоздко. Не для этого XML содан.

AVK>>А для чего?

PE>Это не ко мне.


Почему? Ты же утверждаешь что не для этого. Вот и интересно тогда для чего.

AVK>>У меня таких примеров в текущем проекте море. Ничего такого пока не понял. Если слишком много и сложно то и в С-стиле тоже будет малочитаемо, нужно писать специализированный редактор. Просто ты привык к чтению больших объемов С-кода, потому тебе кажется что так проще. На самом же деле при больших объемах проще xml за счет большей структурированности. А учитывая то что для XML уже есть готовые редакторы незнакомому с С человеку он куда предпочтительнее.


PE>Редакторы есть какие то. Нет редактора, который отобразит структуру нашей модели.


Редакторы, поддерживающие xsd отображают в соответствии с xsd. Это как минимум базовые взаимосвязи и валидация значений. Для более сложных случаев можешь поглядеть на InfoPath. Для совсем запущенных случаев придется писать свой редактор, а в таком варианте XML безусловно удобнее.

PE>>>XML — не простое, а примитивное решение.

AVK>>Интересно, на основании чего ты такие выводы делаешь.

PE>На основании того, что уже сделано.


Ну вобщем поступай как знаешь. Я на основании своего опыта тебе примерное направление показал.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[68]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.03.04 12:02
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>>> Слишком громоздко. Не для этого XML содан.

AVK>>>А для чего?

PE>>Это не ко мне.


AVK>Почему? Ты же утверждаешь что не для этого. Вот и интересно тогда для чего.


Для хранения, передачи данных например. Но не для декларации сущностей.

AVK>Редакторы, поддерживающие xsd отображают в соответствии с xsd. Это как минимум базовые взаимосвязи и валидация значений. Для более сложных случаев можешь поглядеть на InfoPath. Для совсем запущенных случаев придется писать свой редактор, а в таком варианте XML безусловно удобнее.


Будь все так просто, рулил бы С#+XML или Java+XML. А посмотри, какие тененции — в жаву и нет пихают все, что не лень.

PE>>На основании того, что уже сделано.

AVK>Ну вобщем поступай как знаешь. Я на основании своего опыта тебе примерное направление показал.

Я же сказал, что XML для промежуточных данных подходит. А человеку удобнее работать с языком, в котором меньшая избыточность будет и специализированые фичи.
Re[69]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.03.04 12:31
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>Редакторы, поддерживающие xsd отображают в соответствии с xsd. Это как минимум базовые взаимосвязи и валидация значений. Для более сложных случаев можешь поглядеть на InfoPath. Для совсем запущенных случаев придется писать свой редактор, а в таком варианте XML безусловно удобнее.


PE>Будь все так просто, рулил бы С#+XML или Java+XML.


А он и рулит. Для определенных задач. JSP и ASP.NET к примеру почти что оно и есть. А XAML точно оно.

PE> А посмотри, какие тененции — в жаву и нет пихают все, что не лень.


В смысле?

PE>Я же сказал, что XML для промежуточных данных подходит.


Ну а мой опыт говорит об обратном. Почему не подходит я от тебя так и не услышал. Аргументы типа "не для этого создан" не катят. Для чего он создан написано на w3c.org.

PE> А человеку удобнее работать с языком, в котором меньшая избыточность будет и специализированые фичи.


Не все так просто. Твой специальный язык человеку придется специально изучать. + неизбежные глюки при самопальной реализации. + необходимость в обязательном порядке собственного редактора. Вобщем специальный язык это крайне дорогое решение, как при разработке так и при использовании.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[70]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.03.04 12:54
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Будь все так просто, рулил бы С#+XML или Java+XML.

AVK>А он и рулит. Для определенных задач. JSP и ASP.NET к примеру почти что оно и есть. А XAML точно оно.

PE>> А посмотри, какие тененции — в жаву и нет пихают все, что не лень.

AVK>В смысле?

Языки всякие например.

PE>> А человеку удобнее работать с языком, в котором меньшая избыточность будет и специализированые фичи.


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


Сам XML изучать не нужно. Но нужно будет запоминать все аттрибуты, их порядок, регистр, значения атрибутов и ограничения всякие.
Сравни

<entyty name="Node" base="BaseVertex" implements="Names">
<relation name="NodeEnds" type="NodeEnd" auto="autocollection" validation="Node.Validators"/>
</entyty>

entity Node : BaseVertex, Names
{
  relation NodeEnd NodeEnds
  {
    tYpe = collection; 
    auTo = yes;
    validation=Node.Validators; 
    ...
  }
}
Re[71]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.03.04 13:51
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>>> А посмотри, какие тененции — в жаву и нет пихают все, что не лень.

AVK>>В смысле?

PE>Языки всякие например.


Я же тебе сказал — любая технология хороша в своей области. И не везде императивные языки лучше. Например для кодогенератора XSLT шаблон обычно значительно лаконичнее программы на том же шарпе или джаве. В общем случае чем менее универсально инструментальное средство тем выгоднее декларативное представление. Если в общем случае основная часть модели требует императивного выражения, однако есть и части, которые можно задать декларативно обычно добавляют средства декларативного программирования в императивный язык. Например атрибуты в дотнете. Если же ситуация обратная в декларативное описание добавляют код. Например, как я уже говорил, ASP.NET. Причем, обрати внимание, там есть два разных способа добавления императивной части — embedded код и code behind. Второе применяется когда необходим большой объем кода.
В случае генераторов как правило основная часть исходных данных задается декларативно, иначе просто генератор лишен смысла. Отсюда и XML обычно очень неплохо подходит для этих целей.

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


PE>Сам XML изучать не нужно.


Основные принципы XML можно изложить на одной страничке. Кроме того, как ты правильно написал, это стандарт. Поэтому есть немалый шанс что человек уже будет с ним знаком.

PE> Но нужно будет запоминать все аттрибуты,


Нет конечно, это справочная информация.

PE> их порядок,


Это вобще не нужно. Если у тебя что то зависит от порядка атрибутов то это очень криво.

PE> регистр, значения атрибутов и ограничения всякие.

PE>Сравни

PE>
PE><entyty name="Node" base="BaseVertex" implements="Names">
PE>  <relation name="NodeEnds" type="NodeEnd" auto="autocollection" validation="Node.Validators"/>
PE></entyty>

PE>entity Node : BaseVertex, Names
PE>{
PE>  relation NodeEnd NodeEnds
PE>  {
PE>    tYpe = collection; 
PE>    auTo = yes;
PE>    validation=Node.Validators; 
PE>    ...
PE>  }
PE>}
PE>


Сравнил. Второй вариант для стороннего человека однозначно сложнее. Ты опять делаешь ту же самую ошибку — это для тебя ; в конце строки естественна и не вызывает вопросов. Это для тебя . отделяет классы от атрибутов. Это для тебя применение {} для блоков интуитивно понятно.
Поэтому понять первый вариант не программисту заметно проще. А если еще к нему xsd написать и воспользоваться специализированным редактором, то редактировать данные в гриде сможет совсем уж далекий от программирования человек. Для второго же варианта нужно быть программистом, причем на С-like языке.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[73]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 16.03.04 15:51
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>Я же тебе сказал — любая технология хороша в своей области. И не везде императивные языки лучше. Например для кодогенератора XSLT шаблон обычно значительно лаконичнее программы на том же шарпе или джаве.


PE>Шаблон генерации в HTML очень похож на этот самый HTML. А если захочешь гнать XML в С#, то шаблон будет очень похож на C#.


Я тебе говорю про C#. ПО факту XSLT намного удобнее в таких задачах.

AVK>>Это вобще не нужно. Если у тебя что то зависит от порядка атрибутов то это очень криво.


PE>Для XML нужны схемы данных.


Необязательно.

PE> Это там порядок указывается и регистр.


Только по желанию. А регистр как таковой вобще не указывается, XML чувствителен к регистру.

PE>В одном случае придется писать редактор, во втором — просто перегонять в XML, с которым и будет работать генератор.


С точностью до наоборот. Твой самопальный язык придется редактировать в ноутпаде, без подсветки синтаксиса. А xml можно редактировать в каком нибудь XmlSpy с куда большим комфортом.

PE> Но человеку XML не нужно знать.


Я помнится уже говорил что знаний там на страничку не наберется.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[74]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.03.04 16:07
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Шаблон генерации в HTML очень похож на этот самый HTML. А если захочешь гнать XML в С#, то шаблон будет очень похож на C#.

AVK>Я тебе говорю про C#. ПО факту XSLT намного удобнее в таких задачах.

Удобнее, но не в нашей.

AVK>>>Это вобще не нужно. Если у тебя что то зависит от порядка атрибутов то это очень криво.


PE>>Для XML нужны схемы данных.


AVK>Необязательно.


Это как же ты собираешь подсунуть челу редактировать XML без схем ?

AVK>Только по желанию. А регистр как таковой вобще не указывается, XML чувствителен к регистру.


Вот и я про то. Надо помнить все подряд. А свой язык можно упростить очень сильно.

AVK>С точностью до наоборот. Твой самопальный язык придется редактировать в ноутпаде, без подсветки синтаксиса. А xml можно редактировать в каком нибудь XmlSpy с куда большим комфортом.


Почему в нотепаде ? Парсинг языка вроде Паскаля — плевое дело. На третьем курсе студенты это делают.
Могу выслать компилер Модулы. Гы.
Re[75]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.03.04 07:24
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>Я тебе говорю про C#. ПО факту XSLT намного удобнее в таких задачах.


PE>Удобнее, но не в нашей.


Тебе виднее.

AVK>>Необязательно.


PE>Это как же ты собираешь подсунуть челу редактировать XML без схем ?


А в чем проблема?

AVK>>Только по желанию. А регистр как таковой вобще не указывается, XML чувствителен к регистру.


PE>Вот и я про то. Надо помнить все подряд. А свой язык можно упростить очень сильно.


Сильнее XML вряд ли получится

AVK>>С точностью до наоборот. Твой самопальный язык придется редактировать в ноутпаде, без подсветки синтаксиса. А xml можно редактировать в каком нибудь XmlSpy с куда большим комфортом.


PE>Почему в нотепаде ? Парсинг языка вроде Паскаля — плевое дело.


А, ну ну. Значит схему написать это жутко долго, а вот отпарсить язык плевое дело.

PE> На третьем курсе студенты это делают.


То что они делают только для учебных целей и годится. А на практике чтобы получить production quality парсер даже несложного языка надо изрядно попахать. Вот тот же XML, казалось бы там парсер можно за полдня на коленке написать, а на практике даже для такого парсера придется попахать от души.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[76]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.03.04 08:02
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Это как же ты собираешь подсунуть челу редактировать XML без схем ?

AVK>А в чем проблема?

Собственно в валидации.

AVK>>>Только по желанию. А регистр как таковой вообще не указывается, XML чувствителен к регистру.


PE>>Вот и я про то. Надо помнить все подряд. А свой язык можно упростить очень сильно.


AVK>Сильнее XML вряд ли получится


Я уже говорил, что XML это примитивный язык. Простота — это немного другое.


PE>>Почему в нотепаде ? Парсинг языка вроде Паскаля — плевое дело.

AVK>А, ну ну. Значит схему написать это жутко долго, а вот отпарсить язык плевое дело.

Нет. Схему еще проще. Для редактирования XML придется свой редактор писать. Вот я про что.

AVK>То что они делают только для учебных целей и годится. А на практике чтобы получить production quality парсер даже несложного языка надо изрядно попахать. Вот тот же XML, казалось бы там парсер можно за полдня на коленке написать, а на практике даже для такого парсера придется попахать от души.


На практике пахать не нужно. Можно брать готовое.
Re[78]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.03.04 08:39
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ну так способ задания валидации при помощи схемы куда проще обработки ошибок в парсере.


Проще, но толку ? Нагляднее XML от этого не станет.

PE>>Я уже говорил, что XML это примитивный язык. Простота — это немного другое.

AVK>Это все игра словами и ничего более.

Я уже приводил примеры. Ты разницу видел. Наш продукт — объектная модель данных(результат работы генератора), а не редактор или XML или еще что.
Посему лучше использовать специализированое средство.

AVK>>>А, ну ну. Значит схему написать это жутко долго, а вот отпарсить язык плевое дело.


PE>>Нет. Схему еще проще.


AVK>Причем намного. О том и речь.


PE>> Для редактирования XML придется свой редактор писать. Вот я про что.

AVK>А для своего языка типа не надо? Впрочем меня пока XmlSpy устраивал по большей части.

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

PE>>На практике пахать не нужно. Можно брать готовое.

AVK>А готовое и есть XML.

Ну ты просто фанат по XML. Всему свое место. XML это не панацея. Читать его ез специфического редактора вообще невозможно. Аддон для студии и специализированый редактор XML — разные вещи.
Re[79]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.03.04 08:56
Оценка:
Здравствуйте, 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 умеет работать и таким манером.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[80]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.03.04 09:21
Оценка:
Здравствуйте, 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" ?
Re[81]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.03.04 09:36
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Ты сказал, что XML с редактором удобнее для непрограммиста. Таких у нас не будет, ибо средство для внутреннего использования. Посему такие удобства сомнительны.


Тебе виднее.

AVK>>Видел. XML вариант мне понравился куда больше.


PE>Это самы простой пример, что пришел в голову.

PE>Для описания импорта-экспорта XML понимает только тот чел, который писал этот импорт-экспорт.
PE>Вот такие дела.

Я писал. Вот такие дела.

PE>Мне нужно все лишь раскраска текста. А XML никак не сможет помочь. Если ты заметил, язык будет с объектнориентированым уклоном. Какие преимущества здесь XML дает, extends="BaseClass" ?


И все таки я тебя не пойму. XML тебе не нравится, потому что слишком примитивно. Свой язык не нравится потому что слишком сложно. В итоге ты выбрал самое худшее из возможных решений — написание классов ручками.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[82]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.03.04 09:45
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Это самы простой пример, что пришел в голову.

PE>>Для описания импорта-экспорта XML понимает только тот чел, который писал этот импорт-экспорт.
PE>>Вот такие дела.

AVK>Я писал. Вот такие дела.


Писать можно, не спорю.

PE>>Мне нужно все лишь раскраска текста. А XML никак не сможет помочь. Если ты заметил, язык будет с объектнориентированым уклоном. Какие преимущества здесь XML дает, extends="BaseClass" ?


AVK>И все таки я тебя не пойму. XML тебе не нравится, потому что слишком примитивно. Свой язык не нравится потому что слишком сложно. В итоге ты выбрал самое худшее из возможных решений — написание классов ручками.


Я не выбирал. Я девелопер. Сверху сказали — .Net+C#.

Есть язык разметки сетей http://giga.dia.uniroma3.it/~ivan/NetML/publications/Ripe-47-04-02-01.pps

Это годится для описания сетей. А вот модель сети посложнее будет. И нужен объектно-ориентированный подход.
Re[83]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.03.04 10:56
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Я не выбирал. Я девелопер. Сверху сказали — .Net+C#.


Для генератора? Странные у тебя начальники.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[84]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.03.04 10:57
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Я не выбирал. Я девелопер. Сверху сказали — .Net+C#.


AVK>Для генератора? Странные у тебя начальники.


Для проекта. Наш продукт повторяю, объектная модель сети. Фреймворк неслабый.
Re[85]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.03.04 11:18
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>Для генератора? Странные у тебя начальники.


PE>Для проекта.


Я вобще то про генератор все это время говорил, а не про проект.

PE> Наш продукт повторяю, объектная модель сети. Фреймворк неслабый.


Не, ну такое ощущение что ты один серьезные вещи пишешь, а остальные дурака валяют. Сложности есть везде. И в возможность их решать как раз и есть один из главных скиллов программиста.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[86]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.03.04 11:27
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>> Наш продукт повторяю, объектная модель сети. Фреймворк неслабый.

AVK>Не, ну такое ощущение что ты один серьезные вещи пишешь, а остальные дурака валяют. Сложности есть везде. И в возможность их решать как раз и есть один из главных скиллов программиста.

Ого, куда тебя понесло. Я просто повторил на том случай, если ты не понял, что не генератор и редактор текста являются продуктами.

Язык должен четко отражать предметную область. Просто набор ключевых слов не годится.
Поскольку фреймворк достаточно большой, особых преимуществ в XML я не вижу.
Re[87]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.03.04 11:56
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Ого, куда тебя понесло. Я просто повторил на том случай, если ты не понял, что не генератор и редактор текста являются продуктами.


Тем более непонятно при чем тут требование начальства.

PE>Язык должен четко отражать предметную область. Просто набор ключевых слов не годится.

PE>Поскольку фреймворк достаточно большой, особых преимуществ в XML я не вижу.

Поэтому пишете все руками вместо написания генератора?
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[88]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.03.04 12:06
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Ого, куда тебя понесло. Я просто повторил на том случай, если ты не понял, что не генератор и редактор текста являются продуктами.


AVK>Тем более непонятно при чем тут требование начальства.


Сам продукт должен быть на дотнете. Начальство затребовало С#. Вот и все. Непонятно — дам мыло, спросишь у них сам.

PE>>Язык должен четко отражать предметную область. Просто набор ключевых слов не годится.

PE>>Поскольку фреймворк достаточно большой, особых преимуществ в XML я не вижу.

AVK>Поэтому пишете все руками вместо написания генератора?

Частично руками. То, что не получается генерировать, руками. На XML не намного то и меньше.
Re[89]: C++ versus C#
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 17.03.04 12:26
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

AVK>>Тем более непонятно при чем тут требование начальства.


PE>Сам продукт должен быть на дотнете. Начальство затребовало С#. Вот и все.


Нет, мне непонятно другое — при чем тут это если речь о генераторе и данных для него?

AVK>>Поэтому пишете все руками вместо написания генератора?

PE>Частично руками. То, что не получается генерировать, руками.

А как же тогда 600 ручных классов? Больно много что то у вас получается руками.

PE> На XML не намного то и меньше.


Тебе виднее.
... << RSDN@Home 1.1.3 stable >>
AVK Blog
Re[90]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.03.04 13:05
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Нет, мне непонятно другое — при чем тут это если речь о генераторе и данных для него?


Вот с чего началось

AVK>И все таки я тебя не пойму. XML тебе не нравится, потому что слишком примитивно. Свой язык не нравится потому что слишком сложно. В итоге ты выбрал самое худшее из возможных решений — написание классов ручками.

Я не выбирал. Я девелопер. Сверху сказали — .Net+C#.


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

Сейчас, поскольку базовые классы уже на С#, С++ уже нет смысла использовать. Теперь я пробую оформить генерацию модели в Шарп. Модель задавать на XML громоздко, посему его думаю юзать лишь как промежуточный язык — его орабатывать проще.
Так понятно ?
Re[90]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.03.04 13:33
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>А как же тогда 600 ручных классов? Больно много что то у вас получается руками.


Блин. Все классы создавались по UML. Потом на них был напущет постпроцессор жавовский.
На выходе поимели коллекции, и кучу кода, который не нужно руками писать.
Потом заполнили кой-какие методы и все.
Re[58]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.03.04 18:07
Оценка:
Здравствуйте, 011, Вы писали:

011>Modelica?


Нечто вроде. Только Моделика слишком сложная. А в нашей области ничего нет такого.


P.S. Откуда музыку достаешь ?
Re[59]: C++ versus C#
От: 011  
Дата: 22.03.04 18:37
Оценка:
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
Posted via RSDN NNTP Server 1.8 beta
Re[60]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.03.04 18:41
Оценка:
Здравствуйте, 011, Вы писали:

PE>> 011>Modelica?

PE>> Нечто вроде. Только Моделика слишком сложная. А в нашей
PE>> области ничего нет такого.

011>Она не сложнее, чем C++. Правда, к ней шароварных компиляторов не найти. Был проект OpenModelics, но кажется умер.


По сравнению с С++ это совсем просто. Все дело именно в компиляторе и внешнем интерфейсе.
Вот это и есть засада.

Хорошо, что ты пришел, а то AVK заладил про XML.


PE>> P.S. Откуда музыку достаешь ?

011>Приносят. &)

Скажи, пусть и мне принесут
Re[23]: C++ versus C#
От: Mr.ToNik Россия http://sinstr.ru
Дата: 07.04.04 17:41
Оценка:
Здравствуйте, 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#
Re[13]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.04.04 04:21
Оценка:
Здравствуйте, <Аноним>, Вы писали:
А>Так это и чертовски удобно — отладил модуль и используешь его.
А что мешает в шарпе отладить и использовать?
А>Реализация не мешает (дурацкие редакторы в 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>А что мешает в шарпе отладить и использовать?
Извини, хотел сказать, что для использования класса мне нет надобности смотреть его реализацию. Лично мне кажется, что это удобнее — код не мешает.
Re[15]: C++ versus C#
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.04.04 06:52
Оценка:
Здравствуйте, <Аноним>, Вы писали:
А>Извини, хотел сказать, что для использования класса мне нет надобности смотреть его реализацию. Лично мне кажется, что это удобнее — код не мешает.
В шарпе для использования класса обычно его реализацию тоже никто не смотрит. Заголовочную информацию показывает 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++, за исключением шаблонов, более ограниченный язык.
Re[6]: Вопрос слегка не в тему
От: Воронков Василий Россия  
Дата: 18.04.04 16:45
Оценка:
Здравствуйте, <Аноним>, Вы писали:

А>Так 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>
CS>for (int i=0; i<N; i++) 
CS>{
CS>  if((i & 1) == 0)
CS>     StringBuffer1.Append("hello");
CS>  else
CS>     StringBuffer2.Append("hello!");
CS>}
CS>


Тест некорректный. правильно будет так:
for ( int i = 0; i != N; ++i )
{
  if((i & 1) == 0)
     StringBuffer1.Append("hello");
  else
     StringBuffer2.Append("hello!");
} // for


Тогда время оценки цикла более чистое, соответственно преимущество С++ по эффективности еще более отчетливое.
Re[8]: Вопрос слегка не в тему
От: Воронков Василий Россия  
Дата: 19.04.04 18:18
Оценка:
Здравствуйте, <Аноним>, Вы писали:

ВВ>>C++-то как раз куда менее ограниченный чем C#.

А>Мы про язык? Тогда считаем:
А>1. Атрибуты.
А>2. Сборщик муссора.
А>3. Отражения.
А>4. foreach
А>5. Мощный строковый тип
А>6. Многомерные массивы, массивы массивов
А>7. Делегаты, цепочки делегатов.
А>8. События.
А>9. SEH.
А>10. Параметризованные/непараметризованные свойства + наследование свойств.
А>11. Тип 128-битный тип decimal

Большая часть из того, что вы перечислили к _языку_ C# имеет весьма опосредованное отношение, а то и не имеет вовсе.

ВВ>>Зато вот Win32 куда более ограниченная платформа чем .NET

А>Да-да, крокодил больше длинный, чем зеленый... Проходили.

По-моему, все-таки больше зеленый, чем длинный.
... << RSDN@Home 1.1.3 stable >>
Re[9]: Вопрос слегка не в тему
От: kuj  
Дата: 19.04.04 21:41
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>>>C++-то как раз куда менее ограниченный чем C#.

А>>Мы про язык? Тогда считаем:
А>>1. Атрибуты.
А>>2. Сборщик муссора.
А>>3. Отражения.
А>>4. foreach
А>>5. Мощный строковый тип
А>>6. Многомерные массивы, массивы массивов
А>>7. Делегаты, цепочки делегатов.
А>>8. События.
А>>9. SEH.
А>>10. Параметризованные/непараметризованные свойства + наследование свойств.
А>>11. Тип 128-битный тип decimal

ВВ>Большая часть из того, что вы перечислили к _языку_ C# имеет весьма опосредованное отношение, а то и не имеет вовсе.

Открываете спецификацию C# и убеждаетесь в его правоте. Все (кроме, разве что, отражений) вышеперечисленные понятия имеют непосредственное отношение к языку C#.
... << RSDN@Home 1.1.3 beta 1 >>
Re[10]: Вопрос слегка не в тему
От: Воронков Василий Россия  
Дата: 20.04.04 06:36
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>Открываете спецификацию C# и убеждаетесь в его правоте. Все (кроме, разве что, отражений) вышеперечисленные понятия имеют непосредственное отношение к языку C#.


При этом все это реализовано на уровне библиотек.
Re[12]: Вопрос слегка не в тему
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.04.04 17:45
Оценка:
Здравствуйте, 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 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Вопрос слегка не в тему
От: Воронков Василий Россия  
Дата: 20.04.04 17:47
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, Воронков Василий, Вы писали:


kuj>>>Открываете спецификацию C# и убеждаетесь в его правоте. Все (кроме, разве что, отражений) вышеперечисленные понятия имеют непосредственное отношение к языку C#.


ВВ>>При этом все это реализовано на уровне библиотек.

kuj>Свойства,

Ну свойства это язык

kuj>атрибуты,


System.Attribute (mscorlib.dll)

kuj>отражения?


System.Reflection.* (mscorlib.dll)

kuj>Да, а еще хотелось бы урл на полноценный эфемерный сборщик муссора с дефрагментацией кучи, масштабируемый на многопроцессорной системе и отдельной кучей для больших объектов.


System.GC (mscorlib.dll)

Далее.

4. foreach

System.Collections.IEnumerator, System.Collections.IEnumerable (mscorlib.dll)

5. Мощный строковый тип

System.String (mscorlib.dll)

6. Многомерные массивы, массивы массивов

System.Array (mscrolib.dll)

7. Делегаты, цепочки делегатов.

System.Delegate, System.MulticastDelegate (mscorlib.dll)

8. События.

Реализованы на делегатах

9. SEH.

Частично — полная типизация исключений (System.Exception)

10. См. выше

11. Тип 128-битный тип decimal

System.Decimal (mscorlib.dll)
... << RSDN@Home 1.1.3 stable >>
Re[13]: Вопрос слегка не в тему
От: kuj  
Дата: 20.04.04 18:23
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

kuj>>>>Открываете спецификацию C# и убеждаетесь в его правоте. Все (кроме, разве что, отражений) вышеперечисленные понятия имеют непосредственное отношение к языку C#.


ВВ>>>При этом все это реализовано на уровне библиотек.

kuj>>Свойства,
ВВ>Ну свойства это язык

kuj>>атрибуты,

ВВ>System.Attribute (mscorlib.dll)
Стоп-стоп! Речь ведь о C++, а не о managed C++. Это два разных языка. А managed языки отличаются очень незначительно.

ВВ>8. События.

ВВ>Реализованы на делегатах
Но поддержка со стороны языка в виде ключевого слова event.
... << RSDN@Home 1.1.3 stable >>
Re[13]: Вопрос слегка не в тему
От: kuj  
Дата: 20.04.04 18:23
Оценка:
Здравствуйте, Sinclair, Вы писали:

kuj>>Свойства, атрибуты, отражения? Можно узнать урлы библиотек, реализующих это?

S>Свойства — нет, это фича компилятора.
S>System.Attribute лежит в Mscorlib.dll
Хм , если бы Вы внимательно перечитали тред, то заметили бы, что на протяжении всего треда речь шла о сопоставлении "unmanaged" C++ и C#. Естественно, managed C++ от C# функционально почти не отличается. С этим никто по-моему и не спорил.
... << RSDN@Home 1.1.3 stable >>
Re[14]: Вопрос слегка не в тему
От: Воронков Василий Россия  
Дата: 20.04.04 18:27
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>>>атрибуты,

ВВ>>System.Attribute (mscorlib.dll)
kuj>Стоп-стоп! Речь ведь о C++, а не о managed C++. Это два разных языка. А managed языки отличаются очень незначительно.

A причем здесь вообще С++? Мы же о C# говорим.
... << RSDN@Home 1.1.3 stable >>
Re[15]: Вопрос слегка не в тему
От: kuj  
Дата: 20.04.04 18:53
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

kuj>>>>атрибуты,

ВВ>>>System.Attribute (mscorlib.dll)
kuj>>Стоп-стоп! Речь ведь о C++, а не о managed C++. Это два разных языка. А managed языки отличаются очень незначительно.

ВВ>A причем здесь вообще С++? Мы же о C# говорим.


Хм... Просмотреть ветку треда внимательно сложно было?

Напоминаю:

А>>Ясно) Интересно, что у тебя за проект, и почему его решили на шарпе писать?)

V>Много всяких. От всякого бухгалтерского дерьма, систем обработки заказов, до оптимизаций грузоперевозок. Шарп используется, потому что на нём удобно проектировать сложные проекты. Я понимаю, что проектирование и язык программирования суть разные вещи, я имею ввиду в шарпе удобно спроектированные конструкции воплощать. Эвенты, делегаты, сборщик мусора, аттрибуты, большая библиотека классов и ограниченность языка по сравнению с С++ -- всё это
делает проект дешевле. С другой стороны, меня тошнит уже. Но бизнес есть бизнес.

Так C++, за исключением шаблонов, более ограниченный язык.

... << RSDN@Home 1.1.3 stable >>
Re[16]: Вопрос слегка не в тему
От: Воронков Василий Россия  
Дата: 20.04.04 19:15
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>Так C++, за исключением шаблонов, более ограниченный язык.


В ответ на что я написал, что это C# более ограниченный язык. А фичи C#, о которых вы говорите, являются фичам платформы .NET, и к языку имеют весьма опосредованное отношение.
... << RSDN@Home 1.1.3 stable >>
Re[14]: Вопрос слегка не в тему
От: Sinclair Россия https://github.com/evilguest/
Дата: 21.04.04 10:06
Оценка:
Здравствуйте, kuj, Вы писали:
kuj>Хм , если бы Вы внимательно перечитали тред, то заметили бы, что на протяжении всего треда речь шла о сопоставлении "unmanaged" C++ и C#. Естественно, managed C++ от C# функционально почти не отличается. С этим никто по-моему и не спорил.
Я вообще ничего про managed мы unmanaged не говорил. Вы спросили урл библиотеки, которая реализует функциональность, предоставленную (по вашему мнению) C#. Вот я вам его и дал.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: Вопрос слегка не в тему
От: kuj  
Дата: 21.04.04 20:42
Оценка:
Здравствуйте, Sinclair, Вы писали:

kuj>>Хм , если бы Вы внимательно перечитали тред, то заметили бы, что на протяжении всего треда речь шла о сопоставлении "unmanaged" C++ и C#. Естественно, managed C++ от C# функционально почти не отличается. С этим никто по-моему и не спорил.

S>Я вообще ничего про managed мы unmanaged не говорил. Вы спросили урл библиотеки, которая реализует функциональность, предоставленную (по вашему мнению) C#. Вот я вам его и дал.
Спасибо конечно, но, боюсь, что unmanaged (который ANSI) C++ эту библиотеку не поймет. Так что ваш ответ, мягко говоря, был э-э-э.. "мимо тазика".
... << RSDN@Home 1.1.3 stable >>
Re[16]: Вопрос слегка не в тему
От: Sinclair Россия https://github.com/evilguest/
Дата: 22.04.04 03:02
Оценка:
Здравствуйте, kuj, Вы писали:
kuj>Спасибо конечно, но, боюсь, что unmanaged (который ANSI) C++ эту библиотеку не поймет. Так что ваш ответ, мягко говоря, был э-э-э.. "мимо тазика".
Так, проблемы с reading skills. Попробую объяснить поподробнее:
1. Спор зашел о том, какой из языков более ограничен
2. Василий утверждает, что C#.
3. Аноним пытется привести в опровержение список фич, которых нет в С++
4. Василий отвечает ему, что в C# этих фич тоже нет.
5. Ты начинаешь ссылаться на спецификации С#
6. Василий намекает, что почти все из упомянутого, реализуется не C#, а библиотеками.
7. Ты требуешь их предъявить.
Ну вот я и предъявил. А теперь ты начинаешь делать вид, что говорил про библиотеки для С++. Не было такого.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.04.04 03:07
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>В ответ на что я написал, что это 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.04.04 03:09
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>Понятно. А вот это здесь
Автор: kuj
Дата: 20.04.04
сообщение ты написал видно под принуждением.


Думаю, он имел в виду библиотеки которые позволи ли бы реализовать все это для анменеджед С++.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.04.04 03:40
Оценка:
Здравствуйте, 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: Вопрос слегка не в тему
От: kuj  
Дата: 22.04.04 17:10
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Безспорно реализация многих фич дотнета связана с CLR и FCL, но ведь язык от этого языком быть не перестает.


VD>Я так полностью согласен с тем, что Шарп богаче С++. Есть только несколько фич которых нет в Шарпе, но есть в С++:

VD>1. Деструкторы (так они ненужны, да и кое что есть)
Есть и в C#. Даже синтаксис такой же.
VD>2. Множественное наследование (приятная фича для подключения реализаций)
Есть множественное интерфейсное наследование.
VD>3. Шаблоны (частично будут компенсированы в Шарпе 2)
Почему частично?
VD>4. Const для как ограничитель модифицируемости переменных (в общем фигня, жить не мешает, даже упрощает жизнь).
const тоже есть.
VD>7. typedef
А зачем?
VD>8. Сложные макросы
Зачем?
VD>9. Большая совместимость с С.
... << RSDN@Home 1.1.3 stable >>
Re[18]: Вопрос слегка не в тему
От: kuj  
Дата: 22.04.04 17:36
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Если считать по количеству фич, то это факт. Другое дело, что фичи вроде Шаблонов и МН могут многое перевесить.

По поводу шаблонов абсолютно согласен. Но есть ведь МИН. Зачем еще обычное МН? Нет, не спорю, МН может пригодится, но так ли часто? К тому же, само по себе оно весь небезопасно...
... << RSDN@Home 1.1.3 stable >>
Re[19]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.04.04 18:21
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>По поводу шаблонов абсолютно согласен. Но есть ведь МИН. Зачем еще обычное МН? Нет, не спорю, МН может пригодится, но так ли часто? К тому же, само по себе оно весь небезопасно...


Я не знаю что значит И в МИН. А по поводу МН... дорого яичко к христову дню. Само МН не в полном объеме может и не нужно. А вот подключение готовых реализаций (совместно с шаблонами) которое оно позволяет делать очень даже полезно. Правда в R#-е это уже делается и без МН. Да и других способов обхъода проблемы много, но в C# их нет. Вернее есть самые некрасивые и трудоемкие решения.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.04.04 18:21
Оценка:
Здравствуйте, 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Вопрос слегка не в тему
От: kuj  
Дата: 23.04.04 11:59
Оценка:
Здравствуйте, VladD2, Вы писали:

kuj>>По поводу шаблонов абсолютно согласен. Но есть ведь МИН. Зачем еще обычное МН? Нет, не спорю, МН может пригодится, но так ли часто? К тому же, само по себе оно весь небезопасно...


VD>Я не знаю что значит И в МИН.

Интерфейсное — множественное интерфейсное наследование. Или под МН подразумевалось нечто иное?
VD>А по поводу МН... дорого яичко к христову дню. Само МН не в полном объеме может и не нужно. А вот подключение готовых реализаций (совместно с шаблонами) которое оно позволяет делать очень даже полезно.
Э-э, реализаций чего?
VD>Правда в R#-е это уже делается и без МН. Да и других способов обхъода проблемы много, но в C# их нет. Вернее есть самые некрасивые и трудоемкие решения.
Еще раз, МН — множественное наследование?
Re[21]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.04.04 13:06
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>Интерфейсное — множественное интерфейсное наследование.


И почему МИН? Тогда уж МНИ или ИМН.

kuj>Или под МН подразумевалось нечто иное?


Оно самое.

kuj>Э-э, реализаций чего?


Класса.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[22]: Вопрос слегка не в тему
От: kuj  
Дата: 23.04.04 20:44
Оценка:
Здравствуйте, VladD2, Вы писали:

kuj>>Интерфейсное — множественное интерфейсное наследование.

VD>И почему МИН? Тогда уж МНИ или ИМН.
А какая разница?
... << RSDN@Home 1.1.3 stable >>
Re[23]: Вопрос слегка не в тему
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.04.04 21:12
Оценка:
Здравствуйте, kuj, Вы писали:

VD>>И почему МИН? Тогда уж МНИ или ИМН.

kuj>А какая разница?

А как угадать то?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[61]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.04.04 23:34
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Хорошо, что ты пришел, а то AVK заладил про XML.


Это он любит.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[59]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.04.04 23:34
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>На основе XML неудобно. Я думаю, что это может быть нечто вроде С-подобного языка такого плана.


Кстати, R# уже кое-как работает. Так что можешь попробовать его.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[62]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.04.04 23:34
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>> Смотри в IDL.


AVK>Вот смотрел, потому и говорю. WSDL удобнее, более масштабируемо и мощнее.


WSDL то удобнее? Не, ну, ты уже просто пухнеш от этого эксемеля. Блни, эдак и к ассемблеру можно привыкнуть.

Я конечно согласен, что его проблемы нужно решать декларациямии и генератором по ним, но так же соглашусь с Plutonia, что декларировать будет куда удобнее на декларативной части С-подобного языка. Она кстати, тоже исключительно для деклараций предназначена. А если это будет Шарп с его атрибутами, то и проблем не будет.

ЗЫ

2Plutonia: Може правда возмешь R# и попробуешь что-нить на нем слабать? За одно мне идей подкинешь...
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[80]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.04.04 23:59
Оценка:
Здравствуйте, AndrewVK, Вы писали:

PE>>Ну ты просто фанат по XML.


AVK>Нет, скорее ты С++.


Не деритесь, я вас рассужу...

Вы оба фанаты. Один С(с чем-нить), другой ХМЛ-я.

И спорить любите.

По сути вы пришли к главному выводу: схему лучше описывать декларативно, а код генерировать.

Что исопльзовать для описания ХМЛ или некий дургой язык не так важно.

Если пользователь будет программистом, то конечно предпочтительнее свой языкх.
Если нет, то возможно вообще лучшим выходом будет создание БД для хранения описания и генеарция кода на ее базе.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[60]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.04.04 11:14
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>На основе XML неудобно. Я думаю, что это может быть нечто вроде С-подобного языка такого плана.

VD>Кстати, R# уже кое-как работает. Так что можешь попробовать его.

Опробовать можно, почему бы и нет ?
Re[63]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.04.04 11:17
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>ЗЫ


VD>2Plutonia: Може правда возмешь R# и попробуешь что-нить на нем слабать? За одно мне идей подкинешь...


Что-нить понятие весьма растяжимое. Я не знаю, что тебя интересует, но успел уяснить, что области у нас с тобой и АВК совершенно различные. У меня десктоп приложения, модель данных и тд. Еще вот серилизацией занялись.
Re[61]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.04.04 22:51
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

VD>>Кстати, R# уже кое-как работает. Так что можешь попробовать его.


PE>Опробовать можно, почему бы и нет ?


Могу подключить к ЦВС.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[64]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.04.04 22:51
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Что-нить понятие весьма растяжимое. Я не знаю, что тебя интересует, но успел уяснить, что области у нас с тобой и АВК совершенно различные. У меня десктоп приложения, модель данных и тд. Еще вот серилизацией занялись.


R# — это не область. Это универсальная технология.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[62]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.04.04 08:45
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>Опробовать можно, почему бы и нет ?

VD>Могу подключить к ЦВС.

А без ЦВС нельзя ? У меня нет доступа на внешние ЦВС. Только если из дому, то там у меня канал очень тонкий.
Вообще, попробовать можно, .
Re[63]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.04.04 12:45
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>А без ЦВС нельзя ? У меня нет доступа на внешние ЦВС. Только если из дому, то там у меня канал очень тонкий.

PE>Вообще, попробовать можно, .

Ну, если только по почте отдельную версию. Но проект постоянно изменяется.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[64]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.04.04 12:55
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>Вообще, попробовать можно, .


VD>Ну, если только по почте отдельную версию. Но проект постоянно изменяется.


Тогда сделаем таким образом, если не возражаешь. Ты высылаешь на почту(ту, на которуй подписка отправляется), последнюю версию. Ну и напиши, что надо написать с помощью R#. Я так понял некое тестовое приложение ? Это лучше сюда.
А потом я попробую прикруть домой интернет нормальный.
Re[65]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.04.04 19:19
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>Тогда сделаем таким образом, если не возражаешь. Ты высылаешь на почту(ту, на которуй подписка отправляется), последнюю версию. Ну и напиши, что надо написать с помощью R#. Я так понял некое тестовое приложение ? Это лучше сюда.


Вот пишу издому. Вроде все пучком. Надо полагать, что ЦВС пройдеть.
Re[62]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.04.04 13:14
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>Опробовать можно, почему бы и нет ?


VD>Могу подключить к ЦВС.


Так что c ЦВС ?
Re[63]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.04.04 23:48
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

VD>>Могу подключить к ЦВС.


PE>Так что c ЦВС ?


Кидай логин/парлоь. Подключу.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Вопрос слегка не в тему
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 29.04.04 14:49
Оценка:
Здравствуйте, 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 >>
и солнце б утром не вставало, когда бы не было меня
Re[11]: Вопрос слегка не в тему
От: kuj  
Дата: 29.04.04 20:02
Оценка:
Здравствуйте, 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) все вышеозначенное (кроме сборщика муссора и отражений) не ново.
... << RSDN@Home 1.1.3 stable >>
Re[64]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 30.04.04 20:02
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>Так что c ЦВС ?

VD>Кидай логин/парлоь. Подключу.

ТАк что с подключением ?
Re[65]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 30.04.04 22:11
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>ТАк что с подключением ?


Я же вроде тебе по почте ответил, что логин создан...

Или это был другой Павел?
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[66]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.05.04 10:55
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>ТАк что с подключением ?

VD>Я же вроде тебе по почте ответил, что логин создан...
VD>Или это был другой Павел?

А когда ты отписал ? Вчера(пятница) вечером еще ничего не было. А сейчас я к почте доступа не имею.
Re[67]: C++ versus C#
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.05.04 13:04
Оценка:
Здравствуйте, Plutonia Experiment, Вы писали:

PE>А когда ты отписал ? Вчера(пятница) вечером еще ничего не было. А сейчас я к почте доступа не имею.


Я уж и не помню. Ну, да пробуй так. Пароль я тот что в письме был взял. Модуль называется /rsharp.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[68]: C++ versus C#
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.05.04 13:11
Оценка:
Здравствуйте, VladD2, Вы писали:

PE>>А когда ты отписал ? Вчера(пятница) вечером еще ничего не было. А сейчас я к почте доступа не имею.

VD>Я уж и не помню. Ну, да пробуй так. Пароль я тот что в письме был взял. Модуль называется /rsharp.

Все пучком, просто почта долго шла почему то. Сегодня попробую
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.