добрый день
есть след тесктовый файл
Цитата
bookmark3,value1
bookmark1,value2
bookmark2,value3

как его зогнать в std::map ?
т.е получить key = bookmark3 value = value1 ....

Приветствую, Анонимус, вы писали:

> есть след тесктовый файл
> Цитата
> bookmark3,value1
> bookmark1,value2
> bookmark2,value3
> как его зогнать в std::map ?
> т.е получить key = bookmark3 value = value1 ....

Парсер пишется на коленке за час максимум. Ориентироваться по запятой и переводу строки.

Здравствуйте, Аноним, Вы писали:

А>добрый день
А>есть след тесктовый файл
А>Цитата
А>bookmark3,value1
А>bookmark1,value2
А>bookmark2,value3

А>как его зогнать в std::map ?
А>т.е получить key = bookmark3 value = value1 ....

Типа этого:

typedef map< string, string > Bookmarks;

    Bookmarks bookmarks;

    ifstream file( "bookmarks.txt" );

    while( file )
    {
        string line;
        getline( file, line );

        size_t i = line.find( ',' );

        if( string::npos != i )
        {
            string key = line.substr( 0, i );
            string value = line.substr( i + 1 );

            bookmarks.insert( make_pair( key, value ) );
        }
    }

Здравствуйте, Sheridan, Вы писали:

S>Парсер пишется на коленке за час максимум. Ориентироваться по запятой и переводу строки.

Что там писать час...

You will always get what you always got
  If you always do  what you always did

Приветствую, jazzer, вы писали:

j> S>Парсер пишется на коленке за час максимум. Ориентироваться по запятой и переводу строки.
j> Что там писать час...
Оптимизировать (ц)

Здравствуйте, Sharpeye, Вы писали:

S>Здравствуйте, Аноним, Вы писали:

А>>добрый день
А>>есть след тесктовый файл
А>>Цитата
А>>bookmark3,value1
А>>bookmark1,value2
А>>bookmark2,value3

А>>как его зогнать в std::map ?
А>>т.е получить key = bookmark3 value = value1 ....

S>Типа этого:

S>

S>typedef map< string, string > Bookmarks;

S>    Bookmarks bookmarks;

S>    ifstream file( "bookmarks.txt" );

S>    while( file )
S>    {
S>        string line;
S>        getline( file, line );

S>        size_t i = line.find( ',' );

S>        if( string::npos != i )
S>        {
S>            string key = line.substr( 0, i );
S>            string value = line.substr( i + 1 );

S>            bookmarks.insert( make_pair( key, value ) );
S>        }
S>    }
S>

а если данные такие:
test1,test2
test3test4,
test5,test6

А>а если данные такие:
А>test1,test2
А>test3test4,
А>test5,test6

А Вы сами формально можете специфицировать формат файла? Если да, то по этой спецификации и пишите загрузчик.

J>Что там писать час...

TDD?

Здравствуйте, Sharpeye, Вы писали:

S>        string line;
S>        getline( file, line );

S>        size_t i = line.find( ',' );

S>        if( string::npos != i )
S>        {
S>            string key = line.substr( 0, i );
S>            string value = line.substr( i + 1 );

S>            bookmarks.insert( make_pair( key, value ) );
S>        }

Наверное можно упростить:

        string key, value;
        getline( file, key, ',' );
        getline( file, value );

        if( !value.empty() )
            bookmarks[key] = value;

Здравствуйте, Sheridan, Вы писали:

j>> S>Парсер пишется на коленке за час максимум. Ориентироваться по запятой и переводу строки.
j>> Что там писать час...
S>Оптимизировать (ц)

Здравствуйте, Аноним, Вы писали:

А>а если данные такие:
А>test1,test2
А>test3test4,
А>test5,test6

1) не ясно почему "test3test4,", а не "test3". Имелось в виду что-то конкретное, или это чисто так записалось?
2) IMHO, это должно обозначать, что ключу "test3test4" соответствует пустая строка Или такое соответствие должно записываться как-то иначе?

Здравствуйте, igna, Вы писали:


I>Наверное можно упростить:

I>

I>        string key, value;
I>        getline( file, key, ',' );
I>        getline( file, value );

I>        if( !value.empty() )
I>            bookmarks[key] = value;
I>

А где тут обработка ошибок? Например строк, где запятой вовсе нет?

ВСЁ!!!!!!!!!111111адинадин

Здравствуйте, Erop, Вы писали:

E>А где тут обработка ошибок? Например строк, где запятой вовсе нет?

Обработка ошибок такая же как в исходном варианте.

Здравствуйте, jazzer, Вы писали:

J>Что там писать час...

А сколько, три минуты? Так напиши и покажи, жалко что ли.

Вот например для случая set<string> в самом деле просто:

    set<string> ss(
        (istream_iterator<string>(in)),
        (istream_iterator<string>()));

Давай самое простое решение для map<string, string>, где key и value в файле разделены запятой.

Здравствуйте, igna, Вы писали:

I>Вот например для случая set<string> в самом деле просто:

I>

I>    set<string> ss(
I>        (istream_iterator<string>(in)),
I>        (istream_iterator<string>()));
I>

В таком варианте рискуем получить split по пробелам, а не только по строкам.

Здравствуйте, Centaur, Вы писали:

C>В таком варианте рискуем получить split по пробелам, а не только по строкам.

Да, конечно. Я просто привел пример, который на самом деле простой. В достаточно хорошо продуманной стандартной библиотеке замена признака окончания ввода не должна значительно увеличивать объем кода; как, впрочем, и замена set на map. Но имеем, что имеем.

Здравствуйте, igna, Вы писали:
I>Обработка ошибок такая же как в исходном варианте.
В исходном варианте строчки без запятых вроде как пропускаются...

Здравствуйте, Erop, Вы писали:

E>В исходном варианте строчки без запятых вроде как пропускаются...

В моем тоже.

Здравствуйте, igna, Вы писали:

I>В моем тоже.
Зато в твоём нельзя записать пустую строку, в качестве значения, а в исходном было можно...

Здравствуйте, Erop, Вы писали:

E>Зато в твоём нельзя записать пустую строку, в качестве значения, а в исходном было можно...

И что? Пустую строку в обоих вариантах и в качестве ключа можно записать, это что, нормально? В постановке задачи, которую мы здесь прочитали, не было ничего про то, как обрабатывать особые случаи, и (1) человек написал как написал; (2) я обратил внимание на то, что, во-первых, можно обойтись без промежуточной строки, во-вторых, лучше использовать operator[] для вставления в map; и (3) ты занимаешься ерундой.

Здравствуйте, igna, Вы писали:

I>Здравствуйте, Erop, Вы писали:

E>>Зато в твоём нельзя записать пустую строку, в качестве значения, а в исходном было можно...

I>И что? Пустую строку в обоих вариантах и в качестве ключа можно записать, это что, нормально? В постановке задачи, которую мы здесь прочитали, не было ничего про то, как обрабатывать особые случаи, и (1) человек написал как написал; (2) я обратил внимание на то, что, во-первых, можно обойтись без промежуточной строки, во-вторых, лучше использовать operator[] для вставления в map; и (3) ты занимаешься ерундой.

Вообще, я думал, у топикастера вызывает затруднение работа с map, string, ifstream, а не с алгоритмом, поэтому да, написал как написал .

Здравствуйте, igna, Вы писали:

I>(1) человек написал как написал;
Ну код у тебя неэквивалентен коду у него...
Кстати, ни ты ни он не проверяете, что такой ключ уже есть...
Просто как-то не понятно. Если речь идёт о том, как примерно можно написать, то не понятно зачем это "примерно" совершенствовать? А если речь идёт о подробностях реализации, то почему ты считаешь их несущественными тогда?

I>(2) <...> во-вторых, лучше использовать operator[] для вставления в map; и
Почему?

I>(3) ты занимаешься ерундой.
Это т. н. переход на личности? Или ты что-то другое имел в виду?

Здравствуйте, Erop, Вы писали:

I>>(2) <...> во-вторых, лучше использовать operator[] для вставления в map; и
E>Почему?

Из эстетических соображений.

Здравствуйте, igna, Вы писали:

I>>>(2) <...> во-вторых, лучше использовать operator[] для вставления в map; и
E>>Почему?
I>Из эстетических соображений.

Они, IMHO, субъективны...

Здравствуйте, Erop, Вы писали:

I>>Из эстетических соображений.

E>Они, IMHO, субъективны...

В данном случае operator[] еще и эффективнее, если значения string value длинные настолько, что их хранение приводит к выделению свободной памяти.

Здравствуйте, igna, Вы писали:

