LINUX.ORG.RU

Rust 1.13

 


4

10

Представлен релиз Rust 1.13 — системного языка программирования, нацеленного на безопасную работу с памятью, скорость и параллельное выполнение кода. В этот релиз вошли 1448 патчей.

Этот сезон оказался очень плодотворным для Rust. Проведены конференции RustConf, RustFest и Rust Belt Rust. Обсуждено будущее языка, разработан план на 2017 год и созданы новые инструменты.

Новое в 1.13

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

Cargo в этом релизе содержит важные обновления безопасности, связанные с зависимостями от curl и OpenSSL, для которых также недавно были опубликованы обновления безопасности. Подробную информацию можно найти в соответствующих источниках для curl 7.51.0 и OpenSSL 1.0.2j.

Оператор ?

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

fn read_username_from_file() -> Result<String, io::Error> {
    let f = File::open("username.txt");

    let mut f = match f {
        Ok(file) => file,
        Err(e) => return Err(e),
    };

    let mut s = String::new();

    match f.read_to_string(&mut s) {
        Ok(_) => Ok(s),
        Err(e) => Err(e),
    }
}

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

С оператором ?, вышестоящий код выглядит следующим образом:

fn read_username_from_file() -> Result<String, io::Error> {
    let mut f = File::open("username.txt")?;
    let mut s = String::new();

    f.read_to_string(&mut s)?;

    Ok(s)
}

Оператор ? заменяет весь код обработки ошибок, написанный при помощи оператора match ранее. Иными словами, ? применяется к значению Result, и если оно равно Ok, разворачивает его и отдаёт вложенное значение; если это Err, то происходит возврат из функции, в которой вы находитесь.

Более опытные пользователи могут заметить, что этот оператор делает то же самое, что и макрос try!, который доступен начиная с Rust 1.0. И будут правы, в самом деле, это то же самое. До 1.13 read_username_from_file можно было бы написать следующим образом:

fn read_username_from_file() -> Result<String, io::Error> {
    let mut f = try!(File::open("username.txt"));
    let mut s = String::new();

    try!(f.read_to_string(&mut s));

    Ok(s)
}

Так зачем надо было расширять язык, если до этого уже был такой макрос? Есть несколько причин. Во-первых, try! доказал своё огромное значение и часто используется в идеоматичном Rust. Он используется так часто, что было принято решение о создании собственного «подслащенного» синтаксиса для него. Такой вид эволюции — одно из преимуществ мощной системы макросов: расширения к синтаксису языка можно добавлять через прототипирование без внесения изменений в сам язык и особо полезные макросы могут указать на недостающие возможности языка. Эволюция try! в ? — яркий пример этого.

Другая причина — восприятие нескольких последовательных вызовов try!:

try!(try!(try!(foo()).bar()).baz())
против
foo()?.bar()?.baz()?

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

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

Более подробно об операторе ? можно прочитать в RFC 243.

Улучшение производительности

В последнее время очень много внимания заострено на производительности компилятора. Mark Simulacrum и Nick Cameron произвели улучшения http://perf.rust-lang.org/, инструмента для отслеживания производительности компилятора, на котором периодически запускается набор rustc-benchmarks на выделенном оборудовании. Инструмент записывает результаты каждого прохода компилятора и позволяет находить и отслеживать код, приведший к регрессии. Например, при помощи этого инструмента можно посмотреть график производительности за весь цикл разработки релиза 1.13, где можно увидеть заметное сокращение времени работы компилятора, отдельно представленное на соответствующей странице со статистикой.

Большое улучшение на графике от 1 сентября связано с оптимизацией от Niko по кешированию нормализованных проекций во время преобразования. То есть во время генерации промежуточного представления LLVM компилятор больше не пересчитывает каждый раз конкретные экземпляры связанных типов, когда они необходимы, а использует ранее вычисленные значения. Несмотря на то, что данная оптимизация не влияет на всю кодовую базу, для некоторого кода с определенным шаблоном, например, futures-rs, ускорение сборки в режиме отладки достигает 40%.

