История изменений

Исправление khrundel, 20.10.22 12:55 (текущая версия) :

Нет, корректность программы определяется именно компилятором. Если программа делает не то, что ты от нее ждешь – это твои проблемы, ты не знаешь языка.

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

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

Как не привёл? Я тебе вот прямо в прошлой ссылку давал. Ресолв урла через СУБД. У тебя мозги вообще не пашут?

Что характерно, именно избегая auto&& ты заложил мину с int и char.

Нет, тупица. Если написать auto&& ты, условно, получишь сообщения от компилятора в 0-50% случаев отсутствия ветки, в зависимости от того, что ты в эту ветку запишешь. Если не напишешь - получишь в 90%. До 100% ты не доведёшь никогда в виду особенностей приведения типа плюсов. Поэтому написание auto&& ситуацию ухудшает.

Мразь в очередной раз пытается проигнорировать сообщение

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

Цитату, ссылку на сообщение, где я делаю дефолтную ветку в матче. Сейчас увидим, насколько ты бездарен.

[](auto &&){} - - это и есть дефолтная ветка, тупица.

В принципе, на этом можно заканчивать – все ясно.А знаешь, почему не передаются? Потому что это не скейлится.

Нет, дебил ты конченый. Ещё раз, для тупых: в той же библиотеке джавы, ссылку на которую я дал как на самый конченый в плане любви к объектам язык, линия рисуется вызовом drawLine и параметрами x,y,x2,y2. Хочешь прямоугольник со скруглёнными углами - drawRoundRect(int x, int y, int width, int height, int arcWidth, int arcHeight). Для добавления другого примитива, авторы либы должны были бы писать новый метод drawXXX. И заметь, никакого draw(Shape shape) в этой библиотеке нет. Так устроены графические библиотеки, пока можно, они принимают простые команды, если уже нельзя - принимают сложные графические пути или модели. Вся эта срань типа class circle implements shape - её оставляют пользовательскому коду.

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

Смотрим, как он блеял о том, что до std::variant в С++ не было вариантов.

Так и не было. Говорю же тебе, клоун, буст не в счёт. Вообще. Садись, клоун, двойка, твой ответ не принимается.

Что характерно, с самого появления плюсов люди пилили свои реализации динамических массивов с реаллокацией, иногда под конкретные типы, иногда обобщённые. И все нормальные люди описывали ситуацию: «в C++ нет динамических массивов с реаллокацией, однако язык позволяет их реализовать». Потом появилась STL и ситуация сменилась на «В стандартной библиотеке плюсов есть std::vector, являющийся динамическим массивом с реаллокацией». Но почему-то для варианта вдруг должно быть по другому, вдруг факт наличия какой-то черезжопной реализации (когда не было трюка с overloaded) где-то на сайте у Васяна, которая ещё не факт что твоим компилятором подхватится, начал означать, что вариант в плюсах был ещё в нулевых.

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

Не позорься. Символьные литералы к типу char отношения не имеют.

У тебя новая версия объяснения, почему тот код скомпилялся? Зря. Я ведь, тебе, чучелу, демонстрировал, что std::variant<int,char> = 'a'; выбирает именно char-ветку в случае её наличия в visitor. Так что символьный литерал - это именно char. Ты, видимо, с K&R C спутал.

Это буквально одно и то же. Разница лишь в том, что компилятор не навязывает выполнение проверки на ошибку.

Нет, чучело ты тупое.

вот тебе код на go:

message, err := foo();
fmt.Println(message);

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

Или, более реалистичный

message2, err2 := foo();
if err != nil {
  fmt.Println(message2);
}

Ты уже написал 10^2 реализаций для Add? Там еще Mul и Div на очереди

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

Проект в неподдерживаемом состоянии после тебя. Достаточно посмотреть на ветку match, которая там осталась после добавления обработчика Uuid, делающего ее недостижимой.

Я бы принял эту попытку свалить вину на предшественника если бы ты сам не вещал тут о необходимости auto&& веток. Я действовал в соответствии с предлагаемым тобой же методом, чтоб продемонстрировать этого метода ущербность. Если до тебя дошло наконец, что auto&& ветка - это зло, ну что ж, поздравляю тебя.

Кроме того, та ветка могла бы остаться и по иным причинам. Вполне возможно, что в варианте есть ещё какие-то способы идентификации, которые раньше обрабатывались общей с guid веткой, потом для guid сделали оптимизированную, а старую оставили для вот них. В любом случае, обработчик «для всего» - это зло. Если лень копипастить строчки, требуй синтаксиса вида [](A&|B&|C& value){ dbaccessor.get_data(val);}.

Ты ничего не ответил и слился, а далее при напоминаниях игнорировал.

Прочитал. Теперь хотя бы понимаю, почему ты, тупица, своё СВИНАЕ вспомнил.

Что я скажу: хрень там полная и дрочево на костыли из плюсов. СВИНАЕ в расте вообще невозможен, в виду наличия нормальных дженериков. ADL… Знаешь, давай представим что это вот реально та самая сложная штука, из-за которой авторы Раст сломались, плюнули и сказали что не будут оверлоады делать. Могли бы они обойтись без неё?

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

Видишь, очередная твоя надежда оказалась просто твоей тупостью и непониманием, отчего в плюсах всё так сложно. Ответ прост: потому что изначально сделано через жопу.

Ещё раз, для тупых, оверлоады в расте есть. Они используются для определения дженерика.

trait Fooable<T> {
    fn foo(&self, a: T);
}
impl Fooable<i32> for i32 {
    fn foo(&self, a:i32){
        println!("i32 foo called")
    }
}
impl Fooable<f32> for i32 {
    fn foo(&self, a:f32){
        println!("f32 foo called")
    }
}
...
    1.foo(1f32);
    1.foo(1);

Заметь, это не дженерик функция, это разные функции, с разным кодом, и раст их легко различает.

С другой стороны, если ты добавишь:

trait Fooable2 {
    fn foo(&self);
}
impl Fooable2 for i32 {
    fn foo(&self) {
        
    }
}

то вызов 1.foo(1) перестанет компиляться и будет жаловаться на наличие 2х разных foo и требовать от тебя пояснения. Не смотря на разное число параметров. Так что мы видим сознательное решение по отключению перегрузки. Если одинаковые имена появились в виду наличия дженерика - раст соизволит найти нужную реализацию на основании параметров. Если они появились от того что случайно совпало, то раст отключает механизм перегрузки и требует написать Fooable::foo(&1, 1);

Исходная версия khrundel, 20.10.22 12:45: