Дарней wrote: > Если отказаться от использования некоторых частей .NET, которые /пока/ > не в полном объеме реализованы в Моно — никаких проблем с переносимостью > не должно быть. Даже если эти части используются, локализовать их и > заменить — вполне тривиальная задача.
Вот! Именно в этом сейчас обвиняют С++ — что его разные компиляторы
поддерживают в разном объеме. Оказывается в С# ситуация ну точно такая же.
> C>Конечно ухудшит Тот же C# будет по сравнению с ним выглядеть > C>маломощным карликом. > Скорее, новый C++ будет выглядеть многоножкой, которая запуталась в > своих многочисленных ногах. Растущих не только с нижней стороны тела, но > также с боков и даже сверху — из соображений совместимости с предыдущими > версиями
Ага, и при этом может летать в космос и просачиваться в миллиметровые
отверстия
> Не говоря уже о том, что к тому моменту, когда опубликуют наконец новый > стандарт С++ (и, что более важно, соответствующие ему компиляторы ) — M$ > уже выпустит C# за версией 4.0. А независимые разработчики языков для > .NET тоже не дремлют. > Вот ты сам как думаешь, когда появятся полноценные рабочие компиляторы > для нового стандарта?
В районе 2009 года. ConceptGCC отслеживает развитие Draft Proposal, а
Herb Sutter в MS пообещал выпустить компилятор "как только, так сразу".
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, igna, Вы писали:
I>>Hashtable был взят только для примера, и лишь потому, что в .NET FCL отсутствует что-нибудь вроде BTree или BPlusTree. I>> Что впрочем неудивительно, возможности эффективно использовать их все равно нет.
AVK>При желании все можно. В том числе и MMF использовать.
Здравствуйте, Cyberax, Вы писали:
C>Вот! Именно в этом сейчас обвиняют С++ — что его разные компиляторы C>поддерживают в разном объеме. Оказывается в С# ситуация ну точно такая же.
нет, не в точности. Там нет различий в реализации стандарта — там есть только неполная реализация стандарта. Пока неполная, стоит еще добавить.
C>Ага, и при этом может летать в космос и просачиваться в миллиметровые C>отверстия
Чтобы в космосе порадовать пользователей внезапной разгерметизацией, а в дырках намертво застревать, если луна находится не в нужной фазе.
C>В районе 2009 года. ConceptGCC отслеживает развитие Draft Proposal, а C>Herb Sutter в MS пообещал выпустить компилятор "как только, так сразу".
Полной поддержкой текущего стандарта до сих пор мало кто может похвастаться, а ты ожидаешь выхода полноценных новых компиляторов через год-два после выхода нового стандарта? Оптимистично.
Дарней wrote: > C>Вот! Именно в этом сейчас обвиняют С++ — что его разные компиляторы > C>поддерживают в разном объеме. Оказывается в С# ситуация ну точно такая же. > нет, не в точности. Там нет различий в реализации стандарта — там есть > только неполная реализация стандарта. /Пока/ неполная, стоит еще добавить.
Ну так и в Mono — неполная реализация .NET FW
> C>Ага, и при этом может летать в космос и просачиваться в миллиметровые > C>отверстия > Чтобы в космосе порадовать пользователей внезапной разгерметизацией, а в > дырках намертво застревать, если луна находится не в нужной фазе.
Это только плохие программы так себя ведут
> C>В районе 2009 года. ConceptGCC отслеживает развитие Draft Proposal, а > C>Herb Sutter в MS пообещал выпустить компилятор "как только, так сразу". > Полной поддержкой текущего стандарта до сих пор мало кто может > похвастаться, а ты ожидаешь выхода полноценных новых компиляторов через > год-два после выхода нового стандарта? Оптимистично.
VS8 уже вполне близок к нормальному компилятору, так что все вполне
оптимистично. GCC еще ближе — там даже exception specification
поддерживается.
AndrewVK wrote: > C>Глобальный кэш сборок — прекрасно знаю что это такое. > Тогда может объяснишь какое он имеет отношение к быстрой работе и > конвертации форматов? Здесь
Ну да, можно положить Assemblt в GAC и сделать ей ngen'ом
оптимизированое изображение.
ЗЫ: Блин, договорились называется... Надо спросить не читает ли заказчик
RSDN, сегодня именно ЭТУ ФИЧУ попросили — оптимизированый кэш документов
для их быстрого открытия.
Д>Привязывать прогу к бинарному представлению конкретной платформы — это вообще моветон. Потому что зависимости от библиотек находятся легко, а зависимости от бинарных особенностей платформы потребуют перетряхивать всю программу.
+1 см. ниже.
Д>ну конечно. Сделать то мы сделаем, а чтобы это можно было использовать в реальной работе — это уже отдельный вопрос
Д>вопрос встанет тогда, когда прогу придется портировать. А для серьезного проекта такой вопрос встанет обязательно. И маленький пушистый зверек придет, как всегда, неожиданно.
По пушистому зверьку, который прийдет из-за вопроса совместимости бинарных сереализованных данных в
серьезногый проект
следует пальнуть ASN1, а полученную пушистую шкурку сдать на мех, а бапки пропить.
ЗЫ Просто в С++ надо больше думать, некоторые от этого отвыкли, им больше нравиться не думать.
Здравствуйте, Cyberax, Вы писали:
C>Ну так и в Mono — неполная реализация .NET FW
ну так я про это и писал. В отличие от реализаций С++, где существует куча нестандартных расширений, а вполне валидный код компилируется далеко не всегда. Достаточно на исходники буста посмотреть — сколько раз там упоминается "обход проблем совместимости"
C>Это только плохие программы так себя ведут
а где они, хорошие? Я пока ни одной не видел, если она сложнее чем hello world
C>VS8 уже вполне близок к нормальному компилятору, так что все вполне C>оптимистично. GCC еще ближе — там даже exception specification C>поддерживается.
а где у них про текущий статус соответствия новому стандарту написано?
Здравствуйте, Дарней, Вы писали:
Д>да, asn.1 хорошая штука. Жаль, что в наших краях он мало распространен
Есть у меня подозрение, что и в тех краях asn1 широко известен только в узких кругах.
Иначе XML для передачи данных между приложениями нервно покуривал бы себе в сторонке.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Дарней, Вы писали:
Д>Здравствуйте, Cyberax, Вы писали:
C>>Запросто — формировать кэш для быстрой работы. В .NET же используется GAC — чем я хуже?
Д>Угу. То есть бинарный формат первой платформы, для которой писали систему, становится "универсальным". Д>Перекодировать файл в платформо-специфичный формат (то есть сначала считать файл из "универсального" формата, потом замапить на файл и сохранить), а потом считывать в память маппингом — но зато оччень эффективно . Декодер "универсального" формата, конечно, сначала нужно написать — для каждой платформы, куда надо портировать систему. Д>При записи на флэшку — повторить всю последовательность в обратном порядке. Д>Гениально. Где ты берешь такую траву?
-1
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Дарней, Вы писали:
Д>>да, asn.1 хорошая штука. Жаль, что в наших краях он мало распространен
E> E>Есть у меня подозрение, что и в тех краях asn1 широко известен только в узких кругах. E>Иначе XML для передачи данных между приложениями нервно покуривал бы себе в сторонке.
-1
Не передергивайте
XML получил широкое распространение, потому, что он очень human-readable + на лету может трансформироваться (xsl[t]) + на него с минимум оговорок ложится html + легко его парсить + ограничения задаются в виже самого-же xml (xml-scheme).
НО ЗАТО у него зверский размер, и без сжатия xml нервно курит в сторонке.
ASN1 наоборот совсем не human readable ну может есть гении .
ASN1 гораздо сложней сереализовать/десеарилизовать чем xml, вот ИМХО поэтому он и не так распространён.
Здравствуйте, srggal, Вы писали:
E>>Иначе XML для передачи данных между приложениями нервно покуривал бы себе в сторонке. S>-1
S>Не передергивайте
Я не передергиваю, я специально сказал, что речь идет о передаче данных между приложениями. Где human-readability идет лесом, а вот вопросы размера, расширяемости и, в потенциале, верифицируемости, очень важны (например, криптографическая подпись XML -- это вообще изобретение то еще).
Что касается реализации парсинга и формирования ASN1 в BER, то это может быть даже проще, чем XML. Поскольку такие реализации работают даже на смарт-картах.
А для более сложных упаковок предназначены ASN1 компиляторы.
S>XML получил широкое распространение, потому, что он очень human-readable + на лету может трансформироваться (xsl[t]) + на него с минимум оговорок ложится html + легко его парсить + ограничения задаются в виже самого-же xml (xml-scheme).
А это уже совсем другая область.
Что же касается органичений, то в ASN1 они так же есть.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Ну да, можно положить Assemblt в GAC и сделать ей ngen'ом C>оптимизированое изображение.
Афигеть. Блин, ну ты и спорщик.
Для того чтобы обработать ngen'ом сборку не нужно класть ее в GAC. Единственная связь между GAC и ngen это то что каталог ngen'а лежит рядом с каталогом GAC.
Здравствуйте, eao197, Вы писали:
E>Есть у меня подозрение, что и в тех краях asn1 широко известен только в узких кругах. E>Иначе XML для передачи данных между приложениями нервно покуривал бы себе в сторонке.
я имел в виду не географию, а области программирования
насколько я слышал, asn.1 широко применяется только в телекоммуникациях
