- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
#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 студии, и быстренько накатал этот минимальный пример. Но вышел облом - он почему-то компилится, в отличие от моей реальной либы со схожими шаблонными крестоконструкциями.
Follow us!
Неудобно раскрытие вариадиков работает. И, ЕМНИП, кое-где неоднозначно и в 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
давайте помянем его