Igors, это ты? :)

[_Bers]

И часто вы можете от итератора позвать std::begin? Или всё таки от контейнера? а от dir iteratora - можете (чтобы работал for_range). for по итератору! Причем достаточно было бы поменять название.

не часто.

error: ‘class boost::filesystem::directory_iterator’ has no member named ‘begin’

а вот идея "итерируйся пока валиден" - очень даже правильная.
применяется повсеместно везде, кроме стандартных итераторов std

Угу, и это превращается в код вида

Код:

#ifdef Q_OS_WIN
label->setText(QString::fromStdWString(path.wstring()));
#else
label->setText(QString::fromStdString(path.string()));
#endif

а кто вам запрещал юзать всегда std::string? или всегда std::wstring?

ваш label->setText это не поддерживает?

бывает. только fs тут причем?

Удобно. Логично. То есть даже тот факт, что WString никто не исользует просто потому, что он непереносим между платформами, их ничему не научил.

это - не факт.
потому что его юзают, и ещё как.
под виндой юзают на полную катушку.
потому что там юникод во все поля.

только fs то тут причем? она заставляет вас юзать std::wstring?

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

другие разработчики вынудили вас написать это:

#ifdef Q_OS_WIN

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

Upd: вот это тоже прекрасно

Otherwise, if path::value_type is wchar_t, conversion, if any, is unspecified. This is the case on Windows, where wchar_t is 16 bit and the native encoding is UTF-16.
Otherwise, if path::value_type is char16_t, native encoding is UTF-16 and the conversion method is unspecified.
Otherwise, if path::value_type is char32_t, native encoding is UTF-32 and the conversion method is unspecified.

а ещё, порядок вычисления аргументов функции есть unspecified
у вас какая то проблема?

может быть аргументы плохо вычисляются?
или conversion method как то плохо работает на какой то конкретной платформе?

[_Bers]

Ну хорошо, вот я открыл упомянутую либу и взял наугад шматок с boost::filesystem.

Код:

		boost::filesystem::path p( soundCacheDir );
#if (BOOST_VERSION > 104400)
		boost::filesystem::path abs_p = boost::filesystem::absolute( p );
#else
		boost::filesystem::path abs_p = boost::filesystem::complete( p );
#endif

//            char full[ _MAX_PATH ];
//            if ( _fullpath( full, "..\\..\\..\\..\\..", _MAX_PATH ) != NULL )
#if (BOOST_VERSION > 104400)
        if ( boost::filesystem::exists( abs_p ) )
#else
        if ( boost::filesystem2::exists( abs_p ) )
#endif
        {
            //soundFile = string( full ) + string( "/" ) + soundFile;
			p  /= soundFile;
            soundFile = abs_p.string() + string("/") + soundFile;
        }

Чехарда с версиями - и править код сторонней либы как-то не тянет.

зачем его править? у вас что-то не работает?

И оказывается есть filesystem и filesystem2 - какую читать?

впервые слышу про filesystem2
гугл кстати, тоже ничего о ней не знает.

Оператор /=, ну наверное добавляет путь, хз.

вот видите как все интуитивно.

мне вот любопытно, а что ещё мог бы делать слэш в файловых путях?

Быстренько в этом убедиться (просто открыв букварь) не получится, не та система.

то есть, написать:

Код:

fs::path p = fs::current_path()/"..";

это что-то запредельно сложное?
http://rextester.com/QYP64737

И предположение что используется правый слеш - значит кто-то должен заботиться о нативных вызовах злосчастного Вындоуз.

ээээ... не распарсил этот поток сознания. винде вообще пофигу: правый/левый.
причем тут fs?

Что же тут "такого уж хорошего"? Разве это интуитивно? Или может это как-то компенсируется "глубиной концепций"? По-моему вовсе нет, особенно если сравнить с QDir и QFileInfo - вот удобные классы для людей, а не так. операторы задрочить.

я покамест не увидел примеров не интуитивности.
QDir и QFileInfo - те же яйца.
в чем принципиальное отличие?

[Авварон]

а кто вам запрещал юзать всегда std::string? или всегда std::wstring?

ваш label->setText это не поддерживает?

бывает. только fs тут причем?

Всегда std::string мешает юзать то, что conversion uncpecified.
Всегда std::wstring мешает юзать то, что на линуксе он 4 байта, а не 2 как на венде.
Проблемки-с.

[Igors]

я покамест не увидел примеров не интуитивности.
QDir и QFileInfo - те же яйца.
в чем принципиальное отличие?

Да я собсно ничего доказывать не собирался, Вы спросили чем мне boost::filesystem не приглянулся - я ответил. Насчет Qt реализации - ну поприятнее и побогаче, напр задать фильтры так и сяк и забрать контейнер, а не тюкать по одному тем итератором..

