Дарней wrote: > праавда? А то, что бинарные внутренности контейнера на другой платформе > могут быть совсем другими — это ничего? И всё, прощай совместимость > сериализованных файлов.
При первой установке просто преобразуем из кроссплатформенной формы в
оптимизированую для текущей платформы.
> Мне как-то раз уже приходилось исправлять последствия таких художеств
И это говорит программист на .NET, который толково нигде кроме Windows и
не работает...
Здравствуйте, Дарней, Вы писали:
I>>Аллокаторы это еще и возможность персистентно хранить контейнеры в файлах используя file mapping, что может использоваться в словарях и энциклопедиях. В таких программах данные нередко read only, сами программы однопользовательские, базы данных тут явно из пушки по тараканам.
Д>а потом понадобится портировать прогу на другую платформу — и всё, понеслась...
Так и без портирования приключений с file mapping аллокатором предостаточно. Но иногда на порядок большее быстродействие того стоит.
Дарней wrote: > I>Аллокаторы это еще и возможность персистентно хранить контейнеры в > файлах используя file mapping, что может использоваться в словарях и > энциклопедиях. В таких программах данные нередко read only, сами > программы однопользовательские, базы данных тут явно из пушки по тараканам. > а потом понадобится портировать прогу на другую платформу — и всё, > понеслась...
А если сайт на aspx понадибится портировать?
igna wrote: > Так и без портирования приключений с file mapping аллокатором > предостаточно. Но иногда на порядок большее быстродействие того стоит.
Попробуйте Boost.Shmem (его недавно приняли в официальный Boost) —
удобнее ничего не нашел.
Привязывать прогу к бинарному представлению конкретной платформы — это вообще моветон. Потому что зависимости от библиотек находятся легко, а зависимости от бинарных особенностей платформы потребуют перетряхивать всю программу.
E>Правда Д>> А то, что бинарные внутренности контейнера на другой платформе могут быть совсем другими — это ничего? И всё, прощай совместимость сериализованных файлов.
E>Это уже второй вопрос
ну конечно. Сделать то мы сделаем, а чтобы это можно было использовать в реальной работе — это уже отдельный вопрос
E>Ведь речь могла идти и о совместно работающих процессах на одной машине -- им ведь так же данными обмениваться нужно. Тогда вопрос о совместимости не столь актуален.
вопрос встанет тогда, когда прогу придется портировать. А для серьезного проекта такой вопрос встанет обязательно. И маленький пушистый зверек придет, как всегда, неожиданно.
Здравствуйте, igna, Вы писали:
I>Аллокаторы это еще и возможность персистентно хранить контейнеры в файлах используя file mapping, что может использоваться в словарях и энциклопедиях. В таких программах данные нередко read only, сами программы однопользовательские, базы данных тут явно из пушки по тараканам.
Аллокаторы — это возможность угробить память и насандалить глюков. А с данными в файлах можно и без них работать. Причем не менее эффективно.
Причем для длоступа к данным применяются абстракции вроде потоков. А то как эти абстрации лезут к физическим аднным (через файл-маппинг или еще как) определяется реализациями абстракций.
Мне искренне жать тех кто этого не понимает.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>При первой установке просто преобразуем из кроссплатформенной формы в C>оптимизированую для текущей платформы.
словари тоже "оптимизировать", то бишь конвертировать будем? А может быть, и офисные документы тоже?
C>И это говорит программист на .NET, который толково нигде кроме Windows и C>не работает...
Ну во первых — это переход на личности, в частности — дискредитация квалификация оппонента.
Во вторых — ты просто попал пальцем в небо. Если тебе так хочется об этом поговорить, то я писал как минимум для четырех разных ОСей. Ну ладно, для трех с половиной — одна из них это WinCE. Можно еще вспомнить всякую экзотику наподобие CP/M и TR-DOS, но это вряд ли кого-то сейчас интересует
В третьих, мой опыт работы с приплюснутым будет раза так в три длительнее, чем на .NET.
так что, мой друг, расскажи лучше что-нибудь по делу. Вместо того, чтобы в очередной раз устраивать сеанс пенисометрии.
VladD2 wrote: > Аллокаторы — это возможность угробить память и насандалить глюков. А с > данными в файлах можно и без них работать. Причем не менее эффективно.
.NET дает возможность писать кривые и уродские приложения. Причем не
менее неэффективно, чем VB3.
> Причем для длоступа к данным применяются абстракции вроде потоков. А то > как эти абстрации лезут к физическим аднным (через файл-маппинг или еще > как) определяется реализациями абстракций.
А для вызова методов у String надо _обязательно_ использовать SOAP через
прокси-сервер в Африке. В конце концов, вы ведь не можете знать заранее
откуда пришла строка?
Здравствуйте, Дарней, Вы писали:
C>>При первой установке просто преобразуем из кроссплатформенной формы в C>>оптимизированую для текущей платформы. Д>словари тоже "оптимизировать", то бишь конвертировать будем? А может быть, и офисные документы тоже?
Запросто — формировать кэш для быстрой работы. В .NET же используется GAC — чем я хуже?
C>>И это говорит программист на .NET, который толково нигде кроме Windows и C>>не работает... Д>Ну во первых — это переход на личности, в частности — дискредитация квалификация оппонента.
Я так и думал, что это предложение будет неправильно понято
Фраза "нигде кроме Windows и не работает" относится к .NET, а не к программисту.
Д>Во вторых — ты просто попал пальцем в небо. Если тебе так хочется об этом поговорить, то я писал как минимум для четырех разных ОСей. Ну ладно, для трех с половиной — одна из них это WinCE. Можно еще вспомнить всякую экзотику наподобие CP/M и TR-DOS, но это вряд ли кого-то сейчас интересует
На Линуксе Mono пока плохо пригодно для запуска программ, написанных на .NETе. Ситуация как с Kylix'ом — программы для Mono можно запускать в .NET, но обратное обычно не верно.
Left2 wrote: > C>А если сайт на aspx понадибится портировать? > Тогда из С++-библиотеки лёгко постукивая кувалдой делается COM-обьект и > юзается почти как родной
Вы не поняли... Что будет, если я захочу сайт на aspx захостить на Линуксе?
Дарней wrote: > I>Речь не о сериализации. Это просто уточнение (чтобы проходящие мимо > чего не так не поняли). > хоть как назови, суть от этого не изменится.
Меняется. File mapping и использование custom-allocator'ов позволяет
работать с объектами на диске так, как будто они прямо в памяти лежат.
То есть в таком коде:
struct some
{
std::string str;
};
std::vector<some> vec_;
std::cout<<vec_.at(100).str;
обращение по индексу в векторе может вызывать _прозрачное_ чтение с
диска нужных страниц.
Здравствуйте, Cyberax, Вы писали:
C>Запросто — формировать кэш для быстрой работы. В .NET же используется GAC — чем я хуже?
Угу. То есть бинарный формат первой платформы, для которой писали систему, становится "универсальным".
Перекодировать файл в платформо-специфичный формат (то есть сначала считать файл из "универсального" формата, потом замапить на файл и сохранить), а потом считывать в память маппингом — но зато оччень эффективно . Декодер "универсального" формата, конечно, сначала нужно написать — для каждой платформы, куда надо портировать систему.
При записи на флэшку — повторить всю последовательность в обратном порядке.
Гениально. Где ты берешь такую траву?
C>Фраза "нигде кроме Windows и не работает" относится к .NET, а не к программисту. C>На Линуксе Mono пока плохо пригодно для запуска программ, написанных на .NETе. Ситуация как с Kylix'ом — программы для Mono можно запускать в .NET, но обратное обычно не верно.
это всё равно на порядок лучше, чем портировать среднестатистическую С++ прогу. В особенности, если до нее уже добрались шаловливые ручки кул-С++-хацкеров.
Дарней wrote: > C>Запросто — формировать кэш для быстрой работы. В .NET же используется > GAC — чем я хуже? > Угу. То есть бинарный формат первой платформы, для которой писали > систему, становится "универсальным".
Переносимые документы можно хоть в XML делать — тот же Boost.S11N это
поддерживает. А вот локальные закэшированые копии можно хранить в
оптимальном формате.
Ну и документы — это нестандартный случай. А вот игра, в которой графика
уровней хранится в таком кэше — вполне себе вариант. "На халяву"
получаем от ОС крайне эффективный механизм кэширования с минимальным
оверхедом.
Или как вариант — я использую shared-memory для эффективного общения
клиента и сервера в разных процессах на одной машине. Скорость в десятки
раз больше, чем при работе с пайпами/сокетами, так как объекты не
сериализуются, а просто помещаются (или сразу же там и создаются —
зависит от ситуации) в разделяемую память (обычным копиктором).
> Перекодировать файл в платформо-специфичный формат (то есть сначала > считать файл из "универсального" формата, потом замапить на файл и > сохранить), а потом считывать в память маппингом — но зато оччень > эффективно . Декодер "универсального" формата, конечно, сначала нужно > написать — для каждой платформы, куда надо портировать систему. > При записи на флэшку — повторить всю последовательность в обратном порядке. > Гениально. Где ты берешь такую траву?
А откуда MS берет свою траву? Из компилятора C# получается байт код для
стековой машины, который потом JITом обратно переводится в SSA-дерево,
которое потом компилируется. И зачем такой изврат?
> это всё равно на порядок лучше, чем портировать среднестатистическую С++ > прогу. В особенности, если до нее уже добрались шаловливые ручки > кул-С++-хацкеров.
А я не пишу "среднестатистические" проги
Здравствуйте, Дарней, Вы писали:
Д>Угу. То есть бинарный формат первой платформы, для которой писали систему, становится "универсальным".
А что, вероятность того, что бинарный формат первой платформы сразу окажется кросс-платформенным, ничтожно мала?
Что-то мне кажется, что это не так. Особенно с учетом того, что библиотек для сериализации (использующих платформо-независимый формат) не так уж и мало.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
