The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск языка программирования Rust 1.37, opennews (??), 17-Авг-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


1. "Выпуск языка программирования Rust 1.37"  –1 +/–
Сообщение от Антонemail (??), 17-Авг-19, 09:32 
Хорошечно!
Ответить | Правка | Наверх | Cообщить модератору

7. "Выпуск языка программирования Rust 1.37"  +10 +/–
Сообщение от Аноним (7), 17-Авг-19, 11:13 
Так-то аналогов Раста фактически нет. Хочется zero cost abstraction и скорости плюсов? И чтоб популярный за пределами круга чей-то мамы?
Ну и кто кроме него?
А синтаксис вырвиглазный только до того момента, пока не начинаешь его понимать. Сам через это прошел.
Ответить | Правка | Наверх | Cообщить модератору

9. "Выпуск языка программирования Rust 1.37"  +/–
Сообщение от Аноним (9), 17-Авг-19, 11:16 
Расскажи кстати какой полезный сервис ты написал или даже внедрил на расте?
Ответить | Правка | Наверх | Cообщить модератору

83. "Выпуск языка программирования Rust 1.37"  +2 +/–
Сообщение от Wilem (?), 17-Авг-19, 23:46 
Я например написал около 6-ти инструментов, серьёзно упрощающие работу. Четыре из них для работы с логами. Logmerge - мержит тысячи логов в один файл сохраняя записи в хронологическом порядке и корректно обрабатывая многострочные записи, типа стектрейсов. Изначально тулза была на жаве. Отрабатывала за 25 минут и съедала 2500 мегов памяти. На расте те же данные за 1 минуту и съедает 3 мегабайта памяти.
Ответить | Правка | Наверх | Cообщить модератору
Часть нити удалена модератором

117. "Выпуск языка программирования Rust 1.37"  –2 +/–
Сообщение от анон (?), 18-Авг-19, 21:03 
какой в ж.. sed awk в венде? На вас краснглазых мир клином не сошелся!
Ответить | Правка | Наверх | Cообщить модератору

121. "Выпуск языка программирования Rust 1.37"  +/–
Сообщение от Аноним (121), 18-Авг-19, 22:48 
Этих вполне достаточно. Или можно руками собрать.

http://gnuwin32.sourceforge.net/packages/gawk.htm
http://gnuwin32.sourceforge.net/packages/sed.htm

Ответить | Правка | Наверх | Cообщить модератору

137. "Выпуск языка программирования Rust 1.37"  +/–
Сообщение от Wilem (?), 20-Авг-19, 11:58 
На знаю что там была за удалённая нить, но вообще сед и авк в винде норм. BusyBox называется. Я так кросс-платформенные скрипты делаю. И не для себя, а для гигантских компаний по всему миру.
Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

16. "Выпуск языка программирования Rust 1.37"  –1 +/–
Сообщение от user90 (?), 17-Авг-19, 11:35 
«zero cost abstraction» - это случайно не из методичек по Расту?
Я вот не знаю, хочется ли мне этого, т. к. не знаю, что это такое ;)

> А синтаксис вырвиглазный только до того момента, пока не начинаешь его понимать.

То есть этот момент может не наступить никогда?))

Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

17. "Выпуск языка программирования Rust 1.37"  +2 +/–
Сообщение от Аноним (7), 17-Авг-19, 11:51 
Это ещё из методичек по C || C++ :)
Например, заменяешь цикл расчета суммы до аналогичной функций в одну строку с лямбдой (типа как map/reduce)
C++/Rust не это потратят столько же мс, сколько и обычный цикл (условные 20 мс). В других языках может потратиться на несколько сотен больше мс (500, к примеру)

> То есть этот момент может не наступить никогда?))

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

Ответить | Правка | Наверх | Cообщить модератору

29. "Выпуск языка программирования Rust 1.37"  –1 +/–
Сообщение от user90 (?), 17-Авг-19, 13:30 
Каждому свое - не думаю, что в Лиспе есть накладки с лямбдами нопример.
Ответить | Правка | Наверх | Cообщить модератору

33. "Выпуск языка программирования Rust 1.37"  +/–
Сообщение от Другой анан (?), 17-Авг-19, 13:53 
Шта?
Ответить | Правка | Наверх | Cообщить модератору

