LINUX.ORG.RU

Rust: преобразования указателя на трейт в конкретный тип

 


1

7

Хочу хранить мапу с экземплярами реализующими трейт. При этом на месте одного ключа я уверен, что будет всегда лежать экземпляр одной и той же реализации (в данном примере в качестве ключа выступает помимо прочего TypeId). С хранием проблем не возникает, возникает проблема с извлечением элементов.

use std::collections::HashMap;
use std::any::TypeId;
use std::rc::Rc;

trait MyTrait {
    fn new() -> Self where Self: Sized;

    // Тут ещё какие-нибудь методы
}

struct MyStruct {
    items: HashMap<(i32, TypeId), Rc<dyn MyTrait>>
}

impl MyStruct {
    fn get<T: MyTrait + 'static>(&mut self, key: i32) -> Rc<T> {
        if let Some(item) = self.items.get(&(key, TypeId::of::<T>())) {
            item.clone() as Rc<T>
        } else {
            let item = Rc::new(T::new());
            self.items.insert((key, TypeId::of::<T>()), item.clone());
            item
        }
    }
}

Как правильно конвертировать элемент при его извлечении в тип T?

★★★★★

Последнее исправление: KivApple (всего исправлений: 2)
Ответ на: комментарий от khrundel

Отвечу вкратце на остальный бред.

Для добавления другого примитива, авторы либы должны были бы писать новый метод drawXXX. И заметь, никакого draw(Shape shape) в этой библиотеке нет.

Именно! Иметь draw(Shape shape) – бред. Поэтому, если ты хранишь у себя Shape shape, то передача на отрисовку будет сводиться к match с описанием маппинга тип -> метод для отрисовки. Проблема в том, что, складывая в shape тип, ты его знаешь. Ты уже знаешь, какой метод нужно вызвать для него. Ты на ровном месте создаешь себе мувы, диспатчи, лишний код.

Ты подстелил соломку постфактум.

Охренеть. Добавил контекст в ответ на запрос показать с контекстом – «подстелил соломку постфактум». Как же он виляет.

Так и не было. Говорю же тебе, клоун, буст не в счёт

Мне вообще без разницы, что тебе в счет, а что нет. Boost был почти всю историю крестов и использовался почти всю историю плюсов.

Что характерно, с самого появления плюсов люди пилили свои реализации динамических массивов с реаллокацией, иногда под конкретные типы, иногда обобщённые.

И все нормальные люди описывали ситуацию: «в C++ нет динамических массивов с реаллокацией, однако язык позволяет их реализовать».

«в языке нет динамических массивов с реаллокацией, однако язык позволяет их реализовать»

Нормальные люди говорили «в STL нет контейнера динамического размера, последовательно хранящего элементы в памяти, но язык позволяет их реализовать». Динамических массивов в С++ нет.

Ты, видимо, с K&R C спутал.

Вообще-то, символьные литералы имеют тип int в актуальном С.

Так что символьный литерал - это именно char.

Нет. Символьный литерал по умолчанию имеет тип char, но char’ом не является. Ну да это не принципиально.

У тебя новая версия объяснения, почему тот код скомпилялся?

Забавно, что ты так и не понял, что причина там вовсе не в char. Это так же мог быть short, long и так далее – проблема в неявных преобразованиях. Эта проблема – наследие сишки, С++ – строго типизированный язык. Если бы ты писал auto&&, как я показал ранее – проблем бы не было. А еще можно писать std::same_as<int> auto x и std::same_as<char> auto x.

Перепиши его на «аналогичный» раст с Result.

match (foo) {
    Ok(m) => { print(m) },
    Err(e) => e
}

Отличие одно – компилятор требует сделать match или if let для извлечения любого из значений, это элементарно делается для if err != nil, это есть в практически любом статанализаторе, и даже реализуется на уровне языка – см. тот же TS.

Ты же в курсе, что в расте есть дженерики?

Да я-то в курсе как раз. А ты? Rust: преобразования указателя на трейт в конкретный тип (комментарий)

а старую оставили для вот них.

Ты опять начинаешь маневрировать. Оставили – нет проблем завернуть в тип, это тривиальное найти&заменить изменение.

СВИНАЕ в расте вообще невозможен, в виду наличия нормальных дженериков.

И это проблема. Дженерики в расте не нормальные, они в нем это помесь темплейтов и дженериков, берущая от каждого мира худшее. От темплейтов берется раздувание кода, с которым rustc практически не умеет справляться, в отличие от крестовых фронтов, от дженериков – затирание типов.

ADL… Знаешь, давай представим что это вот реально та самая сложная штука, из-за которой авторы Раст сломались, плюнули и сказали что не будут оверлоады делать. Могли бы они обойтись без неё?

Да. Правда, для этого нужна функциональность концептов, т.е. возможность проверить валидность произвольного выражения и его свойства в компайл-тайме. Тогда получаются ниблоиды.

В расте нет, например, операторов +(a,b), оператор всегда пилится через self. Так что foo + bar для раста - это всегда foo.add(bar), так что если у тебя foo в неймспейсе, то вопросов где брать add тупо нет, в трейте, который реализован для foo.

Ещё раз, для тупых, оверлоады в расте есть.

А я где-то утверждал обратное?

Они используются для определения дженерика.

Да, это их очень кастрированная форма. Проблема не в том, есть они или нет, проблема в том, что типы затерты, и особого проку нет. Ты задекларировал T: Fooable<i32> + Fooable<f32>, дальше определение это вопрос линейного обхода ассоциированных с именем трейтов и попытки туда подставить тип аргумента. Ты не знаешь ни тип T, ни его свойства – только то, что его можно .foo от i32 и f32.

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

Siborgium ★★★★★
()
Последнее исправление: Siborgium (всего исправлений: 1)
Ответ на: комментарий от Siborgium

Именно! Иметь draw(Shape shape) – бред.

Знаешь что? Твоя анальная клоунада мне надоела. Сначала ты мне написал, что шейпы через enum делать нельзя, надо через трейт-объект. Для доказательства этого потребовал предъявить тебе графическое api, принимающее enum. Я тебе ответил, что в графические api не только enum’ы не передаются, но и трейты/базовые классы, это как бы другой уровень. Вопрос как в один контейнер запихать много разных примитивов на уровне графического api вообще не решается. Привёл тебе пример даже. И что я получил? Ты переобулся в прыжке и начал свистеть, что, оказывается именно это ты мне и пытался объяснить. Короче, ты победил. Если человек настолько лишён стыда чтоб нести ахинею и каждый раз обосравшись делать вид что это не он, а потом, когда уляжется, снова по кругу повторять ту же самую ахинею, то спорить тут бесполезно. В общем дальше без меня.

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Что я скажу: хрень там полная и дрочево на костыли из плюсов. СВИНАЕ в расте вообще невозможен, в виду наличия нормальных дженериков.

Прокомментирую эту чушь. В целом это типичная проблема ретрансляторов пропаганды. Они сидят в своём болоте невежества и агрятся на всё. Я уже приводил в пример множество его сказок.

