- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
// А какие-нибудь IDE с интегрированными отладчиками (или
// отладчики сами по себе) умеют нахрен выкидывать всякую
// там компилтайм-метушню из кода, оставляя лишь то, что
// реально исполняется в рантайме?
// Ну например, чтобы хуйня вида
if constexpr(хуйня1)
{
bagor1();
if constexpr(хуйня2)
{
bagor11();
}
else
{
bagor12();
}
}
else
{
bagor2();
if constexpr (хуйня3)
{
bagor21();
}
bagor();
}
// и если хуйня1 == true и хуйня2 == false то чтоб в отладчике
// в какой-то там говноIDE я увидел бы не эту пидоросню с if consexpr
// а только лишь
bagor1();
bagor12();
Follow us!
Может есть некий "компилтайм-препроцессор", который бы высирал код на крестах со всеми этими говноспециализациями, как если бы все это ручками кто-то писал по мотивам шаблоноговна и прочей крестометушни?
З.Ы. Разве что конпелятор должен составить по временному файлу на каждый инстанс метушни (на основе оригинальных файлов это фиг покажешь т.к. одна и та же метушня может по-разному раскрываться)... Но тогда ты хрен найдёшь откуда всё это взялось, комменты какие-нибудь разве что добавить со ссылками на оригиналы.
Мне раскрытие такой хрени не нужно, мне надо выбрасывать неиспользуемые ветки с `if constexpr'. И этот cppinsights.io как раз не умеет выкидывать `if constexpr'. Можешь проверить
->
Больше, к сожалению, ничего нят. Дебаггеры в принципе ничего ня знают про constexpr, у них есть только номера строк.
> if constexpr(false) {
И что это такое?
Я не хочу видеть никакого `if constexpr'
* Хотя можня форкнуть cppinsights и сделать выпиливание if constexpr. Если так сильня нужня.
Никто не помнит?
Знаете ли какие либо тулзы, которые генерируют JSON сериализаторы объектов на C++?
> For that you need reflection in C/C++ language, that doesn't exists. You need to have some meta data describing the structure of your classes (members, inherited base classes). For the moment C/C++ compilers doesn't provide automatically that information in built binaries.
Какой багор )))
А вот?
> А последние пару лет набирает популярность boost.hana. Это boost.fusion, но с constexpr'ом и лямбдами. Автор hana, Луис Дионе (Louis Dionne), используя на полную мощь все возможности новых стандартов, в некотором смысле очеловечил метапрограммирование. С помощью hana всяческие манипуляции с типами, их кортежами, отображениями, а также компайл- и рантайм-работа с ними обрели практически человеческое лицо и читаемый вид. Ну, с поправкой на синтаксис C++, разумеется. Вот, например, как выглядит универсальный сериализатор структур, написанный с помощью hana:
> Ну да, структуры приходится описывать особым образом. А кому сейчас легко? (какой багор ))) ) И тут хочется также отметить библиотеку tinyrefl за авторством Manu Sánchez (Мануэля Санчеса). Довольно неплохая попытка принести в мир C++-разработки статическую рефлексию без расширения компилятора. Для своей работы библиотека требует стороннюю утилиту (cppast), но зато предоставляет довольно удобный доступ к информации о структурах, которую можно использовать в процессе разработки программы.
Зачем? Зачем? Кресты - говно.
Видимо такое говноразделение придумано для оправдания говна в своем говноязыке программирования
это правда
хуже только всё остальное
А у крестухов нет на это времени, им язык не навязывает всякие правила (типа как в джаве), они ботают кресты и метушню.
А коммюнити, как известно, многое говорит о питушне. Вспомним, хотя бы, «РНР».
Давайте еще будем считать какой-то язык хуевее другого за то, что создатель одного языка был допустим негром, а другого - чистокровным арицйем.
так не бывает
вот объясните мне, какой смысл носиться с этими рецензиями (даже с такими ебанутыми как Altero!), но при этом даже близко не догадываться что они обратной силы не имеют как и все остальное (а не как в розовом мирке, где можно вычеркнуть из истории версий потомушто насильника пизнес)
Это да, старый код по свободной лицензии можно будет юзать дальше. А вот свежие патчи -- только "во имя добра".
С "JSON" в "PHP" такая история уже была. Чувакам пришлось в срочном порядке выпиливать это этичное говнище из репозиториев.
как будто бывают зависимости от еще не написанного кода
А что, только я один так делаю? о.о
Логика тут проста: у условного «РНР» есть некие характеристики, которые притягивают определённые типажи людей.
И наоборот, определённые типажи людей как мухи слетаются на объекты с характеристиками, сходными с таковыми у «РНР».
Таким образом, если на расте пишут какие-то заедушные сектанты, то явно что-то такое там есть, что притягивает именно этих людей.
А если по делу, то «С++» лучше «Rust» по той же причине, по которой «C++» лучше «Java»:
1. GC.
2. BDSM-питушня.
Но в расте нет GC!
ты можешь представить себе чтобы кто-то всерьез сравнивал кресты или сишку с языком с гц?
гц это как пожевать жвачку, и выплюнуть ее на пол, чтоб на нее кошачья шерсть налипла. Вот что такое гц
У тебя просто нормального ГЦ не было.
... а потом следующий человек аллоцировал себе жвачку с пола и положил к себе в рот. И так каждые одну-две минуты, пока программа работает.
И где BDSM-питушни больше, в Rust или C++? И что лучше, когда эта BDSM-питушня есть, или когда ее нет? И что вообще под этим термином понимается?
А в расте какие-то safe-unsafe, это плохо, прямо как исключения, которые надо ОБЯЗАТЕЛЬНО обработать. Программист не обезьянка (кроме программисов на ПХП), чтобы его ЗАСТАВЛЯТЬ. Вот ты бы стал писать какую-нибудь прошивку на расте? И я бы не стал.
Ну так никто и не заставляет. Можешь вообще абсолютно весь код завернуть в unsafe.
> Вот ты бы стал писать какую-нибудь прошивку на расте?
Я бы вполне стал, если бы мне платили за написание прошивок на расте.
Тебя найдут растосектанты и заставят переписывать код в safe. А если не перепишешь, уронят винт.
> Я бы вполне стал, если бы мне платили за написание прошивок на расте.
Вероятно, потому что ты будешь единственным программистом на расте, который пишет прошивки, а не жонглирует safe'ами.
Это кстати спорно. Но чтобы предметно что-то обсуждать, расшифруй значение выражения "BDSM-питушня"
В джаве это принудительное ООП и ГЦ, а ПХП ничего такого нет, но ПХП это не помогло.
А safe-unsafe – это главная фича раста (безопасность), поэтому программирование на расте без safe сопоставимо с программированием на джаве как я описал чуть выше.
Значит ли это, что "BDSM-питушня" существует не в языке, а в голове программиста, который решил, что раз тут вот есть такая фича в языке, и раз тут так принято писать, то я буду писать так, как принято?
На самом деле тут всё проще. На уровне языка есть BDSM-питушня, некоторые программисты считают её крайне полезной, поэтому выбирают этот язык. Если ты будешь писать не так, как они, то твой код среди программистов на таком языке будет «говнокодом», и на тебя будут смотреть как на пыхера. Оно тебе надо?
Даже пословица есть: «в чужой монастырь со своим уставом не ходят».
Я не спорю, что на джаве можно писать как на питоне, а на крестах как на сишке, но зачем?
Так это не языковая проблема, это проблема в том, кто на что как смотрит и кого кем считает в зависимости от того, кто как пишет какой-то код на каком-то там языке. Это не имеет значения в контексте сравнения свойств самого языка.
Неявно кастить void* и void main вроде, а еще что?
Чего там еще может не быть? _Generic? VLA?
В крестах правила с приведением типа с указателями другие. Например
нельзя в крестах, можно в Си. Для крестов надо указатель кастовать в нужный тип.
В си есть <iso646.h>, в крестах <ciso646> убрали из C++20
Ну и банальный sizeof('a')
Но обычно программисты работают в стаях, а даже если не работают, то писать код, который потом назовут "говнокодом" – просто неэтично, поэтому приходится считаться с мнением адептов safe-unsafe подхода, которые за unsafe могут и заклевать.
Из объективных причин, т.к. раст я не знаю, могу назвать только несоответствие инструмента решаемой задаче. Раст предполагает упарывание по "безопасности", как джавушки упарываются по "ооп", это сильные стороны этих языков, за что их и выбирают. А ты предлагаешь не пользоваться этими преимуществами, а писать как в сишке, что довольно странно звучит.
На сишке куда больше кода написано, и спецов по ней тоже куда больше
>как джавушки упарываются по "ооп",
ООП в джавке хуёвый, кстати. Протектд наследования нету, сахара для делегирования нету..
Например если мне надо чтоб мой код кто-то из раста удобно вызывал, и если мне надо из своего кода удобно вызывать код раста.
Для полуавтоматического перевода кода из си в раст кстати есть какие-то говнотрансляторы.
https://c2rust.com/
Аналогичная хрень есть для перевода Си в go, Си в D, C++ в D, еще всякие трансляторы фортрана в сишку есть.
Все апишки операционок же на сях
Там хедеры через какую-то срань конвертят же. https://github.com/rust-lang/rust-bindgen
Ну конечно не так удобно как Rust из Rust, но пользоваться можно.
Ну вот видишь. А из крестов вызов сишного кода практически бесплатен
Добавить шаг в билд-систему -- это не такая уж и ёбля... Тем более он там уже есть, скорее всего.
Это как в той истории про чела, который десять тысяч функций для Х11 руками пилил, лишь бы сишную либу не цеплять?
Вот если бы я писал большой хай перформанс проект, то наверное имело бы смысл подумать про раст
А мог бы брать https://docs.python.org/3/library/ctypes.html! Гляди, как круто:
в индентно-ориентированном язычке
огласите пожалуйста весь список woke-полных языков!
А кто такие Вуки?
лапша такая
лапшевидный код в общем
Несколько лет назад они проснулись и поняли, что мир управляется белыми мужчинами-капиталистами, и нужно отнять у них власть, чтобы везде стало так же хорошо, как в тех странах, где нет ни белых, ни капиталистов. Ну, как в Африке
Not Woke Enough: Portland Antifa Attack Pro-Gay Church
Antifa Rioters Attack Portland Church, Museum for 2nd Time in a Year
ахахахаха, это какого?
Гологуб, иди сюда, я тебе нямку принёс
https://github.com/KyleMiles/bananaScript
https://habr.com/ru/post/492410/
а если без шуток: тебе нравица борроучекер?
В текущем состоянии -- х.з., я не растишка чтобы его оценивать... А в целом -- это годная идея, которой очень не хватает в крестах когда работаешь со всякими итераторами и мувами. Возможно когда-нибудь его и в кресты завезут, хотя бы как выключенное по-умолчанию предупреждение.
Если без шуток, можно писать всё в unsafe - будет как кресты. В чем-то типа борроучекере смысл определенно есть, но я б это делал через формальные доказывания хуйни, а не как в Rust.
Это абсолютно желтушный заголовок, и статья кстати полное говно. Типа "Rust хуже C++ потому что хуевее оптимизируется на какой-то хуите", бля, ну охуеть теперь. А ничего что это не проблема языка как такового, а проблема компилятора? Давайте еще сишку с -O2 сравнивать с крестами с -O0 на древнем компиляторе, и кричать потом что вот си быстрее крестов.
☆*:.｡.o(≧▽≦)o.｡.:*☆
Один раз попробуешь стандартизированную систему сборки и централизованный репозиторий — и всю оставшуюся жизнь от крестов с сишкой будет тошнить. Останется только переходить ня NodeJS и Python (＞﹏＜).
Лучше всего конечно это сделано у BSD
Ваш раст небось тоже под досом не работает
>ня решает вопросы мультиверсионности зависимостей,
А там сайд бай сайд, как в .net и winsxs?
https://www-legacy.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-depend.html
устанавливал питон
запускал install.py
> Один раз попробуешь стандартизированную систему сборки и централизованный репозиторий — и всю оставшуюся жизнь от крестов с сишкой будет тошнить.
Раст хуже крестов потому что в расте есть удобная хрень для управления зависимостями, а в крестах нет? Эмм, че?
Какая-то альтернативная логика
В целом я считаю, что это должно быть межъязыковым, а не как сейчас. Если программа на Rust требует для сборки либу на крестах которая требует либу на Haskell, притом либа на Haskell требует либу на Common Lisp - это в рамках какого-то Cargo уже не разрулить. Про менеджеры зависимостей для языков я писал в https://govnokod.ru/20044
Короче, нужен или единый менеждер зависимостией для всего зоопарка говноязычков, или протокол коммуникации между кучей имеющихся сейчас менеджеров.
Это не какая-то фича языка. И к языку это не должно иметь отношения вообще никакого
Да.
> И к языку это не должно иметь отношения вообще никакого
Нет. Лучше иметь стандартный менеджер зависимостей, чем ня иметь.
Ты опять уходишь в характерную для тебя степь: если инструмент X ня решает все задачи ня свете, то инструмент X ня нужен. Разумеется, в реальности это ня так. Между няличием несовершенного инструмента, позволяющего решать практические задачи, и отсутствием такого инструмента (потому что очевидня, что инструмента, решающего все задачи ня свете, существовать ня может) лучше выбирать первый вариант.
Просто мало кому хочется ставить хедеры нужной библиотеки через пакетный менеджер ОС
А ты как бы хотел?
Вот есть либа FOO, для её сборки нужен Perl и Ruby с кучей джемов.
Я запустил "magic_unicorn build Foo" на винде, и мне скачалось всё для сборки, собралось, а потом скачались сырцы моей либы и тоже собрались?
Это же нужен человековек на поддержку одной либыв
Может что-то типа Nix package manager, Guix? И чтобы переносимо за пределы Linux.
Процесс сборки представляем в виде AST-дерева, местным анялогам мейкфайлов даём возможность этим деревом маняпулировать!
Для сборки Foo нужня libbar-1.6, для сборки Baz — libbar-1.5. Удачи!
Там все зависимости не конфликтующие
Именно в этом и смысл дистрибутива
На большинстве **nix либы ставятся из репы, и хела там нет.
Другой вопрос, что если ты на debian 8 захочешь Python 3.9, то пакетный менеджер разведет руками:)
Всё не нужно, чего нет. Если этого нет — то оно и не нужня.
Если бы это было так — ня было бы ни docker, ни node_modules, ни virtualenv.
Еще раз: хелла там нет. Но там вполне может не оказаться нужных тебе сущностей (см пример с python 3.9).
Ну я же три раза уже написал:
>если ты на debian 8 захочешь Python 3.9, то пакетный менеджер разведет руками:)
> Но там вполне может не оказаться нужных тебе сущностей
>мало кому хочется ставить хедеры нужной библиотеки через пакетный менеджер ОС
Разумеется, там вполне может не быть нужного тебе софта, и именно потому нужны все эти докеры и снапы и пр.
Но утверждение "пакетные менеджеры не решают проблему DLL HELL" неверно.
Они её решают, но платой за это является возможность использовать только тот софт, который они предоставляют
Для кого-то это неприемлемо (для программистов, например)
Для кого-то вполне ок (админов обычно устраивает версия bash и samba из пакетного менеджера)
Такая ситуация не может возникнуть в ОС, основанной на пакетных менеджерах: там будет либо Foo, либо Baz.
Например, тебе скажут так:
В версии 4.0 у нас есть Foo;
В версии 5.0 есть Baz
выбирай
В общем виде хелл решается только хранением каждой версии библиотеки отдельно и возможности указания версий библиотек, если вдруг необходимо привязать программу к определённой версии (эдакий pif файл).
Пакетный менеджер это попытка частично решить проблему, которая работает только для каких то конкретных задач. Справедливости ради, эти задачи охватывают большую часть пользователей.
Скорее всего да.
Кстати, в Windows есть SxS, которая эту проблему неплохо решает, как раз потому что
> хранением каждой версии библиотеки отдельно
>Справедливости ради, эти задачи охватывают большую часть пользователей
Угу. Для десктопа или небольшого офисного сервачка обычно хватает того, что есть в поставке.
А потом приходит программист, и хочет другую версию gcc, и конкретную версию postgres. И пиздец
Люди иногда покупют RedHat потому, что у них есть софт, который официально поддерживает только RH
И там в пакетном менеджере есть всё, что софт использует.
Если там чего-то нет, то программист не имеет права это использовать.
понятное дело, что это крайне высокая цена, и её платят только в особых случаях
> А потом приходит программист, и хочет другую версию gcc, и конкретную версию postgres. И пиздец
А зачем в треде про системы сборки, которые в большинстве случаев нужны исключительня программистам, предлагать инструмент, для программистов ня подходящий?
Допустим, ты пилишь софт для debian. Все зависимости ты опишешь в терминах пакетного менеджера
Очень удобный инструмент.
Правда, мода на софт, прибитый гвоздями к конкретной версии конкретной ОС, прошла где-то лет пятнадцать нязад. Или двадцать.
Он может иметь смысл только для debian. Например, это aptitude:)
Причём тут вообще ОС? Я сама собираю Foo и Baz, из исходников.
Тогда ты не можешь использовать пакетный менеджер
Это же очевидно, нет?
Кстати, пакетный менеджер тоже появился не сразу: в классическом юниксе _весь_ софт вовсе ставился с системой.
Рудименты этого можно наблюдать в некоторых BSD, где есть четкая разница между "системным софтом" (base system) и внешними пакетами.
К примеру во FreeBSD с системой ставится sendmail. Если ты хочешь поставить postfix, то sendmail нужно отключить. Его нельзя удалить -- он часть системы
С чего бы? Буквальня вчера я някатила виртуалку с Debian, поставила там через apt кучку libboost-nya-dev и спокойня собирала проект, зависящий от <boost>.
(Ироничня, кстати, что делала это я как раз для того, чтобы получить бинярник, который может работать ня одной виртуалке с древним gcc.)
Возвращая дискуссию в правильное русло: что мне нужня, чтобы собрать open-source проект ня, няпример, rust?
1. git clone ...
2. cargo build
Всё. Этими двумя командами я соберу абсолютное большинство rust-проектов ня любых поддерживаемых системах: и ня Debian, и в винде. Разумеется, ошибки и кривые руки встречаются всегда, но в языках с централизованной системой сборки и разрешения зависимостей ошибки — это исключение, а не правило.
Теперь перейдём в другой конец ринга: что мне нужня, чтобы собрать open-source проект ня C или C++?
1. git clone ...
2. Час читать документацию о том, как это собирать.
3. Час вручную устанавливать всякую хер-ню (от более-менее вменяемых make/cmake до каких-то монструозных поделий типа bazel, которые ещё и зависят чуть ли не от минорной версии восьмой джавы и ставятся только из стороннего репозитория — привет, Tensorflow!).
4. Час нястраивать всякую хер-ню, прописывая ей флаги, переменные окружения, пути к библиотекам, хидерам, .a, .so, .lib, .dll, .daiuzhesobrat... Ай, нять, да почему этот cmake ня подхватывает буст?! А, нядо его положить не в X:\dev\nay\boost-1-45\, а в X:\dev\nya\boost-1.45\...
5. Час обтекать от того, что у тебя стоит Visual Studio 2019, а для сборки нядо Visual Studio 2015; повторять всё заново.
6. Для каждой новой платформы — повторять всё с шага 1.
Для C/C++ это — норма.
Чувствуешь разницу?
В С++ вполне бывает
зы: Я собирал CEF на винде, я знаю, что такое в дебрях .bat файла исправлять пути к виндовым SDK и cl, так что боль я понимаю примерно
> в дебрях .bat файла исправлять пути к виндовым SDK и cl
(｡╯︵╰｡)
Вот как жавист со своим gradle пишет всё на groovy
Вот да, систему сборки для кода на Си можно написать на Си, чтобы там компилятор и линкер через fork()+execve() вызывался (или через system() чтоб). Один сборочный C-файл можно мейком, скомпилировать, запускать бинарник, и пусть он там сам дособирает всякую хрень.
Система сборки будет одним C-файлом который можно sh-скриптом или батником тупо собрать. А потом тот бинарник будет там что-то дальше питушить, возможно сам себя дособирать, т.е. собрать более мощную систему сборки чтоб уже всё окончательно собрать как надо.
Ну заюзаешь функцию system() на первых порах. Она в Си точно есть. А дальше базовая система сборки проанализирует доступные функции и что-то там сконфигурирует, использовать ли там виндовые аналоги fork()+execve() или есть нативный fork()+execve() и что там с многопоточной сборкой можно сделать.
и я думаю (но это не точно) что gnumake не работает без цыгвин
В mingw отлично работает.
А потом начнуится проблемы:
* на винде слеши другие
* разделители PATH другие
* кодировка не так работает
еще что-то...
Кросс-платформенную систему сборки сделать не баран чихнул
Их надо ставить, но это намного проще, чем ставить мингвин на винде всётаки
А есть даже линукс без либси.. алпайн, или как его
>проанализирует доступные функции и что-то там сконфигурируе
ты же не пытаешься аутотутлз с поддержкой винды изобрести?
автотулз это ж скриптуха на каком-то перле(automake точно perl требует) и m4, а тут Царская Сишка и никакой скриптухи. Батником компилим один .c файл, запускаем его, дальше он там сам со всей хуйней ебется.
хотя если научить её качать готовое, то не страшно
Если нядо собрать какую-то другую программу, а оня с версиями либ из твоего дистрибутива ня совместима, то тебе не надо собирать эту программу. Опен-сорс же, free as in speech!
Есть некоторые области, в которых это отлично работает.
Тащемто до середины 10-х годов это было повсеместно.
На шаред хостингах версия php и mysql зависела от версии дистрибутива, а не от желания программиста:)
Stop it, Satan!
Индустрия уже и так не очень, но по крайней мере leftpad не был написан Common Lisp.
во-первых у карги всегда есть локфайл, а у питона -- не всегда
во-вторых у карги есть cgf зависимости от разных ос, а у питона это вручнубю делают
в-третьих там есть dev/prod, а у питона нету
Лучше иметь выбор, чем ня иметь. (*¯︶¯*)
> во-вторых у карги есть cgf зависимости от разных ос, а у питона это вручнубю делают
Ня нужен. Питоняше не требуются такие костыли, он ня всех поддерживаемых платформах способен работать сразу. (⁀ᗢ⁀)
> в-третьих там есть dev/prod, а у питона нету
Питоняше ня нужна prod-конфигурация: она все равно будет тормозить. (￢‿￢ )
Пока не возникало потребности использовать локфайл.
> во-вторых у карги есть cgf зависимости от разных ос,
Пока не возникало необходимости использовать ос-специфичный код.
> в-третьих там есть dev/prod, а у питона нету
Пока не возникало потребности разделять код на продакшен и дев
https://nnethercote.github.io/perf-book/bounds-checks.html
Fossil is a simple, high-reliability, distributed software configuration management system with these advanced features:
Project Management - In addition to doing distributed version control like Git and Mercurial, Fossil also supports bug tracking, wiki, forum, email alerts, chat, and technotes.
All-in-one - Fossil is a single self-contained, stand-alone executable. T
а индеец-программист бывает?
а цыган?