Из-за того, что у меня нет опыта написания статей, многого не расскажу, но наверное посоветую делать небольшие напоминания в тексте, что есть что. Просто если информации много (а тут так), то отдельные функции и определения легко забыть, а возвращаться по тексту не хочется.
Возможно, опытный редактор подсказал бы получше и побольше полезных советов, но я не один из них, поэтому могу лишь как читатель говорить что-то, к сожалению.
Вообще, как будто интересно… Я глянул предложение о рефлексии и мне интересно немного: почему функции std::meta решили сделать отдельными функциями, а не методами std::meta::info? Хотя, учитывая, что в плюсах у базовых типов впринципе иное поведение, чем у производных, а данный как будто сделали таковым, чтобы разные компиляторы могли считать его таковым… Иначе, не знаю как-то, странное дизайнерское решение, мне кажется.
Насчёт байта: пусть эксперименты с размером это и хорошо, но слова "байт = 8 бит" так у всех в голове укоренились, что мало кто бы стал писать исходя из обратного. Хотя, возможно, я не знаю какие-то нишевые области? Ну, многие языки уже приняли данное высказывание как стандарт, в любом случае. Отчасти к сожалению, ибо стандартизация чего-то это как отрезать ноги (взамен на то, чтобы вас не догнали с плохими намерениями)) ).
Про контракты: такое как будто лучше работает только если изначально является фишкой языка. Иначе получится как с добавлением добавлением nullability в C#. Или штук вроде @NotNull в java — такой пример точнее. Вроде и окей, но как по мне не на уровне всего языка с принуждением вручную ставить if и отслеживанием локально допустимых значений такое будет так себе, лишь пускаться исключениями или абортами. Но тут уж без отдельного диалекта никак, наверное, как в том странном предложении о safe-c++ (сейчас не найду его, но где-то на хабре есть). Кстати, такое вроде какие-то языки реализовывали как свои "кор-механики", можете напомнить, какие? red: немного погуглив, нашёл лишь spark. В остальном, эта идея какая-то малоиспользуемая, хах. В любом случае, оставить нечто в декларации это хорошо, но, довериться лишь на то, что программист, статический анализ (тут у него возможностей мало), тестирование и т.д. что-то там заметит — это не то, чтобы полноценно. Или же поясните, как это должно работать?
constexpr не особо часто приходится использовать, поэтому многие особенности всё же не помню, да и вспомнить всё же как будто проще будет лишь в момент необходимости:)
К сожалению, маркер constexpr как обещание не очень работает: вполне себе можно функцию, никак не работающую в comp-time, пометить constexpr, с точки зрения стандарта это вроде нормально, но точно я не помню. Это сделано для тех случаев, когда при одних вводных, функция работает в constexpr-"режиме", а при других в рантайме.
Возможно, это разрешимо с помощью consteval, но уже не помню. Типа такого:
Вообще, тут как будто четвёртое состояние всё же нужно: когда 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 и подобного, которые будут немного "чище" плюсов, но всё же.
В последнее время люблю читать про всякие интересные структуры данных...
Я тут подумал: если смотреть с точки зрения ЯПов, а не баз данных, то у такого способа балансировки будет небольшой недостаток в виде того, что она нестабильная (перемещает данные из одного участка памяти в другой).
А так, про кеше-дружелюную реализацию списка уже читал, а вот и аналог для дерева, классно))
если не против компиляторозависимости, то есть специальные #pragma под такое, вроде
Проблема ИИ в том, что его результаты могут быть намного менее детерминированы по сравнению с кодом.
Из-за того, что у меня нет опыта написания статей, многого не расскажу, но наверное посоветую делать небольшие напоминания в тексте, что есть что. Просто если информации много (а тут так), то отдельные функции и определения легко забыть, а возвращаться по тексту не хочется.
Возможно, опытный редактор подсказал бы получше и побольше полезных советов, но я не один из них, поэтому могу лишь как читатель говорить что-то, к сожалению.
Вот из F# пример, как там работает:
Но там как бы удобно, что есть оператор <|, который работает навроде обычной передачи в функцию, но с меньшим приоритетом самого оператора.
Я немного перегнул, но всё же думаю, что тут чем раньше, тем лучше. Но тут как будто впринципе всё лучше заранее планировать.
Как бы это сказать помягче…
Из фундаментальных предпосылок, было создано нечто весьма затруднительное для понимания. Я как-то потерял нить. Извиняюсь.
Могу ли я попросить прожёвывать чуть побольше, пожалуйста?
Вообще, как будто интересно… Я глянул предложение о рефлексии и мне интересно немного: почему функции
std::metaрешили сделать отдельными функциями, а не методамиstd::meta::info? Хотя, учитывая, что в плюсах у базовых типов впринципе иное поведение, чем у производных, а данный как будто сделали таковым, чтобы разные компиляторы могли считать его таковым… Иначе, не знаю как-то, странное дизайнерское решение, мне кажется.Насчёт байта: пусть эксперименты с размером это и хорошо, но слова "байт = 8 бит" так у всех в голове укоренились, что мало кто бы стал писать исходя из обратного. Хотя, возможно, я не знаю какие-то нишевые области? Ну, многие языки уже приняли данное высказывание как стандарт, в любом случае. Отчасти к сожалению, ибо стандартизация чего-то это как отрезать ноги (взамен на то, чтобы вас не догнали с плохими намерениями)) ).
Про контракты: такое как будто лучше работает только если изначально является фишкой языка. Иначе получится как с добавлением добавлением nullability в C#. Или штук вроде
@NotNullв java — такой пример точнее. Вроде и окей, но как по мне не на уровне всего языка с принуждением вручную ставить if и отслеживанием локально допустимых значений такое будет так себе, лишь пускаться исключениями или абортами. Но тут уж без отдельного диалекта никак, наверное, как в том странном предложении о safe-c++ (сейчас не найду его, но где-то на хабре есть). Кстати, такое вроде какие-то языки реализовывали как свои "кор-механики", можете напомнить, какие? red: немного погуглив, нашёл лишь spark. В остальном, эта идея какая-то малоиспользуемая, хах. В любом случае, оставить нечто в декларации это хорошо, но, довериться лишь на то, что программист, статический анализ (тут у него возможностей мало), тестирование и т.д. что-то там заметит — это не то, чтобы полноценно. Или же поясните, как это должно работать?про
if consteval— в моменте перепутал, спасибо))constexprне особо часто приходится использовать, поэтому многие особенности всё же не помню, да и вспомнить всё же как будто проще будет лишь в момент необходимости:)К сожалению, маркер constexpr как обещание не очень работает: вполне себе можно функцию, никак не работающую в comp-time, пометить constexpr, с точки зрения стандарта это вроде нормально, но точно я не помню. Это сделано для тех случаев, когда при одних вводных, функция работает в constexpr-"режиме", а при других в рантайме.
Возможно, это разрешимо с помощью consteval, но уже не помню. Типа такого:
Ну, точно не знаю, наспех придумал.
Короче говоря, комитет очень сильно влюблён в свои возможности принимать самые странные решения.
Вообще, тут как будто четвёртое состояние всё же нужно: когда 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, если он нигде не используется?
В последнее время люблю читать про всякие интересные структуры данных...
Я тут подумал: если смотреть с точки зрения ЯПов, а не баз данных, то у такого способа балансировки будет небольшой недостаток в виде того, что она нестабильная (перемещает данные из одного участка памяти в другой).
А так, про кеше-дружелюную реализацию списка уже читал, а вот и аналог для дерева, классно))