Единственное, что я вижу в С++ для этого дела - это extern C. Все остальное выглядит одинаково, что в расте, что в K/N

О том и речь.
Это просто быстрее, чем руками писать импорты.

возможно у твоего оператора/железа с этим все хорошо еще

но проблема такая была, сейчас не найду статейку на тему

А кто их руками-то пишет?

Кгм, крестам этого достаточно, там с extern "C" инклудится сишный хедер и проблемы заканчиваются (ну ладно, в 99.9% случаев). В отличие от K/N, которому надо хэдэр сожрать и переварить в свою систему типов. Или, прости господи, в отличие от JVM, где есть зоопарк вариантов интеропа и все не очень.

Если б к сям прилагался стандартизированный формат для описания интерфейса либы, который не являлся бы при этом исходниками на сях, было бы намного круче, конечно :)

Я понимаю. Но с точки зрения использования голого С особой разницы нет. Что там автоматика, что тут автоматика. Я про K-N, разумеется. Проблемы с cinterop начинаются ровно там же, где они начинаются у С++. При этом, я не буду спорить, что в С++ удобнее. Вопрос в том, какую цену мы платим за это?

Да, есть генераторы, типа gcc -fdump-ada-spec  $(find -name "*.c"), но они порой ошибаются.

> Проблемы с cinterop начинаются ровно там же, где они начинаются у С++.

У cinterop проблем начинаются раньше по очевидным причинам.

Согласен. Но вопрос про цену остается

Ну а сравнивать цену смысла нет, так как почти вся эта цена — это цена использования языка, а не цена интеропа.

Это примерно с 15-16 года. В 2010-м например в области я не мог толком по ssh консольку открыть во время звонка всё отваливалось. А то что называлось Еdge давало  скорость <30 Кбайт/c
А wifi... там нас всю дорогу дурят, вот держу сейчас в руках некий TL-WR841N(RU)- dirty cheap rouyer. В 12-году на его упаковках гордо рисовали (300Мби/c) по факту из-за лимита ОЗУ и тормозного проца оно не может дать даже 8Мбайт/c  между eth и wlp.

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

Вы ж понимаете, что у кого-то с его задачами ровно так же будут большие проблемы от использования той же джавки в противовес крестам, да?

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

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

Ну так подвижки в этом плане тоже идут.
Щаз и модули завезли, и пакетники есть.
Глядишь к 23 стандарту 20 заимплиментят.

Опять же не спорю. В расте уже тоже видны отдельные проблемы. Тут идеального решения нет. Но тем не менее это не значит, что надо проблемы игнорировать пользуясь аргументами, которые уже 15 лет как протухли. Я рад, что в С++ наконец-то завозят модули, которые в принципе могут все это решить. Правда думаю, что too little too late.

А какие, кстати, проблемы в расте?