Re[5]: так компайл тайм рефлекшину быть 26-й стандарт ?? - C/C++

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, ботаныч, Вы писали:

R>>>Ничего я никуда не увожу, говорю строго по факту того, что говоришь ты.
Б>> уводишь уводишь, я говорю компайл тайм рефлекшине, о чем ты? О памяти ?

R>Ты не говоришь о рефлекшене, ты решил пофлудить в профильном форуме, как тот Шмж.
Ну ты меня сравнил )) Шмж задает детские вопросы по плюсам и вряд-ли поймет мой код )))
И с каких это пор мессаджи с кодом (рабочим) в контексте стали флудом?
Сомневаешься что у меня есть то, что я описал ? https://rsdn.org/forum/cpp/4713560.1

блин посмотри гоьд )))? 23.04.12 13 лет назад жопа. И ты хочешь, чтобы я обошел эту тему .. и промолчал, да оно меня касается экзистенциально. ))

на почитай (скомпилируй = запусти), я на днях проверял этот механизм работает под MSVS (хотя писался под gcc, думаю и там отработает, хотя не проверял). И этот "хак" пользовался и работает уже много лет в разных компиляторах, а ты мне, я помню как-то написал, много лет назад "ну расскажи нам за SFINAE" — ну вот рассказываю. Эта регистрация инкапсулирует все типы в компайл тайм лист. далее еще пару финтов — и CTR с коробки бесплатно — держи. А почему актуально? Потому как вот оно уже в стандарте, т.е если реализовать велосипед сейчас (это с большой долей вероятности даст прорыв в некотрых областях проекта, сериализация, маршалинг, построение всяких клиент сервер систем — аля webservice COM COM+ .. client services на базе dbas etc.) Это я просто описал где я этот код внедрялся в том или ином виде. Даже в языке для искусственного интеллекта — я реализовывал с использованием compile time refliction на базе этого (ну в вариациях)))) от это флуд?))

R>Мне эта пустая болтовня
Пустая ?))) Ну это тебе к комитету, а я говорю, что это переломит во многом ситуацию в отношении языков, что имеют reflection. И в купе с ИИ агентами может здорово разогреть ситуацию в архитектуре

R>не была интересна с самого начала и я не собирался в этом участвовать. Я просто не смог пройти мимо вот этого высказывания:
R>https://rsdn.org/forum/cpp/9068221.1
1. Так яж говорю, тебе похрен CTR
2. тут cjdctv другая точка ))

R>

R>Два двоеточия ("::") — это переход по имени, а '.' — это доступ к свойству

R>Вот и всё. Всё, что я говорил, касалось только вот этих "точек"
рантаймовых точек, а не точек через которые обращаются к метаданным объекта в компайл тайм, что ломает объектную модель С++ с проекцией в реализации на годы еще ... главное, только появилось. Ну ничего время рассудит. Когда начнут появляться обертки аля std::pack_object_to_send(std::extract_meta(obj)) будет понятно кто флудил )

R>- их смысла и сценариев их использования. К тебе я даже не обращался, чего ты прилип как банный лист?
Я прилип?)) ладно давай, ты нормальный мужик, я тоже. мы вполне по-дружески с тобой общались по телефону, чего нам делить ?
обязуюсь каркас ближайшего (если успею) реализации CTR с учетом сегодняшних реалий компиляторов выкласть

Здравствуйте, ботаныч, Вы писали:

Б> Я прилип?)) ладно давай, ты нормальный мужик, я тоже. мы вполне по-дружески с тобой общались по телефону, чего нам делить ?

Без обид

Здравствуйте, ботаныч, Вы писали:

BFE>>Никакая это не ирония. Два двоеточия ("::") — это переход по имени,
Б> странное определение
Оно намерено сделано таким, чтобы не увязнуть в терминологии.

Б>Чего аж вообще не скажешь за оператор точка, который без инстанса (за некоторыми исключениями) рантайма неупотребим.
Именно. И на этом можно сыграть.

BFE>>а '.' — это доступ к свойству (к проперти, говоря на сленге).
Б> В рантайме, если мы говорим о С++, а не абтрактном языке в вакууме.
Правильно. Поэтому логично сделать так же для доступа к свойствам метаобъекта, что существует только в компайл тайме.

BFE>>Как их можно перепутать я представляю с трудом. "компайл-коснт" тут вообще ни причём.
Б> Вы почитайте ответ ИИ (мы с ним во много совпадаем). Что там кто путал я не знаю, просто ваше выражение, аж совсем не про С++.
ИИ всё ещё остаётся слабым, поэтому опираться на его результаты относительно ещё несуществующих понятий не имеет смысла.