78. "Выпуск языка программирования Rust 1.37"  +3 +/–
Сообщение от Ordu (ok), 17-Авг-19, 22:37 
В лиспе есть очень интересные "накладки". Скажем в lisp'е нет понятия "переменная" в смысле других языков. Там есть символы. Символ может иметь значение, и таким образом его можно использовать как переменную. Но согласно семантике лиспа, каждая ссылка на символ должна разрешаться начиная с имени этого символа в рантайме. Да, всякие там оптимизирующие компиляторы могут обратить внимание на то, что внутри (let ((x 0)) ...) x -- это локальная переменная, и они могут даже не создавать символ с именем x в некоторых случаях, заменив его регистром. Но, как говориться, шаг влево, шаг вправо, и вот у тебя уже создан символ x, и обращение к нему неявно включает в себя поиск в хештабличке.

Но там есть и "накладки" с лямбдами. Функция в lisp'е это значение, которое (если копнуть в сторону реализации), располагается в куче, сопровождается тегом типа, а код жонглирует указателем на кусок памяти в функцию. А указатель не простой, динамическая типизация требует встроить в указатель тег типа (все возможные типы закодировать в указателе не удастся, поэтому там несколько бит под этот тег, самые частовстречающиеся типы полностью кодируются этими битами в указателе, в остальных эти биты выставлены в определённое значение, говорящее о том, что тип объекта определять надо по тегу прицепленному к объекту), и в дополнение к этому тегу типа в указателе есть ещё бит для сборщика мусора. И вот мы уже получаем, что у нас выравнивание объектов не менее восьми байт (а то и 16-32), потому что несколько бит указателя используются не для того, и кроме того, разадресация указателя требует выделения этих битов, сверки с ними, доведения указателя до машинного вида (обнуление всех посторонних битов), и только после этого разадресация. Это касается не только лямбды, но и её это касается тоже.

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

В lisp'е такого рода накладных расходов, дофига. И они не бесплатны для программы, даже если она не использует всякие фичи типа lexical binding, сборку мусора, динамическую типизацию и тп.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

129. "Выпуск языка программирования Rust 1.37"  +2 +/–
Сообщение от Урри (?), 19-Авг-19, 11:16 
Все вами описанное в личпе как раз и является "zero cost", так как реализовано естественным для рантайма образом.

Выравнивание объектов в памяти по границе слова (двойного слова)? Любой язык, кроме специально оговоренных программистом случаев, это делает за вас - напомню, что обращение к невыровненным словам до сих пор влечет за собой CPU пенальти. А в лиспе (и других языках со сборкой мусора) это выравнивание дополнительно используется для элегантного 0-cost выделения объектов в куче, где выделение объекта, это просто увеличение внутреннего указателя на N слов.

Локальные переменные? Локальные "переменные" еще на этапе компиляции переименовываются в вида lvarNNNNN и не требуют поиска по таблице, так как даже студенческие лисп-поделки умеют это дело опитимизировать.

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

Ответить | Правка | Наверх | Cообщить модератору

134. "Выпуск языка программирования Rust 1.37"  –1 +/–
Сообщение от Ordu (ok), 19-Авг-19, 21:03 
> Все вами описанное в личпе как раз и является "zero cost", так
> как реализовано естественным для рантайма образом.
> Выравнивание объектов в памяти по границе слова (двойного слова)? Любой язык, кроме
> специально оговоренных программистом случаев, это делает за вас - напомню, что
> обращение к невыровненным словам до сих пор влечет за собой CPU
> пенальти.

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


> А в лиспе (и других языках со сборкой мусора) это
> выравнивание дополнительно используется для элегантного 0-cost выделения объектов в куче,
> где выделение объекта, это просто увеличение внутреннего указателя на N слов.

Куча -- это не zero-cost абстракция. Она отъедает процессорное время и изменяет объём расходуемой памяти, причём как именно она будет это делать зависит от реализации этой кучи. Но что самое интересное, ты будешь платить за кучу, вне зависимости от того, хочешь ты её использовать или нет. malloc/free в этом смысле -- это вещь не бесплатная, но если ты их не используешь, ты их не используешь и не платишь за их использование.

> Локальные переменные? Локальные "переменные" еще на этапе компиляции переименовываются
> в вида lvarNNNNN и не требуют поиска по таблице, так как
> даже студенческие лисп-поделки умеют это дело опитимизировать.

А если эта локальная переменная не локальна?

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

Элегантность спорна, абстрактность бесспорна. А вот быстрота в lisp'е достигается огромными геморроями, и то не во всех. Если lisp позволяет аннотации типов переменных функций, если он позволяет выделять память на стеке, если он позволяет работать с машинными типами, то тогда на нём можно писать быстрые программы. Но пока ты будешь это делать, ты поймёшь, что элегантность lisp'а выходит боком. Lisp не для написания быстрых программ, он для быстрого написания программ, которые ты не знаешь заранее как писать. Для тех проблем, которые ты исследуешь "боем" посредством написания программы.

