Который раз.

дай, хозяин, водички, а то так кушать хочется, что переночевать негде.

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

А есть вообще что-то ценное на C++ без C интерфейса?

А есть вообще что-то ценное на C++ без C интерфейса?

Qt?

Хм, ну да. А кроме?

не благодари

https://www.stroustrup.com/applications.html

gcc

Не успеешь оглянуться и уже ABI стандартизировали по самые темплейты.

Скорее всего целевая аудитория тут - chrome, android и другие огромные C++ проекты которые хочется постепенно покрывать ржавчиной.

вот еще развивающее чтение для растафанов.

https://www.geeksforgeeks.org/top-applications-of-cpp-in-real-world/

хотя… относиться с долей скепсиса, ибо похоже на текст от ИИ. но попробуйте его опровергнуть

вот еще развивающее чтение для растафанов.

https://www.geeksforgeeks.org/top-applications-of-cpp-in-real-world/

А во что в этом списке ещё не запустил клешни крабик?

Пока си-плюс-плюсом рулит комитет кина не будет. Эти бюрократы только штаны просиживают. Раст целиком был написан за время всего пары релиз циклов цпп. Это приговор.

Пока си-плюс-плюсом рулит комитет кина не будет. Эти бюрократы только штаны просиживают

Ох, если бы просто просиживали. Они же с большим рвением и энтузиазмом портят язык.

Rust рулит!

Раст целиком был написан за время всего пары релиз циклов цпп

Звиздюлькин :)

ржасту уже за 15 … C++ после 15 лет после появления уже был языком нумбер ван в софтострое, причем неперерекаемым и никто это не подвергал сомнению… И только с появлением Java хоть что то стало меняться в этом плане.

А для AI что С++ что ржаст … всё один хрен промежуточная фигня, которая ни заказыику ни самому AI - не нужна :( Ибо заказывают на человеческом, а в результате бинарный код для заказанной платформы. Всё что посередине - суть издержки, от которых надо избавляться …

В принципе есть основной проект биндгена, все особенности вполне насписаны:

https://rust-lang.github.io/rust-bindgen/cpp.html

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

А время разработки LLVM вы посчитали? В этом «волшебном» компиляторе плюсового кода столько, что растерам хватит его лет 20 переписывать на раст.

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

Даже манглинг же до сих пор остаётся на усмотрение компилятора?

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

Проблемы с теми же темплейтами или инлайновскими функциями не решаемы в принципе без настоящего компилятора c++

Ну так их и надо решать через компилятор С++? Как тот же SWIG это делает. Что мешает для файла:

namespace my {
template<typename T> class MyClass {
public:
  MyClass() { /* ... */ }
};
}

и требования «хочу MyClass<int32_t>» сгенерировать C++ файлик вида:

namespace ffi_GjJaskhB223jHS {
::my::MyClass<int32_t> MyClass_int32_t_constructor_GHBaHHkhHShks() {
  return ::my::MyClass<int32_t>();
}
}

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

Что-то мне подсказывает, что решать вопросы прямого переноса шаблонов из C++ в какой либо другой ЯП тупиковый путь.

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

Для примера, достал из загашника дааааавних времён алгоритм аккуратного суммирования SumK на плисах:

При оптимизации не один метод шаблонных классов не остаётся.

https://godbolt.org/z/nTK8vqEKG

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

Расширить и углубить…

3. Embedded Systems

Тащемта Раст уже давно там есть. Даже асинхронщину туда протащили, безо всяких ОС.

Хм, ну да. А кроме?

Венда? Хотя на лоре это вряд ли за ценность примут, да.

Тогда Кеды.

openCV?

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

Так лям баксов гугле заплатил.

Rust рулит!

Чем? )

Расширить и углубить…

и консенсус найти

ржасту уже за 15 … C++ после 15 лет после появления уже был языком нумбер ван в софтострое, причем неперерекаемым и никто это не подвергал сомнению… И только с появлением Java хоть что то стало меняться в этом плане.

Увидел данную ветку пару дней назад, и хотел было написать, но опоздал, анон меня опередил. Именно так! Вернее, может быть, не совсем так, но в корне именно так. Первая спека в 1985г., а через 15 лет 2000г., и там уже плюсы вовсю въехали в нишу десктопного софта, которая тогда ещё была ого-го, никаких смартфонов ещё не было. И был уже целый ряд коммерческих компиляторов. Собственно говоря, почему нужен был комитет по стандартизации? Чтобы реализации не расползались, а поддерживали плюс-минус один и тот же язык. Т.е. комитет - это следствие популярности. Какую нишу захавал раст после 15 лет его существования? Какая-то дрочка с криптой? Это не серьёзно.

А время разработки LLVM вы посчитали?

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

Давайте жить дружно!

Skia, различные игровые движки.

Тогда Кеды.

KDE 7 на Rust? Звучит интересно.

Полистал переписки на https://rust-lang.zulipchat.com/#narrow/channel/427678-t-lang.2Finterop

Среди них отсылка к Carbon

Заголовочный файл:

// C++ code used in both Carbon and C++:
#include <stdfloat>

struct Circle {
  std::float32_t r;
};

Реализация кода на Carbon:

// Carbon exposing a function for C++:
package Geometry;
import Cpp library "circle.h";
import Math;

fn PrintTotalArea(circles: [Cpp.Circle]) {
  var area: f32 = 0;
  for (c: Cpp.Circle in circles) {
    area += Math.Pi * c.r * c.r;
  }
  Print("Total area: {0}", area);
}

Использование функции в плюсах:

// C++ calling Carbon:
#include <vector>
#include "circle.h"
#include "geometry.carbon.h"

auto main() -> int {
  std::vector<Circle> circles = {{1.0}, {2.0}};
  // A Carbon slice supports implicit construction
  // from `std::vector`, similar to `std::span`.
  Geometry::PrintTotalArea(circles);
  return 0;
}

KDE 7 на Rust? Звучит интересно.

Почитай на что я отвечал, там не про раст было.

Чем? )

Rust больше соответствует названию «высокоуровневого» ЯП на сегодня чем C и C++, хотя последние тоже неплохи, да, а также хорошо поддерживает юникод из коробки. На таком же уровне как Rust C и C++ поддерживают его только через wchar_t, к которому у многих предубеждение, а потому они предпочитают юзать для строк не glibc/musl/etc, а сторонние библиотеки. А лично я хорошо отношусь и к wchar_t. Среди программистов на Rust'е таких холиваров просто нет.

Так Rust же хранит строки в UTF-8? А значит сравнивать с wchar_t так себе.

И если понадобилось что-то больше std::string в плюсах, то это уже ICU. Как пример, разбей на предложения и слова:

春眠不觉晓，
处处闻啼鸟。
夜来风雨声，
花落知多少？

Если сшить двух одноногих, то получится… Четырехрукий!

Как пример, разбей на предложения и слова:

Предложения, ладно. А слова разве бывают в китайском? Вот 啼鸟 — это одно слово или два?

Ну тот же ICU предлагает такое разбиение.

春眠    不觉    晓      处处    闻      啼      鸟
夜来    风      雨声    花落    知      多少

дипсик почти так же, только уловил 啼鸟, а вот с 风雨声 есть загвоздка.

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

Удивительно, как спустя 13 лет продолжают выходить новые версии Раста и останавливаться не собираются! Хотя, казалось бы, приговор уже вынесен!

Хотя, казалось бы, приговор уже вынесен!

Какой и где?

不觉 — «не чувствует», это одно слово? Серьёзно?

风 雨声

Шум дождя и ветра стал ветром и шумом дождя…

风雨声

Считаешь, что это одно слово? Дождеветрошум…

P.S. Это вэньяньский стих, тут почти все слова в один иероглиф. Разве что 多少 одно слово.

不觉 — «не чувствует», это одно слово? Серьёзно?

А в чём проблема? В частице «не» в русском языке?

В том, что если это слово делится на два отдельных слова со своим смыслом, то зачем его считать одним словом?

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

1. Я привёл как разбивает на «слова» библиотека ICU.
2. Я не эксперт в китайском.

不觉 — «не чувствует», это одно слово? Серьёзно?

Пояснения дипсика:

不 (bù) – не
觉 (jué) – осознавать, чувствовать
→ 不觉 (bùjué) – не заметить

晓 (xiǎo) – рассвет
→ 不觉晓 (bùjué xiǎo) – не заметил рассвета

风雨声 — «звуки ветра и дождя» передаются одним словом, что типично для древнекитайской поэзии (сжатие смысла).

Я понял. Судя по результату, он просто обозвал «словами» устойчивые словосочетания. С таким подходом «не видно ни зги» тоже одно слово. Или «Советский Союз».

Понятие слов в европейских языках — условность, определяемая синтаксисом. Огнеборец одно слово, «борец с огнём» три слова, при том, что смысл и даже частотность почти одинакова.

В китайском всё сложнее. В современном китайском есть слова в том смысле, что набор иероглифов нельзя представить смыслом отдельных иероглифов. Классический пример: имена и заимствованные слова: кофе (咖啡) или Путин (普京).

А вот древнекитайские понятия почти всегда выражаются единственным иероглифом. Поэтому желание считать «певчую птицу» или «шум ветра и дождя» одним словом для меня странно. Потому что они чётко делятся на «петь» «птица» и «ветер» «дождь» «шум».

И есть совсем неоднозначные случаи: 雷达 (léidá) = радар = «гром» + «достигать». Можно считать заимствованием, а можно считать двусловным описанием технологии (дословно «электромагнитная локация»).

P.S. В юникоде ещё поиздевались, объединив китайские иероглифы с кандзи и ханча. Всё равно, что была бы у нас одна буква на б, b и β.