Re[10]: так компайл тайм рефлекшину быть 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. у таких как я видите-ли, винвин.

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

Б> это не сишный вызов, этор метаметод в с++;
А почему он выглядит как вызов сишной функции?

	Скрытый текст
	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>>>>Далее, template for не нужен.
Б> )) вы пытаетесь играть в Чепаева там, где играют в шахматы.
Да ну? Зачем template, если и без него всё получилось? Переусложнение ради выпендрёжа.

Б> Я пропускаю этот код не относящийся к теме, сорри. Меня не смущает.
Извинения не принимаются.

BFE>>Приведите пример такой парадигмы.
Б> А я привел, смотрите выше, вам моих велосипедов еще подкинуть ?
И вы это называете парадигмой?

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

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

Б> я видите ли контекстно зависимые синтаксические выражения нюхом чую.
То есть в шахматы вы тоже чисто на интуиции? Да?

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

Б> это вас по голове погладили, сказав перед тем, что вы предлагаете сломать объектную модель.
В каком месте сломать? Вот что конкретно ломается?

BFE>>Что же касается "красивых оберток", то покажите мне красивую обёртку вокруг std::filesystem
Б> Вообще без проблем шо вам написать ? сколько тенге?
Не надо мне ничего писать, просто укажите на красивые обёртки вокруг std::filesystem или std::condition_variable. Ведь ИИ утверждают, что их пишут. Если это правда, то нет никакого труда указать на парочку красивых, уже написанных.

Б> ))) какбы так описать, ну не сделает комитет, я буду продолжать зарабатывать на велосипедах (и скрещу в солюшинах с ИИ), сделает ... будет еще интереснее скрещу стандарт с ИИ )) вам что написать?))). ой сколько у меня этих велосипедов, что упрощали мне жизнь, и создавали syntax barier, за которым жилось вполне комфортно в realisation time. у таких как я видите-ли, винвин.
Тогда зачем о сроках интересуетесь?

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

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

Б>> это не сишный вызов, этор метаметод в с++;
BFE>А почему он выглядит как вызов сишной функции?
так boost::bind тоже выглядит как "сишная".. но вы посмотрите на сигнатуру.

Б>>//просто Это не доля слабаков.
BFE>Действительно.
Ага, не слабак. ну скажите а как эта "штука" https://rsdn.org/Forum/?fuid=91523 работает.
Кстати там, тоже "сишный" вид hl::print_type<typename hl::export_to_list<cutlets>::type >(); ))

BFE>Не все могут отличить тип от объекта.
Да не все могут понять, что вести дискуссию про синтаксис когда под рукой нет грамматик. А комитетчики обсуждают там, куда больше 1-2-х, они ткскть ищуит золотую средину, чтобы минимизировать риски для раработчиков компиляторов всех стран )).

BFE>Вот пример здесь,
пример вообще ниочем, и к теме отношения не имеет. Но спасибо за аргумент против себя ) прктически автогол.

BFE>который (без всякой рефлексии) авторы компиляторов компилируют в меру своего прочтения стандарта. А ваш пример довольно простой и однозначный. К обсуждаемому вопросу имеет весьма опосредствованное отношение. Какое отношение правила поиска имени имеет к рефлексии? Их менять не потребуется.
Не ну я вам более интересный пример привел, с template <auto... Dat> struct Meta;

BFE>>>>>Далее, template for не нужен.
Б>> )) вы пытаетесь играть в Чепаева там, где играют в шахматы.
BFE>Да ну? Зачем template, если и без него всё получилось? Переусложнение ради выпендрёжа.
Складывается ощущение, что вы читаете только себя. Я намекал на наличие typename в бустах нечто NESTED_TYPENAME есть почему? Комитет занимается поиском минимизированных (и слава Богу) решений.

Б>> Я пропускаю этот код не относящийся к теме, сорри. Меня не смущает.
BFE>Извинения не принимаются.
Извините, но мне побарабану.

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

BFE>>>Это не так. Нет такого конфликта. Приведите пример, если думаете иначе. Однако "Автор прав"
Б>> конечно нет ))) вообще в грамматиках если че поменяешь конфликтов нет... ))!! браво!!!
BFE>Давайте. Покажите на примере.
Что показать на примере?
У вас есть точка после типа? В С++? — проиллюстрируйте. Вам прямо в комитет дорога,
Даже если каким-то чудом вы там окажетесь, знаю что вам ответят — хотите точку ? Хотите дальше )

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

Б>> вы когда грамматически обоснуете, чи там переменная, или тип, или другой типа в скоупе ... напишите грамматику, и будет с вас. )) а мне уже влом отвечать.
BFE>То есть вы хотите сказать, что если в С++ справа от имени поставить точку, то имя автоматически становится именем объекта? Так? Ведь другого способа отличить имя объекта от имени типа нет?
Я там спросоня, после довольно жесткой дискуссии с rg45 пытался привести контекстнозависимые выражения, .. но сорри пошел спать) поздно было и весел я не был. А вообще зачем точка после типа, если сейчас уже там есть ::? Зачем? По-выпендриваться?

BFE>То есть в шахматы вы тоже чисто на интуиции? Да?
Ну скажем, я не силен, так чтобы совсем .. но обыграв коллегу, которого мастер спорта тренировал, услышал в свой адрес — игра со слабой дебютной подготовкой. Да я слабо знаю дебюты, впрочем как и нотную грамоту, но сыграю .. ушки заверутся
)

Б>> см ответ про typename
BFE>Причём он тут?
А притом, что на наличие его можно тоже по-возмущаться )) Зачем он там, если и так понятно, что там должен быть тип. Но ) это компиляторостроение, а не танцы для девочек.
BFE>И что с этим зависимым именем? Если явно указали typename, значит получили тип, значит можно type_.entities; В чём вопрос-то?
Вы хотите точку ? Хотите дальше, больше скажу, я не могу ответить себе на вопрос зачем?

BFE>В каком месте сломать? Вот что конкретно ломается?
Да что там, велкам в комитет, вас внимательно прослушают, думаю совсем недолго. Хотите точку справа от типа? — Хотите дальше.

BFE>Не надо мне ничего писать, просто укажите на красивые обёртки вокруг std::filesystem или std::condition_variable. Ведь ИИ утверждают, что их пишут. Если это правда, то нет никакого труда указать на парочку красивых, уже написанных.
Меня устраивает std::filesystem чем он не устраивает вас? это 1. а 2. Вы переходите от языка к фреймворкам, реализуйте свой.

BFE>Тогда зачем о сроках интересуетесь?
А вот когда состоится, поговорим ) уже с обертками.

	От:	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
	Оценка: