Метапрог-прототип 16 + СУВТ по енумам

людей, которые могут писать на С++ так, чтобы царь был доволен. Таких один на тысячу, если не меньше, среди тех, кто говорит «пишу на С++».

Подозреваю, что для этого придется от корочки до корочки прочитать талмуды Страуструпа и Александреску, так ведь?

Простой тест - если человек не может прочитать весь код этой библиотеки (а не только «как использовать») и полностью понять его семантику (про время не говорим) а также сам писать в таком стиле, то для царя он «не может».

Раньше царь вроде наоборот топил за простоту сишки. Я и не претендую на то, что «могу» что-то на плюсах. Но, возможно, в идеях царя что-то есть - по крайней мере, в отношении к говноскриптухе я его понимаю. Хотелось бы лучше понять что именно он хочет сделать - подозреваю, что в Метапроге я хочу реализовать практически то же самое.

Во всяком случае, мы понимаем, что соответствовать царским критериям большинству программистов нереально. И тут на помощь приходит визуальное программирование: оно резко снижает порог входа, я тому пример. Я вообще не профессиональный программист, но благодаря Лабвью я могу делать целый прототип Метапрога. При этом он делался и делается постепенно, «методом тыка». Лабвью позволяет мне не думать заранее о многих вещах, о которых неизбежно надо думать в текстовых ЯП (проектирование, какие где классы, интерфейсы и все такое). Но самое важное - если опираться на сишку (и сишную систему типов), то при всей простоте и удобства для программирования оверхед будет минимальным.

Долго думал?

Нет:)

Но там в общем случае все же свич будет плюс юнион имеет размер самого большого его члена

Нет, все лишнее удаляется - https://godbolt.org/z/jknZv-

Оно и видно.

PS: Забавно, я на тебе уже вторую звезду заработал.

Простой тест - если человек не может прочитать весь код этой библиотеки

Какой ужас, все нужные знания по этой теме можно получить скачав SP-Forth. Сразу понятно станет что такое метапрограммирование, как оно должно выглядеть, и что такое «гибкий язык».

Надо еще протестить случай когда тип и содержимое СУВТ задается не константой, известной на этапе компиляции, а именно в рантайме.

После победы над тем багом я наконец-то могу нормально тестить онлайн-функционал, возможно даже будет клиент Метапрог онлайн на Метапроге.

Надо еще протестить случай когда тип и содержимое СУВТ задается не константой, известной на этапе компиляции, а именно в рантайме.

Ну вот например: https://godbolt.org/z/uZtsHv
Все поля задаются НЕ через константы, а потом еще модифицируются. И никаких дополнительных байтов или проверок.

Только один cmp. Оптимизируется предельно. Чудесно!

cmp только что бы неконстантный argc проверить, а он не входит в СУВТ. Так что ни слова о PyObject! %) arturianec100

Возможен ли подобный уровень оптимизации на каком-нибудь питоне или джаваскрипте?))

все лишнее удаляется - https://godbolt.org/z/jknZv-

https://godbolt.org/z/W3wCgg

Антиметапрогеры как всегда. Метапрог-прототип, версия 6 + будильник на Метапроге (комментарий)

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

Антиметапрогеры

https://i.imgur.com/nsEKiVx.jpg
Антиметапроггеры, фак’йэа!
Камин’ агейн, ту сейф зе м’факин дей’йэа!

Если считаешь что там дикий оверхед, покажи на плюсах тоже самое без оверхеда.

А как же «все лишнее удаляется»? Не удаляется, значит?

А как же «все лишнее удаляется»? Не удаляется, значит?

Зачем ты продолжаешь? Ну мне не сложно... Я писал что удаляется все только если тип компилятору известен, и противопоставлял этому случай когда СУВТ лежат в массиве - Метапрог-прототип 16 + СУВТ по енумам (комментарий)

