> сначала сериализуем в контейнер
Наверное, вы хотели сказать «десериализуем». В принципе, вы правильно поняли, что
> это не совсем то
Зачем мне какой-то дополнительный контейнер, если я хочу посчитать сумму, найти максимум, создать новый файл, который будет содержать только чётные числа из старого? Зачем мне дополнительная сущность в виде контейнера при решении каждой этой задачи? Бритва Оккамма решает…
Про смысл обучения этому я не хотел бы спорить по разным причинам, но насчёт использования при обучении STXXL — я (как человек работавший три года в университете с младшекурсниками) сильно сомневаюсь: тяжеловато для старших школьников/младшекурсников (для которых, как сказано в статье, это делалось). Возможно, я ошибаюсь, это только моё ощущение.
Спасибо, да, вот на это я как раз посмотрел. Что пугает: определение my_type (сложнее, чем хотелось бы; обязательно ли min/max_value?…), используют не стандартные алгоритмы (для сортировки, например), а свои: с моей точки зрения, это слегка противоречит идеологии, когда если ты реализуешь специальный контейнер (их вектор, отмапленный на файл), то предоставляя итераторы по нему, можешь пользоваться стандартными алгоритмами. У нас, в частности, была задача работать стандартными алгоритмами. Но мысль ясна, спасибо.
Я думал об этом, да. А вы не задумывались, например, какой указатель хранить, константный или нет?
И вы уверены, что память, на которую он будет указывать, всегда будет валидна? То есть не получится указателя на локальные ресурсы?
В общем, такая реализация (если её вообще можно сделать, в чём я не уверен сходу), будет сложней, чем моя. Семантика значения сильно проще во многих отношениях. С другой стороны, тут затраты на wrap не будут велики (особенно в случае встроенных типов, которые не сильно больше или даже меньше, чем указатель), и для моих задач эти затраты не играю никакой роли.
Кроме того, я думаю, что хороший компилятор постарается соптимизировать так, чтобы затраты на wrap были минимальны или их вообще не было (я думаю, это вполне возможно). В общем, интересно было бы, если бы кто-то сравнил. Но я, как уже говорил, сходу такое просто не могу написать.
Побился минут 10, чтобы скомпилировать пример с type_traits/enable_if — не получилось… Хотя опыт использования этого добра есть. Кстати, у вас съедены некоторые угловые скобки.
Кроме того, подозреваю, что в этом варианте также, как в примере выше в комментариях, потеряем возможность работы с текстовыми файлами.
Про Google Protocol Buffers знаю, но никогда не использовал, к сожалению. Пример, выполняющий работу, аналогичную той, что в последнем листинге в статье — приветствуется!
Спасибо, любопытно. Примеры на сайте STLXX кажутся весьма многословными и не очень интуитивными. Интересно было бы посмотреть на код делающий то же, что в статье (последний листинг).
Название подразумевало не работу, а обеспечение возможности такой работы. Пример работы — в последнем листинге (copy, inner_product).
Каждый раз писать свои классы долго и скучно (код был бы одинаковый с точностью до типов): на помощь приходят шаблоны (об этом сказано в тексте статьи).
Про аналог это правильно. Только, чтобы получить такой аналог в C++ (то есть, чтобы работать с бинарным файлом, хранящимся на диске, как с list), нужно идти на описанные в статье ухищрения.
Вы лучше не торопитесь и делайте так, как собирались. Также помните, что примеры — ваши главные друзья. Советовать что-то более конкретное не стану, потому что, во-первых, думаю, что это не в последнюю очередь вопрос творческий, и вам нужно доверять своей интуиции и вдохновению, а во-вторых, потому что у меня есть кое-какой теоркатегорный бэкграунд, и говорить что делать, чтобы статьи стали более доступны хабровчанам, я не считаю возможным.
Изначально презентация была размещена в ЖЖ-сообществах ру-лямбда и ру-декларатив, сходу могу дать ссылку на второе, видимо, спрашивать надо там: ru_declarative.livejournal.com/97251.html
Я менее аккуратный в вопросах лицензий человек, так что я выбросил оттуда слайд с матом (заодно потерялись все гиперссылки, что ужасно), перевыложил в сеть университета (домен sfedu.ru) и дал ссылку студентам.
Поддерживаю комментарий Tasman99. «Типовой ситуацией» использования итераторов назвал бы итераторы списков, а никак не векторов, у которых [] за константу и которые многими используются просто как динамические массивы без осознания из STL-совместимости. (Я не про себя, если что, а про типовую ситуацию.)
Наверное, вы хотели сказать «десериализуем». В принципе, вы правильно поняли, что
> это не совсем то
Зачем мне какой-то дополнительный контейнер, если я хочу посчитать сумму, найти максимум, создать новый файл, который будет содержать только чётные числа из старого? Зачем мне дополнительная сущность в виде контейнера при решении каждой этой задачи? Бритва Оккамма решает…
И вы уверены, что память, на которую он будет указывать, всегда будет валидна? То есть не получится указателя на локальные ресурсы?
В общем, такая реализация (если её вообще можно сделать, в чём я не уверен сходу), будет сложней, чем моя. Семантика значения сильно проще во многих отношениях. С другой стороны, тут затраты на wrap не будут велики (особенно в случае встроенных типов, которые не сильно больше или даже меньше, чем указатель), и для моих задач эти затраты не играю никакой роли.
Кроме того, я думаю, что хороший компилятор постарается соптимизировать так, чтобы затраты на wrap были минимальны или их вообще не было (я думаю, это вполне возможно). В общем, интересно было бы, если бы кто-то сравнил. Но я, как уже говорил, сходу такое просто не могу написать.
Кроме того, подозреваю, что в этом варианте также, как в примере выше в комментариях, потеряем возможность работы с текстовыми файлами.
Про Google Protocol Buffers знаю, но никогда не использовал, к сожалению. Пример, выполняющий работу, аналогичную той, что в последнем листинге в статье — приветствуется!
Каждый раз писать свои классы долго и скучно (код был бы одинаковый с точностью до типов): на помощь приходят шаблоны (об этом сказано в тексте статьи).
Про аналог это правильно. Только, чтобы получить такой аналог в C++ (то есть, чтобы работать с бинарным файлом, хранящимся на диске, как с list), нужно идти на описанные в статье ухищрения.
ru_declarative.livejournal.com/97251.html
Я менее аккуратный в вопросах лицензий человек, так что я выбросил оттуда слайд с матом (заодно потерялись все гиперссылки, что ужасно), перевыложил в сеть университета (домен sfedu.ru) и дал ссылку студентам.
Это спорная оценка.