Хитрый memcpy

Напиши свою, вопрос фигня

//currentPointer += someDataSize; <-- вот этот кусок кода должен выполнится во время memcpy

Вряд ли такое непотребство есть в стандартной библиотеке. Ведь функции стараются писать по возможности без сайдэффектов.(хотя есть же всякие там strtok). В общем пиши свою, но всё-таки это как-то не по понятиям, имх, такое поведение функции.

Делаю сериализацию/десериализацию. Сначала все сохраняю в char*, потом оттуда считываю. Вот эти вот += уже писать поднадоело. Думал, что-нибудь стандартное уже есть.

есть. std::vector, к примеру.

http://wiki.shelek.ru/index.php/FAQ:STL:C++_сериализация_данных

Хм. Что-то я про него забыл. А он сможет потом мне все отдать _быстро_ в виде массива?

Вот эти вот += уже писать поднадоело.

ну можно ещё макрос написать. Хотя странно это, что уж так часто тебе писать приходиться этот +=. Может там цикл какой привинтить или ещё что.
ну тады, когда будешь писать, добавь ещё параметр max_size, чтоб проверяло на переполнение.

char data[max_size];
memcpy(&currentPointer,someData,someDataSize,max_size);

Спасибо за ссылку, полезная информация.
Один вопрос, сереалайз ведь вроде бы не только из исходников состоит, там еще и либина нужна?

Если имеется в виду «string of bytes» - то нет.

vector сам по себе является массивом. Конкатенировать векторы тоже достаточно просто.

С++ не поддерживает интроспецию, так что все поля приходится обходить вручную. К тому же они разного размера со всеми вытекающими.
К тому же я не так уж и много этих += понаписал, но я вообще ленивый, а когда приходится делать монотонную работу, то становлюсь суперленивым. Так что пойду писать свою функцию.

P.S. за max_size отдельное спасибо. Полезная фишка.

Ну да, boost таки нужен. Но сначала нужно решить нужен ли он и вправду. К тому же можно boost статически линковать.

Не, мне там сериализовать то надо - board для крестиков/ноликов. Ради этого впиливать буст в андроид-приложение - это слишком.

typedef struct {
  char *p;
  int len;
  int cons;
} buff_t;

#define INITB(b,p,l) \
  ((buff_t)(b)).p=((char *)(p)); \
  len=(l);cons=0


#define EATB(b,dst,num) \
  assert((b).cons+num<(b).len); \
  memmove((dst),((b).p+(b).cons),(num)); \
  (b).cons+=(num)
  

шото типа такого.

Есть алгоритм copy.

Вот эти вот += уже писать поднадоело.

А написать свою функцию из 2-3 строк тебе не позволяют?

Что-то мне подсказывает, что тебе следует написать storage класс для этих действий. Или хотя бы inline-функию или макрос, как уже заметили.

mempcpy(), но это GNU extension

c++
Есть ли в стандартной библиотеке такой memcpy

http://www.cplusplus.com/reference/algorithm/copy/

currentPointer = std::copy(someData, someData+someDataSize, currentPointer);

андроид-приложение
c++

Прошу прощения, а разве андроид-приложения не на жабке пишут?

там есть поддержка C/C++ через NDK

ну он же потянет не все, а только одну либину по ходу

С++ не поддерживает интроспецию, так что все поля приходится обходить вручную. К тому же они разного размера со всеми вытекающими.

Есть два культурных пути: либо как в boost::serialization (при каждом классе оператор, перечисляющий его поля), либо как в google protobuffers (кодогенерация из специального языка в c++). Ну и еще третий путь: с опорой на парсер компилятора (парсить c++ код в xml, а из xml генерировать c++ код сериализаторов).

там есть поддержка C/C++ через NDK

Разве это не приведет к тому, что нужно будет скомпилировать программу под каждое из зоопарка андройд-устройств?

только для arm6 и arm7, можно только для armv6 но профита для armv7 не будет

А как же всякие mips, x86 и прочее неведомое говно?

ну для них тоже с ними не сталкивался пока

boost::serialization? Данунах!!!

Юзать либу, в которой почти в каждой новой версии ломают совместимость сериализованых данных - спасибо. А потом ипаться с линковкой нового буста и старого boost::serialization. Понарывался на это говно, теперь даже идея сериализации вручную не так дико смотрится.

