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

    +1

    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
    #include <iostream>
    #include <tuple>
    using namespace std;
    
    template<typename T, typename T0, typename T1, typename ...Args>
    void PrintStruct(const tuple<T0 T::*, T1 T::*, Args T::*...>& members, const T& val)
    {
    	cout << val.*std::get<0>(members) << endl;
    	PrintStruct(members._Get_rest(), val);
    }
    
    template<typename T, typename T0>
    void PrintStruct(const tuple<T0 T::*>& members, const T& val)
    {
    	cout << val.*std::get<0>(members) << endl;
    }
    
    struct MyStruct
    {
    	int x;
    	float y;
    
    	static const tuple<decltype(&MyStruct::x), decltype(&MyStruct::y)> Members;
    };
    
    const tuple<int MyStruct::*, float MyStruct::*> MyStruct::Members = std::make_tuple(&MyStruct::x, &MyStruct::y);
    
    int main()
    {
    	MyStruct str = {123, 3.14159f};
    	PrintStruct(MyStruct::Members, str);
    	return 0;
    }

    Пытался понять, почему мой код не компилится в 2013 студии, и быстренько накатал этот минимальный пример. Но вышел облом - он почему-то компилится, в отличие от моей реальной либы со схожими шаблонными крестоконструкциями.

    Запостил: gammaker, 27 Июля 2016

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

    • потому что надо через раскрытие integer_sequence.

      Неудобно раскрытие вариадиков работает. И, ЕМНИП, кое-где неоднозначно и в 17-м исправят

      Но в 17-м можно околотривиально реализовать подобное через apply
      Ответить
      • Это как? Чем здесь integer_sequence поможет?
        Ответить
        • Какие планы на вечер? ;-)
          Ответить
        • https://www.murrayc.com/permalink/2015/12/05/modern-c-variadic-template-parameters-and-tuples/
          Глянь тут. Валидный с++11 код, т.е. студия 13-ого года ну прям обязана понимать
          Ответить
    • >Пытался понять, почему мой код не компилится в 2013 студии

      Потому что нехуй всякими анскильными несвежими говностудиями пользоваться и компилировать под поганый заедушный питушиндошс
      Ответить
      • Я пользуюсь 2015, в которой работает. Просто вроде слышал, что многие люди по некоторым причинам вынуждены использовать 2013 и старее. Например фирма не закупила лицензии новой студии. И я стараюсь обеспечить совместимость, чтобы они могли использовать мою библиотеку.
        Ответить
        • Бред собачий. Сам компилятор (а не их говноиде) у них бесплатен так что скомпилировать можно

          https://en.wikipedia.org/wiki/Microsoft_Visual_Studio_Express
          https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/6742251-make-c-c-compiler-cl-exe-independent-of-ide
          Ответить
          • Один человек дома установит 2015 Community и вряд ли у него будут какие-то проблемы. А я говорю про фирмы. Они же не будут все поголовно переходить на 2015 Express, имея лицензию на 2013. А на 2015 Community они переходить права не имеют, если фирма коммерческая и программистов там больше 5 человек.
            2013 студия вроде не умеет использовать компилятор от 2015-й. И, кстати, я заметил, что компилятор 2013-й студии выдаёт более компактные бинарники, чем 2015.
            Ответить
            • > 2013 студия вроде не умеет использовать компилятор от 2015-й.

              Это как вообще? Насколько я помню, к студии даже GCC прикручивать умеют. Да даже если так, из консоли скомпилировать у них мозгов разве не хватит?
              Ответить
              • https://msdn.microsoft.com/en-us/library/hefydhhy.aspx вот еще
                Ответить
              • Кто захочет к нормальной удобной среде прикручивать костыли типа ручной компиляции? Прикрутить можно что угодно, но нужно возиться и пользоваться этим будет неудобно. Тот intellisense будет колбасить от фич C++11\14\17, о которых он не знает. И если весь вопрос будет только в моей библиотеке, они её просто пошлют нафиг.
                Ответить
                • > Кто захочет к нормальной удобной среде

                  Спасибо, рассмешил. Я пробовал эту ссаную студию юзать - эмоции только негативные, и желание побыстрее эту парашу снести вместе с виндой. Оно еще SQL сервер зачем-то запускает, пиздец. Зачем редактору исходников нужен работающий в фоне SQL сервер? Они там часом не пизданулись? Говно ваша студия, просто говно. Говно, выжирающее кучу памяти, работающее только под уебанским виндовсом. Говно, которое индусы из майкрософта не могут толком портировать на 64-битную архитектуру, потому что когда они ваяли свое говно, они НЕ ДУМАЛИ о переносимости. Они серьезно считали, что процыки ВСЕГДА будут 32битными?

                  http://www.viva64.com/ru/k/0025/
                  https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-studio-why-is-there-no-64-bit-version-yet/


                  Хотя вроде есть какие-то подвижки
                  https://visualstudio.uservoice.com/forums/121579-visual-studio-2015/suggestions/2255687-make-vs-scalable-by-switching-to-64-bit?page=1&per_page=20
                  Ответить
                  • и чем же пользуется царь?
                    Ответить
                  • Всегда найдутся те, кому что-то не нравится. Ты видимо относишься к ним. А для меня Visual Studio - самая удобная IDE для C++. Ещё Eclipse CDT был неплох, но до студии всё-таки немного не дотягивает по удобству, хотя очень близок.

                    Мне тоже не нравится, что студия тянет за собой кучу всякого говна, ставящегося в систему, и весит десятки гигов. Но по поводу 64-битной версии вообще не обращал внимания. Всё работает, памяти жрёт всего 200 МБ - в 10-15 раз меньше лимита 32-битной программы. Падает очень редко и то в основном из-за плагинов. В общем, недостатки с лихвой покрываются удобством IDE, я считаю.

                    А ещё студийный компилятор компилирует в разы быстрее GCC\Clang, выдаёт более быстрый и компактный код.
                    Ответить
                    • студийный компилятор выдает выхлоп лучше gcc/clang? Вы, сударь, забыли зеленым выделить,вестимо
                      Ответить
                      • Тестил на своём синтезаторе midi. Откомпилированный студией, он синтезирует где-то на 15% быстрее (2,01 с против 2,35 с) и exe'шник весит на 20% меньше (55,5 КБ против 81 КБ), чем Clang. С GCC не проверял, потому что он не так просто прикручивается к студии, как Clang, а из командной строки компилировать лень.
                        Ответить
                        • Ты хоть с -O2 собирал?
                          Ответить
                          • Там толком не поймёшь. В студии стоит Максимальная скорость (/O2) и Предпочитать краткость кода (/Os). При компиляции clang'ом она вызывает clang-cl с этими параметрами, а во что он там транслируется, я не знаю. Предполагаю, что во что-то аналогичное как раз тому, что делает студийный компилятор с теми же параметрами.
                            Ответить
                        • > А ещё студийный компилятор компилирует в разы быстрее GCC\Clang, выдаёт более быстрый и компактный код.
                          >С GCC не проверял

                          Ясно
                          Ответить
                          • Ну я скорость программы, скомпилированной в GCC не мерил. А так я 3 года назад какое-то время сидел на Linux'е и там мой движок компилировался целиком 2 минуты, если память не изменяет. А в студии полная сборка сейчас занимает 16 секунд, хотя кода стало с тех пор почти в 2 раза больше.

                            Размер бинарника был близок, но побольше всё-таки.
                            Ответить
                            • > но побольше всё-таки
                              Ты же учёл, что в линухе по-дефолту дебаг инфа прямо в бинарнике, а в вижуалке - в отдельной PDB?
                              Ответить
                              • Естественно. Я вообще перерыл все рекомендации по уменьшению бинарника. И оптимизация под минимальный размер, и упрощённая математика, LTO, strip всей дебажной информации. И ещё куча всяких ключей было, которые уменьшали размер и про которые я уже забыл.
                                Ответить
                            • А ты в несколько потоков компилировал, или в один?
                              Ответить
                              • В студии с ключом /MP 16 секунд, без него - 30 секунд, хотя ядра 4, да ещё и гиперпоточность есть. В линуксе не помню, а я через Eclipse всё делал, был ли там какой-то ключик многопоточной компиляции или нет. Но даже если сравнивать с 30 секундами, всё равно разница на порядок.
                                Ответить
                                • > ... 3 года назад ... мой движок компилировался целиком 2 минуты ... был ли там какой-то ключик

                                  Это самое непредвзятое мнение из всего что я когда-либо читал!
                                  Ответить
                                  • Ну он же не специально писал свой движок для того, чтобы он в студии компилировался быстрее. Поэтому да, жизненный опыт, уникальный пример вместо надуманных тестов заинтересованных производителей компиляторов.
                                    Ответить
                                    • ну я просто беру в пример большой опенсорсный проект - Qt (5.5). На gcc 4.8 на моей машине он компилируется минут 45 вместо почти часа студийным. Включая -j4 получаем 15-20 минут (ох как я одно время молился на этот ключик).

                                      С учетом того что gcc 4.8 малех постарше 15-й студии
                                      Ответить
                                      • показать все, что скрытоА Вам не приходило в голову что Qt могли подтачивать под gcc? И что 90% случаев использования Qt собирают gcc а не vc?
                                        Ответить
                                        • а откуда цифра 90%?
                                          Ответить
                                        • > А Вам не приходило в голову что Qt могли подтачивать под gcc?
                                          Это что, какие-то особые прагмы, игнорируемые msvc, но от которых gcc включает фазу берсерка и распараллеливает компиляцию на видеокарту, аудиочип и контроллеры мышки и клавиатуры?

                                          > И что 90% случаев использования Qt собирают gcc а не vc?
                                          Я своих коллег приучаю хотя бы время от времени пересобираться в mingw с -Wприебаться-к-мелочам и пижу шваброй за ворнинги. Говорят, некоторые ошибки нашли таким образом.
                                          Ответить
                                          • > -Wприебаться-к-мелочам
                                            А в студии какой уровень ворнингов включен, кстати? Так то последние версии тоже неплохо приябываются к мелочам, и даже на свои хедера не ругаются...
                                            Ответить
                                            • > А в студии какой уровень ворнингов включен, кстати?
                                              В самой студии - вроде бы, дефолтный второй из четырех, в Qt mkspec схожие настройки.
                                              Ну, кстати, да, я давно не работал с вижуальным компилятором. Может, он и правда стал лучше.
                                              Ответить
                                              • В студии по дефолту /W3, но я ставлю /W4. Ещё есть /Wall, но он ругается на всё подряд, даже на хидеры.
                                                Ответить
                                          • > пижу шваброй за ворнинги

                                            Учитывая, что относительно недавно ГЦЦ имело привычку ругаться на отсутствие return после свича, учитывающего все варианты (control reached end of non-void function), а если этот return поставить, то ругалось на unreachble code; это напоминает анекдот про «Ты почему без шапки?»
                                            Ответить
                            • "А так я 3 года назад какое-то время сидел на Linux'е и там мой движок компилировался целиком 2 минуты, если память не изменяет. А в студии полная сборка сейчас занимает 16 секунд, хотя кода стало с тех пор почти в 2 раза больше."

                              если С++, то это может быть эффект PCH, которыми на линухе почти никто не пользуется.
                              Ответить
                              • Ну он по идее тоже должен пересобираться при полной пересборке проекта, разве нет? Что если какой-то заголовок изменился? Я же не кладу стандартные заголовки в pch, потому что у меня всё своё, и оно иногда меняется.
                                Ответить
                                • пересборка PCH тоже может быть делается при полном билде - но сборка всего остального с PCH происходит намного быстрее.

                                  на С++ коде, львиная доля времени компиляции тратится на парсинг STL/etc. PCH помогают этого избегать.
                                  Ответить
                                  • Но я не использую STL. А всякие WinAPI, stdio и другие стандартные хидеры у меня инклюдятся только в cpp файлах, которые их используют, то есть в мои заголовки не попадают вообще.
                                    Ответить
                                  • наверно не на парсинг, а на инстанацию шаблонов
                                    хотя вообще хрен его знает как оно сделано, скорее всего и парсит один файл по нескольку раз, инклюды вроде же тупо "сшиваются" вместе с цппшником при его сборке
                                    Ответить
                                    • > наверно не на парсинг, а на инстанацию шаблонов

                                      не замечал. моё старое (и все еще валидное наблюдение) что скорость компиляции простого С++ кода зависит от количества STL инклюдов: больше инклюдов, медленее. (и тут тоже есть логика: мегабайты текста С кода обрабатываются, из которых получается только 10-100К объектного кода. вход компилятора на порядок больше чем выхлоп.)

                                      плюс, наблюдение которое я сделал с GCC (я думаю что зависит больше от версии STL) это то что С++11 компилируется медленее чем C++98.

                                      количество инстанций шаблонов больше влияет только на скорость оптимизации - и это самое тормозное на билде релиза. а обычному дебаг билду это скорее всего не настолько критично.
                                      Ответить
                                      • STL по скорости компиляции - это, пожалуй, нет и 5% от проекта, где есть буст (и я сейчас не про спирит)

                                        только pch и параллельная сборка

                                        > количество инстанций шаблонов больше влияет только на скорость оптимизации
                                        когда давно я собирал свой проект со спиритом и компилятор MSVC (2010 вроде) упирался в 3+ГБ памяти и падал - пришлось сделать "форвард декларацию" этих 100-этажных шаблонов, вынеся инстанциирование в отдельные cpp (звучит дико да), чтобы он уже конкретные инстансы подцеплял на этапе линковки
                                        Ответить
                                        • > компилятор упирался в 3+ГБ памяти

                                          32битопроблемы.
                                          Ответить
                                          • даешь свободу коконпеляторам! 32 гигабайта хватит всем!
                                            Ответить
                                        • >когда давно я собирал свой проект со спиритом и компилятор MSVC (2010 вроде) упирался в 3+ГБ памяти и падал - пришлось сделать "форвард декларацию" этих 100-этажных шаблонов, вынеся инстанциирование в отдельные cpp (звучит дико да)


                                          Нет, ну всё-таки кресты днище. Отрадно что фф переписали на питуха.
                                          Раньше там то ли 5, то ли 7 гиг нужно было чтоб просто собрать ЭТО.
                                          Ответить
                    • Вообще, судя по этим тестам, Clang уделывает студийный компилятор в скорости http://insights.dice.com/2013/11/26/speed-test-2-comparing-c-compilers-on-windows/
                      Ответить
                    • > выдаёт более быстрый и компактный код.

                      вот чет я сомневаюсь на счет более быстрый, например не умеет инлайнить функции возвращающие временный объект (хотя самый свежий не смотрел, но думаю все так же)
                      Ответить
                  • > Они серьезно считали, что процыки ВСЕГДА будут 32битными?
                    Я прямо сейчас думаю, что процыки всегда будут 64битными, базарю. Ну может и не думаю, но о возможных архитектурах большей разрядности даже не вспоминаю, когда код пишу.
                    Ответить
                    • > Я прямо сейчас думаю, что процыки всегда будут 64битными, базарю.

                      Пойди-ка ты под атмеги попрограммируй на ассемблере, мыслитель. Когда пишешь некую хуйню на неассемблере, и не надо мегаоптимизаций и уберреалтаймовости когда четко каждый байтик экономишь(как в истории одного байта), от битности процессора желательно абстрагироваться, и писать код таким образом, чтобы он от этой самой битности НЕ ЗАВИСЕЛ и работал НА ЛЮБОЙ БИТНОСТИ
                      Ответить
                      • показать все, что скрытоКакая связь между атмегами и студией?

                        > от битности процессора желательно абстрагироваться, и писать код таким образом, чтобы он от этой самой битности НЕ ЗАВИСЕЛ и работал НА ЛЮБОЙ БИТНОСТИ

                        От всего не абстрагируешься. Да и не нужно это.
                        Я в своем коде специально на amd64 и не закладываюсь - вполне возможно, что он без проблем заработает на гепотетическом x86-128. Ну а может и не заработает, я этого не знаю и задумываться над этим не хочу, потому что такой архитектуры не существует.
                        Ответить
                        • показать все, что скрытоох, булщитеры вы оба.

                          >>>и писать код таким образом, чтобы он от этой самой битности НЕ ЗАВИСЕЛ и работал НА ЛЮБОЙ БИТНОСТИ

                          а! Лучше быть богатым и здоровым, чем бедным и больным. Лучше писать код без багов, чем код с багами. Хорошо совершать хорошие поступки, а плохие поступки совершать плохо.

                          Спасибо что ты рассказал мне что в коде на С++ лучше на закладываться на разрядность. Я то-то все думал: нужно закладываться или не нужно? Оказалось что не нужно.

                          >>От всего не абстрагируешься.
                          Где не абстрагируешься? От чего -- от всего? В чем? Если я пишу игру змейку могу я абстрагироваться от разницы между ivy bridge и haswell?

                          У меня есть аппликуха под ios на ObjC, она работает и на 64 и на 32. Что я делаю не так?
                          Ответить
                          • показать все, что скрыто> Я в своем коде специально на amd64 и не закладываюсь - вполне возможно, что он без проблем заработает на гепотетическом x86-128

                            Чувствуешь разницу между "старался не говнокодить и ура, получилось портабельно" и "специально обеспечивать поддержку x86, amd64 и несуществующей x86-128"? Первое - это правила хорошего тона, доброе намерение, не накладывающее обязательств. Второе - это целенаправленное действие, в идеале, включающее тестирование на всех целевых архитектурах.
                            Ответить
                          • >Спасибо что ты рассказал мне что в коде на С++ лучше на закладываться на разрядность. Я то-то все думал: нужно закладываться или не нужно? Оказалось что не нужно.

                            Ну вот разрабы говновизуальной студии почему-то на разрядность не закладывались, и теперь не могут свое говно портануть под 64 бит.
                            Ответить
                            • > Ну вот разрабы говновизуальной студии почему-то на разрядность не закладывались

                              Имеется ввиду, что они судя по всему не думали, что могут быть какие-то там еще разрядности, на которые их говно надо будет портануть
                              Ответить
                        • > Какая связь между атмегами и студией?

                          Связь не со студией и атмегами. Связь в том, что под какие-нибудь атмеги еще имеет смысл ебстись с байтиками и узкозатачивать код под битность конкретной архитектуры, заниматься всяким битоебством и прочими извращениями, можно даже хуярить ассемблерные вставки потому что GCC говно под AVR компилирует. А когда пишешь хуйню вроде IDE, желательно писать этот код таким образом, чтобы он да сколь-угодно-битной хуйне работал, например используя int8_t, uint8_t, int16_t, uint16_t и далее по списку, а не дефолтные int, long, short потому что хуй знает какой там размер у этой хуйни будет. Например, на каком-то говне у тебя unsigned int 32-битный, и у тебя там что-то с чем-то умножается, и ты пишешь свой код исходя из предположения, что если что-то там умножается и получается число, не влазящее в 32 бита, то эти битики прогондониваются. А потом появляется говноархитектура, где int уже 64-битный, и твоя хуйня не работает.
                          Ответить
                          • тип фиксированной длины нужен когда нужна фиксированная ширина поля! (парсинг какой-нить)

                            Там, где фиксированная ширина необязательна, берешь и пишешь (u)int_fast32_t .
                            Ответить
                            • показать все, что скрытоНу вот пишешь ты (u)int_fast32_t, а сам рассчитываешь, что он после 32 бит переполнится и пойдет с нуля. и совпадет с какой-то там маской. А потом раз, и будущее, и он 64 бита и не переполняется, все тесты красным ничего не работает. Поэтому либо фиксированная ширина намного шире парсинга, либо надо вообще на переполнение не рассчитывать.
                              Ответить
                              • > Там, где фиксированная ширина необязательна

                                > рассчитываешь, что он после 32 бит переполнится

                                /0
                                Ответить
                    • показать все, что скрытоМногие до середины 90х думали что процы бывают только 16ти битными
                      Ответить
              • > рабы ide
                > конпелировать в консоли
                > cmd.exe вместо шелла
                > виндовс
                Ответить
                • >> рабы ide
                  >> конпелировать в консоли

                  а чем же тогда компилировать, vim-ом? Или может через emacs? (или emacs это уже ide?)
                  Ответить
        • А заниматься подстраиванием своего говнокода под баги несвежих компиляторов это тот еще идиотизм
          Ответить
          • Этим идиотизмом приходится заниматься авторам всех библиотек, которые они хотят сделать популярными, либо которые популярны уже. Например тот же Boost указывает, какими компиляторами какой код поддерживается, содержит код обхода багов и другие вещи вплоть до самых древних студий.
            Я же выбрал компромиссный вариант - 2013 студия и выше. Её ещё много где можно встретить, поддерживать её несложно, потому что не так уж много важных для моего кода вещей C++11\C++14 появилось в 2015. А вот поддержка 2012 очень проблематична и требует переписывания кучи кода, поэтому я остановился на 2013.
            Ответить
          • Все этим занимаются, особенно опенсорц. У тебя что не тезис, то пук в лужу.
            Ответить
            • опер сорс страдает этим меньше чем коммерческий софт. потому что коммерческое Г приходится иногда 5-10-15 лет поддерживать.

              а на нишевых платформах (типа Solaris/Sparc, HP-UX/Itanic & AIX/Power) там вообще мрак. с одной стороны всегда можно собрать свежий GCC. с другой стороны, устаревший коммерческий компилер для нишевой платформы легко обгоняет GCC, каким бы свежим он не был: никто в GCC оптимизацией этих нишевых платформ сильно не занимается. и как раз эти нишевые платформы и существуют потому что они предлагают (и выполняют) контракты поддрежки 10+ лет.

              у меня знакомый на 10+ летнем Сан серваке винт менял. у нормального совкового чудака был просто культурный шок: позвонил в Сан, ему сказали что сложно потому что ооочень старое железо, но они посмотрят - через неделю позвонили назад, сказали что еще три винта на складе есть, и один из них уже ему послали. и в ж его не послали, и еще сами перезвонили и сами же запчасть послали - по гарантии 10-летнее давности.
              Ответить
              • А какой смысл брать под несвежий Сан несвежий винт, устаревший на 10 лет от актуальных на сегодняшний момент моделей, доступных на PC? У них же там наверняка интерфейс SCSI используется и взять "неродной" SCSI винт не проблема вообще
                Ответить
                • на старых системах там были еще предшественники SCSI. (и серваки тех времен IDE в принципе не использовали.)

                  с другой стороны, если у тебя есть контракт поддержки, то вставлять можно только железо, которое тебе поддрежка посылает (или даже ихний инженер приходит и заменяет).

                  в случае винтов, у большинства больших фирм 24 часа гарантия что они тебе новый винт пришлют. и часто посылают сразу с пару другую - на всякий пожарный. (у HP-UX есть даже специальный демончик который (если подцепить) автоматом суппорт оповещает, и они уже когда ты еще может спишь уже начинают что-то делать.)

                  те у кого большие дата центры, там вообще смешно: у них буквально подписка, по которой они каждую неделю получают новые винты, потому что статистичски каждую неделю, из 1000+ винтов, какие-то сыпятся.
                  Ответить
              • А когда пишешь хуйню вроде IDE, желательно писать этот код таким образом, просто обосраться, чтобы он от этой самой битности не зависел и работал на любой битности от всего не абстрагируешься к ебеням. Что я делаю не так, ебись оно все раком, сказали что еще три винта на складе есть до пизды, и один из них уже ему послали. И в ж его не послали в пизду, и еще сами перезвонили и сами же запчасть послали - по гарантии 10-летнее давности на хуй. А какой смысл брать под несвежий сан несвежий винт в жопу, устаревший на 10 лет от актуальных на сегодняшний момент моделей, доступных на pc. Студия 13-ого года ну прям обязана понимать пытался понять, блядь, почему мой код не компилится в 2013 студии потому что нехуй всякими анскильными несвежими говностудиями пользоваться и компилировать под поганый заедушный питушиндошс я пользуюсь 2015, в которой работает.Но даже если сравнивать с 30 секундами, сучье вымя, все равно разница на порядок.... 3 года назад, еби мать... Мой движок компилировался целиком 2 минуты блядь... Был ли там какой-то ключик многопоточной компиляции или нет. Размер бинарника был близок, но побольше все-таки, сукины дети. Но побольше все-таки ты же учел, блядская параша, что в линухе по-дефолту дебаг инфа прямо в бинарнике, сучье вымя, а в вижуалке - в отдельной pdb? Естественно, бля буду. Я вообще перерыл все рекомендации по уменьшению бинарника. И оптимизация под минимальный размер, и упрощенная математика, дерьмо собачье, lto, strip всей дебажной информации. И еще куча всяких ключей было, которые уменьшали размер и про которые я уже забыл. А ты в несколько потоков компилировал, или в один, ебанный карась? В общем, блядь, недостатки с лихвой покрываются удобством ide, я считаю, ебать мои мозги, как говорят французы, чтобы он от этой самой битности не зависел и работал на любой битности какая связь между атмегами и студией?#вореции
                Ответить
            • > Все этим занимаются, особенно опенсорц.

              Я не занимаюсь. Так что не все этим занимаются. Шах и мат.

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

                > Наверное это в основном проблема говноплюсов

                Верно. Плюсы настолько сложные, что даже в свежих шланге и гцц есть баги, которые приходится обходить. Чего уж говорить о бедных опенсорсных библиотеках, которым неплохо бы поддерживать дефолтный гцц из позапрошлого лтс убанты.
                Ответить
    • Я обычно подобные вещи делаю как-то так:
      struct MyStruct {
          int x;
          float y;
      
          template <class Visitor>
          void visit(Visitor& v) const { v(x)(y); }
      };
      Тут ничего кроме C++98 не нужно.
      Ответить
      • Интересная идея. Надо будет так попробовать.

        Я раньше слышал про эту идею и критиковал её, а сейчас подумал, вроде все недостатки, которые я там нашёл, можно устранить, если развить эту идею дальше.
        Ответить
      • > v(x)(y);

        Это что блядь за частичное применение?

        Показал бы код визитора (вангую return *this в () )
        Ответить
      • В общем, переделал на visitor, спасибо. Теперь проект компилится под 2013, да ещё и кучу шаблонной магии убрал вместе с указателями на члены.
        Ответить
    • Что это за лавина минусов тут прошлась?
      Ответить
    • показать все, что скрытоТест
      #collapse_me

      Кстати, комменты разворачиваются? Эх. Долго. Наверно бот занят.
      Ответить
    • показать все, что скрытоОпять пидар сайт шатает. Только что 502 было.
      #collapse_me
      Ответить
      • когда посты будешь поднимать, а не только комменты?
        Ответить
        • Как только страйко назначит меня патриархом всея ГК Боюсь, что никогда )
          Ответить
      • void_main

        давайте помянем его
        Ответить

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