Обновления компиляторов C, C+, Fortran

А потом оказывается что ваш код не собирается MSVC, ибо у них вечно какие-то странные реализации стандарта.

Рекомендую изучить табличку: https://en.cppreference.com/w/cpp/compiler_support

MSVC имеет лучшую поддержку С++ вплоть до С++17, отсутствует лишь aligned_alloc, и то лишь потому что это вина стандартной библиотеки С…

Код не собирается если он затачивался на gcc вместо стандарта плюсов. С поддержкой именно стандартов у MSVC всё замечательно, по крайней мере в текущей версии VS 2019

отсутствует лишь aligned_alloc, и то лишь потому что это вина стандартной библиотеки С…

А вот здесь поподробнее. Опять Сишечка Майкрософту в штаны насрала?

Но истерику закатил не я…

Я вам еще раз повторяю - не нужно хамить. В тред залезли вы со своей якобы «критикой». Я всего лишь написал что в D удобно работать с другими языками. Без сравнения с другими языками, а просто в контексте того, что из D можно использовать библиотеки из других языков. В D есть поддержка С, С++, Obj-C, Python, R, сейчас стадии активного завершения идут работы по поддержке Java и Webassembly. Эта поддержка заключается как просто в библиотеках, так и поддержке со стороны компилятора и библиотеки времени выполнения. Вот и весь смысл моего поста. Еще раз повторяю, я просто написал, что в D есть поддержка других без сравнения с другими языкам. Имея в виду, что для небольших научных исследовательских задач D подходит сам по себе, плюс есть возможность использовать уже существующие библиотеки. А вы начали спрашивать чем это лучше других языков. И получается что это вы начали орать и истерить, что D не подходит. А теперь сравните содержательность моих постов и содержательность ваших. И прекратите лажать. Я не занимаюсь продажей языка. Я лишь подсказал человеку, что есть возможность использовать D для небольших исследовательских задач. Привел примеры как D используют для решения задач в области гидродинамики. Постарался дать человеку информацию, чтобы ему было легче принять решения нужно ему это или нет. При этом мне и в голову не придет проводить какой-то сравнительный анализ, дать развернутые ответы на всевозможные мелочи и т.д. Человек задал вопрос, получил на него некий ответ. Он уже и в теме то не отписывается. Лишь вы только засоряете тему переходя на личности, потому что по сути вам сказать то и нечего.

А вот здесь поподробнее. Опять Сишечка Майкрософту в штаны насрала?

Есть функция https://en.cppreference.com/w/cpp/memory/c/aligned_alloc

Память выделенная этой функцией должна освобождаться функцией free.

Microsoft сказала что не может сделать такую функцию в С++, потому что тогда нужно менять поведение функции free и ломать ABI.

Вот короче их ответ на вопрос когда они сделают alligned_alloc:

aligned_alloc() will probably never be implemented, as C11 specified it in a way that’s incompatible with our implementation (namely, that free() must be able to handle highly aligned allocations).

Если что в Microsoft есть функции _aligned_malloc и _aligned_free так что написать свою кросскомпиляторную обёртку несложно.

Про C11 тихо промолчим?

Ну то есть

Однако у D есть еще очень хорошее преимущество

оказалось 4.2? ЧТД

MSVC имеет лучшую поддержку С++ вплоть до С++17

Если верить вашей же табличке, то поддержка C++17 у них такая же как и у всех.

Если верить вашей же табличке, то поддержка C++17 у них такая же как и у всех.

Ну да, ну да. У меня что-то страничка перестала открываться, ладно вырезал из кеша гугла:

https://i.imgur.com/fw5yXGU.png

Не помню, чтобы они позиционировали свой компилятор, как специализированный на Си.

Какой ужас. gcc поддерживает на одну фичу меньше. msvc впереди планеты всей!

Выше уже упоминалось, что использовать C++ без C - нереально. И многие из сишных проектов на C11.

Выше уже упоминалось, что использовать C++ без C - нереально.

