Дарней wrote: > C>Горячие BDB-шные парни пишут на чистом С > C>Но отображение файлов в память они как раз именно так и используют. > а я и не говорил, что MMF это плохо. Я говорил, что отображение > приплюснутых объектов в бинарной форме в персистентное хранилище — это > плохо.
Потому как непортабельно, а ненормальнопортабельный aspx — это хорошо
Двойные стандарты, однако.
Здравствуйте, Cyberax, Вы писали:
C>Потому как непортабельно, а ненормальнопортабельный aspx — это хорошо C>Двойные стандарты, однако.
как раз aspx под никсами уже хостят. Не знаю правда, насколько это проблематично. В любом случае, ситуация будет улучшаться с развитием Моно. А плюсам уже ничто не поможет.
Здравствуйте, Дарней, Вы писали:
Д>как раз aspx под никсами уже хостят. Не знаю правда, насколько это проблематично.
Как в рекламе: "Сынок, это фантастика". Наблюдается стандартная ситуация — приложения для Mono работают в .NET, обратное неверно.
Д>В любом случае, ситуация будет улучшаться с развитием Моно. А плюсам уже ничто не поможет.
С++ поможет новый Стандарт и новые компиляторы.
Здравствуйте, Cyberax, Вы писали:
C>Как в рекламе: "Сынок, это фантастика". Наблюдается стандартная ситуация — приложения для Mono работают в .NET, обратное неверно.
обратное тогда тоже верно — только с небольшой доработкой.
C>С++ поможет новый Стандарт и новые компиляторы.
новый стандарт только всё ухудшит. Но это уже тема для отдельного флейма
Очень точную и емкую характеристику языка C++ я нашел в owerview к языку D (перевод мой):
Индустрия программного обеспечения прошла большой путь после изобретения C. Много новых коцепций было добавлено в язык посредством C++, но обратная совместимость с C была сохранена, включая совместимость почти со всеми слабыми сторонами исходного дизайна. Было много попыток исправить эти слабые стороны, но вопрос совместимости сделал их тщетными. Между тем, и C, и C++ подвергаются постоянному дополнению новыми возможностями. Эти возможности должны очень аккуратно встраиваться в существующие конструкции для избежания переписывания старого кода. Получаемый результат очень сложен -- стандарт C почти 500 страниц, а стандарт C++ больше 750! C++ является очень сложным и дорогим в реализации языком, в результате в реализациях есть отличия, которые делают очень сложным написание полностью переносимого C++ кода.
C++ программисты стремяться программировать на отдельных островках языка, т.е. очень искусно использует некоторые возможности, избегая множества других. Хотя код более-менее переносим с компилятора на компилятор может быть очень тяжело перенести его от программиста к программисту. Великая сила C++ в том, что он поддерживат много совершенно разных стилей программирования, но при длительном использовании перекрывающиеся и несовместимые стили программирования становятся преградой.
Это слова Walter Bright, разработчика компилятора Digital Mars C++ и языка D.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Дарней wrote: > C>Как в рекламе: "Сынок, это фантастика". Наблюдается стандартная > ситуация — приложения для Mono работают в .NET, обратное неверно. > обратное тогда тоже верно — только с небольшой доработкой.
Тогда это уже не обратная, а прямая ситуация.
> C>С++ поможет новый Стандарт и новые компиляторы. > новый стандарт только всё ухудшит. Но это уже тема для отдельного флейма
Конечно ухудшит Тот же C# будет по сравнению с ним выглядеть
маломощным карликом.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
V>>>Функциональщики считают, что да. посмотри на программы на Схеме, например. Там программы — это макраме из массы очень коротких, по сравнению с "обычными", процедур.
Рискну предположить, что макраме из процедур — это обычно интерфейс к ADT.
VD>>У функциональщиков как раз есть замыкания и "массы очень коротких" функций они объявляют по месту используя контекст методов в которые они вложены.
V>Чего гадать? Возьми любые исходники на Схеме чего-нить (полно в сети) да посмотри. Локальные замыкания в Паскалевском стиле не так уж часто используются. А по мне, есть в этом что-то от использования глобальных переменных. Кстати, в Паскале, глобальные переменные — это окружение замыкания процедуры program. (на слух звучит коряво, но "envirounment/окружение" — это термин такой для замыканий)
Что такое "локальные замыкания"? let — локальное замыкание? cond ? Если нет, почему?
Здравствуйте, Cyberax, Вы писали:
>> C>.NET дает возможность писать кривые и уродские приложения. Причем не >> C>менее неэффективно, чем VB3. >> Понимаш ли в чем дело. Твое злопыхательство ни на грам не повредит >> .NET-у, но вот тебя подобные слова выставляют в не очень хорошем свете. C>Если ты не заметил, то я просто утрирую твои слова
И в чем же заключается утрирование?
C>Ну так ты ведь утверждаешь, что всегда надо использовать GC.
Я утверждаю, что в 99% случаев ЖЦ порвет вашу самопальщину. И делаю столь смелые утверждения потому, что сам сделал один из самых быстрых "аллкаторов
Здравствуйте, vdimas, Вы писали:
V>Вот не надо эту мысль озвучивать без уточнений, а то черезчур неграмотно выглядит. GC "рвет" не все аллокаторы и далеко не во всех сценариях использования.
Ты за свой проффесионализм бойся, а за мой не надо. Я понимаю что говорю. В большинстве случаев порвет. А тот 1-2% происходят когда оптимизацией занимаются действительно знающие люди и в довольно редких случаях. Пока хорошему ЖЦ хватает памяти он весьма эффективен.
V> Кстати, даже в С++ юзают аллокаторы, построенные по принципу GC. И некоторые так и делают, особенно в тех сценариях, где GC действительно является наиболее подходящим.
Вот и срани как нибудь эти реализации. ЖЦ под обычным С++ — это слезы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, VladD2, Вы писали:
VD>>Темболее, что если надо, то это в любом языке делается. VD>>Вот только с замыканиями и локальными фунциями это можно делать удобнее и чаще:
V>Можно сравнить "синтаксический оверхед" и run-time эффективность на твоем любимом C# и С++:
А что же с C# то? Давай как с Nemerle-ом сравним. Хотя и тут в общем то видно, что из С++ пытаются выжать то на что он явно не рассчитан. Что за "var(x)" иди "_1"? Что это за не определенная грязь?
V>Тем более, что вместо typedef я могу по месту писать требуемый function<type1(type2, ... and so on)>, а в C# я должен явно декларировать делегат перед использованием.
В Nemerle вообще писать ничего не нужно. Да и в C# можно определить 4-5 дженерик-делегатов и забыть про их объявление навсегда.
Ты лучше вспомни, о том, что boost::lambda вынуждает:
1. Тащить за собой огромную библиотеку.
2. Резко замедляет компиляцию.
3. Применима только в примитивнихшых случаях.
4. Неполноценная реализация.
Что же ты, например, не смог воспроизвести даже примитивного кода? Почему у тебя в последней функции:
Predicate GreaterOrEquals = var(x) >= _1;
не используются две другие (Greater и Equals)? Напомню, оригинал выглядел так:
В общем, очередная демонстрация так называемой аргументации. Какая на фиг краткость в плюсах? Акстись! Погляди на реальный код на С++. Это же ужасно! Тут рядом
орел даже не поверил, что понравившеся ему извращение на плюсах можно во много раз более кратко записать на шарпе.
V>Замыкание красиво и элегантно создается конструкцией var(x)
Красота не описуемая.
Да и что же ты этой красотой так же Greater и Equals не замкнул?
V> (есть еще константная версия, для избежания копирования по значению больших объектов, если мы не собираемся их модифицировать). Созданное замыкание — суть функциональный объект, который затем используется в функциях высшего порядка. Примеры эти тривиальны, иначе можно было бы показать такое же элегантное порождение curring-функций через bind.
Я плякаль. Тут уже до тебя приводили примеры этой "элегантности". Поверь от нее тошнит.
V>Но это все синтаксис. С точки зрения run-time, в C# динамически создаются экземпляры объектов/замыканий, так что подобный код я бы не рекомендовал
Твои рекомендации к щастью ничего не стоят.
V> применять при обработке значительных объемов данных.
V> Оссобенно хотелось бы отметить эффективность замыкания GreaterOrEquals. Причем ситуация такова, что на данном этапе развития CLR нет никакой возможности оптимизировать это дело, ввиду самой механики эмуляции замыканий. Эти замыкания и код по их вызову "по-честному" создает компилятор. Только вот сам характер генерируемого кода таков, что платформа CLR не в состоянии предотвратить динамическое создание объектов-замыканий никакими оптимизациями, ибо классы, их реализующие, декларативно никак не связаны с целевым методом в конечном байт-коде, кроме как в момент вызова из оного. Т.е. пока что для замыканий существует слишком высокий "abstraction penalty", о котором необходимо помнить (динамическое создание объектов-замыканий!!!).
Ты хоть знаешь сколько стоит создать один мелкий объект? Что касается невозможности оптимизаций, то это не правда. Подобные вещи потенциально полностью устраняются совершенно универсальными алгоритмами.
V>Напротив, в С++ не создаеются динамические объекты, не используется ни полиморфизм или коссвенная адресация, а значит все инлайнится в момент компиляции таким образом,
Хм. Нэемерле тоже не пользуется для таких случаев полиморфизмом. А инлайнится или нет — это уже качество оптимизатора кокретного компилятора. К языку это отношение не имеет.
Зато С++-ный код точно не полноценный. Такое замыкание ни передать никуда нельзя, ни продлить время жизни за пределы функции.
В общем, оправдания убогости стремлением к скорости явно не прокатывает. Скорости ведь хватает. Куда больше можно "выжать" используя более подходящие алгоритмы. А вот выразительности и простоты явно не хватает. Их никогда хватать не будет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > V> Кстати, даже в С++ юзают аллокаторы, построенные по принципу GC. И > некоторые так и делают, особенно в *тех сценариях*, где GC действительно > является наиболее подходящим. > Вот и срани как нибудь эти реализации. ЖЦ под обычным С++ — это слезы.
Кхм.
Boehm GC в Mono ничем почти не отличается от обычного Boehm'а,
применимого для С++. Собственно, в Mono их GC сканирует и C-шную часть кода.
VladD2 wrote: >> > C>.NET дает возможность писать кривые и уродские приложения. Причем не >> > C>менее неэффективно, чем VB3. >> > Понимаш ли в чем дело. Твое злопыхательство ни на грам не повредит >> > .NET-у, но вот тебя подобные слова выставляют в не очень хорошем свете. > C>Если ты не заметил, то я просто утрирую твои слова > И в чем же заключается утрирование?
"Если что-то может быть использовано неправильно — то это отстой и
маздай" — почти ваши слова.
> C>Ну так ты ведь утверждаешь, что всегда надо использовать GC. > Я утверждаю, что в 99% случаев ЖЦ порвет вашу самопальщину. И делаю > столь смелые утверждения потому, что сам сделал один из самых быстрых > "аллкаторов <http://rsdn.ru/article/cpp/QuickHeap.xml>
Здравствуйте, Cyberax, Вы писали:
C>"Если что-то может быть использовано неправильно — то это отстой и C>маздай" — почти ваши слова.
Где я такое говорил?
C>Но не самый быстрый.
Ты провоил измерения?
C>Знаю коммерческий аллокатор, работающий за O(1) для C>блоков небольшого размера.
QuickHeap именно O(1). Причем с очень незначительной константой.
C>Я уж не говорю, что ваш QuickHeap совершенно непригоден для быстрый C>MT-приложений (в них рулит Hoard).
Измерял?
C>Кроме того, с GC может быть _аллокация_ будет быстрее. Но вот циклы GC C>съедают это преимущество.
Дык я как раз сравнивал общее время работы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Boehm GC в Mono ничем почти не отличается от обычного Boehm'а, C>применимого для С++. Собственно, в Mono их GC сканирует и C-шную часть кода.
Не потому ли Моно проигрывает дотнету в 2-10 раз по скорости?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > C>Boehm GC в Mono ничем почти не отличается от обычного Boehm'а, > C>применимого для С++. Собственно, в Mono их GC сканирует и C-шную часть > кода. > Не потому ли Моно проигрывает дотнету в 2-10 раз по скорости?
В частности из-за этого — специализированый точный GC обычно лучше
консервативного. Ну и JIT у них намного хуже.
PS: а кто тут утверждал, что .NET замечательно работает на куче платформ??
VladD2 wrote: > C>"Если что-то может быть использовано неправильно — то это отстой и > C>маздай" — почти ваши слова. > Где я такое говорил?
Аллокаторы — это возможность угробить память и насандалить глюков. А с
данными в файлах можно и без них работать. Причем не менее эффективно.
> C>Но не самый быстрый. > Ты провоил измерения?
Уже да
> C>Знаю коммерческий аллокатор, работающий за O(1) для > C>блоков небольшого размера. > QuickHeap именно O(1). Причем с очень незначительной константой.
У меня меньше — только простые битовые операции используются (всего с
одним ветвлением, от него тоже можно избавиться).
> C>Я уж не говорю, что ваш QuickHeap совершенно непригоден для быстрый > C>MT-приложений (в них рулит Hoard). > Измерял?
Вижу по коду — есть синхронизации. В Hoard'е в большинстве случаев даже
атомарные операции при распределении памяти не используются — она
берется из арены текущего потока.
Ну и сложность у Hoard'а соответствующая.
> C>Кроме того, с GC может быть _аллокация_ будет быстрее. Но вот циклы GC > C>съедают это преимущество. > Дык я как раз сравнивал общее время работы.
Тесты в студию. И еще надо помнить, что в С++ есть автоматические объекты.
Здравствуйте, VladD2, Вы писали:
V>>Вот не надо эту мысль озвучивать без уточнений, а то черезчур неграмотно выглядит. GC "рвет" не все аллокаторы и далеко не во всех сценариях использования.
VD>Ты за свой проффесионализм бойся, а за мой не надо. Я понимаю что говорю. В большинстве случаев порвет. А тот 1-2% происходят когда оптимизацией занимаются действительно знающие люди и в довольно редких случаях. Пока хорошему ЖЦ хватает памяти он весьма эффективен.
Влад, я очень часто использую аллокаторы стекового типа. Причем они абсолютно безопасны, в отличие от обычных сишных массивов. И они очень сильно рвут GC. Причем, если брать сервер под нагрузкой, то надо учитывать не только быстрое выделение памяти, но и "небыстрый" GC при освобождении. А в стековых аллокаторах практически нулевые издержки на обе операции.
Эффективность ЖЦ зависит не только от кол-ва памяти (ведь потребность в памяти — величина относительная), а так же от сценариев использования. Например, если мы в одном потоке создаем данные, а потом передаем для обработки в другие потоки, то GC здесь — идеальное решение, и он порвет все, что можно порвать. В таких случаях и в С++ будет грамотно задействовать GC. Кстати, все сишные и плюсовые реализации Лиспа и Схемы используют GC. ВСЕ БЕЗ ИСКЛЮЧЕНИЯ.
V>> Кстати, даже в С++ юзают аллокаторы, построенные по принципу GC. И некоторые так и делают, особенно в тех сценариях, где GC действительно является наиболее подходящим.
VD>Вот и срани как нибудь эти реализации. ЖЦ под обычным С++ — это слезы.
Я не понял, что именно ты имеешь в виду. В С++ работу с GC осуществляют через GC-хендлы, и значения этих GC-хендлов точно так же корректируются при уплотнении памяти. Если ты именно это имел в виду... то это не проблема.
Здравствуйте, Cyberax, Вы писали:
C>igna wrote: >> P.S. Думаю, это непродумано в стандарте, что std::string с разными >> аллокаторами нельзя присваивать друг другу. C>Ага, и то что allocator::pointer и allocator::const_pointer должны быть C>простыми указателями.
C>Обещают исправить в C++09
Ничего подобного. Новая модель аллокаторов не прошла. Она не дружит с временными копиями, RVO и rvalue reference.