Методичка там одна - обвиняет С++ в чём-то даже не понимая, что это свойства любой состоятельной системы. Далее показывая «у меня этого нет» называет это свойством.

Есть в расте генерики? Нет - это бездарный мусор. Этот мусор не может делать и 1% того, что может делать цпп. Почему? Потому что просто примитивная скриптуха, которую писали те кто дальше лабы не ушёл в развитии.

Этот момент я отдельно поясню. Комментом.

right_security
()
Ответ на: комментарий от khrundel

Дак вот. sfinae - это свойство любого преобразования типов. Любое преобразование может быть неполным. И нам нужна эта фича.

И вот мы пишем это преобразование, которое является неполным. Что делать? Там пропагандисты рассказывают какие-то сказки про проверки, но всё это чушь. Полиморфизм нельзя проверить. Все их проверки это просто фейк. Там нет никаких проверок - просто код говно.

Понять проблему можно просто. Генерик-мусор и код на расте - это код уровня random(seed) => 4 - очевидно, что в рамках подобного мусора мы очень просто можем найти обратную функцию. Особенно если написать random(seed: int): 4 => 4.

Вот все функции в подобной скриптухе - они такие. Примитивное днище.

Но кому в реальности нужен такой рандом? Да, пропаганда сильная и адепты его впаривают за рандом. И многих можно убедить, но толку. Людям нужен реальный рандом.

В реальном рандоме найти обратную функцию уже не просто. И зачастую невозможно. Допустим, система типов цпп вполне себе выражает хеширование. Т.е. произвольную тип-строку в произвольную тип-строку. Очевидно, что у хеша нет обратной функции. В этом его фишка.

Вот системы типов скриптухи - это таблица. Это только табличные преобразования. Очевидно, что в рамках любых табличных преобразований - мы можем найти обратную функцию. На этом фокусе и работают все их проверки. Но это мусор, очевидно.

Пример с хешом здесь показателене. Если мы опишем хеш-функцию как таблицу(каким образом?), то там уже будет обратная функция. Но как это написать?

Вот все хеши у адептов раста - это hash(str: "foo") => "bar" с таким уровнем, конечно, мы можем проверить что-то.

right_security
()
Ответ на: комментарий от right_security

Так и не написал про преобразования. Проще, опять же, написать это на примере хешей.

Вот представьте, что вы хотите написать функцию, которая бы принимала только валидные хеши. Допустим те, где вначале 7 нулей. Как мы здесь и что прочекаем заранее? Ничего.

Для этого и существует sfinae, мы принимает неполные преобразования и работаем с ними так как будто бы они полные. Узнать попал ли аргумент в это не-полноту, либо нет - мы не можем заранее.

Конечно, пропагандист здесь перепутал и sfinae это не то. В расте не осилил не его, а преобразования типов. sfinae как понятие цпп - оно дальше. Но оно основано на то, о чём я рассказываю. Это базовый принцип. Просто на разных этапах в цпп его выражают разные механизмы.

Если мы возьмём за пример тот же ts, где системы типов вынуждена была косплеить полиморфизм(в сравнении с тс - раст это мусор бездарный. Хотя в сравнении даже с пхп будет тоже самое. Система типов там(расте) просто днище даже по меркам 60-70 годов).

Как следствие в типовых преобразованиях появился if - это сломало табличность, а значит преобразования будут не полными. Это значит, в любом преобразовании где есть if - мы не можем вычислять его как a|b - это сделает преобразование бессмысленным.

Почему a|b - бессмысленно? Причина тому ясна. Если у нас преобразование неполное - оно не имеет смысла в ветке b, а значит мы не можем написать для него реализацию.

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

Поэтому мы предполагаем, что оно будет успешным.

right_security
()
Ответ на: комментарий от right_security

Царь, твой бред можно было бы написать проще: «не хочу париться, хочу говнокодить, а конпелятор пускай разрулиывет со своей СВИНАЕ».

Что я могу ответить? Я понимаю твою боль. И так сказать с фактологической точки зрения ты даже прав, действительно это всё сложно и муторно и конпелятору ничего не стоит попробовать разные шлабоны и выбрать тот, который компиляется.

Однако целеполагание авторов современных языков другое. Им плевать на твоё удобство. Им даже плевать на компилятор. Они заботятся об удобстве читателя кода. Потому что если ты потратить пару лишних часов на приведение в порядок своего кода и этим позволишь читателю сэкономить 5 минут на разбор, суммарно это сэкономит время разработки, так как читается код гораздо чаще чем пишется и если при чтении происходит ошибка, то это сожрёт ещё больше времени.

Ну а если ты хочешь поговорить заумно, то я тебе тоже могу ответить. Скриптухой, не умеющей в обобщенное программирование, являются как раз кресты. Обобщенное программирование, это когда ты говоришь «функция выполняет такую-то операцию над любой коллекцией объектов любого типа». Соответственно ты обязан написать правильные гварды для дженерик-параметра, а компилятор - проверить, что любой тип, соответствующий этим параметрам сможет скомпиляться с данным дженериком. В плюсах же просто костыль, причем Страуструп предельно честен: он назвал их не дженериками, а шаблонами. Подставь в шаблон на место плейсхолдера название типа, получишь исходник, который, возможно, скомпиляется. Новый вариант препроцессора.

В Расте вместо этого нормальные дженериком, а там где этого недостаточно и в плюсах требуются вариадики и прочая магия предлагают писать макросы.

Ну и возвращаясь к практической стороне, напиши ты внутри тела шаблонной функции

#if DEBUG
  std::cout<<val<<std::endl;
#endif

И привет, в лучшем случае в отладочном режиме программа прекратит компиляться, а в худшем - включится твое любимое СВИНАЕ и в релизной и отладочной сборках будут работать разные реализации

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Им даже плевать на компилятор.

Врёшь, ты ничего не знаешь о языках, их авторах и прочем.

Они заботятся об удобстве читателя кода.

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

Как можно говорить об удобстве в ситуации, когда пациент не может написать парсер? Не может написать компилятор языка? Твои пустые рассуждения предполагают у них выбор, но его нет.

Потому что если ты потратить пару лишних часов на приведение в порядок своего кода и этим позволишь читателю сэкономить 5 минут на разбор

Опять же, чушь. Большинство в индустрии - те, кто не могут в принципе читать код. Поэтому никакому это ненужно, даже если мы предположим, что твои фантазии действительно соотносятся с реальностью.

Поэтому, открою твою тайну, но в мире уже давно научились решать эту проблему - это разделение труда. Тот, кто может точит болты - ему ненужно уметь что-то. Никто не думает о том, чтобы он там читал чертежи сложнее тех, которые ему требуются.

Поэтому тот, кто не может читать - пойдёт писать на пхп.

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

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

Нет, это фантазии. За примерами ходить ненужно. Берём цпп и тот код, что написать на нём. На его шаблонах. Потом смотрим на тот растомусор. И о чудо - он говно. Он даже не может в 1% того, что может цпп.

Но как же так? Код говно, а шаблонов нет? Отсутствие шаблонов должно ведь увеличивать ту самую продуктивность. Код ведь больше читается? А чего же мы этого не наблюдаем?

right_security
()
Ответ на: комментарий от khrundel

Кстати, начав смотреть на языки популярные среди неофитов я обнаружил, что мне ненужно ничего объяснять. Ничего доказывать. Я просто привожу в пример ts и ты теряешься, как ты это делал выше.

Ну а если ты хочешь поговорить заумно, то я тебе тоже могу ответить. Скриптухой, не умеющей в обобщенное программирование, являются как раз кресты.

Да ты чё. Только почему-то в реальности мы этого не наблюдаем.

Обобщенное программирование, это когда ты говоришь «функция выполняет такую-то операцию над любой коллекцией объектов любого типа».

Не, в этом твоя проблема. Ты даже не знаешь предмета. Пытаешься натягивать то, что не понимаешь на свою жалкую помойку.

Соответственно ты обязан написать правильные гварды для дженерик-параметра

Нет, ты опять всё перепутал. Никаких гвардов, гереников и прочей чуши не существуют. Генерики - это просто мусор, который используют те кто не осилил.

Генерики не могут в типы, не могут в гварды. Это говно. Ты даже элементарных вещей не знаешь. Ты просто рядовйо пропагандист.

а компилятор - проверить, что любой тип

Ты даже что такое типы не знаешь. Не говоря уже о том как работает то на что ты ссылаешься. Никакой компилятор твоей мусорной скриптухи не знает ничего о типах. И ничего не проверяет.

соответствующий этим параметрам сможет скомпиляться с данным дженериком.

Нет, ещё раз. Ты путаешься в элементарщине. Что было уже множество раз продемонстрировано.

Аннотации в генериках нужны только потому, что это говно стирает типы. И там нет никаких типов - генерик-аннотации - это интерфейсы, либо vtable. Это обычный табличный жава-мусор.

Т.к. невежество не может в полиоморфизм, то полиморфизм сводится к таблицам. Вводится таблица, она через имя связывается в impl.

В Расте вместо этого нормальные дженериком, а там где этого недостаточно и в плюсах требуются вариадики и прочая магия предлагают писать макросы.

Да ты чё. Т.е. вместо нормального языка говно, а дыры затыкаются макросами, которые не язык, а просто позорище?

В плюсах же просто костыль, причем Страуструп предельно честен: он назвал их не дженериками, а шаблонами. Подставь в шаблон на место плейсхолдера название типа, получишь исходник, который, возможно, скомпиляется. Новый вариант препроцессора.

right_security
()
Ответ на: комментарий от khrundel

Ну и возвращаясь к практической стороне, напиши ты внутри тела шаблонной функции

Боже, эти пропагандисты с тупыми заходами через макросню. Ну хорошо -я напишу это.

И привет, в лучшем случае в отладочном режиме программа прекратит компиляться

С чего вдруг? Какой-то отладочный режим и прочая чушь - сразу мимо. Меня мало интересуют попытки навязать мне свои фантазии.

а в худшем - включится твое любимое СВИНАЕ

Ты не знаешь что это такое. Кидание базвордами тебе не поможет. И оно не включится - в этом одна из проблем цпп.

и в релизной и отладочной сборках будут работать разные реализации

Да ты чё. Уровень, конечно, поражает воображение. Пропагандист мне пытается сообщить, что «разные реализации» в каким-то мусорных сборках - это проблема. Но реальная проблема в том, что ты запутался в показаниях. Ведь именно в твоей скриптухи мусорной имеется такое поведение.

Когда раст-позорище не смогло не позориться. Оно решило менять поведение, чтобы люди не видели всего того позора, что генерирует этот мусор без ллвм.

К тому же, в чём смысл фантазий нелепых? Ты мне хочешь навязать то, что я не могу мочь в условную компиляцию? Ну дак мимо. Это пытаются костылять и в твоём огрызке.

Ты мне хочешь сообщить, что я не могу конфигурировать это через sfinae? Тоже мимо. На каком основании?

right_security
()
Ответ на: комментарий от right_security

Опять же, чушь. Большинство в индустрии - те, кто не могут в принципе читать код.

А теперь представь, что я писал не о тестерах/визионерах/аналитиках или ещё кого ты там себе представлял, а о программистах, работающих на том же проекте и подумай ещё раз. Может быть дойдет. Итак, должен ли программист читать код? Должен ли код быть написан так, чтоб читающий его программист быстро и точно понял, что этот код делает?

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

Не надо на меня проецировать свои мечты. Это ты пытаешься казаться умнее чем ты есть и поэтому стараешься простые мысли ленивого дегенерата обратить во что-то псевдонаучное. Я пытаюсь писать максимально просто.

Берём цпп и тот код, что написать на нём. На его шаблонах.

Ну вот, чучело ты гороховое, ты как раз подтверждаешь то, на что пытаешься возразить. Ещё раз говорю: вменяемым людям глубоко насрать на то, насколько крутые концепции можно запилить на языке. На лиспе можно реализовывать очень крутые штуки. На форте вроде, я его не знаю, но слышал что тоже можно намудрить всякого. Но эти свойства таких языков сейчас не ценятся, люди, которых ты называешь студентами, но которые умнее тебя на 2 головы, они совсем не ценят свободу полёта мысли говнокодера, они отдают предпочтение читаемости кода, потому что главная проблема индустрии в том, чтоб один говнокодер не наворотил гору неподдерживаемого кода и не стал незаменимым. Им совершенно плевать на то что плюсы вот позволяют написать std::variant и std::visit(overloaded {…}) и тем самым получить некий аналог типа суммы и match по нему, гораздо проще добавить в язык этот самый тип сумму и матч, чтоб он был красивым, немногословным и работал именно так как нужно, а не так как получилось.

Кстати, комитет плюсов готовит очередной удар тебе в спину. Большие дяди уже несколько лет обсуждают матчинг в плюсы, настоящий, а не вот эту срань, на которую вы дрочите. Будете писать

int get_area(const Shape& shape) {
  return inspect (shape) {
    <Circle> [r] => 3.14 * r * r,
    <Rectangle> [w, h] => w * h
  }
}

или

int get_area(const Shape& shape) {
  return inspect (shape) {
    c is Circle => 3.14 * c.r * c.r,
    r is Rectangle => r.w * r.h
  }
}

И ты будешь рассказывать, насколько это круто, не то что в Расте.

khrundel ★★★★
()
Ответ на: комментарий от right_security

С чего вдруг? Какой-то отладочный режим и прочая чушь - сразу мимо. Меня мало интересуют попытки навязать мне свои фантазии.

Видимо это слишком сложно для тебя. Попробуй прочитать ещё раз.

Ладно, тебе сложно, объясняю на пальцах: твоё тупое свинае завязывает выбор реализации на фактический код, присутствующий в теле шаблона, а не на его прототип. А фактический код может меняться в зависимости от флагов компиляции. Например:

#if DEBUG
#define TRACE(x) std::cout<<__FILE__<<":"<<__LINE__<<" "<<#x<<(x)<<std::endl;
#else
#define TRACE(x) ;
#endif

Ну, или если хочешь, можешь запилить аналогичный трейс на шаблоне.

Далее ты добавляешь внутрь одного из шаблонов, самого специализированного безобидную строку TRACE(value) и всё. В случае компиляции без -DDEBUG будет выбираться этот шаблон, в случае c -DDEBUG - другой, менее специализированный. Программа будет вести себя странно. А всё от того, что для какого-то типа не написана перегрузка operator <<.

khrundel ★★★★
()
Последнее исправление: khrundel (всего исправлений: 1)
Ответ на: комментарий от khrundel

Хрюндель, ты ведь совсем нулёвый. Зачем ты споришь, усираешься? Ты бы изучил тему для начала и перестал быть таким фанатичным пустословом с пустотой вместо знаний.

И ты будешь рассказывать, насколько это круто, не то что в Расте.

На самом деле нет, но, что самое интересное - мне ничего не помешает это сделать. Потому как это действительно не мусорное растоднище.

right_security
()
Ответ на: комментарий от khrundel

Давай я тебе объясню в последний раз. Меня уже давно утомила твоя клоунада, да и в целом ты давно слился и перестал мне отвечать.

Вот ты рассказывал что-то про дактайпинг, но как всегда сел в лужу. Да ладно сел - ты запутался в показаниях. Тебе показали, что в твоём днище так же есть дактайпинг. Что ты ответил? Ты съехал с темы.

Но из этого делается простой вывод. Все твои попытки - жалкая клоунада, потому как если посмотреть на реальность мы видим, что убожество типа раста пытается подражать цпп. Просто оно настолько бездарное говно, что может это делать еле-еле.

add = |x, y| x + y - это тот самый дактайпинг. Самое интересное то, что даже базовый фокус параметрического говна - это дактайпинг.

Вот ты утверждаешь, что в твоём мусоре нужно что-то аннотировать, но почему-то map(x, |x| x.foo()) аннотировать ненужно. А почему? Да, это дерьмо не может вы вывод типов и потому позорится, но некоторые костыли так есть. Я показал их выше.

При этом, если мы напишем так:

fn foo<T>(x: T) { map(x, |x| x.foo()); }

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

Если же ты против и требуешь, чтобы аннотации были, то почему же их нет? Это противоречие.

Точно так же как раст-пропагандисты плакались много лет про «преобразование типов говно», а потом побежали косплеить into/collect. В результате то оказалось, что ни не говно. Просто мусор не может в них. Поэтому сектантов пришлось оправдываться, но когда какие-то фокусы они смогли спастить - получилось противоречие.

И в этом все вы - жалкие пропагандисты.

Им совершенно плевать на то что плюсы вот позволяют написать std::variant и std::visit(overloaded {…}) и тем самым получить некий аналог типа суммы и match по нему, гораздо проще добавить в язык этот самый тип сумму и матч, чтоб он был красивым, немногословным и работал именно так как нужно, а не так как получилось.

Вот типичные бредни подобных пропагандистов. Уже тысячи раз было доказано, что именно match является пародией на visit, а не наоборот. Но пропагандист как бот продолжаешь повторять одну и ту же чушь.

Так же было доказано, что никаких сумтипов в этой мусорной скриптухи нет. Это бездарный ни на что не способный сахарок. Смысла от которого нет. Но пропагандист продолжает врать.

right_security
()
Ответ на: комментарий от khrundel

твоё тупое свинае завязывает выбор реализации на фактический код, присутствующий в теле шаблона

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

И уж никакого «тела шаблона» в принципе не существует.

а не на его прототип.

Какой прототип? Прототип чего? Что это за чушь мусорная? Ещё раз тебе сообщаю - прототип и прочий vtable-мусор - это дерьмо. Оно существует только в бездарной скриптухи и не может существовать в нормальном языке.

Если ты совсем упоролся и прототипов называешь сигнатуру функции, то в двойне опозорился. Ведь именно с сигнатурами и работает sfinae.

А фактический код может меняться в зависимости от флагов компиляции. Например:

Сразу мимо. То, что там может и прочие твои фантазии - меня мало волнуют.

Далее ты добавляешь внутрь одного из шаблонов, самого специализированного безобидную строку TRACE(value) и всё. В случае компиляции без -DDEBUG будет выбираться этот шаблон, в случае c -DDEBUG - другой, менее специализированный.

Нет, ты опять опозорился.

Во-первых, «выбирает» - сразу говорит о том, что ты типичный пустозвон. Потому как ты не можешь в случае с цпп использовать то, чего нет в твоём бездарном мусоре. Как следствие ты не можешь ссылаться на предикаты, специализацию и прочее - чего нет в твоём дерьме.

Во-вторых, нет не будет.

А всё от того, что для какого-то типа не написана перегрузка operator <<.

А всё от невежества типичного раст-пропагандиста. Хотя ты и о расте знаешь не больше. Просто рядовой пхпист, который надеется, что если ____ куда нужно - пойку повысят.

И даже если принять всю эту шизу, то дальше что? Ну выберется? В этом фишка. Человек специально так написал код, чтобы собиралось и с трейсом и без трейса. Значит ему это нужно было.

right_security
()
Ответ на: комментарий от khrundel

Самое интересное, что выше этот пропагандист рассказывал что-то об обобщённом коде. И смысл такого кода в том, что «собирается - работает».

Вот как пишут обобщённый код раст-адепты. Они его не пишут, но если захотят? Вот как мне написать функцию, которая бы принимала любой ренж(мусороный итератор из жавы, если мы говорим о раст-позорной скриптухи)?

А никак. Да, ворованные трейты(интерфейсы из жавы) позволяются как там заюзать какой-то итер, но почему так не делают адепты?

Потому как, если в жаве, можно передать foo(list) и он будет итерабельным, то вот в раст-мусоре это не так. Приходится писать бездарное .iter-дерьмо, но если мы будем его писать - код сломается.

Но ладно - будем везде использовать итераторы. Но, это говно опять сломается. Мусор не может в полиморфизм, а значит там будет самый убогий итератор, который не будет иметь нужных методов.

Но основная проблема не в этом. Она в том, что это дерьмо не являются владеющим. Нельзя вернуть итератор.

Оценить уровень позорища можно можно на примере size_hint. Эта жалкая скриптуха не смогла в полиморфизм. А засунуть в итератор size_hint хотелось секте, чтобы совсем не позорится.

И что же они решили? Они решили засунуть его в базовый итератор, а после обмазать рантайм-мусором и дефолтной реализацией, чтобы это днище не падало. И далее уже в рантайме проверять - какого типа итератор.

Т.е. это тот самый is из жавы. Только этот мусор в него не может - пришлось костылять для метода.

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

right_security
()
Ответ на: комментарий от khrundel

И таких примеров масса. Допустим, возьмём какой-нибудь boost safe numerics, на котором пару лет назад полёг не один раст-пропагандист.

Мало того, что мусорная(протухшие ещё лет 50 назад днище) «система» «типов» раста в принципе не может выразить что-то подобное.

Но предположим, что мы просто хотим написать генрик-сигнатуру для этого днища. Как это сделать? Можно написать миллион строк вайтонли-дерьма, но это никак не поможет.

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

Проблема в следующем. Если мы все операции с числами запишем в сигнатуру, то всё сломается. Вот у меня есть арифметика, для которой реализованы только пару операций. Я хочу использовать safe-враппер поверх неё. Как это сделать?

Если описать всё - меня обяжут реализовывать то, чего у меня нет. И что в принципе невозможно реализовать, допустим. Обычно раст-сектанты хакают это дерьмо через всякие фейк-реализации. По-сути через сегфолты и дыры.

Написал там пустую функцию, вставил туда ворованный __builtin_unreachable и погнал. Только на уровне типов это никак не отражается, вызвать эту функцию может кто угодно. И привет дыра.

Пример с size_hint я показал. Как следствие никакой обобщённый код на растомусоре в принципе написать нельзя. Потому мы его и не видим. А в цпп всё им завалено было ещё тогда, когда си с классами только-только появились в минимально-рабочем виде.

Поэтому все эти рассуждения о раст-пропагандистов, особенно про какой-то обобщённый код - мусор. Они даже не знают что это такое. Как это пишется и как работает.

Как и не знаю что такое типобезопасность. Потому что у них нет ни типов, ни безопасности.

right_security
()
Ответ на: комментарий от right_security

Вот ты рассказывал что-то про дактайпинг, но как всегда сел в лужу. Да ладно сел - ты запутался в показаниях. Тебе показали, что в твоём днище так же есть дактайпинг. Что ты ответил? Ты съехал с темы.

Я просто не читаю твой бред в основном. Вот сейчас ты высрал аж 6 комментариев в ответ и ни одного по теме. Естественно, я читаю твои высеры в лучшем случае по диагонали.

add = |x, y| x + y - это тот самый дактайпинг

Нет. Ты, клоун, даже не знаешь о чём пишешь. В расте add = |x, y| x + y не больше дактайпинг чем let a = x + y; И там и там типы явно не указываются, и там и там оператор или функция находятся из исходника без уточнения. Однако, в виду того что в расте лямбды не являются дженериками, add = |x, y| x + y, благодаря выводу типов, превращается в какое-нибудь Fn(i32, i32) -> i32; И где ты тут разглядел дактайпинг, клоун?

Однако вывод типа работает только внутри функции. Так что как при попытке объявить глобальную переменную не указав тип, так и при попытке описать функцию, неважно даже дженерик или обычную, без типа и в надежде «как-нибудь скомпиляется» - раст ничего подобного не позволит.

Так что ты опять обосрался.

Вот ты утверждаешь, что в твоём мусоре нужно что-то аннотировать, но почему-то map(x, |x| x.foo()) аннотировать ненужно. А почему?

Потому что вывод типа, клоун. Раст знает тип второго параметра мап.

Если же ты против и требуешь, чтобы аннотации были, то почему же их нет? Это противоречие.

Нет, тупица. Это «противоречие» разрешилось в тот момент, когда люди решили что писать int i = 0 излишне и разрешили писать auto i = 0. Лямбды в этом плане ничуть не хуже простых переменных.

Точно так же как раст-пропагандисты плакались много лет про «преобразование типов говно», а потом побежали косплеить into/collect. В результате то оказалось, что ни не говно.

Как говно было, так и осталось. Тебе, конечно, сложно понять, почему эксепшены - говно, а вот try!() или сахар над ним ? не говно. Так и с From/Into. Если программист явно дал разрешение на конвертацию и явно показал читателю, что он намерен произвести конвертацию, то никаких проблем в преобразовании типов нет. Проблемы бывают когда компилятор начинает заниматься этим по собственной инициативе.

khrundel ★★★★
()
Ответ на: комментарий от right_security

И уж никакого «тела шаблона» в принципе не существует.

Как не существует, клоун?

Какой прототип? Прототип чего? Что это за чушь мусорная?

О, так наше чучело даже терминологии сишечки и плюсов не знает?

Ну извини. Прототип функции, в рамках си/плюсов, означает список входных параметров, выходного типа, и имени. От декларации отличается тем, что декларация - это просто вставка прототипа функции в текст с точкой с запятой на конце.

Если ты совсем упоролся и прототипов называешь сигнатуру функции, то в двойне опозорился. Ведь именно с сигнатурами и работает sfinae.

Конечно же нет, что я и доказал примером выше.

Во-первых, «выбирает» - сразу говорит о том, что ты типичный пустозвон. Потому как ты не можешь в случае с цпп использовать то, чего нет в твоём бездарном мусоре.

Ты сейчас шаблонное программирование отрицаешь. Оно именно что позволяет использовать то, чего нет в твоём бездарном мусоре. Если ты пишешь foo(1, 1) и компилятор знает foo(int, int) то он вызовет её. А если не знает, но слышал про шаблон template int foo(int, T) то он попытается создать для тебя int foo(int, int) из него. Если не получится, то твоё СВИНАЕ будет искать другой способ сгенерировать что-то выглядящее как foo(int, int), и где-то там сбоку ещё будет попытка поискать foo(double, int) или чего-то типа этого. Короче, помойка а не язык.

И СВИНАЕ твоё будет отличаться от отсутствия СВИНАЕ именно тем, что оно будет выбирать шаблон для создания foo.

Во-первых, «выбирает» - сразу говорит о том, что ты типичный пустозвон…

Во-вторых, нет не будет.

И даже если принять всю эту шизу, то дальше что? Ну выберется? В этом фишка.

Так «нет, не будет» или «в этом фишка»?

Человек специально так написал код, чтобы собиралось и с трейсом и без трейса. Значит ему это нужно было.

Нет, конечно, чучело ты гороховое. Человек добавил трейс для отладки, чтоб понять, что тут вообще происходит в коде. В нормальном языке ему бы сказали, что для типа X нет перегрузки оператора <<(stream&, X). Ну или что шаблон write_trace не может быть инстанцирован. Но благодаря СВИНАЕ компилятор просто выберет другую реализацию, которая не на подозрении.

Для сравнения, в Rust в таком случае напишут: `T` cannot be formatted using `{:?}` because it doesn't implement `Debug`

Напишут ещё на этапе парсинга дженерика. Человек подумает, и добавит к гварду Debug. Далее попытается собрать, и ему скажут, чувак, твой тип X не умеет в Debug. Человек добавит #[derive(Debug)] и у него всё заработает. Ситуации, когда 2 дженерика сидят под одним именем и один из них выбирается втихую в расте не произойдёт. Потому что дженерики сделаны по-человечески, а не через СВИНАЕ

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Однако, в виду того что в расте лямбды не являются дженериками, add = |x, y| x + y, благодаря выводу типов, превращается в какое-нибудь Fn(i32, i32) -> i32; И где ты тут разглядел дактайпинг, клоун?

Эти оправдания жалкие. |x, y| x + y - это явный дактайпинг(ну если брать твои фантазии). Остальное нытьё мимо.

Никакого вывода типов там нет. Там сделан специальный костыль. Эникеям это сложно понять, но ты постарайся. Хотя бы через то, что нельзя написать |x| x.foo.

Как говно было, так и осталось. Тебе, конечно, сложно понять, почему эксепшены - говно

Настолько говно, что ты их косплеишь. И не можешь в принципе без них существовать.

а вот try!() или сахар над ним ? не говно.

Бездарное говно. Смысл в том, что изначально жертвы пропаганды орали, что никакой try! ненужен и пм - это круто. Лучшие ошибки, кукареку.

Но что-то пошло не так. А ворованный ?, тру - это просто попытка(жалкая) косплеить исключения.

Так и с From/Into. Если программист явно дал разрешение на конвертацию и явно показал читателю

Нет, пропагандист. Это преобразования типов. Никакого «разрешил» и прочих сказок там нет. Ты опозорился. Слёзы - мимо.

что он намерен произвести конвертацию, то никаких проблем в преобразовании типов нет.

Нет, там нет никакого конвертации. В том и смысл - она неявная. По методичке должна быть явная.

А то, что там into и прочий мусор - это по той же причине почему у тебя ::new и прочие жалкие костыли из жавы 30летней давности. Твоя скриптуха мусор.

К тому же, в этом дерьме уже давно костыляют неявные преобразования даже без into и прочего мусора.

Проблемы бывают когда компилятор начинает заниматься этим по собственной инициативе.

Какой компилятор, какой собственной? Что ты несёшь.

right_security
()
Ответ на: комментарий от right_security

Эти оправдания жалкие. |x, y| x + y - это явный дактайпинг(ну если брать твои фантазии). Остальное нытьё мимо.

Жалкое зрелище. Царь упорно пытается придумать, почему auto a = 1 + 2.0; - это не дактайпинг, а пацанский вывод типа, а let f = |x, y| x + y; let a = f(1, 2); - это не вывод типов, а дактайпинг.

Так вот, клоун, дактайпинг - это вполне устоявшееся понятие, означающее «признаём тип подходящим если у него есть подходящие по названию поля/методы/операторы». От вывода типа, т.е. «угадываем конкретный тип на основании операций, в которых данная переменная участвует», дактайпинг отличается возможностью работать с разными типами. Давай проверим:

let f = |x, y| x + y;
let a = f(1, 2);
lef b = f(1f32, 2f32);

Примет Раст такой код? Нет. Он скажет, что f принимает только параметры типа i32. Вывод: ducktyping’а в расте нет от слова совсем. Аналогичный код в плюсах откомпиляется. И, кстати, я плюсы за это не то что бы сильно критикую: внутри функции в лямбде хрен с ним, пусть будет дактайпинг. Но он ведь не только там, он и в нормально оформленных шаблонах, которые могут и другими людьми писаться и экспортироваться.

Надеюсь, теперь, когда ты узнал что такое дактайпинг, ты больше этот бред писать не будешь.

Бездарное говно. Смысл в том, что изначально жертвы пропаганды орали, что никакой try! ненужен и пм - это круто

У тебя галлюцинации. Трай в расте был ещё хрен знает когда, когда был оператор box вместо new и планировались зелёные потоки. Ты, видимо, его с ? перепутал.

Нет, пропагандист. Это преобразования типов. Никакого «разрешил» и прочих сказок там нет. Ты опозорился. Слёзы - мимо.

Что бы я окончательно опозорился не хватает примера неявного преобразования типов. Ну вот напиши мне код на расте, который с помощью from или into неявно приведёт тип, а я посмеюсь. Я вот знаю такой код:

fn log<T: Into<String>>(val : &T) {
   logger.write_string(val.into()) // ой, надо же, это ж джерик, внутри которого into явно вызывается.
}

Ну а если ты сейчас начнёшь свистеть про то что любое преобразование типа - это зло, то извини, не принимается. Никто никогда не говорил, что преобразования типов вообще не должно быть, без него ты инт с флоатом не сложишь.

::new и прочие жалкие костыли из жавы 30летней давности.

Насчёт ::new я бы согласился, некрасиво сделали. Т.е. в принципе нормально, но в условиях миграции из плюсов/жабы создаёт неверные ожидания. Нужно было ::create какой-нибудь, чтоб подчеркнуть, что это никакой не конструктор, а просто функция.

Какой компилятор, какой собственной? Что ты несёшь.

Так я приводил пример где преобразования типов обосрали std::visit по std::variant<int, char>.

Могу подкинуть ещё классического:

std::string_view trim(const std::string_view& str) {
  auto start = str.find_first_not_of(' '),
       end = str.find_last_not_of(' ');
  return start != std::string_view::npos ? str.substr(start, end - start + 1) : str.substr(0,0);
}

int main(){
   std::string a{"   test   "}, b{"   test2   "}; 
   auto trimmedA = trim(a);
   auto trimmedB = trim(b);
   auto trimmedAB = trim(a+b);
   auto trimmedShit = trim("   some shit   ");
   std::cout<< trimmedA << std::endl << trimmedB << std::endl << trimmedAB << std::endl << trimmedShit << std::endl;
}

Видишь, неявные преобразования сыграли с программистом злую шутку.

Также прошу обратить внимание на инициализацию строк. Какое уродство. Но плюсовики пишут так, потому что должна вырабатываться хорошая привычка обходить преобразования типов. В этом плане плюсы - родной брат javascript с его ===. К сожалению, как демонстрирует этот пример, нихрена это не спасает. Нужен новый способ вызова функций, отключающий преобразование. Чтоб плюсовики писали какой-нибудь trim{a} или trim({a}) или trim!(a) и это бы не компилялось, потому что функция принимает стрингвью, а передают ей стринг. И вот, на фоне всего этого, появляется Царь и вещает, что никакой проблемы с преобразованием типов нет и быть не может, глупости какие-то распространяемые пропагандистами.

khrundel ★★★★
()
Ответ на: комментарий от khrundel

К сожалению, как демонстрирует этот пример, нихрена это не спасает. Нужен новый способ вызова функций, отключающий преобразование. Чтоб плюсовики писали какой-нибудь trim{a} или trim({a}) или trim!(a) и это бы не компилялось

Либо нужно просто использовать explicit конструкторы у классов вроде string_view.

Почему это не сделал для string_view – это отдельный вопрос.

Но даже если бы все было обложено explicit-ом, то все равно осталась бы вот такая засада:

template<typename T>
const T & min(const T & a, const T & b) { return a < b ? a : b; }

...
const auto & r = min("A"s, "B"s); // Oops!

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

eao197 ★★★★★
()
Ответ на: комментарий от khrundel

add = |x, y| x + y, благодаря выводу типов, превращается в какое-нибудь Fn(i32, i32) -> i32

add = |x| x + 1 - это таки да, компилируется. И то, если вызывать add(x) только с одним типом.

add = |x| x.add_one() - а что случилось? (с) Если там действительно есть вывод, то почему компилятор плачет и просит указать тип вручную?)) Есть сильное подозрение, что на самом деле там внутри сидит какая-нибудь очередная vtable, которая затирает типы и увеличивает время компиляции

Lrrr ★★★★★
()
Ответ на: комментарий от Lrrr

add = |x| x.add_one() - а что случилось? (с) Если там действительно есть вывод, то почему компилятор плачет и просит указать тип вручную?)) Есть сильное подозрение, что на самом деле там внутри сидит какая-нибудь очередная vtable, которая затирает типы и увеличивает время компиляции

Какая vtable нахрен? Это рантаймовая структура, её не может быть во время компиляции. Хватит за царьком повторять его бред.

В остальном, да, это не очень красиво. Возможно это баг выводителя типов, а возможно сознательное решение, потому что в каких-то случаях такая лямбда с выводом приводила к ошибкам и поэтому в этом случае отключили.

В любом случае, в расте вывод типа на 2 головы выше плюсового. Печально что не на 3, ты это хотел сказать?

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Khrundel… Аплодирую. Давно не видел такого качественного цареубийства.

hbee ★★★★
()
Ответ на: комментарий от eao197

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

Ну так а я о чём?

Если бы автор кода знал, что trim(a+b) не примет на ревью сеньор-помидор, то он написал бы, условно, trim!(a+b) (предполагаем, что запрет на неявные преобразования включается восклицательным знаком). Этот код бы уже не принял компилятор. Автору пришлось бы писать trim!((a+b).to_view()), чтоб компилятор без борроу чекера эту штуку пережевал. Вот этот, последний вариант, он бы мог заставить задуматься, всё ли правильно в этом коде, даже если читатель не очень представляет, какие параметры функция trim принимает.

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Вот этот, последний вариант, он бы мог заставить задуматься, всё ли правильно в этом коде, даже если читатель не очень представляет, какие параметры функция trim принимает.

Да уж, «страшно далеки вы от народа» (с)

Если человек напишет:

auto r = trim!((a+b).to_view());

то проблему это не решит от слова совсем. Потому что вернется все равно string_view на временный объект string.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Не решит, но код станет намного понятнее. Тот же сеньор-помидор просматривая, вот этот trim(a+b) мог бы и зевнуть, а вот где явно временная строка приводится к вьюхе не заметить будет сложнее. Кстати, необязательно и to_view. Вон, предлагают as добавить, как универсальный преобразователь типа.

auto r = trim!((a+b) as string_view);

тоже было бы заметнее.

khrundel ★★★★
()
Ответ на: комментарий от khrundel

тоже было бы заметнее

Не было бы. Т.к. проблема не в том, что идет в trim на вход, а в том, что возвращает trim.

И эта проблема в текущем C++ не решается от слова никак, поскольку в C++ чисто сишное наследие по работе с указателями: нет в C возможности отличить валидный указатель от невалидного, нет возможности понять имеем ли мы дело с указателем на временный объект или на static-объект.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Вроде Статтер (или как его там) лет 5 назад говорил что у него готов тул, аналогичный борроучекеру, надо просто правильные аннотации рассставить.

khrundel ★★★★
()
Ответ на: комментарий от khrundel

Саттер много чего говорил: он и предложения по рефлексии продвигал (вроде как работа идет, но где эта рефлексия?), он и новый механизм исключений для C++ предлагал (вроде как даже работа приостановилась), сейчас вот он cppfront делает…

Простым же смертным приходится есть то, что есть здесь и сейчас. И еще хорошо, когда хотя бы C++17 доступен вместе с каким-нибудь gcc-9.

Так-то компиляторы со временем сами становятся достаточно умными, чтобы предупреждать о повисших ссылках в простых случаях. Но это не гарантировано.

Тут скорее на анализаторы (статические и динамические) больше надежды. Думаю, что какой-нибудь PVS-Studio такую ошибку отловит на раз-два.

eao197 ★★★★★
()
Ответ на: комментарий от Lrrr

Я говорил об этом случае выше. Да, это прямой контр-пример мусорному бреду.

Если там действительно есть вывод, то почему компилятор плачет и просит указать тип вручную?))

Его там нет - это хак. Там есть специальный кейс для +, чтобы это говно могло в перегрузку операторов. Данная ситуация - сайд-эффект.

что на самом деле там внутри сидит какая-нибудь очередная vtable, которая затирает типы и увеличивает время компиляции

В данном случае это дерьмо не работает, поэтому там ничего нет. Хак с + работает через тот самый дактайпинг.

right_security
()
Ответ на: комментарий от khrundel

Примет Раст такой код? Нет. Он скажет, что f принимает только параметры типа i32.

Удивительно то, как севший в лужу пропагандист пытается фантазировать о чём-то и порождать какие-то шизо-критерии.

Вывод: ducktyping’а в расте нет от слова совсем.

Нет такого вывода - он есть. Трейт не указан - + - работает. Это нарушает твоё нелепый трёп выше.

Аналогичный код в плюсах откомпиляется.

Не, сразу мимо. Аналогичный код на плюсах компилируется по другой причине.

И да, пропагандист, там в плюсах нет дактайпинга. О чём тебе уже выше сообщили.

У тебя галлюцинации. Трай в расте был ещё хрен знает когда, когда был оператор box вместо new и планировались зелёные потоки. Ты, видимо, его с ? перепутал.

Нет, пропагандист. Изначальной каждый раст-сектант орал о том, что пм круто. Ну так же как и ты. Потом обосрались(так же как и ты) и начали менять методички.

Очевидно, что макрос говна появился достаточно быстро - потому что это помойный макрос. Но это ничего не меняет.

Ну вот напиши мне код на расте, который с помощью from или into неявно приведёт тип, а я посмеюсь

Нет, пропагандист, инто - уже неявное преобразование типов. Твои слёзы опять мимо.

Почему ты не можешь это не писать в данном случае - тебе уже сообщили. Твоя скриптуха говно. Это никак не связано с темой.

Насчёт ::new я бы согласился, некрасиво сделали.

Т.е. ты опозорился? У тебя просто нету возможности в принципе сделать что-то. Поэтому все твои слёзы - это жалкое враньё. Т.е. наличие инто - это просто мусорный костыль, каки new.

Ведь в цпп этого говна нет. А у тебя есть. А приведения типов нет. Т.е. то на что ты ссылаешься - не имеет отношения к теме. Ты опять опозорился.

Т.е. в принципе нормально, но в условиях миграции из плюсов/жабы создаёт неверные ожидания. Нужно было ::create какой-нибудь, чтоб подчеркнуть, что это никакой не конструктор, а просто функция.

Нет, это не функция. А то, что оно функция - то просто следствие нелепости твоей скриптухи жалкой.

right_security
()
Ответ на: комментарий от khrundel

Видишь, неявные преобразования сыграли с программистом злую шутку.

Вижу эникейский понос. Какое отношение этот бездарный мусор имеет к цпп и какое отношение имеем к преобразованиям?

Также прошу обратить внимание на инициализацию строк. Какое уродство. Но плюсовики пишут так, потому что должна вырабатываться хорошая привычка обходить преобразования типов.

Какие строк, какое преобразование? Что ты несёшь. Это бездарный высер, а не код. И уж тем более раст-дерьмо в тысячи раз позорнее несмотря на то, что в цпп все литералы сишные.

const std::string_view& str - уровень бездарности того, кто писал это высер - просто поражает воображение.

Так я приводил пример где преобразования типов обосрали std::visit по std::variant<int, char>.

В твоих фантазиях там обосрался кто-то кроме тебя.

Нужен новый способ вызова функций, отключающий преобразование. Чтоб плюсовики писали какой-нибудь trim{a} или trim({a}) или trim!(a) и это бы не компилялось, потому что функция принимает стрингвью, а передают ей стринг.

Жертва пропаганды, я тебе открою тайну, но если хочешь обмазываться дерьмом - берёшь строки говна «как в расте» и там не будет никаких преобразований.

Кстати, удивительно бездарные потуги, учитывая то, что никакой into ничего не меняет.

И вот, на фоне всего этого, появляется Царь и вещает, что никакой проблемы с преобразованием типов нет и быть не может, глупости какие-то распространяемые пропагандистами.

Ну да. Ты просто рядовой пропагандист со знаниями на уровне эникея, который пытается своим невежеством спорить и усираться.

right_security
()
Ответ на: комментарий от khrundel

Кстати, по поводу сказок этого нелепого пропагандиста на тему неявных преобразований.

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

В качестве пруфа, чтобы окончательно похоронить эти жалкие потуги - можно взять ? и жалкие костыли из этого мусора. Т.е. result был настолько дерьмо и into было настолько позорным, что они впили неявные преобразования. Причём тут же не отмажешься.

https://doc.rust-lang.org/std/convert/trait.From.html - вот пруф.

Поэтому все сказки этого пропагандиста - просто настолько нелепый позорный мусор.

right_security
()
Ответ на: комментарий от khrundel

Какая vtable нахрен? Это рантаймовая структура

Нет, сразу мимо. Рантайм для раста - это всё, что после мир.

её не может быть во время компиляции. Хватит за царьком повторять его бред.

Нет, жалкий пропагандист. Она там есть. А слив на рантайм - это просто позорище.

В остальном, да, это не очень красиво.

В остальном ты сел в лужу.

Возможно это баг выводителя типов

Опять позорная херня. Никаких багов там быть не может.

а возможно сознательное решение, потому что в каких-то случаях такая лямбда с выводом приводила к ошибкам и поэтому в этом случае отключили.

Эти фантазии эникейские.

В любом случае, в расте вывод типа на 2 головы выше плюсового. Печально что не на 3, ты это хотел сказать?

Да ты чё, насколько же жалок этот пропагандист. В целом как я уже говорил - врать это то, что может делать раст-адепт. Ничего иного он делать не в состоянии.

right_security
()
Ответ на: комментарий от khrundel

А для пацанов напомню, как глушить подобных пропагандистов.

  • рантайм не является критериев. В рантайме и в жаваскрипте может не быть диспатча в рантайме. Поэтому в случае с языками есть/нет определяется семантикой, а не рантаймом.

  • вообще когда перед вами какой-то пропагандист несёт херню про рантайм - у него просто пусто в голове. Это ретранслятор пустоголовый.

  • весь тайплевел на расте происходит на уровне до мир, но мир в расте именно с vtable. Т.е. он динамический. А монорфиазация в расте - это просто ворованный хак, который там появился тогда, когда они побежали воровать ллвм. Только раст то об этом ничего не знает.

Чтобы в этом убедиться любой может пойти и посмотреть мир. Все функции там динамические.

right_security
()
Ответ на: комментарий от right_security

Не удержался. Такое позорище нужно на камнях выбивать (дабы остальным не повадно было).

Вижу эникейский понос.

бездарный мусор

бездарный высер, а не код

И таки да - ждём демонстрацию шедевров.

уровень бездарности

писал это высер

В твоих фантазиях там обосрался

Меня терзают смутные сомнения, больная тема походу.

Жертва пропаганды

Ооо, повторяемся.

я тебе открою тайну

Пионер, носитель сокровенных знаний, ага.

удивительно бездарные потуги

Если правильно считаю - четвёртый раз за пост. Лексикончик Эллочки-Людоедочки.

Ты просто рядовой пропагандист

со знаниями на уровне эникея

который пытается своим невежеством

Зациклило «людоедочку».

Спешу обратить внимание - вот это вот всё из одного (!!) поста.

ПыСы. Забаньте уже кто нибудь персонажа - мучается ведь…

bugfixer ★★★★★
()
Ответ на: комментарий от bugfixer

ПыСы. Забаньте уже кто нибудь персонажа - мучается ведь…

Он уже на грани этого, наступила стадия бешенства, когда на один коммент в свой адрес чудище порождает 3-4 портянки.

Virtuos86 ★★★★★
()
Ответ на: комментарий от right_security

Царь-балабол, ты уже свою первую работающую программу написал?

Очень уж хочется прикоснуться к творению настоящего мастера, проникнуться.

eao197 ★★★★★
()
Ответ на: комментарий от right_security

как же она побежала гадить

Попросить у программиста показать код – это уже «гадить»? Ахринеть.

Так что на счет работающих программ? Написал хоть одну уже?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Попросить у программиста показать код – это уже «гадить»? Ахринеть.

Гадить - это прибежать лизать тогда, когда тебе приказали. Ты сидел тут язык в жопу засунув, а как только тебе хозяин пинка дал - ты побежал блеять что-то. Почему не блеял ранее? Почему именно сейчас?

Холуй, ты когда в последний раз пытался мне что-то показать, плакался что ты не программист и всё что ты смог мне показать - это какое-то говно на 10 строчек, который ты впаривал лохам за 10баксов. И то под сапогом хозяина, т.е. к тебе отношения не имеет.

Так что на счет работающих программ? Написал хоть одну уже?

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

А так же мусор меня так же не интересует.

right_security
()
Ответ на: комментарий от right_security

Гадить - это прибежать лизать тогда, когда тебе приказали.

С этого места поподробнее, пожалуйста. Кто, когда, за сколько и т.д.

тебе хозяин пинка дал

А хозяин кто?

ты не программист

Я нет. А ты программист?

eao197 ★★★★★
()
5 ноября 2023 г.
Ответ на: комментарий от Siborgium

У него даже нет своего собственного компилятора

Странный тезис какой-то. Чем трансляция Rust → LLVM не является компиляцией?

И если можно взять готовый бэк, зачем делать свой? Чтобы что?

utf8nowhere ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.