Здравствуйте, Shmj, Вы писали:
S>Нужно и востребованно. Я уже приводил пример библиотеки, которая собирается под все 6 платформ и используется из всех ЯП простым способом — есть обертки даже для C#.
В некоторых частных случаях действительно, можно написать такую библиотеку, которую можно использовать примерно откуда угодно. Я вам по соседству привёл примеры других случаев, в которых вам не помогут ни Rust, ни C++, ни C. Отсутствие комментариев туда с вашей стороны вполне красноречиво.
S>На C# вы такой в принципе не сможете написать. Попробуйте найти хотя бы одно решение — посмотрим. Уверен что в мире нет ни одной такой библиотеки.
Если ограничить своё понимание "библиотеки" некоторыми частными случаями, то и на C# можно написать библиотеку, которая будет использоваться из любого языка (ежели написать к нему обёртки). Кроссплатформенность вообще проблемой не является, т.к. в дотнете идёт из коробки.
По итогу: выдуманные вами критерии оценки языков не применяются никем, в том числе и вами. Поэтому вопрос о языковых предпочтениях должен решаться на основе каких-то других критериев.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>то и на C# можно написать библиотеку, которая будет использоваться из любого языка (ежели написать к нему обёртки). Кроссплатформенность вообще проблемой не является, т.к. в дотнете идёт из коробки.
Попробуйте. Уверен что ничего не получится, когда столкнетесь с практикой.
Здравствуйте, Shmj, Вы писали:
S>>то и на C# можно написать библиотеку, которая будет использоваться из любого языка (ежели написать к нему обёртки). Кроссплатформенность вообще проблемой не является, т.к. в дотнете идёт из коробки.
S>Попробуйте. Уверен что ничего не получится, когда столкнетесь с практикой.
Ну а самому слабо? Это как про неуловимого Джо, почему он неуловимый.
Тем кому это нужно используют. И прикручивают заголовки. Мне это и большинству просто не нужно.
Но возможность есть!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>Попробуйте. Уверен что ничего не получится, когда столкнетесь с практикой. S> Ну а самому слабо? Это как про неуловимого Джо, почему он неуловимый.
Я даже не представляю как это сделать. Как быть с GC?
S> Тем кому это нужно используют. И прикручивают заголовки. Мне это и большинству просто не нужно. S>Но возможность есть!
Если бы эта возможность была — ей бы уже воспользовались. Уже как минимум статьи были бы. А так ничего нет.
Более того — на мин. примере оно может и сработает — но для продакшена точно не годится.
Хотите это сделать первым в мире? Вы что-нибудь делали первым в мире?
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>Попробуйте. Уверен что ничего не получится, когда столкнетесь с практикой. S>> Ну а самому слабо? Это как про неуловимого Джо, почему он неуловимый.
S>Я даже не представляю как это сделать. Как быть с GC?
А чем тебе GC мешает? Разные менеджер памяти так он ив C++ есть.
Выкручиваются через копирование или обработку памяти.
S>> Тем кому это нужно используют. И прикручивают заголовки. Мне это и большинству просто не нужно. S>>Но возможность есть!
S>Если бы эта возможность была — ей бы уже воспользовались. Уже как минимум статьи были бы. А так ничего нет.
Я тебе приводил ссылку на создание заголовков для C++. Значит используют. https://github.com/dotnet/runtime/issues/100747
S>Более того — на мин. примере оно может и сработает — но для продакшена точно не годится.
S>Хотите это сделать первым в мире? Вы что-нибудь делали первым в мире?
Поверь уже делают. Только не на этом форуме.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>Если бы эта возможность была — ей бы уже воспользовались. Уже как минимум статьи были бы. А так ничего нет. S> Я тебе приводил ссылку на создание заголовков для C++. Значит используют. S>https://github.com/dotnet/runtime/issues/100747
Это для AOT — не поддержки всех платформ.
S>>Хотите это сделать первым в мире? Вы что-нибудь делали первым в мире? S> Поверь уже делают. Только не на этом форуме.
Ну приведешь пример хотя бы одной такой библиотеки во Вселенной — поверю.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>Если бы эта возможность была — ей бы уже воспользовались. Уже как минимум статьи были бы. А так ничего нет. S>> Я тебе приводил ссылку на создание заголовков для C++. Значит используют. S>>https://github.com/dotnet/runtime/issues/100747
S>Это для AOT — не поддержки всех платформ.
AOT компилируется для всех платформ. Еще раз формируется С++ код со сборщиком мусора. S>>>Хотите это сделать первым в мире? Вы что-нибудь делали первым в мире? S>> Поверь уже делают. Только не на этом форуме.
S>Ну приведешь пример хотя бы одной такой библиотеки во Вселенной — поверю.
Здравствуйте, Serginio1, Вы писали:
S>>Это для AOT — не поддержки всех платформ. S>AOT компилируется для всех платформ. Еще раз формируется С++ код со сборщиком мусора.
Здравствуйте, 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, и всё размещение динамики будет сделано через них.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Попробуйте. Уверен что ничего не получится, когда столкнетесь с практикой. S>Всё прекрасно получится. Например, MS SQL Server, написанный на C++, прекрасно исполнял дотнетовый код вплоть до недавних версий, где это было выпилено за ненадобностью. Делал он это, разумеется, на всех платформах.
А на моб. платформах он работал? Отож.
S>Встречное предложение — попробовать столкнуться с практикой и привинтить какую-нибудь типовую header-only library на С++ к проекту на более-менее любом языке. Хоть даже и к С.
Делал и не раз, причем не только h-only.
S>Я вам даже подскажу, в чём затруднения, которых вы не видите из-за своей зашоренности: S>1. Различия в языковых концепциях. Языки программирования настолько различны, что очень немногие конструкции есть сразу во всех. В большинстве случаев вы не сможете воспользоваться ничем, кроме "голых функций". Плюсовые шаблоны и операторы невозможно употребить ни в одном языке, кроме С++ — и то, при условии, что вы собираете весь код одним и тем же компилятором. S>2. Различия в реализации похожих и даже одинаковых концепций. Наследование в Java, Javascript, и C++ реализовано настолько по-разному, что вы не сможете использовать классы, написанные на любом из этих языков, в других языках. Исключения — то же самое: не сможете вы поймать исключение, выброшенное из C++-кода, ни в каком другом языке. Даже если в этом языке тоже есть исключения. Управление памятью — та же беда. Код, написанный для JVM, будет использовать один и тот же менеджер памяти. Код, написанный на С++, использовать из С нужно с великой осторожностью — иначе вы получите трудноуловимые утечки, и вообще undefined behavior на каждом первом шагу.
Нужно только делать extern "C". Но это будет 100% собираться под все 6 платформ и работать ВЕЗДЕ. На C# так невозможно в принципе.
А ограничения то смотрели? Limitations of Native AOT deployment — No C++/CLI.
Поймите — если бы это было возможно — уже были бы библиотеки. А так вы просто верите что проблем не возникнет, стоит только захотеть.
На самом деле крутые перцы из reddit смотрят сразу на суть — на базу, на фундамент. И языки выбирают по этому признаку. Вы можете 10 лет писать по найму и даже не задумываться об этом — не будет широты охвата — а у них это первый вопрос. Они все сидят с макбуками и iPhone и первый вопрос будет — насколько ЯП позволяет интегрироваться в эту экосистему + во все другие экосистемы.
Здравствуйте, Shmj, Вы писали:
S>А на моб. платформах он работал?
Если и не работал, то нерабочесть его была связана вовсе не с дотнетом. А как раз с кодом на C++
S>Делал и не раз, причем не только h-only.
"не только", my ass.
S>>Я вам даже подскажу, в чём затруднения, которых вы не видите из-за своей зашоренности: S>Нужно только делать extern "C".
Я одного не могу понять — вы стебётесь или реально настолько некомпетентны?
Как по вашему, подойдёт вот такой библиотечный код для работы из любого языка?
extern"C" Matrix<int> * create_matrix_int(int n, int m)
{
return new Matrix<int>(n, m);
}
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>А на моб. платформах он работал? S>Если и не работал, то нерабочесть его была связана вовсе не с дотнетом. А как раз с кодом на C++
Смотря какой C++-код генерит — в этом вопрос.
Если на работало — значит C++ -код был завязан на POSIX или еще что, чего в моб. не было.
S>>Делал и не раз, причем не только h-only. S>"не только", my ass.
Для доступа из других языков обязательно делать C-обертку. Но на .Net вы и этим не сможете проблему решить.
S>>>Я вам даже подскажу, в чём затруднения, которых вы не видите из-за своей зашоренности: S>>Нужно только делать extern "C". S>Я одного не могу понять — вы стебётесь или реально настолько некомпетентны?
S>Как по вашему, подойдёт вот такой библиотечный код для работы из любого языка? S>
S>extern"C" Matrix<int> * create_matrix_int(int n, int m)
S>{
S> return new Matrix<int>(n, m);
S>}
S>
В extern "C" нужно привести все к формату простого C. Шаблоны на верх не выдавать, исключения перевести в коды ошибок, вместо объектов — либо указатель голый либо даже хандлер.
Т.е. внешний API должен быть упрощенном виде и этого достаточно. А уже внутренне можете все фишки C++ -а юзать.
На C# вы этого под все 6 платформ сделать не сможете. Возможно что через платное решение за штуку баксов от www.remobjects.com — но это совсем другая история, я бы не рекомендовал.
Здравствуйте, Shmj, Вы писали: S>Смотря какой C++-код генерит — в этом вопрос.
Вот именно. S>Если на работало — значит C++ -код был завязан на POSIX или еще что, чего в моб. не было.
Вот именно. S>Для доступа из других языков обязательно делать C-обертку.\
Перед обёрткой нужно провести кастрацию библиотеки. S>Но на .Net вы и этим не сможете проблему решить.
И с чего бы это вдруг?
S>В extern "C" нужно привести все к формату простого C. Шаблоны на верх не выдавать, исключения перевести в коды ошибок, вместо объектов — либо указатель голый либо даже хандлер.
Отож. "Привести к формату" можно только то, что приводится к формату. Ну не сможете вы STL привести к формату простого C. S>Т.е. внешний API должен быть упрощенном виде и этого достаточно. А уже внутренне можете все фишки C++ -а юзать. Нет, не можете. В обратную сторону всё работает точно так же — если у вас есть коллбэк, то он тоже ограничен. Я же вам пишу, а вы не читаете — попробуйте передать в С-шный qsort джавовскую коллекцию и кастомный компаратор, написанный на джаве. Более того — вы не можете передавать в qsort коллбэк, написанный на полном С++. Не получится выбросить исключение из коллбэка и поймать его в своём коде, вызывающем qsort. Упс, то есть в коде библиотеки вы не можете использовать "все фишки С++" — придётся ограничиться C-совместимыми. Про управление памятью я вам уже писал — либо выставлять наружу свои аналоги malloc/free, либо, наоборот, получать их снаружи.
Не получится вернуть "смарт поинтер", который гарантированно уничтожит объект после выхода из области видимости. Всё. Ничего от вашего С++ не осталось. Борьба с С++ за совместимость с C настолько малоприятна, что проще с самого начала писать библиотеку на С.
S>На C# вы этого под все 6 платформ сделать не сможете.
Да почему не смогу-то? Упорствуете в заблуждениях.
Точно так же смогу, написав C-шную обёртку. С теми же жертвами. Да, в конце концов, неважно, что будет за обёртка — если уж мы взялись оборачивать обёртками, кто мне запретит выставить мою "библиотеку" в виде REST-сервиса? Запустил себе приложение — и вызывай его через HTTP. А уж возможность вызывать REST есть даже на большем количестве платформ и языков, чем умеющих импортировать C-шные динамические и статические либы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Ограничения для C++/CLI .NET Core
Существуют некоторые важные ограничения для проектов C++/CLI и .NET по сравнению с платформа .NET Framework:
Компиляция проекта C++/CLI в исполняемый файл не поддерживается. Необходимо скомпилировать библиотеку DLL.
Поддержка C++/CLI для .NET доступна только для Windows.
Проекты C++/CLI не могут использовать .NET Standard.
Проекты C++/CLI не поддерживают более новый формат файла проекта в стиле ПАКЕТА SDK. Вместо этого проекты C++/CLI используют тот же формат файла .vcxproj , что и другие проекты Visual Studio C++.
Проекты C++/CLI не могут нацелиться на несколько платформ .NET. Если необходимо создать проект C++/CLI для .NET и платформа .NET Framework, используйте отдельные файлы проекта.
.NET не поддерживает -clr:pure или -clr:safe компиляцию, только более -clr:netcore новый параметр (который эквивалентен -clr платформа .NET Framework).
И сколько таких проектов C++/CLI?
S>Поймите — если бы это было возможно — уже были бы библиотеки. А так вы просто верите что проблем не возникнет, стоит только захотеть.
S>На самом деле крутые перцы из reddit смотрят сразу на суть — на базу, на фундамент. И языки выбирают по этому признаку. Вы можете 10 лет писать по найму и даже не задумываться об этом — не будет широты охвата — а у них это первый вопрос. Они все сидят с макбуками и iPhone и первый вопрос будет — насколько ЯП позволяет интегрироваться в эту экосистему + во все другие экосистемы.
Их используют, но ты библиотек этих не найдешь. Это как "Видишь суслика — нет. А он есть!"
Это же касается и использование нативных библиотек. Сам натив нужен для приложений ускорения и обфускации прежде всего.
А создавать нативные кроссплатформенные библиотеки это уже некий приятный бонус.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinclair, Вы писали:
S>>Но на .Net вы и этим не сможете проблему решить. S>И с чего бы это вдруг?
Потому что нужна реализация сборщика мусора и прочих фишек .net под все 6 платформ — а этого просто нет.
S>>В extern "C" нужно привести все к формату простого C. Шаблоны на верх не выдавать, исключения перевести в коды ошибок, вместо объектов — либо указатель голый либо даже хандлер. S>Отож. "Привести к формату" можно только то, что приводится к формату. Ну не сможете вы STL привести к формату простого C.
Внутри библиотеки пользуете все фишки C++ -а. А наружу делаете простые упрощенные обертки в C-стиле. Никаких проблем с этим нет. Библиотеку изменять не нужно.
S>>Т.е. внешний API должен быть упрощенном виде и этого достаточно. А уже внутренне можете все фишки C++ -а юзать. S> Нет, не можете. В обратную сторону всё работает точно так же — если у вас есть коллбэк, то он тоже ограничен.
Ссылка на функцию стандартизирована.
S>>На C# вы этого под все 6 платформ сделать не сможете. S>Да почему не смогу-то? Упорствуете в заблуждениях. S>Точно так же смогу, написав C-шную обёртку. С теми же жертвами. Да, в конце концов, неважно, что будет за обёртка — если уж мы взялись оборачивать обёртками, кто мне запретит выставить мою "библиотеку" в виде REST-сервиса? Запустил себе приложение — и вызывай его через HTTP. А уж возможность вызывать REST есть даже на большем количестве платформ и языков, чем умеющих импортировать C-шные динамические и статические либы.
Выше написал — нет сборщика мусора под все платформы и возможности собрать стандартную .net-библиотеку под все платформы. А C++ — все можно. Даже важные сторонние библиотеки все собираются под все платформы — тот же boost.
Нет, не можете. В обратную сторону всё работает точно так же — если у вас есть коллбэк, то он тоже ограничен. Я же вам пишу, а вы не читаете — попробуйте передать в С-шный qsort джавовскую коллекцию и кастомный компаратор, написанный на джаве. Более того — вы не можете передавать в qsort коллбэк, написанный на полном С++. Не получится выбросить исключение из коллбэка и поймать его в своём коде, вызывающем qsort. Упс, то есть в коде библиотеки вы не можете использовать "все фишки С++" — придётся ограничиться C-совместимыми. Про управление памятью я вам уже писал — либо выставлять наружу свои аналоги malloc/free, либо, наоборот, получать их снаружи. 