BFE>>Нет никакой проблемы в том, чтобы операция доступа к свойствам объекта встречалась в любом контексте.
Б> Это как никаких ? Достаточно написать пару грамматик для языка хотя бы имеющего функциональную полноту по Тьюрингу, чтобы иметь представление о разрешении конфликтов, чтобы понимать никакого "Нет никакой проблемы" в этой сфере не существует. А тут разговор про С++, в котором уже предостаточно контекстно зависимых сегментов. А вы именно, что предлагаете — "всего лишь" переписать язык, и менять концепции.
Это всё общие слова. Давайте конкретный пример, где предложенный доступ ломает синтаксис языка.

BFE>>Вас же не смущает, что в коде можно написать sizeof(int) ? Я не вижу причин, почему всякий sizeof(int) нельзя заменить на выражение int.size.
Б> Да все можно, в пределах разумного, вопрос, кто и сколько времени\денег на это потратит, и когда будет результат.
Это не аргумент.

BFE>>Сейчас, за именем типа не может следовать одна точка (только троеточие), а за именем объекта не может следовать два двоеточия (только одно). Если не согласны — приводите пример.
BFE>>Поэтому нет никаких проблем с тем, чтобы задействовать точку после имени.
Б> Да не )) конечно никаких проблем, только это не про С++
Почему не про С++?

BFE>>Компилятор переписывать не надо, так как добавление точки — это расширение, а не изменение.
Б> жаль я забыл свой промт на который ИИ выдал очень неплохой ответ, но я его почему-то удалил, вместе с промтом. Своими словами что-то вроде за тем, что автор называет "простым и понятным" стоит полное переписывание языка.

Вы что? Доверяете ИИ?

Б>Впрочем я вас уверяю попробуйте реализовать хотя бы метаструктуру
Допустим я это реализовал. Что это изменит?

Здравствуйте, ботаныч, Вы писали:

BFE>>Комитетчики добавили это для метаданных? Нет, они пишут сначала преобразование всего имени в метаобъект, а потом используют сишный (!) доступ к его свойствам:
Б> сишный доступ для компайлтайм звучит как прокрутить фарш обратно
Да, меня от этого подхода тоже коробит.

BFE>>Эта запись должна выглядеть так:
BFE>>E.entities
Б> Шарпофщина какая-то, это там к "вложенным типам" обращаются через точку, в плюсах привычнее с::m
Это не обращение к вложенному типу. Это доступ к свойству типа.

Б> я сомневаюсь, что без наличия под рукой текущий компилятор с тем, чтобы ззаранее проверить какие синтаксические нагрузки надо добавить, что-бы разрешить появляющиеся в нем конфликты. Я так подозреваю, гонка на реализацию рефлекшина стартанула, а там уже подтянется первым ) того и тапки
Ага. Гонят, вместо того, чтобы работать.

BFE>>Далее, template for не нужен.
Б> в gcc часто надо добавлять typename при обращении к вложенному темплиту... using type_ = some_struct::typename calc_some_type<type_arg>::type; а мелкомягких не надо. Вы же говорите об этом, "как вам заблагорассудится", не зная, чем чревато.
Скажите, вас не смущает, что в следующем примере template перед for отсутствует, хотя цикл выполняется во время компиляции?

#include <array>
#include <cstddef>

consteval int sum_upto(int n) {
    int result = 0;
    for (int i = 1; i <= n; ++i) {
        result += i;
    }
    return result;
}

int main() {
    // Вычисляется на этапе компиляции
    constexpr int value = sum_upto(10);
    static_assert(value == 55);
    return value;
}

Б> мне так не кажется, получается, что мы заморачиваемся еще к куче всевозможных кейсам по модификации типов операторами доступа и прочим, что ломает уже существующие парадигмы.
Приведите пример такой парадигмы.

Б>которую вы привели, отражает одну из самых горячих дискуссий в сообществе C++. Это классический конфликт между «прагматичным дизайном» (как это могло бы быть в идеальном новом языке) и «дизайном комитета», скованным обратной совместимостью и необходимостью вписать метапрограммирование в существующую грамматику.
Б>Вот несколько тезисов в ответ на этот разбор:
Б>1. Синтаксис ^E vs E.entities
Б>Автор прав: запись E.entities выглядит естественнее. Однако в C++ точка (.) зарезервирована для доступа к членам объекта. Если разрешить E.entities, где E — тип, возникает неоднозначность с static полями.
Это не так. Нет такого конфликта. Приведите пример, если думаете иначе. Однако "Автор прав"

