Здравствуйте, Zhendos, Вы писали:

Pzz>>Угу. При этом оба основных открытых компилятора написаны один на C, другой на C++.

Z>Если имеются ввиду gcc и clang, то они оба на C++.
Z>Погуглите "GCC's move to C++"

Он может и move, только ему еще очень туда топать и топать.

Здравствуйте, student__, Вы писали:

s> Ну не совсем. Основная проблема, которую хотят решить, как я понял, — необходимость использовния нескольких ЯП в околонаучных расчетах.

По описанию кажется, что они хотят сделать язык для распределенных вычислений. Но там у них тоже все пока(?) крайне печально (чего только стоит full-mesh связность между узлами например). Может для ученых оно "и так сойдет", а вот для промышленных применений оно будет отвергнуто еще на стадии прототипа.

Здравствуйте, Pzz, Вы писали:

Pzz>исходники, поди, в гите держат.

Держат, по крайней мере в некоторых проектах.

Здравствуйте, Anton Batenev, Вы писали:

AB>По описанию кажется, что они хотят сделать язык для распределенных вычислений.

Не только. Темы самые разные, собственно, https://julialang.org/research/

Здравствуйте, Pzz, Вы писали:

Pzz>и исходники, поди, в гите держат.

Ну а до гита был правленный Perforce.

Здравствуйте, Sinclair, Вы писали:

S>Ну, или админ, который не говорит "ваше приложение говно — я всё настроил, как надо, а оно работает плохо, и меня не парит, почему".
S>Привыкайте, камрады — грядёт эпоха смежных специальностей.

Эта эпоха всегда и была.
Я ХЗ почему примерно с начала 2000-х в IT стала преобладать некая розовоочковость в плане строгого разделения знаний и соотв. навыков.
Сейчас эта ересь сходит на нет, слава богу.

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>если С++ на помойку то на чем тогда писать ОС компиляторы и системыне утилиты
НС>Компиляторы точно на С++ писать не стоит.

И не только на С++.
На любом мейнстривовом, верно?
Мейнстрим — он для других задач.

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

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>И? Были написаны, пришлось переписать. Ровно то, о чем я и говорил.

Ты говорил слишком обще.

А стоит начать раскладывать по полочкам и всё становится "не так однозначно" (С):
— Кодовая база компилятора после переписывания стала больше где раз в 5-6?
— Написание компилятора на шарпе и всей инфраструктуры вокруг заняло примерно 3-4 года?
— При этом потрачено примерно в 50 раз больше человекочасов?

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

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

Здравствуйте, smeeld, Вы писали:

S>Ядра OC-ей-это чистый Cи. В некоторых, вроде винды, есть какие-то части, но они там в исчезающе малом количестве, и тому причины-прелести самого C++ не позволяющие его без проблем зазюзать для разработки систем ядра. В Unix и Unix-likе-ах нет вобще C++ с ядрах и системных тулзах, его туда с намордником не пускают прицнипиально (Торвальдс одобряэ).

Торвальдс упорот, т.е. не показатель.

А причины вполне здравые есть.

ИМХО, единственной непреодолимой причиной является модель исключений С++, которую, действительно, нельзя применять в ядре, бо эта модель (а) медленная из-за RTTI-природы перехвата исключений и (б) подразумевает некое "волшебное" автоматическое распределение памяти под объекты-исключения, а ядро не может себе позволить отдавать на откуп некоему третьестороннему механизму вопросы управления памятью. Т.е. если для дефолтного new/delete можно сделать переопределения, так же как переопределения для доп. их сигнатур (можно даже запретить дефолтные сигнатуры), то в механизм исключений вмешаться нельзя, эта вещь в себе.

Всё остальное, типа инлайных типов/ф-ий, шаблонов, неймспейосов, повышенной типобезопасности и т.д. до бесконечности — всё это резко облегчает жизнь разработчикам.
По крайней мере, надобность вместо исходного Си сплошняком писать на макросах, как в ядре Linux и еще больше в ядре FreeBSD — отпадает.

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

Так шта, вопрос в чём-то другом.
Например, на момент начала разработки Linux, компиляторы С++ были не под все архитектуры или не обладали нужной совместимостью со стандартом.
Это и сейчас так.
Т.е. Си обладает большей распространённостью и повторяемостью реализаций под различные железки, т.е., скорее всего, основная причина в этом.

Здравствуйте, Denis Ivlev, Вы писали:

DI>А ты вот, например, понимаешь как работают виртуальные вызовы? Я расскажу:

Думаю, понимает.


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

И?
В Си-ядре Linux именно это и происходит:
https://github.com/torvalds/linux/blob/master/include/linux/fs.h

Смотрим строки:
https://github.com/torvalds/linux/blob/master/include/linux/fs.h#L362

struct address_space_operations {
    int (*writepage)(struct page *page, struct writeback_control *wbc);
    int (*readpage)(struct file *, struct page *);
    ...

Это классическая таблица виртуальных ф-ий.

Еще:

struct file_operations {
    struct module *owner;
    loff_t (*llseek) (struct file *, loff_t, int);
    ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
    ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
    ...

Вот виртуальный объект, ссылающийся на экземпляр таблицы виртуальных ф-ий:
https://github.com/torvalds/linux/blob/master/include/linux/fs.h#L935

struct file {
    ...
    const struct file_operations    *f_op;
    ...

А вот множественное наследование от виртуальных типов:

struct super_block {
    ...
    const struct super_operations    *s_op;
    const struct dquot_operations    *dq_op;
    const struct quotactl_ops    *s_qcop;
    const struct export_operations *s_export_op;
    ...

DI>2. С девиртуализацией компилятор может не справится, поэтому:

По моим наблюдениям, при включённом LTO компилятор слишком часто применяет девиртуализацию.
Т.е. намного чаще, чем можно было представить при взгляде со стороны.
У меня часто исчезают как сами виртуальные методы, так и экземпляры таблиц виртуальных методов при включенной опции /OPT:REF.

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


DI>3. Чтение таблицы ВФ по этому указателю тоже может означать поход по памяти и плюс к этому вытеснение из кеша данных, которые могут скоро понадобится

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


DI>Вот теперь, когда ты знаешь про стоимость этой абстракции, скажи будут в ядре ОС использовать ВФ?

Ес-но.

Рядом ты добавлял про возможность вместо размещения указателя на таблицу хранить в области памяти экземпляра типа сразу указатели на целевые ф-ии.
Это тоже небезупречный аргумент, т.к.:
— подобная техника применима и для С++ и мы в своих проектах тоже иногда (редко) так делаем (и выходит как минимум типобезопасней, чем в Си);
— техника эта оправдана или когда кол-во таблиц виртуальных ф-ий и кол-во экземпляров близко к 1:1, или когда кол-во ф-ий в наборе мало (1-3 от силы);
— компилятор умывает руки в плане девиртуализации; поэтому, подобную технику стоит тщательно тестировать в реальной архитектуре и на реальных данных, бо она может дать замедление чаще, чем кажется в "теории" (что лично меня не перестаёт удивлять, положа руку на).

Здравствуйте, Marty, Вы писали:

B>>С++ обрел новое дыхание после 11-го стандарта, это да. Но после 17-го года стало ясно, что язык распухает и распухает, и конца этому не видно. Причем новые возможности не только не уменьшают сложность языка, а наоборот добавляют ему подводных камней. То есть С++ тоже маргинализируется, причем, судя по тому как разошелся его комитет, достаточно динамично.

M>А что же такого в 17ом так распухло, и, видимо, давит на тебя?

Я больше 20-й имел в виду.

Здравствуйте, vdimas, Вы писали:

V>- Кодовая база компилятора после переписывания стала больше где раз в 5-6?

Нет.

V>- Написание компилятора на шарпе и всей инфраструктуры вокруг заняло примерно 3-4 года?

Эрик, по его словам, первый прототип накатал месяца за 4.

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>- Кодовая база компилятора после переписывания стала больше где раз в 5-6?
НС>Нет.

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


V>>- Написание компилятора на шарпе и всей инфраструктуры вокруг заняло примерно 3-4 года?
НС>Эрик, по его словам, первый прототип накатал месяца за 4.

Первый прототип на плюсах делается за 4 дня.
Посмотри плюсовые исходники компилятора от первой-второй версии дотнета, они ж простейшие.
Особенно должно понравиться включение одного и того же файла-таблицы в разных местах с разными определениями одних и тех макросов, т.е. когда из одной и той же таблицы в разных местах достаётся разная информация, т.е. генерируется разный код. Такие фокусы развязывают руки, но в C# требуют внешней кодогенерации, а это +1 к заморачиванию.

В общем, речь об общей трудоёмкости по окончании проекта, и эта трудоёмкость отличается на более чем порядок.

ИМХО, на начальном этапе развития .Net нельзя было позволить себе вбухать столько труда всего-лишь в компилятор.

Здравствуйте, Pzz, Вы писали:

Pzz>Микрософт раньше использовал только все свое. Теперь у них движок бровсера от гугля, язык программирования от мозилы, на серверах у них линух стоит, и исходники, поди, в гите держат.

Держат, но они много правок сделали для Гита, чтобы он их кодобазу тянул. Видимо и с Растом так будет, если он приживется в МС.

Здравствуйте, Patalog, Вы писали:

_>>А вот скажем если сравнивать с современным C++ язык C или же C++98 (тут у нас похоже и такие любители водятся), то я считаю что плюсов у них не будет в принципе, а минусов множество.
P>Плюс в общем-то только один, но зачастую перевешивающий все остальное — C API. В виду этого зачастую получаются забавные конструкции — либа внутри плюсовая, поверх нее Сшный АПИ, поверх которого плюсовые врапперы прикладного уровня.

Да, C API — это стандарт де-факто, если мы хотим, чтобы наша C++ библиотека использовалась из произвольных языков. Но т.к. создание такого API делается в C++ в одно ключевое слово, то никаких проблем с этим нет. Т.е. конечно есть неудобство в том смысле, что мы не можем использовать даже красивые ООП структуры (про шаблоны я даже не заикаюсь), но это очевидное следствие требования использования из других языков — в них же частенько просто нет аналогичных конструкций.

Здравствуйте, Pzz, Вы писали:

_>>Ууу, это значит что у тебя там что-то совсем печальное в коде было. Хотя конечно базовые операции со строками в скриптовых языках всё равно реализованы на C++ и не отличаются по производительности от самого C++. Но если у тебя там было много разнообразных данных (а не одна гигантская строка), то динамический код по любом должен был отставать из-за повышенной косвенности и лишних данных в массивах (если это конечно родные массивы динамического языка, а не что-то типа numpy).
Pzz>У перла, возможно, до освобождения просто не доходило.

Это само собой. Но ты же говорил, что у тебя перловский скрипт работал столько же, сколько и C++ программа с отключённым освобождением памяти. А это уже однозначно намекает на какой-то косяк в коде. )

Здравствуйте, Marty, Вы писали:

M>Ну, на пёрле это мог быть один большой регэксп, например. На грани того, что еще может быть написан человеком. Прекомпилируешь его, потом натравливаешь на данные — профит. Тут плюсики и в правду не нужны

Собственно лично я, при всём моём хорошем отношение к C++, точно не стал бы начинать решать такую задачу на нём. Для начала я бы решил её на Питоне (что было бы в разы быстрее в смысле времени разработки), а к C++ обратился бы только в случае специфических требований (время исполнения, потребляемая память, защита алгоритма, приложение без рантайма и т.п.).

Здравствуйте, so5team, Вы писали:

_>>А именно: C (устаревший язык, на котором написаны в основном библиотеки и продукты с длинной историей), C++ (текущий лидер ниши, на котором написаны почти все компоненты современной инфраструктуры) и Rust (возможное потенциальное будущее ниши, если сумеет не остановиться в развитии и занять место C++).
S>Формально говоря, есть еще и Ada. На котором реального кода для embedded-а и системщины, полагаю, написано и эксплуатируется пока сильно больше, чем на Rust-е.

По объёму кода это наверняка так. Но у меня как-то не поднимается рука назвать Ada универсальным системным языком (хотя технически он такой и есть) из-за такого, что использует его вроде только американская военщина и всё. Так то и какой-нибудь Swift (кстати очень не плохой язык) можно было бы сюда подтянуть и ещё много чего, но они все ограничены одной платформой или железом. У Ada конечно такого ограничения нет, но т.к. вообще никто в моём весьма большом круге общения даже не задумывается о нём, то...

Здравствуйте, alex_public, Вы писали:

_>что использует его вроде только американская военщина и всё

AFAIK не только. Еще он используется в авиации, медицине и энергетике. Т.е. в сегменте mission critical систем этот язык весьма известен.

Здравствуйте, so5team, Вы писали:

S>AFAIK не только. Еще он используется в авиации, медицине и энергетике.

В передаче и распределении? О нем легенды ходят. В смысле, что Аду там в глаза не видели, только легенды рассказывают.
Про область генерирования энергии (большие электростанции) не расскажу, не знаю.

S>Т.е. в сегменте mission critical систем этот язык весьма известен.

Проблемы mission critical систем ортогональны проблемам используемого в них ЯП.