Тут удалять нечего, это все нужная информация. В такой массив можно положить СУВТ с любым типом, если это массив для одного типа из СУВТ то какой смысл вообще делать массив СУВТ а не интов?

А как же «все лишнее удаляется»? Не удаляется, значит?

Пациент путается в показаниях.

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

А все потому что надо нормальный кодогенератор писать, а не эту СУВТ-шизу.

Пациент путается в показаниях.

Тогда давай код на другом языке, который делает тоже самое, без оверхедов. Я же путаюсь, а не ты лжешь, да?

Вообще мне видится странным подход, в котором все перекладывается на оптимизатор.

А перекладывание задачи по управлению памяти на GC тебя не смущает?

А если я хочу с другими опциями собрать?

Собирай, кто мешает?

Вообще нет никаких гарантий, что лишний код будет удален.

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

Уже даже Atonl признавал что ошибался когда рассказывал сказки о СУВТ, и казалось бы кто будет продолжать эту тему?... Жду когда все опять придет к «СУВТ сделает метапрог медленнее питона».

удаляется все только если тип компилятору известен, и противопоставлял этому случай когда СУВТ лежат в массиве

Вау! Откровение! Если компилятор сумел редуцировать проверки, то их нет. А если не сумел, то есть. Лодку капитану очевидность!

Тут удалять нечего, это все нужная информация.

Ну вообще-то тут только один тип используется. Так что проверки — лишние. Если по каким-то причинам так будет написан критичный к скорости код, то ты теряешь скорость на ровном месте. И более того, ты даже не поймёшь, что ты эту скорость теряешь.

какой смысл вообще делать массив СУВТ а не интов?

Ну кто вас знает. Это же вы тут с ТС’ом зациклились. Из обрывков ответов я видел, что вам по которому разу уже объясняют, что за штуковину вы изобрели, и как характеристики этой штуковины уже всем давно известны, и что она за вас чуда не сотворит. А вы всё упорствуете.

Вау! Откровение!

Не переводи стрелки.

Ну вообще-то тут только один тип используется.

Я дальше написал что подобный массив будет наполнятся неизвестными СУВТ, иначе он не имеет смысла. Если такой массив сделали, значит он должен уметь хранить множество типов. К тому же ведется сравнение с плюсами, а там лучше не сделаешь.

какой смысл вообще делать массив СУВТ а не интов?

Ну кто вас знает.

А причем тут мы? Ты сам пришел, дал пример который я описывал, и теперь говоришь что это я чего то не понял? Серьезно?

Из обрывков ответов я видел, что вам по которому разу уже объясняют, что за штуковину вы изобрели

Да, да, помню эти отрывки «СУВТ сделает метапрог медленнее питона», «кривой аналог PyObject», «там всегда останется union, enum». Но у нас своя позиция.

А причем тут мы?

ТС даже тему назвал в честь своего изобретения. А ты бегаешь и всем пытаешься доказать, что оверхеда нет. Потом, правда, быстро скатываешься до того, что оверхеда хоть и нет, но он не такой уж и большой. И вообще это не важно. У вас свой путь.

ТС даже тему назвал в честь своего изобретения.

А как он должен был назвать? Про Tagged Union он не знал. Да и название нерусское какое то.

А ты бегаешь и всем пытаешься доказать, что оверхеда нет.

Ну так его и нету, я всегда писал «оверхеда нету, все удаляется если тип известен», мне антиметапрогеры писали что это неправда.

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

Так его и нету, мы же с плюсами сравниваем, а там лучше нельзя. Но вообще можно было бы и убрать этот массив из СУВТ заменив на инты по хорошему, если не смотреть на другие языки. Но я никогда и не говорил что массив оптимизируется. Это ты врешь и выдумываешь за меня.

Ну так его и нету

Отрицание

Это ты врешь и выдумываешь за меня.

Гнев.

Так его и нету, мы же с плюсами сравниваем, а там лучше нельзя.

Торг.

