1. C++ / Говнокод #27364

    0

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    31. 31
    32. 32
    33. 33
    34. 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();

    Есть ли такое?

    Запостил: j123123, 18 Апреля 2021

    Комментарии (176) RSS

    • На кой хуй мне в отладчике при какой-нибудь пошаговой отладке видеть всякую компилтайм-поебень, которая никакой рантайм-интерпретации не имеет?

      Может есть некий "компилтайм-препроцессор", который бы высирал код на крестах со всеми этими говноспециализациями, как если бы все это ручками кто-то писал по мотивам шаблоноговна и прочей крестометушни?
      Ответить
      • Хер знает... Отладчики же тупые обычно, они и текстовый файл(!) отлаживать могут если символьная инфа на него ссылается.

        З.Ы. Разве что конпелятор должен составить по временному файлу на каждый инстанс метушни (на основе оригинальных файлов это фиг покажешь т.к. одна и та же метушня может по-разному раскрываться)... Но тогда ты хрен найдёшь откуда всё это взялось, комменты какие-нибудь разве что добавить со ссылками на оригиналы.
        Ответить
      • Есть: https://cppinsights.io. Локальняя версия тоже есть.
        Ответить
        • Там оно выдает какую-то нечитаемую вербозную хрень, например `std::cout << "test1" << "test2\n";' заменяется на `std::operator<<(std::operator<<(std::co ut, "test1"), "test2\n");'

          Мне раскрытие такой хрени не нужно, мне надо выбрасывать неиспользуемые ветки с `if constexpr'. И этот cppinsights.io как раз не умеет выкидывать `if constexpr'. Можешь проверить
          Ответить
          • Проверила, всё прекрасня выкидывается:
            #include <cstdio>
            
            template<bool B>
            void f() {
              if constexpr (B) {
               std::puts("true");
              } else {
               std::puts("false"); 
              }
            }
            
            int main() {
              f<true>();
              f<false>();
            }

            ->
            #include <cstdio>
            
            template<bool B>
            void f() {
              if constexpr (B) {
               std::puts("true");
              } else {
               std::puts("false"); 
              }
            }
            
            /* First instantiated from: insights.cpp:13 */
            #ifdef INSIGHTS_USE_TEMPLATE
            template<>
            void f<true>()
            {
              if constexpr(true) {
                puts(static_cast<const char *>("true"));
              } 
              
            }
            #endif
            
            
            /* First instantiated from: insights.cpp:14 */
            #ifdef INSIGHTS_USE_TEMPLATE
            template<>
            void f<false>()
            {
              if constexpr(false) {
              } else /* constexpr */ {
                puts(static_cast<const char *>("false"));
              } 
              
            }
            #endif
            
            
            int main()
            {
              f<true>();
              f<false>();
            }

            Больше, к сожалению, ничего нят. Дебаггеры в принципе ничего ня знают про constexpr, у них есть только номера строк.
            Ответить
            • > if constexpr(true) {
              > if constexpr(false) {

              И что это такое?
              Ответить
              • Оператор if. Как видишь, няиспользуемые ветки были успешно выкинуты.
                Ответить
                • Мне там вообще никакого `if constexpr' не нужно. Мне нужно само std::puts("true"); или std::puts("false");

                  Я не хочу видеть никакого `if constexpr'
                  Ответить
                  • Тогда никак. *

                    * Хотя можня форкнуть cppinsights и сделать выпиливание if constexpr. Если так сильня нужня.
                    Ответить
    • Не много ли ты хочешь?
      Ответить
    • Кстати, помню сюда выкладывали багор типа
      if (false) {
         if constexpr (...) { // или как-то по-другому 
            kakoi_bagor(); // вызывается 
         }
      }

      Никто не помнит?
      Ответить
    • Всем привет. У меня опять вопрос.
      Знаете ли какие либо тулзы, которые генерируют JSON сериализаторы объектов на C++?
      Ответить
      • https://stackoverflow.com/questions/17549906/c-json-serialization/34165367

        > 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.

        Какой багор )))
        Ответить
        • https://m.habr.com/ru/post/311262/

          А вот?
          Ответить
          • Ээээ... этот сериализатор разве умеет инспектить типы в классах и на основе этого чего-то там сериализовать, подписывая хуиту именами типов класса? Я там этого не вижу
            Ответить
          • В крестах сейчас нет возможности сделать так, что вот если у тебя описана структура вида
            struct fuck
            {
              int crap;
              char shit;
            }
            
            struct fuck my_struct = {123, 'z'};
            
            print_shit(my_struct);
            // чтоб эта хуина вывела допустим
            {
              "str_name":"fuck",
              "crap": {"int", "123"},
              "shit":' {"char", "z"}
            }
            Ответить
          • https://habr.com/ru/article/448466/

            > А последние пару лет набирает популярность boost.hana. Это boost.fusion, но с constexpr'ом и лямбдами. Автор hana, Луис Дионе (Louis Dionne), используя на полную мощь все возможности новых стандартов, в некотором смысле очеловечил метапрограммирование. С помощью hana всяческие манипуляции с типами, их кортежами, отображениями, а также компайл- и рантайм-работа с ними обрели практически человеческое лицо и читаемый вид. Ну, с поправкой на синтаксис C++, разумеется. Вот, например, как выглядит универсальный сериализатор структур, написанный с помощью hana:

            // 1. Give introspection capabilities to 'Person'
            struct Person {
              BOOST_HANA_DEFINE_STRUCT(Person,
                (std::string, name),
                (int, age)
              );
            };
            // 2. Write a generic serializer (bear with std::ostream for the example)
            auto serialize = [](std::ostream& os, auto const& object) {
              hana::for_each(hana::members(object), [&](auto member) {
                os << member << std::endl;
              });
            };
            // 3. Use it
            Person john{"John", 30};
            serialize(std::cout, john);


            > Ну да, структуры приходится описывать особым образом. А кому сейчас легко? (какой багор ))) ) И тут хочется также отметить библиотеку tinyrefl за авторством Manu Sánchez (Мануэля Санчеса). Довольно неплохая попытка принести в мир C++-разработки статическую рефлексию без расширения компилятора. Для своей работы библиотека требует стороннюю утилиту (cppast), но зато предоставляет довольно удобный доступ к информации о структурах, которую можно использовать в процессе разработки программы.
            Ответить
            • Сколько же всякой хуйни надо знать, чтобы быть крестобоярином!
              Ответить
              • > чтобы быть крестобоярином!

                Зачем? Зачем? Кресты - говно.
                Ответить
                • Языки программирования бывают ровня двух типов: говно и никому ня нужные.
                  Ответить
                  • Есть языки, которые нужны и которые значительно менее говно, чем кресты.
                    Ответить
                  • Ну и конечно есть и такие языки, которые и говно, и никому не нужны. Так что такое разделение языков на категории - говно.

                    Видимо такое говноразделение придумано для оправдания говна в своем говноязыке программирования
                    Ответить
                    • По этому я за lua
                      Ответить
                    • Страуструп пытался красиво обобщить но абстракция как обычно одинаково хуево налезла на все юз кейсы
                      Ответить
                • >Кресты - говно.
                  это правда

                  хуже только всё остальное
                  Ответить
                  • Чем же Rust хуже?
                    Ответить
                    • Тем, что ядро Линукс хотят переписать на раст.
                      Ответить
                      • Как это относится к вопросу о том, чем же Rust хуже C++?
                        Ответить
                        • Тем, что растушки захотели переписать ядро Линукса на раст, но обосрались (анскилльные) и Линус их за это обоссал.
                          Ответить
                          • Комбо будет если их ещё подожгут.
                            Ответить
                            • Да, у них знатно подгорело, т.к. всякая safe-unsafe BDSM-питушня им совсем разжижила мозг (как джаверам), и Линус во всеуслышание это обнародовал. Теперь каждый системный программер смотрит на растуха как на говно и пишет на няшной классической сишке.
                              Ответить
                              • ты бы слышал, что Линус про кресты говорит)
                                Ответить
                                • Как только Линус начинает что-то говорить про кресты, я затыкаю уши и громко пищу.
                                  Ответить
                          • Я все еще не вижу связи с вопросом "чем же Rust хуже C++?"
                            Ответить
                            • В расте коммьюнити заедушное. Они какого-то прогера так ЗАКОЛЕБАЛИ тем, что он, видите ли, неправильно пишет на расте, что ему пришлось удалить гитхаб из-за опасений за собственную жизнь.

                              А у крестухов нет на это времени, им язык не навязывает всякие правила (типа как в джаве), они ботают кресты и метушню.

                              А коммюнити, как известно, многое говорит о питушне. Вспомним, хотя бы, «РНР».
                              Ответить
                              • Я опять не понял, каким хреном это характеризует соотношение качества ЯЗЫКА C++ и ЯЗЫКА Rust

                                Давайте еще будем считать какой-то язык хуевее другого за то, что создатель одного языка был допустим негром, а другого - чистокровным арицйем.
                                Ответить
                                • Именно поэтому я за "PHP".
                                  Ответить
                                • Качества языка это не характеризует, а вот желание связываться с экосистемой языка — вполне. Если я что-то выкладываю на гитхаб, я ожидаю, по крайней мере, что меня за это не будут травить или шеймить. Ну и что зависимости моего проекта за ночь не сменят лицензию со свободной на "этическую".
                                  Ответить
                                  • > сменят лицензию
                                    так не бывает

                                    вот объясните мне, какой смысл носиться с этими рецензиями (даже с такими ебанутыми как Altero!), но при этом даже близко не догадываться что они обратной силы не имеют как и все остальное (а не как в розовом мирке, где можно вычеркнуть из истории версий потомушто насильника пизнес)
                                    Ответить
                                    • > обратной силы не имеют

                                      Это да, старый код по свободной лицензии можно будет юзать дальше. А вот свежие патчи -- только "во имя добра".

                                      С "JSON" в "PHP" такая история уже была. Чувакам пришлось в срочном порядке выпиливать это этичное говнище из репозиториев.
                                      Ответить
                                      • > старый код
                                        как будто бывают зависимости от еще не написанного кода
                                        Ответить
                                • > Давайте еще будем считать какой-то язык хуевее другого за то, что создатель одного языка был допустим

                                  А что, только я один так делаю? о.о

                                  Логика тут проста: у условного «РНР» есть некие характеристики, которые притягивают определённые типажи людей.

                                  И наоборот, определённые типажи людей как мухи слетаются на объекты с характеристиками, сходными с таковыми у «РНР».

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

                                  А если по делу, то «С++» лучше «Rust» по той же причине, по которой «C++» лучше «Java»:

                                  1. GC.
                                  2. BDSM-питушня.
                                  Ответить
                                  • > 1. GC.

                                    Но в расте нет GC!
                                    Ответить
                                    • Он в «Go», да? Опять перепутал (((
                                      Ответить
                                      • да

                                        ты можешь представить себе чтобы кто-то всерьез сравнивал кресты или сишку с языком с гц?

                                        гц это как пожевать жвачку, и выплюнуть ее на пол, чтоб на нее кошачья шерсть налипла. Вот что такое гц
                                        Ответить
                                        • > гц это как пожевать жвачку, и выплюнуть ее на пол, чтоб на нее кошачья шерсть налипла. Вот что такое гц

                                          У тебя просто нормального ГЦ не было.
                                          Ответить
                                          • Ладно, для функциональщины можно сделать исключение
                                            Ответить
                                        • > гц это как пожевать жвачку, и выплюнуть ее на пол, чтоб на нее кошачья шерсть налипла. Вот что такое гц

                                          ... а потом следующий человек аллоцировал себе жвачку с пола и положил к себе в рот. И так каждые одну-две минуты, пока программа работает.
                                          Ответить
                                  • > 2. BDSM-питушня.

                                    И где BDSM-питушни больше, в Rust или C++? И что лучше, когда эта BDSM-питушня есть, или когда ее нет? И что вообще под этим термином понимается?
                                    Ответить
                                    • Я сейчас подумал... Да, в крестах BDSM-питушни больше, но она не мешает писать программы.

                                      А в расте какие-то safe-unsafe, это плохо, прямо как исключения, которые надо ОБЯЗАТЕЛЬНО обработать. Программист не обезьянка (кроме программисов на ПХП), чтобы его ЗАСТАВЛЯТЬ. Вот ты бы стал писать какую-нибудь прошивку на расте? И я бы не стал.
                                      Ответить
                                      • > А в расте какие-то safe-unsafe, это плохо, прямо как исключения, которые надо ОБЯЗАТЕЛЬНО обработать. Программист не обезьянка (кроме программисов на ПХП), чтобы его ЗАСТАВЛЯТЬ.

                                        Ну так никто и не заставляет. Можешь вообще абсолютно весь код завернуть в unsafe.

                                        > Вот ты бы стал писать какую-нибудь прошивку на расте?

                                        Я бы вполне стал, если бы мне платили за написание прошивок на расте.
                                        Ответить
                                        • > Ну так никто и не заставляет.

                                          Тебя найдут растосектанты и заставят переписывать код в safe. А если не перепишешь, уронят винт.

                                          > Я бы вполне стал, если бы мне платили за написание прошивок на расте.

                                          Вероятно, потому что ты будешь единственным программистом на расте, который пишет прошивки, а не жонглирует safe'ами.
                                          Ответить
                                      • > Да, в крестах BDSM-питушни больше, но она не мешает писать программы.

                                        Это кстати спорно. Но чтобы предметно что-то обсуждать, расшифруй значение выражения "BDSM-питушня"
                                        Ответить
                                        • «BDSM-питушня» – фичи языка, которые ограничивают программиса в написании всяких штук.

                                          В джаве это принудительное ООП и ГЦ, а ПХП ничего такого нет, но ПХП это не помогло.
                                          Ответить
                                          • В Rust ты можешь писать всю хуйню, через unsafe, никто ничего не ограничивает.
                                            Ответить
                                            • А на джаве можно писать всё в одном классе Main, и будет процедурное программирование! А если ещё немного всякого кода дописать для иммутабельности, то и функциональное программирование будет. Но так обычно не делают.

                                              А safe-unsafe – это главная фича раста (безопасность), поэтому программирование на расте без safe сопоставимо с программированием на джаве как я описал чуть выше.
                                              Ответить
                                              • > А на джаве можно писать всё в одном классе Main, и будет процедурное программирование! А если ещё немного всякого кода дописать для иммутабельности, то и функциональное программирование будет. Но так обычно не делают.

                                                Значит ли это, что "BDSM-питушня" существует не в языке, а в голове программиста, который решил, что раз тут вот есть такая фича в языке, и раз тут так принято писать, то я буду писать так, как принято?
                                                Ответить
                                                • А как ты себе представляешь посещение BDSM вечеринки, где ты один не в латексе?

                                                  На самом деле тут всё проще. На уровне языка есть BDSM-питушня, некоторые программисты считают её крайне полезной, поэтому выбирают этот язык. Если ты будешь писать не так, как они, то твой код среди программистов на таком языке будет «говнокодом», и на тебя будут смотреть как на пыхера. Оно тебе надо?

                                                  Даже пословица есть: «в чужой монастырь со своим уставом не ходят».

                                                  Я не спорю, что на джаве можно писать как на питоне, а на крестах как на сишке, но зачем?
                                                  Ответить
                                                  • > На самом деле тут всё проще. На уровне языка есть BDSM-питушня, некоторые программисты считают её крайне полезной, поэтому выбирают этот язык. Если ты будешь писать не так, как они, то твой код среди программистов на таком языке будет «говнокодом», и на тебя будут смотреть как на пыхера.

                                                    Так это не языковая проблема, это проблема в том, кто на что как смотрит и кого кем считает в зависимости от того, кто как пишет какой-то код на каком-то там языке. Это не имеет значения в контексте сравнения свойств самого языка.
                                                    Ответить
                                                    • В таком случае можня считать, что C++ полностью эквивалентен C, потому что на C++ можня писать в точности как ня C (за исключением редких исключений, в особенности из новых сишных стандартов).
                                                      Ответить
                                                      • Да, надо еще поотрубать всякие там исключения и прочее рантайм-крестоговно с помошью флагов компилятора. И тогда будет почти как сишка, но с немного другими правилами в отношении type-punning через структуры и более строгими правилами касательно проверки типов, так что придется лишние касты писать.
                                                        Ответить
                                                      • Чего нельзя делать в крестах, но можно в сишке?
                                                        Неявно кастить void* и void main вроде, а еще что?

                                                        Чего там еще может не быть? _Generic? VLA?
                                                        Ответить
                                                        • В актуальном стандарте сишки правила type punning через union являются определенными, в крестах это ub.

                                                          В крестах правила с приведением типа с указателями другие. Например
                                                          char ch = 0;
                                                          unsigned char *ch_p = &ch;

                                                          нельзя в крестах, можно в Си. Для крестов надо указатель кастовать в нужный тип.
                                                          Ответить
                                                        • Если начать докапываться, отличий можно накопать. Например, в С11 есть <threads.h>, в крестах его не добавляли в стандарт, хотя наверное он будет работать, если его начать использовать

                                                          В си есть <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, но пользоваться можно.
                                                              Ответить
                                                              • >Там хедеры через какую-то срань конвертят же.

                                                                Ну вот видишь. А из крестов вызов сишного кода практически бесплатен
                                                                Ответить
                                                                • Из раста он тоже бесплатен, если речь про оверхед. А так да, для использования сишкокода из Rust конечно же придется поебаться побольше, чем если из крестов.
                                                                  Ответить
                                                                  • Я про использование конечно. Придется много ебстись, а это плохо.
                                                                    Ответить
                                                                    • > много ебстись

                                                                      Добавить шаг в билд-систему -- это не такая уж и ёбля... Тем более он там уже есть, скорее всего.
                                                                      Ответить
                                                                    • Для популярных и полезных библиотек на Си там уже за тебя поебались с биндингами. Например вот https://lib.rs/os/unix-apis
                                                                      Ответить
                                                                      • > поебались с биндингами

                                                                        Это как в той истории про чела, который десять тысяч функций для Х11 руками пилил, лишь бы сишную либу не цеплять?
                                                                        Ответить
                                                                      • Что-то есть, чего-то нет. Я беру сишку или кресты когда мне нужно трогать API операционки напрямую, и вот еще мне что-то генерить для этого


                                                                        Вот если бы я писал большой хай перформанс проект, то наверное имело бы смысл подумать про раст
                                                                        Ответить
                                                                        • > Я беру сишку или кресты когда мне нужно трогать API операционки напрямую, и вот еще мне что-то генерить для этого
                                                                          А мог бы брать https://docs.python.org/3/library/ctypes.html! Гляди, как круто:
                                                                          import ctypes
                                                                          ctypes.cdll.user32.MessageBoxW(0, "Hello World", "16", 0)
                                                                          Ответить
                                                                          • Хотелось бы стат типизации и отсутвтвия завязки на интерпретатор)
                                                                            Ответить
                                                                            • и структурирования отступами
                                                                              в индентно-ориентированном язычке
                                                                              Ответить
                                • > создатель одного языка был допустим негром
                                  огласите пожалуйста весь список woke-полных языков!
                                  Ответить
                                  • > woke-полных

                                    А кто такие Вуки?
                                    Ответить
                                    • не вуки, а воки

                                      лапша такая

                                      лапшевидный код в общем
                                      Ответить
                                    • Пробудившиеся

                                      Несколько лет назад они проснулись и поняли, что мир управляется белыми мужчинами-капиталистами, и нужно отнять у них власть, чтобы везде стало так же хорошо, как в тех странах, где нет ни белых, ни капиталистов. Ну, как в Африке
                                      Ответить
                                    • это свежее словечко в красном новоязе

                                      Not Woke Enough: Portland Antifa Attack Pro-Gay Church

                                      Antifa Rioters Attack Portland Church, Museum for 2nd Time in a Year
                                      Ответить
                    • ахахаха
                      https://habr.com/ru/post/492410/

                      а если без шуток: тебе нравица борроучекер?
                      Ответить
                      • > тебе нравица борроучекер

                        В текущем состоянии -- х.з., я не растишка чтобы его оценивать... А в целом -- это годная идея, которой очень не хватает в крестах когда работаешь со всякими итераторами и мувами. Возможно когда-нибудь его и в кресты завезут, хотя бы как выключенное по-умолчанию предупреждение.
                        Ответить
                      • > а если без шуток: тебе нравица борроучекер?

                        Если без шуток, можно писать всё в unsafe - будет как кресты. В чем-то типа борроучекере смысл определенно есть, но я б это делал через формальные доказывания хуйни, а не как в Rust.
                        Ответить
                      • > C++ быстрее и безопаснее Rust, Yandex сделала замеры

                        Это абсолютно желтушный заголовок, и статья кстати полное говно. Типа "Rust хуже C++ потому что хуевее оптимизируется на какой-то хуите", бля, ну охуеть теперь. А ничего что это не проблема языка как такового, а проблема компилятора? Давайте еще сишку с -O2 сравнивать с крестами с -O0 на древнем компиляторе, и кричать потом что вот си быстрее крестов.
                        Ответить
                      • Боровчекер лучше, чем ничего, но это ограниченная хрень, т.к. он автоматический, а автоматически можно проверить только малое подмножество не-Тьюринг полных программ. Поэтому я за separation logic с возможностью ручного доказательства. Вот это будет реально zero cost abstraction/memory safety.
                        Ответить
                    • Чем C++!
                      ☆*:.。.o(≧▽≦)o.。.:*☆
                      Ответить
                      • А вообще, Раст хуже своими cargo и crates.io.
                        Один раз попробуешь стандартизированную систему сборки и централизованный репозиторий — и всю оставшуюся жизнь от крестов с сишкой будет тошнить. Останется только переходить ня NodeJS и Python (>﹏<).
                        Ответить
                        • У сишки тоже такое есть. В любой unix-like ос. В почти любой.
                          Лучше всего конечно это сделано у BSD
                          Ответить
                          • Это — платформозависимая хер-ня, которая ещё и ня решает вопросы мультиверсионности зависимостей, няпример.
                            Ответить
                            • Почему меня должны ебать чужие платформы?
                              Ваш раст небось тоже под досом не работает

                              >ня решает вопросы мультиверсионности зависимостей,
                              А там сайд бай сайд, как в .net и winsxs?
                              Ответить
                              • Потому что "git clone && cargo build" — это легче, чем "git clone" и три часа возни с поиском нужных пакетов в твоём дистрибутиве.
                                Ответить
                                • не понял зачем мне возня. Если софт портирован под мою ОС, там там он сам все зависимости скачает

                                  https://www-legacy.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-depend.html
                                  Ответить
                                  • Из нядавнего: собирала фигню с boost-ом под x86, boost:i386 тянет вместе с собой python3:i386, python3:i386 принципиальня ня может стоять с python3:i686, единственный выход — собирать boost самой и самой же скармливать его системе сборки фигни.
                                    Ответить
                                    • Нахуя козе баян бусту питон? Чисто ради интеграции с boost::python?
                                      Ответить
                        • > А вообще, Раст хуже своими cargo и crates.io.
                          > Один раз попробуешь стандартизированную систему сборки и централизованный репозиторий — и всю оставшуюся жизнь от крестов с сишкой будет тошнить.

                          Раст хуже крестов потому что в расте есть удобная хрень для управления зависимостями, а в крестах нет? Эмм, че?

                          Какая-то альтернативная логика
                          Ответить
                          • Это был очень толстый сарказм. Разумеется, cargo и crates.io — очень удобные инструменты, которых очень ня хватает что в крестах, что в сишке.
                            Ответить
                            • Это уже не про язык, а про какие-то инфраструктурные хрени вокруг языка. И что-то там же есть уже в крестах, Conan какой-то.

                              В целом я считаю, что это должно быть межъязыковым, а не как сейчас. Если программа на 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-дерева, местным анялогам мейкфайлов даём возможность этим деревом маняпулировать!
                                        Ответить
                                        • (gcc (php 'prog-template.c.php' (perl 'gen-prog-template-parameters.pl') (gperf 'blah')) -o (get-artifact-path 'helloworld'))
                                          Ответить
                                • > пакетный менеджер юникс-подобной операционной системы
                                  Для сборки Foo нужня libbar-1.6, для сборки Baz — libbar-1.5. Удачи!
                                  Ответить
                                  • Поэтому я за portage, с таким-то слотами!
                                    Ответить
                                  • В операционной системе так быть не может.
                                    Там все зависимости не конфликтующие

                                    Именно в этом и смысл дистрибутива
                                    Ответить
                                    • Так думали где-то лет тридцать нязад. Потом пришёл DLL Hell, и так думать перестали.
                                      Ответить
                                      • DLL HELL ровно потому и случился на винде, что либы там ставили не из репозитория, а с компакт-диска, купленного в метро

                                        На большинстве **nix либы ставятся из репы, и хела там нет.

                                        Другой вопрос, что если ты на debian 8 захочешь Python 3.9, то пакетный менеджер разведет руками:)
                                        Ответить
                                        • > На большинстве **nix либы ставятся из репы, и хела там нет.
                                          Всё не нужно, чего нет. Если этого нет — то оно и не нужня.

                                          Если бы это было так — ня было бы ни docker, ни node_modules, ни virtualenv.
                                          Ответить
                                          • Докер нужен потому, что тебе могут понадобиться зависимости, которые система не предоставляет.

                                            Еще раз: хелла там нет. Но там вполне может не оказаться нужных тебе сущностей (см пример с python 3.9).
                                            Ответить
                                            • Никогда не натыкался на ситуации когда одна программа не запускается, потому что glibc слишком новый, а другая при этом — что слишком старый?
                                              Ответить
                                              • Нет, если эти программы поставлены из пакетного менеджера на стабильной версии ос
                                                Ответить
                                                • Да, все нужные программы всегда есть в пакетном менеджере. Включая софт для сбора данных с установки для титрования, созданной ещё до распада СССР.
                                                  Ответить
                                                  • охх..
                                                    Ну я же три раза уже написал:

                                                    >если ты на debian 8 захочешь Python 3.9, то пакетный менеджер разведет руками:)

                                                    > Но там вполне может не оказаться нужных тебе сущностей

                                                    >мало кому хочется ставить хедеры нужной библиотеки через пакетный менеджер ОС


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

                                                    Но утверждение "пакетные менеджеры не решают проблему DLL HELL" неверно.

                                                    Они её решают, но платой за это является возможность использовать только тот софт, который они предоставляют

                                                    Для кого-то это неприемлемо (для программистов, например)

                                                    Для кого-то вполне ок (админов обычно устраивает версия bash и samba из пакетного менеджера)
                                                    Ответить
                                                    • Изначальня речь шла о том, что "Для сборки Foo нужня libbar-1.6, для сборки Baz — libbar-1.5". Пакетные менеджеры эту проблему ня решают.
                                                      Ответить
                                                      • >Для сборки Foo нужня libbar-1.6, для сборки Baz — libbar-1.5"

                                                        Такая ситуация не может возникнуть в ОС, основанной на пакетных менеджерах: там будет либо Foo, либо Baz.

                                                        Например, тебе скажут так:

                                                        В версии 4.0 у нас есть Foo;
                                                        В версии 5.0 есть Baz
                                                        выбирай
                                                        Ответить
                                                        • В таком случае эта проблема и в Windows Store решена, вроде нужно запускаться на свежей версии системы чтобы быть там. Да и пиратский диск с программой эту проблему решает: всё будет работать, если не решишь поставить что-нибудь ещё. Такой пакетный менеджер с одним пакетом.

                                                          В общем виде хелл решается только хранением каждой версии библиотеки отдельно и возможности указания версий библиотек, если вдруг необходимо привязать программу к определённой версии (эдакий pif файл).

                                                          Пакетный менеджер это попытка частично решить проблему, которая работает только для каких то конкретных задач. Справедливости ради, эти задачи охватывают большую часть пользователей.
                                                          Ответить
                                                          • >эта проблема и в Windows Store решена,
                                                            Скорее всего да.

                                                            Кстати, в Windows есть SxS, которая эту проблему неплохо решает, как раз потому что
                                                            > хранением каждой версии библиотеки отдельно


                                                            >Справедливости ради, эти задачи охватывают большую часть пользователей

                                                            Угу. Для десктопа или небольшого офисного сервачка обычно хватает того, что есть в поставке.

                                                            А потом приходит программист, и хочет другую версию gcc, и конкретную версию postgres. И пиздец
                                                            Ответить
                                                            • Ну, зачастую это не программист, а здоровая дура, которую студент-автоматизатор за зачёт заставил пересылать данные по КОМ-порту, собирать статистику, инрать в блекджек и звонить шлюхам 25 лет назад. А так, как новая абсолютно такая же дура, но с ЮСБ, стоит 15 миллионов рублей и нанять нормального программиста тоже стоит денег, то "если не хочешь лишиться премии за некомпетентность, то это должно работать вчера"
                                                              Ответить
                                                              • Студенту нужно сказать, чтоб он сертифицировал конкретный дистр под свой софт

                                                                Люди иногда покупют RedHat потому, что у них есть софт, который официально поддерживает только RH

                                                                И там в пакетном менеджере есть всё, что софт использует.
                                                                Если там чего-то нет, то программист не имеет права это использовать.

                                                                понятное дело, что это крайне высокая цена, и её платят только в особых случаях
                                                                Ответить
                                                            • > Угу. Для десктопа или небольшого офисного сервачка обычно хватает того, что есть в поставке.
                                                              > А потом приходит программист, и хочет другую версию gcc, и конкретную версию postgres. И пиздец
                                                              А зачем в треде про системы сборки, которые в большинстве случаев нужны исключительня программистам, предлагать инструмент, для программистов ня подходящий?
                                                              Ответить
                                                              • Для программистов он на самом деле тоже подходит, если ты пишешь софт, который должен работать только с этой версией дистрибутива.

                                                                Допустим, ты пилишь софт для debian. Все зависимости ты опишешь в терминах пакетного менеджера
                                                                Ответить
                                                                • > софт, который должен работать только с этой версией дистрибутива
                                                                  Очень удобный инструмент.

                                                                  Правда, мода на софт, прибитый гвоздями к конкретной версии конкретной ОС, прошла где-то лет пятнадцать нязад. Или двадцать.
                                                                  Ответить
                                                                  • >Очень удобный инструмент.

                                                                    Он может иметь смысл только для debian. Например, это aptitude:)
                                                                    Ответить
                                                        • > Такая ситуация не может возникнуть в ОС, основанной на пакетных менеджерах: там будет либо Foo, либо Baz.
                                                          Причём тут вообще ОС? Я сама собираю Foo и Baz, из исходников.
                                                          Ответить
                                                          • > Я сама собираю Foo и Baz, из исходников.
                                                            Тогда ты не можешь использовать пакетный менеджер
                                                            Это же очевидно, нет?

                                                            Кстати, пакетный менеджер тоже появился не сразу: в классическом юниксе _весь_ софт вовсе ставился с системой.

                                                            Рудименты этого можно наблюдать в некоторых BSD, где есть четкая разница между "системным софтом" (base system) и внешними пакетами.

                                                            К примеру во FreeBSD с системой ставится sendmail. Если ты хочешь поставить postfix, то sendmail нужно отключить. Его нельзя удалить -- он часть системы
                                                            Ответить
                                                            • > Тогда ты не можешь использовать пакетный менеджер
                                                              С чего бы? Буквальня вчера я някатила виртуалку с Debian, поставила там через apt кучку libboost-nya-dev и спокойня собирала проект, зависящий от <boost>.

                                                              (Ироничня, кстати, что делала это я как раз для того, чтобы получить бинярник, который может работать ня одной виртуалке с древним gcc.)
                                                              Ответить
                                                              • Ты же понимаешь, что тебе просто повезло, что версия boost из репы тебя устроила?
                                                                Ответить
                                                                • Да. И имення поэтому стандартизированная ня уровне языка система сборки и разрешения зависимостей лучше, чем её отсутствие.

                                                                  Возвращая дискуссию в правильное русло: что мне нужня, чтобы собрать 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++ это — норма.

                                                                  Чувствуешь разницу?
                                                                  Ответить
                                                                  • Я не очень знаю Rust. Там не бывает педерастов, которым для сборки нужны perl, sed, awk и ruby?

                                                                    В С++ вполне бывает


                                                                    зы: Я собирал CEF на винде, я знаю, что такое в дебрях .bat файла исправлять пути к виндовым SDK и cl, так что боль я понимаю примерно
                                                                    Ответить
                                                                    • Няверняка везде бывают, но дело всё таки в их количестве.

                                                                      > в дебрях .bat файла исправлять пути к виндовым SDK и cl
                                                                      (。╯︵╰。)
                                                                      Ответить
                                                                      • Вероятно было бы хорошо иметь систему сборки со встроенным языком (lua там и ли python), чтобы мамкины автоматизаторы не .bat файлы писали, и не зависели бы от perl, а использовали бы чисто средства сборки

                                                                        Вот как жавист со своим gradle пишет всё на groovy
                                                                        Ответить
                                                                        • > Вероятно было бы хорошо иметь систему сборки со встроенным языком (lua там и ли python)

                                                                          Вот да, систему сборки для кода на Си можно написать на Си, чтобы там компилятор и линкер через fork()+execve() вызывался (или через system() чтоб). Один сборочный C-файл можно мейком, скомпилировать, запускать бинарник, и пусть он там сам дособирает всякую хрень.
                                                                          Ответить
                                                                          • Чем собрать систему сборки для С, написанную на С?
                                                                            Ответить
                                                                            • > Чем собрать систему сборки для С, написанную на С?

                                                                              Система сборки будет одним C-файлом который можно sh-скриптом или батником тупо собрать. А потом тот бинарник будет там что-то дальше питушить, возможно сам себя дособирать, т.е. собрать более мощную систему сборки чтоб уже всё окончательно собрать как надо.
                                                                              Ответить
                                                                          • А если ня моей системе нет ни fork(), ни execve() (•ิ_•ิ)?
                                                                            Ответить
                                                                            • >А если ня моей системе нет ни fork(), ни execve() (•ิ_•ิ)?

                                                                              Ну заюзаешь функцию system() на первых порах. Она в Си точно есть. А дальше базовая система сборки проанализирует доступные функции и что-то там сконфигурирует, использовать ли там виндовые аналоги fork()+execve() или есть нативный fork()+execve() и что там с многопоточной сборкой можно сделать.
                                                                              Ответить
                                                                          • Боюсь что make, fork() и execve() будут плохо работать на Windows
                                                                            Ответить
                                                                            • make-то будет, а вот в работе последних двух няблюдаются проблемы.
                                                                              Ответить
                                                                              • makа на винде нету, его туда придется отдельно ставить

                                                                                и я думаю (но это не точно) что gnumake не работает без цыгвин
                                                                                Ответить
                                                                                • > и я думаю (но это не точно) что gnumake не работает без цыгвин

                                                                                  В mingw отлично работает.
                                                                                  Ответить
                                                                                  • Ну вот видишь, придется ставить еще и их

                                                                                    А потом начнуится проблемы:
                                                                                    * на винде слеши другие
                                                                                    * разделители PATH другие
                                                                                    * кодировка не так работает
                                                                                    еще что-то...

                                                                                    Кросс-платформенную систему сборки сделать не баран чихнул
                                                                                    Ответить
                                                                                • На Debian, нясколько я помню, тоже.
                                                                                  Ответить
                                                                                  • На Debian по умолчанию нету никаких инструментов сборки, угу
                                                                                    Их надо ставить, но это намного проще, чем ставить мингвин на винде всётаки

                                                                                    А есть даже линукс без либси.. алпайн, или как его
                                                                                    Ответить
                                                                            • На замену make там тупого батника хватит, а fork() и execve() можно заменить на system() на первых порах.
                                                                              Ответить
                                                                              • >батника
                                                                                >проанализирует доступные функции и что-то там сконфигурируе
                                                                                ты же не пытаешься аутотутлз с поддержкой винды изобрести?
                                                                                Ответить
                                                                                • > ты же не пытаешься аутотутлз с поддержкой винды изобрести?

                                                                                  автотулз это ж скриптуха на каком-то перле(automake точно perl требует) и m4, а тут Царская Сишка и никакой скриптухи. Батником компилим один .c файл, запускаем его, дальше он там сам со всей хуйней ебется.
                                                                                  Ответить
                                                                                  • боюсь., что долго будет работать, если будет все тулы компилить с ноля

                                                                                    хотя если научить её качать готовое, то не страшно
                                                                                    Ответить
                                                • Имення в этом и смысл: всё не нужно, чего нет, чего нет — то не нужно. Используй только программы, заботливо подобранные мейнтейнерами дистрибутива, и радуйся.

                                                  Если нядо собрать какую-то другую программу, а оня с версиями либ из твоего дистрибутива ня совместима, то тебе не надо собирать эту программу. Опен-сорс же, free as in speech!
                                                  Ответить
                                                  • >Используй только программы, заботливо подобранные мейнтейнерами дистрибутива, и радуйся

                                                    Есть некоторые области, в которых это отлично работает.
                                                    Тащемто до середины 10-х годов это было повсеместно.

                                                    На шаред хостингах версия php и mysql зависела от версии дистрибутива, а не от желания программиста:)
                                                    Ответить
                              • > В целом я считаю, что это должно быть межъязыковым, а не как сейчас. Если программа на Rust требует для сборки либу на крестах которая требует либу на Haskell, притом либа на Haskell требует либу на Common Lisp

                                Stop it, Satan!
                                Ответить
                                • Если серьёзно, то обычно такий винегрет в один бинарь не линкуется, а как-то через RPC общается. А для этого и докер сгодится в качестве "универсального пакетного менеджера".
                                  Ответить
                              • Я думаю, что потенциальных создателей пакетного менеджера, который позволяет линковать зависимости на Rust, Haskell и Common Lisp, просто убивают во младенчестве пришельцы из будущего.

                                Индустрия уже и так не очень, но по крайней мере leftpad не был написан Common Lisp.
                                Ответить

    Добавить комментарий