> Настолько отлично, что его каждый
> раз пытаются переизобрести в качестве подмножества того или иного языка (десятое
> правила Гринспена, да).

Ну естественно. Если в язык засунуть всё, то любой другой язык будет его подмножеством. Но засунуть всё -- это очень дорогостоящая вещь. Можно вспомнить историю PL/1. Ещё ты можешь почитать документацию на ANSI Common Lisp. Если от чтения просветления не возникнет, то попробуй взять sbcl и написать на нём что-нибудь. Когда в язык пихают всё на все случаи жизни, это кончается плохо. Jack of all trades, master of none. Он может всё, но сливает любому более специализированному языку в области его специализации. То есть для любой проблемы можно найти более подходящий язык, нежели lisp.

Ответить | Правка | Наверх | Cообщить модератору

132. "Выпуск языка программирования Rust 1.37"  +/–
Сообщение от freehck (ok), 19-Авг-19, 15:42 
> Скажем в lisp'е нет понятия "переменная" в смысле других языков. Там есть символы.

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

> Но это лишь полбеды, лисп имеет такую фичу как lexical binding
> <...>
> таким образом, я могу переопределить значение глобального символа, вызвать функцию, ссылающуюся на этот символ, и она из этого символа получит подставленное мною значение

Ты путаешь с динамическим связыванием. Динамическое связывание -- это во-первых зло, а во-вторых диалекты scheme (которые таки да, тоже обычно подразумеваются, когда мы говорим о lisp) его либо вообще не поддерживают, либо поддерживают через явное декларирование в каждом месте, где используются, что это не лексические связывания. Как пример можешь посмотреть на parameters в Racket.

Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

135. "Выпуск языка программирования Rust 1.37"  +/–
Сообщение от Ordu (ok), 19-Авг-19, 21:08 
>> Скажем в lisp'е нет понятия "переменная" в смысле других языков. Там есть символы.
> Вообще-то сравнивать символ с переменной не корректно. Наиболее близким аналогом переменной
> в лиспах является связывание.

Может быть. Попробуй объяснить человеку далёкому от lisp'а эти нюансы.

> Ты путаешь с динамическим связыванием.

Может быть.

> Динамическое связывание -- это во-первых зло,

Да ладно. Я не считаю себя фанатом динамического связывания, но это очень удобная фишка.

> во-вторых диалекты scheme (которые таки да, тоже обычно подразумеваются, когда мы
> говорим о lisp) его либо вообще не поддерживают, либо поддерживают через
> явное декларирование в каждом месте, где используются, что это не лексические
> связывания. Как пример можешь посмотреть на parameters в Racket.

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

Ответить | Правка | Наверх | Cообщить модератору

136. "Выпуск языка программирования Rust 1.37"  +/–
Сообщение от freehck (ok), 19-Авг-19, 23:26 
>> Ты путаешь с динамическим связыванием.
> Может быть.

"Может быть". =/

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

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

Ответить | Правка | Наверх | Cообщить модератору

65. "Выпуск языка программирования Rust 1.37"  +1 +/–
Сообщение от Совершенно другой аноним (?), 17-Авг-19, 19:17 
Не знаю, как в C++, но в C нет никаких zero cost abstractions, по причине отсутствия каких либо абстракций.
Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

77. "Выпуск языка программирования Rust 1.37"  +/–
Сообщение от Аноним (77), 17-Авг-19, 22:07 
В C++ есть. Дырявые. Потому и zero cost.
Ответить | Правка | Наверх | Cообщить модератору

79. "Выпуск языка программирования Rust 1.37"  +9 +/–
Сообщение от Ordu (ok), 17-Авг-19, 22:53 
В C есть абстракции, если ты их не видишь, то это значит, что ты не кодил на ассемблере. Возьмём, скажем, понятие "переменная". В ассемблере такого понятия, по-хорошему, нет. Там есть регистры, есть стек, есть RAM. И ты перекладываешь значения с места на место. Некоторые места в RAM могут иметь вполне определённую семантику, и такие места можно назвать переменными, но подчастую работа с этими переменными сводится к тому, чтобы забрать оттуда значение, что-то с ним сделать, положить обратно. В C же, переменная -- это переменная, она может располагаться на стеке, в куче, в статической памяти, в регистре, иногда это определяется контекстом, но очень часто компилятор за тебя решает, когда и какая переменная будет представляться регистром, а когда ячейкой стека.