Но вообще можно было бы и убрать этот массив из СУВТ заменив на инты по хорошему, если не смотреть на другие языки.

Депрессия и принятие.

i-rinat

Лживый, и ЧСВэшный.

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

Лживый, и ЧСВэшный.

Что ты несёшь?

Подозреваю, что для этого придется от корочки до корочки прочитать талмуды Страуструпа и Александреску, так ведь?

Если бы так просто… Там надо и мануалов сухим языком, и практики, и изучение опытным путём тысячи грабель… Даже liksys плюнул бы на такие простыни со словами «мне нафиг не нужно досконально изучать кресты на уровне главных задротов планеты».

Раньше царь вроде наоборот топил за простоту сишки

Он видел в крестах только Си с классами и vtable, но потом увидел мощь современных крестов, недоступную большинству сишников и плюсовиков.

Хотелось бы лучше понять что именно он хочет сделать

Это невозможно, пока

Я и не претендую на то, что «могу» что-то на плюсах

подозреваю, что в Метапроге я хочу реализовать практически то же самое

Ты много писал про снижение порога входа. Он же – «пацаны осилили кресты, неосиляторы идут мыть полы». Даже без рассуждений про типизацию этого достаточно, чтобы показать разницу в ваших целях.

оно резко снижает порог входа, я тому пример

Для царя это – скриптуха.

Лично мне нравится гибкий синтаксис лиспов и форта, но там я передавал позицию царя.

Повторюсь ещё раз: liksys умнее, чем кажется на первый взгляд. Он давно записал Котечку в тролли. Я же только недавно начал понимать, что он именно что разводит демагогию. Пламенные речи толкает, проигнорировал мою цитату из царской статьи про «если оптимизатор выкидывает - затирание типов остаётся в языке», проигнорировал мой пример на крестах страницу-две назад, облажался кот - а виноват Ринат. Теперь я точно не воспринимаю Котечку всерьёз. Тот же ТС адекватнее – признаёт, что иногда СУВТ не оптимизируется.

Пример, когда в одном контейнере хранится множество значений совсем разных типов и когда ведётся их обработка одной функцией, специализированной для каждого типа, царь приводил. Он однажды писал маленькие оптимизированные программы на boost::hana, там hana::tuple и hana::transform (и не только, там много всего) позволяют всё это делать в компайлтайме без всяких cmp в ассемблере.

struct Fish { std::string name; };
struct Cat  { std::string name; };
struct Dog  { std::string name; };

int main() {
  // Sequences capable of holding heterogeneous objects, and algorithms
  // to manipulate them.
  auto animals = hana::make_tuple(Fish{"Nemo"}, Cat{"Garfield"}, Dog{"Snoopy"});
  auto names = hana::transform(animals, [](auto a) {
    return a.name;
  });
  assert(hana::reverse(names) == hana::make_tuple("Snoopy", "Garfield", "Nemo"));
}

Этот огрызок кода из первого примера показателен – подразумевается, что этот код читает человек, никогда в глаза не видевший эту библиотеку.

switch_ на хане без cmp в результате на произвольно сложном коде тоже в базовых примерах из туториала.

Ну лисп это совсем другое, у форта есть разделитель в виде пробела, и на этом все. Дальше крутись как хочешь %)

проигнорировал мою цитату из царской статьи про «если оптимизатор выкидывает - затирание типов остаётся в языке»

Метапрог-прототип 16 + СУВТ по енумам (комментарий)

Остальное даже комментировать не буду. Жду извинений!

Твой пример кстати можно будет реализовать сразу после добавления в метапрог «цикла по структуре», а оптимизация доведет это все до компилтайма.

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

В С++ всё точно также. Комитет закладывается на то что код будет собираться с максимальными оптимизациями.

Проблема не в «текущих абстракциях», не в «хозяевах», не в «скриптухе», не в «запарте» и не в любой другой шизофазии в этих терминах, все эти писульки на птичьем языке можно свести к вполне простым и лаконичным словам, а именно:

Все чему даны эти новые определения, есть следствия причины ограничений архитектуры по фон нейману, и ограниченности ее реализации в виде вполне конкретного «железа».

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

Все что он может сделать, это придумать еще какую-то абстракцию над вычислителем и просто подменить динамический диспатчинг, диспатчингом компилятором, хотя суть вообще никак не меняется, что то подмена что это, немного разный подход, немного разные выгоды от каждого из них, но суть остается сутью, архитектура имеет ограничения и обойти их не выйдет. Железо не умеет в абстракции, хотя вполне возможно создать аналоги вполне определенных абстракций «железно», но один черт на такие аналоги будут все еще накладываться «железные» ограничения реализации.

Возможно когда-нибудь это ограничение удастся обойти либо «железно» появится вычислитель способный не только исполнять, но и думать, какой-нибудь вычислитель на стыке с биологией. Либо это обойдут «программно» когда некоторая программная надстройка над таким простым железным вычислителем, позволит этой надстройке выступать в качестве «думающего вычислителя», тогда и оперирование типом как некоторой абстракцией, не прибитой гвоздями к конкретной железной реализации станет возможным. В нынешнем мире, таким вычислителем является человек, но его кпд мизерно, банки памяти ограничены, срок службы посредственный.

А в чем причина?

Ставит лукас картинеке «Антиметапрогеры» чет орнул.

Простите котечка, но он увы прав по поводу «депрессии и принятия» ну или придется мериться с избыточностью. А все кивания на другие реализации той же идеи, но более махровые лишь это подтверждают. По сути СУВТ очень прост, поэтому и оверхеды минимальны случаями, но другими случаями проверки получаются избыточными. И вот в попытках избавиться от случаев с избыточными проверками и получится что оверхед в среднем возрастет.

Депрессии и принятия не избежать если такие попытки будут приняты. Нет тут никакой лжи, ни вы ни i-rinat никого не обманываете, просто есть разные реализации разной проработанности и с разными узкими местами но общим списком предъявляемых критериев.

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

Из того что я помню:

1. автор пропозала ranges, говорил что пользуйтесь ranges и не важно что в debug там код будет гораздо хуже чем на циклах for, в release будет такой же.

2. автор пропозала pattern matching(Michael Park), тоже говорил что не важно, что там для реализации pattern matching нужно будет больше сравнений чем в if, в release компилятор всё оптимизирует.

3. член комитета ISO C++ в видосике https://www.youtube.com/watch?v=_qzMpk-22cc говорил не используйте reinterpret_cast, это в 99% путь к UB, используйте вместо этого memcpy и приводил пример кода Кармака с UB. И говорил не бойтесь memcpy, в релизе компилятор всё оптимизирует, и даже все 3 основных компилятора проверил: https://imgur.com/a/4GS3iR0

Снова этот тезис… Царь не видит в этом проблемы, он на лоре с умным видом рассуждал о цпу, о vliw’ах, явно что-то понимает. Опять же, из его тезиса про «могут», которые создают манямирки-загоны-рантаймы скриптухи, как раз единственные, кто учитывают ВСЮ реальность (включая особенности железа). Более того, твой тезис про то, чтобы железо «понимало» абстракции. Ему для его «иситинной статической типизации» совсем не нужно, чтобы железо в рантайме что-то делало с типами. Он же про то, чтобы все типы были только в компайлтайме, а в рантайме выкинуть все типы ради перфоманса. Кроме примитивов уровня инструкций цпу.

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

