Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Пытался понять, почему мой код не компилится в 2013 студии, и быстренько накатал этот минимальный пример. Но вышел облом - он почему-то компилится, в отличие от моей реальной либы со схожими шаблонными крестоконструкциями.
Я пользуюсь 2015, в которой работает. Просто вроде слышал, что многие люди по некоторым причинам вынуждены использовать 2013 и старее. Например фирма не закупила лицензии новой студии. И я стараюсь обеспечить совместимость, чтобы они могли использовать мою библиотеку.
Один человек дома установит 2015 Community и вряд ли у него будут какие-то проблемы. А я говорю про фирмы. Они же не будут все поголовно переходить на 2015 Express, имея лицензию на 2013. А на 2015 Community они переходить права не имеют, если фирма коммерческая и программистов там больше 5 человек.
2013 студия вроде не умеет использовать компилятор от 2015-й. И, кстати, я заметил, что компилятор 2013-й студии выдаёт более компактные бинарники, чем 2015.
Кто захочет к нормальной удобной среде прикручивать костыли типа ручной компиляции? Прикрутить можно что угодно, но нужно возиться и пользоваться этим будет неудобно. Тот intellisense будет колбасить от фич C++11\14\17, о которых он не знает. И если весь вопрос будет только в моей библиотеке, они её просто пошлют нафиг.
Спасибо, рассмешил. Я пробовал эту ссаную студию юзать - эмоции только негативные, и желание побыстрее эту парашу снести вместе с виндой. Оно еще SQL сервер зачем-то запускает, пиздец. Зачем редактору исходников нужен работающий в фоне SQL сервер? Они там часом не пизданулись? Говно ваша студия, просто говно. Говно, выжирающее кучу памяти, работающее только под уебанским виндовсом. Говно, которое индусы из майкрософта не могут толком портировать на 64-битную архитектуру, потому что когда они ваяли свое говно, они НЕ ДУМАЛИ о переносимости. Они серьезно считали, что процыки ВСЕГДА будут 32битными?
Всегда найдутся те, кому что-то не нравится. Ты видимо относишься к ним. А для меня Visual Studio - самая удобная IDE для C++. Ещё Eclipse CDT был неплох, но до студии всё-таки немного не дотягивает по удобству, хотя очень близок.
Мне тоже не нравится, что студия тянет за собой кучу всякого говна, ставящегося в систему, и весит десятки гигов. Но по поводу 64-битной версии вообще не обращал внимания. Всё работает, памяти жрёт всего 200 МБ - в 10-15 раз меньше лимита 32-битной программы. Падает очень редко и то в основном из-за плагинов. В общем, недостатки с лихвой покрываются удобством IDE, я считаю.
А ещё студийный компилятор компилирует в разы быстрее GCC\Clang, выдаёт более быстрый и компактный код.
Тестил на своём синтезаторе midi. Откомпилированный студией, он синтезирует где-то на 15% быстрее (2,01 с против 2,35 с) и exe'шник весит на 20% меньше (55,5 КБ против 81 КБ), чем Clang. С GCC не проверял, потому что он не так просто прикручивается к студии, как Clang, а из командной строки компилировать лень.
Там толком не поймёшь. В студии стоит Максимальная скорость (/O2) и Предпочитать краткость кода (/Os). При компиляции clang'ом она вызывает clang-cl с этими параметрами, а во что он там транслируется, я не знаю. Предполагаю, что во что-то аналогичное как раз тому, что делает студийный компилятор с теми же параметрами.
Ну я скорость программы, скомпилированной в GCC не мерил. А так я 3 года назад какое-то время сидел на Linux'е и там мой движок компилировался целиком 2 минуты, если память не изменяет. А в студии полная сборка сейчас занимает 16 секунд, хотя кода стало с тех пор почти в 2 раза больше.
Размер бинарника был близок, но побольше всё-таки.
Естественно. Я вообще перерыл все рекомендации по уменьшению бинарника. И оптимизация под минимальный размер, и упрощённая математика, LTO, strip всей дебажной информации. И ещё куча всяких ключей было, которые уменьшали размер и про которые я уже забыл.
В студии с ключом /MP 16 секунд, без него - 30 секунд, хотя ядра 4, да ещё и гиперпоточность есть. В линуксе не помню, а я через Eclipse всё делал, был ли там какой-то ключик многопоточной компиляции или нет. Но даже если сравнивать с 30 секундами, всё равно разница на порядок.
Ну он же не специально писал свой движок для того, чтобы он в студии компилировался быстрее. Поэтому да, жизненный опыт, уникальный пример вместо надуманных тестов заинтересованных производителей компиляторов.
ну я просто беру в пример большой опенсорсный проект - Qt (5.5). На gcc 4.8 на моей машине он компилируется минут 45 вместо почти часа студийным. Включая -j4 получаем 15-20 минут (ох как я одно время молился на этот ключик).
С учетом того что gcc 4.8 малех постарше 15-й студии
> А Вам не приходило в голову что Qt могли подтачивать под gcc?
Это что, какие-то особые прагмы, игнорируемые msvc, но от которых gcc включает фазу берсерка и распараллеливает компиляцию на видеокарту, аудиочип и контроллеры мышки и клавиатуры?
> И что 90% случаев использования Qt собирают gcc а не vc?
Я своих коллег приучаю хотя бы время от времени пересобираться в mingw с -Wприебаться-к-мелочам и пижу шваброй за ворнинги. Говорят, некоторые ошибки нашли таким образом.
> -Wприебаться-к-мелочам
А в студии какой уровень ворнингов включен, кстати? Так то последние версии тоже неплохо приябываются к мелочам, и даже на свои хедера не ругаются...
> А в студии какой уровень ворнингов включен, кстати?
В самой студии - вроде бы, дефолтный второй из четырех, в Qt mkspec схожие настройки.
Ну, кстати, да, я давно не работал с вижуальным компилятором. Может, он и правда стал лучше.
Учитывая, что относительно недавно ГЦЦ имело привычку ругаться на отсутствие return после свича, учитывающего все варианты (control reached end of non-void function), а если этот return поставить, то ругалось на unreachble code; это напоминает анекдот про «Ты почему без шапки?»
"А так я 3 года назад какое-то время сидел на Linux'е и там мой движок компилировался целиком 2 минуты, если память не изменяет. А в студии полная сборка сейчас занимает 16 секунд, хотя кода стало с тех пор почти в 2 раза больше."
если С++, то это может быть эффект PCH, которыми на линухе почти никто не пользуется.
Ну он по идее тоже должен пересобираться при полной пересборке проекта, разве нет? Что если какой-то заголовок изменился? Я же не кладу стандартные заголовки в pch, потому что у меня всё своё, и оно иногда меняется.
Но я не использую STL. А всякие WinAPI, stdio и другие стандартные хидеры у меня инклюдятся только в cpp файлах, которые их используют, то есть в мои заголовки не попадают вообще.
наверно не на парсинг, а на инстанацию шаблонов
хотя вообще хрен его знает как оно сделано, скорее всего и парсит один файл по нескольку раз, инклюды вроде же тупо "сшиваются" вместе с цппшником при его сборке
не замечал. моё старое (и все еще валидное наблюдение) что скорость компиляции простого С++ кода зависит от количества STL инклюдов: больше инклюдов, медленее. (и тут тоже есть логика: мегабайты текста С кода обрабатываются, из которых получается только 10-100К объектного кода. вход компилятора на порядок больше чем выхлоп.)
плюс, наблюдение которое я сделал с GCC (я думаю что зависит больше от версии STL) это то что С++11 компилируется медленее чем C++98.
количество инстанций шаблонов больше влияет только на скорость оптимизации - и это самое тормозное на билде релиза. а обычному дебаг билду это скорее всего не настолько критично.
STL по скорости компиляции - это, пожалуй, нет и 5% от проекта, где есть буст (и я сейчас не про спирит)
только pch и параллельная сборка
> количество инстанций шаблонов больше влияет только на скорость оптимизации
когда давно я собирал свой проект со спиритом и компилятор MSVC (2010 вроде) упирался в 3+ГБ памяти и падал - пришлось сделать "форвард декларацию" этих 100-этажных шаблонов, вынеся инстанциирование в отдельные cpp (звучит дико да), чтобы он уже конкретные инстансы подцеплял на этапе линковки
>когда давно я собирал свой проект со спиритом и компилятор MSVC (2010 вроде) упирался в 3+ГБ памяти и падал - пришлось сделать "форвард декларацию" этих 100-этажных шаблонов, вынеся инстанциирование в отдельные cpp (звучит дико да)
Нет, ну всё-таки кресты днище. Отрадно что фф переписали на питуха.
Раньше там то ли 5, то ли 7 гиг нужно было чтоб просто собрать ЭТО.
вот чет я сомневаюсь на счет более быстрый, например не умеет инлайнить функции возвращающие временный объект (хотя самый свежий не смотрел, но думаю все так же)
> Они серьезно считали, что процыки ВСЕГДА будут 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, а сам рассчитываешь, что он после 32 бит переполнится и пойдет с нуля. и совпадет с какой-то там маской. А потом раз, и будущее, и он 64 бита и не переполняется, все тесты красным ничего не работает. Поэтому либо фиксированная ширина намного шире парсинга, либо надо вообще на переполнение не рассчитывать.
Этим идиотизмом приходится заниматься авторам всех библиотек, которые они хотят сделать популярными, либо которые популярны уже. Например тот же 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, я считаю, ебать мои мозги, как говорят французы, чтобы он от этой самой битности не зависел и работал на любой битности какая связь между атмегами и студией?#вореции
Конечно не занимаешься, я же говорил про профессиональную разработку ПО.
Ты поймал меня на гиперболе. Может кто-то и не занимается.
> Наверное это в основном проблема говноплюсов
Верно. Плюсы настолько сложные, что даже в свежих шланге и гцц есть баги, которые приходится обходить. Чего уж говорить о бедных опенсорсных библиотеках, которым неплохо бы поддерживать дефолтный гцц из позапрошлого лтс убанты.
Я раньше слышал про эту идею и критиковал её, а сейчас подумал, вроде все недостатки, которые я там нашёл, можно устранить, если развить эту идею дальше.
Неудобно раскрытие вариадиков работает. И, ЕМНИП, кое-где неоднозначно и в 17-м исправят
Но в 17-м можно околотривиально реализовать подобное через apply
Глянь тут. Валидный с++11 код, т.е. студия 13-ого года ну прям обязана понимать
Потому что нехуй всякими анскильными несвежими говностудиями пользоваться и компилировать под поганый заедушный питушиндошс
2013 студия вроде не умеет использовать компилятор от 2015-й. И, кстати, я заметил, что компилятор 2013-й студии выдаёт более компактные бинарники, чем 2015.
Это как вообще? Насколько я помню, к студии даже GCC прикручивать умеют. Да даже если так, из консоли скомпилировать у них мозгов разве не хватит?
Спасибо, рассмешил. Я пробовал эту ссаную студию юзать - эмоции только негативные, и желание побыстрее эту парашу снести вместе с виндой. Оно еще SQL сервер зачем-то запускает, пиздец. Зачем редактору исходников нужен работающий в фоне SQL сервер? Они там часом не пизданулись? Говно ваша студия, просто говно. Говно, выжирающее кучу памяти, работающее только под уебанским виндовсом. Говно, которое индусы из майкрософта не могут толком портировать на 64-битную архитектуру, потому что когда они ваяли свое говно, они НЕ ДУМАЛИ о переносимости. Они серьезно считали, что процыки ВСЕГДА будут 32битными?
Хотя вроде есть какие-то подвижки
Он использует одну кнопку с NAND.
Шутку с xxd оценил.
Мне тоже не нравится, что студия тянет за собой кучу всякого говна, ставящегося в систему, и весит десятки гигов. Но по поводу 64-битной версии вообще не обращал внимания. Всё работает, памяти жрёт всего 200 МБ - в 10-15 раз меньше лимита 32-битной программы. Падает очень редко и то в основном из-за плагинов. В общем, недостатки с лихвой покрываются удобством IDE, я считаю.
А ещё студийный компилятор компилирует в разы быстрее GCC\Clang, выдаёт более быстрый и компактный код.
максимальная скорость это вообще-то /Ox
>С GCC не проверял
Ясно
Размер бинарника был близок, но побольше всё-таки.
Ты же учёл, что в линухе по-дефолту дебаг инфа прямо в бинарнике, а в вижуалке - в отдельной PDB?
Это самое непредвзятое мнение из всего что я когда-либо читал!
С учетом того что gcc 4.8 малех постарше 15-й студии
Это что, какие-то особые прагмы, игнорируемые msvc, но от которых gcc включает фазу берсерка и распараллеливает компиляцию на видеокарту, аудиочип и контроллеры мышки и клавиатуры?
> И что 90% случаев использования Qt собирают gcc а не vc?
Я своих коллег приучаю хотя бы время от времени пересобираться в mingw с -Wприебаться-к-мелочам и пижу шваброй за ворнинги. Говорят, некоторые ошибки нашли таким образом.
А в студии какой уровень ворнингов включен, кстати? Так то последние версии тоже неплохо приябываются к мелочам, и даже на свои хедера не ругаются...
В самой студии - вроде бы, дефолтный второй из четырех, в Qt mkspec схожие настройки.
Ну, кстати, да, я давно не работал с вижуальным компилятором. Может, он и правда стал лучше.
Учитывая, что относительно недавно ГЦЦ имело привычку ругаться на отсутствие return после свича, учитывающего все варианты (control reached end of non-void function), а если этот return поставить, то ругалось на unreachble code; это напоминает анекдот про «Ты почему без шапки?»
если С++, то это может быть эффект PCH, которыми на линухе почти никто не пользуется.
на С++ коде, львиная доля времени компиляции тратится на парсинг STL/etc. PCH помогают этого избегать.
хотя вообще хрен его знает как оно сделано, скорее всего и парсит один файл по нескольку раз, инклюды вроде же тупо "сшиваются" вместе с цппшником при его сборке
не замечал. моё старое (и все еще валидное наблюдение) что скорость компиляции простого С++ кода зависит от количества STL инклюдов: больше инклюдов, медленее. (и тут тоже есть логика: мегабайты текста С кода обрабатываются, из которых получается только 10-100К объектного кода. вход компилятора на порядок больше чем выхлоп.)
плюс, наблюдение которое я сделал с GCC (я думаю что зависит больше от версии STL) это то что С++11 компилируется медленее чем C++98.
количество инстанций шаблонов больше влияет только на скорость оптимизации - и это самое тормозное на билде релиза. а обычному дебаг билду это скорее всего не настолько критично.
только pch и параллельная сборка
> количество инстанций шаблонов больше влияет только на скорость оптимизации
когда давно я собирал свой проект со спиритом и компилятор MSVC (2010 вроде) упирался в 3+ГБ памяти и падал - пришлось сделать "форвард декларацию" этих 100-этажных шаблонов, вынеся инстанциирование в отдельные cpp (звучит дико да), чтобы он уже конкретные инстансы подцеплял на этапе линковки
32битопроблемы.
Нет, ну всё-таки кресты днище. Отрадно что фф переписали на питуха.
Раньше там то ли 5, то ли 7 гиг нужно было чтоб просто собрать ЭТО.
вот чет я сомневаюсь на счет более быстрый, например не умеет инлайнить функции возвращающие временный объект (хотя самый свежий не смотрел, но думаю все так же)
Я прямо сейчас думаю, что процыки всегда будут 64битными, базарю. Ну может и не думаю, но о возможных архитектурах большей разрядности даже не вспоминаю, когда код пишу.
Пойди-ка ты под атмеги попрограммируй на ассемблере, мыслитель. Когда пишешь некую хуйню на неассемблере, и не надо мегаоптимизаций и уберреалтаймовости когда четко каждый байтик экономишь(как в истории одного байта), от битности процессора желательно абстрагироваться, и писать код таким образом, чтобы он от этой самой битности НЕ ЗАВИСЕЛ и работал НА ЛЮБОЙ БИТНОСТИ
> от битности процессора желательно абстрагироваться, и писать код таким образом, чтобы он от этой самой битности НЕ ЗАВИСЕЛ и работал НА ЛЮБОЙ БИТНОСТИ
От всего не абстрагируешься. Да и не нужно это.
Я в своем коде специально на amd64 и не закладываюсь - вполне возможно, что он без проблем заработает на гепотетическом x86-128. Ну а может и не заработает, я этого не знаю и задумываться над этим не хочу, потому что такой архитектуры не существует.
>>>и писать код таким образом, чтобы он от этой самой битности НЕ ЗАВИСЕЛ и работал НА ЛЮБОЙ БИТНОСТИ
а! Лучше быть богатым и здоровым, чем бедным и больным. Лучше писать код без багов, чем код с багами. Хорошо совершать хорошие поступки, а плохие поступки совершать плохо.
Спасибо что ты рассказал мне что в коде на С++ лучше на закладываться на разрядность. Я то-то все думал: нужно закладываться или не нужно? Оказалось что не нужно.
>>От всего не абстрагируешься.
Где не абстрагируешься? От чего -- от всего? В чем? Если я пишу игру змейку могу я абстрагироваться от разницы между ivy bridge и haswell?
У меня есть аппликуха под ios на ObjC, она работает и на 64 и на 32. Что я делаю не так?
Чувствуешь разницу между "старался не говнокодить и ура, получилось портабельно" и "специально обеспечивать поддержку 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 .
> рассчитываешь, что он после 32 бит переполнится
/0
>Зачем редактору исходников нужен работающий в фоне SQL сервер?
Оно автогенерит из базы dtoшки для C#.
И автокомплитит linq-to-sql.
> конпелировать в консоли
> cmd.exe вместо шелла
> виндовс
>> конпелировать в консоли
а чем же тогда компилировать, vim-ом? Или может через emacs? (или emacs это уже ide?)
Я же выбрал компромиссный вариант - 2013 студия и выше. Её ещё много где можно встретить, поддерживать её несложно, потому что не так уж много важных для моего кода вещей C++11\C++14 появилось в 2015. А вот поддержка 2012 очень проблематична и требует переписывания кучи кода, поэтому я остановился на 2013.
а на нишевых платформах (типа Solaris/Sparc, HP-UX/Itanic & AIX/Power) там вообще мрак. с одной стороны всегда можно собрать свежий GCC. с другой стороны, устаревший коммерческий компилер для нишевой платформы легко обгоняет GCC, каким бы свежим он не был: никто в GCC оптимизацией этих нишевых платформ сильно не занимается. и как раз эти нишевые платформы и существуют потому что они предлагают (и выполняют) контракты поддрежки 10+ лет.
у меня знакомый на 10+ летнем Сан серваке винт менял. у нормального совкового чудака был просто культурный шок: позвонил в Сан, ему сказали что сложно потому что ооочень старое железо, но они посмотрят - через неделю позвонили назад, сказали что еще три винта на складе есть, и один из них уже ему послали. и в ж его не послали, и еще сами перезвонили и сами же запчасть послали - по гарантии 10-летнее давности.
с другой стороны, если у тебя есть контракт поддержки, то вставлять можно только железо, которое тебе поддрежка посылает (или даже ихний инженер приходит и заменяет).
в случае винтов, у большинства больших фирм 24 часа гарантия что они тебе новый винт пришлют. и часто посылают сразу с пару другую - на всякий пожарный. (у HP-UX есть даже специальный демончик который (если подцепить) автоматом суппорт оповещает, и они уже когда ты еще может спишь уже начинают что-то делать.)
те у кого большие дата центры, там вообще смешно: у них буквально подписка, по которой они каждую неделю получают новые винты, потому что статистичски каждую неделю, из 1000+ винтов, какие-то сыпятся.
Я не занимаюсь. Так что не все этим занимаются. Шах и мат.
Наверное это в основном проблема говноплюсов, потому что туда всякую ебанутую хуйню затащили, которую хуй скомпилируешь. А я в основном Си использую
Ты поймал меня на гиперболе. Может кто-то и не занимается.
> Наверное это в основном проблема говноплюсов
Верно. Плюсы настолько сложные, что даже в свежих шланге и гцц есть баги, которые приходится обходить. Чего уж говорить о бедных опенсорсных библиотеках, которым неплохо бы поддерживать дефолтный гцц из позапрошлого лтс убанты.
Тут ничего кроме C++98 не нужно.
Я раньше слышал про эту идею и критиковал её, а сейчас подумал, вроде все недостатки, которые я там нашёл, можно устранить, если развить эту идею дальше.
Это что блядь за частичное применение?
Показал бы код визитора (вангую return *this в () )
Вот видишь, ты сам всё понял.
и через 30сек меня автоматически заминусует
#collapse_me
Кстати, комменты разворачиваются? Эх. Долго. Наверно бот занят.
#collapse_me
давайте помянем его