I>В данном случае operator[] еще и эффективнее, если значения string value длинные настолько, что их хранение приводит к выделению свободной памяти.

Это если строка без COW... К сожалению STL даёт мало гарантий по производительности, так что всё зависит...

Здравствуйте, Erop, Вы писали:

E>Это если строка без COW... К сожалению STL даёт мало гарантий по производительности, так что всё зависит...

Зависит. Тем не менее чаще всего в map именно value "тяжелая" часть, и копировать ее два раза вместо одного IMHO неразумно. Хотя Meyers в Effective STL дает именно такую рекомендацию, при заполнении map (то есть не при обновлении значений, а именно при заполнении) использовать insert, а не operator[]. Последний мол приводит в вызову конструктора по умолчанию для значения. Про то, что при использовании insert вместо конструктора по умолчанию вызывается конструктор копирования, Meyers почему-то не упоминает.

PS. Поставлю оценку super тому, кто разубедит меня и покажет, что Meyers прав.

Здравствуйте, igna, Вы писали:

I>...

Майерс таки не прав. Не прав в том смысле, что такая рекомендация не может быть безусловной, поскольку получаются совершенно разные последовательности операций:

map::insert:
передача параметра — конструктор value_type: копирование значения
создание ноды — конструктор копирования value_type: копирование значения

map::operator[] (обычно реализован как find + хинтовый insert):
find — никаких операций со значением
а далее insert — всё что описано выше, только в параметр подставляется значение, сконструированное по умолчанию
ну и потом уже, видимо, присвоение (map[i] = ...)

Итого, для типа значения:
insert: 2 копирования (полноценных)
operator []: конструктор по умолчанию + 2 копирования пустышки + присвоение

Для stl строк скорее всего использование [] будет более эффективным, поскольку операция копирования пустых строк практически бесплатна, а вот полноценное копирование затратно. В то же время, очевидно, что заполнение map<int, int> будет работать быстрее с использованием insert.

Здравствуйте, sokel, Вы писали:

S>operator []: конструктор по умолчанию + 2 копирования пустышки + присвоение

Теоретически, возможна реализация оператора [] без копирования

Автор: sokel
Дата: 17.04.09

. Но ни в одной реализации stl не замечена

Здравствуйте, sokel, Вы писали:

S>...

ну и ещё небольшое дополнение:

 bookmarks.insert( make_pair( key, value ) );

Если уж insert, то лучше использовать insert(map_type::value_type(...)), потому как для make_pair получаем уже 3 копирования!

Здравствуйте, sokel, Вы писали:

S>Если уж insert, то лучше использовать insert(map_type::value_type(...)), потому как для make_pair получаем уже 3 копирования!

Копирование при возврате из make_pair компилятор вправе оптимизировать.

Здравствуйте, igna, Вы писали:

I>Копирование при возврате из make_pair компилятор вправе оптимизировать.

Вправе, но не обязан:

#include <stdio.h>
#include <map>

struct value
{
    bool empty;
    value(int) : empty(false) {}
    value(): empty(true) { puts("default constructor"); }
    value(const value& other) : empty(other.empty) { puts(empty?"empty copy":"copy"); }
    value& operator = (const value&) { puts("assignment"); return *this; }
};
typedef std::map<int, value> test_map;

int main()
{
    test_map m;
    puts("insert(value_type):");
    m.insert(test_map::value_type(1, value(1)));
    m.clear();
    puts("\ninsert(make_pair):");
    m.insert(std::make_pair(1, value(1)));
    m.clear();
    puts("\noperator[]:");
    m[1] = value(1);
    return 0;
};

MSVC2005 Release, ACC +O3, gcc +O3:

insert(value_type):
copy
copy

insert(make_pair):
copy
copy
copy

operator[]:
default constructor
empty copy
empty copy
assignment

Здравствуйте, sokel, Вы писали:

I>>Копирование при возврате из make_pair компилятор вправе оптимизировать.

S>Вправе, но не обязан:

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

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

Здравствуйте, igna, Вы писали:

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

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

А в данном случае это "заведомо" или "возможно"? Или, может, "возможно не приводящий к выполнению избыточных действий".
Я привёл простой пример, в котором три компилятора показали что этот случай ближе к "заведомо". Значит, использование make_pair вместо value_type — это преждевременная пессимизация. Хотя у make_pair есть плюс — проверка типов, тогда как конструктор value_type может использовать скрытую (и, возможно, не предусмотренную) конвертацию.