Принципиальной разницы - разумеется никакой, НО опять-таки: мне не нравится сам подход. Ну вот ЗАЧЕМ мне "асиливать" тот или иной std класс ? Просто так, "повышать повышаемость"?  У любого использующего Qt эта потребность давным-давно закрыта. Ах, вот если надо будет сделать консольное приложение.. ну вот тогда этот класс и открою, а так "на всякий случай" есть бездарное разбазаривание  интеллектуальных ресурсов.

[_Bers]

Всегда std::string мешает юзать то, что conversion uncpecified.

каким именно образом conversion uncpecified мешает вам юзать std::string?
приведите пример.

Всегда std::wstring мешает юзать то, что на линуксе он 4 байта, а не 2 как на венде.
Проблемки-с.

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

сейчас ваши тезисы со стороны выглядят так:

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

[_Bers]

Да я собсно ничего доказывать не собирался,

я не просил никаких доказательств. я спросил: что именно не удобно? приведите пример неинтуитивности, или и неудобств?

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

Вы спросили чем мне boost::filesystem не приглянулся - я ответил.

но вы же вообще не привели никакой конкретики.
не очевидно: что именно не так?

Насчет Qt реализации - ну поприятнее и побогаче, напр задать фильтры так и сяк и забрать контейнер, а не тюкать по одному тем итератором..

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

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

где сама по себе идея: "перебрать файлы" - и есть по сути работа с итератором.

Ну вот ЗАЧЕМ мне "асиливать" тот или иной std класс ?

с таким же успехом, этот вопрос можно задать в отношении любой технологии.
например: "ну вот зачем мне осиливать классы Qt?"

ответ прост и очевиден: осиливать Qt придется, если хочется состояться,
как программист Qt.

осиливать std придется, если хочется состояться,
как программист с++

У любого использующего Qt эта потребность давным-давно закрыта. Ах, вот если надо будет сделать консольное приложение.. ну вот тогда этот класс и открою, а так "на всякий случай" есть бездарное разбазаривание  интеллектуальных ресурсов.

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

например, нужно по быстрому создать независимый (детачнутый) тред.

Код:

std::thread(threadFunction).detach();

в случае с qt всегда нужно помнить о нюансах: система кютешных сообщений.
которые по итогу выливаются в подобную хрень:
https://toster.ru/q/289471
https://habr.com/post/202312/
http://rsdn.org/forum/cpp.qt/6946232.all

куча кода ради кода, только за ради поддержания куютешной архитектуры.

[Авварон]

каким именно образом conversion uncpecified мешает вам юзать std::string?
приведите пример.

Я, может быть, неправильно читаю документацию, но это значит, что конвертации UTF16 -> UTF8 (std::string) на венде нет. Может вам сделают её, а может и нет. А может это будет cp1251 или любая другая local8bit. То есть надо ЯВНО указать, как конвертировать (QString::fromWChar(path.wstring()).toUtf8()).

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

сейчас ваши тезисы со стороны выглядят так:

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

При  том, что wchar_t на венде - это UTF16, а та же самая строка на линуксе - это UTF32 и с ними вообще всё по разному (int, во-первых, в реальности везде 32бита, а во вторых, над ним определены операции, дающие определенный результат (пока нет переполнения)). А в случае wchar_t даже простая итерация различается из-за размера (с учетом суррогатной пары или без))

[Igors]

осиливать std придется, если хочется состояться,
как программист с++

Не разделяю этого мнения (к сожалению, популярного). Бездумное пожирание std ничего не дает ни уму ни сердцу, зато изрядно калечит молодых ребят.

или потому что std во многих случаях тупо удобнее, чем решения Qt.

например, нужно по быстрому создать независимый (детачнутый) тред.

Код:

std::thread(threadFunction).detach();

в случае с qt всегда нужно помнить о нюансах: система кютешных сообщений.
которые по итогу выливаются в подобную хрень:
https://toster.ru/q/289471
https://habr.com/post/202312/
http://rsdn.org/forum/cpp.qt/6946232.all

куча кода ради кода, только за ради поддержания куютешной архитектуры.

Может я чего-то не понял, поясните зачем такое чудо (независимая нитка) нужно? Не вижу как это связано с линками ниже. И что плохого в Qt сообщениях? По-моему только хорошее. Пример

- сделать 2 нитки, одна принимает символ с клавы, другая печатает

Сделать это пуляя Qt сигналами - не вопрос, а вот на std - придется изрядно попыхтеть. Конечно std::thread - это хорошо, избавляет от походов в нативняк всякий раз когда нет фреймворка. Но упиваться std решениями опрометчиво, стандартная библиотека и не должна быть "лучшей", она всего лишь должна "обеспечивать достойную конкуренцию".