Кем? Покрытие c++ не означает полное покрытие c11.

И многие из сишных проектов на C11.

Даже если принять на веру это голословное утверждение, то причём тут компилятор от microsoft?

Есть проект на C++. Он использует C11 либу. Как мне его собрать через MSVC? С и C++ идут в тандеме. Нельзя поддерживать C++ без C.

Если ты не замечал, то у всех компаний предоставляющих компиляторы, компиляторы C и C++ - отдельные исполняемые файлы и это, надо полагать, не просто так.

Есть проект на C++. Он использует C11 либу. Как мне его собрать через MSVC?

Понятия не имею. MSVC не предоставляет, насколько я помню, отдельный компилятор C, поэтому поддержку C11 они никогда и не обещали и ожидать её немного странно. Поэтому ещё более странно брать для сборки чего-то неподходящие для этого инструменты.

С и C++ идут в тандеме. Нельзя поддерживать C++ без C.

Вот свои фантазии не надо тут.

Какие ещё фантазии? Любой мало-мальский C++ проект так или иначе зависит от C. А значит его тоже нужно чем-то собирать.

Как мне его собрать через MSVC?

https://docs.microsoft.com/ru-ru/cpp/build/clang-support-msbuild?view=vs-2019

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

Но если ты так уверен, то попробуй собрать какой-нибудь пример с использованием «_Genetic» компилятором C++: clang++ очень удивится, например.

А значит его тоже нужно чем-то собирать.

Компилятором C?

Или OpenBLAS зависящий от BLAS и LAPACK надо собирать тоже компилятором C++? Ну удачи.

Да всё верно, можно использовать clang C компилятор, но стандартная библиотека останется от Microsoft, а там нет всяких threads.h и stdatomic.h, но вроде все С99 инклюды есть.

Если реально есть проблема, что нужно собрать какой-то С++ проект, который использует С11 либу, то можно собрать эту либу с помощью mingw-w64 и использовать дальше в MSVC проекте.

У mingw и MSVC только плюсовое ABI разное, C ABI одинаковое, так что сишными либами можно обмениваться.

В расте нет динамической линковки. Поэтому и проблемы такой нет.

А если код совсем не писать, так вообще проблем не будет

Компилятором C?

То есть вместо С компилятора MSVC используем другой С компилятор? Очень продуктивно.

Я даже боюсь представить какие будут проблемы с линковкой всего этого чуда.

Вместо компилятора C++ использовать компилятор C и неважно что за реализация компилятора C++: я привёл пример, где это просто необходимо. Не притворяйся идиотом. В таких случаях используются библиотеки.

Я даже боюсь представить какие будут проблемы с линковкой всего этого чуда.

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

Божечки, примите успокоительные.

Я спокоен и даже не брежу как ты. Мне даже немного неловко,что вынудил тебя нести такую херню о сборке кода.

а там нет всяких threads.h

В glibc тоже их не было долгое время, в этом году вроде появились. Разве их кто то использовал?

Разве их кто то использовал?

Mesa использует, но у них своя обертка над pthreads и win32.

Ну я от своих слов не отказываюсь. А вот ваш опыт в данной теме ставлю под сомнение.

если хотели получить максимальную совместимость с другими системами то нет.

Если просто написать что-то на стандартном С, то да.

Но писать переносимый код можно, просто добавлять условие есть threads.h ? если нет, то использовать врапперы:

1. https://github.com/tinycthread/tinycthread

2. Или как уже сказали выше, можно использовать враппер из mesa(там Boost Software License, Version 1.0): https://cgit.freedesktop.org/mesa/mesa/tree/include/c11

Конечно, конечно. Куда мне до опыта успешной сборки кода содержащего фичи о которых компилятор ничего не знает.

Ну вы же лжете наглым образом. Вам прекрасно известно, что в D поддержка сишного кода намного лучше чем в том же Расте. Так что про преимущество D в этом плане никакого 4.2 нет. А вы просто делаете вбросы. Или вы будете отрицать очевидное?

