История изменений
Исправление Siborgium, (текущая версия) :
Отвечу вкратце на остальный бред.
Для добавления другого примитива, авторы либы должны были бы писать новый метод 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, :
Отвечу вкратце на остальный бред.
Для добавления другого примитива, авторы либы должны были бы писать новый метод 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.
И это уже скейлится. Худо-бедно, но скейлится, мысль о чем я тебе многократно пытался донести.