Дана строка std::wstring, в неё прочитан из преобразован и кодировки utf8 файл, требуется вывести файл на экран с сохранением перевода строк, а для этого надо разобрать строку на строки файла. ,
. Вот это поле Text и надо вывести с сохранением перевода строк, а для этого разобрать на строки файла. Как это сделать? Заранее не известно, сохранён ли файл в виндузячем, или в линуксоидном переводе строк.

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

ТарасАтавин, ты лучше приведи пример того, что находится в файле.
Кстати, а кто сохраняет HWND в файл?!? Это же указатель и он валиден только в пределах одного приложения (более того, после перезапуска приложения он станет невалиден).

И что это дало?

Добавлено @ 11:15
Это где ж такое?

Это сообщение отредактировал(а) ТарасАтавин - 28.8.2013, 11:17

Если <regex> не реализован, а в винде С++ он пока не реализован, то тупо разбираешь строку на подстроки по символам новой строки TCHAR('\n') или 



как-то так. да и разбор файла можешь попроще сделать. если файл текстовый, то 



Добавлено @ 11:44
и, кстати, здесь тебе сразу же разница между ifstream.getline(..) и std::getline(..)

Это сообщение отредактировал(а) akizelokro - 28.8.2013, 12:17

Вопрос не в парсинге строк, а в том, как разобрать на них единую строку. То есть задача не  получить, а целиком . Именно в той разбивке на строки, как в файле.

Добавлено @ 12:20
Проект полностью юникодовый. И я не знаю, в каких переносах сохранён файл.

Добавлено через 6 минут и 1 секунду
Имя файла тоже в широкой уникодовой стоке, у потоков с этим проблемы, даже у щироких,


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

Поточнее можно? Потому что термин "парсить" разбор именно и означает.
Заменить все вхождения символов '\r' '\n' на Сишные '\0'?

Кстати, никсовый перевод \r\n, или наоборот?

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

Разбор ченго? И на основании чего? Мне надо разобрать переменную на строки, а сами строки разбирать на лексемы уже не надо, это парсит сама функция вывода строки. Проблема в том, что на строки она разбирает совсем не так, как надо, а на основании ширины страницы, а с символами перевода строки не дружит вовсе.

А чёрт его знает, похоже на то, что никсовый (бухал 4 года, много забыл).





Давай ещё раз. По самым основам. Строка в Си (С++) завершается на нуль-символе '\0'. Экранное представление это совсем другое, здесь в теме, когда говорят про строку, говорят про Сишную строку с неограниченным числом символов и с произвольной длиной, ограниченной лишь нуль-символом.




Это у кого проблемы? Сколько ни работаю, ещё не встречался. Я тебе работающий код привёл (выжимки из работающего кода).


А тебя это и не должно волновать. У тебя несколько вариантов действий. Заменить ещё в начале работы "\r\n" на "\n" и потом работать с "\n" (раз ты пишешь под Виндой). Либо разбивать сразу по '\n', а '\r' искать потом. С обязательным преобразование, конечно, раз ты юникоидную строку смотришь к WCHAR('\n'). 

Давай ещё раз посмотрим. Чтобы у тебя не возникало проблем с работой со строками string и wstring

Я как-то перекомпилировал две юникоидных библиотеки под VS проекты (не особо много, но по остальным были версии под Винду). Ребята и там уже берут и чтобы не париться с разницей между двумя этими типа строк при перекомпиляции пишут уже не string, не wstring, а tstring, определяя её так

#ifdef _UNICODE
typedef wstring tstring
// прочие обозначения, если надо
typedef wifstream tifstream; 
#else
typedef string tstring
// и здесь аналогично
typedef ifstream tifstream; 
#endif

Потому что в некоторых случаях бывает нужно в коде явно указать, что нужна строка string или wstring, просто строка в кавычках или L"..".
Потому что есть функции или классы, которые работают только с одним видом строк.
И, соответственно, в Виндоус 
И TCHAR() и _T()  будeт зависеть от метода компиляции. А WCHAR или char - уже нет.
Это делает простым и явным код, что если идёт tstring, то безразлично, как строка будет перекомпилирована, в Юникоде или вмультибайте. А если явное указание string или wstring, то кодер желает привлечь внимание, что здесь нужен именно такой вид строки.

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

Это сообщение отредактировал(а) akizelokro - 28.8.2013, 13:25

Это Win перевод строк. В Unix'ах это просто '\n'. (А в Маках кажется '\r')

В Маках там вроде позашибенней что-то придумано.  

Пусть разбирает оба варианта сразу и, когда забудет, чем они там отличаются, то будет получаться переносимый код.
Вообще, вся эта канитель полезла из-за Доса (вспомнил). Потому что они в '\n' умудрились разместитьсразу два символа CRLF. Или LFCR


Это сообщение отредактировал(а) akizelokro - 28.8.2013, 13:38

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

Добавлено @ 09:00
Проблема решена так:  27-я строка ищёт перенос строки, а 31-я ищет начало следующей.

Это сообщение отредактировал(а) ТарасАтавин - 29.8.2013, 09:01

Если у тебя есть строка string x, которая содержит некий текст с разбивкой на строки, то самое простое засунуть ее в stringstream, а затем читать из него с помощью std::getline.
Можно извратиться и сделать тоже самое с помощью strtok.

Нафига мне на пустом месте потоки?

А нафига тебе куча тем в форуме?
Если бы место было простым, ты бы вопросов не задавал. логично?

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

Это сообщение отредактировал(а) ТарасАтавин - 7.9.2013, 10:35

Если вы про переводы строк, то ось не причем.
Достаточно посмотреть CRT, исходники коей официально идут вместе со студией.

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

Ого, ты пишешь такой код, что вызываешь сбои внутри ОС? Желание отлаживать ОС возникает у двух видов людей (разработчики ОС не в счет): новичков, которые не могут признать, что ошибка в их коде; и специалистов по безопасности операционных систем. Ко второму типу ты точно не относишься.