Вот пример возможностей D в плане взаимодействия с другими языками.

This repository is an example of using D's powerful metaprogramming features to enable calling C code from Python without having to write any code at all.

Обращаю внимание, что ни одной строчки кода ни на C, ни на Питоне писать не нужно. И только 4(!) строчки на D. Причем три из этих строчек это имена файлов на С и Питоне. И это будет работать и для других языков.

Вот и покажите, как такую функциональность можно реализовать на другом языке - и получите ответ, в чем преимущество D.

Вам прекрасно известно, что в D поддержка сишного кода намного лучше чем в том же Расте.

С чего бы это? Я с D никогда не работал. Чем поддержка Си в нём лучше?

Я правильно понимаю, что они генерируют биндинги на этапе компиляции? Это конечно здорово, но я могу вызвать bindgen в build.rs, всё те же 4-е строчки, получить тот же самый результат.

Или оно каким-то образом оборачивает сишные в идиоматический D код?

Я с D никогда не работал

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

Чем поддержка Си в нём лучше?

Ну, если вкратце то можно спокойно вызывать как дишный код из сишечки так и наоборот. При этом что тот, что тот код (или оба) могут находится в динамической библиотеке. И для этого не нужно никаких дополнительных крейтов типа libc или инструментов, типа bindgen. Все работает из коробки. Ну, а с инструментами типа dpp вы можете напрямую включать в дишный код сишный, включая сишные макросы.

Более того, в D вы можете работать и с плюсовым кодом включая шаблоны(!), там не 100% поддержка, но тем не менее. Раст, насколько я знаю, плюсовый код вообще не может использовать.

Или оно каким-то образом оборачивает сишные в идиоматический D код?

This.

И не просто оборачивает, но и автоматически формирует врапперы для других языков типа Питона и Сишарпа.

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

Ок. Ну вот есть сишная функция, которая принимает список файлов:

void process_files(const char **files, int size);

Как мне её вызвать из D, если у меня файлы в vector<string>?

Ок.

Как я понимаю, преимущества D теперь вам стали понятны?

Нет конечно. Пока что никаких преимуществ я не увидел.

На мой взгляд, главная проблема Rust-а – это слишком агресивные упоротые Rust-оманы. Которые производят столько шума, что непонятно, есть ли вообще в Rust-сообществе нормальные люди.

Помню у одного языка с двумя плюсами на конце такая же проблема была лет 15 - 20 назад :)

Похоже это тренд в современных языках, та же засада с Go…

С++ трудно назвать современным, но у у него та же проблема, ABI нет и любая динамическая линковка или через Си или через платформозависимые вещи (например COM в windows).

А если код совсем не писать, так вообще проблем не будет

Из языков в этом треде только у си (и возможно у фортрана) нет проблем с динамической линковкой, остальные в этом плюс минус с большими проблемами, С++ и Rust практически одинаково нет ABI, у D еще к их проблемам еще добавляется рантайм с GC.

У фортрана нет проблем, он совместим с сишкой по ABI

У C++ есть Itanium ABI который уже много лет как де-факто стандарт

В отличие от плюсов и Раста у D как раз нет проблем с ABI, поскольку он стандартный.

В отличие от плюсов и Раста у D как раз нет проблем с ABI, поскольку он стандартный.

Интересно, а давно стандартизировали? Помню раньше надо было сильно приседать с инициализацией GC при динамической линковке.

Интересно, а давно стандартизировали?

ABI был стандартным с самого начала, насколько я помню. Был учтен опыт плюсов как раз.

Помню раньше надо было сильно приседать с инициализацией GC при динамической линковке.

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

Тут дело такое… Если компилятор один, и вся разработка по сути в одних руках, то и проблем таких может и не возникнуть.

а может и возникнуть.

попробуй собери код написанный на swift 3, например компилятором swift 5.

Очень уродский язык этот swift с полным забиванием на совместимость…