Естественно нет. Попробуй ради интереса проследить зависимость sizeof(Codes) от количества хранимых в Codes елементов.
Hint: каждый узел — динамический объект. Кроме того, std::string также хранит свое содержимое в динамическом буфере.
_L_>Если нет, то каков правильный варинт.?
Для текстового файла можно так:
ofstream out("map.txt");
out << Codes.size() << '\n';
map<char, string>::iterator b = Codes.begin(), e = Codes.end();
for(; b != e; ++b)
out << b->first << '\t' << b->second << 'endl';
//дальше твои данные
Для бинарного бедет несколько сложнее — нужно будет вручную организовать звпись строк.
Здравствуйте, _Lestat_, Вы писали:
_L_>Можно ли так делать? Если нет, то каков правильный варинт.?
Так делать нельзя, потому как std::map и std::basic_string не POD типы и работают с динамической памятью. Ты просто сохраняешь состояние объекта, так как он есть в памяти. Объект агрегирует в себя указатели, не факт (вообще это мало вероятно), что эти указатели будут валидны при попытке загрузить этот объект обратно;
"В любое мгновение принятия решения, лучшее, что вы можете сделать, это принять правильное решение; следующим лучшим вариантом будет принять неправильное решение, худший вариант – не принимать решения совсем" (c) Теодор Рузвельт.
_L_>Можно ли так делать? Если нет, то каков правильный варинт.?
Правильный вариант -- не использовать ассоциативное хранилище там где оно не нужно.
// таблица
string table[MAX_CHAR];
// получить строку по символу chchar ch;
string &rule = table[unsigned(ch)];
Получится даже быстрее, потому что не нужен поиск по сбалансированному бинарному дереву, который в твоем случае требует log2(256) = 8 итераций не самого быстрого цикла,
Я ожидал, что мой вариант неправильный, т.к. map — это динамический класс.
В итоге я сделал просто. Формат файла получился такой: количество_элементов_в_контейнере, char, длина string, сам string, char, длина string, сам string, и т.д.
Здравствуйте, _Lestat_, Вы писали:
_L_>В итоге я сделал просто. Формат файла получился такой: количество_элементов_в_контейнере, char, длина string, сам string, char, длина string, сам string, и т.д.
В ранее предложенном мною варианте количество элементов контейнера не используется. Взгляни.
Здравствуйте, _Lestat_, Вы писали: _L_>Можно ли так делать? Если нет, то каков правильный варинт.?
БугагагГ!!! Долго ржал!!!
ИМХО, boost::serialization тебе поможет ...
... и ещё раз БуГаГаГГГ!!!
"Дайте мне возможность выпускать и контролировать деньги в государстве и – мне нет дела до того, кто пишет его законы." (c) Мейер Ансельм Ротшильд , банкир.
Здравствуйте, siv, Вы писали: siv>В теории верно, на практике чревато Ибо на стороне писателя и siv>читателя может быть разное выравнивание...
... мне кажется с тех пор как придумади механизм засериализовать всё что угодно в строку и оттуда же это всё десериализовать, бинарное перепехивание POD объектов стало экзотическим извратом!
"Дайте мне возможность выпускать и контролировать деньги в государстве и – мне нет дела до того, кто пишет его законы." (c) Мейер Ансельм Ротшильд , банкир.
Здравствуйте, Roman Odaisky, Вы писали:
RO>И в самом деле, интересно: по стандарту можно реализовывать std::map<char, X> как X[256]? И, если можно, кто-то так делает?
Нельзя.
Элемент мапа (value_type) — это pair<const Key, Value>.
Синтезировать его в итераторе (как это делается у vector<bool>) нельзя, т.к. ссылки и указатели на элементы не должны инвалидироваться при разрушении итератора.
Плюс ещё нужно где-то хранить признаки присутствия. То есть,
— pair<bool, storage<value_type>>[256]
— (value_type*)[256]
— storage<value_type>[256] + bool[256]
где storage<T> — выделенная, но не инициализированная память под объект типа T.
Далее встаёт вопрос о sizeof(map<char,Value>) — значит, массив должен быть динамическим.
Ну и самое главное — этот подход годится только для map<char,Value,Pred,Alloc> у которых
— Alloc способен создавать массив, а не только мелкие объекты (узлы дерева)
— Pred — это less<char> либо greater<char>, либо ещё какие-то порядки, для которых известна проекция на числовую ось, т.е. Pred(c1,c2) == Index(c1)<Index(c2)
(для less<char> Index(c) = (unsigned char)c, а для greater — соответственно, (unsigned char)(-c)).
Так что проще не заморачиваться со специализацией, а делать правильный контейнер "по мотивам".