А типы? В асме нет типов, тип значения определяется операцией, которую ты выполняешь. Если add -- это целочисленное сложение 32-х битных целых, то она будет складывать 32-х битные флоаты как целые числа. В C тип определяется типом переменной или другого источника/приёмника откуда ты берёшь или куда ты кладёшь значение. Если ты используешь операцию + для сложения целых, то она сложит целые. Если ты используешь её для сложения float'ов, она сложит флоаты. При этом при необходимости типы аргументов будут приведены до соответствия друг-другу. Особенно эти сишные типы заметны на указателях: для асма нет разницы между целым значением, void* и char*. Ты когда пишешь на асме думаешь об указателях как о целых числах. В C же, указатель с некоторой натяжкой можно назвать целым числом, но в зависимости от типа указателя операция сложения будет выдавать разные значения. (char*)0 + 1 даст 1, а (int*)0 + 1 даст 4.

В C есть функции -- это тоже абстракции. В ассемблере есть код и есть данные, деление между ними условно -- ты можешь сделать jmp на данные, или прочитать байт кода в регистр. В асме ты можешь создавать функции, но при этом ты можешь сделать call в середину функции, или jmp из одной функции в другую. И, я отмечу, это не всегда глупость, это может быть вполне осмысленным и полезным действием. Скажем, tail call'ы так и делаются -- вместо call func/ret, мы делаем jmp func. Функции с несколькими точками входа тоже не редкость в асме.

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

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

106. "Выпуск языка программирования Rust 1.37"  +2 +/–
Сообщение от Совершенно другой аноним (?), 18-Авг-19, 14:48 
>[оверквотинг удален]
> что ты не кодил на ассемблере. Возьмём, скажем, понятие "переменная". В
> ассемблере такого понятия, по-хорошему, нет. Там есть регистры, есть стек, есть
> RAM. И ты перекладываешь значения с места на место. Некоторые места
> в RAM могут иметь вполне определённую семантику, и такие места можно
> назвать переменными, но подчастую работа с этими переменными сводится к тому,
> чтобы забрать оттуда значение, что-то с ним сделать, положить обратно. В
> C же, переменная -- это переменная, она может располагаться на стеке,
> в куче, в статической памяти, в регистре, иногда это определяется контекстом,
> но очень часто компилятор за тебя решает, когда и какая переменная
> будет представляться регистром, а когда ячейкой стека.

Вообще опыт программирования на ассемблере вполне себе имею и до сих пор приходится периодически или писать ассемблерные вставки для C, а то и чисто ассемблерный код для 86-ой архитектуры, или смотреть дизассемблированный код. Ассемблер даёт возможность объявлять именованные ячейки памяти - на самом деле метки присвоенные ячейкам. По крайней мере для 86 архитектуры, как для для разных там masm-ов/tasm-ов, так и для разных gas-ов это справедливо. Опять-же для tasm-ов была возможность даже объявлять переменные на стеке в соответствии с определённой callcing convention, и тогда написав что-то типа

mov ax,myparam1
в коде можно было получить что-то типа:
mov ax,[bp + 7]

Так-что ассемблер ассемблеру рознь - некоторые даже позволяли объявлять структуры и прочие высокоуровневые абстракции.

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

> А типы? В асме нет типов, тип значения определяется операцией, которую ты
> выполняешь. Если add -- это целочисленное сложение 32-х битных целых, то
> она будет складывать 32-х битные флоаты как целые числа. В C
> тип определяется типом переменной или другого источника/приёмника откуда ты берёшь или
> куда ты кладёшь значение. Если ты используешь операцию + для сложения
> целых, то она сложит целые. Если ты используешь её для сложения
> float'ов, она сложит флоаты. При этом при необходимости типы аргументов будут
> приведены до соответствия друг-другу.

С float-ами соглашусь - там это специализированные команды сопроцессора, по крайней мере опять-же для 86-ой архитектуры. А вот для целочисленных это не так - там (в tasm/masm, а, если не ошибаюсь, с недавнего времени и в gas), add складывает как 8-ми битные, так и 16-ти и 32-х битные целые значения, как знаковые так и беззнаковые, вроде как одной и той-же командой (понятно, что для процессора эти команды разные, но для программиста - нет), а, опять-же в каких-то архитектурах типа 86 даже может прибавлять к регистру содержимое памяти.

> Особенно эти сишные типы заметны на указателях:
> для асма нет разницы между целым значением, void* и char*. Ты
> когда пишешь на асме думаешь об указателях как о целых числах.
> В C же, указатель с некоторой натяжкой можно назвать целым числом,
> но в зависимости от типа указателя операция сложения будет выдавать разные
> значения. (char*)0 + 1 даст 1, а (int*)0 + 1 даст
> 4.

