Разработчики проекта Mozilla представили (https://mail.mozilla.org/pipermail/rust-dev/2012-January/001...) первый релиз компилятора и инструментария для языка программирования Rust (http://www.rust-lang.org/). Версия 0.1 позиционируется как релиз альфа-качества, пригодный для начального ознакомления с языком. API ещё полностью не сформирован и будет расширяться и изменяться, также предстоит большая работа по оптимизации производительности, которая пока оставляет желать лучшего. Исходные тексты проекта распространяются (https://github.com/mozilla/rust/) в рамках лицензии MIT. Компилятор поддерживает сборку для платформ Linux (x86 и x86_64), Mac OS X (x86 и x86_64) и Windows (x86), включая возможность кросс-компиляции и сборки сразу для нескольких целевых платформ.
Rust является языком со строгой типизацией, сфокусированным на безопасной работе с памятью и обеспечении высокого параллелизма выполнения заданий (возможность порождать тысячи и даже миллионы подпроцессов). По ст...URL: https://mail.mozilla.org/pipermail/rust-dev/2012-January/001...
Новость: http://www.opennet.ru/opennews/art.shtml?num=32876
"Ржавейка"! Отличное название! :)
Скорее "ржа" :)
Я в курсях, спасибо. Я вспомнил мульт "Тачки" просто. Там было Rusteze, евжли память мне не врет. :)
по описанию выглядит круто, хорошо бы, чтоб из него получилось что-то путное.
а результирующие бинарники будут жестко завязаны на libxul и libxpcom, да?
Учитывая что libxul и libxpcom возможно будут частично на rust, да, они будут завязаны.
Продолжаем строить вавилонскую башню? Стопицот языков с одинаковыми возможностями, разница только в том, как писать слово function или fn или func или def или "мнепофигкакэтоназватьглавноечтобработало"?
>Продолжаем строить вавилонскую башню?Разрушать. ;)
В моем пишется как ->
> Продолжаем строить вавилонскую башню? Стопицот языков с одинаковыми возможностями, разница
> только в том, как писать слово function или fn или func
> или def или "мнепофигкакэтоназватьглавноечтобработало"?Фатальный недостаток же. Оно написано не нами.
Ориентация на безопасность и отсутствие типов данных. Это как?И что будет если "i=ptr[0]"? Не зная размера?
Это вообщене понял: "никаких нулевых и потерянных указателей. Автоматическое управление памятью".
ptr = malloc();
free(ptr);И чему будет равен ptr?
А вообще, ещё один бесполезный язык, ещё один С/С++, коих уже пару сотен, а то и тысяч.
> ptr = malloc();Никаких malloc и free.
Т.е. живём без динамической памяти? Без списков, деревьев и дин.массивов?
ну почему же. с ними, просто память под них будет выделяться и освобождаться автоматически, а не вручную программистом
Если есть указатели, динамическая память и функция её освобождения, то я могу указатель сделать невалидным.Без явного контроля над освобождением памяти ни о какой эффективности речь не идёт.
> и функция её освобожденияНикаких функции освобождения, ты читать умеешь?
> Без явного контроля над освобождением памяти ни о какой эффективности речь не идёт.Очередная анонимная икспертиза. Конечно же без пруфов.
Я комментирую статью. И высказываю свою точку зрения. Мне на этот язык начхать, как и всем собственно.
> Я комментирую статью. И высказываю свою точку зрения.А я думал что ты кормишь троллей сухим кормом, путем просто сказочного торможения, невладения терминологией и просто общим дебилизмом. Да, будущее MS в надежных руках - счастливой отладки, суки :)
Ждем примера с превращением std::tr1::shared_ptr в невалидный.
Это возможно, конечно.
Но только на более низком уровне, который в Rust'е, очевидно, будет недоступен.
free(ptr)Функцию free прошу заменить на функцию освобождения дин.памяти.
После указатель будет либо NULL, либо ссылаться хрен пойми на что. И то, и другое описано как невозможное, с чего собственно и начался наш с вами диалог.
Будет доступен в unsafe-блоке. Да, в нём можно начудить, а можно получить хорошую эффективность. И это правильно, товарищи.
Осталось объяснить, с какого перепугу в этот язык кто-то будет вводить функции освобождения динамической памяти.
Даже на С++ их непосредственное использование давно стало дурным тоном, поскольку для одних и тех же задач куда безопаснее применять не "сырые" указатели, а ссылки и "умные" указатели. Чуть менее эффективно, но это отнюдь не критично.
> Я: Если есть указатели, динамическая память и функция её освобождения, то я могу указатель сделать невалидным
> Вы: Ждем примера с превращением std::tr1::shared_ptr в невалидный
> Вы: Осталось объяснить, с какого перепугу в этот язык кто-то будет вводить функции освобождения динамической памяти.Повторюсь ещё раз: если есть указатели, динамическая память и функция её освобождения, то я могу указатель сделать невалидным.
>> Я: Если есть указатели, динамическая память и функция её освобождения, то я могу указатель сделать невалидным
>> Вы: Ждем примера с превращением std::tr1::shared_ptr в невалидный
>> Вы: Осталось объяснить, с какого перепугу в этот язык кто-то будет вводить функции освобождения динамической памяти.
> Повторюсь ещё раз: если есть указатели, динамическая память и функция её освобождения,
> то я могу указатель сделать невалидным.Тебе человеческим языком сказано, что НЕТ функции освобождения памяти, а есть автоматическое управление памяти — то бишь без участия программиста. Какие еще могут быть "если"?
> Даже на С++ их непосредственное использование давно стало дурным тоном, поскольку для одних и тех же задач куда безопаснее применять не "сырые" указатели, а ссылки и "умные" указатели.Ну вот тут недавно был отчет о том как в firefox борются с утечками памяти, можете там про умных с хорошими тонами почитать
>НЕТ функции освобождения памяти, а есть автоматическое управление памяти — то бишь без участия программиста. Какие еще могут быть "если"?
никаких если, да зравствует жаба-ц# ясное дело!
Жаба и ц#? Увольте. Лисп — наше всё!
будет очередной gc, почти как в яве с её гемором сборщика.
И мозилла станет жрать еще больше памяти...
типы есть
"Ориентация на практическое применение: Нет номинальных типов или иерархии типов"
> "Ориентация на практическое применение: Нет номинальных типов или иерархии типов""Rust является языком со строгой типизацией, сфокусированным на безопасной работе с памятью и обеспечении высокого параллелизма выполнения заданий", вообще-то.
"нет номинальных типов или иерархии типов" значит всего лишь, что не получится использовать long int и short int в одном выражении. (http://en.wikipedia.org/wiki/Nominative_type_system)
Под типами данных (базовыми, стандартными, номинальными, типовыми, ..) всю жизнь подразумевал как раз эти самые char, int, float, ..long, short, signed, unsigned, .. - всю жизнь называл модификаторами.
Ну да ладно, вопрос терминологии.
модификаторы здесь разве что signed/unsigned
Спорно.int - целое число.
long int - целое число с бОльшим количеством значений
signed int - знаковое целое числоБыло целое число и осталось целое число.
'a' -целое число?
ага, была переменная, и осталась переменной. В общем, существует только один тип - переменная.
Слежу за дискуссией и не понимаю. Вот парень вроде какое-то отношение имеет к программированию, но бля неужели у такого эпического долбоёба получалось хоть что-то когда-то накодячить?А пишу я for the great justice, у меня собственно вопрос:
> int - целое число.
> long int - целое число с бОльшим количеством значенийЧто у тебя за компилятор такой, что у тебя long int длиннее int? Запости мне пожалуйста, что выведет printf("%d %d\n", sizeof(int), sizeof(long int));
Хмм... Вот мне тоже вас оскорблять, обвинять в непрофессионализме и грязно ругаться?И вообще, интересно было бы посмотреть ваши ответы на задаваемые мне вопросы. Как со стороны, то каждый герой.
Насколько я помню, sizeof(long)=8, sizeof(int)=4, sizeof(short)=2, но я на С/С++ писал давно и возвращаться в обозримом будущем не планирую, а потому эти заморочки не критичны. "long" - значит должен быть длиннее, "short" - значит короче; тип int не предусматривает хранение в виде 2e5, поэтому всё остальное личная шиза разработчиков языка, ломающая привычную логику. Таких граблей везде хватает и запоминать их уже подустал.
> "long" - значит должен быть длиннее, "short" -
> значит короче; тип int не предусматривает хранение в виде 2e5, поэтому
> всё остальное личная шиза разработчиков языка, ломающая привычную логику. Таких граблей
> везде хватает и запоминать их уже подустал."long" - значит должен быть не короче , "short" - значит не длиннее. Так гласит спецификация языка. В отдельных реализациях компилятора размер int равен размеру short, в других — размеру long. Более того, компилятор, для которого размер short равен размеру long, тоже имеет право на существование (размер int в таком случае будет точно таким же). Поэтому полагаться на различия между размером типов long,int,short — моветон. Используйте типы intN_t и uintN_t — cтардарт С99 их включает (см. http://en.wikipedia.org/wiki/C_data_types#Fixed_width_intege...)
Как я не люблю сам себя цитировать...Я не пишу на С/С++ и полагаться ни на что не собираюсь.
Таких граблей везде хватает и запоминать их уже подустал. Поэтому всё что выбивается из общечеловеческой логики просто не запоминаю и наступаю каждый раз. Так оказалось проще, чем запоминать шизофрению каждого.
Поправьте, если я правильно понял. Общечеловеческая логика диктует Вам, что запоминать наизусть размер типов char,short,int,long,long long для каждого отдельного компилятора проще, чем обращаться к типам, в которых размер указан непосредственно — т.е. int8_t, int16_t, int32_t и int64_t? Серьезно?
Я не пишу на С/С++ и не собираюсь делать этого в обозримом будущем.Какое из слов этой фразы вам непонятно??????
ну не мучай ванюшу, ну что ты, право… он же тебе уже намекнул, что окончательно распростился с мечтами работать программистом и смирился с должностью разносчика кофе.
> Так гласит спецификация языка.подожди, не спеши, ванюша спешно читает. хотя вон в другом каменте утверждает, что таки читал. он весь такой противоречивый — просто как капризная барышня.
> я на С/С++ писал давно и возвращаться в обозримом будущем не планируютебя таки окончательно выгнали с должности стажёра и перевели в вечные дежурные по аэродрому?
ванюша, так открой нам тайну, разреши вопрос: что стреляет в анус, попадает в нос^w^w^w^w^w^w^w на чём же пишет сейчас такой титан мысли и светоч знаний, как ты?
> модификаторы здесь разве что signed/unsignedу ванюши всё, что с пробелом — «модификатор». то, что название типа может быть более, чем в одно слово — в череп не помещается.
> у ванюши всё, что с пробелом — «модификатор». то, что название типа
> может быть более, чем в одно слово — в череп не
> помещается.Ну вообще-то, long и short - это и в самом деле модификаторы типа int, так же как signed и unsigned.
> Ну вообще-то, long и short - это и в самом деле модификаторы
> типа int, так же как signed и unsigned.вопрос достаточно спорный, конечно: трактовать можно и так, и иначе. я бы, всё-таки, рассматривал это как разные типы, просто с похожими названиями.
Спецификации языка программирования (С99 и более поздние) больше не авторитет? Теперь "вы" решаете что является типом, а что нет? Странная избирательность...
> Спецификации языка программирования (С99 и более поздние) больше не авторитет? Теперь "вы"
> решаете что является типом, а что нет? Странная избирательность...Теория типов уже не авторитет? Теперь спецификации отдельных языков программирования решают, что является типом, а что нет? Странная избирательность…
Для компилятора языка программирования Си спецификация (практическая реализация теории) языка программирования Си выше любых теорий.Не так давно данный персонаж мультов как раз писал что я, дескать, спецификаций не читаю. И вот, на тебе, в лужу сел.
> Для компилятора языка программирования Си спецификация (практическая реализация теории)
> языка программирования Си выше любых теорий.
> Не так давно данный персонаж мультов как раз писал что я, дескать,
> спецификаций не читаю. И вот, на тебе, в лужу сел.Если спецификация, скажем, паскаля начнёт утверждать, что комплексные числа — это всегда запись из двух 42хбитных. Когда речь идёт только о гипотетическом паскале с комплексными числами, терминологию можно и даже нужно брать из спецификации; но когда обсуждаются НЕСКОЛЬКО языков, размахивать спецификацией одного из них, как флагом, и кричать, что только эту терминологию нужно использовать — глупость.
> Не так давно данный персонаж мультов как раз писал что я, дескать,
> спецификаций не читаю.что, книжку по ассемблеру отобрали?
кстати, ванюша: а зачем тебе C99? ведь твой любимый компилятор всё равно его не умеет.
Сорри, погорячился, оно таки инопланетное. То есть может за многими рещениями и есть толковые обоснования, но их тогда надо было описать на сайте. Я всего лишь кратенько пробежался по описанию типов - и слегка очумел. Как минимум, конструкция alt для биндинга переменных к членам структуры и отсутствие нормального доступа через точку вызывают сомнения. Также как и требование явного боксинга для объектов при преедаче в функцию, принимающую итерфейс. Из замеченного - ещё угловые скобки для параметров шаблонов - им что, проблем плюсов с парсингом хочется?
так, что-то я сегодня туплю. Можно там через точку обращаться, это меня конструкция alt с толку сбила. И в общем язык довольно забавный - эдакий конкурент D, авторы явно много чему научились на дишном опыте и стараются не наступать на грабли (находя, впрочем другие).Хотя кое-где явная чушь. Допустим, что им мешает immutable shared boxes гонять между тасками - я не понимаю. Но они для таких случаем используют зачем-то unique boxes, которые в один момент могут быть доступны только одному таску. Всё, что можно предположить - что это артефакт подсчета ссылок, который между потоками работает откровенно паршиво.
«Ржавчина». Обнадеживающее название, ага.
судя по описанию - язык довольно адекватный, начиная с бинарной совместимости структур с сишными
"бинарной совместимости структур с сишными"Это как?
Ваня такой Ваня...
А теперь объясни мне "на пальцах" что из себя представляет "бинарная совместимость со структур данных двух разных языков программирования".
> А теперь объясни мне "на пальцах" что из себя представляет "бинарная совместимость
> со структур данных двух разных языков программирования".Существуют конвенции о том, как должны выглядеть структуры данных после компиляции. Так, struct {int_8_t a; long b int_32_t} может в целом занимать как пять байт, так и шестьдесят четыре, если не придерживаться какой-то конкретной конвенции выравнивания (т.е. b может находиться по смещению +4, так и по смещению +1). Однако если её не придерживаться, между собой не будут совместимы не только обьектные файлы разных языков, но и обьектные файлы одного языка, скомпилированные разными компиляторами. Поскольку основная часть библиотек написана на Си, совместимость с Си важна для любого языка. Так понятно?
Открываю вам Америку: структуры АБСОЛЮТНО ВСЕХ языков программирования "бинарно совместимы".
> Открываю вам Америку: структуры АБСОЛЮТНО ВСЕХ языков программирования "бинарно совместимы".Ловлю на слове и жду демонстрации использования структур из Си в питоне. Или в яве. Или, если уж на то пошло, перловских хешей в паскале.
Формат объектных файлов один? Значит могут использоваться.Формат файлов (.obj в т.ч.) один для всех ЯП и всех компиляторов.
Сморозили глупость, уже который пост отмазываетесь.
> Формат файлов (.obj в т.ч.) один для всех ЯП и всех компиляторов.There are many different object file formats (http://en.wikipedia.org/wiki/Object_file)
> Сморозили глупость, уже который пост отмазываетесь.Возвращаю. Почему Вы решили, что у АБСОЛЮТНО ВСЕХ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ™ один и тот же формат обьектных файлов?
Ещё раз:> Формат файлов (.obj в т.ч.) один для всех ЯП и всех компиляторов.
А теперь с пояснениями для женщин, обезьян, и детей младшей группы: {формат файлов} один для {всех ЯП и всех компиляторов}. Я не говорил что все объектные файлы имеют один формат. Я сказал что каждый конкретный формат объектного файла одинаков для всех ЯП и всех компиляторов.
> Почему Вы решили, что у АБСОЛЮТНО ВСЕХ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ™ один и тот же формат обьектных файлов?
Хмм... Странный вопрос. Нигде в описании формата файла не встречал ссылку на язык программирования. Ни разу не видел фразы вида "файл может быть прочитан лишь кодом, изначально написанным на Паскале". И вряд ли когда-нибудь увижу.
> Хмм... Странный вопрос. Нигде в описании формата файла не встречал ссылку на
> язык программирования. Ни разу не видел фразы вида "файл может быть
> прочитан лишь кодом, изначально написанным на Паскале". И вряд ли когда-нибудь увижу.Скажи, чувак, а тебя не смущает что например COFF и ELF - разные форматы? И оба могут хранить промежуточный объектный код. А у старины Воланда^W Борланда так и вовсе какой-то самопальный формат объектников был. При том еще и разный для паскакаля и сей, в сях объектники и .lib в каком-то собственном формате, а в паскале юниты, в каком-то еще более ином формате.
p.s. это ж надо быть таким самоуверенным дураком и с таким нахрапом нести полную чушь...
> Скажи, чувак, а тебя не смущает что например COFF и ELF - разные форматы? И оба могут хранить промежуточный объектный код.Вы из милиции :). Нужно было сказать сразу, я бы повторил дважды:
А теперь с пояснениями для женщин, обезьян, и детей младшей группы: {формат файлов} один для {всех ЯП и всех компиляторов}. Я не говорил что все объектные файлы имеют один формат. Я сказал что каждый конкретный формат объектного файла одинаков для всех ЯП и всех компиляторов.
> Вы из милиции :). Нужно было сказать сразу, я бы повторил дважды:Если б ты не был эпическим тормозом то заметил бы что уже как несколько месяцев нет никакой милиции, поэтому я ну никак не могу оттуда быть. За отсутствием такой "бинарной структуры" :)
> что все объектные файлы имеют один формат. Я сказал что каждый
> конкретный формат объектного файла одинаков для всех ЯП и всех компиляторов.Покажи мне формат файла объектника для допустим JS в инкарнации гугловского v8? Как бы в понятие "все ЯП" указанный яваскрипт вполне попадает, да? А если ты такой эпичный тормоз что даже элементарные логические условия сам себе подогнать в своей фразе не можешь, я что, виноват чтоли?
> Покажи мне формат файла объектника для допустим JS в инкарнации гугловского v8Сами же ответили на свой вопрос - "Покажи мне формат файла объектника". Если объектный файл существует, у него есть формат. В этом был ваш вопрос?
Оскорбления и глупости вместо аргументов... Что ж, по причине отсутствия аргументация у оппонента продолжать не имеет смысла.
> Если объектный файл существует, у него есть формат.Прикол состоит в том что у JS нет никаких объектных файлов. Ну вот как-то не предусмотрели в дизайне такую сущность.
Получается что ты логически обосрался - ты заявлял про ВСЕ ЯП, JS в это множество, очевидно входит, раз уж ВСЕ. А объектники в рамках JS - просто несуществующая сущность.
> Что ж, по причине отсутствия аргументация у оппонента продолжать не имеет смысла.
Я бы сказал - по причине одноклеточности оппонента. И вообще, после такого сухого корма пить хочется.
> Формат файлов (.obj в т.ч.) один для всех ЯП и всех компиляторов.А еще 640 килобайтов хватит всем, да? Не, ну ты бы ради приличия посмотрел чтоли в гугле насчет форматов объектников, тебя ждало бы большое обломинго на этот счет.
> Сморозил глупость в очередной раз
//fixed...
А теперь с пояснениями для женщин, обезьян, и детей младшей группы: {формат файлов} один для {всех ЯП и всех компиляторов}. Я не говорил что все объектные файлы имеют один формат. Я сказал что каждый конкретный формат объектного файла одинаков для всех ЯП и всех компиляторов.
> А теперь с пояснениями для женщин, обезьян, и детей младшей группы: {формат
> файлов} один для {всех ЯП и всех компиляторов}.Так я не понял, а ты к какой из этих категорий относишься? Ко всем сразу? (учитывая тупизну и наглость - довольно правдоподобно).
Для амеб поясняю: в мире есть более 1 формата объектных файлов. Более того, чисто для лулзов посмотри сколько форматов объектников жрет гнутый binutils. И да, эти форматы ни разу не одинаковые между различными компилерами, а произвольно взятый компилер вовсе не обязан жрать произвольно взятый формат файла. Например, в лине форматом объектников может являться ELF. Как бы удачи тебе в подсовывании ELF`а вьюжлстудии, было б интересно на это посмотреть.
// #include <trollface.jpg>> Я не говорил что все объектные файлы имеют один формат. Я сказал что каждый
> конкретный формат объектного файла одинаков для всех ЯП и всех компиляторов.Что это за юления начались? Если уж на то пошло, ВСЕ яп и компилеры не обязаны поддерживать ВСЕ форматы объектников или реализовывать их одинаково. Более того, у некоторых ЯП вообще нет такого понятия, как минимум в некоторых инкарнациях. А что такое объектный файл применительно допустим к JS работаюшем в браузере?
Объектные файлы - промежуточная техническая сущность этапа компиляции, характерная для си и еще нескольких компилируемых ЯПов. Их переносимость - довольно мизерная, когда был такой бред как бинарные 3rd party библиотеки, они таскали около дюжины форматов объектников под разные компилеры. Например: http://www.ibsensoftware.com/files/aPLib-1.01.zip - wtf? Всего 7 разных вариантов формата бинарных файлов этой библиотеки? Ну да, тяжела жизнь проприетарщика... :))
Я ни говорил ничего из того, что вы опровергаете. Если вам нравится высказывать мысль, приписывать её другому, и опровергать - ваш путь лежит в дурку. Но мне всё равно.
> Я ни говорил ничего из того, что вы опровергаете.Ну да, а вон там выше - чего?
Ваня, ты неадекват. Это же твоя фраза - "Формат объектных файлов один? Значит могут использоваться." (см. выше, точно твоя фраза, не вру). Поголовно все русскоязычные должны понять это изречение как то, что других форматов объектных файлов, кроме какого-то единственного, не существует. А на самом деле форматов объектных файлов много. Или ты просто не силен в русском языке или ты просто дятел. Или тролль, что более всего вероятно. Поясню для обезьян и кого ты там еще упомянул - на простой вопрос "Формат объектных файлов один?" должен следовать ответ "Нет, их много всяких разных для всяких разных языков и платформ программирования". Но ты сам отвечаешь "да" неявно на этот вопрос и сам же делаешь вывод "... Значит могут использоваться.". Типа доказал.
"
- Аргументируй!
- Аргументирую.
- Чем аргументируешь?
- АргУментом
" (с) не помню из какого фильма
- Формат объектных файлов один?- У Си и Rust формат объектных файлов один?
Что там "поголовно все русские должны понять"?
> - Формат объектных файлов один?Так и скажи: "да, я дебил и не понимаю разницы между форматом данных в памяти и объектником". Это по крайней мере будет честно.
Нет, я это к тому что слова, предложения и абзацы нужно читать целиком, а не выдирать слова из контекста, наделяя их своим смыслом.
лол) ну вот кто бы говорил)
Ваня, уже даже как-то неудобно тебя опускать, даже стыдно немного, как-будто над убогим смеемся: сам тот контекст пересмотри? Что там выдрано? Вот все слова, предложения и абзацы, на который последовал тот ответ:
"
Ваня:
Открываю вам Америку: структуры АБСОЛЮТНО ВСЕХ языков программирования "бинарно совместимы".
Аноним:
Ловлю на слове и жду демонстрации использования структур из Си в питоне. Или в яве. Или, если уж на то пошло, перловских хешей в паскале.
Ваня:
Формат объектных файлов один? Значит могут использоваться.
Формат файлов (.obj в т.ч.) один для всех ЯП и всех компиляторов.
Сморозили глупость, уже который пост отмазываетесь.
"
где там просто про Си и Раст? Там говорится про ВСЕ языки! Для тебя Си и Раст - все языки?
> Открываю вам Америку: структуры АБСОЛЮТНО ВСЕХ языков программирования "бинарно совместимы".Размечтался. Попробуй в яваскрипте отпарсить "массив байтов", заведомо адресуя его как именно байты, а не абстрактные символы в вакууме. Тебя будет ждать немало интересных открытий насчет того какой ты все-таки ламер.
А попробуй в Прологе работать с бинарным деревом, созданным в С++.Зачем бред писать?
> А попробуй в Прологе работать с бинарным деревом, созданным в С++.Так если по твоему мнению структуры бинарно одинаковые - фигня вопрос, должно быть можно.
А на самом деле - это вполне решаемая задача. Просто ты еще наверное не дочитал в вумной книжке про сериализацию-десериализацию, поэтому выступаешь бесплатным клоуном и сухим кормом для троллей. А приколись, некоторые форматы файлов натурально содержат в себе b-деревья и в принципе их можно так иди иначе вгрузить/распарсить на любом ЯП.
> Зачем бред писать?
Ну тебе наверное виднее зачем. Да, с такими как ты MS точно будет в заслуженном месте :)
скорее всего он сам троль и есть. Пытается вывести всех из себя. Надо просто Ваню игнорировать, пусть сам с собою разговаривает
> скорее всего он сам троль и естьКак известно, тролли - каннибалы. Поэтому толстый и тупой тролль сам является вполне себе годной едой для более высокоразвитых. С учетом тупости Вани - он является дежурным сухим кормом на случай если захотелось потроллить.
Бред ты, Ванюш, пишешь...
Тебе как бы все вокруг намекают, что значит совместимые на бинарном уровне структуры. Не важно в каком объектном формате хранятся функции и данные, важно что после загрузки этих функций в память на выполение, результат функции написанной на одном языке программирования мог быть обработан в другой функции, написанной на другом языке программирования без использования костылей. Спецификация этого языка утверждает, что если я объявляю в Rust объект некоторой структуры, то в Си я без заморочек могу определить практически копи-пасте одноименный тип и через вызовы функций обмениваться данными между модулями не заметив разницы - если в некоторое поле А я записываю некоторое значение, то из другого модуля я прочитав это поле А получаю это же значение.
Rust и С - языки программирования. Толпа анонимов утверждает что "бинарно совместимые языки" означают что бинарник, созданный из скомпиленного кода на Rust можно прочитать из бинарника, скомпиленного из кода на С.Я утверждаю что это выполняется для любых языков программирования и компиляторов. Со мной спорят, но аргументы какие-то левые... Напр. ваши:
"если я объявляю в Rust объект некоторой структуры, то в Си я без заморочек могу ... через вызовы функций обмениваться данными между модулями не заметив разницы"
Возьмите два любых других языка - будет аналогично.
> Я утверждаю что это выполняется для любых языков программирования и компиляторов.Изначально ты утверждал какой-то булшит насчет форматов объектников. При том совершенно бредовый. То что ты туп, не владеешь терминологией и сам загнал себя в логическую ж!@у, никто тебе не виноват.
> Возьмите два любых других языка - будет аналогично.
Не будет. А попробуй между модулями одной программы напрямую паскакалю сишную строку передать. Или сям паскакалевскую. Тебя будет ждать очень интересный сюрприз. Кстати по этому поводу юзеж паскалеобразных языков в операционках писанных на си являет собой ту еще попаболь. Конвертить форматы строк в сишные при передаче их функциям ОС и наоборот при получении результатов - довольно утомительное и невкусное начинание :P.
Вы либо идиот, либо не знаете, к чему прицепиться. И то и другое выглядит, мягко говоря, не очень.Ничего, объясню, мне не жалко. Совместимость структур означает, что выполняются сишные правила по лайауту - отсутствие лишних полей, совпадающий порядок полей, в конце концов, то, что структура - это простая последовательность полей а не какое-нибудь b-дерево или хеш-таблица.
Другими словами, если отдать в C-библиотеку адрес структуры, созданной в Rust, то там с ней можно будет работать без дополнительных плясок с бубном, определив аналогичную по типам полей и порядку их следования структуру.
Свои оскорбления оставьте при себе.struct xxx
{
float f: 1;
int i: 1;
char c: 7;
}Хорошая такая структура для С. Размер = 9 бит.
Аналогичную можно построить в любом языке программирования. Хотя выглядеть её определение будет, видимо, немного иначе.
Ваша "БИНАРНАЯ совместимость" это одинаковый синтаксис? Тогда это не бинарная. Или возможность получить доступ? Тогда это бинарный, но тогда все языки бинарно совместимы.
моя "бинарная совместимость" - это возможность сунуть рустовскую
type point = {x: float, y: float};
в сишную функциюtypedef struct point {
float x;
float y;
} point;float minCoord(struct point p) {
}
в сях определить
моя "бинарная совместимость" - это возможность сунуть рустовскую
type point = {x: float, y: float};
в сишную функциюtypedef struct point {
float x;
float y;
} point;float minCoord(struct point p) {
return (p.x < p.y)? p.x :p.y
}без каких-либо преобразований.
Подобное понимает любой, кто хоть как-то работал с вызовами сишных функций из других языков, поэтому "либо идиот, либо не знаете, к чему прицепиться" - это в данном случае не оскорбление, а определение.
Эт конечно хорошо, однако как быть с так часто используемыми расширениями в Си как упакованные струтуры и хитрыми битовыми полями. В этом Rust хость ввели на уровень языка, что-нибудь подобное?
Оставь. Он пишет о чём-то своём, игнорируя всё что ему говорят. Пример с битовыми полями и структурой размером 9 бит я ему привёл, а в ответ...Ладно, не буду портить хороший день :)
Я уж не говорю про union и пр. сяшные заморочки.typedef struct _OVERLAPPED {
ULONG_PTR Internal;
ULONG_PTR InternalHigh;
union {
struct {
DWORD Offset;
DWORD OffsetHigh;
};
PVOID Pointer;
};
HANDLE hEvent;
} OVERLAPPED, *LPOVERLAPPED;
А если включить внутрь ссылку на класс, то будет ли итог "бинарно совместимым" и можно ли будет обратиться к функциями этого класса? Хрен!
>[оверквотинг удален]
> struct {
> DWORD Offset;
> DWORD OffsetHigh;
> };
> PVOID Pointer;
> };
> HANDLE hEvent;
> } OVERLAPPED, *LPOVERLAPPED;
> А если включить внутрь ссылку на класс, то будет ли итог "бинарно
> совместимым" и можно ли будет обратиться к функциями этого класса? Хрен!В Си нету никаких классов, и ссылок тоже нет, одни указатели. Вас жестоко обманули. И да, в разных компиляторах С++ (а иногда даже разных версиях одного компилятора) проблемы с именами методов разных классов решаются по-разному, в силу чего С++ бинарно несовместим сам с собой(http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_...). И Вы всё еще утверждаете, что АБСОЛЮТНО ВСЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯ™ бинарно совместимы?
struct
{
int x;
int func(int y){return x+y;}
}Хоть С, хоть С++, но когда мне было нужно ЭТО скомпилить - у меня ЭТО компилилось.
> struct
> {
> int x;
> int func(int y){return x+y;}
> }
> Хоть С, хоть С++, но когда мне было нужно ЭТО скомпилить -
> у меня ЭТО компилилось.
$ cat temp.c
#include <stdio.h>
struct
{
int x;
int func(int y){return x+y;}
} my_struct;
int main(){
my_struct.x = 1;
printf ("%d\n", my_struct.func(2) );
return 0;
}
$ gcc temp.c
temp.c:5:16: ошибка: expected «:», «,», «;», «}» or «__attribute__» before «{» token
temp.c: В функции «main»:
temp.c:9:28: ошибка: «struct <anonymous>» не содержит элемента с именем «func»
> Никогда в жизни не пользовался GCC и никогда в жизни не планирую.
> Упаси Бог от этого удолбища.А, ну конечно. В качестве примеров языков программирования следует приводить лишь включённые в состав Visual Studio, а остальные вы и за языки не считаете, так? Каюсь, был неправ.
> Упаси Бог от этого удолбища.то ли дело няшный m$vc. как там дела с поддержкой C99? что, всё по-прежнему? ах, ну да: C99 не нужен, потому что не поддерживается в m$vc. я верно догадался?
> struct
> {
> int x;
> int func(int y){return x+y;}
> }
> Хоть С, хоть С++, но когда мне было нужно ЭТО скомпилить -
> у меня ЭТО компилилось.А ты это писал в файлик с расширением ".c" или ".cpp". попробуй файлик с расширением ".c". Тогда твоя студия запустит именно компилятор для С, а не C++.
> struct
> {
> int x;
> int func(int y){return x+y;}
> }
> Хоть С, хоть С++, но когда мне было нужно ЭТО скомпилить -
> у меня ЭТО компилилось.А ты это писал в файлик с расширением ".c" или ".cpp". попробуй файлик с расширением ".c". Тогда твоя студия запустит именно компилятор для С, а не C++. И тогда такая конструкция нифига не скомпилится.
> И Вы всё еще утверждаете, что АБСОЛЮТНО ВСЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯ™ бинарно совместимы?Ещё раз поднимите глаза где я это утверждал и прочтите 2 раза. Если не поймёте о чём я - 3, 5, 10. Как поймёте осознаете как вы ошибались :)
>> И Вы всё еще утверждаете, что АБСОЛЮТНО ВСЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯ™ бинарно совместимы?
> Ещё раз поднимите глаза где я это утверждал и прочтите 2 раза.
> Если не поймёте о чём я - 3, 5, 10. Как
> поймёте осознаете как вы ошибались :)Утверждали Вы:
>Открываю вам Америку: структуры АБСОЛЮТНО ВСЕХ языков программирования "бинарно совместимы"
Так вот, открываю Вам Америку: структура данных — довольно общее понятие, которое включает в себя в том числе и классы. Бинарная несовместимость классов неизбежно свидетельствует о бинарной несовместимости структур.
А теперь ещё выше, ответом на что были мои слова. Даю подсказку: я спросил что такое "бинарно совместимые" языки программирования и мне дали ответ. Ответом на ответ была приведённая цитата.Повторяю второй раз: не нужно вырывать слова из контекста и наделять их своим смыслом.
> А теперь ещё выше, ответом на что были мои слова. Даю подсказку:
> я спросил что такое "бинарно совместимые" языки программирования и мне дали
> ответ. Ответом на ответ была приведённая цитата.
> Повторяю второй раз: не нужно вырывать слова из контекста и наделять их
> своим смыслом.Еще раз поднимите глаза к своему вопросу про бинарную совместимость и прочтите 2 раза. Если не поймёте о чём я - 3, 5, 10. Как поймёте осознаете как вы ошибались :)
подсказка: бинарная совместимость структур данных разных ЯП != бинарная совместимость ЯП.
Вы спрашивали именно про структуры данных — вы получили ответ про структуры данных, а так же то, как бинарная несовместимость структур данных может случиться на примере сишных struct. Пример был разжёван и предельно понятен — но увы, Вами он был недопонят.
Вот уж не знал что в скомпилированном коде структуры живут своей отдельной жизнью :)
Теперь вы вообще высасываете выводы из пальца или еще из какого-то органа. Прочитать комментарий что, не судьба? При чем здесь отдельная жизнь?
>[оверквотинг удален]
>ULONG_PTR InternalHigh;
>union {
>struct {
>DWORD Offset;
>DWORD OffsetHigh;
>};
>PVOID Pointer;
>};
>HANDLE hEvent;
>} OVERLAPPED, *LPOVERLAPPED;Это строки из той самой известной "Божественной комедии" Данте? Теперь я кажется знаю что такое Ад.
Вовсе нет... 8-байтный указатель сохранили как верхнюю и нижнюю часть чтобы не писать в коде макросы, теперь:Без этого ухищерения пришлось бы писать конструкции вида:
// запись
s.Pointer = (s.Pointer & 0xFFFFFFFF) | low;
s.Pointer = (s.Pointer & 0xFFFFFFFF00000000) | (high << 32);// чтение
low = s.Pointer & 0xFFFFFFFF;
high = (s.Pointer & 0xFFFFFFFF00000000) >> 32;А так получаем элегантный код:
s.offset = low;
s.offsetHi=high;low=s.offset;
high=s.offsetHi;Какое решение нравится вам? Мне второе, с использованием union.
> Вовсе нет... 8-байтный указатель сохранили как верхнюю и нижнюю часть чтобы не
> писать в коде макросы, теперь:
> Без этого ухищерения пришлось бы писать конструкции вида:Эт, понятно и нормально.
> Какое решение нравится вам?
Мне больше нравится не писать с использованием так называемой венгерской нотации. Хотя при использовании WinAPI видимо приходится смиряться.
Вы пожаловались на ад, я объяснил нормальность и услышал "это понятно и нормально". Зачем было жаловаться?Я спросил какое из решений: с использованием union или без него нравится лично вам, а в ответ узнал что вам не нравится венгерская нотация в WinAPI.
У вас, случайно, не разделение личности? Утром вы одна, вечером другая (с) Шрек.
> Какое решение нравится вам? Мне второе, с использованием union.А мне нравится решение, в котором ваш код окружён строчками:
#if sizeof(void*) == 8
/* здесь находятся обьединения, включающие в себя структуры */
#endif
Ибо не факт, что Ваш код будет компилироваться для 64хбитной системы.
Да и тот факт, что элементы структуры выравниваются по границе 4 байт, а не 8ми, сомнителен. Во втором случае Ваш s.Pointer будет содержать какой-то совершенно левый указатель, а s.offsetHi окажется не у дел. Вот и выходит, что
// запись
s.Pointer = (s.Pointer & 0xFFFFFFFF) | low;
s.Pointer = (s.Pointer & 0xFFFFFFFF00000000) | (high << 32);// чтение
low = s.Pointer & 0xFFFFFFFF;
high = (s.Pointer & 0xFFFFFFFF00000000) >> 32;
хоть и менее элегантно, но зато гарантированно работает.
Вы в шаг от моего любимого:a=b+c;
if(a<>b+c){...}:)
> Размер = 9 бит.Чуров нервно покуривает в сторонке...
В сях вы ещё девственны. Ох, как много вам ещё предстоит узнать...
> В сях вы ещё девственны. Ох, как много вам ещё предстоит узнать...Угу, особенно про побитное выравнивание данных в памяти.
> В сях вы ещё девственны. Ох, как много вам ещё предстоит узнать...Да, загнать столько данных в 9 битов - даже волшебнику Чурову слабо! :)
>> В сях вы ещё девственны. Ох, как много вам ещё предстоит узнать...
> Да, загнать столько данных в 9 битов - даже волшебнику Чурову слабо!
> :)Особенно радует однобитный float.
> Особенно радует однобитный float.ыыыыыы! а я сразу-то и не приметил! да ванюша просто мегаотжигает сегодня!
Просто пример. Возможности языка это позволяют.
> Просто пример. Возможности языка это позволяют.Угу, только выравнивания адресов по границе N байт в памяти никто не отменял. Напоминяю, минимально адресуемая единица информации в любом процессоре — байт; в современных процессорах байт всегда равен октету битов; эрго, хоть Ваша структура и выглядит 9тибитной, но меньше двух байт занимать не может.
Хмм... Язык Си может использоваться для написания программ только на процессорах где в 1 байте 8 бит и только на компьютерах где выравнивание по 1 байту?
Язык Си может использоваться для написания программ только на процессорах, для которых предусмотрен компилятор. Так уж получилось, что во ВСЕХ процессорах в 1 байте по 8 бит. Выравнивание не во всех компьютерах по 1 байту — чаще по 4 или 8, однако именно кратно байту — во ВСЕХ процессорах. Так что — да, в данный момент (25 января 2012 года) Си может использоваться для написания программ только на процессорах где в 1 байте 8 бит и только на компьютерах где выравнивание по (целое число) байт.
> Язык Си может использоваться для написания программ только на процессорах, для которых предусмотрен компилятор
> Си может использоваться для написания программ только на процессорах где в 1 байте 8 бит и только на компьютерах где выравнивание по (целое число) байт.Можно написать программу для процессора в котором 10 бит - да, можно скомпилировать - сейчас нет. Но вы, почему то, утверждаете что даже написать такую программу нельзя. Обманываете.
> Выравнивание не во всех компьютерах по 1 байту — чаще по 4 или 8
Вы не знаете что такое выравнивание, для чего оно служит и как работает.
Очередной пример вашего невежества, да.
Нет, не все. К примеру, для высокопроизводительных числодробилок можно написать реализацию языка, который бы для массивов структур делал несколько массивов для каждого поля в структуре.
Поправлюсь: если возможности языка это позволяют. Сути это не меняет: бинарные данные могут быть прочитаны программой, на каком бы языке эта программа не была написана.
> Поправлюсь: если возможности языка это позволяют. Сути это не меняет: бинарные данные
> могут быть прочитаны программой, на каком бы языке эта программа не
> была написана.А вот хрен. Возьмите к примеру сишную строку. Её размер не известен заранее и может занимать хоть всю доступную память, посему паскаль, в котором array[0..7]of char и array[0..65535]of char — разные типы (и даже array[0..7]of char и array[1..8]of char), с сишной библиотекой обработки строк общаться не сможет, особенно в случаях, когда сишная функция возвращает строку.
Строка не "сишная", а ASCII-Z. Это просто формат. Вам знакомо слово "формат"? И после этого вы удивляетесь что данные одного формата не могут быть обработы функцией, предназначенной для обработки данных другого формата?
> Строка не "сишная", а ASCII-Z. Это просто формат. Вам знакомо слово "формат"?
> И после этого вы удивляетесь что данные одного формата не могут
> быть обработы функцией, предназначенной для обработки данных другого формата?В данном случае, дражайший, строка — это тип. Сишной функции strcat МОЖНО дать то, что строкой называют в паскале (при условии соблюдения того самого формата — 0 в конце строки). Тем не менее возвращённая этой функцией строка не будет совместима с паскалем — паскаль, будучи [неоправданно]строго типизированным, ожидает, что тип возвращаемой функцией значения заранее известен, где в тип для него входит размер возвращаемого значения. Это и есть то, что называется бинарной совместимостью: строку, в которой > 256 символов, паскаль не проглотит.
В Си нет типа строка. Этим он отличается от многих ЯВУ, и максимально приближен к ассемблерам и аппаратуре. Есть тип "символ" (char), строки хранятся в формате (ФОРМАТЕ), который определил программист. Функции библиотеки string.h оперируют ASCII-Z строками.При серьёзном академическом изучении Паскаля, как и других ЯП, на этом также акцентируют внимание.
> В Си нет типа строка. Этим он отличается от многих ЯВУ, и
> максимально приближен к ассемблерам и аппаратуре. Есть тип "символ" (char), строки
> хранятся в формате (ФОРМАТЕ), который определил программист. Функции библиотеки string.h
> оперируют ASCII-Z строками.
> При серьёзном академическом изучении Паскаля, как и других ЯП, на этом также
> акцентируют внимание.
> В Си нет типа строка.Зато он есть в паскале. В си есть тип "указатель на символ", посредством которого реализованы строки переменной длины — наш пример структуры данных. В паскале строк переменной длины нет и реализовать их не выйдет — эрго, имеем бинарную несовместимость структур данных. Дальше разжёвывать или сам проглотишь?
Вообще то в Паскале никто не запрещает создать динамический массив типа СИМВОЛ.char *s=new char[500];
strcpy(s,"long string\0"); // явный ноль-терминаторint len=0;
while(s[i])len++;Никто не мешает повторить это с паскалевским синтаксисом. Не нужно лениться.
>Никто не мешает повторить это с паскалевским синтаксисом. Не нужно лениться.Proof or GTFO.
Я понять не могу, вы чего к паскалевской строке докопались - вы можете создать указатель на массив символов, даже в турбо-паскале:
var str type ^pchar;
как-то так
А адресную арифметику потом использовать?
И да, Pascal <> Object Pascal. Так и сам Вирт сказал. В оригинальном паскале ни указателей, ни адресной арифметики нет.
>В си есть тип "указатель на символ", посредством которого реализованы строки переменной длины — наш пример структуры данных. В паскале строк переменной длины нет и реализовать их не выйдет — эрго, имеем бинарную несовместимость структур данных. Дальше разжёвывать или сам проглотишь?Вы бы почитали что ли про паскаль что нибудь, ну там где про указатели пишут чтоле, заодно задумались бы как это апи функции в паскаль программах на раз-два вызываются и к любым ц библиотекам обертки написаны, я уж не предлагаю про новые строки которым всего лет 20 почитать а то шаблон разорвется.
В Pascal нет указателей. Вообще. Спросите хоть Никлауса Вирта. А всякие монстры франкенштейна из мира языков программирования, имеющие в названии слово "Pascal", с паскалем имеют мало общего.
В советском самоучителе Паскаля 1976 года указатели уже были.
Ну, советскому самоучителю явно лучше знать, чем тому, кто этот язык создал.
> В советском самоучителе Паскаля 1976 года указатели уже были.У меня нет такого самоучителя, но могу предположить, что адресной арифметики не было.
Наверное, можно как-нибуть "непереносимо" (в обоих смыслах) выкрутиться. А new()/dispose() не слишком удобны в случае манипуляций ASCIIZ
Ну уж не знаю... В Си мне new/delete (они же malloc/free) для манипуляции ASCII-Z хватало.
Наверное, давно это было.
В C нет new/delete (это в C++), только malloc/free
Но в С у malloc вы можете запрашивать произвольный объём данных,
а pascal-евские new()/dispose() не так гибки - они выделяют память только под один элемент.Если вы напишете
var p: PChar;
...new(p);
то из кучи будет выделен 1 байт.
в turbo pascal есть procedure GetMem(Var P : Pointer; Size : Word); и FreeMem ей в пару,
но ваш старинный самоучитель может о такой и не знать.
Я открою вам Америку:
1. программа в конечном счёте будет выполняться в среде ОС. И вызовы new/malloc/.. в конечном счёте сведутся к вызову функции выделения памяти в ОС, в случае Windows ей станет HeapAlloc. Если ваш компилятор вас настолько ограничивает - используйте функции ОС напрямую.
2. если вы будете продолжать оперировать компиляторами 60-х и 70-х годов прошлого века, то наш разговор не сложится. Любой язык живой, он изменяется согласно изменяющимся реалиям жизни. И в современных реализациях языка Паскаль можно выделить блок памяти любого размера.
> в случае Windows ей станет HeapAllocванюша, ну вот зачем ты опять полез туда, где ничего не смыслишь? нет, я понимаю, что это привычка — но постарайся её контролировать. и почитай, что ли, о стратегиях выделения памяти в своей любимой недоос.
хинт: в хипаллок попадём далеко не всегда. может, и вовсе не попадём.
> В Си мне new/delete (они же malloc/free)«Мария Колыванова, она же Манька Облигация», ага. мало того, что в C нет ни new, ни delete: ванюша у нас считает, что new — аналог malloc, а delete — аналог free…
ванюша, позорище наше ходячее, выучи brainfuck и говори только о нём: остальные языки для тебя слишком сложны.
> посему паскаль, ... с сишной библиотекой обработки строк общаться не сможет, особенно в случаях, когда сишная функция возвращает строку.20 лет анабиоза, я бы тоже так хотел
Delphi strings are a complete replacement for Pascal strings. They have a 4-byte length field (i.e. they can hold 2Gb, or until you run out of memory, whichever comes first), are always null-terminated for easy use with OS functions, and have reference counting with copy-on-write.
> 20 лет анабиоза, я бы тоже так хотелтак у тебя и… Delphi — не паскаль, а Delphi.
А чем их vala не устроила?
И безопасность, а автоуправление памятью, и распараллеливание - всё есть.
И не нужно ждать пока оптимизатор допилят - вала компилируется в С, для которого всё уже заоптимизировано по самое не балуйся :)
Наверное потому, что Вала отдает Джавой и пошарпанным Си.
ну и?
Это значит пока хардкорной оптимизации и невероятно сложное прогнозирование скорости исполнения кода.
Потому что профиль dova (без glib) так и не доведён до рабочей альфы.
> Наверное потому, что Вала отдает Джавой и пошарпанным Си.Она просто не ими написана :D:D:D:D:D
в вале вроде полное ООП головного мозга? Это как бы не очень хорошо.
> А чем их vala не устроила?NIH. Каждая команда должна написать свою операционку, браузер и язык программирования. Даже если половина из них будут нафиг никому не нужны :)
>> А чем их vala не устроила?
> NIH. Каждая команда должна написать свою операционку, браузер и язык программирования.
> Даже если половина из них будут нафиг никому не нужны :)Фатальный недостаток же :D:D:D:D
Лучше скажите, чем их D не устроил. Тут же соврешенно явно по мотивам написано, и сложность не меньше. С другой стороны - язык, в общем-то, инетересный. После того как понаступают на грабли и выпустят следующую версию (как у D и было, и как бывает у любого языка с кучей экспериментальных фич) - может оказаться вполне рабочим. И даже если нет - это полигон дя обкатки этих самых фич, а особенно - их взаимодействия, на которое и приходится 90% проблем. Так что как ни крути - хорошо, что делают.
> А чем их vala не устроила?
> И безопасность, а автоуправление памятью, и распараллеливание - всё есть.
> И не нужно ждать пока оптимизатор допилят - вала компилируется в С,
> для которого всё уже заоптимизировано по самое не балуйся :)Rust, Vala, D, Go, ещё десяток других...
Я думаю, просто дошли до того уровня технологий, когда такой язык (и переводчик из него в Си, чтобы не мучаться с глубинным уровнем компиляции и взять готовые средства) способен написать любой продвинутый студент. И теперь идёт борьба вариантов.Я бы апеллировал в этой возне за Go, если бы он не был таким эстетически уродливым (чисто на мой вкус), а за 0 как префикс восьмеричной константы в XXI веке и прочие раритеты я бы просто расстреливал на месте. В Rust хоть этого нет - чуть лучше умеют чиститься от прошлых гадостей. Но надо смотреть и на другие особенности.
Вот зачем в определении функции добавлять fn, с ним синтаксис выглядит как-то коряво.
Там у них этого "зачем" - талмуд написать можно. А еще больше будет, когда попытаются со всем этим взлететь. Уже то, что тип структуры определяется её полями, а не именем, создаст им массу проблем вида "суммируем груши с чемоданами".
> проблем вида "суммируем груши с чемоданами".И получаем чемодан груш. Вроде все логично :)
Это если код ожидал, что получит груши и чемоданы. А тут скорее получим чемоданогрушу... ну или грушечемодан, как больше нравится.
чемодан груш, это, очевидно, чемодан умноженный на грушу, а не сумма.
Однако, груши с чемоданами сложатся только тогда, когда их программист сложит.
Ослабление статического контроля типов, конечно, может показаться регрессом по сравнению со многими другими языками. Нужно смотреть, что такой ценой "покупается".
>Уже то, что тип структуры определяется её полями, а не именем...Для библиотек на динамических языках это норма и называется duck typing, может для этого.
> Вот зачем в определении функции добавлять fn, с ним синтаксис выглядит как-то коряво.Вероятно, для грамматики LL(1).
Довольно полезное свойство для ускорения компиляции и формирования понятных сообщений.
И поэтому они сделали шаблоны через <>...
> И поэтому они сделали шаблоны через <>…а это уже потому, что: «а? как? что? можно и по-другому? ёлы-палы… алё! пацаны! срочно всё переделываем, тут малява пришла, что шаблоны можно делать и не так, как в C++!»
Если рассматривать шаблон как своего рода функцию, то использование круглых скобок было бы предпочтительнее. Но автор решил использовать <>, и написал подходящую LL(1) грамматику. Очевидно, автор не собирается параметризовать шаблоны произвольными выражениями, а только именами типов. Поэтому затруднений подобных затруднениям при компиляции шаблонов в C++ нет.Право слово, на практике применялись языки с более серьёзными заморочками в синтаксисе.
Вспомните PL/I или Pick BASIC. В первоначальном варианте языка C были операторы типа =+, которые потом заменились на +=. А тут версия 0.1, всё ещё может измениться.
на самом деле всё выглядит намного проще: дизайном языка никто не занимался. собралась Могучая Кучка и решила, что вместо нормального дизайна вполне покатит солянка из фич. не то, чтобы это было очень плохо, но всё-таки…
Ага, у меня такое же впечатление собралось. Это не просто не плохо - это очень полезно - в отличие от тщательно разработанной системы такая солянка даёт довольно свободно добавлять/удалять/менять фичи, так что в смысле наработки опыта создания языков тут очень много выгод. А взлетит/не взлетит - от качества языка, конечно зависит - но весьма слабо. Чего стоит только веб - подавляющее большинство серверов - PHP, а на клиентах застрял JS (и эти люди называют Перл write-only языком!). На их фоне проблемы какого-нибудь D или Rust - детские игры. Хотя PHP сейчас сильно окультурили, конечно - вон, даже типизацию тихой сапой вводят.
js нормальный вполне, хоть и корявый немного.а вот насчёт создания языка… оно, конечно, ничего бы — но авторы, я так понимаю, делают это на деньги тормозилла фаундэйшн? честное слово: если бы я давал тормозилле денег, то немедленно бы прекратил. я понимаю, когда студенты от избытка сил играют в то, во что взрослые уже наигрались и знают, как не надо делать; но когда достаточно взрослые и опытные, вроде бы, лбы — и занимаются тем же самым, да ещё и на зарплате… неплохо устроились, тоже хочу ваньку валять за деньги. да хоть здешнего.
Я не знаю как популярен станет этот язык,
но название реализации от МикроСофт должно начинатся с приставки Пидо
во, неужели наконец альтернатива так и не взлетевшему D нарисовалась?