Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Общие вопросы > Как реализовать правильней?

Автор: andrew_121 20.6.2009, 18:56

Ситуация следующая. Есть набор строк. Код static const char *sources_ext[] = {     "c",     "cc",     "cpp",     "cxx" }; static const char *header_ext[] = {     "h",     "hh",     "hpp",     "hxx" }; static const char *resources_ext[] = {     "res",     "rc" }; static const char *objects_ext[] = {     "o",     "obj" }; static const char *lib_ext[] = {     "a",     "lib" }; static const char *dynlib_ext[] = {     "so",     "dll" }; Есть расширение файла в виде строки. По расширению нужно определить тип файла. Это можно сделать при помощи функций. Код bool is_cppfile(const QString&); bool is_cfile(const QString&); bool is_hfile(const QString&); bool is_objfile(const QString&); bool is_rcfile(const QString&); bool is_rcbinfile(const QString&); bool is_staticlibfile(const QString&); bool is_dynlibfile(const QString&); bool is_unknownfile(const QString&); Но как-то нелепо   Нужно чтоб функция: Код typedef enum {     cppfile,     cfile,     hfile,     objfile,     rcfile,     rcbinfile,     staticlibfile,     dynlibfile,     unknownfile } types; types determine_filetype(const QString&); возвращала тип файла. Предложите что нить более правильное. Спасибо! Добавлено @ 18:57 П.С. Не знаю куда отнести .def файл. Дополните пожалуйста расширения файлов. Если что-то пропустил.

Автор: zim22 20.6.2009, 19:21

Цитата(andrew_121 @  20.6.2009,  18:56 ) Предложите что нить более правильное. ассоциативный массив не хотите завести? Код map<sting /* name */, eType /* enum: cpp, c, etc */ > extension; eType result = extension["lib"]; // result contains staticlibfile *** только имейте ввиду, что эта строчка Код eType result = extension["lib"]; будет выполняться весьма специфически  т.е. если "lib" будет найдено - вернётся его значение. если не найдено - ключ lib создастся со значением по умолчанию для типа eType так что более правильно через функцию map::count проверять есть ли элемент в map или нет ;)

Автор: andrew_121 20.6.2009, 19:27

Цитата(zim22 @  20.6.2009,  19:21 ) ассоциативный массив не хотите завести? Т.е. Все категории запихнуть в один массив? Вариант!

Автор: nix_crash 20.6.2009, 21:17

Это я, Andrew_121. Получил бан. Не понятно за что... Наверное за нелюбовь к виндавз  По теме: Цитата(zim22 @  20.6.2009,  19:21 ) т.е. если "lib" будет найдено - вернётся его значение. если не найдено - ключ lib создастся со значением по умолчанию для типа eType Да. Естественно. Уже сделал. Спасибо за помощь! Тема закрыта. Добавлено через 1 минуту и 15 секунд ГЫ   Закрою когда бан вылечу

Автор: Любитель 21.6.2009, 11:31

Цитата(zim22 @  20.6.2009,  19:21 ) так что более правильно через функцию map::count проверять есть ли элемент в map или нет ;) Зачем count?! find - вернёт итератор для найденного элемента. Если он неравен myMap.end() - разыменовываем его и возвращаем, если равен - возвращаем какое-нибудь значение для неизвестного типа файла.

Автор: zim22 21.6.2009, 11:44

Цитата(Любитель @  21.6.2009,  11:31 ) Зачем count?! find - вернёт итератор для найденного элемента.    http://www.cplusplus.com/reference/stl/map/count/ Complexity: Logarithmic in size. http://www.cplusplus.com/reference/algorithm/find/ Complexity: At most, performs as many comparisons as the number of elements in the range [first,last). *** ааа, понял! вы наверное имели ввиду не std::find из <algorithm>, а std::map::find  тогда да, согласен    standard: Цитата a.find(k)  - logarithmic a.count(k)  - log(size())+count(k)

Автор: azesmcar 21.6.2009, 12:00

zim22 А зачем сравнивать std::map::count и std::find? Это не честно   std::find - универсальный алгоритм, он работает на всех, STL совместимых контейнерах, но...универсальные алгоритмы не рекомендуется использовать на тех контейнерах, которые имеют свою собственную реализацию. Алгоритм find не может знать ничего он внутренней структуре map и потому ищет линейно.

Автор: Любитель 21.6.2009, 12:19

Цитата(zim22 @  21.6.2009,  11:44 ) ааа, понял! вы наверное имели ввиду не std::find из <algorithm>, а std::map::find  Естественно. ТЫ предлагаешь count, а затем ещё и индексатор. В плане производительности - один find (для бинарного дерева - с логарифмической сложностью само собой) будет лучше

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)