Подробнее
resolution • (xj 3372 Errors A0cf45Wirangs '1 0 Messages 3u*d0nly Code Description Reference required to assembly '< Missing Core Assembly», VemomtiMty Cdturexnei/lJ one to your project Reference required to assembly '< Missing Core Assembly». VersonrOMD. Cufture=neut| one to your project. Type Diroonar/ is rot def ied Reference required to assembly '«Mining Core Assembly». VenionsOMflt Cufture: neub| one to your project Type Possib «Modules a not di'ired Reference required to assembly '< Missing Core Assembly>, Vernon:0 OlO.C, Cubure= neutr j one to your project. List bas no type oar jiretrs and so cannot have type a'q jnents. Reference required to assembly < Missing Core Assembly>. Vers oreO 0.04 Cuburemeuti^ one to your project Type Type «not del.nec Reference required to assembly < Missing Core Assembly», YenorcOOJXC, Cubure=n«utii one to your project Type ’SystervVoNftsnot defned -£ra
it-юмор,geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,Are Ya Winning Son?
Еще на тему
>сначала запустите гребаный симейк чтобы создать солюшен из овер9к разновидностей всевозможных компиляторов
>затем когда эта срань закончит, запустите билд сорс кода, который будет билдится хуй знает сколько времени потому что умники разработчики в соотвествии со всеми правилами элегантного дизайна понатыкали везде кучу темплейтов, инклюдов в стандартные библиотеки, которые раздувают код до сотен тысяч строк, когда ты пользуешься всего-лишь одной функцией из либы
>конечно же сорс код поделен на тысячи компилейшен юнитов каждый из которых будет компилироваться заново, потому что сука потому что.
>под конец ебучий линкер кряхтя пердя и охуевая будет пытаться это говно собрать воедино.
И это все причина почему код на крестах компилится минуты, часы, в охуевших случаях типа хромиума сутки. Просто потому что люди в комитете крестов далеки от реальной разработки, а обычные погромизды долбоёбы, которые следуют по заветам теоретиков, а в итоге получается такое дерьмо. Хотя по факту код пусть даже из миллионов строк не должен компилиться на каком-то среднем текущем процессоре больше 10 сек.
Комитет как раз и рад бы модули запилить, только в нем есть 100500 компаний с правом вето которым и так норм.
Плюсы как яп конеш помойка, только вот люди на нем пишут не самые тупые. Так что жду рекомендаций, как плюсовики-недолбоёбы пишут.
P.S. Бай зе вей, на картинке - не плюсы, а сишарп.
ниразу не видел такого
и то всеравно все билдится, а вот если паблишить то может вылететь ошибка где укажет версию библиотеки которая надо, и какая есть
может потому что с кором работаю потому и не видел такие ошибки
и все что ехало это стартап
понятно что нагеты тоже едут, но это и так понятно
Почти, другалёк, юнити билд погугли. К сожалению пользуются им в основном в гейдеве, потому что там нужно выжимать максимум производительности. Те же юбики его юзают.
>Комитет как раз и рад бы модули запилить, только в нем есть 100500 компаний с правом вето которым и так норм.
Ну кресты и так на издыхании находятся, пользуются ими просто потому что больше нечем. Когда появится вменяемая альтернатива где будут и вменяемые хай левел абстракции: темплейты, метапрограмминг и т.д. и к лоу левелу не будет закрыт доступ: работа с сырой памятью, возможность встраивать ассембли напрямую, тогда кресты пойдут нахуй далеко и надолго.
>Плюсы как яп конеш помойка, только вот люди на нем пишут не самые тупые. Так что жду рекомендаций, как плюсовики-недолбоёбы пишут.
Дата ориентированный дизайн. Минимум абстракций, никаких иерархий, не каплить дату с функциями. Такое делают к сожалению опять-таки только в гейдеве, где юзерам нужно минимум 60 фпс и приходится выжимать все соки, а не выебываться абстрактными абстракциями и 6-слотовыми наследованиями.
Имхо, C# движется в хорошем направлении и по моему в нем все есть. Конечно напрямую с памятью проблематично работать, но у меня не возникало такой необходимости. Асм вставки тоже ну что-то ну очень прям экзотическое для этого должно быть...
C# достаточно зрел+ мультиплатформенен, а в .Net Core так вообще не требуется больше иметь на ПК исполняемую среду и можно Standalone компиляцию делать.
Т.е он должен удволитворять 80% все задачи.
А темплейты тебе чем не метапрограммирование?
https://www.tiobe.com/tiobe-index/
Поэтому когда тру-сишник не знает, что такое принцип единой ответственности, и лезет из многих потоков мимо буфера потому что "я точно знаю што там а если там не так то виноват Васян который забыл что в этой ситуации в этой функии этот инт не просто инт, а поинтер на вон ту штуку с которой надо что-то сделать", то для меня это не трушность, а глупость.
Ну и наконец, даже если не спорить про тупость кодеров: и что дальше с этим делать? НУ окей, допустим кодеры тупые, они НЕ МОГУТ писать на супер-си, а писать кому-то надо или нет? Вот и придумывают всякие хрусты и жабы, которые не позволяют по ногам стрелять, говорят "а вы тут лок забыли на шаред переменную" и прочие непотребства. Ишь чего придумали, владение, заимствование, лайфтаймы, иммьютабл, набор каких то слов бесполезных, нормальный программист никогда не ошибётся и два раза не напишет фри или не начнёт мутировать из 2 ух потоков данные без синхронизации
Чувак, ты осознаёшь, что споришь с голосами в голове? Никто ни слова в этом треде не сказал про "трусишников", кроме тебя самого, а ты рванул в полемику непонятно с кем.
- код ядра линукс и модулей ядра
- код от которого требуется высокое быстродействие
- код для микроконтроллеров и прочего
те он был и будет всегда, замены ему нет и не будет.
собственно зачем менять то, что отлично работает больше 50ти лет?
Плюсы в мире вряд ли вымрут, у них огромная ниша — уже написанный код (+ графические движки), но их вполне могут сильно потеснить в новых проектах.
И не нужно смешивать C/C++, плюсы менее популярны судя по твоему же скрину, а совместимость с С у них не больше, чем в других си-подобных языках.
А вот раст - другое дело. Ну и нужно понимать, что такое убьет - вот убили плюсы сишку? Не, живут себе в узкой нише типа эмбеда и радуются. Но объективно понятно, что сишку выкинули отовсюду, где она была: операционки на них не пишут, только саппортят виндолинухи которые никто никогда конечно не перепишет, прикладной софт не пишут, и так далее. Так же и раст, уже сейчас все HFT биржи пишутся на расте как я знаю, хайлоад веб тоже на нем пишут, не зря майкрософт задонатил разработку actix, ну и так далее. Процесс небыстрый, лет 10 точно займет, может больше, и то в конце концов какая-то доля у плюсов все равно останется: доля легаси. А она в любом языке есть. Вот кто помнит про КОБОЛ? А в ньюджерси вон в этом году искали программиста на него, у них там система поломалась, нужен был человек чтобы починить. Но пусть бросит в меня камень тот, кто считает что кобол не умер.
https://twitter.com/ID_AA_Carmack/status/1089286703817412608
Развитие плюсов очень медленное из-за того количества обратной совместимости которую требуют поддерживать. Доходит до смешного: я слышал от разрабов гцц что они делают обратно-совместимое УБ, чтобы новые версии УБ так же компилировали, как старые. Казалось бы, именно тот случай, Когда можно сделать по-нормальному. Но вот так вот.
ИМХО про развитие плюсов можно следить по скорости внедрения модулей и концептов. Будем надеяться, что в ближайшие лет 5 их завезут, но я не уврене.
Ты это блядь сейчас серьезно?
Чувак, ты говоришь о том, о чём понятия не имеешь. Операционки на C не пишут, мухаха! Ты вообще в разработке скольких современных операционок принимаешь участие? Значительная часть множества систем пишется на C. Весь сетевой стек TCP/IP, вообще ядерная часть операционных систем и некоторые другие подсистемы, не говоря уже на *BSD, которые практически целиком на C за небольшими вкраплениями С++. В MacOS X используется не только C, но на C написана базовая часть, как и базовая часть iOS (Swift получил более менее стабильное API только с тринадцатой версии iOS).
И хватит писать С/С++, это разные языки, я же не пишу С/Rust. Код плюсов вряд ли когда-нибудь пустят в код линукс, что не похоже на ситуацию великой схожести языков. Да они даже не совместимы между собой! Я перешёл когда-то с плюсов на си, а потом ушёл на раст — так мне писать C++/C/Rust? Gtk живёт со всеми языками в мире и согласии, написан на чистом си, кьют разве что сам с собой играет, поддержка других языков у него отвратительная из-за врождённой плюсовости.
Нишу С (как лингва франка, хотя си этим и не ограничивается) никто не тронет в ближайшие годы, ниши С++ не существует, он старается быть всем, как и многие другие языки.
Ну а «такие гении как ты» твердили, что какая-то джава-выскочка будет даже не замечена плюсами (сейчас же по все рейтингам джава популярнее плюсов, даже не смотря на появление кучи других jvm-языков, потеснивших уже саму джаву), затем в начале нулевых писали, что в геймдеве равных плюсам нету, а потом крайенжин получил части на шарпе, вышел шарповый юнити, на котором сегодня большинство поделок выходят. Или чего ты ждёшь — мгновенного схода на нет плюсов? Они будут жить долго, но их слава с годами меркнет всё сильнее, просто потому что новые языки вытесняют старые, с чем плюсы не смогут бороться, не сломав обратную совместимость, но тогда это уже будут не плюсы.
И C# никогда не стремился отобрать всё у C/C++, он стремился быть более специализированным, как и Java. И Java успеха достигла большего — кровавый энтерпрайз именно с джавой связывают.
А что не так с тем, что я написал ввше? Я написал именно о рейтинге ПОПУЛЯРНОСТИ который основываеться на количестве запросов. Но ладно можем глянуть другие рейтинги IEEE, PYPL, RedMonk и что ты увидишь? Что С/С++ в топе и не опускакться ниже 5 места уже на протяжении многих лет, а если говорить про количество написангого кода на С/С++ то вообще лучше не выебываться.
Во-вторых рейтинг TIOBE показывают что люди гуглят. То есть если есть популярная жаба у которой есть нормальная дока и проблемы с которой бывают сравнительно редко, то в рейтинге она будет низко - ну не гуглят люди.
И наоборот, возьмем какой-нибудь VB с 0 использованием, но у которого дохрена проблем и нет документации, в рейтинге будет высоко.
То что рейтинг говно очевидно - ну НЕ МОЖЕТ быть VB выше JS, ну вот вообще никак, даже на другой планете. Это очевидно каждому кто хоть чуть-чуть в теме разработки.
не нравится SO? Ну возьми любой рейтинг, хоть гитхаб, хоть статистику hh/любого другого агрегатора вакансий. Да хоть твой RedMonk на который ты сослался
1 JavaScript
2 Python
2 Java
4 PHP
5 C#
6 C++
7 Ruby
7 CSS
9 TypeScript
9 C
11 Swift
12 Objective-C
13 Scala
13 R
15 Go
15 Shell
17 PowerShell
18 Perl
19 Kotlin
20 Haskell
В это я ещё готов поверить. В си на первом месте и вб выше JS - уж извини, но никак.
int func();
int main() {
func(1, 2);
return 0;
}
А вот g++ уже нет.
С++ далеко не на первом месте. Возможно в районе пятого. Си где-то в конце десятки. Собственно, я это сказал не глядя на рейтинг выше, и щас глянул, так и есть.
Ну и нужно понимать объемы кода. Места это места, но реально первые 3 места это 90% всего рынка софта. Люди которые говорят что он умрет скоро конечно ошибаются - умирать он будет как кобол, ещё лет 20-30 точно, а можно и больше.
C# Unity
>системные программисты, программисты микросхем и электроники
Полторы позиции в мире.
>VR
C# Unity
>медицинское оборудование
Еще половина позиции в мире.
>десктопные приложения,
Почти никто не пишет на плюсах
>операционики, драйвера и так далее.
Еще полторы позиции в мире
>Альтернативы вы где а то С/С++ 1 место в рейтинге популярности языков занял.
Мммм, как интересно. И что же этот рейтинг популярности обозначает? Особенно Visual Basic и R в первой десятке?
Цифры давай. А то пишет у него огромное количество, а вакансий в 10 раз меньше, чем в геймдеве, и в 150 раз чем у веб-макак.
Насчет цифр - погляди статистику количества нового кода на C в одних только ядрах Линукса между релизами.
Для приватной разработки in-house медицинского софта никто тебе не будет показывать код.
Код линукса это жалкие 28 миллионов строк кода, столько кода каждый час в мире пишется. И только процентов 10-20 из них - на С или С++.
Судя по тому, что я читаю, этот юнити билд судя по всему не серебрянная пуля. Например, видимо он не умеет в инкременталку и при изменении одной строчки пересобирает всё приложение. Удачи поработать так с любым крупным приложением, особенно упомянутым тобой хромиумом. Неплохо про минусы тут собрано: http://web.archive.org/web/20161021225056/https://engineering-game-dev.com/2009/12/15/the-evils-of-unity-builds/
> Ну кресты и так на издыхании находятся, пользуются ими просто потому что больше нечем. Когда появится вменяемая альтернатива где будут и вменяемые хай левел абстракции: темплейты, метапрограмминг и т.д. и к лоу левелу не будет закрыт доступ: работа с сырой памятью, возможность встраивать ассембли напрямую, тогда кресты пойдут нахуй далеко и надолго.
У нас 2 микросервиса на расте уже написаны, полёт нормальный.
> Дата ориентированный дизайн. Минимум абстракций, никаких иерархий, не каплить дату с функциями. Такое делают к сожалению опять-таки только в гейдеве, где юзерам нужно минимум 60 фпс и приходится выжимать все соки, а не выебываться абстрактными абстракциями и 6-слотовыми наследованиями.
Если у тебя проблема с абстракциями то тебе в го, там с этим всё хорошо, нет ни абстракций, ни способа их сделать. Лепота.
Не, я согласен, что лишние абстракции копить не стоит, а наследование имплементации не нужно, но обычно люди которые говорят про "лишние" абстракции даже инкапсулировать какой-нибудь filterM не могут, копипасятят каждый раз.
Так и живем.
А это основные источники медленной компиляции.
Как нетеоретик, отвечаю. Во-первых, использовать такие либы только в самом крайнем случае, если без этого никак не обойтись. По возможности вместо тяжелых внешних зависимостей, когда нужна одна функция, либо делать свою реализацию, либо даже тупо вырезать функцию из либы и скопипастить локально - если это поможет убрать тяжелую зависимость. Во-вторых, не использовать системы сборки, которые заставляют пересобирать те модули, которые можно не пересобирать, даже если такие системы супермодерновые и модные. В третьих, изучать документацию на используемые фреймворки и пакеты и отключать сборку опциональных компонентов, а не собирать всё подряд без нужды. В четвертых, использовать оптимизаторы сборки типа METAMODE или ccache, но использовать их с умом. Ну и там по мелочи всякое, типа использовать оперативную память для TMPDIR (ramdisk), в крайнем случае SSD, в самом крайнем случае отдельный HDD, чтобы головки одного диска не перепозиционировались лишний раз; и уж точно при использовании HDD не размещать каталоги исходников и результатов компиляции (объектников, библиотек и исполняемых файлов) на одном HDD.
Короче, не быть тупым кодером и изучать матчасть.
2. ну, инкрементные билды обязательно нужны, с этим никто не спорит
3. тоже логично
4. и тут тоже согласен
Но там же по сути речь не про зависимости, а про "абстракций много, файлов много, всё плохо". Много файлов обычно означает хорошую декомпозицию, и это плюс, а не минус. Абстракций - их да, должно быть поменьше, но обычно эту фразу пишут люди которые предпочитают функции по тыщи строк делать, "а чо и так понятно, зато смари как быстра, ЭКОНОМИМ НА ДЖАМПАХ".
Согласен, что если в языке нет нормального пакетного менеджера то подключать библиотеку может быть дороже чем её написать самостоятельно, сюда можно и однострочные cfg_if! вспомнить. Но надеюсь с vcpkg у вас с этим станет попроще.
2)Нигде в правилах элегантного кода не слышал что бы юзали кучу инклюдов и темплейтов. Все как один говорят да блять не юзай тимплейт если он тебе не нужен, не создавать эти уродливые иерархи классов. НЕ ПЛОДИ СУЩНОСТИ СУКА НЕ ПЛОДИ СУЩНОСТИ
3) конечно же сорс код поделен на тысячи компилейшен юнитов , может он как раз специально и поделен что бы заново всю эту хуйню не компилить ?
4)Придумали еще такую штуку как Dll и тебе не нужно ее компилить, да оф кос гиганский проект собирается долго. Но как бы преимущество компилируемого языка не в скорости сборки а в скорости выполнения программы.
5) Ты хоть раз читал C++ ISO? ану что тебе в нем не нравиться? да есть всякое говницо но его стараються убирать и даже в каждом обновлении убирают. И ISO этот как раз классная штука которая делает С++ стабильным.
6) Каким хуем за 10 секунд программный код в миллионы строк должен стать соптимизированным объектным кодом ? ты блять просто посчитай
2)Нигде в правилах элегантного кода не слышал что бы юзали кучу инклюдов и темплейтов. Все как один говорят да блять не юзай тимплейт если он тебе не нужен, не создавать эти уродливые иерархи классов. НЕ ПЛОДИ СУЩНОСТИ СУКА НЕ ПЛОДИ СУЩНОСТИ
Объясни это мартыханам, которые без темплейтов и посрать не сядут: нужнапростенькая хэш таблица — темплейт, нужен динамический массив или линкед лист — темплейт.
3) конечно же сорс код поделен на тысячи компилейшен юнитов , может он как раз специально и поделен что бы заново всю эту хуйню не компилить ?
Что значит конечно же, мартыхан. Юнити билд еще раз для тупых повторяю ЮНИТИ БИЛД, чем меньше компилейшен юнитов в сорсе, тем быстрее он будет компилиться. Потому что не надо парсить с нуля каждый юнит.
4)Придумали еще такую штуку как Dll и тебе не нужно ее компилить, да оф кос гиганский проект собирается долго. Но как бы преимущество компилируемого языка не в скорости сборки а в скорости выполнения программы.
Чушь собачья насчет скорости. Сопоставимые проекты по кодо-базе: хромиум и к примеру последний асасин у юбисовта. Хромиум компилится сутки, асасин компилится несколько минут и то это дохуя, но это уже предел для слоупочного с++ компилятора и линкера. Потому что в одном случае делают код люди с мозгами и пониманием аппаратной платформы и дата-ориентированного дизайна, в другом ооп-мартыханы.
>Каким хуем за 10 секунд программный код в миллионы строк должен стать соптимизированным объектным кодом ? ты блять просто посчитай
Что посчитай мартыхан? На современном кукурузене 12-ядерном кернел линупса должен компилиться меньше чем за секунду, в противном случае это мартышкин код.
Ты главную идею не понимаешь, что текущие кододелы выезжают на ахуенной производительности и росте железа, что позволяет писать ультра хуевый и не оптимизированный код. И это плохо я так считаю.
Ну-ка, объясни, как это сделать. Я на си пишу, где темплейтов нету. Поэтому никаких стандартных контейнеров тоже нету. Ну-ка, расскажи, как мне делать хэш таблицу? Каждый раз руками заново под каждую структуру? На void? На уродливых извращениях с макросами в стиле "struct hash_##_TYPE", что по-сути есть тот же темплейт, только на минималках и под бутиратами.
> Что посчитай мартыхан? На современном кукурузене 12-ядерном кернел линупса должен компилиться меньше чем за секунду, в противном случае это мартышкин код.
Начали за С++ и темплейты, а щас чот к Си пришли. Ну давай, покажи мне пруфы, что код по объему и сложности сопоставимый с кернелом, может скомпилироваться меньше, чем за секунду. Давай, расскажи, если ты такой дохуя умный и не мартыхан, как правильно надо было писать кернел. Кернел пишут далеко не дураки, не макаки-формошлепы на жс. И довольно высокие стандарты, чтобы твой патч приняли. Сам не посылал, но знаю тех, кто разрабатывает драйвера.
О боже мой, ты ещё не открыл для себя готовые библиотеки на C? Libaura, gperf, cmph, glib, libcfu, uthash, Google SparseHash, libthmap, libmba, libmaa, libhash, publib, libcdb, libmowgli-2, htable, libds, pdel - всё это бесплатные и открытые библиотеки с универсальными реализациями для hashmap, выбирай на вкус и под задачу. Есть и в виде h-файлов.
https://developer.gnome.org/glib/stable/glib-Hash-Tables.html#g-hash-table-insert
И что мы видим?
gboolean
g_hash_table_insert (GHashTable *hash_table,
gpointer key,
gpointer value);
А gpoonter это
typedef void* gpointer;
Что я и говорил: void*.
Ещё работал с https://linux.die.net/man/3/queue, там аналогично.
Щас просматривать все перечисленные имплементации мне лень. Но выше я перечислил все известные мне способы делать контейнеры и обобщенные алгоритмы. Ну ещё типо "дженерики" из С11. Поэтому мой вопрос - знаете ли вы другие способы? Потому что все они уебанские, не мне вам говорить, чем плох void*.