Для наших целей, говоря об операциях ALU, мы будем рассматривать только операции типа регистр-регистр. Если задействована память, затраты могут быть ОЧЕНЬ разными — это будет зависеть от того, “насколько велик был промах кэша” при доступе к памяти, как описано ниже.
Нужно делать не так, а рассматривать именно операции для которых доступны аргументы. А то, что записало туда эти аргументы — это совершенно другая история.
В наши дни (и на современных процессорах), «простые» операции, такие как ADD/MOV/OR/..., могут легко выполняться быстрее одного такта ЦП.
Не могут. То, что указанно в табличке за 0.5 и менее — это не время выполнение операции, а просто ipc(для одних и тех же операций). Время же выполнения самое операции — написано с столбике «летенси».
оценивает стоимость 32/64-битного умножения (MUL/IMUL в мире x86/x64) в 1-7 тактов
Не оценивает.
на практике я наблюдал более узкий диапазон значений, например 3-6 тактов
Это уже похоже на правду — по ссылки минимальная летенси 3такта( по крайней мере меньше я не увидел).
Если использовать скалярные SSE-операции (которыми, по-видимому, пользуется “каждая собака” в наши дни),
Действительно, х87 ещё с core2 выкинули на помойку.
показатели уменьшаться до 0,5-5 тактов для умножения (MULSS/MULSD)
Не уменьшатся. Как я уже говорил — время выполнение одно и то же и написано в столбике «летенси».
оценивает целочисленное сложение над 128-битным вектором в < 1 такт
Нет. Проблема та же, что и выше.
Не такая очевидная вещь, связанная с затратами на вычисления, заключается в том, что переключение между целыми и плавающими инструкциями не бесплатно. [Agner3] оценивает эту стоимость (известную как «задержка перехода») в 0-3 такта в зависимости от процессора. На самом деле проблема более общая, и (в зависимости от ЦП) также могут быть штрафы за переключение между векторными (SSE) целочисленными инструкциями и обычными (скалярными) целочисленными инструкциями.
Вот именно, что «задержка» и на те 0.5 — она «никак» не повлияет.
Совет по оптимизации: в коде, для которого критична производительность, избегайте комбинирования вычислений с плавающей запятой и целыми числами.
Совет не имеет смысла. Всё зависит от того, что понимать под производительностью и в подавляющем большинстве случаев под нею понимается не то, на что влияют эти задержки.
если процессор правильно угадывает, куда будет направлено выполнение (это до фактического вычисления условия if), тогда стоимость перехода составляет около 1-2 тактов ЦП
Из этого мало что следует, т.к. процессор умеет спекулятивно исполнять угаданную ветку. В любом случае — измерение этого «наобум» имеет мало смысла, т.к. в одном случае это может быть ноль, а в другом далеко не ноль. И всё это в рамках угаданного перехода.
процессору не нужно ждать завершения записи перед тем, как идти вперед (вместо этого он только начинает писать — и сразу переходит к другим делам).
Не совсем верно. Это лишь «размазывает» по времени редкие записи. Не нужно ждать пока не переполнился буфер/кэш, а далее ждать нужно.
Это означает, что большую часть времени процессор может выполнять запись в 1 такт; это согласуется с моим опытом и, по-видимому, достаточно хорошо коррелирует с [Agner4].
Не может. Есть два кейса — пишешь в рамках ширины буфера/кеша/etc — получаешь ~трупут буфера/кеша/etc, а вот если не пишешь — не получаешь. Ничего другого нет и быть не может. Всё так же, как для чтения. Хотя есть нюансы и они не в пользу записи.
Разница между чтением и записью в том, что чтение всегда является зависимостью для следующей, а запись нет. И вся задержка идёт именно в чтение.
Так же как и для любого типа кэша, существует стоимость промаха TLB; для x64 она колеблется между 7-21 тактами ЦП [7cpu].
Не совсем верно, а вернее совсем неверно. Стоимость промаха кэша — это не оверхед самого кеша( Это та задержка, которая существует между получением данным и возвратам их кешом. Это задержка на запись данных с вам кеш + много организационных задержек( надо узнать в какое место писать и прочее)). И по ссылкам это именно оверхед кеша.
Но ещё одно и основной свойство промаха в том, что надо прочитать данные из предыдущего уровня памяти и это и есть основная задержка, которую все и понимают под ценой промаха. И она в ссылке не указана, а вернее указана ниже. И там уже далеко не 10тактов. Ну и к тому же, бывают не только минорные пейджфолты.
еще раз — улучшение общей локальности памяти помогает уменьшить промахи TLB; чем локальнее ваши данные, тем меньше шансов выйти из TLB.
Странная формулировка с общей локальностью. Из TLB можно либо выйти, либо не выйти — третьего не дано. А выйти( 1к * 4к страниц в дефолте) из него не составляет труда.
С другой стороны, по моему опыту, для функции с достаточно небольшим числом параметров это скорее будет 15-30 тактов
Из этого так же мало что следует.
В то время как переключение между уровнями процессора занимает всего около 100 тактов, другие связанные с этим накладные расходы, как правило, делают вызовы ядра намного более дорогими, поэтому обычный вызов ядра занимает не менее 1000-1500 тактов процессора
Мало коррелирует с реальность для того же Linux.
0 тактов означает, что MOV не имеет дополнительную стоимость, поскольку она выполняется параллельно с некоторыми другими операциями
Не совсем верно — mov попросту не существует по причине отсутствия самих регистров. А даже если бы существовало, то не параллельно, а вместе.
В принципе, стоимость возврата-и-проверки состоит из трех отдельных стоимостей.
Куда делась стоимость самой проверки?
Объединив все три стоимости, я бы оценил затраты на возврат-кода-ошибки-и-проверку (в нормальном случае) в пределах от 1 до 7 тактов ЦП.
От нуля.
Резюмируя, перед написанием подобных статей — надо для себя и аудитории определить базовые понятия. В частности, что такое latency/throughput, почему и откуда они взялись. И почему вообще ничего, без контекста, предсказать нельзя.
Это что такое? Где вообще пруфцы от вас? Почему я вижу только ссылки на хрен пойми что в интернете и пустые заявления?
Это, вообще говоря, сделано для безопасности — но ничто не мешает оптимизатору испольовать эту информацию и для чего-то ещё.
Меня мало интересуют абстрактные обсуждения и ссылки на то, что «может быть». Я вам привёл свои рассуждения, которые вы никак не опровергли и начали ехать в сторону каких-то левых, не относящихся к теме, вещей.
И в инлайн и в статическую функцию в C++ могут придти пара указателей — и всё.
Не могут. Единственная возможность — это экспортировать сразу несколько указателей из внешнего контекста, но это ненужно. И любой, кто претендует на хоть какую-то производительность — так делать не будет.
godbolt.org/g/V3KXCW — шлангу даже рестрикт не помог, а шансом 98% — это проблема в ллвм, в значит расту ничего не поможет.
Да, есть так нелюбимый вами __restrict__, но нет реальной культуры его применения.
Я уже сказал, что его нету. Культуры нет ни его применения, а написания производительного кода.
Где-то частица «не» пропущена. Ибо вы явно ненавидите rust, но берётесь о нём рассуждать не зная и не понимаю его. Типичное «Пастернака не читал, но осуждаю»…
Опять эти глупые попытки меня ловить. Меня мало волнуют ваши «явно» — я вижу ваш уровень, уровень раст-апологетов. Мне этого достаточно. Мнение о языка, о производительности тех, кто ничего в теме не понимает — меня волновать не должно.
А ненавижу я не раст, а рекламный булшит и балаболов.
И заметьте, я привёл чёткие причины моего недовольства — вы ответили что-то на них? Нет, вы всё неудобное вам игнорируете, занимаясь глупыми обвинениями. А чей-то трёп стоит ноль.
P.S. Я, кстати, не фанат rust'а.
Фанат. Без понимания чего-то лезть куда-то и что-то вещать — это типичная фанатичная глупость. Я где-то услышал какие-то лозунги — и пошел вещать об этом в комментах.
Достаточно посмотреть ваши подобные попытки, когда вы пытались вещать мне про ГЦ. Фанатизм во все поля, ссылки на левые хелворды, отсутствие ответов. А это первое, что я вспомнил. Подобных наших баталий помню больше одной, но мне лень их искать.
И я до сих пор не уверен, что в реальных проектах необходимость всё укладывать в «прокрустово ложе» borrow checker'а не приведёт к проблемам.
Это типичный пример кастылей, когда проблема не решается, а хайп нужен. Да и подобные рассуждения не имеют смысла — без bc потеряется основной лозунг, а кроме них ничего и нет.
Да что там далеко ходить, оно даже слайс на константную(времени компилтайма) строку borrow checker'ом ловит. Колхоз колхоза.
Но я, в отличие от вас, хотя бы понимаю — чего в этом языке люди пытаются добиться и зачем.
Нет, вы не понимаете. И в этом проблема. Вы лезете в тему производительности, в тему лоулевел и С/С++, в которых ничего не понимаете. Как и все остальные адепты.
Хотите делать свои супер-языки? Делайте, но не лезьте в эти темы и не рассказывайте мне о том, что ваш колхоз хоть как-то заменяет С/С++.
А для чего мозилла производит этот хайповый булшит? График популярности броузеров за последние года — вам должен дать ответ на этот вопрос.
Почему весь хабр заспамлен этим булшитом? Пример я уже приводил(а вы его проигнорировали. Хотя это типичное, для вас, поведение). Всё просто — халявные инвайты, халявные плюсы. Пиши любую ахинею в рамках «руст так же быстр» — получай халяву от фанатиков.
Перво наперво — нужно осилить понятие «контекст», а уже потом приходить со своими пожалуйста. Но я помогу, контекстом был синтаксис описания типов, а не синтаксис вообще. Тем более, половина тут вообще не касается синтаксиса.
Оператор «запятая». Зачем она вообще нужна? Я не могу представить случая, где она была бы полезна. А вот ограничения на синтаксис при этом накладываются довольно сильные.
Везде, особенно в однострочниках. Вон пару сообщений назад мне кто-то пастил крестовый код, и там именно запятая.
Оператор switch крайне непродуман.
Продуман. Это банальная логика третий класс. Есть семантика перехода, есть переходы в свиче. Переходы не ограничены ничем.
Переход управления из одной ветви в другую — ситуация, которая случается крайне редко.
Каждая вторая — подобная ситуация.
Ну и группировать несколько подряд идущих case в один, указывая условия через запятую.
Т.е. для тех ситуаций, которых две строчки назад «крайне редко»? Сильно.
Это итак работает. case: case: case: — сколько угодно.
Объявления типов с квалификаторами и слева, и справа — затруднение чтения кода.
Не объективно. Для меня затрудняет чтение обратное.
Я бы предпочёл, чтобы мухи (тип) и котлеты (объявление переменной) были отдельно
Это не критика. Меня мало должны волновать ваши предпочтения. Они так отдельно.
обе переменные будут должны тип int *
Как мне объявить int v, * p; в вашем супер-синтаксисе? Хотите ограничить типы — есть тайпдеф. Напишите там что угодно и это уже будет типов, а «составным типом».
Объявление массивов фиксированного размера: int[10] a, а не int a[10].
И? С каких пор «хочу» — стало критикой? [10] — это такое же свойство переменной. Хотите определить это на базе типа — есть тайпдефы.
Про указатели на функции: аналогично п. 3. хотелось бы видеть что-то типа:
Зачем нужно это «function» кастыльное непотребство? Мне не хотелось бы, дальше что?
Имена типов в виде крокодилов unsigned long long.
Есть тайпдефы, стандартизированные.
[C++] Неоднозначности между определением функции и инициализацией объекта, костыль в виде двух видов записи вызова конструктора — с обычными и фигурными скобками.
Нету никакой неоднозначности. Конструктор — это вызов функции. Другое дело, что на самом деле конструктор — инициализатор, а в си инициализатор {}. Поэтому всё вернулось на круги своя.
Угу, в C++ это костыль в виде auto
Это не костыль.
именно потому, что обявление без типа не предусмотрено синтаксисом.
Неверно. К синтаксису языка это не имеет никакого отношения — это фундаментальная неоднозначность между использованием и объявлением. И auto в С++ не кастыль, ведь синтаксис определения не изменяется. type var;, а вот в кастыльном var: type; — меняется, ведь нам нужно добавлять ненужность в виде let, как и ненужность в виде function/fn и прочего колхоза.
Особенно смешно выглядят лямбды:
Сишный синтаксис позволяет опускать типы, но в С++ как всегда — решили пойти своим путём.
[](auto x, auto y) { return x + y; }, когда можно было бы написать (x, y) -> x + y;
А как только нам нужно больше логики? И опять же, это примитивный сахар, а не синтаксис. Убогая стрелка, которая ничем не лучше скобок.
Почему вам «лишнее» слово тут «int function(int, int)» не мешает, а тут мешает? Вы уж там определитесь.
А теперь [&]{ x += 1;}. Синтаксис намного мощнее, нежели эти хелворды.
Тем более, этот синтаксис итак есть в крестах [](auto x, auto y) -> auto {}, только синтаксис крестов несоизмеримо мощней, нежели эти хелворды, которые вы пытаетесь выдать за синтаксис.
Вы попробуйте облечь в них все те возможности, что есть в крестах. В этом проблема всех «критиков», помимо основной «я хочу так — это критика», — «я пащу левый синтаксис, который просто не может в ту семантику, которая существует в рамках крестов».
Например вы можете получить две мутабельные ссылки и быть уверенным, что они указывают на разные объекты.
И? Во-первых это попытка выдать ограничение за фичу.
Во-вторых, алиаситься может не только мутабельное с мутабельным, а так же мутабельное с иммутабельным. Это подлог, либо явное непонимание темы.
Второе, разные объекты ничего не значат. Ссылка на элемент массива и сам массив — являются разными объектами, но они алиасятся. Ссылка на поле и структура — так же. Я сомневаюсь, что нельзя взять ссылку на на поле, либо на елемент и что это идёт в счёт той самой «только одной» ссылки.
Классический случай pointer aliasing'а.
Для разных типов это итак не работает.
В плюсах есть костыль в виде__restrict__
В плюсах нету рестрикта, он есть в си. Хотя раст не имеет никакого отношения к унификации и стандартизации, поэтому мы можем брать любую фишку любого компилятора и приписывать её к С/С++.
но компилятор никак не проверяет это, все на совести разработчика.
Продолжим, как вы ответите на мои вопросы. Но в любом случае — это невозможно.
Раст же не заставляет выбирать между производительностью и корректностью.
Это не производительность, даже близко. Люди, которые ничего о ней не знают — очень любят раст и порассуждать.
Пруфы? Пожалуйста — начало ветки. У автора ансейф через ансейф. Где же мистическая «производительность без выбора»? Как только автор предоставит код — можно будет посмотреть, что именно там намерено и как. Уже потом можно будет и исходный крестовый код посмотреть. Пока что — тут рассуждать не о чём.
Ещё пруфы? Пожалуйста, «предыдущая» тема про раст, которая касалась сравнения раста и С++. 72 плюса, 7 минусов и ноль сообщений о том, что это убогая клоунада, а не сравнение. Множество восторженных сообщений. Как вы это объясните?
Банальный пример — проблемы алиасинга почти не существует для инлайна, да что там — даже для статических функций. Она существует только тогда, когда функция торчит наружу, а значит — в неё может прийти что угодно.
Пока это лишь голословные заявления. Мне всегда было интересно — как люди позволяют себе публиковать результаты бенчмарков без самих бенчмарков. Мы не можем ни воспроизвести результата, ни проверить — реально ли бенчмарк измеряет то, что предполагается и т.д.
Известно же, что С++ не самый быстрый в мире язык. Это заблуждение вызвано всего лишь близким родством с действительно быстрым чистым С.
Действительно — С++ позволяет писать «как на си» и люди любят брать свойства этого «как на си» и натягивать на современные/новомодные С++-реалии. Именно на эту тему много спекуляций, но всё равно — формально это не так, и С++ действительно почти как си.
А «чистый си» — это далеко не «быстрый си». Быстрый си почти никогда не бывает чистым.
Rust тем и отличается, что занудливо просит (нет, не так — требует даже) программиста уточнить намеряния.
Не видел ни единого проявления подобного поведения.
Эта требовательность Rust и позволяет произвести более глубокие оптимизации.
Есть примеры живые примеры?
Учитывая возраст C++ и возраст Rust — стоит ожидать только увеличения отрыва по мере оптимизации компилятора.
У раста нет компилятора — раст это фронтенд к крестовому llvm. И какие там вообще оптимизации на уровне фронтенда?
Это не имеет смысла, ведь работает подобное и в обратную сторону. Если привычный — не значит лучший, то и «не привычный» — не значит лучший, а значит подобные заявления друг друга компенсируют.
Современные языки массово используют var: type вместо type var, благодаря чему тип можно опустить.
Нельзя. Именно для этого и существуют let-кастыли, т.к. выражение без типа — неоднозначно.
Я видел очень мало людей, которые понимают сишный синтаксис. 99% вообще напишет тут void f(int f(void)) указатель на функцию. То же самое с type qualifiers, то же самое с теми же указателями. Люди не понимают, что тип у переменной не type *, а *, а type и всё что слева — относится к операции разыменования.
Квалификаторы справа — дефолт, квалификатор слева в случае с * неоднозначен, а значит не может относится к *. Квалификаторы слева — так же никаких проблем, ведь всё логично.
Дано я уже не видел объективной критики сишного синтаксиса. Кроме возврата указателя на функцию я вообще не видел ничего.
Это меня никак не расстраивает, т.к. а) это ничего не меняет, б) я и не утверждал подобного.
Берете Qt'шные библиотеки
С чего я должен их брать? Когда на вы мне кути на расте покажите — тогда приходите. Для проверки достаточно любого С++ кода.
Или можно на оборот библиотеки собранные под gcc а линковать msvc. Разультат тотже.
Это я вообще не обсуждал, т.к. не нужно.
В любом случает, мне не интересна эта «платформа» и её проблемы. Все эти рассуждения ничего не доказывают, ведь за ними ничего не стоит.
Точно известно, что шланг пытается поддерживать msvs abi. Этого уже достаточно для моей правоты. Я не верю, что за десятки лет в гцц так и не реализовали msvs abi, а по ключевым словам гуглится всякий шлак.
Шланг c gcc может и слинкуются, так-как шланг старается мимикрировать под gcc.
Не может, а слинкуются.
Но гарантий нету никаких.
Пустые рассуждения. Вам не нужно забывать о контексте, а в рамках него вероятнее произойдёт ситуации отсутствия хоть какого-то бинарного кода на расте. Все остальные рассуждения не имеют смысла, ведь мы не обсуждаем какие-то гарантии, а сравниваем раст и кресты.
Да и то пока вы не будете передавать что-то через классы стандартной библиотеки. Так-как она у них по разному реализована.
Шланг почти всегда существовал с гнутой stdlib, да и сейчас существует. Если понадобиться линковаться к гцц, то никто не будет использовать libc++.
даже бинарники из-под разных версий msvc не могут друг с другом слинковаться
И? Что же из этого следует? Да мало того, что ничего не следует и это очередной бред, да к тому же — я уже разобрал эту тему выше.
а с gcc и подавно
Заявления противоречат реальности. gcc должен уметь линковаться с msvs, и я на 99% уверен, что это именно так.
Про шланг/гцц я уже говорил, и тут я уже точно знаю, что это работает.
Рантайм то он может быть и поддерживает
Что же вам так хочется везде лезть со своей невероятность глупостью. Поддержка рантайма и есть поддержка левого аби, в противном случае вызвать нужную функцию попросту невозможно.
но скорее всего только если gcc собрать студией
Как комментировать подобную ахинею я просто не знаю. Это ведь не просто ошибка — это отборный бред.
Сборка компилятора другим компилятором не меняет логику работы компилятора. Хотя данный пример показателен, ведь зачем что-то понимать — надо прийти в комменты и нести ахинею. Хотя, судя той реакции и тем ответам, что получаю я — это норма для данного ресурса. С умным видом спамить полную ахинею.
Я даже поясню: в твоей пасте разделителем используется ,(запятая), а не точка с запятой(;).
Второе, твоя глупая попытка не генерирует список типов, а то, что ты впихнул туда тип — ничего не меняет, т.к. в результате всё равно нет списка типов.
И самое интересное, почему заигнорил часть моего комментария про букварь?
Проблемма в том что вам могут дать бинарник собранный другим компилятором.
Маловероятно, что вам кто-то пришлёт бинарники написанные на расте, поэтому это высосанный из пальца пример.
Так же, разные версии раста несовместимы между собой. За примерами ходить не надо, мне уже кто-то рассказывал о том, что «в расте добавили супер-оптимизацию, которой нет в С/С++, потому что это супер-язык», а оказалось — просто врубили флажок существовавший в llvm уже сотни лет, который уже давно реализован в гцц/шланге(-fpack-struct). Естественно, что эти изменения породили бинарно-несовместимые версии компилятора раст.
Ну и во имя справедливости. Шланг спокойно линкуется с гцц, а значит и наоборот. Остаётся только один альтернативно-одарённый компилятор, но даже с ним гцц должен линковаться, но тут я не эксперт и данную платформу никогда в глаза не видел. Но в любом случае, он же как-то собирается с крестовым мсным рантаймом, а значит совместим.
Поэтому, подобная проблема существует только на одной платформе и с одним компилятором, и то кейс нереалистичный. Никто не будет под эту платформу собирать бинари gcc, а если будут собирать, то они должны быть совместимы с msvs.
По поводу подобного:
Для c/c++ у нас есть msvc/gcc/llvm/Green Hills/keil/iar/borland список можно долго продолжать.
Зачем эта глупя подмена понятий? Во-первых — откуда тут взялся си? Во вторых, с каких пор эти «компиляторы» стали уметь в С++?
Живых кросслпатформенных компилятора существует только два — гцц/шланг. Под одну платформу существует альтернативно-одарённый компилятор, который недавно только начал хоть как-то «уметь» в С++. Про их совместимость я уже написал выше.
Только вот незадача, у раста нет «другого компилятора». И почему вдруг для раста вам хватает одного компилятора, а для С++ нет? Вы уж определитесь там.
В данном случае это не принципиально. Разница между написанием даже на готовых примитивах пародии на концепты и использование концептов — такая же «очень большая».
лично я примерно за 2 года уже научился их понимать :), серьезные разработчики — я уверен, тоже
Это не особо продуктивно. Существует очень много людей — их подавляющие большинство, которые не занимают написанием абстракций, интерфейсов, а просто используют готовые. Они мало знакомы с проблемами, которые возникают. С ограничениями, которые не позволяют что-то реализовать(приемлемо) и прочее. Научиться понимать пару знакомых паттернов и понимать ошибки — это две большие разницы.
Ну будет у вас ошибка вида «не найдено» — дальше что? Что она даёт? Что из неё следует? Ничего. Как максимум — вы получите контекст, но это мало что даст.
А если вы пользователь интерфейса? Эти ошибки полностью бесполезны.
И я абсолютно серьезно спрашиваю про вашу версию.
«Вменяемая» версия невозможна в рамках текущих возможностей языка.
А вот более красивый статический интерфейс для кортежа без костылей вида «пропихнем в ядро языка»
Очень просто. Тут вылезают все проблемы, ведь почти всё в с++ — убогие костыли.
Нету рефлексии нету — struct {type;type;}, да ладно там рефлексия — нельзя генерировать идентификаторы. Да что там идентификаторы — вообще ничего нельзя, кроме подстановки типов/значений базовых типов. Какое же метапрограммирование может быть без этих фишек?
А далее, мы видим очередной уродство — аргпаки. Вместо того, чтобы реализовать их на базе рефлексии, как некий компил-тайм итерируемые объекты, вместо того, чтобы добавить к типу метаинформацию — мы имеем костыли, и убогую распаковку в перечисление через запятую.
Это попытались хоть как-то решить в folding expressions, но оно не умеет в типы, а так же не умеет в ;. Но в любом случае — это уже хоть какая-то кодогенерация, а не gnuc 80 годов.
А далее мы имеем язык 80годов, который просто не предназначен для подобного. Да, constexpr — это начало пути к нормальному языку, но всё же. Это лишь костыль.
За примерами далеко ходить не нужно — мы не можем написать цикл по компил-тайм списку. Хотя этому ничего не мешает, но мы всё равно обременены ограничениями рантайм языка.
for() {v;}, где v — есть переменные разных типов в разных итерациях цикла.
Сейчас мы должны генерировать каждое тело подобного цикла отдельно. Типично — через функции, сейчас лямбды. Большинство любят лямбды не потому, что они такие полезные, а потом, что этот костыль позволяет обходить подобный кейс.
for() {[]{v;}}
В этом и фишка, что по сути — в компилтайме С++ может обладать динамикой, причём не уровня костылей, а уровня языка. Компилтайм части языка — не нужна та статика уровня рантайма. И мы получаем «питон», а не экспортируем ограничения рантайма на компилтайм.
Поэтому да, нужно пропихивать в «ядро языка», только не кортежи, а функционал, который и позволить реализовать этот красивый интерфейс.
Как будет время — я опишу подробно две эти темы. Что и почему в языке является костылём, и как( примерно) это должно( по моим представлениям) выглядеть.
Маловероятно, даже для того вида, в котором они существуют сейчас.
Естественно он полезен, но и без него жить можно.
Естественно, С++ полезен, но и с асм«ом жить можно. Дальше что? И да, концепты не сахар, а sfinae-кастыли — не решение.
С таким успехом — можно всё что угодно записать в сахар. Молоток то же сахар, ведь задолбить гвоздь можно и микроскопом, дальше что? А ничего. Это просто полный неадекват.
Есть решения, а есть костыли. Если раньше что-то решалось костылями, а теперь даётся нормальное решение, то оно не становится сахаром, тем более, что оно намного мощнее костылей.
Ок. Не могли бы вы предложить ваш вариант реализации кортежа — убийцы нынешнего?
Кортежи — это про рефлексию, а не про концепты. Кстати, рефлексия тоже сахар?
И да, очередной идиотский вопрос. Хотя о чём я говорю, ведь ваши ответы — типичный заспам неадекватом. Я говорю о том, что в крестах нет средств для реализации вменяемых статических интерфейсов, а мне несут какую-то ахинею про „а где ваш вариант?“. Шаблон сломался? Это такой же полный неадекват.
Если хотите, чтобы я пояснил — почему кортежи в текущих реалиях нельзя реализовать нормально, то я объясню. Точно так же — я могу пояснить и по поводу того, как оно должно выглядеть.
А потом жалуются на всякие взломы, падения, BSODы и прочие «если бы программисты строили дома».
Ну на «современных С++» ничего нет(по крайне мере я об этом не знаю, но вы можете мне такие примеры показать), поэтому не с чем сравнивать. А вот С/С++ на который была попытка съехать выше — там бсоды, падения, взломы и чего только нет.
В любом случае — этот разговор бессмысленный, ведь дискутировать тут попросту не с кем, либо они до сих пор сюда не явились. Всё сводится к простым шаблонным фразочкам, обвинениями в «пхпизме» и прочий зелёный фанатичный бред.
Люди не хотят ничего слушать, не хотят пытаться понять то, что им говорят. Они кидаются ярлыками и обвиняют тебя в том, что сами придумали. Основную причину я уже называл — люди фанатичны по своей природе, и они попросту не могут поверить в то, что можно критиковать то, что используешься.
Критикуешь С++ — пхпист, ведь ты на самом деле не критикуешь, а выгораживаешь своё пхп. Каждый, кто отвечал мне — руководствовался этим. И как я уже говорил, да — в большинстве случаев это работает, ведь привычные людям оппоненты являются такими же фанатиками.
Приходишь в тему с тегом С++ и критикуешь к ресты — фанатики тебя минусуют, ведь ты просто не осилил и на самом деле пхпист. Приходишь в тему с тегом раст и критикуешь раст, защищая кресты — ты крестовый фанатик и не осилил раст.
За этим так интересно наблюдать. Кем же я буду в следующий раз.
И что это за глупый маразм я вижу в ответ? На что это отвечает? Что из этого следует? К чему это написано? Да просто так, лишь бы что-то написать.
Я вот просто не могу понять, зачем вы мне отвечаете этой клоунадой? Ты немного перепутал. Ну это ладно, я не буду разрушать твои наивные представления о мире.
1. вы говорите, что шаблоны принципиально ничем не отличаются от макросов и у них нет проверок типа
Враньё, нигде подобное не говорилось. Опять же — попытки свои фантазии выдать за мои утверждения.
речь о том, что в динамически типизированных языках в отсутствие статических проверок на корректность типов часто выскакивают ошибки несоответствия типов, и выскакивают они в рантайме.
Ну что за клоун. Вы только поглядите на это, клоун ниже выдаёт решение на варианте за решение, хотя ошибки несоответствия типов в варианте выскакивают где? В рантайме, да неужели. Как всё повернулось.
И самое интересное — зачем мне вообще эту ахинею толкать? Я задал конкретные вопросы — где я писал что-то из того, что вы пытаетесь ко мне привязать? Я понимаю, что вы пытаетесь ретранслировать шаблонные ответы, а для этого — меня надо подбить под какой-то шаблон( в частности за адепта динамически типизированных языков), но не выйдет.
Итого код надо покрывать тестами там, где достаточно статических проверок на соответствие типа.
Итого — это никого не волнует. Меня не интересуют подобные рассуждения, ведь я не обсуждал тут статическую/динамическую типизацию.
Была чёткая тема — статический интерфейсы и убогость крестов, которая не позволяет их реализовывать нормально. И я уже так же говорил, что никого не интересуют причины подобного. Есть факт, а всё остальное — никого не волнует. Ваш слив с таппла на вариант — типичный тому пример.
Статический/динамический интерфейсы ортогональны типизации. Те же интерфейсы на виртуальном наследовании, даже в крестах — это динамический интерфейс. Тот же вариант — это динамический интерфейс. Все проверки, кроме примитивных, — в рантайме. Вся логика — в рантайме.
std::enable_if позволяет накладывать ограничения на шаблоны. Рекомендую курить до просветления
Не позволяет. Я уже отвечал на эту ахинею. Подобное кастыляние работает сбоку, т.е. не на уровне шаблонов, описания типов аргументов и ТП.
Уровень маразма находится где-то в районе рассуждений о том, что в жс есть перегрузка функций, ведь typeof'ом можно что-то подобное накастылить.
Примеры я уже показывал, но они в очередной раз были проигнорированы.
void f(int a, int b);
#define f(a, b) f(a, b)
я учил плюсы несколько лет, посещал конференции и смотрел видео докладов не для того, чтобы какой-то выскочка попрекал меня баззвордами.
Меня это мало волнует. Когда клоуну ответить нечего — начинаются рассуждения о том, что он что-то там много лет учил, и что-то там смотрел. Есть что ответить — отвечай, а нету — твоя клоунада меня мало волнует.
И много из себя представляет питон без биндингов к си/с++ модулям? И много где вы запустите джаву кроме десктопа?
И много из себя представляешь ты, без готовой лапши? Ничего. И это ничего не меняет. Тебя не об этом спрашивали. Дак и тому же, как-то ты быстро слился на неведомый С/С++ с обсуждаемого тут «современного С++». Хотя что ещё ожидать.
И много где используется пыха кроме форумов? На плюсах можно писать буквально всё, в отличие от всех динамических языков
Опять же, типичная шаблонная ахинея. Тебя не спрашивали о том, что можно, либо не можно написать. И что же ты слился на пых? Куда пропала та же жава? Тебе говорили о том, что никому не нужны твои рассуждения, ведь они противоречат реальности. Рантайм резиновый, и множество людей с этим живёт. Твои рассуждения в их реальности не котируются, а их реальность куда более реальна, нежели твои шаблонные лозунги.
угандийцы тоже живут.
Аргументы, такие аргументы.
зато можно просто так взять и понять, чем таппл отличается от массива и почему обходить его для большинства задач не требуется.
Пошли очередные мазы. Всё, на что у меня нет ответа — не нужно, при этом нет ни единого обоснования подобному трёпу.
Клоуны настолько неадекватны, что противоречат реалиям того же языка. Клоун орёт «всё есть», а люди пилят концепты. Вот ведь идиоты. Клоун орёт, что «обходить таппл не нужно», но в стандарт добавляют хелперы, которые реализуются через tuple expansion, что и есть его обход.
И да, таппл отличается от массива только потому, что это убогий кастыль. Если бы в языке была нормальная рефлексия, то он бы ничем от массива не отличался. Налицо полный неадекват и непонимание базовых вещей.
обойти таппл можно и в с++11.
И? Я где-то утверждал обратное?
Сложно, но можно.
Неможно. В рамках контексте предполагается решение «без магии», а не любое решения.
Как я уже сказал: зачем?
Распакуй таппл в набор параметров. Типичный кейс, который ввели в стандарт.
Реализуй любую операцию поверх таппла — ничего не сможешь, кроме уже реализованного сравнения.
Если для задачи достаточно контейнера вариантов, почему не воспользоваться им?
Я нихрена не понимаю, что за «контейнера вариантов» и каким боком он тут взялся, но всё же.
Вариант — это рантайм кастыльня. Т.е. мы видим типичное проявление того, о чём я говорил. Пациент, который со мной пытается спорить — сам же признаёт, что статический интерфейс говно и надо использовать динамический интерфейс, пусть и с убогой статической обёрткой.
Массив вариантов — такое же динамическое решение, и это очередной слив.
К тому же, это очередной слив ещё и тем, ведь вариант это так же 17 кресты, а значит мы автоматически множим предыдущие на ноль и это ничего не меняет.
1) И что такого можно сделать концептами, чего нельзя добиться SFINAE? (Красивые ошибки компиляции не в счет))
Что можно написать на С++, чего нельзя написать на асм? Эта рассуждения глупы, ведь неважно что можно, важно то — как можно. И это как — является ключевым. А так да, всё можно сделать кастылями, но является ли это аргументом?
Но если вам хочется, чтобы программа работала быстро, вы не будете её использовать, не так ли?
Вот вы мне объясните, зачем вы спорите с кем угодно, только не со мной? Я где-то что-то отрицал, где-то что-то подобное предлагал, либо это отрицал?
Не надо юлить. Не существует цензурных слов, которые опишут всё то, что я думаю о питоне, жаве, либо пхп. Но дело не в этом — я не обсуждаю пхп/пистон. Я обсуждаю конкретные рассуждения и отвечаю только за то, что писал я, не за то, что вы там придумали себе.
У людей очень странна реакция — они просто осознать не могут возможность, что кто-то может критиковать их. Мышление людей заканчивается на «если критикует — он адепт другой веры, а значит я могу ему сказать „ты не осилил“», и это даже работает( иногда).
Но проблема в том, что именно подобные люди не осилили, именно подобные люди ничего не знаю — они фанатики. А люди те, которые знают — объективно воспринимают реальность, и критика своего языка для них — это не табу.
Много на питоне или пхп, баз данных написано? Или, к примеру, ОС?
И? Вот вы заметьте — вы спорите с кем угодно, только не со мной. Мы где-то обсуждали ОС, базы данных? Нет.
Я больше скажу — те, с кем я спорю — не имеют никакого отношения ни к ОС, ни к базам данных, и они их точно так не напишут. Достаточно посмотреть на перлы выше. А особенно «я уже забыл как работать с памятью», вернее «я даже и не помнил».
Язык языку рознь, любое написание чего-то требует не только языка — да даже не уровне языка существуют люди совершенно с разным уровнем понимания — и возможности их даже в рамках языка не сопоставимы. А за рамками языка — почти всегда решает бекграунд, и язык выступаешь лишь тем, что позволит воплотить в реальность эти знания и понимание.
Т.е. тратить время на написание типов, которые часто сводятся к auto, вы не хотите, а фиксить всякие «too many values to unpack», «int is not iterable» и прочие «TypeError: null has no properties» хотите?
Что? Опять какие-то ответы, адресованные явно не мне. Откуда взялось какое-то написание типов, откуда взялись все эти строчки, которые я «хочу фиксить»?
Кишки кортежей — это да. Мне кажется, чтобы что-то использовать, нужно это что-то изучать
Изучить можно всё что угодно, и как штаны через голову натягивать — только вот зачем? Мы это обсуждали? Нет.
Говорилось совсем о другом. Кто-то утверждал то, что «понимать не нужно», хотя это неправда. Понимать нужно, но всё это понимание — ненужно. Да, ты обязан его использовать — ты заложник убогости, но это не делает его нужным, красивым, удобным, либо необходимым.
Язык не умеет в рефлекшен, но можно через одно место накастылить tuple. Пусть и полное убожество, но всё же — работает. Это очень показательно, как люди недовольные тем, что всё ограничивается критерием «лишь бы работало», но при этом руководствуются им же. Пистон не быстро, но работает. tuple убого, но работает. К чему мы с таким подходом придём?
И это крайне показательно. Люди попросту не знают язык, именно поэтому и игнорируют мои вопросы, мои тезисы, мои примеры и пытаются спорить сами с собой.
Но ведь фанатизм он такой — его уровень обратно пропорционален пониманию языка. Вот мы и получаем вылезших из-за парты екпертов, которые заучили пару трюков, повторяют какую-то ахинею про «С++ дано не си», но ответить на банальные вопросы не могут.
Но ничего, они такие уверенные в себе только в первый парту постов, а потом они куда-то очень быстро исчезают.
Нужно делать не так, а рассматривать именно операции для которых доступны аргументы. А то, что записало туда эти аргументы — это совершенно другая история.
Не могут. То, что указанно в табличке за 0.5 и менее — это не время выполнение операции, а просто ipc(для одних и тех же операций). Время же выполнения самое операции — написано с столбике «летенси».
Не оценивает.
Это уже похоже на правду — по ссылки минимальная летенси 3такта( по крайней мере меньше я не увидел).
Действительно, х87 ещё с core2 выкинули на помойку.
Не уменьшатся. Как я уже говорил — время выполнение одно и то же и написано в столбике «летенси».
Нет. Проблема та же, что и выше.
Вот именно, что «задержка» и на те 0.5 — она «никак» не повлияет.
Совет не имеет смысла. Всё зависит от того, что понимать под производительностью и в подавляющем большинстве случаев под нею понимается не то, на что влияют эти задержки.
Из этого мало что следует, т.к. процессор умеет спекулятивно исполнять угаданную ветку. В любом случае — измерение этого «наобум» имеет мало смысла, т.к. в одном случае это может быть ноль, а в другом далеко не ноль. И всё это в рамках угаданного перехода.
Не совсем верно. Это лишь «размазывает» по времени редкие записи. Не нужно ждать пока не переполнился буфер/кэш, а далее ждать нужно.
Не может. Есть два кейса — пишешь в рамках ширины буфера/кеша/etc — получаешь ~трупут буфера/кеша/etc, а вот если не пишешь — не получаешь. Ничего другого нет и быть не может. Всё так же, как для чтения. Хотя есть нюансы и они не в пользу записи.
Разница между чтением и записью в том, что чтение всегда является зависимостью для следующей, а запись нет. И вся задержка идёт именно в чтение.
Не совсем верно, а вернее совсем неверно. Стоимость промаха кэша — это не оверхед самого кеша( Это та задержка, которая существует между получением данным и возвратам их кешом. Это задержка на запись данных с вам кеш + много организационных задержек( надо узнать в какое место писать и прочее)). И по ссылкам это именно оверхед кеша.
Но ещё одно и основной свойство промаха в том, что надо прочитать данные из предыдущего уровня памяти и это и есть основная задержка, которую все и понимают под ценой промаха. И она в ссылке не указана, а вернее указана ниже. И там уже далеко не 10тактов. Ну и к тому же, бывают не только минорные пейджфолты.
Странная формулировка с общей локальностью. Из TLB можно либо выйти, либо не выйти — третьего не дано. А выйти( 1к * 4к страниц в дефолте) из него не составляет труда.
Из этого так же мало что следует.
Мало коррелирует с реальность для того же Linux.
Не совсем верно — mov попросту не существует по причине отсутствия самих регистров. А даже если бы существовало, то не параллельно, а вместе.
Куда делась стоимость самой проверки?
От нуля.
Резюмируя, перед написанием подобных статей — надо для себя и аудитории определить базовые понятия. В частности, что такое latency/throughput, почему и откуда они взялись. И почему вообще ничего, без контекста, предсказать нельзя.
Кроме трёпа ничего не будет, я правильно понимаю?
Неверно, это свойства базовой реальности. Почему вы проигнорировали это? Где ответы?
fn main() {
let s1 = String::from("hello");
let mut rs = &s1;
let mut len = calculate_length(&s1, &rs);
len = calculate_length(&s1, &s1) + len;
let mut slice = &s1[..3];
println!("The length of '{}' is {} is {} is {}.", s1, len, slice, rs);
}
fn calculate_length(mut s: &String, mut sl: &String) -> usize {
s.len() + sl.len()
}
Это что такое? Где вообще пруфцы от вас? Почему я вижу только ссылки на хрен пойми что в интернете и пустые заявления?
Меня мало интересуют абстрактные обсуждения и ссылки на то, что «может быть». Я вам привёл свои рассуждения, которые вы никак не опровергли и начали ехать в сторону каких-то левых, не относящихся к теме, вещей.
Не могут. Единственная возможность — это экспортировать сразу несколько указателей из внешнего контекста, но это ненужно. И любой, кто претендует на хоть какую-то производительность — так делать не будет.
godbolt.org/g/V3KXCW — шлангу даже рестрикт не помог, а шансом 98% — это проблема в ллвм, в значит расту ничего не поможет.
Я уже сказал, что его нету. Культуры нет ни его применения, а написания производительного кода.
Опять эти глупые попытки меня ловить. Меня мало волнуют ваши «явно» — я вижу ваш уровень, уровень раст-апологетов. Мне этого достаточно. Мнение о языка, о производительности тех, кто ничего в теме не понимает — меня волновать не должно.
А ненавижу я не раст, а рекламный булшит и балаболов.
И заметьте, я привёл чёткие причины моего недовольства — вы ответили что-то на них? Нет, вы всё неудобное вам игнорируете, занимаясь глупыми обвинениями. А чей-то трёп стоит ноль.
Фанат. Без понимания чего-то лезть куда-то и что-то вещать — это типичная фанатичная глупость. Я где-то услышал какие-то лозунги — и пошел вещать об этом в комментах.
Достаточно посмотреть ваши подобные попытки, когда вы пытались вещать мне про ГЦ. Фанатизм во все поля, ссылки на левые хелворды, отсутствие ответов. А это первое, что я вспомнил. Подобных наших баталий помню больше одной, но мне лень их искать.
Это типичный пример кастылей, когда проблема не решается, а хайп нужен. Да и подобные рассуждения не имеют смысла — без bc потеряется основной лозунг, а кроме них ничего и нет.
Да что там далеко ходить, оно даже слайс на константную(времени компилтайма) строку borrow checker'ом ловит. Колхоз колхоза.
Нет, вы не понимаете. И в этом проблема. Вы лезете в тему производительности, в тему лоулевел и С/С++, в которых ничего не понимаете. Как и все остальные адепты.
Хотите делать свои супер-языки? Делайте, но не лезьте в эти темы и не рассказывайте мне о том, что ваш колхоз хоть как-то заменяет С/С++.
А для чего мозилла производит этот хайповый булшит? График популярности броузеров за последние года — вам должен дать ответ на этот вопрос.
Почему весь хабр заспамлен этим булшитом? Пример я уже приводил(а вы его проигнорировали. Хотя это типичное, для вас, поведение). Всё просто — халявные инвайты, халявные плюсы. Пиши любую ахинею в рамках «руст так же быстр» — получай халяву от фанатиков.
Перво наперво — нужно осилить понятие «контекст», а уже потом приходить со своими пожалуйста. Но я помогу, контекстом был синтаксис описания типов, а не синтаксис вообще. Тем более, половина тут вообще не касается синтаксиса.
Везде, особенно в однострочниках. Вон пару сообщений назад мне кто-то пастил крестовый код, и там именно запятая.
Продуман. Это банальная логика третий класс. Есть семантика перехода, есть переходы в свиче. Переходы не ограничены ничем.
Каждая вторая — подобная ситуация.
Т.е. для тех ситуаций, которых две строчки назад «крайне редко»? Сильно.
Это итак работает. case: case: case: — сколько угодно.
Не объективно. Для меня затрудняет чтение обратное.
Это не критика. Меня мало должны волновать ваши предпочтения. Они так отдельно.
Как мне объявить int v, * p; в вашем супер-синтаксисе? Хотите ограничить типы — есть тайпдеф. Напишите там что угодно и это уже будет типов, а «составным типом».
И? С каких пор «хочу» — стало критикой? [10] — это такое же свойство переменной. Хотите определить это на базе типа — есть тайпдефы.
Зачем нужно это «function» кастыльное непотребство? Мне не хотелось бы, дальше что?
Есть тайпдефы, стандартизированные.
Нету никакой неоднозначности. Конструктор — это вызов функции. Другое дело, что на самом деле конструктор — инициализатор, а в си инициализатор {}. Поэтому всё вернулось на круги своя.
Это не костыль.
Неверно. К синтаксису языка это не имеет никакого отношения — это фундаментальная неоднозначность между использованием и объявлением. И auto в С++ не кастыль, ведь синтаксис определения не изменяется. type var;, а вот в кастыльном var: type; — меняется, ведь нам нужно добавлять ненужность в виде let, как и ненужность в виде function/fn и прочего колхоза.
Сишный синтаксис позволяет опускать типы, но в С++ как всегда — решили пойти своим путём.
А как только нам нужно больше логики? И опять же, это примитивный сахар, а не синтаксис. Убогая стрелка, которая ничем не лучше скобок.
Почему вам «лишнее» слово тут «int function(int, int)» не мешает, а тут мешает? Вы уж там определитесь.
А теперь [&]{ x += 1;}. Синтаксис намного мощнее, нежели эти хелворды.
Тем более, этот синтаксис итак есть в крестах [](auto x, auto y) -> auto {}, только синтаксис крестов несоизмеримо мощней, нежели эти хелворды, которые вы пытаетесь выдать за синтаксис.
Вы попробуйте облечь в них все те возможности, что есть в крестах. В этом проблема всех «критиков», помимо основной «я хочу так — это критика», — «я пащу левый синтаксис, который просто не может в ту семантику, которая существует в рамках крестов».
И? Во-первых это попытка выдать ограничение за фичу.
Во-вторых, алиаситься может не только мутабельное с мутабельным, а так же мутабельное с иммутабельным. Это подлог, либо явное непонимание темы.
Второе, разные объекты ничего не значат. Ссылка на элемент массива и сам массив — являются разными объектами, но они алиасятся. Ссылка на поле и структура — так же. Я сомневаюсь, что нельзя взять ссылку на на поле, либо на елемент и что это идёт в счёт той самой «только одной» ссылки.
Для разных типов это итак не работает.
В плюсах нету рестрикта, он есть в си. Хотя раст не имеет никакого отношения к унификации и стандартизации, поэтому мы можем брать любую фишку любого компилятора и приписывать её к С/С++.
Продолжим, как вы ответите на мои вопросы. Но в любом случае — это невозможно.
Это не производительность, даже близко. Люди, которые ничего о ней не знают — очень любят раст и порассуждать.
Пруфы? Пожалуйста — начало ветки. У автора ансейф через ансейф. Где же мистическая «производительность без выбора»? Как только автор предоставит код — можно будет посмотреть, что именно там намерено и как. Уже потом можно будет и исходный крестовый код посмотреть. Пока что — тут рассуждать не о чём.
Ещё пруфы? Пожалуйста, «предыдущая» тема про раст, которая касалась сравнения раста и С++. 72 плюса, 7 минусов и ноль сообщений о том, что это убогая клоунада, а не сравнение. Множество восторженных сообщений. Как вы это объясните?
Нужны пруфы того, что это клоунада? Пожалуйста — habrahabr.ru/post/344282/#comment_10563198
Банальный пример — проблемы алиасинга почти не существует для инлайна, да что там — даже для статических функций. Она существует только тогда, когда функция торчит наружу, а значит — в неё может прийти что угодно.
Пока это лишь голословные заявления. Мне всегда было интересно — как люди позволяют себе публиковать результаты бенчмарков без самих бенчмарков. Мы не можем ни воспроизвести результата, ни проверить — реально ли бенчмарк измеряет то, что предполагается и т.д.
Действительно — С++ позволяет писать «как на си» и люди любят брать свойства этого «как на си» и натягивать на современные/новомодные С++-реалии. Именно на эту тему много спекуляций, но всё равно — формально это не так, и С++ действительно почти как си.
А «чистый си» — это далеко не «быстрый си». Быстрый си почти никогда не бывает чистым.
Не видел ни единого проявления подобного поведения.
Есть примеры живые примеры?
У раста нет компилятора — раст это фронтенд к крестовому llvm. И какие там вообще оптимизации на уровне фронтенда?
А разрыва пока никто не показал.
Можно увидеть код на rust/C++, который сравнивается? А так же, желательно, код самого бенчмарка.
Это не имеет смысла, ведь работает подобное и в обратную сторону. Если привычный — не значит лучший, то и «не привычный» — не значит лучший, а значит подобные заявления друг друга компенсируют.
Нельзя. Именно для этого и существуют let-кастыли, т.к. выражение без типа — неоднозначно.
Я видел очень мало людей, которые понимают сишный синтаксис. 99% вообще напишет тут void f(int f(void)) указатель на функцию. То же самое с type qualifiers, то же самое с теми же указателями. Люди не понимают, что тип у переменной не type *, а *, а type и всё что слева — относится к операции разыменования.
Квалификаторы справа — дефолт, квалификатор слева в случае с * неоднозначен, а значит не может относится к *. Квалификаторы слева — так же никаких проблем, ведь всё логично.
Дано я уже не видел объективной критики сишного синтаксиса. Кроме возврата указателя на функцию я вообще не видел ничего.
Это меня никак не расстраивает, т.к. а) это ничего не меняет, б) я и не утверждал подобного.
С чего я должен их брать? Когда на вы мне кути на расте покажите — тогда приходите. Для проверки достаточно любого С++ кода.
Это я вообще не обсуждал, т.к. не нужно.
В любом случает, мне не интересна эта «платформа» и её проблемы. Все эти рассуждения ничего не доказывают, ведь за ними ничего не стоит.
Точно известно, что шланг пытается поддерживать msvs abi. Этого уже достаточно для моей правоты. Я не верю, что за десятки лет в гцц так и не реализовали msvs abi, а по ключевым словам гуглится всякий шлак.
Не может, а слинкуются.
Пустые рассуждения. Вам не нужно забывать о контексте, а в рамках него вероятнее произойдёт ситуации отсутствия хоть какого-то бинарного кода на расте. Все остальные рассуждения не имеют смысла, ведь мы не обсуждаем какие-то гарантии, а сравниваем раст и кресты.
Шланг почти всегда существовал с гнутой stdlib, да и сейчас существует. Если понадобиться линковаться к гцц, то никто не будет использовать libc++.
И? Что же из этого следует? Да мало того, что ничего не следует и это очередной бред, да к тому же — я уже разобрал эту тему выше.
Заявления противоречат реальности. gcc должен уметь линковаться с msvs, и я на 99% уверен, что это именно так.
Про шланг/гцц я уже говорил, и тут я уже точно знаю, что это работает.
Что же вам так хочется везде лезть со своей невероятность глупостью. Поддержка рантайма и есть поддержка левого аби, в противном случае вызвать нужную функцию попросту невозможно.
Как комментировать подобную ахинею я просто не знаю. Это ведь не просто ошибка — это отборный бред.
Сборка компилятора другим компилятором не меняет логику работы компилятора. Хотя данный пример показателен, ведь зачем что-то понимать — надо прийти в комменты и нести ахинею. Хотя, судя той реакции и тем ответам, что получаю я — это норма для данного ресурса. С умным видом спамить полную ахинею.
Я даже поясню: в твоей пасте разделителем используется ,(запятая), а не точка с запятой(;).
Второе, твоя глупая попытка не генерирует список типов, а то, что ты впихнул туда тип — ничего не меняет, т.к. в результате всё равно нет списка типов.
И самое интересное, почему заигнорил часть моего комментария про букварь?
Маловероятно, что вам кто-то пришлёт бинарники написанные на расте, поэтому это высосанный из пальца пример.
Так же, разные версии раста несовместимы между собой. За примерами ходить не надо, мне уже кто-то рассказывал о том, что «в расте добавили супер-оптимизацию, которой нет в С/С++, потому что это супер-язык», а оказалось — просто врубили флажок существовавший в llvm уже сотни лет, который уже давно реализован в гцц/шланге(-fpack-struct). Естественно, что эти изменения породили бинарно-несовместимые версии компилятора раст.
Ну и во имя справедливости. Шланг спокойно линкуется с гцц, а значит и наоборот. Остаётся только один альтернативно-одарённый компилятор, но даже с ним гцц должен линковаться, но тут я не эксперт и данную платформу никогда в глаза не видел. Но в любом случае, он же как-то собирается с крестовым мсным рантаймом, а значит совместим.
Поэтому, подобная проблема существует только на одной платформе и с одним компилятором, и то кейс нереалистичный. Никто не будет под эту платформу собирать бинари gcc, а если будут собирать, то они должны быть совместимы с msvs.
По поводу подобного:
Зачем эта глупя подмена понятий? Во-первых — откуда тут взялся си? Во вторых, с каких пор эти «компиляторы» стали уметь в С++?
Живых кросслпатформенных компилятора существует только два — гцц/шланг. Под одну платформу существует альтернативно-одарённый компилятор, который недавно только начал хоть как-то «уметь» в С++. Про их совместимость я уже написал выше.
Для справки, с каких пор args стал типами? Да и тому, что писал этот хелворд нужно срочно букварь перечитать на тему того же pf.
В данном случае это не принципиально. Разница между написанием даже на готовых примитивах пародии на концепты и использование концептов — такая же «очень большая».
Это не особо продуктивно. Существует очень много людей — их подавляющие большинство, которые не занимают написанием абстракций, интерфейсов, а просто используют готовые. Они мало знакомы с проблемами, которые возникают. С ограничениями, которые не позволяют что-то реализовать(приемлемо) и прочее. Научиться понимать пару знакомых паттернов и понимать ошибки — это две большие разницы.
Ну будет у вас ошибка вида «не найдено» — дальше что? Что она даёт? Что из неё следует? Ничего. Как максимум — вы получите контекст, но это мало что даст.
А если вы пользователь интерфейса? Эти ошибки полностью бесполезны.
«Вменяемая» версия невозможна в рамках текущих возможностей языка.
Очень просто. Тут вылезают все проблемы, ведь почти всё в с++ — убогие костыли.
Нету рефлексии нету — struct {type;type;}, да ладно там рефлексия — нельзя генерировать идентификаторы. Да что там идентификаторы — вообще ничего нельзя, кроме подстановки типов/значений базовых типов. Какое же метапрограммирование может быть без этих фишек?
А далее, мы видим очередной уродство — аргпаки. Вместо того, чтобы реализовать их на базе рефлексии, как некий компил-тайм итерируемые объекты, вместо того, чтобы добавить к типу метаинформацию — мы имеем костыли, и убогую распаковку в перечисление через запятую.
Это попытались хоть как-то решить в folding expressions, но оно не умеет в типы, а так же не умеет в ;. Но в любом случае — это уже хоть какая-то кодогенерация, а не gnuc 80 годов.
А далее мы имеем язык 80годов, который просто не предназначен для подобного. Да, constexpr — это начало пути к нормальному языку, но всё же. Это лишь костыль.
За примерами далеко ходить не нужно — мы не можем написать цикл по компил-тайм списку. Хотя этому ничего не мешает, но мы всё равно обременены ограничениями рантайм языка.
for() {v;}, где v — есть переменные разных типов в разных итерациях цикла.
Сейчас мы должны генерировать каждое тело подобного цикла отдельно. Типично — через функции, сейчас лямбды. Большинство любят лямбды не потому, что они такие полезные, а потом, что этот костыль позволяет обходить подобный кейс.
for() {[]{v;}}
В этом и фишка, что по сути — в компилтайме С++ может обладать динамикой, причём не уровня костылей, а уровня языка. Компилтайм части языка — не нужна та статика уровня рантайма. И мы получаем «питон», а не экспортируем ограничения рантайма на компилтайм.
Поэтому да, нужно пропихивать в «ядро языка», только не кортежи, а функционал, который и позволить реализовать этот красивый интерфейс.
Как будет время — я опишу подробно две эти темы. Что и почему в языке является костылём, и как( примерно) это должно( по моим представлениям) выглядеть.
Маловероятно, даже для того вида, в котором они существуют сейчас.
Естественно, С++ полезен, но и с асм«ом жить можно. Дальше что? И да, концепты не сахар, а sfinae-кастыли — не решение.
С таким успехом — можно всё что угодно записать в сахар. Молоток то же сахар, ведь задолбить гвоздь можно и микроскопом, дальше что? А ничего. Это просто полный неадекват.
Есть решения, а есть костыли. Если раньше что-то решалось костылями, а теперь даётся нормальное решение, то оно не становится сахаром, тем более, что оно намного мощнее костылей.
Кортежи — это про рефлексию, а не про концепты. Кстати, рефлексия тоже сахар?
И да, очередной идиотский вопрос. Хотя о чём я говорю, ведь ваши ответы — типичный заспам неадекватом. Я говорю о том, что в крестах нет средств для реализации вменяемых статических интерфейсов, а мне несут какую-то ахинею про „а где ваш вариант?“. Шаблон сломался? Это такой же полный неадекват.
Если хотите, чтобы я пояснил — почему кортежи в текущих реалиях нельзя реализовать нормально, то я объясню. Точно так же — я могу пояснить и по поводу того, как оно должно выглядеть.
Ну на «современных С++» ничего нет(по крайне мере я об этом не знаю, но вы можете мне такие примеры показать), поэтому не с чем сравнивать. А вот С/С++ на который была попытка съехать выше — там бсоды, падения, взломы и чего только нет.
В любом случае — этот разговор бессмысленный, ведь дискутировать тут попросту не с кем, либо они до сих пор сюда не явились. Всё сводится к простым шаблонным фразочкам, обвинениями в «пхпизме» и прочий зелёный фанатичный бред.
Люди не хотят ничего слушать, не хотят пытаться понять то, что им говорят. Они кидаются ярлыками и обвиняют тебя в том, что сами придумали. Основную причину я уже называл — люди фанатичны по своей природе, и они попросту не могут поверить в то, что можно критиковать то, что используешься.
Критикуешь С++ — пхпист, ведь ты на самом деле не критикуешь, а выгораживаешь своё пхп. Каждый, кто отвечал мне — руководствовался этим. И как я уже говорил, да — в большинстве случаев это работает, ведь привычные людям оппоненты являются такими же фанатиками.
Приходишь в тему с тегом С++ и критикуешь к ресты — фанатики тебя минусуют, ведь ты просто не осилил и на самом деле пхпист. Приходишь в тему с тегом раст и критикуешь раст, защищая кресты — ты крестовый фанатик и не осилил раст.
За этим так интересно наблюдать. Кем же я буду в следующий раз.
Я вот просто не могу понять, зачем вы мне отвечаете этой клоунадой? Ты немного перепутал. Ну это ладно, я не буду разрушать твои наивные представления о мире.
Враньё, нигде подобное не говорилось. Опять же — попытки свои фантазии выдать за мои утверждения.
Ну что за клоун. Вы только поглядите на это, клоун ниже выдаёт решение на варианте за решение, хотя ошибки несоответствия типов в варианте выскакивают где? В рантайме, да неужели. Как всё повернулось.
И самое интересное — зачем мне вообще эту ахинею толкать? Я задал конкретные вопросы — где я писал что-то из того, что вы пытаетесь ко мне привязать? Я понимаю, что вы пытаетесь ретранслировать шаблонные ответы, а для этого — меня надо подбить под какой-то шаблон( в частности за адепта динамически типизированных языков), но не выйдет.
Итого — это никого не волнует. Меня не интересуют подобные рассуждения, ведь я не обсуждал тут статическую/динамическую типизацию.
Была чёткая тема — статический интерфейсы и убогость крестов, которая не позволяет их реализовывать нормально. И я уже так же говорил, что никого не интересуют причины подобного. Есть факт, а всё остальное — никого не волнует. Ваш слив с таппла на вариант — типичный тому пример.
Статический/динамический интерфейсы ортогональны типизации. Те же интерфейсы на виртуальном наследовании, даже в крестах — это динамический интерфейс. Тот же вариант — это динамический интерфейс. Все проверки, кроме примитивных, — в рантайме. Вся логика — в рантайме.
Не позволяет. Я уже отвечал на эту ахинею. Подобное кастыляние работает сбоку, т.е. не на уровне шаблонов, описания типов аргументов и ТП.
Уровень маразма находится где-то в районе рассуждений о том, что в жс есть перегрузка функций, ведь typeof'ом можно что-то подобное накастылить.
Примеры я уже показывал, но они в очередной раз были проигнорированы.
void f(int a, int b);#define f(a, b) f(a, b)
Меня это мало волнует. Когда клоуну ответить нечего — начинаются рассуждения о том, что он что-то там много лет учил, и что-то там смотрел. Есть что ответить — отвечай, а нету — твоя клоунада меня мало волнует.
И много из себя представляешь ты, без готовой лапши? Ничего. И это ничего не меняет. Тебя не об этом спрашивали. Дак и тому же, как-то ты быстро слился на неведомый С/С++ с обсуждаемого тут «современного С++». Хотя что ещё ожидать.
Опять же, типичная шаблонная ахинея. Тебя не спрашивали о том, что можно, либо не можно написать. И что же ты слился на пых? Куда пропала та же жава? Тебе говорили о том, что никому не нужны твои рассуждения, ведь они противоречат реальности. Рантайм резиновый, и множество людей с этим живёт. Твои рассуждения в их реальности не котируются, а их реальность куда более реальна, нежели твои шаблонные лозунги.
Аргументы, такие аргументы.
Пошли очередные мазы. Всё, на что у меня нет ответа — не нужно, при этом нет ни единого обоснования подобному трёпу.
Клоуны настолько неадекватны, что противоречат реалиям того же языка. Клоун орёт «всё есть», а люди пилят концепты. Вот ведь идиоты. Клоун орёт, что «обходить таппл не нужно», но в стандарт добавляют хелперы, которые реализуются через tuple expansion, что и есть его обход.
И да, таппл отличается от массива только потому, что это убогий кастыль. Если бы в языке была нормальная рефлексия, то он бы ничем от массива не отличался. Налицо полный неадекват и непонимание базовых вещей.
И? Я где-то утверждал обратное?
Неможно. В рамках контексте предполагается решение «без магии», а не любое решения.
Распакуй таппл в набор параметров. Типичный кейс, который ввели в стандарт.
Реализуй любую операцию поверх таппла — ничего не сможешь, кроме уже реализованного сравнения.
Я нихрена не понимаю, что за «контейнера вариантов» и каким боком он тут взялся, но всё же.
Вариант — это рантайм кастыльня. Т.е. мы видим типичное проявление того, о чём я говорил. Пациент, который со мной пытается спорить — сам же признаёт, что статический интерфейс говно и надо использовать динамический интерфейс, пусть и с убогой статической обёрткой.
Массив вариантов — такое же динамическое решение, и это очередной слив.
К тому же, это очередной слив ещё и тем, ведь вариант это так же 17 кресты, а значит мы автоматически множим предыдущие на ноль и это ничего не меняет.
Да и куда делся any?
Что можно написать на С++, чего нельзя написать на асм? Эта рассуждения глупы, ведь неважно что можно, важно то — как можно. И это как — является ключевым. А так да, всё можно сделать кастылями, но является ли это аргументом?
Вот вы мне объясните, зачем вы спорите с кем угодно, только не со мной? Я где-то что-то отрицал, где-то что-то подобное предлагал, либо это отрицал?
Не надо юлить. Не существует цензурных слов, которые опишут всё то, что я думаю о питоне, жаве, либо пхп. Но дело не в этом — я не обсуждаю пхп/пистон. Я обсуждаю конкретные рассуждения и отвечаю только за то, что писал я, не за то, что вы там придумали себе.
У людей очень странна реакция — они просто осознать не могут возможность, что кто-то может критиковать их. Мышление людей заканчивается на «если критикует — он адепт другой веры, а значит я могу ему сказать „ты не осилил“», и это даже работает( иногда).
Но проблема в том, что именно подобные люди не осилили, именно подобные люди ничего не знаю — они фанатики. А люди те, которые знают — объективно воспринимают реальность, и критика своего языка для них — это не табу.
И? Вот вы заметьте — вы спорите с кем угодно, только не со мной. Мы где-то обсуждали ОС, базы данных? Нет.
Я больше скажу — те, с кем я спорю — не имеют никакого отношения ни к ОС, ни к базам данных, и они их точно так не напишут. Достаточно посмотреть на перлы выше. А особенно «я уже забыл как работать с памятью», вернее «я даже и не помнил».
Язык языку рознь, любое написание чего-то требует не только языка — да даже не уровне языка существуют люди совершенно с разным уровнем понимания — и возможности их даже в рамках языка не сопоставимы. А за рамками языка — почти всегда решает бекграунд, и язык выступаешь лишь тем, что позволит воплотить в реальность эти знания и понимание.
Что? Опять какие-то ответы, адресованные явно не мне. Откуда взялось какое-то написание типов, откуда взялись все эти строчки, которые я «хочу фиксить»?
Изучить можно всё что угодно, и как штаны через голову натягивать — только вот зачем? Мы это обсуждали? Нет.
Говорилось совсем о другом. Кто-то утверждал то, что «понимать не нужно», хотя это неправда. Понимать нужно, но всё это понимание — ненужно. Да, ты обязан его использовать — ты заложник убогости, но это не делает его нужным, красивым, удобным, либо необходимым.
Язык не умеет в рефлекшен, но можно через одно место накастылить tuple. Пусть и полное убожество, но всё же — работает. Это очень показательно, как люди недовольные тем, что всё ограничивается критерием «лишь бы работало», но при этом руководствуются им же. Пистон не быстро, но работает. tuple убого, но работает. К чему мы с таким подходом придём?
И это крайне показательно. Люди попросту не знают язык, именно поэтому и игнорируют мои вопросы, мои тезисы, мои примеры и пытаются спорить сами с собой.
Но ведь фанатизм он такой — его уровень обратно пропорционален пониманию языка. Вот мы и получаем вылезших из-за парты екпертов, которые заучили пару трюков, повторяют какую-то ахинею про «С++ дано не си», но ответить на банальные вопросы не могут.
Но ничего, они такие уверенные в себе только в первый парту постов, а потом они куда-то очень быстро исчезают.