Здравствуйте, adontz, Вы писали:
A>Это не правильный подход. .Net Framework у нас один, а Си++ компиляторов много. Выбрать из них самый приличный, особенно если его делала та же фирма это правильно. А сравнивать 100 компиляторов и говорить, что если 99 гавно, то превать, что на 100м всё быстро это не правильно.
Думаю, что всем очивидно, что говорить о приемуществе в скорости конкретного языка некорректно и бессмысленно. Спорить дальше на эту тему как-то не хочется.
VD>>А возможности по оптимизации у модели JIT-компиляции куда выше.
A>Почему?
1. Известны все характиристики железа на котором будет выполняться код. Так можно учесть размер кэша и тип процессора. Так же можно специально оптимизировать код для многопроцессорных машин.
2. Приложение можно оптимизировать в целом, а не по отдельным модулям (длл-ям и т.п.). Например, можно во многих случаях можно устранить виртуальность функций, а потом некоторые из них заинлайнить.
3. Имеется возможность динамической перекомпиляции. Это позволяет использовать динамическое профилирование и на основе его результатов производить более тонкую оптимизацию.
4. Нет проблем совместимости с разными процессорами.
В общем, чем ближе к телу, тем больше желание.
A>Именно в байт-код? А то нетовские сборки и нативный код поддерживают, а МС++ нет-нет да и скомпилирует в негоь что-нибудь.
Именно. При невозможности компиляции в МСИЛ МС++ выдает варнинг, так что это хорошо видно. Да и бывает это очень редко.
A>Ну и на свалку их, пока не улучшатся.
Так в основном весь код работающий у тебя на машине ими и скомпилирован. 7-ка вещь свежая. Переход под нее будет идти еще несклько лет. Да и не все предпочитают продукцию МС. Все же ошибок у МС не мало. Да и иногда требуется переносимость.
A>А зачем по суммарному?
Затем, что единственным доказуемым фактом на сегодня является правомерность сравнеия языков программировния, а не компиляторов.
A>Вон сам утверждаешь что 90% программ пишуться на 6ке.
Чё?
A> Думаешь будет время когда 50% программ будут на Шарпе писать?
Ну, 50% на Шарпе может и не будет. Все же есть Васик и С++. Но то, что через лет 5 дотнет будет доминирующей системой разработки для Виндовс я почти уверен.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>ОК, покажи мне реальную задачу где это надо или просто пример и вообще доступно для таких тупых плюсовиков как я объясни, что такое мета-программирование, что оно так нужно и без него жизнь сереет.
Общая идея очень близка к той что эксплуатирует Александреску — модернизация возможностей языка. Только он использует для этого побочные эффекты от использования шаблонов. А я хочу получить полноценное решение не имеющее серьезных ограничений.
Это можно рассматривать под разными углами зрения:
1. Метокомпилятор — компилятор позволяющий читать код и другие источники информации и менять код перед компиляцией, получая тем самым возможность гибкой модификации и генерации кода.
2. Синтаксические макросы — мы имеем некий макроязык позволяющий намного гибче чем макросы или шаблоны производить макроподстановку.
3. Модификация возможностей компилятора. Мы получаем возможность заставлять компилятор делать то что нам нужно.
Где это можно использовать: Ну, например:
1. АОП. Когда вместо рутинного кодирования мы декларируем свои намерения.
2. Генерация кода. Например, я могу создать гибкую систему O/R Maping-а (мапинга объектов ООЯ программирования на реляционную БД. Или создать систему эффективной сериализации и/или ремоутинга.
3. Оптимизации. Я могу модифицировать код заставляя его работать быстрее. Например заинлайнить некоторые методы при некотроых условиях.
4. Изменение семантики языка. Я могу отмечать некоторые участки кода как имеющие другую семантику. Например, я могу встроить в Шарп полноценную поддержку функционального и логического программирования.
5. Создание компиляторов-компиляторов и генерация ДКА (детерминированных конечных автоматов) для решения сложных задачь.
6. Возможность использовать для генерации кода внешние источники даннях. Нарпмер, XML и БД.
В общем, опять же все возможности даже тяжело придумать.
A>Частичной, Влад, частичной, а не ручной.
Ром, почему ты считашь, что другие знают меньше тебя? Я не оговорился. Именно ручной. А частичной или полной уже не важно. Я не виноват, что в среде в котрой ты варишся не принят этот термин. Специализации создаются или человеком или компилятором. Компилятор С++ создает специализации когда встречает использование шаблона. Ну, например:
vector<int> xxx;
Человек может сделать свою, ручную специализацию. Вот побочный эффект от этого явления он и использует.
A> Создаёться впечатление, что ты никогда толком не знал Си++.
Содается впечатление, что ты неумешь уважать других людей и оценивать их знания.
A> IT со своим delete[] конечно повеселил,
В его тесте этот delete[] был совершенно не нужен. Ошибка конечно, но ровным счетом ничего не значащая. Не стоит докапываться до этой мелочи. Глупость этого теста намного больше заслуживает докапывания. Жалко что ты этого не понимаешь.
За-то эта ошибка как раз является замечательной демонстрацией ущербности модели управления памяти в С++. Человек поработавший с нормальной моделью или просто привыкший к заплаткам может сделать такую ошибку и имея за плечами 12-ти летний опыт за плечами.
A> но то механическая ошибка, аназывает он всё достаточно точно, ты же похоже даже названия не выучил, а ругаешь уже во всю. Мне бы в голову не пришло обозвать специализацию ручной.
Ну, вот такая у тебя голова.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>2. Приложение можно оптимизировать в целом, а не по отдельным модулям (длл-ям и т.п.). Например, можно во многих случаях можно устранить виртуальность функций, а потом некоторые из них заинлайнить.
Еще один момент — JIT может заинлайнить функции из другой сборки.
VD>4. Нет проблем совместимости с разными процессорами.
Здравствуйте, VladD2, Вы писали:
AVK>>А ты думал зря что ли скорость работы программ главный приоритет? На такой то технике .
VD>У Купаева машина вообще P3 650. Но даже у него хоум больше 20 сек. не грузится.
Вобще то у него Янус более чем прилично работает, сам видел.
Здравствуйте, VladD2, Вы писали:
ВВ>>Да, но от версии к версии компиляция в МСИЛ все равно наверное меняется. И на скорость по идее должно влиять.. Что бы в противном случае значил загадочный флажок оптимизации в настройках компилятора?
VD>Почти нет.
А можно узнать почему? Ведь учитывая, что, за редким исключением, меняется в основном язык, а не МСИЛ, то по логике вещей этап генерации МСИЛа должен быть более важным. Ведь вполне можно сгенерить более/менее оптимальный МСИЛ для одного и того же кода. Разные компиляторы генерят разный МСИЛ. Скорость у MC++ и C# отличается. В общем непонятно
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, oRover, Вы писали:
R>>Здравствуйте, IT, Вы писали:
R>>поделюсь своими тестами на этот счет: R>>машина — Intel Celeron 2.4 шина 400 R>>памяти — 512, дуальная (2*256) т.к. целерон, то на шине 266
VD>Тоулатин то? Вроде был на 100.
Hello, "Воронков Василий" > > А можно узнать почему? Ведь учитывая, что, за редким исключением, меняется в основном язык, а не МСИЛ, то по логике вещей этап генерации МСИЛа должен быть более важным. Ведь вполне можно сгенерить более/менее оптимальный МСИЛ для одного и того же кода. Разные компиляторы генерят разный МСИЛ. Скорость у MC++ и C# отличается. В общем непонятно
Логика генерации MSIL важна, но в некоторых случаях тяжелую работу проще переложить на "другого" парня. В случае с C# это переложили на разработчиков JIT.
Что-же касается managed C++, то просто крут. by design. Visual C++ .NET produces the best-optimized IL code of any Visual Studio .NET compiler In addition, there are some features of the .NET Framework that are only exposed by Visual C++ .NET and not by any other Visual Studio .NET language.
Posted via RSDN NNTP Server 1.8 beta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, oRover, Вы писали:
R>>без понятия. Вроде нет.
AVK>Туалатины были 100 для целеронов и 133 для пеньков. 266 ни у одного интеловского камня не было.
на материне было написано, что для целеронов шина 400, а для памяти (дуальной) — 266
Здравствуйте, TK, Вы писали:
TK>Логика генерации MSIL важна, но в некоторых случаях тяжелую работу проще переложить на "другого" парня. В случае с C# это переложили на разработчиков JIT.
TK>Что-же касается managed C++, то просто крут. by design. TK>Visual C++ .NET produces the best-optimized IL code of any Visual Studio .NET compiler TK>In addition, there are some features of the .NET Framework that are only exposed by Visual C++ .NET and not by any other Visual Studio .NET language.
Ну-ну. А сколько фич он не поддерживает — об этом видно решили умолчать. Хотя факт интересный, не знал. Правда, насколько я помню, в 1.0 C# был по-быстрее малость.
Твой пример мне тоже понятен. Никаких новых задач я не увидел. Хотя не буду отрицать что .Net вообще и C# в частности могут представлять для их решение более удобные средства по сравнению с другими языками программирования.
A>>Частичной, Влад, частичной, а не ручной.
VD>Ром, почему ты считашь, что другие знают меньше тебя? Я не оговорился. Именно ручной. А частичной или полной уже не важно. Я не виноват, что в среде в котрой ты варишся не принят этот термин. Специализации создаются или человеком или компилятором. Компилятор С++ создает специализации когда встречает использование шаблона. Ну, например: VD>vector<int> xxx; VD>Человек может сделать свою, ручную специализацию. Вот побочный эффект от этого явления он и использует.
Во-первых ты говорил о Си++ и конкретно в Си++ термин ручная специализация не только не принят но и вообще не используется. Во-вторых то что ты говоришь это частичная специализация и есть потому что она не может быть выполнена компилятором по определению. В-третьих это ещёбольшой вопрос что считать побочным эффектом. Когда Александреску писал Локи не то что частичную специализацию, сами шаблоны мало какой компилятор поддерживал, а теория шаблонов находилась в очень ранней стадии. Советовать тебе читать книги я не буду, всё равно не прочтёшь, так что поверь на слово.
Итак, я не думаю, что побочным эффектом монжно назвать стандартизированное поведение компилятора.
A>> Создаёться впечатление, что ты никогда толком не знал Си++. VD>Содается впечатление, что ты неумешь уважать других людей и оценивать их знания.
Я меня много знакомых которые и включать-то копьютер не умеют, каким это боком к уважению? А знания я оцениваю в том числе (но не только) по используемой терминологии.
A>> IT со своим delete[] конечно повеселил, VD>В его тесте этот delete[] был совершенно не нужен. Ошибка конечно, но ровным счетом ничего не значащая. Не стоит докапываться до этой мелочи. Глупость этого теста намного больше заслуживает докапывания. Жалко что ты этого не понимаешь.
Текст глупый в том смысле, что удивительно, что даже на такой просто вещи С# пусть чуть-чуть да и проиграл. Кстати свои почти 20% я получал на 7.0 и первом фреймворке. Меня больше беспокоит что если уже здесь, на фигне, началось отставание, то что потом будет?
VD>За-то эта ошибка как раз является замечательной демонстрацией ущербности модели управления памяти в С++. Человек поработавший с нормальной моделью или просто привыкший к заплаткам может сделать такую ошибку и имея за плечами 12-ти летний опыт за плечами.
Не может. Человек имеющий даже однолетний опыт работы будет использовать умные указатели. IT хотел написать по проще (понятнее) и накололся. И кстати как ты всё многообразие поведений локевского CSmartPtr с его политиками поведения запихаешь в Нет мне не ясно. А распределение памяти далеко не основная его задача.
Hello, "Воронков Василий" > > TK>Что-же касается managed C++, то просто крут. by design. > TK>Visual C++ .NET produces the best-optimized IL code of any Visual Studio .NET compiler > TK>In addition, there are some features of the .NET Framework that are only exposed by Visual C++ .NET and not by any other Visual Studio .NET language. > > Ну-ну. А сколько фич он не поддерживает — об этом видно решили умолчать. Хотя факт интересный, не знал. Правда, насколько я помню, в 1.0 C# был по-быстрее малость.
А что именно не поддерживает? В 1.1 (в 2.0)?
Posted via RSDN NNTP Server 1.8 beta
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, adontz, Вы писали:
A>Во-первых ты говорил о Си++ и конкретно в Си++ термин ручная специализация не только не принят но и вообще не используется.
user-defined specialization
A> Во-вторых то что ты говоришь это частичная специализация и есть потому что она не может быть выполнена компилятором по определению.
Ты ошибаешся. Частичная специализация — это неполная специализация. Т.е. кода один из параметров типа явно задан, а другой остался неопрделенным. (чувствую следующий вопрос бдет что такое "параметры типа" )
A> В-третьих это ещёбольшой вопрос что считать побочным эффектом.
В-третьих у тебя как-то из другой оперы, ну, да ладно.
Рекурсия при специализации — это и есть побочный эффект.
A> Когда Александреску писал Локи не то что частичную специализацию, сами шаблоны мало какой компилятор поддерживал, а теория шаблонов находилась в очень ранней стадии. Советовать тебе читать книги я не буду, всё равно не прочтёшь, так что поверь на слово.
A>Итак, я не думаю, что побочным эффектом монжно назвать стандартизированное поведение компилятора.
"Ошибочно было бы думать..." (с) В.И.Ленин.
A>Я меня много знакомых которые и включать-то копьютер не умеют, каким это боком к уважению? А знания я оцениваю в том числе (но не только) по используемой терминологии.
Ну, значит у тебя со знаниями... ээ...
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