[_Bers]

Я, может быть, неправильно читаю документацию, но это значит, что конвертации UTF16 -> UTF8 (std::string) на венде нет. Может вам сделают её, а может и нет. А может это будет cp1251 или любая другая local8bit. То есть надо ЯВНО указать, как конвертировать (QString::fromWChar(path.wstring()).toUtf8()).

вы не правильно понимаете понятие "uncpecified".
в плюсах есть два понятия: "undefined behavior" и "uncpecified behavior"
первое означает: "поведение не определенно, но все плохо".
второе - "поведение не определено, но все хорошо".

вам не нужно думать,
как именно fs выполнит преобразования для std::string на конкретной платформе.
раз оно "uncpecified", значит каким бы оно ни было - все будет хорошо.

конвертации UTF16 -> UTF8 (std::string) на венде нет

uppsss...
std::filesystem::path::generic_u8string


вы вообще документацию смотрели?
я ж не зря выше писал: к вашим услугам целая пачка функций-конвертеров.

хотите UTF16?
о боже!
std::filesystem::path::generic_u16string

или может быть UTF32? ну вы понэли.

При  том, что wchar_t на венде - это UTF16, а та же самая строка на линуксе - это UTF32 и с ними вообще всё по разному

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

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

и почему я каждый раз вынужден задавать вам один и тот же вопрос: "почему вы так думаете? приведите пример"
вы в состоянии сразу аргументировать свои тезисы?

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

по-первых, в реальности int реально плавающий.
а во вторых, для basic_string<char_type> определены операции, дающие определенный результат

случае wchar_t даже простая итерация различается из-за размера (с учетом суррогатной пары или без))

это что за бред?
пример "различий" вы конечно привести не в состоянии.

[_Bers]

Может я чего-то не понял, поясните зачем такое чудо (независимая нитка) нужно?

зачем вообщще нужны нитки вы в курсе?
чем более они независимые в контексте решаемой задачи - тем лучше.
это как бе азбука "фри-лок" алгоритмов.

Не вижу как это связано с линками ниже.

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

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

И что плохого в Qt сообщениях?

тормозные. неудобные. не интуитивные.

Пример

- сделать 2 нитки, одна принимает символ с клавы, другая печатает

Сделать это пуляя Qt сигналами - не вопрос, а вот на std - придется изрядно попыхтеть.

попыхтеть?

Код:

std::thread(processKeyboard).detach();
std::thread(processPrinter).detach();

это конечно неиллюзорно трудно!

Конечно std::thread - это хорошо, избавляет от походов в нативняк всякий раз когда нет фреймворка. Но упиваться std решениями опрометчиво, стандартная библиотека и не должна быть "лучшей", она всего лишь должна "обеспечивать достойную конкуренцию".

эт что за лозунги?
стандартная бибилотека отвечает требованиям: портируемость, эффективность (сочетание быстродействия и экономичности), универсальность.

кутешный тред - прожорливая скатина.
стандартный - тупо оч тонкая обертка над системным апи.

[Авварон]

это что за бред?
пример "различий" вы конечно привести не в состоянии.

Очень удобно называть аргументы бредом:)

Я, если честно, так и не понял, чем generic отличается от native. До того, как вы о нем сказали, я даже не знал. Вот я читаю документацию и вижу копипасту с заменой native/generic. И чо?

[Авварон]

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

Не нужно. До какой-то версии QThread::run был вообще pure virtual.

[_Bers]

Очень удобно называть аргументы бредом:)

бред - неадекватное, не соответствующее реальности представление, рассуждение, или вывод

ваши "аргументы" - это бред,
потому что итерация по wstring абсолюбтно точно такая же,
как итерация по string,
или итерация по какому нибудь basic_string<custom_type>

привести пример различий итераций для string и wstring вы не сможете.
потому что их не существует.

Я, если честно, так и не понял, чем generic отличается от native. До того, как вы о нем сказали, я даже не знал. Вот я читаю документацию и вижу копипасту с заменой native/generic. И чо?

и то, вы как то странно смотрите.

нет там никакой копипасты.
есть кучка конвертеров,  и один единственный метод 'native'

[_Bers]

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

Не нужно. До какой-то версии QThread::run был вообще pure virtual.

приведите пример "не нужности"
я сам помниццо, наступил на эти грабли, и пинал вручную евент-луп.

[Авварон]

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

Не нужно. До какой-то версии QThread::run был вообще pure virtual.

приведите пример "не нужности"
я сам помниццо, наступил на эти грабли, и пинал вручную евент-луп.

1. http://doc.qt.io/qt-5/qthread.html#create
2. берете и переопреляете run() и не нужен никакой эвентлуп из 7 залуп