Ребята, кто-нибудь может подсказать есть ли вменяемый способ преобразовать строку в 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 не предлагать

UuidFromString функция есть.
а можно присвоить std::wstring-у ваш std::string .... для обычных типов прокатит, либо использовать UuidFromStringA функцию (что особо не рекомендуют)

кхм


должно работать

Это сообщение отредактировал(а) alexvs11 - 1.9.2010, 22:50

Рекомендую простой способ:

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

я всё ж в итоге сделал так 



конечно, немного напрягает, но так я уверен что работать будет всегда. Такого шаманства с константностью лучше избегать всё ж... хотя в данном случае, наверно, можно...


всем спасибо

Master01, 

На самом деле да. Но если точно знаешь, что параметр не сделан константным только по доброй воли программиста (а такое бывает даже в крутых библиотеках за $млн), то const_cast можно использовать.


Я посмотрел в MSDN эту функцию - первый параметр - IN. Поэтому и предложил. Хотя, возможно, я неправ.

да, согласен, конечно, что сonst могли просто и упустить...

кстати, я вверху прогнал насчёт auto_ptr и массивов, но не суть важно

А вот к auto_ptr у меня личная неприязнь. Я вообще придерживаюсь мнения, что в стандарте c++ он лишний.

позвольте узнать, чем он вам не угодил ?

Мое мнение такое, что разные части одной библиотеки (под библиотекой подразумеваю всю библиотеку C++ вообще) должны гармонично взаимодействовать друг с другом. А auto_ptr не хочет дружить с контейнерами. Поэтому, ИМХО, его в топку.  
Знаю что есть мнения, что для каждого свое предназначение, но для меня это не аргумент. Пользуюсь boost и доволен. Вот shared_ptr, ИМХО, надо стандартизировать.

он дружит показывая (на нормальных компиляторах)  контейнеру то, что его нельзя в нем хранить 



уже...

 только ведь шаред предназначен для несколько инхых задач 


Это сообщение отредактировал(а) mes - 2.9.2010, 16:43

Это как раз тот аргумент, о котором я говорил. Объясню мое мнение. shared_ptr можно использовать везде, где используется auto_ptr. А дополнительные накладные расходы - актуально, но 10 лет назад.

Добавлено через 1 минуту и 23 секунды

Уже вышел стандарт 0x?
Или это ухмылка?  

а вот интересно зачем в бусте наряду с shared_ptr предлагают также и scoped_ptr - это ведь вроде такие же non-copyable указатели?

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

на самом деле я  auto_ptr тоже редко использую, поэтому и промахнулся с массивом 

а ещё похоже что гуру С++ по этому вопросу тоже не сошлись - помниться Мейерс рекомендовал бежать от них как от огня, так же как и от vector<bool>, но зато у Александреску в "Современном проектировании"  в примерах иногда auto_ptr проскакивали.... (as I remember)

как то маловероятно, но даже так, в 99% c_str вернет указатель на внутреннее представление строки, а оно по стандарту должно линейно представлятся в памяти, вообщем ничего не будет  

маловероятно по сравнению с чем? что это за оценка такая 99%? кем и как измеренно? почему вы думаете что дл ямоей задачи это приемлемо? а что произойдёт в оставшийся один процент? 

настораживает тут не то, что модификация не пройдёт, а как раз обратное ...

то что реализация библиотеки поместит строку в защищенную область памяти и при работе произойдет крах например