Б>Комитет выбрал оператор отражения ^ (reflection operator), чтобы четко разграничить: «сейчас мы работаем не с типом, а с его метаданным описанием». Это позволяет избежать перегрузки парсера, но, безусловно, выглядит «инородно».
С++ не для слабаков. Да.

Б>2. Сплайсинг [:e:] и метаобъекты
Б>Автор утверждает, что e.value достаточно. Но в текущем черновике рефлексии (P2996) e — это не сам объект, а «дескриптор» (handle) метаобъекта.
Б>Сплайсинг ([:e:]) — это мост из мира метаданных обратно в мир кода.
Б>Без явного сплайсинга компилятору было бы крайне сложно понять, когда вы хотите получить свойство метаобъекта, а когда — превратить метаобъект в реальное выражение (expression), которое можно использовать в коде.
Если слева от точки стоит тип, то это обращение к метаобъекту, если слева от точки стоит имя переменной, то это обращение с свойству переменной. Что тут сложного?

Б>3. template for vs обычный for
Б>Здесь автор затронул фундаментальную проблему. Обычный for в C++ порождает цикл в рантайме. Чтобы превратить итерацию по метаданным в развернутый код (unrolling) или генерацию разных типов на каждой итерации, нужен специальный маркер.
Б>Если оставить обычный for, компилятору придется проводить сложнейший анализ, чтобы понять: «ага, это цикл по константам, я должен его развернуть».
Б>template for явно говорит: «это генерация кода». Это делает поведение предсказуемым.
См. пример выше.

Б>4. consteval vs constexpr
Б>Автор абсолютно прав в том, что функции, работающие исключительно с метаданными, должны быть consteval. В C++20/23 constexpr функция может быть вызвана в рантайме, а рефлексия в рантайме невозможна. Использование consteval здесь — это не просто хороший тон, а гарантия того, что код не «протечет» в исполняемый файл.
Автор уже "абсолютно прав"

Б>5. Философский вопрос: Революция или Эволюция?
Б>Критика про «монструозную химеру» обоснована. C++ пытается внедрить мощнейшую систему метапрограммирования, не ломая парсеры, написанные 30 лет назад.
Б>Подход автора (в стиле C# или Swift) требует полной переработки модели типов.
Б>Подход комитета — это попытка дать программисту «низкоуровневый ассемблер для типов». Это мощно, но страшно на вид.
Б>Итог
Б>Предложенный автором вариант (E.entities, e.value) — это путь языка с сильной встроенной интроспекцией (как Zig или частично Rust). Путь C++ — это путь библиотечного метапрограммирования, где через страшные символы (^, [: :]) даются фундаментальные возможности, на которых потом напишут красивые обертки.
Б>Согласны ли вы с тем, что C++ стоило бы пожертвовать совместимостью ради чистоты синтаксиса, или гибкость текущего (пусть и сложного) подхода важнее?
Б>[/q]
Б> Оно там вопрос задает, ..
Удивительное рядом.
Где, опять же, жертвенность? В чём она? Это же бред ИИ.
Что же касается "красивых оберток", то покажите мне красивую обёртку вокруг std::filesystem или для std::condition_variable, хотя бы.

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

Здравствуйте, rg45, Вы писали:

BFE>>Два двоеточия ("::") — это переход по имени, а '.' — это доступ к свойству (к проперти, говоря на сленге).
R>Ну начинаются удивительные истории.
Что тут удивительного? Впрочем, это дело вкуса.

Вам правда вот этот синтаксис
auto minVal = std::numeric_limits<std::underlying_type_t<E>>::max();
std::meta::enumerators_of(^E)
нравится больше этого:
auto minVal = E.underlying_type.max_value;
E.entities
?
Или есть какое-то ещё предложение?

Здравствуйте, B0FEE664, Вы писали:

BFE>>>Два двоеточия ("::") — это переход по имени, а '.' — это доступ к свойству (к проперти, говоря на сленге).
R>>Ну начинаются удивительные истории.
BFE>Что тут удивительного? Впрочем, это дело вкуса.

BFE>Вам правда вот этот синтаксис
BFE>auto minVal = std::numeric_limits<std::underlying_type_t<E>>::max();
BFE>std::meta::enumerators_of(^E)
BFE>нравится больше этого:
BFE>auto minVal = E.underlying_type.max_value;
BFE>E.entities
BFE>?
BFE>Или есть какое-то ещё предложение?

Я не готов дискутировть по поводу синтаксиса компайл-тайм рефлексии, я же писал. Просто не успел ещё выработать мнения. Чтоб это мнение выработать, нужно с этим поработать. А вот такое вольное жонглирование терминами в отношении операторов '::' и '.' ("переход по имени", "доступ к свойству") мне не понравилось, вот об этом я и высказался. И только об этом.

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, ботаныч, Вы писали:

BFE>>>Комитетчики добавили это для метаданных? Нет, они пишут сначала преобразование всего имени в метаобъект, а потом используют сишный (!) доступ к его свойствам:
Б>> сишный доступ для компайлтайм звучит как прокрутить фарш обратно
BFE>Да, меня от этого подхода тоже коробит.
это не сишный вызов, этор метаметод в с++;

BFE>>>Эта запись должна выглядеть так:
BFE>>>E.entities
Б>> Шарпофщина какая-то, это там к "вложенным типам" обращаются через точку, в плюсах привычнее с::m
BFE>Это не обращение к вложенному типу. Это доступ к свойству типа.
Ага )) https://onlinegdb.com/8pjntt4PN

