Комментарии 15
Вообще не въезжаю, почему A=B*C с матрицами понятно, а A=B&&C с матрицами непонятно. Если на то пошло, то как раз A=B*C методом перегрузки вызывает вопросы, так как это может быть матричное умножение, а может – поэлементное. А с конъюнкцией что неясно? Такого в языках, допускающих элементарные операции с массивами, в программах полно. Просто конвейеризованная логическая операция.
Конечно, можно криво перегрузить, но это другой вопрос. Умножение тоже можно криво перегрузить.
Как раз операция A=B*C в контексте работы с матрицами должна четко ассоциироваться с матричным умножением. Если человеку кажется иное, то тут вопрос скорее к человеку, чем к коду.
В языках программирования, из коробки допускающих такую запись над матрицами (из которых наиболее широко употребимым на сегодняшний день является Фортран) эта запись чаще всего означает поэлементное умножение. Никакого специального смысла тут нет, это происходит просто из обобщения элементарных операций на аргументы-массивы. Операция или элементарная функция в таком случае вообще не знает, к чему её применяют.
Матричное умножение так записывается обычно в математических пакетах вроде Матлаба.
Так никто не говорит про дефолтную запись. Если идет перегрузка, значит скорее всего есть свой класс Matrix, и оператор *, принимающий в качестве аргументов объекты этого класса. Этого должно хватать, чтобы недвусмысленно интепретировать оператор *. Собственно в Qt так и сделано. Есть класс QMatrix4x4 и перегруженные для него операторы, согласно алгебре матриц.
Опытные товарищи, посоветуйте, как кроссплатформенно работать со строками, с частности, с путями, без собственных оберток над string.
Кросплатформенно невозможно работать с путями, так как сами пути не кроссплатформенны.
Необходимо уточнить задачу.
С типичными современными файловыми системами (FAT, NTFS, EXT...) можно, используя std::filesystem::path, доступный в C++17, о чём тут уже сказали. Вот если нужна работа с древними или нестандартными файловыми системами -- там да, проблематично придумать что-то кроссплатформенное. Но в реальной жизни сейчас такое если и встречается, то крайне редко.
Пишут, что даже в Windows std::filesystem::path не в состоянии правильно разобрать все пути.
Ну и в любом случае несколько популярных примеров не означают кроссплатформенности.
Кроме того, надо специфически обрабатывать семантику, а не только синтаксис. Например, в macOS у консольных программ есть текущий каталог, а у гуёвых нет (точнее, не задействуется при нормальном вызове). И таких фишек много.
Ну, если брать уж совсем общие случаи, то да -- кроссплатформенного решения нет, придётся писать ручками или тащить реализованное кем-то другим для конкретных платформ.
Что же до ссылки на пример неправильного разбора, то, на первый взгляд, проблема в реализации библиотеки, а не в принципиальной невозможности сделать правильный разбор -- т.е. имеет место баг или недоработка, что можно (и нужно) исправить в следующей версии. Но честно скажу, что глянул бегло, не вникая.
Ну и, кроме того, даже если я прав и это баг в библиотеке, всё равно остаётся проблема обеспечения кроссплатформенности здесь и сейчас, а не когда все баги исправят, -- так что, решение может быть теоретически кроссплатформенным, а на практике -- не совсем... В общем, надо исходить из задачи и из реального списка необходимых платформ, а не пытаться сделать решение "сферическое в вакууме".
Конечно. Я как раз именно это и имел в виду – что бессмысленно в данном случае требовать абстрактную “кроссплатформенность”, а надо ставить конкретную задачу, например, “написать программу, которая работает в Windows, Linux и macOS таким-то образом”.
А так-то истинно кроссплатформенно будет написать программу на Фортране и адресоваться к файлам по номерам, рассудив, что стандартная библиотека в каждом случае как-то это разрулит. Только это окажется очень неудобно для пользователя.
Начиная с C++17 есть std::filesystem::path. Если этого не достаточно, то надо или искать подходящую библиотеку или писать самому.
Трудно рекомендовать что-то конкретное, не зная конкретных требований.
По поводу std::string можно было бы добавить про std::string_view. Штука, которая немного повышает читаемость и очень сильно снижает вероятность ошибки при использовании, в сравнении с const std::string&.
А как его использовать? Обычно, протащив string_view через 15 вложенных функций замечаеш, что у 16 функции параметр const std::string&, и приходится конвертировать это в строку, выполняя лишнюю аллокацию памяти и копирование.
Хотя, может на данный момент большинство кода написано со string_view, и этой проблемы больше не возникает, но раньше было именно так
К сожалени, из опыта попыток использования std::string_view, не очень оно и подходит. В большинстве случаев оказывается что либо чего-то не хватает (например конкатенации двух sv) без предварительной конвертации в std::string, либо в какой-то очередной API надо передать именно string. Единственное где sv сейчас применять удобно, это всякого рода парсинг, когда можно сделать remove_prefix() и/или remove_suffix() без реаллокации.
60 антипаттернов для С++ программиста, часть 10 (совет 46 — 50)