Igors, это ты? :)

[Alex Custov]

https://www.linux.org.ru/forum/development/13158009?lastmod=1484810731834

Есть проект. Почти весь написан на C++, GUI + очень малая часть функционала написана на C#. Целевая платформа: оффтопик.

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

Я никак не могу, зачем он это делает (NIH?), и стараюсь убедить его, что мол есть же Boost.Filesystem, юзай его. Ответ таков: Boost тяжёлый, тянуть не хочется да и вообще лень. А вот мои костыли это просто лучшее решение. И это после того, как я регулярно в его костылях правлю баги какие-нибудь.

И это касается не только Filesystem. Он ещё своё жалкое подобие lexical_cast впихнул и много чего ещё...

[Igors]

Нет, не я. Мое знакомство с бустом началось когда один из контракторов сказал что нужна boost::polygon. Я подумал и разрешил - оказалось очень к месту. В прошлом году работал с либой где использовалась boost::filesystem. Не могу сказать что в восторге - не очень интуитивный сынтаксыс, приходилось гуглить. Но запрещать я бы не стал. Вот собсно и весь мой бустовский багаж. А вообще open-sources приходится привлекать довольно часто, 3-4 раза в год, но вот буста в них почему-то нет (std практически тоже). Ну может скоро придется собирать "alembic", там вроде много, вот и потренируюсь.

И вот там тимлид сидит и пишет свои костыли для работы с файловой системой: итерация по директории, удаление файла и т.д.

Не думаю что здесь много фанатов boost::filesystem. Наверное потому что и с QDir все очень неплохо

И это касается не только Filesystem. Он ещё своё жалкое подобие lexical_cast впихнул и много чего ещё...
Откуда такая может быть ненависть к Boost? И как с этим можно бороться?

Тут ясно видна "ненависть к великам", видимо человек затратил много сил на постижение бустовских премудростей, теперь считает их "единственно правильными" и пытается их навязывать другим - это в любом случае нехорошо, да и толку не будет. По-человечески я конечно понимаю - "разобрался", "дошло", хочется поделиться - это нормально. Только вот какую часть проекта покроют эти разборки? У меня - ну точно не скажу, где-то порядка 1% (может быть)

[Racheengel]

Либо тимлид понимает, что он как тимлид некомпетентен и таким образом старается повысить свою значимость на проекте.

[Авварон]

Не думаю что здесь много фанатов boost::filesystem. Наверное потому что и с QDir все очень неплохо

