Вообще, тут как будто четвёртое состояние всё же нужно: когда x и y несравнимы. Конечно, конкретно классического сравнения это касается слабо, но всё же сравнивать nan с чем-то — по версии ieee754 дело такое себе.
Да и если считать, что "меньше" это некое иррефлекивное асимметричное транзитивное соотношение, "равно"… короче пропустим, эти малопонятные слова. Например, из похожего, операция стогого подмножества в качестве "меньше" и равенства множеств в качестве "равно", ну и т.д., то как бы не верно {1}⪋{2, 3}. Спекуляция, конечно, но для чего-то вроде перегрузки операторов чутка неудобно кажется. Впрочем, тогда уж, считая, что nan!=nan… странно всё это. Сойдёмся на том, что это пустое рассуждение.
Ну и сверху уже писали, но я повторюсь: метрика эффективности взята с воздуха. Тут уж лучше глянуть с точки зрения хранения или как-то ещё, но не пальцем в небо.
что насчёт оператора "->*", кстати? Я глянул: его можно спокойно вне класса перегрузить. И по общей логике подходит. Единственное, не превращать его использование в то, что в первой строчке, ибо приоритет у него чуть ниже, чем у "()", что не совсем интуитивно:
(obj_ptr ->* ptr) (param) //реальность использования указателей на метод
obj ->* extention(param) //ожидание или если писать как конвеер
Их относительно легко использовать, особенно если использовать литералы.
Ну, тут немного моей личной фантазии, но если бы в c++ были бы shared immutable-строки как во многих языках на уровне хотя бы библиотеки, это было бы довольно хорошим решением, ибо можно было бы на constexpr-уровне сделать что-то вроде ""sv, но с возможностью конкатенации и другими плюшками.
Ну а так, лучше всего всегда писать ""sv тли ""s по ситуации. Но вообще, проблема первого в том, что операции конкатенауии и подобного недоступны, а воорого в том, что он всегда аллоцирующий.
Можно, конечно, написать нечто вроде ""s + "..."sv + some_fun(), но это не совсем то.
необходимость передачи .begin()/.end() в большинстве случаев.
std::ranges::find_if(vec, ...)
и другие функции в std::ranges:: хедера <algorithm> решают эту проблему.
Но вот про extension methods согласен частично, ибо возможность сломать что-либо всё же присутствует, хотя это можно решить через добавление в стандарт чего-то вроде using-ов по типу того, как это происходит со строковыми и числовыми литералами. Тут мне нравится предложенное кем-то использование через оператор ".*", но странно, что его так и не приняли в стандарт. Ну, если писать свою библиотеку, то можно попробовать перегрузить оператор "->*" в качестве замены (всё равно по назначению его никто не перегружает), но проблему уже имеющегося кода это не решит.
Про модули и requires уже написали, так что распинаться не буду.
Язык должен быть красивым, певучим, типа испанского. Это не должно быть как в немецком или японском языке, когда признание в любви звучит как речь Гитлера с призывом резать евреев, русских и т.д.
Не очень разбираюсь, но как по мне, японский звучит вполне мелодично. Чтобы чутка уменьшить субъективный фактор, в японском все слоги кроме "н" открытые, что идёт ему сильно на пользу в этом плане. Подправьте меня.
И если подход к изучению информатики не изменится кардинально, то на первых курсах технических ВУЗов преподавателям скоро придётся учить фактически с нуля
Вообще, я не из России, а из Беларуси, но в общем-то у нас в ВУЗе как раз с нуля и учили (плюсам). До этого я учился в лицее, пусть и не специализированном, могу сказать, что тому, чему нас учили (паскаль), вообще в мозг не въедается как-то, да и зачем нам там нужны были всякие задачи на создание каких-то ходящих человечков и рисование (на паскале), я без понятия.
А так, что насчёт преподаваемого языка использовать C++? Его сишная часть как раз была нацелена на структурное программирование, что прекрасно подойдёт для объяснения всяких базовых концепций по типу циклов, а плюсплюсная часть для обучения будет хороша в плане опускания всякой устаревшей сишной лабуды, тем самым позволяя глубоко не углубляться.
Понимаю, что, возможно, есть языки, не делящиеся вот так вот чуть ли не на два мира, но всё равно хотелось бы узнать мнение по поводу плюсов как языка школьного обучения.
Если что, сразу уточню, что понимаю существование всяких golang и подобного, которые будут немного "чище" плюсов, но всё же.
В последнее время люблю читать про всякие интересные структуры данных...
Я тут подумал: если смотреть с точки зрения ЯПов, а не баз данных, то у такого способа балансировки будет небольшой недостаток в виде того, что она нестабильная (перемещает данные из одного участка памяти в другой).
А так, про кеше-дружелюную реализацию списка уже читал, а вот и аналог для дерева, классно))
Вообще, тут как будто четвёртое состояние всё же нужно: когда x и y несравнимы. Конечно, конкретно классического сравнения это касается слабо, но всё же сравнивать nan с чем-то — по версии ieee754 дело такое себе.
Да и если считать, что "меньше" это некое иррефлекивное асимметричное транзитивное соотношение, "равно"… короче пропустим, эти малопонятные слова. Например, из похожего, операция стогого подмножества в качестве "меньше" и равенства множеств в качестве "равно", ну и т.д., то как бы не верно {1}⪋{2, 3}. Спекуляция, конечно, но для чего-то вроде перегрузки операторов чутка неудобно кажется. Впрочем, тогда уж, считая, что nan!=nan… странно всё это. Сойдёмся на том, что это пустое рассуждение.
Ну и сверху уже писали, но я повторюсь: метрика эффективности взята с воздуха. Тут уж лучше глянуть с точки зрения хранения или как-то ещё, но не пальцем в небо.
что насчёт оператора "->*", кстати? Я глянул: его можно спокойно вне класса перегрузить. И по общей логике подходит. Единственное, не превращать его использование в то, что в первой строчке, ибо приоритет у него чуть ниже, чем у "()", что не совсем интуитивно:
Не знаю, о чём думали создатели стандарта
От человека, только учащегося создавать проекты — спасибо за статью. :)
Про doxygen — узнал впервые, и хорошо, что на раннем этапе). И за это отдельное спасибо.
нет, невозможно
откуда такое предположение?;)
Если честно, уровень абстракции растёт очень быстро. Общая суть понятна, но детали без достаточного опыта работы с подобным лишь взрывают мозг.
Странно, что U с -1 начинаются, конечно, какой-то dreamberd.) Это из-за изначально неудачно подобранного соглашения?
И ещё интересно, но уже просто для улучшения понимания:
Возьмём такой псевдокод на C++:
Это ведь S: (*–>*)–> * , верно? Ну, то есть "(*–>*)–> *" — это род S, да?
А если так, то для:
Род S это T –> *, верно?
Ещё из вопросов: можно пример "родов родов" , ибо что-то принадлежащее, если я правильно понимаю, U_2 или выше не знаю как представить. Типа такого:
, где "суперрод" у T это uint -> хз, где хз это не-generic суперрод?
Тяжело такое представлять, как и задачи, где подобное можно применить практически.
Ну, тут немного моей личной фантазии, но если бы в c++ были бы shared immutable-строки как во многих языках на уровне хотя бы библиотеки, это было бы довольно хорошим решением, ибо можно было бы на constexpr-уровне сделать что-то вроде ""sv, но с возможностью конкатенации и другими плюшками.
Ну а так, лучше всего всегда писать ""sv тли ""s по ситуации. Но вообще, проблема первого в том, что операции конкатенауии и подобного недоступны, а воорого в том, что он всегда аллоцирующий.
Можно, конечно, написать нечто вроде ""s + "..."sv + some_fun(), но это не совсем то.
Ну или, к примеру, условно:
Не откомпилируется
std::ranges::find_if(vec, ...)
и другие функции в std::ranges:: хедера <algorithm> решают эту проблему.
Но вот про extension methods согласен частично, ибо возможность сломать что-либо всё же присутствует, хотя это можно решить через добавление в стандарт чего-то вроде using-ов по типу того, как это происходит со строковыми и числовыми литералами. Тут мне нравится предложенное кем-то использование через оператор ".*", но странно, что его так и не приняли в стандарт. Ну, если писать свою библиотеку, то можно попробовать перегрузить оператор "->*" в качестве замены (
всё равно по назначению его никто не перегружает), но проблему уже имеющегося кода это не решит.Про модули и requires уже написали, так что распинаться не буду.
Не очень разбираюсь, но как по мне, японский звучит вполне мелодично. Чтобы чутка уменьшить субъективный фактор, в японском все слоги кроме "н" открытые, что идёт ему сильно на пользу в этом плане. Подправьте меня.
Вообще, я не из России, а из Беларуси, но в общем-то у нас в ВУЗе как раз с нуля и учили (плюсам). До этого я учился в лицее, пусть и не специализированном, могу сказать, что тому, чему нас учили (паскаль), вообще в мозг не въедается как-то, да и зачем нам там нужны были всякие задачи на создание каких-то ходящих человечков и рисование (на паскале), я без понятия.
А так, что насчёт преподаваемого языка использовать C++? Его сишная часть как раз была нацелена на структурное программирование, что прекрасно подойдёт для объяснения всяких базовых концепций по типу циклов, а плюсплюсная часть для обучения будет хороша в плане опускания всякой устаревшей сишной лабуды, тем самым позволяя глубоко не углубляться.
Понимаю, что, возможно, есть языки, не делящиеся вот так вот чуть ли не на два мира, но всё равно хотелось бы узнать мнение по поводу плюсов как языка школьного обучения.
Если что, сразу уточню, что понимаю существование всяких golang и подобного, которые будут немного "чище" плюсов, но всё же.
Можно вопрос? Зачем нужен digits.as_str, если он нигде не используется?
В последнее время люблю читать про всякие интересные структуры данных...
Я тут подумал: если смотреть с точки зрения ЯПов, а не баз данных, то у такого способа балансировки будет небольшой недостаток в виде того, что она нестабильная (перемещает данные из одного участка памяти в другой).
А так, про кеше-дружелюную реализацию списка уже читал, а вот и аналог для дерева, классно))
Предполагаю, это потому что возможно изначально это задумывали как сокращение для чего-то такого:
А потом оно обросло... гипотеза, если что, но правдоподобная.