С этим - согласен. Хотя его предок, B, если правильно помню вполне себе был безтиповым, т.е. у него, если правильно понимаю, был тип int и был, формально, указатель void*, правда как он там с переменными с плавающей запятой обходился не знаю, возможно для той архитектуры их просто не было.

> В C есть функции -- это тоже абстракции. В ассемблере есть код
> и есть данные, деление между ними условно -- ты можешь сделать
> jmp на данные, или прочитать байт кода в регистр. В асме
> ты можешь создавать функции, но при этом ты можешь сделать call
> в середину функции, или jmp из одной функции в другую. И,
> я отмечу, это не всегда глупость, это может быть вполне осмысленным
> и полезным действием. Скажем, tail call'ы так и делаются -- вместо
> call func/ret, мы делаем jmp func. Функции с несколькими точками входа
> тоже не редкость в асме.

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

> Абстракции есть в любой проблеме, о которой ты в состоянии думать. Если
> ты не видишь этих абстракций, значит ты недостаточно глубоко копнул.

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

Ответить | Правка | Наверх | Cообщить модератору

114. "Выпуск языка программирования Rust 1.37"  +/–
Сообщение от Ordu (ok), 18-Авг-19, 20:06 
> С float-ами соглашусь - там это специализированные команды сопроцессора, по крайней мере
> опять-же для 86-ой архитектуры. А вот для целочисленных это не так
> - там (в tasm/masm, а, если не ошибаюсь, с недавнего времени
> и в gas), add складывает как 8-ми битные, так и 16-ти
> и 32-х битные целые значения, как знаковые так и беззнаковые, вроде
> как одной и той-же командой (понятно, что для процессора эти команды
> разные, но для программиста - нет), а, опять-же в каких-то архитектурах
> типа 86 даже может прибавлять к регистру содержимое памяти.

А на других архитектурах? Где-то сопроцессор, где-то нет. А знаковые/беззнаковые умножения/деления? Тип операнда определяется кодом операции и всякими флагами в ней, а не свойствами операндов.

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

Да, это поможет.

> Впрочем, всё-равно было интересно Вас почитать. Спасибо.

Пожалуйста. Но в общем не за что.

Ответить | Правка | Наверх | Cообщить модератору

119. "Выпуск языка программирования Rust 1.37"  +2 +/–
Сообщение от Аноним84701 (ok), 18-Авг-19, 21:10 
>  Опять-же
> для tasm-ов была возможность даже объявлять переменные на стеке в соответствии
> с определённой callcing convention, и тогда написав что-то типа

Оно, ЕМНИП, для всех более-менее популярных  "человеческих" x86 ассемблеров было - MASM, TASM, NASM, FASM
Но "круче" в этом плане IMHO все же всякие "proto/proc/uses REG1, ... REGX" макросы -  автоматом создавался стекфрейм, делался PUSH REG для register preservation (и что гораздо интереснее - перед каждым RET в этой "процедуры" – автоматически вставлялся POP REG1, ..., REGX), оформлялся вызов через INVOKE в нужном соглашении и даже, вроде бы, предупреждениями сыпало при несоответсвии кол. аргументов.

Хотя и MASMовые "абстракции":


.IF al < FOO
   print CurDir$()
...
    mov hFile, fopen("testfile.txt")            ; open the existing file again
    mov flen, fsize(hFile)                      ; get its length
    mov hMem, alloc(flen)                       ; allocate a buffer of that size
    mov bwrt, fread(hFile,hMem,flen)            ; read data from file into buffer
    fclose hFile              
  ...
.ELSE
или 
.WHILE ecx < BAR*4

или

   .WHILE TRUE
        invoke GetMessage, ADDR msg,NULL,0,0
        .BREAK .IF (!eax)
                invoke TranslateMessage, ADDR msg
                invoke DispatchMessage, ADDR msg
    .ENDW

тоже "ничего так".
Ответить | Правка | К родителю #106 | Наверх | Cообщить модератору

15. "Выпуск языка программирования Rust 1.37"  –2 +/–
Сообщение от Аноним (15), 17-Авг-19, 11:31 
> Вырвиглазный синтаксис даже обсуждать лениво..

Видимо для тех, кто не осилил?

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

63. "Выпуск языка программирования Rust 1.37"  +3 +/–
Сообщение от хотел спросить (?), 17-Авг-19, 18:13 
а он вправду не очень по сравнение с джавой или шарпом

не то чтобы откровенное говно, но меня на него ни разу не тянет

Ответить | Правка | Наверх | Cообщить модератору

72. "Выпуск языка программирования Rust 1.37"  +2 +/–
Сообщение от Аноним (72), 17-Авг-19, 21:12 
Он не очень даже по сравнению с С++
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру