> Только проверяются они в точке использования функции, а не в точке её определения
Согласен. Отсутствие встроенных концептов и проверки соответствия определения типа концепту — не есть гуд. Если надо, думаю, это можно решить (не интересовался), но да, будет классический «закат Солнца вручную» когда это мог бы делать компилер.
> компилятор не проверяет, что те проверки, которые вы добавили в её сигнатуру, на самом деле соответствуют её телу
Ммм, тут Вашу мысль не понял. Проверки по смыслу делаются по внешним признакам, бо duck typing. Если прям очень надо верифицировать тело-поведение, думаю, это тоже в каком-то видер решаемо тэгированием и доп. орг. мерами с разумной пресуппозицией, что пользователь/программер вредить не будет.
> без наследования, которое ещё нужно девиртуализировать
Откуда взялась девиртуализация? Обычное статическое наследование, никаких виртуалов…
> что-то вроде Send в C++ невозможно.
Честно пытался понять, что это, перечитывал несколько раз, но описание назначения и функционала оказалось за гранью моих скромных телепатических способностей.
ps: пока ещё все виденные мной утверждения «В С++ это сделать невозможно» на проверку следовало читать «я не знаю, как это сделать». Как обычно, не настаиваю, что сейчас именно такой случай.
В С++ параметры шаблонов тоже можно проверять на соответствие заданному функциональному интерфейсу и наличию определённых дата-мемберов. Это не всегда надо, но если надо — не вопрос, поэтому аргумент не валиден.
Я не знаю, как это работает в расте (и, соответственно, что конкретно имеется в виду), но судя по всему, при желании, и в плюсах же тоже можно проверять аргументы шаблонов компилятором на соответствие любым требованиям типа (ну, может не 100% эквивалентно расту, ибо см. выше про отсутствие моих знаний в нём, но для надёжной работы — достаточно). Если хотим «типизировать» параметр шаблона, то требуем, чтобы его тип он наследовался от специального базового класса (::std::is_base_of<> проверяем через ::std::enable_if<> или static_assert()). В этом спец.базовом классе (aka статический интерфейс) просто задаём/перечисляем, но не декларируем (т.е. не пишем реализаций), нужные функции, описывающие абстракный тип. Соответственно, любой наследный класс от этого статического интерфейса будет обязан переопределить эти функции, иначе будет ошибка линковки из-за отсутствия определений. А не наследный класс не пролезет в проверку ::std::is_base_of<>.
Так же с небольшим количеством шаблонной магии можно проверить наличие у типа нужного дата-мембера, хоть и не так «батчем», как с интерфейсными функциями (хотя может и можно батчем, я просто не заморачивался с этим, т.к. по хорошему если выставлять наружу важные дата-мемберы, лучше сделать это через геттер, который будет описан в интерфейсном классе).
Вполне допускаю, что это лишь некий эрзац-заменитель того, что может раст, ибо имея желание, можно отыскать дырки, однако для практического использования этого достаточно, чтобы избежать случайно-неслучайной подстановки неверного типа.
Ммм, погодите-ка. Шаблонная магия в некотором смысле вся «нетипизируемая», если так можно выразиться, до момента передачи типа в шаблон, после чего всё становится строго типизированным. Шаблон должен отвечать используемому интерфейсу, — да, иначе не соберётся. Т.е повторюсь, все шаблоны как бы одновременно «нетипизируемые», но результат всё равно строго типизирован. По сути, шаблоны это такие «макросы на стероидах» (с).
Т.е. я правильно понял, в расте вообще нет шаблонов?
Я ничего не понял в вашем ответе. Как некая идентичная функциональность, присутствующая в обоих альтернативах, может быть аргументом за или против? Она есть и там и там. И?
Пытаешься внятно и спокойно объяснить, почему такие статьи никого ни в чём не убеждают и что нужно исправить, чтобы убеждали, а в ответ получаешь тучу минусов в комент и карму от тихушников и ни одного ответа по существу.
раст == детский сад?
плюсую.
На десктопе сижу на ФФ с времён ещё допотопной версии 2.0. Андроидного фокса поставил сразу же, как он вышел. Всегда прекрасно работает и там, и там.
Апелляция к авторитету хорошо работает для детей лет до 7-8. Потом чем дальше, тем хуже. Однако почему-то большинство статей «почему ты должен немедленно бросить этот мерзкий языческий С++ и перейти на сторону света ржавчины» пишутся именно в виде апелляции к авторитету какого-то хрена-с-горы. Я вполне готов допустить, что оный пэрсонаж может быть даже действительно в чём-то говорит дело. Но меня это всё равно не убеждает, а покровительски-панибратский тон вызывает лишь раздражение, саркастическую усмешку и вопрос, так ли уж автор хорошо разбирается в вопросе, если не понимает таких простых вещей в жизни?
Кстати в тему же этого вопроса: пример про написание связных списков, мягко говоря, удивил. В 99,99% случаев никто в здравом уме и трезвой памяти не станет решать типовые и давно решенные задачи, когда уже есть множество готовых проверенных решений в виде STL, Boost, Poco и да-тысячи-их-на-любую-потребность. И если это хоть на 1% не так в предлагаемой альтернативе — её просто ещё рано толкать в прод и масс.маркет. А если так, зачем такой пример?
— Вот что реально было бы интересно узнать (ну, т.е. как «реально»… было бы совсем реально — уже давно бы сам узнал, но пока просто интересно в рамках расширения кругозора) — это с какими полезными и удобными возможностями С++ придётся неминуемо расстаться при переходе на раст. There's no free lunch, сколько это стоит? И почему выбрали такое идиотское название — «ржавчина».
Тут главное помнить, что это всё работает лишь благодаря человеколюбивой милости компиляторописателей)) Чтобы вот кто-то коммитился «мы гарантируем, что это всегда во всех версиях наших компиляторов будет работать именно так» — я такого не видел…
Не думаю, что это повлияло на результат, но вообще-то в С++ так делать нельзя, это UB (только в С можно). Доступ к памяти некастуемого типа разрешен только через char* (::std::memcpy() в частности или std::bit_cast (since C++20)).
ПИчаль только в том, что все (виденные мной) решения интерфейсов на базе HTML безумно медленные. Т.е. message box кастомизированный вывести ещё может и ничего, но уже хотя бы просто длинный список с минимальным количеством контролов — всё, крантец. Symantec уже много лет базирует свои продукты Norton* на таких интерфейсах и в результате каждое «общение» с таким софтом — боль чисто по причинам крайне неприятных лагов интерфейса. Зато «вжух-вжух и готово», да…
б. есть две ситуации:
— первую ситуацию мы наблюдаем в статье: в чрезвычайно острой тематике спасения мира от опасного вируса у коллег возникает сомнение в достоверности использованных данных и, понимая что от оперативности привлечения внимания к проблеме зависят жизни и здоровье людей и огромные финансовые вложения, они не обращаются напрямую обращаются напрямую к авторам в открытом письме (очевидно, чтобы привлечь внимание других людей к найденной ими проблеме). Ибо ожидание ответа на приватное письмо, на которое авторы желающие скрыть косяк могут специально не отвечать, приведёт только к потере ценного времени и ненужному риску.
— вторую ситуацию описал коллега Elrond16, судя по его текстам, занимающийся физикой. Просто по закону больших чисел мне трудно предположить, что коллега Elrond16 будет писать статью столь серьёзного масштаба последствий и огромной важности.
Поэтому да, в его случае и подобных, такое открытое письмо можно было бы рассматривать как хамство, хотя и тоже не обязательно. В рассматриваемом же исходном случае — всё абсолютно нормально. Ибо обстоятельства иные.
Вот именно. Не просто не повод, но и отличная возможность выставить дураками тех, кто наехал, просто опубликовав нужные исходные данные и, возможно, ещё инфу сверху.
Строить же из себя обиженку исключительно неумно, особенно на фоне того, что сомнения выразили вовсе не рандомные «чуваки из интернета», а вполне себе серьёзные коллеги.
Ваше представление об эффективности процесса рецензирования и предпечатной подготовки совершенно не соответствует действительности. Ошибки в обработке статистики регулярно всплывают во множестве публикаций многократно рецензированных и перерецензированных. Только вот недавно выпиливали «исследование» по uидроксихлорохину.
Согласен. Отсутствие встроенных концептов и проверки соответствия определения типа концепту — не есть гуд. Если надо, думаю, это можно решить (не интересовался), но да, будет классический «закат Солнца вручную» когда это мог бы делать компилер.
> компилятор не проверяет, что те проверки, которые вы добавили в её сигнатуру, на самом деле соответствуют её телу
Ммм, тут Вашу мысль не понял. Проверки по смыслу делаются по внешним признакам, бо duck typing. Если прям очень надо верифицировать тело-поведение, думаю, это тоже в каком-то видер решаемо тэгированием и доп. орг. мерами с разумной пресуппозицией, что пользователь/программер вредить не будет.
А в чём вы видите проблему при этом?
> Ударит ли вас компилятор по рукам, если вы концептами, SFINAE или ещё как потребуете только operator< или operator>?
Ээээ… Что значит «ударит ли по рукам» если код не скомпилится?
Откуда взялась девиртуализация? Обычное статическое наследование, никаких виртуалов…
> что-то вроде Send в C++ невозможно.
Честно пытался понять, что это, перечитывал несколько раз, но описание назначения и функционала оказалось за гранью моих скромных телепатических способностей.
ps: пока ещё все виденные мной утверждения «В С++ это сделать невозможно» на проверку следовало читать «я не знаю, как это сделать». Как обычно, не настаиваю, что сейчас именно такой случай.
Так же с небольшим количеством шаблонной магии можно проверить наличие у типа нужного дата-мембера, хоть и не так «батчем», как с интерфейсными функциями (хотя может и можно батчем, я просто не заморачивался с этим, т.к. по хорошему если выставлять наружу важные дата-мемберы, лучше сделать это через геттер, который будет описан в интерфейсном классе).
Вполне допускаю, что это лишь некий эрзац-заменитель того, что может раст, ибо имея желание, можно отыскать дырки, однако для практического использования этого достаточно, чтобы избежать случайно-неслучайной подстановки неверного типа.
Ммм, погодите-ка. Шаблонная магия в некотором смысле вся «нетипизируемая», если так можно выразиться, до момента передачи типа в шаблон, после чего всё становится строго типизированным. Шаблон должен отвечать используемому интерфейсу, — да, иначе не соберётся. Т.е повторюсь, все шаблоны как бы одновременно «нетипизируемые», но результат всё равно строго типизирован. По сути, шаблоны это такие «макросы на стероидах» (с).
Т.е. я правильно понял, в расте вообще нет шаблонов?
раст == детский сад?
На десктопе сижу на ФФ с времён ещё допотопной версии 2.0. Андроидного фокса поставил сразу же, как он вышел. Всегда прекрасно работает и там, и там.
светаржавчины» пишутся именно в виде апелляции к авторитету какого-то хрена-с-горы. Я вполне готов допустить, что оный пэрсонаж может быть даже действительно в чём-то говорит дело. Но меня это всё равно не убеждает, а покровительски-панибратский тон вызывает лишь раздражение, саркастическую усмешку и вопрос, так ли уж автор хорошо разбирается в вопросе, если не понимает таких простых вещей в жизни?Кстати в тему же этого вопроса: пример про написание связных списков, мягко говоря, удивил. В 99,99% случаев никто в здравом уме и трезвой памяти не станет решать типовые и давно решенные задачи, когда уже есть множество готовых проверенных решений в виде STL, Boost, Poco и да-тысячи-их-на-любую-потребность. И если это хоть на 1% не так в предлагаемой альтернативе — её просто ещё рано толкать в прод и масс.маркет. А если так, зачем такой пример?
— Вот что реально было бы интересно узнать (ну, т.е. как «реально»… было бы совсем реально — уже давно бы сам узнал, но пока просто интересно в рамках расширения кругозора) — это с какими полезными и удобными возможностями С++ придётся неминуемо расстаться при переходе на раст. There's no free lunch, сколько это стоит?
И почему выбрали такое идиотское название — «ржавчина».Вода мокрая, масло масляное, биты двоичные. Хотя они двоичные по определению.
jpghtmlСпасибо за напоминание, полезно.
ps:
> #define FAU(x) (*(unsigned int*)(&x))
> #define DAU(x) (*(unsigned long long*)(&x))
Не думаю, что это повлияло на результат, но вообще-то в С++ так делать нельзя, это UB (только в С можно). Доступ к памяти некастуемого типа разрешен только через char* (::std::memcpy() в частности или std::bit_cast (since C++20)).
а. нет такого понятия «научное хамство»
б. есть две ситуации:
— первую ситуацию мы наблюдаем в статье: в чрезвычайно острой тематике спасения мира от опасного вируса у коллег возникает сомнение в достоверности использованных данных и, понимая что от оперативности привлечения внимания к проблеме зависят жизни и здоровье людей и огромные финансовые вложения, они
не обращаются напрямуюобращаются напрямую к авторам в открытом письме (очевидно, чтобы привлечь внимание других людей к найденной ими проблеме). Ибо ожидание ответа на приватное письмо, на которое авторы желающие скрыть косяк могут специально не отвечать, приведёт только к потере ценного времени и ненужному риску.— вторую ситуацию описал коллега Elrond16, судя по его текстам, занимающийся физикой. Просто по закону больших чисел мне трудно предположить, что коллега Elrond16 будет писать статью столь серьёзного масштаба последствий и огромной важности.
Поэтому да, в его случае и подобных, такое открытое письмо можно было бы рассматривать как хамство, хотя и тоже не обязательно. В рассматриваемом же исходном случае — всё абсолютно нормально. Ибо обстоятельства иные.
Такое «общение» мне не интересно.
Строить же из себя обиженку исключительно неумно, особенно на фоне того, что сомнения выразили вовсе не рандомные «чуваки из интернета», а вполне себе серьёзные коллеги.