Другая оптимизация от Michael Woerister уменьшает время компиляции библиотек, экспортирующих множество встраиваемых функций. Когда функция помечена как «#[inline]», в дополнение к преобразованию этой функции в текущей библиотеке компилятор сохраняет её представление MIR и преобразует функцию в представление LLVM в каждой библиотеке, которая вызывает её. Оптимизация, сделанная Michael Woerister, позволяет компилятору избегать предварительных преобразований кода встраиваемых функций в библиотеках, в которых они определены, до их непосредственного прямого вызова. Таким образом, компилятор избавляется от необходимости выполнения лишних шагов по преобразованию функции в промежуточное представление LLVM, оптимизации LLVM и преобразования функции в машинный код.

В некоторых случаях это приводит к впечатляющим результатам. Например, время сборки библиотеки ndarray уменьшилось на 50%, а библиотека winapi 0.3 (ещё не опубликована) полностью избавилась от шага генерации машинного кода.

Но это ещё не всё: Nick Nethercote обратил своё внимание на производительность компилятора, сконцентрировавшись на профилировании и микрооптимизациях. Этот релиз включает в себя некоторые плоды его работ, ещё больше ожидается в 1.14.

Другие заметные изменения

Макросы теперь можно использовать на позиции типов (RFC 873), а атрибуты могут быть применены к операторам (RFC 16):

// Use a macro to name a type
macro_rules! Tuple {
    { $A:ty,$B:ty } => { ($A, $B) }
}

let x: Tuple!(i32, i32) = (1, 2);

// Apply a lint attribute to a single statement
#[allow(uppercase_variable)]
let BAD_STYLE = List::new();

Были удалены встраиваемые флаги сброса. Раньше при условном перемещении компилятор встраивал «флаг сброса» в структуру (увеличивая его размер), чтобы отслеживать, когда надо его сбросить. Из-за этого некоторые структуры занимали больше места, что мешало передаче типов с деструкторами поверх FFI. Благодаря тому, что в версии 1.12 добавлен MIR, появилась основа для многих улучшений, включая удаление встраиваемых флагов сброса. Теперь флаги сброса хранятся в дополнительном слоте в стеке тех функций, которым они нужны.

Релиз 1.13 содержит серьёзную ошибку в генерации кода для ARM с аппаратной реализацией чисел с плавающей точкой. Поскольку 1.13 содержит исправление безопасности, пользователям ARM рекомендуется использовать бета-версии 1.14, в которых скоро появится исправление для ARM.

Стабилизация языка

Стабилизация библиотек

Возможности Cargo

Более детальный список изменений доступен по ссылке: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1130-2016-1...

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: cetjs2 (всего исправлений: 5)

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

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

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

Тогда можно как-то так:

impl T for S {
    fn qux(&self) { /* не делегируем, новая реализация */ }
    foo_0, foo_1, foo_2: use S.a;
    bar: use S.b;
}
Даже немного гибче получается.

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

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

Как по мне, это как раз и есть «достаточно сложно».

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

Я имел ввиду, что еще на этапе рассмотрения rfc эту идею выкинут на помойку. Что сейчас и происходит.

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

Не будем забывать, что раст разрабатывают уже 10(8) лет, большую часть из которых это был исследовательский проект.

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

Что сейчас и происходит.

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

Но как только дело доходит до реализации, оказывается что всё не так радужно и текущий вариант совершенно обоснован.

Вот только аргументов от тебя, кроме как «это мне не нужно» не было. Что характерно, по ссылкам аргументы куда более состоятельные.

Не будем забывать, что раст разрабатывают уже 10(8) лет, большую часть из которых это был исследовательский проект.

И что это значит?

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

Сообщество
• Это просто сборище «няшек». Вам не позволено неконструктивно критиковать Rust (и, очевидно, что высказывание «концепция, лежащая в основе этого языка, настолько неправильная, что он никогда не может быть исправлен» здесь не пройдёт), но вам одновременно также запрещается называть другие языки за безнадёжно низкое качество.

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

А какие у меня могут быть аргументы? Я не спец в разработке языков.

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

В комментариях как раз проскакивали мысли о том, что оно-то особо и не нужно:

Besides, if a hypothetical IDE like this existed, it could just write the delegation code as well, making this entire RFC kind of pointless.

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

Лол.

borrowck отвергает безопасный код.

«я крутой сишник и я знаю что я делаю»... бам https://cve.mitre.org/index.html

У Rust есть исключения.

Приехали.

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

Шок. Раст не серебряная пуля.

+ куча нытья и вкусовщины по поводу синтаксиса.