На самом деле реализовать что-то, о чем он грезит выгоднее как раз через виртуализации, с последующей заменой этой виртуализации. Текущее программирование на шаблонах не разворачивается в инструкции цпy или гпу или любого другого вычислителя. Следовательно надо писать виртуалочку, и пытаться разворачивать в инструкции виртуалочки, а уже потом пытаться реализовать железное исполнение виртуалочки. Это наверное самый чистый путь (и это если опять же не смотреть на то, что это все еще потуги над глупым вычислителем который не понимает абстракций). Другой вопрос может ли это сделать один человек? Очевидный ответ - нет. Поэтому его абстракция поверх будет таким же несостоятельным продуктом как и все что он критикует (с позиции его же самого, или это будет лицемерием, подлогом и святотатством)

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

Чот субъективно воспринимается как дичь какая-то. Хз, как к этому относиться. Почему это хорошо? Почему это плохо?

Это не хорошо и не плохо, это деградация мысли и реализации и закладывание на оптимизаторов и перекладывание ответственности на них же, удобная позиция в общем-то.

По сути СУВТ очень прост, поэтому и оверхеды минимальны случаями, но другими случаями проверки получаются избыточными. И вот в попытках избавиться от случаев с избыточными проверками и получится что оверхед в среднем возрастет.

Ну так покажите мне язык без избыточных проверок, все же просто, только я тут дурачек все ошибаюсь. Покажите мне хотя бы аналог того кода с массивов, но без избыточных проверок. Покажите альтернативу СУВТ.

Вообще какой вы компилтайм ждали при использовании calloc? Это похоже уже на какой то троллинг!

К тому же я писал что массив не будет оптимизироваться. Вы говорите что я не прав, только потому что лжец i-rinat начал приписывать мне выдуманные слова. А на деле я и писал что с массивом не будет все так просто. Я когда ссылку дал на слова о массиве, он скатился до своего бреда с «торг-принятие», то есть ответить ему уже было нечего.

Никакого диссонанса не возникает то?

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

Он еще много чего про меня писал, лживый, и подлый. Не знаю как можно тут занять его сторону.

Вы не дурачок, ну по крайней мере я вас так не называл. Я к тому это и написал, что при усложнении вашего СУВТ и попытке избежать избыточности вы получите тот же оверхед. Или наоборот у вас оверхед будет минимальным, но будут подобные избыточные проверки. Нет тут правых или неправых, есть разная степень проработанности с попытками оптимизации под определенные пункты общих критериев. Хотя ваш вариант возможно если рассматривать его именно вот в таком виде и может оказаться быстрее, эти проверки перекладываются на обычные машинные инструкции (ну хочется в это верить, что компилятор С отоптимизирует как надо) и почти ничего не стоят, в отличии того же питона, где касты между типами уже уровня указателей и объектов, они по сути должны быть куда дороже и медленней, зато и система типов куда более гибкая с другой стороны.

если такие попытки будут приняты.

это слова там не зря.

Мой вопрос следует читать как «какие плюсы и минусы у этого решения».

Вообще какой вы компилтайм ждали при использовании calloc? Это похоже уже на какой то троллинг!

К тому же я писал что массив не будет оптимизироваться.

Так вы решитесь вы про систему типов говорите и СУВТ ваше или про массив.

Вы говорите что я не прав,

кто вы? И нет не говорю, я говорю что гибкость дает оверхед, оптимизация скрадывает гибкость.

только потому что лжец i-rinat начал приписывать мне выдуманные слова.

Даже если это так, они не теряют смысла, о котором я и говорю.

Я к тому это и написал, что при усложнении вашего СУВТ и попытке избежать избыточности вы получите тот же оверхед.

Считаю что enum + union не может быть оверхедом, без него нельзя будет вызвать метод если тип не известен, альтернатива это виртуальные методы, но там тоже нужно хранить таблицу с ними, по любому придется хранить дополнительную информацию, без нее никак в этой реальности.

Без массивов никакие проверки не вызываются, это я выше продемонстрировал.

Так вы решитесь вы про систему типов говорите и СУВТ ваше или про массив.

Я говорю про код i-rinat, там массив из СУВТ который выделяется с помощью calloc.

кто вы?

Ну артуарианец, разк, ликсус.

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