, далее s укорачивается, потом надо перегнать s назад в FileOpenDialogDirrectoryPath, не замусоривая хвост буфера. c_str почему-то не помогает.


Это сообщение отредактировал(а) ТарасАтавин - 26.8.2013, 12:07

  Обычно так и происходит, так что код в студию

. Не компилится.  компилится, но не фурычит.

пишется обычно TCHAR (WCHAR, CHAR), например WCHAR('\\')
но это ладно


даёт подстроку без всего, что после последнего слэша


даёт подстроку без последнего слэша и всего, что после него

Это сообщение отредактировал(а) akizelokro - 27.8.2013, 08:36

_T не определено, проект чисто уникодовый. И строка-объект обрабатывается правильно, проблема в копирожании её назад в массив широкочаров. Кстати, зачем обрезь строки простым эрейзом превращать в комбинацию вычисления новой строки и не нужного присваивания? У пасквилянтов научились? А по поводу функции у меня вопрос: как её возвращаемое значение дружит с типом size_t? И потрудитесь ка отличить объект от указателя: или точка вместо ->, или *str= вместо str=.


Это сообщение отредактировал(а) ТарасАтавин - 27.8.2013, 08:14

Это по желанию, мне просто удобней работать через TCHAR и tstring, чтобы больше никогда не заморачиваться с перекомпиляцией или переносимостью. Просто я увидел TCHAR и решил, что _T вы подключили. Иначе бы WCHAR написали, наверно


Можно и так, я чтобы не заморачиваться выдрал её из какого-то кода, можно и erase использовать, это уже не суть важно. Просто есть стандартная find_last_of() для строк, имхо использовать лучше её. Я думал, у вас с этим проблемка.
А если вам надо wstring закопировать в WCHAR, так надо просто копировать. А вы присваивате 

аналог strcpy ищите. Потому что у вас небось потом что-то в этот массив FileOpenDialogDirrectoryPath должно и записаться


Это где, в find_last_of? Номер предупреждения можно подавить прагмой. Лично я закрываю глаза на этот кусок кода, потому что возможное переполнение прошло бы раньше

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

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


Это сообщение отредактировал(а) akizelokro - 27.8.2013, 08:32

А как его зовут? Кроме того, у меня и с самой функцией strcpy проблемы, так что для ансичара мне проще самому её написать, чем юзать готовую. А вот с нервнобайтной кодировкой нуль-треминала беда. Вообще не могу с такими строками ничего толкового сделать.

Это сообщение отредактировал(а) ТарасАтавин - 27.8.2013, 08:39

Про str=str.sub.

Добавлено через 3 минуты и 51 секунду
В отладке видно, что буфер не изменился вовсе. При этом строка-объект s правильная, что тоже видно на отладке.

Добавлено через 7 минут и 12 секунд
При чём здесь предупреждение? Для меня не проблема привести тип при присваивании. А вот с чем потом сравнивать значение?

Добавлено через 9 минут и 4 секунды
size_t - единственный тип, гарантирующий, что ни какой контейнер не способен переполнить его количеством своих элементов ни на одной возможной платформе.

Про str.substr(...)?
да нет, кажется приведение long к size_t нормально работает, а вот обратное - чаще с предупреждениями.



есть и просто аналоги копирования из буфера в буфер
описание

ANSI в OEM и обратно конвертить удобнее всего через CString (если MFC подключен). но можно и без MFC постараться, когда делал такое

Это сообщение отредактировал(а) akizelokro - 27.8.2013, 08:52

Не обращайте внимания, вы правильно всё говорите, просто у меня старые привычки чуть ли 20 летней давности. В программе,откуда кусок кода выдран, это пр9иведение long к size_t или наоборот роли не играет. А так - да. Вы правильно всё говорите.


обнулите его для лучшей видимости


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

M GremlinProg

Тема перемещена из раздела C/C++: Системное программирование и WinAPI