Большинство думает, что Rust имеет два типа строк (и это непохоже на С++, где имеется один хороший тип и один тип, унаследованный от С

Ору!

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

You're not allowed to criticize Rust without being constructive (and apparently «the concept behind the language is so wrong that it can never be fixed» isn't), but you're simultaneously not allowed to call other languages out for irreparably sucking either. I hope you're good at doublethink, because you're gonna have to get used to the idea that Rust needs web frameworks and simultaneously is not competing with Java!

Так лучше, перевод кривоват.

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

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

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

Это я сектант? Лол.

PS: статья забавная, поржал. Особенно с унылого перевода.

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

Я не изменил своего мнения, статейка дерьмовая, анончик

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

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

\d .s

A:(_ci 97+!26;_ci 48+!10)

set:{:[eq1[x;y;z," "];def[x;y;1_ z];_n~r:. z;0;r]}
 eq1:{.[x;`W;:;:[r:"="=*z;();y]];r}
 def:{:[""~z;clr[x;y;x .`Z,y];prs[x;y;z]];.[x;`V;,;,y];0}
  clr:{(`X`Y`Z,\:y).[x;;:;]'(;;());{.[x;`ZZ,z;_dv;y]}[;y]/[x;z]}
  prs:{(`X`Y,\:y).[x;;:;]'(z;,/spl[x;y]'(&1>':z _lin"._`\"",*A)_ z)}
   spl:{:[~(*z)_in*A;z;,/@[(0,(z _lin,/A)?0)_ z;0;nam[x;y]]]}
    nam:{:[""~*|r:(0,(z _lin*|A)?1)_ z;vec[x;y;*r];sca[x;y;r]]}
     sca:{".s.get[_d;",(5:dep[x;y;z]),"]"}
     vec:{"(.s.get[_d]'",(5:dep[x;y]'(z{(x;y)}/:$!x`N)_dv$y),")"}
      dep:{cyc[x;y;r:(`;0)$z];.[x;`Z,y;,;,r];.[x;`ZZ,r;,;,y];r}
       cyc:{if[y _in(,z),don[x;x .`Z,z];'"cycle!"]}
        don:{:[()~y;y;y,,/x _f/:x{x .`Z,y}/:y]}

act:{inv[x;y]'x .`ZZ,y;x get/:x`V}
 inv:{if[~z _in y,x`V;.[x;`V;,;,z];_f[x;y,,z]'x .`ZZ,z]}
 get:{:[~y _in _dv/x`V`W;x .`T,y;dat[x;y]]}
  dat:{r::[@x .`X,y;x .`T,y;. x .`Y,y];.[x;`T,y;:;r];.[x;`V;_dv;y];r}

fd0:{,(`N_;!x;.+(`e`f`l;(0;-8$;"")))}
fds:{(y;x#0;.+(`f`g`fg`bg;`.s.f`.s.g`.s.fg`.s.bg))}
 f:{:[x~0;8#" ";$x]}
 g:{set[dr _d;cl[_v;_i];x]}
 fg:{:[@(d:dr _d).`X,i:cl[_v;_i];0;i~d`W;990000;99]}
 bg:{:[-3=4:x;808080]}
  cl:{(`$1_*|(&"."=v)_ v:$x;*y)}
  dr:{`$(- 1+(|v)?".")_ v:$x}

\d .S

C:`$/:*.s.A
N:100
T..d:"..s.fd0[N],N .s.fds/:C"
T..t:".s.act[_d;_i];"
X..d:Y..d:".+(C;(#C)#,N#_n)"
Z..d:ZZ..d:".+(C;(#C)#,N#,())"
V..d:W..d:"C;N;()"

\d ~
c:`form
a:`T
x:95
y:30
anonymous
()
Ответ на: комментарий от anonymous

этот эксель проще.

/ arthur whitney 1995
/ N, fg, l, and k added sa 11.4.2004

s..t:".[`d;(;);{. y};s[]];s[.;`f]:9$d[]"				/ trigger: re-evaluate data, screen
s:d:.+(`N,`$'_ci 97+!26;(,$!99),26 99#,"")				/ initialize data, screen
s[`N.;`e`l]:0,`								/ first column nameless, cannot be edited
s[.;`fg]:{99*~&/x _lin,/".",$!10}					/ formula foreground = blue
.[`s;(.;`k);:[;".k.s..l:((2$*|$_v),-3$*_i),$_v ._i"]];			/ click to display formula as label
s.[`x`y`l]:65 20,`							/ initial size, no label
`show$`s;

\

S..t:".[`D;(;);{. y};S[]];S[.;`f]:9$D[]"
S:D:.+(`$'_ci 97+!26;26 99#,"");`show$`S
anonymous
()
Ответ на: комментарий от RazrFalcon

А какие у меня могут быть аргументы? Я не спец в разработке языков.

При этом аргументы в духе «нафиг не нужно» себе позволяешь.

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

Или ещё не пришли к лучшему решению. Или руки не дошли. Или...

Besides, if a hypothetical IDE like this existed, it could just write the delegation code as well, making this entire RFC kind of pointless.

Странный аргумент. Тогда и derive не нужны - IDE может и эту ерунду генерировать. Более того, желание избежать разных неявностей сильно повлияло на дизайн раста: может и от этого откажемся? Ведь (некая идеальная) IDE помогает разобраться во всяких перегрузках, специализациях, виртуальных функциях, макросах и т.д.

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

Нет, но кавычки в ЯП принято использовать парами для строк и символов

Кстати, кавычки и в плюсах применяются и совсем не обязательно парно::

1'000'000'000

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

Кстати, кавычки и в плюсах применяются и совсем не обязательно парно::

По желанию. И желающих, мне кажется, будет немного.

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

Или:

match n {
    0...99 => println("1"),
    100...199 => println("2"),
    200...299 => println("3"),
    _ => println("4"),
}

с полпинка:

  int nn=n/100;
  putchar( 0<nn && nn<4 ? '0'+nn : '4' );
  putchar( '\n' );

или если бы ты все же догадался заменить 1 на one,... то:

switch(n/100) {
    case 0:  printf("less than one hundred\n");    break;
    case 1:  printf("less than two hundreds\n");   break;
    case 2:  printf("less than three hundreds\n"); break;
    default: printf("i do not know\n");            break;
}

так что переделывай свой пример (т.к. свитч в плюсах все же барахло)

кстати: как там в расте с оптимизацией match? сможет он из твоего примера сгенерить мой c putchar ? (сам по себе putchar возможно не эффективен, его вставлять вместо printf не обязательно — речь шла об оптимизации n/100 и в том же духе)

А. нет никаких оптимизаций?

В. не глядя жри что дает компилятор, и радуйся?

С. есть что-то типа EXPLAIN в SQL?

D. свои оптимизации для match?

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

Лол. Ну вы даёте. Это же просто пример был. Завтра я захочу -100...100, 133...166, etc и ваш вариант канет в Лету, а мой продолжит работать.

Ответ на ваш идиотский вопрос: B. Оно и так работает достаточно быстро. ASM листинги мне некогда читать.

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

Лол. Ну вы даёте. Это же просто пример был. Завтра я захочу -100...100, 133...166, etc и ваш вариант канет в Лету, а мой продолжит работать.

ты на чем пишешь? на 1с что ли?

тогда просвещайся: программисты на с и с++ могут ради скорости не только выбрать мой вариант (несмотря на то, что он может кануть в лету), но и — сюрприз! — даже ассемблерные вставки делать, которые редактировать еще затратнее, чем мой вариант

если в языке класса с и с++ (а мы обсуждаем раст явно с этой точки зрения) предлагается какая-то конструкция (в данном случае match), то крайне желательно, чтобы у нее было нулевое abstraction penalty ну по крайней мере в типовых частных случаях

Ответ на ваш идиотский вопрос:

почему ты считаешь его идиотским?

Оно и так работает достаточно быстро. ASM листинги мне некогда читать.

я правильно понял, что ты выяснил, что оно работает достаточно быстро, не читая ASM листингов?

тогда, кстати, как ты различаешь ответы А и В?

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

в С++ подобную штуку стоило бы ввести. на аппаратном уровне это делается например на х86 через флаг cf, например так:

а ты уверен, что:

1. cf больше никому не нужен?

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от shkolnick-kun

Я смотрю, у вас тут очень теплая обстановка.

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

да, кстати: а ты тут устраиваешь че-то вроде детского сада в виде «не буду есть РАСТишку!!!!111», в то время как взрослый человек приходит в РАСТоран и спрашивает: «а что у вас есть такого, ну, скажем, холодненького и остренького?»

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

взрослый человек приходит в РАСТоран и спрашивает: «а что у вас есть такого, ну, скажем, холодненького и остренького?»

Ты как будто специально намекаешь на анекдот...

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

cf никому не нужен, инфа 100%. на других архитектурах наверно можно по другому

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

ты на чем пишешь? на 1с что ли?

Аргумент вида: нет в сишке - значит не нужно, меня не интересует.

могут ради скорости не только выбрать мой вариант

О да. Мифичиская сила сишки. Любой код на сишке заведомо быстрее всего на свете. Бла-бла-бла.

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

почему ты считаешь его идиотским?

Потому, что вы не поняли пример.

работает достаточно быстро, не читая ASM листингов?

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

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

Ну если очень хочется...

Хочется паттерн-матчинга, а не case ranges.

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

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

Это поделка из серии «хочу винегрет из С++, Python и Cyclone».

не буду есть РАСТишку!!!!111

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

вроде детского сада

Но мне её пытаются агрессивно впарить в духе.

«Кушай, маленький, ты просто не понимаешь, насколько наша растишка полезная».

взрослый человек приходит в РАСТоран

В глубоком имбеде мне вполне хватает двух опасных бритв: Оккама и Си.

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

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

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

Поклонник Hacker's Delight штоле?

программисты на с и с++ могут ради скорости не только выбрать мой вариант ..., но и — сюрприз! — даже ассемблерные вставки делать

Сюрприз! Растаманы это могут тоже. Но у них есть выбор, в отличие от.

я правильно понял, что ты выяснил, что оно работает достаточно быстро, не читая ASM листингов?

Ты, наверно, все нюансы компиляции switch в си изучил?

anonymous
()
Ответ на: комментарий от shkolnick-kun

я уже взрослый дядя. Давно не делаю ошибок, от которых хотят меня «избавить»

Ахаха, о вау. Такой взрослый.

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

В одном случае не хватало теста на null pointer dereference, в другом - утечка события.

Ты хоть комментарии к коммитам читай перед тем, как постить.

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

Ты хоть комментарии к коммитам читай перед тем, как постить.

Читал.

В одном случае не хватало теста на null pointer dereference

«This issue has been fixed.» Надо думать, ошибка была, просто сначала её поправили, а потом сделали issue, чтоб не забыть дописать тест.

в другом - утечка события

«Possible vint leak in nested case.» Ну, я просто не знаю матчасти. Расскажи, что собой представляет событие и куда утекает. Типа не выполняется, хотя должно?

Esper
()
Ответ на: комментарий от shkolnick-kun

я уже взрослый дядя

Какой ты стал большой и умный! А GitHub помнит, как полтора года назад ты был вот-такусеньким сишником! [шёпотом] Раст бы и от такого защитил, но, думать надо, привык ты уже к сишным практикам передовым.

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

Это когда событие не обрабатывается из-за ошибки в алгоритме. От такого никакой паст не спасет.

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

Что касательно того, что ошибка якобы была, то надо просто глянуть на коммит и там сделано BGRT_SYNC_SLEEP(&bgrt_sync_1,0); вместо передачи указателя на буферную переменную вторым аргументом, а сделано это, потому, эта буферная переменная нужна далеко не всегда, захотелось сэкономить пару байтиков на стеке и нулевой указатель как раз говорит о том, что тут нет буферной переменной, отсюда и тест.

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

О да. Мифичиская сила сишки. Любой код на сишке заведомо быстрее всего на свете. Бла-бла-бла.

и где я это написал?

(для протокола — си кое-где сливает плюсам, например в случае, когда в плюсах можно сунуть функцию в шаблон, а в си — только указатель на нее)

Потому, что вы не поняли пример.

нет, это *ты* не сумел написать пример понятно, о чем тебе и было сказано — перепиши его понятно (и тем не менее я с приемлемой достоверность представляю, что ты хотел сказать)

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

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

я это где-то предлагал?

Мне достаточно rust, который выполняет мои задачи с приемлемой производительностью.

это тебе

а для некоторых стоит другой вопрос: раст или с++

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

Ты как будто специально намекаешь на анекдот...

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

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

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