Процесс портирования и создания средств разработки программ для KolibriOS продолжается. По наиболее активно используемым языкам программирования мы публикуем статьи. Сегодня мы начинаем рассказывать о языке С--, вокруг которого сложилось активное сообщество в 2000-е годы. Подробности под катом.
Кратко о языке с официального сайта:
C-- — это язык программирования, занимающий промежуточное положение между ассемблером и Cи. Идеально подходит для написания маленьких программ, резидентов (TSR), драйверов, обработчиков прерываний. Для работы с языком C-- необходимо знакомство с ассемблером и Cи. Сейчас С-- умеет генерировать 32-битный код под ДОС и Windows (прим. ред. а также под MenuetOS, KolibriOS).
Автором языка SPHINX C-- является Peter Cellik (CANADA). Последняя авторская версия SPHINX C-- v0.203 от 28.Oct.96. К сожалению автор отказался от дальнейшего развития языка. Сам язык вместе с исходные текстами был объявлен сиротой и отдан никому в никуда. Т.е. делайте что хотите. А почему бы и не сделать? На этой страничке Вы найдете самую последнюю (но уже не авторскую) версию самого языка, библиотеки, примеры программ, описание самого языка и библиотек в формате Notron Guide и много другой полезной информации по языку C--.
После Питера Селлика поддержкой занимался Михаил Шекер, но он прекратил разработку несколько лет назад. В прошлом году исходники были выложены на Github https://github.com/jossk/c--sphinx, но мы узнали об этом только в марте 2016 года.
Было решено рассказать о данном языке по двум причинам:
- На нём написаны несколько популярных программ KolibriOS, среди которых и Eolite — пожалуй, самый используемый файловый менеджер.
- Относительно недавно компилятор данного языка был портирован для KolibriOS (ответ на вопрос о лицензии можно найти тут).
Немного о процессе портирования от GerdtR:
Итак. Сначала я переделал код под gcc. Исходники просто были написаны для Watcom C, ну и пусть не значительная, но несовместимость была. Исправил пару названий переменных(extern в ваткоме можно, видимо), и обозначение 64битных чисел по другому. Потом уже Leency выявил, что gcc-версия совсем не ищет файлы в текущей папке, только в папке с самим экзешником. Когда и это исправил осталось самое сложное: порт для Колибри. Ну так как под С я в КОС не писал, то была стандартная проблема — с кем линковать, да и какие инклудники брать. Выбор не широкий, menuetlibc отпал сразу, как я, покопавшись в исходниках, увидел ещё старые функции обращения к файлам(ф56 вроде). Короче menuetlibc устарел сильно, остался newlib. Долго разбирался, как всё таки на выходе получить kex, а не PE, помог один Makefile, где писалась дополнительно обработка objcopy. Ну а дальше уже дописывание функций, которых нет в newlib(например stat не было, в port.c лежит его реализация). Ну и пара функций преобразования кодировок ANSI->ASCII, а точнее заглушек, потому как русских букв всё равно в строках компилятора нет. Ну и последней проблемой было, да и частично осталось вот это: из-за newlib(скорее всего, больше некому) текущий каталог устанавливается как путь до самого сmm(а обычно /rd/1), потому оказывается, что узнать, где лежит исходник компилятор не может, хоть откуда его запускай. Выход на данный момент — копировать компилятор в папку с исходниками, либо указывать абсолютный путь. Кстати, раньше символ '/' считался началом параметра и абсолютный путь указать было не возможно, сейчас можно. Но с абсолютным путём пока не уверен, что инклудники находить будет. Пока что-то не хочется с этим возиться, да и можно просто написать -IP="/hd1/1/my_source". В теории должно работать, на практике никто не спрашивал. Кстати… указать в форуме что ли, что параметры через '-' указывать теперь… И при запуске без параметров, в той таблице поправить, а то некоторая путаница получается. Ладно, потом как-нибудь. Ну вот в общем, вся история. Самое сложное было — это разобраться, откуда брать либы :) Сам код довольно несложный, не в супер порядке, но особо ковыряться в коде не пришлось
Руководство по языку находится по ссылке http://www.c--sphinx.narod.ru/c--doc.htm. Рассмотрим пример простого приложения для KolibriOS:
#define MEMSIZE 4096*10
#include "../lib/io.h"
#include "../lib/gui.h"
void main()
{
word id;
dword file;
io.dir.load(0,DIR_ONLYREAL);
loop() switch(WaitEvent())
{
case evButton:
id=GetButtonID();
if (id==1) ExitProcess();
break;
case evKey:
GetKeys();
if (key_scancode == SCAN_CODE_ESC ) ExitProcess();
break;
case evReDraw:
draw_window();
break;
}
}
void draw_window()
{
proc_info Form;
int i;
DefineAndDrawWindow(215,100,350,300,0x34,0xFFFFFF,"Window header");
GetProcessInfo(#Form, SelfInfo);
for (i=0; i<io.dir.count; i++)
{
WriteText(5,i*8+3,0x80,0xFF00FF,io.dir.position(i));
}
DrawCaptButton(100, 10, 100, 22, 22, 0xCCCccc, 0x000000, "Button");
WriteText(100,50,0x80,0,"Textline small");
WriteText(100,70,0x90,0,"Textline big");
DrawBar(100, 110, 100, 100, 0x66AF86);
}
Как видите, данный код почти не отличается от кода на Си, но при этом есть возможность писать спокойно в почти ассемблерном стиле, аналогично написанию оберток для системных функций. Например, функция создания окна:
void DefineAndDrawWindow(dword x, y, size_w, size_h, byte WindowType,dword WindowAreaColor, EDI, ESI)
{
EAX = 12;
EBX = 1;
$int 0x40
$xor EAX,EAX
EBX = x << 16 + size_w;
ECX = y << 16 + size_h;
EDX = WindowType << 24 | WindowAreaColor;
$int 0x40
EAX = 12;
EBX = 2;
$int 0x40
}Чем же он привлекателен для разработчиков ПО для KolibriOS? Во-первых тем, что начать писать на нём очень легко. Это был единственный язык, не считая FASM, на котором можно было просто начать писать, не заморачиваясь с настройкой кросс-компиляции (сейчас в этом деле Си уже набирает обороты). Во-вторых, для C-- было написано множество библиотек и различных оберток над системными функциями. Среди них собственный набор элементов интерфейса и даже неплохие шрифты:
Вы наверняка зададитесь вопросом: если всё так прекрасно, то в чем же проблема? Почему он не применяется повсеместно, хотя бы в рамках проекта KolibriOS?
Ответ следующий. Несмотря на преимущество в простоте освоения, при его использовании всплывают и недостатки:
- плохая оптимизация результирующего кода;
- практически отсутствуют приоритеты операций (C-- всё считает слева направо, т.е. 2+2*2=8, а не 6);
- самое главное, хоть он и похож на Си, но это другой язык программирования со своей сферой применения. В рамках KolibriOS он наиболее подходит для создания программ с графическим интерфейсом и почти не применяется в системном программировании.
Комментарии (57)
prostofilya
20.07.2016 18:01+2Не понимаю почему, но мне очень симпатичен этот интерфейс
NeoCode
20.07.2016 18:03Интерфейс кстати да, очень приятный, теплый и ламповый.
Единственное — в Eolite левая область окна с информацией об устройствах — «закос под винду», как-то подумалось что это лишнее.
NeoCode
20.07.2016 18:02Я как любитель всяческих языков программирования, когда-то очень давно смотрел и на этот язык. Конечно интересные идеи есть (хотя-бы прямой доступ к регистрам), но вот отсутствие приоритетов операций это конечно нечто. Странно как минимум.
По поводу оптимизации… странно требовать оптимизации от языка, занимающего промежуточное место между Си и Ассемблером. Ведь по сути это тот же Ассемблер, только чуть более структурированный, и по идее в таком языке должна быть не оптимизация, а однозначные и задокументированные правила преобразования высокоуровневых констуркций в код.
RiseOfDeath
20.07.2016 18:52+9>практически отсутствуют приоритеты операций (C-- всё считает слева направо, т.е. 2+2*2=8, а не 6);
Мне кажется, что это довольно фатальный недостаток, причем его исправление поломает старые программыNeoCode
20.07.2016 20:15Именно так. Можно конечно выпустить C--2.0, с другим расширением файла или требованием в начале файла какой-то директивы типа "#version 2", чтобы можно было различать синтаксисы… написать по сути новый язык с полным редизайном и учетом всех ошибок и недоработок старой версии, но обеспечить линковку старых и новых файлов, затем постепенно перевести код на новую версию. Поскольку кода немного, то все вполне реально… вот только нужно ли это кому-то?
Punk_Joker
21.07.2016 01:23+2вероятность есть, но программ на нем не так много, покрайней мере под Колибри, так что не критично.
IIvana
21.07.2016 05:06-4>практически отсутствуют приоритеты операций (C-- всё считает слева направо, т.е. 2+2*2=8, а не 6);
>Мне кажется, что это довольно фатальный недостаток, причем его исправление поломает старые программы
Вы что, серьезно? Оценивать язык программирования не по семантике, выразительности и наличию концепций и средств, а по синтаксису алгебраических выражений? Тогда Lisp с его полным отсутствием приоритетов операций наверное очень плохой язык. И Smalltalk с его полным аналогом приведенного https://ideone.com/TsBHuS — тоже. Ну да, это же мертвые языки, которые не содержат никаких интересных и революционных концепций, а весь мейнстрим пишет на настоящих нормальных языках, в которых арифметика на бинарных инфиксных операциях с понятным еще с первого класса приоритетом…NeoCode
21.07.2016 10:48+4Существуют стандарты (в том числе — «де факто») на разные вещи в нашем мире, ломать которые без крайней необходимости совершенно не нужно. Все математики употребляют "+" для сложения, а если какой нибудь один придумает вместо плюса использовать собачку "@", это будет хорошо или плохо? Хорошо лишь в том случае, если это даст фундаментальный прорыв в математике; в остальных случаях — плохо.
Также и с приоритетами. Так сложилось, что человечество использует инфиксную запись с приоритетами. Для компилятора нет никаких проблем реализовать построение AST с приоритетами. Тогда зачем ломать мозги миллионам программистов на ровном месте?gaki
21.07.2016 11:41Ага. Все математики употребляют для умножения ничего, но иногда точку, хотя бывает, что и косой крестик. Если программисты вместо этого «ничего» употребляют *, хорошо это или плохо?
NeoCode
21.07.2016 13:01Хорошо. Потому что запись на бумаге для человека и запись в файл для человека и машины — это разные вещи.
DarkEld3r
21.07.2016 12:31+2Вот только лисп сюда приплетать не надо. Он необычный/непривычный (если с него не начинать, конечно) — это да. Но давайте представим, что мы его совсем не знаем и смотрим на код:
(+ 1 2 (- 3 4) 5)
Да, будет непривычно/непонятно. Но как только мы понимаем префиксную нотацию, то всё становится прозрачно. Про приоритеты задумываться не надо и самое главное — нет конфликта с уже имеющимися знаниями и привычками. А вот если мы видим код
2+2*2, то весь наш опыт будет протестовать против результата, который выдаст С--.
И да, Smalltalk меня этим тоже напрягает. Но в нём за отсутствием приоритетов стоит идея того, что все операции — это посылка сообщений. А вот в C-- оно зачем?
IIvana
21.07.2016 18:59-1Вот только не надо расплетать отсюда Лисп, оставляя несостоятельные претензии к С-- и Смолтоку. В Лиспе вам все понятно и логично, значит? А свертки по немоноидальным операциям (или словами Лиспа, базовые арифметические функции переменной арности) типа (- 1) (- 1 2) и (- 1 2 3) вам сразу и интуитивно понятно как будут вычисляться? Мне то не составляет труда, я пару Лиспов накостылил. Более того, я допускаю варианты трактовки (- 1) как 1 и как -1 в зависимости от реализации. Но немало близких (т.е. не особо далеких) индивидов предъявляют подобные претензии Лиспу. И претензия к сабжу со Смолтоком из того же числа. Я понимаю зачем оно так в Смолтоке. Я смутно догадываюсь, почему оно так в С--. Но если это главный недостаток языка, а других недостатков нет — то он просто идеален тогда.
DarkEld3r
21.07.2016 19:19типа (- 1) (- 1 2) и (- 1 2 3) вам сразу и интуитивно понятно как будут вычисляться
"Совсем сразу" — нет. После того как понял базовый принцип — вполне. Тут главное, что оно предыдущему опыту никак не противоречит.
Я понимаю зачем оно так в Смолтоке
Я тоже, именно поэтому претензий и не выдвигаю. Не знаю откуда столько агрессии.
смутно догадываюсь, почему оно так в С--
Ну так озвучьте. Потом можем порассуждать приносит ли это какие-то преимущества или нет.
Но если это главный недостаток языка, а других недостатков нет — то он просто идеален тогда.
Это вообще к чему? Где я о качестве языка высказывался?
IIvana
21.07.2016 19:36>Не знаю откуда столько агрессии.
От обилия близких индивидов на харбе (впрочем, как и везде), которые пишут глупости.
> Ну так озвучьте. Потом можем порассуждать приносит ли это какие-то преимущества или нет.
Думаю, это было как минимум удобнее разработчику компилятора, но ценой неудобства пользователей. Можно ли написать какой-нибудь препроцессор для перевода из стандартной нотации? Конечно, об этом ниже писали уже. В Лиспе тоже можно макросы инфиксных бинарных операций написать.
> Это вообще к чему? Где я о качестве языка высказывался?
К тому, что вы поддерживаете критиков языка из-за одного момента реализации его синтаксиса. Я С-- не знаю и использовать вряд ли буду, но в Смолтоке тот же самый синтаксис арифметики. Это то же самое, как если кто-то вам (как Rust-аману) будет говорить, что Rust плохой потому что там синтаксис плохой или скобочки не те.DarkEld3r
22.07.2016 10:55Думаю, это было как минимум удобнее разработчику компилятора, но ценой неудобства пользователей.
Отличный подход, ничего не скажешь.
Это то же самое, как если кто-то вам (как Rust-аману) будет говорить, что Rust плохой потому что там синтаксис плохой или скобочки не те
Регулярно говорят, но на людей я не бросаюсь. (:
И да, в расте есть куча моментов которые мне не особо нравятся. Как из-за (не)привычности, так и "более объективных". И к аргументированной критике отношусь совершенно спокойно, даже с интересном: любопытно же узнать, что разным людям в глаза бросается. Довольно занятно как раст воспринимается людьми в зависимости от их "любимого языка". И в общем-то это довольно важно, если мы хотим новый язык продвинуть: каждая "необычность" должна быть чем-то обоснована, иначе будет сложнее отвоёвывать целевую аудиторию.
Повторюсь касательно Смолтока: я понимаю почему так сделано и понимаю, но там оно хотя бы "логично" в рамках языка. И собственно, является продолжением его особенностей.
gaki
22.07.2016 11:24+1> Думаю, это было как минимум удобнее разработчику компилятора (...)
Для всего языка парсер написал, а такая примитивная вещь, как арифметические выражения, стала последней соломиной? :)
IIvana
21.07.2016 19:40ЗЫ >Тут главное, что оно предыдущему опыту никак не противоречит.
(- 1) = 1 не противоречит?
length (1, 2) = 1 не противоречит?
Во многих интересных языках можно найти что-то «противоречащее предыдущему опыту». Но можно обогащать свой опыт, а можно «не пущать» и «Катерина, доколе» (С)DarkEld3r
22.07.2016 11:04+1(- 1) = 1 не противоречит?
Тут противоречит разве что минус работающий по разному в зависимости от того есть пробел или нет. С другой стороны, о том, что разделителем является пробел и о том как выглядит вызов функций мы, скорее всего, узнаем из любого букваря ещё до того как до арифметики дойдём.
Во многих интересных языках можно найти что-то «противоречащее предыдущему опыту».
Разумеется. Но я с самого начала говорил, что ценность "оригинальности" имеют не сами по себе, а вместе с новыми возможностями. Или вы с этим не согласны? А то ведь можно "обогащать свой опыт" вещами типа brainfuck или ещё лучше — whitespace.
gaki
21.07.2016 06:44-1Не понимаю, почему это вообще «недостаток»? Никакой прямой или обратной совместимости с другими языками же не предполагается, значит, это не недостаток, а особенность языка, о которой просто надо знать.
RiseOfDeath
21.07.2016 11:06+4По-тому что приоритет операций мы познаем еще во втором классе, когда проходим умножение. А тут хоп… и разрыв шаблона, причем разрыв шаблона в такой базовой, с точки зрения картины мира, вещи, как элементарная алгебра.
Это все равно, что вам завтра скажут, что -2 * -2 = -(2 * 2) = 4 (а почему бы и нет? это настолько же тупо, насколько 2 + 2 * 2 = 8)или 0 > 1RiseOfDeath
21.07.2016 11:15ой… наисправлял, блин…
Я имел ввиду -2 * -2 = -(2 * 2) = — 4gaki
21.07.2016 11:51+1Вы сами-то поняли, что написали? -2 * -2 = -(2 * 2) меняет как раз базовые положения алгебры о том, что такое умножение. Не то чтобы это само по себе преступление — можете упороться и, взяв это тождество за аксиому, развить собственную алгебраическую теорию чисел :) Она окажется ненужной по причине отсутствия связи с материальной реальностью, но это уже другой вопрос.
Тогда как 2 + 2 * 2 = 2 + (2 * 2) или (2 + 2) * 2 — это не фундаментальное различие математических теорий, а тривиальное различие алгебраической нотации в рамках одной и той же математической теории. Приоритет операции умножения над операцией сложения, которому учат в школе — не фундаментальный закон мироздания, а соглашение о записи, нужное только и исключительно лишь для экономии скобочек при записи.Vjatcheslav3345
21.07.2016 14:29"Приоритет операции умножения над операцией сложения, которому учат в школе — не фундаментальный закон мироздания, а соглашение о записи, нужное только и исключительно лишь для экономии скобочек при записи."
Что то я это не совсем понял — а как же тогда мы можем строить мосты, туннели и коллайдеры — ведь их строят по предварительным расчётам, и, часто в единственном уникальном экземпляре — не то что табуреты.
gaki
21.07.2016 11:21Ни во втором, ни даже в третьем классе мы не познаём приоритет операций битового сдвига, логического отрицания, разыменования указателя или приведения типа. Да и много чего ещё. Даже приоритет операций ++x и x++ не познаём. И таки это большая проблема?
При этом шаблоны гнутся и трещат, например, при изучении комплексных чисел (еще в пятом классе мы познали, что извлекать квадратный корень из отрицательного числа нельзя!), при изучении пределов (мы же уже познали, что делить на ноль нельзя!), при изучении теории вероятностей (что это, вообще, за число, которое может три, а может пять, а может ноль??). И это таки тоже большая проблема?
При этом существуют другие формы записи алгебраических выражения — всякие префиксные и постфиксные нотации, например, прямая и обратная польская нотация, и даже — о боже! — языки, на них основанные. И это тоже большая проблема? Запретить, всё запретить, тому ли нас во втором классе учила Марьванна, доколе же, Катерина, будешь испытывать ты наше терпение…DarkEld3r
21.07.2016 12:34+3При этом существуют другие формы записи алгебраических выражения — всякие префиксные и постфиксные нотации
Так они, как правило, применяются ради чего-то, а не просто так. Скажем, префиксная нотация лиспа помогает парсить однозначно и упрощает работу с кодом как со списками. То есть, новшества хороши когда дают какие-то преимущества. А оригинальность ради оригинальности только оттолкнёт людей.
gaki
21.07.2016 12:49+1Действительно, не стоит, без веских причин, отступать от конвенции, даже если эта конвенция не несёт никакого глубокого смысла и существует лишь потому, что так сложилось исторически. Я, честно говоря, понятия не имею, почему в С-- конвенция нарушена, но, может, причины таки есть? Я знаю только еще об одном языке программирования, использующем инфиксную нотацию без приоритета операторов — это язык J. Там, насколько я помню, так было сделано потому, что синтаксис языка построен вокруг идеи композиции унарных и бинарных операторов.
kvark
20.07.2016 19:48+6Феноминально, что язык ещё жив. Я в своё время писал на нём всякие мандельбротики, визуализаторы игры жизнь, архиваторы, и прочую мелочь. Тогда это казалось востребованным, ибо компилятор С не был так умён. Сегодня же, не вижу смысла уползать ниже Rust/C без лишней необходимости.
Boletus
20.07.2016 21:01-1> Тогда это казалось востребованным, ибо компилятор С не был так умён.
Вопрос безо всякого подтекста — а в чем именно компилятор Си не был так умен?
Punk_Joker
21.07.2016 01:25+1Поддерживаю вопрос выше. Просто я начал знакомится с Си где-то в 2011, и не могу сейчас понять в чем может быть преимущество С--, перед обычным Си.
RiseOfDeath
21.07.2016 11:14Вероятно что тут нет асемблерных вставок, как таковых, есть просто тупо прямые асемблерные команды (насколько я понял).
mamkaololosha
20.07.2016 21:51+4> практически отсутствуют приоритеты операций (C-- всё считает слева направо, т.е. 2+2*2=8, а не 6);
Это превратит код в lisp и убьет вообще какую-либо совместимость с С-like.
Vjatcheslav3345
20.07.2016 22:10+2А разве нельзя просто сделать конвертер для старых файлов и перегонять их в новые — уже с приоритетами операций?
RiseOfDeath
20.07.2016 23:34+1Проблема в том, как определить писал-ли автор выражение 2+2*2 исходя из того, что оно будет равно восьми (старая версия) или он имел ввиду шесть.
Vjatcheslav3345
21.07.2016 10:20Очень просто — при конвертации конвертер в файл вставляет скобки в выражения и закомментированную спецпометку, на манер хеш суммы от времени конвертации с замечанием "Не удалять!!!" и пояснением — что за пометка и зачем она.
При конвертации проверяется наличие скобок, спецпометки и если не того ни другого нет, значит это старый файл, выражение конвертируется слева направо (ибо таковы правила языка — (2+2)*2).
Вообще, же не вижу особой проблемы здесь — вместо "лестницы приоритетов" в языке простое и запоминающееся правило — "слева-направо", но если уж хочется — можно поправить компилятор, чтобы он выдавал предупреждения специального вида о необходимости расставить скобочки — тогда и старое работать будет и в новом скобки ставить станут — ну или же, компилятор будет ориентироваться на спецметку, (которая автоматически появится в новых файлах после его доработки и старые без метки будет трактовать как "слева-направо" а новые — по приоритетам.
А вот куда важнее научить компилятор 64-битному коду — 32-битный уже уходит в прошлое (может, от LLVM-Clang кодогенератор взять для него?..) и научить компилироваться в Posix-системах (когда последний раз его смотрел, он был только под Виндой) — эти системы — это "естественная среда обитания" компиляторов, ему там будет хорошо — как белке в родном лесу.
Virviil
20.07.2016 22:20+4Я может быть сейчас от незнания сморожу, но можно ли писать под эту ОС на Rust?
Мне кажется, что аналогичная статья про Rust (если можно конечно), была бы очень интересна (благодаря хайпу), и возможно я (и даже куча других людей) бы даже попробовал свои силы в написании каких нибудь программ под эту ОС.
Ну а если нет — тогда ждём....
Punk_Joker
21.07.2016 01:20+2Необходимо портировать компилятор под KolibriOS, или же организовать кросскомпиляцию, если она возможна. Но лучше конечно первое)
claygod
21.07.2016 09:07+2Интересная идея.
Сообщество Rust вполне возможно дало бы импульс развитию этой ОС.
gaki
21.07.2016 10:33-1Я, может быть, тоже сейчас от незнания сморожу, но можно ли щас писать хоть под какую ОС на Rust?
ozkriff
21.07.2016 10:48+1Странный вопрос — http://rurust.github.io/rust_book_ru/src/getting-started.html#Поддерживаемые-платформы
gaki
21.07.2016 10:54-1«Можно писать под данную ОС» != «данная ОС упомянута в списке поддерживаемых платформ». Это, как минимум, еще наличие адекватных библиотек для всего, что нужно, нормальный хелп и т. д.
ozkriff
21.07.2016 11:05+2Ну это какие-то очень размытые требования — очень сильно зависит от решаемых задач, да и требования к "адекватности" у каждого свои :). Тут в общем виде не скажешь. Для меня и моих задач адекватные библиотеки и документация для ОС "первого уровня" наличествуют)
DarkEld3r
21.07.2016 12:38+2Хелп есть по языку и стандартной библиотеке, а они (как и с большинством языков) стараются быть независимы от платформы. Документация к сторонним библиотекам, очевидно, зависит от авторов библиотек и бывает разного качества.
В любом случае, готов спорить, что для раста библиотек куда больше чем для С--.
gaki
21.07.2016 15:53Готов поспорить, что бегаю гораздо быстрее Стивена Хокинга (хотя о чёрных дырах знаю гораздо меньше), и при этом могу нести гораздо больше груза. Делает ли это меня адекватной заменой гужевому и авто-транспорту? :)
DarkEld3r
21.07.2016 16:34+1В определённых условиях — вполне. И уж точно из вас получится лучший транспорт чем из Хокинга.
Но я не совсем понимаю к чему вы клоните. К тому, что нет смысла выбирать из (условно) двух инвалидов при наличии более подходящих вариантов? Возможно, вот только всё, опять же, зависит от условий. Как по мне, то выбирать С-- и писать на нём что либо тоже нет никакого смысла. Но кому-то стало интересно и в результате появилось некоторое количество программ и если они популярны, то какая разница на чём написаны?
Если же вернуться ближе к расту, то (на мой взгляд) рядом преимуществ он обладает, причём даже в сравнении с С и С++, а не только С--. И программы на нём вполне пишут, в том числе и коммерческие. Насколько он нужен в контексте KolibriOS — это уже другой вопрос.
dm_urievich
21.07.2016 10:46Не по теме, но интерфейс ОС Windows напоминает.
А так вроди Си должен нормально подойти, надо почитать что умеет ОС. С первого взгляда, без malloc(), free() (и прочая работа с динамической памятью) и FILE Си очень даже подходит.Punk_Joker
21.07.2016 12:31Немного не понял. На Си уже давно можно писать под Колибри, сейчас портирована последняя версия Tiny C Compiler, и ведутся работы по улучшению работы с этим языком.
tower120
21.07.2016 17:37-1Не пойму я нафига это всё? Для каждой архитектуры писать свой ассемблерный код? А как потом заинлайненую ассемблерную функцию компилятор будет оптимизировать? Даже если и нужно по каким-то причинам писать ассемблерный код — есть же inline assembler.
Бред.gaki
21.07.2016 18:13Достаточно низкоуровневый код даже на C/C++ довольно часто пишут свой под каждую архитектуру.
napa3um
Будучи школьником изучающим ассемблер наткнулся на этот C--. Но тогда уже существовал MASM32, обладающий директивами и макросами в стиле proto/invoke, .if/.else и т.п., превращающими его в «почти си», а потом и FASM появился, на базе макросов которого вообще можно DSL написать, так интерес к C-- и сошёл на нет. Не зря бросают C--, он мертворожденный, IMHO.
PavelMSTU
Почему язык мертворожденный, если он используется в приложениях для KolibriOS?
napa3um
Даже безотносительно оценок «мертворожденности» самой KolibriOS и понимания, что в ней рейтинги популярности языков сильно отличаются от «среднего по палате», оказывается, что C-- не может предложить ничего нового и полезного, чего не было бы в FASM (у которого приоритет как минимум в том, что он является системным языком программирования данной операционной системы). Но не настаиваю на своих критериях «мертворожденности», особенно в чисто хоббийном проекте, где понятия «эффективности», «поддерживаемости» и «стандартности» вообще теряют общепринятый смысл. Пусть, если кому-то доставляет удовольствие программировать на C--, то этот язык родился не зря.