Здравствуйте, Shmj, Вы писали:
S>Попробуйте. Уверен что ничего не получится, когда столкнетесь с практикой.
Всё прекрасно получится. Например, MS SQL Server, написанный на C++, прекрасно исполнял дотнетовый код вплоть до недавних версий, где это было выпилено за ненадобностью. Делал он это, разумеется, на всех платформах.

Встречное предложение — попробовать столкнуться с практикой и привинтить какую-нибудь типовую header-only library на С++ к проекту на более-менее любом языке. Хоть даже и к С.
Я вам даже подскажу, в чём затруднения, которых вы не видите из-за своей зашоренности:
1. Различия в языковых концепциях. Языки программирования настолько различны, что очень немногие конструкции есть сразу во всех. В большинстве случаев вы не сможете воспользоваться ничем, кроме "голых функций". Плюсовые шаблоны и операторы невозможно употребить ни в одном языке, кроме С++ — и то, при условии, что вы собираете весь код одним и тем же компилятором.
2. Различия в реализации похожих и даже одинаковых концепций. Наследование в Java, Javascript, и C++ реализовано настолько по-разному, что вы не сможете использовать классы, написанные на любом из этих языков, в других языках. Исключения — то же самое: не сможете вы поймать исключение, выброшенное из C++-кода, ни в каком другом языке. Даже если в этом языке тоже есть исключения. Управление памятью — та же беда. Код, написанный для JVM, будет использовать один и тот же менеджер памяти. Код, написанный на С++, использовать из С нужно с великой осторожностью — иначе вы получите трудноуловимые утечки, и вообще undefined behavior на каждом первом шагу.

Как с учётом этого можно утверждать, что на С++ "можно написать библиотеку, которую потом использовать из любого языка на любой платформе", будучи в здравом уме — я хз.
Если же вдруг вы всё это осознавали, и имели в виду, что "примерно из любого языка и платформы есть байндинги к plain С коду", то я поясню: возможность позвать "просто функцию" из библиотеки требует, чтобы на стороне С++ вся функциональность этой библиотеки была выставлена наружу в виде "просто функций". То есть вы не можете выставить наружу допустим, класс Matrix<N, M>, который оборудован операторами сложения и перемножения матриц.
Вам придётся для начала переделать свою библиотеку так, чтобы размерность матрицы была частью её рантайм-заголовка, а не параметрами шаблона. Вы не сможете выставить наружу операторы сложения и умножения этих матриц — вы будете писать функции matrix_add и matrix_multiply. Вы не сможете проверять соответствие размеров операндов статически при компиляции — вам придётся вкрячить код этой проверки в каждую функцию. Вы не сможете бросить исключение в случае несовпадения размеров — вы будете вынуждены пойти на унизительные конвенции вроде "если не получилось, то вернём null-указатель вместо результата". Вы не сможете реализовать никакое автоматическое управление памятью — клиенты вашей библиотеки будут вынуждены вызывать ваши функции create_matrix и release_matrix, а если не позвали — утечка.
В общем и целом, вам проще писать эту библиотеку сразу на C.
При этом полезность этой библиотеки будет в разы ниже её плюсового оригинала. Клиенты исходной библиотеки, которые пишут на С++, могут делать всякие прикольные трюки — например, могут предоставить свой тип элемента матрицы, для которого подходящим образом определены операции сложения и умножения. Ваша С-шная поделка потребует от вас просто выставить наружу десяток перегрузок вида сreate_matrix_int32, сreate_matrix_float, сreate_matrix_double, и так далее. И возможности передать вам пользовательский тип так и не появится. Клиенты библиотеки на С++ могут предоставлять частичные специализации операторов — например, для того, чтобы эффективно перемножать матрицы конкретных размеров, используя специфические для конкретной платформы векторные инструкции. Ничего этого сделать с библиотекой, выставленной наружу через С-шный интерфейс, невозможно.


В итоге, интерфейс вашей библиотеки становится бутылочным горлышком. И даже те клиенты, которые в итоге пишут на С++, не могут воспользоваться этим преимуществом — ведь вы уже искалечили библиотеку ради эфемерной цели "использовать её из любого языка".
Ну, и в таких ограничениях, внезапно, весь код этой библиотеки можно прекрасно написать на C#. Точно так же, как и для С++, никакие специфические возможности платформы использовать не получится. А для plain old C struct есть value-типы. И всё будет прекрасно работать. GC никак не помешает — всё управление памятью будет снаружи. Клиент будет передавать в библиотеку пару указателей на функции malloc и free, и всё размещение динамики будет сделано через них.