Беда в том, что дуст::файлсистем в стандарт запихнули:(

[_Bers]

Нет, не я. Мое знакомство с бустом началось когда один из контракторов сказал что нужна boost::polygon. Я подумал и разрешил - оказалось очень к месту. В прошлом году работал с либой где использовалась boost::filesystem. Не могу сказать что в восторге - не очень интуитивный сынтаксыс, приходилось гуглить. Но запрещать я бы не стал. Вот собсно и весь мой бустовский багаж. А вообще open-sources приходится привлекать довольно часто, 3-4 раза в год, но вот буста в них почему-то нет (std практически тоже). Ну может скоро придется собирать "alembic", там вроде много, вот и потренируюсь.

И вот там тимлид сидит и пишет свои костыли для работы с файловой системой: итерация по директории, удаление файла и т.д.

Не думаю что здесь много фанатов boost::filesystem. Наверное потому что и с QDir все очень неплохо

И это касается не только Filesystem. Он ещё своё жалкое подобие lexical_cast впихнул и много чего ещё...
Откуда такая может быть ненависть к Boost? И как с этим можно бороться?

Тут ясно видна "ненависть к великам", видимо человек затратил много сил на постижение бустовских премудростей, теперь считает их "единственно правильными" и пытается их навязывать другим - это в любом случае нехорошо, да и толку не будет. По-человечески я конечно понимаю - "разобрался", "дошло", хочется поделиться - это нормально. Только вот какую часть проекта покроют эти разборки? У меня - ну точно не скажу, где-то порядка 1% (может быть)

а что именно в std::filesystem не интуитивно понятно?

[Авварон]

Нет, не я. Мое знакомство с бустом началось когда один из контракторов сказал что нужна boost::polygon. Я подумал и разрешил - оказалось очень к месту. В прошлом году работал с либой где использовалась boost::filesystem. Не могу сказать что в восторге - не очень интуитивный сынтаксыс, приходилось гуглить. Но запрещать я бы не стал. Вот собсно и весь мой бустовский багаж. А вообще open-sources приходится привлекать довольно часто, 3-4 раза в год, но вот буста в них почему-то нет (std практически тоже). Ну может скоро придется собирать "alembic", там вроде много, вот и потренируюсь.

И вот там тимлид сидит и пишет свои костыли для работы с файловой системой: итерация по директории, удаление файла и т.д.

Не думаю что здесь много фанатов boost::filesystem. Наверное потому что и с QDir все очень неплохо

И это касается не только Filesystem. Он ещё своё жалкое подобие lexical_cast впихнул и много чего ещё...
Откуда такая может быть ненависть к Boost? И как с этим можно бороться?

Тут ясно видна "ненависть к великам", видимо человек затратил много сил на постижение бустовских премудростей, теперь считает их "единственно правильными" и пытается их навязывать другим - это в любом случае нехорошо, да и толку не будет. По-человечески я конечно понимаю - "разобрался", "дошло", хочется поделиться - это нормально. Только вот какую часть проекта покроют эти разборки? У меня - ну точно не скажу, где-то порядка 1% (может быть)

а что именно в std::filesystem не интуитивно понятно?

directory_iterator который сам себе и итератор и контейнер по которому итерируется.
path который string на 1й системе и wstring на другой. прям взяли книжку "как не надо писать на плюсах" и написали

[Igors]

а что именно в std::filesystem не интуитивно понятно?

Ну вот зачем так тупо цитировать (пусть даже мои посты  )?

Я и не подозревал о существовании std::filesystem и узнал о нем только сегодня, из Вашего вопроса. Поэтому что там (не)интуитивно - сказать не могу. Но смущает сам подход - да мало ли чего где "есть", так что, бросаться учить всякую новую "фишку"? Ну это если проектом не сильно загружен и есть время лазить там и сям.

[_Bers]

а что именно в std::filesystem не интуитивно понятно?

Ну вот зачем так тупо цитировать (пусть даже мои посты  )?

Я и не подозревал о существовании std::filesystem и узнал о нем только сегодня, из Вашего вопроса. Поэтому что там (не)интуитивно - сказать не могу. Но смущает сам подход - да мало ли чего где "есть", так что, бросаться учить всякую новую "фишку"? Ну это если проектом не сильно загружен и есть время лазить там и сям.

речь не о том, нужно ли что учить или нет.
выше вы писали:

использовалась boost::filesystem. Не могу сказать что в восторге - не очень интуитивный сынтаксыс, приходилось гуглить

что именно не интуитивно понятно?

fs очень маленькая.
содержит только типичный набор функциональности.
просто любопытно, что там может быть не понятным?

[_Bers]

directory_iterator который сам себе и итератор и контейнер по которому итерируется.

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

а вот фраза: "сам себе и итератор и контейнер по которому итерируется" - смахивает на какой то бред.

path который string на 1й системе и wstring на другой. прям взяли книжку "как не надо писать на плюсах" и написали

path - платформо-зависимое явление.
очевидно жеж, что в зависимости от платформы он может быть utf-8, utf-16, ansi, etc.

к тому же, совершенно не принципиально, как именно хранит path свои буковки
принципиально, что у пользователя в распоряжении кучка методов,
которые позволяют извлечь path явно, как std::string, std::wstring, как utf-8, etc

это удобно, и логично.

и причем тут книжка "как не надо писать на плюсах"?

[Авварон]

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

а вот фраза: "сам себе и итератор и контейнер по которому итерируется" - смахивает на какой то бред.

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

path - платформо-зависимое явление.
очевидно жеж, что в зависимости от платформы он может быть utf-8, utf-16, ansi, etc.

к тому же, совершенно не принципиально, как именно хранит path свои буковки
принципиально, что у пользователя в распоряжении кучка методов,
которые позволяют извлечь path явно, как std::string, std::wstring, как utf-8, etc

это удобно, и логично.

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

Код:

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

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

и причем тут книжка "как не надо писать на плюсах"?

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

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.

[Igors]

речь не о том, нужно ли что учить или нет.
выше вы писали:

использовалась boost::filesystem. Не могу сказать что в восторге - не очень интуитивный сынтаксыс, приходилось гуглить

что именно не интуитивно понятно?

fs очень маленькая.
содержит только типичный набор функциональности.
просто любопытно, что там может быть не понятным?

Ну хорошо, вот я открыл упомянутую либу и взял наугад шматок с 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 - какую читать? Оператор /=, ну наверное добавляет путь, хз. Быстренько в этом убедиться (просто открыв букварь) не получится, не та система. И предположение что используется правый слеш - значит кто-то должен заботиться о нативных вызовах злосчастного Вындоуз.

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

[Авварон]

Igors

Очевидно, что в std::filesystem чехарды с версиями нет, а / платформозависимый.

[Racheengel]

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

[Igors]

Очевидно, что в std::filesystem чехарды с версиями нет, а / платформозависимый.

Зато есть словечко "experimental" быстро охлаждающее энтузиазм 

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

Не, ну идеи/задумки там конечно интересные, но елы-палы, как "неласково" Чем-то быстро попользоваться (попастись) практически нереально.  Надо вникать в концепции, потом где-то изыскивать примеры, потренироваться, ну и вот тогда.. (может быть)... Но обычно дело-то этого не стоит. Ну та же filesystem - да нафиг мне надо во что-то там "вникать", мне надо удобно выдрать список файлов каталога, и чем быстрее я это решу - тем лучше.

[Авварон]

Зато есть словечко "experimental" быстро охлаждающее энтузиазм 

Макопролемы, на венде и линуксе уже есть полная поддержка с++17 без experimental::.

Просто яблоко забыло новые (с++17) хедера положить, проблема известная.