есть массив hex значений вида
std:string data="656667686970";
Нужно из этого получить тот же std::string со символами. std::string result="abcdef"


Как сделать преобразование из int a=65 я знаю, но как string "F4" или "DB" в этот int правильно сконвертить не знаю.

itoa последним параметром ставишь 16

У меня,например, не поддерживается.  (gcc версия 4.4.1)

Добавлено через 12 минут и 19 секунд
Пока сделал через sscanf


в hex читаю по два символа из строки

Как-то так (без проверок на ошибки):

Это сообщение отредактировал(а) bsa - 11.1.2012, 13:09

ой, что-то сильно сложно. data - это std::string ?, Но на сколько я помню порядок символов не гарантируются (могу ошибаться), так что использовать data[i] нельзя

хорошо, чем вот такой код плох ?

http://liveworkspace.org/code/5b3ff759aa91...7407b4ee7afe975
это то, что ты хотел ?
скажи, что именно в результате должно получиться в строке result исходя из твоего же примера


символ с кодом 0x2A, затем символ с кодом 0x64, затем символ с кодом 0x44 и т.п. ?
если да, то код вроде правильный, за исключением того, что если в исходной строке будет 0x00, то все дальнейшие символы будут проигнорированы

что тут сложного? напиши комментарии и все станет очевидно
этот код на основе твоего в первом посте. названия переменных те же.
порядок символов чего? почему нельзя использовать data[i]? ты что-то с чем-то путаешь. если у объекта метод/оператор есть, значит его можно использовать.
И этот код работает

Да, вывод правильный. Известно, что 0x00 не будет.


http://lib.rus.ec/b/191841/read
Вот это имелось введу...

а где ты видишь у bsa требование к непрерывности данных ???
оператор [] гарантирует, что он вернёт i-й элемент. Что и требовалось

borisbn, Я сразу указал, что не уверен в этом, просто читал о чем-то подобном. Можно тогда уточнить, это имеется введу. Когда это проявит себя?

в этом случае c[ 1 ] совершенно необязательно будет указывать на 4.
Если же сделать так

то всё будет OK, т.к. c_str() уже гарантирует непрерывность строки

То что string не гарантирует это только в документации написано. На самом деле реализовать стринг через тот же deque будет совсем нетривиально, потому что c_str() является константным методом. Т.е. внутри стринга кроме хранилища символов должен быть еще и mutable указатель на область памяти, куда будет пихаться результат работы c_str()... Я очень сильно сомневаюсь, что кто-то будет так реализовывать. Значительно проще сделать в непрерывной области и с 0-м на конце. В этом случае c_str() имеет константную сложность.
Но это так, отступление. Если в документации не написано, что "непрерывность гарантируется" (как для vector) или написано обратное, то надеяться на "авось" нельзя.

Честно признаться, сам не проверял, а поверил volatile в этой теме (вернее вот это сообщение)

Видел где то реализацию string, которая хранила последовательность сегментов символов (ну и до кучи реализовавала COW). Реализация была направленна на эффективную работу с арифметикой строк (конкатенация и выделение подстрок).

эх а на асме эта конверсия в пару строчек получится

написать? )))

Если реально в пару строчек, то да, напишите.  
Да, не. Шучу.


да не проверял я ничего, прямо так уж систематически. я просто хотел сказать, что этому придают слишком большую значимость,
то есть мифическая угроза, отвлекает от рельных проблем.
И этот топик, еще одно тому подтверждение.
В коде bsa, нет и намёка на неправильное использование стринга, однако, запуганные этой мифической угрозой программеры, пытаются найти черную кошку в черной комнате, которой там нет.  

Еще одна такая проблема big-endian/little-endian. Один знакомый программер очень озабочен был этой проблемой вычитанной у страуструпа, или еще у кого-то из патриархов. Причем писал он исключительно под венду. Я ему говорю, что венда не работает на биг-ендиен, и типа расслабсья.. Но он ни в какую не верил.  .
Можно конечно сказать, что это хорошо, и что его код, при необходимости легче будет перенести на биг-едниен, если такая задача возникнет. Но такая задача никогда не возникнет, просто потому-что есть еще 100000001 причина, по которой код не будет работать нигде кроме венды. Так зачем тогда тратить столько сил именно на на этот ендиен, как будто нет других проблем...
эх, ладно, щас опять скажут что я подрываю устои платформанезависимого програмирования....

Это сообщение отредактировал(а) volatile - 13.1.2012, 01:42

в AL заносим наш char - 0,1,2,3,4,5,6.7.8.9 - A,B,C,D,F (регистр значения не имеет, коректируем там по ходу)
на выходе в AL бинарное значение 

то есть в примере заносим в AL код буковки D (ascii) = 0x44 или 0x64 в зависимости от регистра
на выходе в AL получаем бинарное значение = 0xD

500mhz, интересно, а во что тогда компилятор превратит:
gcc (gcc -O1 -c -S prog.c -o prog.S) меня удивил:

видимо компилятор не знает о битовых операциях и BCD арифметике )))

кстати, а ты уверен в корректности использования "ASCII Adjust After Addition" после операции вычитания?

а что не правильно работает разве?

еще более интересен вопрос о корректности ААА, без операции вычитания. 
Там по другому разветвлению, вообще ни одна комманда не влияет на флаг AF
сдедовательно результат будет зависеть от кода который расположен выше, и который здесь не приведен.

от фазы луны, другими словами.
 

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


500mhz, Вот перед этим вашим кодом добавьте што-нибудь влияющее на флаг AF,
например:
        mov al, 7
        add al, 9
 и сможете сами ответить на сакроментальный вопрос 

volatile

код как бэ намекает что в начале должно быть xor eax,eax для соблюдений правил "техники безопасности"



Добавлено через 4 минуты и 12 секунд
по поводу "корректности" команд, есть неописуемый случай (уже классика)



тоже не корректное использование cmp ?

Не вижу никакой связи с предыдущим кодом, и разбирать его это уже полный оффтоп.
Вернемся к нашим баранам.

Для сравнения, код 

откомпилированный студией:

по-ходу студия еще и без условных переходов сделала. (условнй переход == лишний тормоз)

Это примерно,  тот-же участок, что и ваш:


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

интересно где это я ошибся? 

пс
разве топик называеться АSM VS C ?

почитайте выше, ваш первый код содержал ошибку.
вы ее исправили, (добавив xor).
это кстати вовсе не очевидная ошибка, и при отладке и тестировании она наверняка не всплывет.
а всплывет где-то потом, у юзера, и то по редким стечениям обстоятельств.
(такой тип ошибок, я считаю самыми мерзкими.)


так вы же сами предложили.   

круто студия оптимизировала (не знал про операцию set*). В итоге код получился:

Это сообщение отредактировал(а) bsa - 15.1.2012, 17:51