#include <stdio.h>

struct SomeIdentifier {}; 

constexpr int IsBool()
{
    struct SomeIdentifier1 { enum { entity = 5}; };
    SomeIdentifier1 SomeIdentifier;
    return SomeIdentifier.entity;
}

//просто Это не доля слабаков. 

int main()
{
    return IsBool();
}

BFE>Ага. Гонят, вместо того, чтобы работать.
"Ага", это у вас ... про блин спать хочу.

BFE>>>Далее, template for не нужен.
)) вы пытаетесь играть в Чепаева там, где играют в шахматы.

Б>> в gcc часто надо добавлять typename при обращении к вложенному темплиту... using type_ = some_struct::typename calc_some_type<type_arg>::type; а мелкомягких не надо. Вы же говорите об этом, "как вам заблагорассудится", не зная, чем чревато.
BFE>Скажите, вас не смущает, что в следующем примере template перед for отсутствует, хотя цикл выполняется во время компиляции?
Я пропускаю этот код не относящийся к теме, сорри. Меня не смущает.

BFE>Приведите пример такой парадигмы.
А я привел, смотрите выше, вам моих велосипедов еще подкинуть ? Мнее минимализм комитета вообще понятен. Вы же должны помнить как появлялся новый стандарт std ? Просто скопировали бустовые велосипеды, ну вот примерно так-же мне и понятен сбор меты и его использование. А появление оного в стандарте вызывает у меня, просто ... я вообще думал тут праздник начнется с фейерверками )) ну ниче ща я даже песенку по этому поводу заброшу ) https://youtu.be/ttQHl1VsqFw
..

Б>>которую вы привели, отражает одну из самых горячих дискуссий в сообществе C++. Это классический конфликт между «прагматичным дизайном» (как это могло бы быть в идеальном новом языке) и «дизайном комитета», скованным обратной совместимостью и необходимостью вписать метапрограммирование в существующую грамматику.
Б>>Вот несколько тезисов в ответ на этот разбор:
Б>>1. Синтаксис ^E vs E.entities
Б>>Автор прав: запись E.entities выглядит естественнее. Однако в C++ точка (.) зарезервирована для доступа к членам объекта. Если разрешить E.entities, где E — тип, возникает неоднозначность с static полями.

BFE>Это не так. Нет такого конфликта. Приведите пример, если думаете иначе. Однако "Автор прав"
конечно нет ))) вообще в грамматиках если че поменяешь конфликтов нет... ))!! браво!!!

Б>>Комитет выбрал оператор отражения ^ (reflection operator), чтобы четко разграничить: «сейчас мы работаем не с типом, а с его метаданным описанием». Это позволяет избежать перегрузки парсера, но, безусловно, выглядит «инородно».
BFE>С++ не для слабаков. Да.
можно просто улыбнуться )) жду велосипеда по CTR, или грамматику языка с полнотой по Тьюрингу. )

Б>>2. Сплайсинг [:e:] и метаобъекты
Б>>Автор утверждает, что e.value достаточно. Но в текущем черновике рефлексии (P2996) e — это не сам объект, а «дескриптор» (handle) метаобъекта.
Б>>Сплайсинг ([:e:]) — это мост из мира метаданных обратно в мир кода.
Б>>Без явного сплайсинга компилятору было бы крайне сложно понять, когда вы хотите получить свойство метаобъекта, а когда — превратить метаобъект в реальное выражение (expression), которое можно использовать в коде.
BFE>Если слева от точки стоит тип, то это обращение к метаобъекту, если слева от точки стоит имя переменной, то это обращение с свойству переменной. Что тут сложного?
см на пример выше. вы когда грамматически обоснуете, чи там переменная, или тип, или другой типа в скоупе ... напишите грамматику, и будет с вас. )) а мне уже влом отвечать. я видите ли контекстно зависимые синтаксические выражения нюхом чую.

