| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > GUID from std::string |
| Автор: Master01 1.9.2010, 22:25 |
Ребята, кто-нибудь может подсказать есть ли вменяемый способ преобразовать строку в GUID, к примеру есть строка "{70DC58DE-8640-4288-85A3-DE353149376D}" нужно преобразовать всё это дело в GUID. Я понимаю что способы есть, но вот только они все какие-то слишком закавырестые для такой, казалось бы, распространённой операции.... Например, есть функция апи CLSIDFromString(LPOLESTR, &guid) на входе строка std::wstring wstr; куда проще! делаю CLSIDFromString(wstr.c_str(), guid) а не тут то было - с_str возвращает const wchar_t*, а мне нужен неконстантный массив! можно, конечно, объявить массив wchar_t, динамически выделить память под него а потом всё скопировать туда (std::copy) и передать всё это хозяйство в CLSIDFromString, НО ёлки-палки, почему так сложно! потом ещё надо не забыть по окончанию осовободить память, забранную под буффер! Ещё пробовал через boost::lexical_cast. Конечно, там такой конвертации нет, т.к. нету operator >> () для GUID, пришлось писать, написал, но опять же почему так сложно то? Просто вроде операция не экзотическая совсем, а на поверку оказывается что нормально инструмента нету ... ну или я не нашёл ... может вы подскажете? заранее спасибо ПС .NET не предлагать |
| Автор: jonie 1.9.2010, 22:30 | ||
UuidFromString функция есть.
|
| Автор: alexvs11 1.9.2010, 22:50 | ||
кхм
должно работать |
| Автор: ИванМ 1.9.2010, 23:24 | ||
Рекомендую простой способ:
|
| Автор: Master01 2.9.2010, 15:14 | ||
ха-ха  откровенно говоря, я просто постяснялся приводить константный тип к неконстантному, наивно полагая, что раз функция ожидает неконстантный массив, то значит это неспроста и она что-то там меняет, а раз так то это может нарушить целостность контейнера ...я всё ж в итоге сделал так
конечно, немного напрягает, но так я уверен что работать будет всегда. Такого шаманства с константностью лучше избегать всё ж... хотя в данном случае, наверно, можно... всем спасибо |
| Автор: ИванМ 2.9.2010, 15:24 | ||||
Master01,
На самом деле да. Но если точно знаешь, что параметр не сделан константным только по доброй воли программиста (а такое бывает даже в крутых библиотеках за $млн), то const_cast можно использовать.
Я посмотрел в MSDN эту функцию - первый параметр - IN. Поэтому и предложил. Хотя, возможно, я неправ. |
| Автор: Master01 2.9.2010, 15:28 |
да, согласен, конечно, что сonst могли просто и упустить... кстати, я вверху прогнал насчёт auto_ptr и массивов, но не суть важно |
| Автор: ИванМ 2.9.2010, 15:56 |
| А вот к auto_ptr у меня личная неприязнь. Я вообще придерживаюсь мнения, что в стандарте c++ он лишний. |
| Автор: mes 2.9.2010, 16:23 | ||
позвольте узнать, чем он вам не угодил ? |
| Автор: ИванМ 2.9.2010, 16:36 | ||
Мое мнение такое, что разные части одной библиотеки (под библиотекой подразумеваю всю библиотеку C++ вообще) должны гармонично взаимодействовать друг с другом. А auto_ptr не хочет дружить с контейнерами. Поэтому, ИМХО, его в топку.  Знаю что есть мнения, что для каждого свое предназначение, но для меня это не аргумент. Пользуюсь boost и доволен. Вот shared_ptr, ИМХО, надо стандартизировать. |
| Автор: mes 2.9.2010, 16:42 | ||||
он дружит показывая (на нормальных компиляторах) контейнеру то, что его нельзя в нем хранить
уже... только ведь шаред предназначен для несколько инхых задач |
| Автор: ИванМ 2.9.2010, 16:51 | ||||||
Это как раз тот аргумент, о котором я говорил. Объясню мое мнение. shared_ptr можно использовать везде, где используется auto_ptr. А дополнительные накладные расходы - актуально, но 10 лет назад. Добавлено через 1 минуту и 23 секунды
Уже вышел стандарт 0x? Или это ухмылка? |
| Автор: Master01 2.9.2010, 21:11 |
| а вот интересно зачем в бусте наряду с shared_ptr предлагают также и scoped_ptr - это ведь вроде такие же non-copyable указатели? и ещё насчёт контейнеров - по идее они должны дружить с intrusive контейнерами, которые хоть и являются гораздо менее востребованными чем обычные контейнеры, но в некоторых ситуациях просто не заменимы. (хотя они вне стандарта) на самом деле я auto_ptr тоже редко использую, поэтому и промахнулся с массивом а ещё похоже что гуру С++ по этому вопросу тоже не сошлись - помниться Мейерс рекомендовал бежать от них как от огня, так же как и от vector<bool>, но зато у Александреску в "Современном проектировании" в примерах иногда auto_ptr проскакивали.... (as I remember) |
| Автор: alexvs11 2.9.2010, 21:55 | ||
как то маловероятно, но даже так, в 99% c_str вернет указатель на внутреннее представление строки, а оно по стандарту должно линейно представлятся в памяти, вообщем ничего не будет  |
| Автор: Master01 2.9.2010, 22:32 |
маловероятно по сравнению с чем? что это за оценка такая 99%? кем и как измеренно? почему вы думаете что дл ямоей задачи это приемлемо? а что произойдёт в оставшийся один процент? настораживает тут не то, что модификация не пройдёт, а как раз обратное ... |
| Автор: alexvs11 2.9.2010, 22:35 | ||
то что реализация библиотеки поместит строку в защищенную область памяти и при работе произойдет крах например |