А ну, может быть. Я обычно в Qt сеарилизовал, а boost для таких целей не использовал.

Так вот, продолжай юзать Qt. Там можно задать версию бинарного формата, а значит всё ок. А юзабельность boost::serialization с учетом этого фейла околонулевая.

ради сомнительной выгоды ты готов пустить бесов в проект? а ты смелый :)

вообще, чего ты плачешь - напиши свой аллокатор, он тебе во время memcpy ещё и калинкумалинку танцевать будет, какие проблемы?

прочитал тред, ТС ты пишешь копипаст-портянки что-ли?

man mempcpy

а зачем, вообще, память по адресному пространству гонять?

а зачем массив, когда есть список?

как с фрагментацией памяти борешься?

Я так понял, что у него есть большой кусок памяти из которого он вычитывает с помощью memcpy структуры и сдвигает указатель.

Вот эти вот += уже писать поднадоело.

Оберни доступ к буферу в какой-нибудь ЧтоТоТамStream, в нём и делай +=.

1. Сейчас у меня такой период, стараюсь использовать только уже готовые библиотеки. Пытаюсь вообще не выходить за рамки std.

2. Предложите ваш вариант сериализации объекта, у которого есть 10 полей разного размера и типа (в том числе некоторые из них массивы) без портянки (для каждого поля один memcpy и один += ).

Спасибо тебе, добрый анонимус. Судя по man, именно это я и искал.

Какая фрагментация? Этот массив потом отдается андроидовскому savedState. Как мне тут поможет список - не очень понятно.

С++ не поддерживает интроспецию, так что все поля приходится обходить вручную.

А помочь ему в этом? Создать вспомогательную структуру, описывающую сериализируемые данные, которая и при десериализации будет использоваться. Тогда сам процесс копирования будет простым. И при изменениях нужно будет просто отредактировать структурку, но не трогать код цикла.

По уму так и нужно было делать, но надо бы было очень долго думать над подобной структурой, чтобы она потом могла использоваться и в наследниках тоже. В итоге я решил сделать все по-быстрому, кода получилось около 20 строчек (сериализация/десериализация).

void *heap_addr = sbrk((ptrdiff_t) 0)

/*здесь многочисленные maloc, free, new, delete*/

void *heap_end = sbrk((ptrdiff_t) 0)

ну и потом первый адрес передаёшь

куча все дела.

p.s. не знаю что такое savedState и андроид

1. Сейчас у меня такой период, стараюсь использовать только уже готовые библиотеки. Пытаюсь вообще не выходить за рамки std.

В итоге я решил сделать все по-быстрому, кода получилось около 20 строчек (сериализация/десериализация).

Да, мне тоже часто не хочется брать целую библиотеку, если кода самому писать не много. А вот чего хочется, так это, чтобы к библиотеке была документация, как в кратце они реализовали функционал. Чтобы свои 20 строчек имели сравнительное качество, но в них был только мой частный случай. Тогда получаем 2в1: проверенное решение + без доп. зависимостей.

А зачем его серилизовать?

android.application.savedState

Надо его туда правильно сохранить, а потом еще и правильно его оттуда считать.

android.application.savedState

это я знаю, я не понял зачем тебе его серилизовать вообще?

Пользователь играет, затем свернул приложение, назапускал кучу софта, моя игра была убита. Потом пользователь решил завершить партию.

Для того, чтобы ее продолжить - надо ее сначала сохранить, как массив в памяти, а потом загрузить. Для этого ее надо сначала сериализовать, а потом десериализовать.

Вроде бы все верно.
Или я где-то ошибся?

Как непоноценный вариант, можно сказать чтобы приложение не убивалось из памяти, те оно может быть убито, но в самом крайнем случае
Только чесно говоря сейчас не помню что нужно для этого дописать

Костыли. Объективно - приложению не нужно оставаться в памяти, но эта же самая память может понадобится для других приложений.

А программистов, которые вместо того, чтобы осиливать сериализацию/десериализацию занимаются подобным рукоблудством, необходимо вышвыривать из профессии на мороз.

Без права апелляции.

ты не понял чувак, ты можешь сохранять только когда приложение собирается закрыться -убиться а не при каждом android.application.savedState хотя что тебе конкретно нужно я хз

Нет, только когда ОС пришлет мне запрос на сохранение. Она его как раз и присылает, когда собирается с приложением сделать что-нибудь нехорошее =)