Б>>3. template for vs обычный for
Б>>Здесь автор затронул фундаментальную проблему. Обычный for в C++ порождает цикл в рантайме. Чтобы превратить итерацию по метаданным в развернутый код (unrolling) или генерацию разных типов на каждой итерации, нужен специальный маркер.
Б>>Если оставить обычный for, компилятору придется проводить сложнейший анализ, чтобы понять: «ага, это цикл по константам, я должен его развернуть».
Б>>template for явно говорит: «это генерация кода». Это делает поведение предсказуемым.
BFE>См. пример выше.
см ответ про typename перед дочерним типом | выражением | etc ... в gcc. Эта синтаксическая нагрузка меня не беспокоит аж совсем. Вас беспокоит ? В бой )) против комитета ... ) Можем обсудить, что такое стандарт, как появляется ... кстати тут в тему пойдет, экспорт шаблонов реализованный в EDG, но не вошедший в стандарт.

Б>>4. consteval vs constexpr
Б>>Автор абсолютно прав в том, что функции, работающие исключительно с метаданными, должны быть consteval. В C++20/23 constexpr функция может быть вызвана в рантайме, а рефлексия в рантайме невозможна. Использование consteval здесь — это не просто хороший тон, а гарантия того, что код не «протечет» в исполняемый файл.
BFE>Автор уже "абсолютно прав"
это вас по голове погладили, сказав перед тем, что вы предлагаете сломать объектную модель.

Б>>5. Философский вопрос: Революция или Эволюция?
Б>>Критика про «монструозную химеру» обоснована. C++ пытается внедрить мощнейшую систему метапрограммирования, не ломая парсеры, написанные 30 лет назад.
Б>>Подход автора (в стиле C# или Swift) требует полной переработки модели типов.
Б>>Подход комитета — это попытка дать программисту «низкоуровневый ассемблер для типов». Это мощно, но страшно на вид.
Б>>Итог
Б>>Предложенный автором вариант (E.entities, e.value) — это путь языка с сильной встроенной интроспекцией (как Zig или частично Rust). Путь C++ — это путь библиотечного метапрограммирования, где через страшные символы (^, [: :]) даются фундаментальные возможности, на которых потом напишут красивые обертки.
Б>>Согласны ли вы с тем, что C++ стоило бы пожертвовать совместимостью ради чистоты синтаксиса, или гибкость текущего (пусть и сложного) подхода важнее?
Б>>[/q]
Б>> Оно там вопрос задает, ..
BFE>Удивительное рядом.
BFE>Где, опять же, жертвенность? В чём она? Это же бред ИИ.
BFE>Что же касается "красивых оберток", то покажите мне красивую обёртку вокруг std::filesystem
Вообще без проблем шо вам написать ? сколько тенге?

BFE>или для std::condition_variable, хотя бы.
))) я бесплатно код не пишу, только музыку .. (сакс, гитара, фано контпробасс.. etc) ..
да вот правда сорри на телефон писал, могу сыграть так, что ушки завернутся
https://youtu.be/ttQHl1VsqFw

Б>>На счет вашей надежды, что оно завязнет. посмотрим, есть надежда (вполне ощутимые), когда начнут появляться хибернейты, когда реляционные структуры с запросами в SQL с проверкой на этапе компиляции, регекспы с встраеваемыми объектами в запрос ...
BFE>Да нет у меня никакой "надежды". Первый раз, что ли, комитет занимается фигнёй, которой никто не будет пользоваться? Вспомните, хотя бы, про спецификацию исключений.
))) какбы так описать, ну не сделает комитет, я буду продолжать зарабатывать на велосипедах (и скрещу в солюшинах с ИИ), сделает ... будет еще интереснее скрещу стандарт с ИИ )) вам что написать?))). ой сколько у меня этих велосипедов, что упрощали мне жизнь, и создавали syntax barier, за которым жилось вполне комфортно в realisation time. у таких как я видите-ли, винвин.

	От:	rg45
	Дата:	25.03.26 15:15
	Оценка:

От:	ботаныч	https://youtu.be/I3lhN5CUP2M
Дата:	25.03.26 19:06
Оценка:

	От:	rg45
	Дата:	25.03.26 20:22
	Оценка:	+1

	От:	B0FEE664
	Дата:	25.03.26 20:35
	Оценка:

	От:	B0FEE664
	Дата:	25.03.26 21:31
	Оценка: