Вышел Rust 1.23

Что, припекает, когда узнал, что сам - хипстер?

Что, припекает, когда узнал, что сам - хипстер?

Так у тебя и надо спросить это.

А ещё там нет наследования, сборки мусора и динамической >типизации. Убожество

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

upd. ещё конструкторов нет

Гонишь. Это же былинный отказ.

В С деструкторов нет, потому что там автоматическое управление памятью?

А в rust есть типаж Drop. В java есть метод finalize.

Гонишь. Это же былинный отказ.

Правда нету. Как без исключений возвращать ошибки из конструкторов?

Есть inherent methods без параметра self. Пример:

impl File {
   pub fn open(file_name: &str) -> Result<File, Error> { ... }
}

Ты сам-то понял, зачем это сказал?

А ты понял что я сказал?

Да. Так ты понял-то, зачем привел эту нерелевантную информацию?

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

Что за чушь? Любой вызов функции, кроме разве что inline функции, как минимум алоцирует память на стеке.

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

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

Если ты говоришь о памяти в куче, то объясни практический смысл этого твоего желания?

Работа в условиях исчерпанной или разрушенной кучи.

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

В каком месты ты увидел одержимость? Это всего лишь пример

Это единственный пример, о котором ты говоришь, причем постоянно.

Как ты можешь засунуть более одного типа в E?

Я оставлю это тебе в качестве упражнения по Rust. Намек: я не говорю о том, чтобы E был enum.

Работа в условиях исчерпанной или разрушенной кучи.

Ещё обработчики сигналов могут требовать отсутствие выделений.

кто тебе сказал что формата машины?

по другому не видел

ты знаешь на какой машине твой код будет выполняться?

зачем?

Ты бы хоть одно переполнение инта под все возможные форматы и платформы обработал в соответствии со стандартом своего любимого C - узнал бы по чём фунт лиха.

// returns true if (a+x) will overflow or underflow
int addo(int a, int x) {
    if ((x > 0) && (a > INT_MAX - x))
        return 1;
    if ((x < 0) && (a < INT_MIN - x))
        return 1;
    return 0;
}

обработал, где фунт лиха?
INT_MAX и INT_MIN из стандартного limits.h

А машиннонезависимый код ты не писал вообще никогда на этом язычке. Иначе бы не писал этой чуши.

только что написал такой код

по другому не видел

т.е. придумал сам.

зачем?

т.е. пишешь код под свой локалхост.

обработал, где фунт лиха?

1) в каждом месте реального код отработал?
2) получил хорошую производительность при этом?

только что написал такой код

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

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

маленькая поправка там должен быть 'least'

ну или парируй цитатой из стандарта C.

ISO/IEC 9899:1999 &7.18.1.2.3

The following types are required:
int_least8_t int_least16_t int_least32_t int_least64_t
uint_least8_t uint_least16_t uint_least32_t uint_least64_t
All other types of this form are optional.

нет, этого не достаточно. Таких мест где автор «думает» что может быть паника слишком много. Часть из них llvm сможет доказать как недостижимые, и реальный список будет намного короче.

Это не деструктор, это аналог finalizer-а в Java. Ничего более страшного, чем завершение программы, не произойдёт. При этом все остальные drop-ы скорее всего отработают. Например если запустить этот код:

struct DropObj1 {
    pub dobj: DropObj2
}

struct DropObj2;

impl Drop for DropObj1 {
    fn drop(&mut self) {
        println!("DropObj1: will panic in drop");
        panic!();
    }
}

impl Drop for DropObj2 {
    fn drop(&mut self) {
        println!("DropObj2: will not panic in drop")
    }
}

fn main() {
    DropObj1 { dobj: DropObj2 };
    println!("Finishing program normally");
}

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

Но я понял о чём ты. i32 в расте - это 32 разряда. А int_least32_t - это «от 32 разрядов».

Продакшон чуток потестил, чтоб не падал совсем уж часто и норм. Да и чего ему падать, ГЦ же. А в поганом расте нужно с компилятором договариваться и каждое изменение отражать.

что ты сам не знаешь есть у тебя паника тут или нет.

Ты знаешь, что автор кода считает ее возможной. Этого достаточно.

нет, этого не достаточно

Совершенно очевидно, что таким образом все паники будут помечены, поэтому и сказано «достаточно» (не «минимально необходимо», а «достаточно»). Если ты считаешь по-другому - обоснуй.

Таких мест где автор «думает» что может быть паника слишком много.

Ты их считал?

Часть из них llvm сможет доказать как недостижимые, и реальный список будет намного короче.

И что? Продолжи свою мысль. В частности, объясни вот это:

pftBest> Нет, нельзя, потому что ты сам не знаешь есть у тебя паника тут или нет.

Интересует «нельзя» - это значит, что лично ты запрещаешь? Или существуют какие-то технические основания, которые это запрещают?

В С деструкторов нет, потому что там автоматическое управление памятью?

Для непонятливых мне надо было написать «общее свойство объектно-ориентированных языков с автоматическим управлением памяти».

В java есть метод finalize.

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

Почему не деструктор? С каким деструктором вы сравниваете?

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

переполнения флоатов в кастах и арифметке в вашем чудо-языке как раз таки UB.
А в C есть возможность вляить на поведение при ошибках с флоатами, обрабатывать как сигналы и настраивать их округление. Конечно эта витча опциональна, не на всех микроконтроллерах это возможно, но в пост-юниксах работает. см. fenv.h

сначала приятно пробрасывать исключения вверх стеку, потом приятно перевыбрасывать исключения из обработчика исключений, потом приятно выбрасывать исключения из конструктора, а потом приятно долбиться в дымоход с таким же любителем приятных особенностей. следи за собой, будь осторожен.
anonymous (05.01.2018 19:39:17)

на какой ты уже стадии? что следующее по списку?

Как без исключений возвращать ошибки из конструкторов?

так же как и из любой другой функции, вторым аргументом.

желаю вам с ox55ff любви и счастья.

Почему не деструктор? С каким деструктором вы сравниваете?

Потому что в JVM освобождение памяти от других объектов, на которые ссылается данный объект, от метода finalize() не зависит. Полагаю, что в случае с drop всё так же. По этой же причине программисты на Java не боятся бросать исключения в конструкторе, чего не любят делать программисты на C++.

на какой ты уже стадии?

Ни на какой. Мань, ты не до конца протрезвел? Не проецируй на меня свои пристрастия.

так же как и из любой другой функции, вторым аргументом.

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

Насколько я знаю, drop работает так же, как и в C++. Разве что у его можно «отключить» через mem::forget.

получил хорошую производительность при этом?

ну мой пример конечно не идеально в плане производительности работает, но можно воспользоваться GNU C расширением и получить нативную проверку на каждой архитектуре взамен на совместимость только с gcc и clang но это всёрано охватывает больше платформ чем rustc

Главное потом не забыть этот зомби-объект уничтожить.

сборщик мусора для этого нужен. все гости собрались, давайте уже, когда у вас свадьба.

переполнения флоатов в кастах и арифметке в вашем чудо-языке как раз таки UB.

А в вашем э то определено на уровне языка? Можно ссылку?

А в C есть возможность вляить на поведение при ошибках с флоатами

Прямо как в Rust.

Хорошо, приведу пример. Вот смотришь ты на такую строку в коде:

    let x = a[b];

Будет тут паника или нет? может и быть а может и нет. Если анализировать только пометки в сигнатурах функций и операторов, то точно есть. Но на самом деле это будет бесполезным ложным срабатыванием если выше по коду есть проверка:

    if b >= a.len() {
        return Err(());
    }
    let x = a[b];

Тут уже никакой паники не будет, но доказать это сможет только сам llvm при оптимизации.

А если бы я хотел чтобы паники тут не было, но ошибся, и написал > вместо >= то я бы «думал» что паники не будет, но на самом деле она есть, и llvm знает об этом, а человек нет. Именно это я и имел в виду.

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

Будет тут паника или нет?

Это неважно. Функция должна быть помечена как потенциально паникующая.

Да. Так ты понял-то, зачем привел эту нерелевантную информацию?

Значит ты не понял. Ты написал: «Исключение можно перехватить всегда, панику - зависит». Вот про это «зависит» я и написал. Кстати, на сколько я понимаю, панику в Rust тоже можно перехватить:
https://doc.rust-lang.org/std/panic/fn.set_hook.html

Когда говорят «закончится память», очень редко имеют в виду стек.

Иметь в виду могут что угодно. Например в JVM может закончиться память PermGen.

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

Что ты собираешься делать с такими помечеными функциями из стандартной библиотеки? Метить все функции, которые их вызывают. Я насчитал там 517 мест, где panic! вызывается явно. Подумай, почему java.lang.Error, java.lang.RuntimeException и их наследники в Java относятся к unchecked.

Работа в условиях исчерпанной или разрушенной кучи.

Разве в этом случае работа вообще возможна?

Это единственный пример, о котором ты говоришь, причем постоянно.

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

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

Ты написал про Java, которая к разговору вообще отношения не имеет.

Панику в Rust тоже можно перехватить:

Можно. Если есть поддержка в рантайм-библиотеке и ты не собрал программу с panic=abort. Вот именно поэтому и «зависит». С чего ты начал притягивать Java - даже ты не знаешь.

Я насчитал там 517 мест, где panic! вызывается явно

И?

Работа в условиях исчерпанной или разрушенной кучи.

Разве в этом случае работа вообще возможна?

Да, конечно. А если ты не считаешь отправку сообщения о фатальном сбое работой - это твоя проблема.

Вообще-то примеры должен был давать тот, кто хочет помечать функции с возможной паникой

Тебе дали как минимум 3 примера.

А в вашем э то определено на уровне языка?

в C нет

Прямо как в Rust.

не нашёл это в std.

Насколько я знаю, drop работает так же, как и в C++. Разве что у его можно «отключить» через mem::forget.

Он работает так, как ты его напишешь. Но поскольку автоматического управления памятью в C++ нет, от реализации деструкторов в C++ зависит и управление памятью. А вот в языках с автоматическим управлением памятью такой зависимости нет. Метод finalize() если и нужен, то совсем для другого и рассматривать его как аналог деструктора совершенно неправильно. Не вижу как drop в Rust может отличаться от finalize() в Java.

А в вашем э то определено на уровне языка?

в C нет

Т.е. тоже UB.

не нашёл это в std.

Это левый крейт: http://mahkoh.github.io/posix/doc/posix/fenv/index.html

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

А что, уже есть такой синтаксис в языке?

Функция должна быть помечена как потенциально паникующая.

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

Я хочу иметь совсем другой инструмент, нужно получить список только тех функций где на самом деле есть паника, а не «потенциально», и те которые доказать нельзя, но с существованием которых я согласен, добавить в белый список и следить чтобы при написании кода не появлялись новые.

Можно. Если есть поддержка в рантайм-библиотеке и ты не собрал программу с panic=abort. Вот именно поэтому и «зависит». С чего ты начал притягивать Java - даже ты не знаешь.

Поддержка уже есть в стандартной библиотеке. Если ты собираешь с panic=abort, то что тебе дадут твои метки? Java я никуда не притягивал, а использовал для сравнения.

> Я насчитал там 517 мест, где panic! вызывается явно
И?

И что ты собрался делать с метками в этих местах? Рекурсивно метить все остальные функции, которые их вызывают?

Да, конечно. А если ты не считаешь отправку сообщения о фатальном сбое работой - это твоя проблема.

У тебя и так есть это сообщение от panic. Какую ещё работу ты хочешь сделать? Переслать стактрейс на email при помощи фатально умирающей программы?

Поддержка уже есть в стандартной библиотеке.

Где-то есть, где-то нет.

Если ты собираешь с panic=abort, то что тебе дадут твои метки?

Моя программа не завершится там, где мне это не нужно.

Java я никуда не притягивал, а использовал для сравнения.

Никто не просил тебя о сравнении, особенно таком бессмысленном.

Да, конечно. А если ты не считаешь отправку сообщения о фатальном сбое работой - это твоя проблема.

У тебя и так есть это сообщение от panic.

А что, panic отправляет сообщение по сети серверу статистики?

Переслать стактрейс на email при помощи фатально умирающей программы?

Примерно так, да. Ты запрещаешь?

При чём тут java? Что такого можно сделать в деструкторе в C++, чего нельзя в Rust?

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

А что, уже есть такой синтаксис в языке?

Так проблема в этом, а не в оптимизации LLVM?

Функция должна быть помечена как потенциально паникующая.

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

Не получится. В местах, где паника недопустима, будет использоваться не foo, а foo.get(i).

Я хочу иметь совсем другой инструмент, нужно получить список только тех функций где на самом деле есть паника

Следи за предупреждениями компилятора о недостижимом коде.

Где-то есть, где-то нет.

Про что ты сейчас говоришь? std::panic::set_hook есть везде, где есть Rust не ниже 1.10

Моя программа не завершится там, где мне это не нужно.

Тоесть на самом деле ты не хочешь panic=abort

Никто не просил тебя о сравнении, особенно таком бессмысленном.

Тебя тоже никто не просил предлагать совершенно бессмысленную идею о метке функций с возможным вызовом panic.

А что, panic отправляет сообщение по сети серверу статистики?
Примерно так, да. Ты запрещаешь?

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

При чём тут java?

При том, что там тоже автоматическое управление памятью.

Что такого можно сделать в деструкторе в C++, чего нельзя в Rust?

В drop нельзя вручную управлять памятью, это же очевидно.

Где-то есть, где-то нет.

Про что ты сейчас говоришь?

Про рантайм-поддержку.

std::panic::set_hook есть везде, где есть Rust не ниже 1.10

Ты точно читал документацию? «the hook will run with both the aborting and unwinding runtimes», а потом программа завершится, если у тебя aborting runtime.

Моя программа не завершится там, где мне это не нужно.

Тоесть на самом деле ты не хочешь panic=abort

То есть я хочу, чтобы программа не зависела от panic=xxx

Ты запрещаешь?

Да

Ты не можешь никому ничего запретить.

В drop нельзя вручную управлять памятью, это же очевидно.

Ты снова что-то запрещаешь?

То есть я хочу, чтобы программа не зависела от panic=xxx

Тебе кто-то запрещает использовать что-то другое, кроме abort?

Ты не можешь никому ничего запретить.

Разумеется, физически не могу. Я просто считаю архитектурно глупые решения глупыми и стараюсь их избегать

> В drop нельзя вручную управлять памятью, это же очевидно.

Ты снова что-то запрещаешь?

Расскажи мне про ручное управление памятью в Rust.

Тебе кто-то запрещает использовать что-то другое, кроме abort?

Почему ты считаешь, что я пишу программу исключительно для себя? Почему ты считаешь, что на целевой платформе уже реализован unwinding runtime?

Я просто считаю архитектурно глупые решения глупыми

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

Почему ты считаешь, что на целевой платформе уже реализован unwinding runtime?

На какой не реализован?

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

Судя по тому, что аргументы у тебя закончились и ты банально перешёл на личности, я таки прав. Но всё таки, ты так и не ответил, что ты собрался делать с метками функций с panic из стандартной библиотеки?

Расскажи мне про ручное управление памятью в Rust.

https://doc.rust-lang.org/1.15.0/alloc/heap/fn.allocate.html

Судя по тому, что аргументы у тебя закончились и ты банально перешёл на личности

После тебя

я таки прав

Ты только считаешь, что прав.

ты так и не ответил, что ты собрался делать с метками функций с panic из стандартной библиотеки?

tailgunner> В местах, где паника недопустима, будет использоваться не foo, а foo.get(i).

При том, что там тоже автоматическое управление памятью.
тоже

У Rust не автоматическое.

В drop нельзя вручную управлять памятью, это же очевидно.

С чего бы это вдруг? А Arc/Rc по вашему как работают?

Расскажи мне про ручное управление памятью в Rust.

https://doc.rust-lang.org/1.15.0/alloc/heap/fn.allocate.html

Ну и какое отношение это имеет к drop? Ты бы ещё new в Java ручным управлением памяти назвал.

После тебя Ты только считаешь, что прав.

Значит что делать с твоими метками функций с panic ты так и не расскажешь? А я так ждал, мне было так интересно.