Здравствуйте, niXman, Вы писали:
X>а почему не просто сериализовать эту структуру с контейнером, и потом получившееся дописывать в представление?
Медленнее, если при сериализации не жать...
X>Lazin это просил.
Ну и в чём проблема?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Медленнее, если при сериализации не жать...
в смысле, сжимать? что сжимать? результат сериализации?
E>Ну и в чём проблема?
не знаю, не задумывался, ибо так и не понял, почему не сделать по-человечески...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
E>>Медленнее, если при сериализации не жать... X>в смысле, сжимать? что сжимать? результат сериализации?
Результат или сами данные. Короче уменьшить обмен с диском что бы.
E>>Ну и в чём проблема? X>не знаю, не задумывался, ибо так и не понял, почему не сделать по-человечески...
А как это "по-человечески"?
Если туда какой-нибудь std::vector вклячить, то будет сильно менее эффективно жеж, чем мэпинг файла данных непосредственно на юзабельные данные...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
12/5/2013 7:08 PM, Erop пишет:
> Если туда какой-нибудь std::vector вклячить, то будет сильно менее > эффективно жеж, чем мэпинг файла данных непосредственно на юзабельные > данные...
Не будет, если не отстреливать себе разные органы.
Здравствуйте, niXman, Вы писали:
L>>Ждем http сервер в 1.65 X>еще в 1.35 добавили. не навороченные, правда — но очень даже рабочие. X>http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/examples.html
Это пример. Он реализует поддержку очень ограниченного подмножества протокола. К тому же, хотелось бы не только сервер иметь, но и клиент. (да и вообще, как можно не иметь в век интернета поддержку http в стандартной библиотеке?)
L>>драйвер БД в 1.87. X>это, вроде как, лишнее. иначе после этого можно будет ожидать GUI библиотечку...
Что в этом плохого?
Здравствуйте, niXman, Вы писали:
X>не уверен что правильно понял, но разве offsets не может быть каким-нить контейнером?
А каким контейнером, std::vector?
Эта память мапится в файл, все что в ней оказывается — записывается в файл. Поэтому нужно контролировать layout каждого отдельного байта.
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, niXman, Вы писали:
X>>... предположу что для харда ... X>в смысле, данные либо считываются с харда, либо записываются на него. либо — и то и другое.
почитай про memory mapped I/O
Здравствуйте, niXman, Вы писали:
E>>Ну и в чём проблема? X>не знаю, не задумывался, ибо так и не понял, почему не сделать по-человечески...
По "человечески" это как? Мне для memory mapped I/O или shared memory, неважно. Как будет "по человечески"?
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, Erop, Вы писали:
E>>Такой, что для харда возможность отмапировать тупо файл на память и юзать как хранилище -- ценна, как нигде. X>нее..наверное со мной действительно что-то не так...
Именно, тебе не хватает опыта для того, чтобы просто понять о чем мы тут толкуем
X>а почему не просто сериализовать эту структуру с контейнером, и потом получившееся дописывать в представление?
Сериализация это жутко медленно, к тому же, я хочу изменять массив offsets при необходимости. Если сериализовать, то нужно будет сначала десериализовать, потом изменить, потом опять сериализовать, просто жуть
E>>Кроме того, его же можно безопасно завернуть в С++ шаблон... X>Lazin это просил.
Это должно было послужить иллюстрацией того, что метапрограммирование на шаблонах в современном с++ иногда все же просасывает примитивному коду на Си
Здравствуйте, Lazin, Вы писали:
X>>>... предположу что для харда ... X>>в смысле, данные либо считываются с харда, либо записываются на него. либо — и то и другое. L>почитай про memory mapped I/O
Для полоного понимания того, что есть memory mapped I/O и почему это так хорошо, следует разобраться сначала с paging-ом в современных ОС и с тем как работает маппинг виртуальных адресов на физические, TLB, page-файл, вот это вот все.
Здравствуйте, Lazin, Вы писали:
E>>>Кроме того, его же можно безопасно завернуть в С++ шаблон... X>>Lazin это просил. L>Это должно было послужить иллюстрацией того, что метапрограммирование на шаблонах в современном с++ иногда все же просасывает примитивному коду на Си
Ой, да ладно! Всё можно написать и на С++ и работать будет ничуть не хуже. Полный пример долго писать, а для затравки могу подкинуть вот такой код, написанный за 10 минут. Тут, конечно, есть проблемы с обработкой ошибок и преобразованием указателей, но всё это можно развить и углубить без потери производительности:
Здравствуйте, Lazin, Вы писали:
L>Для полоного понимания того, что есть memory mapped I/O и почему это так хорошо, следует разобраться сначала с paging-ом в современных ОС и с тем как работает маппинг виртуальных адресов на физические, TLB, page-файл, вот это вот все.
фантик вовсе не обязан описывать то, что в нем содержится.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, B0FEE664, Вы писали:
BFE>Здравствуйте, Lazin, Вы писали:
E>>>>Кроме того, его же можно безопасно завернуть в С++ шаблон... X>>>Lazin это просил. L>>Это должно было послужить иллюстрацией того, что метапрограммирование на шаблонах в современном с++ иногда все же просасывает примитивному коду на Си
BFE>Ой, да ладно! Всё можно написать и на С++ и работать будет ничуть не хуже. Полный пример долго писать, а для затравки могу подкинуть вот такой код, написанный за 10 минут. Тут, конечно, есть проблемы с обработкой ошибок и преобразованием указателей, но всё это можно развить и углубить без потери производительности:
BFE>
Здравствуйте, Lazin, Вы писали:
E>>>>>Кроме того, его же можно безопасно завернуть в С++ шаблон... X>>>>Lazin это просил. L>>>Это должно было послужить иллюстрацией того, что метапрограммирование на шаблонах в современном с++ иногда все же просасывает примитивному коду на Си
BFE>>Ой, да ладно! Всё можно написать и на С++ и работать будет ничуть не хуже. Полный пример долго писать, а для затравки могу подкинуть вот такой код, написанный за 10 минут. Тут, конечно, есть проблемы с обработкой ошибок и преобразованием указателей, но всё это можно развить и углубить без потери производительности:
L>Это куда более многословно,
Зато можно много чего написать.
L>не решает проблему выравнивания (выносит ее из класса в код, создающий объект),
Можно решить и в класс занести. Дело не хитрое.
L> не делает код более безопасным. Увы
Ну, ассёрт на индекс я поставил. А нужно-то что?
Здравствуйте, Lazin, Вы писали:
L>Это куда более многословно, не решает проблему выравнивания (выносит ее из класса в код, создающий объект), не делает код более безопасным. Увы
Ну, так если хочется просто сделать безопасно, то можно просто структуру, в конец которой "приписан" массив сделать с закрытым operator new и остальной ерундой и вперёд, создавай/разрушай безопасно, а остальное как в С мона...
А если ещё хочется от массива сревисов как в С++, то чуть больше похимичить прийдётся, конечно...
Но тоже ничего нереального.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, B0FEE664, Вы писали:
L>>Это куда более многословно, BFE>Зато можно много чего написать.
L>>не решает проблему выравнивания (выносит ее из класса в код, создающий объект), BFE>Можно решить и в класс занести. Дело не хитрое.
Дело в том, что можно много чего там написать, но надо ли? Неужели это поможет решить какие-нибудь проблемы с этим кодом (кроме формального UB, на который лично мне фиолетово)?
L>> не делает код более безопасным. Увы BFE>Ну, ассёрт на индекс я поставил. А нужно-то что?
assert — дело нехитрое, я тоже assert использовал
Здравствуйте, Erop, Вы писали:
L>>Это куда более многословно, не решает проблему выравнивания (выносит ее из класса в код, создающий объект), не делает код более безопасным. Увы E>Ну, так если хочется просто сделать безопасно, то можно просто структуру, в конец которой "приписан" массив сделать с закрытым operator new и остальной ерундой и вперёд, создавай/разрушай безопасно, а остальное как в С мона...
А можно просто проверять размер массива, прежде чем делать reinterpret_cast
E>А если ещё хочется от массива сревисов как в С++, то чуть больше похимичить прийдётся, конечно... E>Но тоже ничего нереального.
Вот в том то и дело, что человеку, применяющему struct hack в коде ничего такого не хочется, скорее наоборот, "сервисы как в С++" для него выглядят как переусложнение кода
Здравствуйте, Lazin, Вы писали:
L>А можно просто проверять размер массива, прежде чем делать reinterpret_cast
А зачем его вообще делать?..
Если элементы массива POD, то можно прямо как в С сделать же, тока для безопасности лучше таки new с delete переделать.
А если не POD, то всё равно их создавать/разрушать надо, то есть опять же new и delete надо прятать, а создавать/разрушать фабричными методами какими-то...
L>Вот в том то и дело, что человеку, применяющему struct hack в коде ничего такого не хочется, скорее наоборот, "сервисы как в С++" для него выглядят как переусложнение кода
В смысле "не хочется"? Ну, например, получить доступ к массиву как к паре интераторов может же захотеться? А обратный итератор, например?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском