Re[72]: Когда это наконец станет defined behavior? - C/C++

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

S>Да ознакомьтесь вы уже наконец с матчастью! Вам от незнания константы мерещатся там, где их нет, что приводит к дурацким утверждениям с вашей стороны, комментировать которые цензурно уже просто невозможно.
Вы в защиту плюсового const приводите странный код, который показывает незнание матчасти других ЯП. Когда я перевожу идентичный код на разных ЯП, у вас подгорает.

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

S>>Да ознакомьтесь вы уже наконец с матчастью! Вам от незнания константы мерещатся там, где их нет, что приводит к дурацким утверждениям с вашей стороны, комментировать которые цензурно уже просто невозможно.
·>Вы в защиту плюсового const приводите странный код, который показывает незнание матчасти других ЯП.

Я здесь привел, помнится, всего один пример кода на Java, к которому претензий не было.

Вы же мало того, что демонстрируете незнание C++ о котором пытаетесь рассуждать, так еще и не способны прочитать то, что вам пишут: вы увидели константность там, где ее нет.

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

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

S>·>Вы в защиту плюсового const приводите странный код, который показывает незнание матчасти других ЯП.
S>Я здесь привел, помнится, всего один пример кода на Java, к которому претензий не было.
Не понял почему к коду на Java у меня должны были быть претензии. Претензии у меня к const. То что вы не понимаете какой код на других ЯП без const соответствует какому плюсововому коду с const — это ваше незнание матчасти других ЯП, а не моё незнание плюсов.

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

S>Вы же мало того, что демонстрируете незнание C++ о котором пытаетесь рассуждать, так еще и не способны прочитать то, что вам пишут: вы увидели константность там, где ее нет.
Я увидел то, что вы показали и просто перевёл с языка на язык.

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

·>Вы даже не понимаете разницу между иммутабельностью и константностью и собирались первое выражать через второе — пробел знания

И это говорит поциент, который не может объяснить схерали o.getX() должен относиться с состоянию объекта o...

> теоретической матчасти.

Какое прекрасное словосочетание. Интересно, а давно "мат" в "матчасти" стало означать что-то отличное от "материальной"?

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

s> ·>Вы даже не понимаете разницу между иммутабельностью и константностью и собирались первое выражать через второе — пробел знания
s> И это говорит поциент, который не может объяснить схерали o.getX() должен относиться с состоянию объекта o...

Я объяснил, ты не понял, потому что проблемы в:
s> > теоретической матчасти.
А так как никаких вопросов/комментарием больше не последовало, я сделал вывод, что желания узнать у тебя и нет.

s> Какое прекрасное словосочетание. Интересно, а давно "мат" в "матчасти" стало означать что-то отличное от "материальной"?

У тебя ещё и по матчасти русского языка пробелы. Раз тебе так интересно, отвечу, хоть и оффтоп. Оно стало означать немного другое с тех пор, как "учи матчасть" перешло из армейской терминологии в устойчивое словосочетание (афаир благодаря какому-то фильму) и интернет-жаргон. Некий аналог английского RTFM.
И "матчасть" тут означает "базовые, элементарные знания". Т.е. "теоретическая матчасть" буквально означает "базовые знания теории".

avalon/3.0.0

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

·>Я объяснил

Нет. Хинт: даже если объект иммутабельный, ничто не обязывает его getX возвращать хоть что-то связанное с его состоянием.

·>А так как никаких вопросов/комментарием больше не последовало

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

·>Некий аналог английского RTFM.

RTFM -- это про изучение теории?

Это про изучение инструкций к инструменту, т.е. про изучение инструмента, т.е. в точности как "учи матчасть".

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

S>Хуже

S>https://habr.com/ru/articles/722668/
S>https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0847r7.html
S>

template <typename T>
S>class optional {
S>  // ...
S>  template <typename Self>
S>  constexpr auto operator->(this Self&& self) {
S>    return addressof(self.m_value);
S>  }
S>  // ...
S>};
S>

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


struct B
{
    template<class T> void vfun(T t) { std::cout << t << '\n'; }
    template <typename Self, class T> void f1(this Self&& self, T t) { self.vfun(t); }
};

struct D: B 
{
    template<class T> void vfun(T t) { std::cout << "D:t=" << t << '\n'; }
};

struct C: B 
{
    template<class T> void vfun(T t) { std::cout << "C:t=" << t << '\n'; }
};

int main()
{
    D d{};
    C c{};
    B* pb = &d;
    pb->f1(1);      // output D:t=1 ?
    pb = &c;
    pb->f1("asdf"); // output C:t=asdf ?
    return 0;
}

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

BFE>Правильно ли я понимаю, что следующий код будет валидным и по сути это будут эмуляция шаблонных виртуальных функций?:

Попробовал с VC++ 19.35.32217.1 и получил вот такой результат:

1
asdf

Т.е., нет, шаблонные методы виртуальными не стали. Что, имхо, ожидаемо.

Пробовал на godbolt с trunk-версиями GCC и Clang, но они, как я понял, еще deducing this не поддерживают

(либо я не смог правильные ключики им передать, хотя -std=c++23 указывал).

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

BFE>>Правильно ли я понимаю, что следующий код будет валидным и по сути это будут эмуляция шаблонных виртуальных функций?:
S>Попробовал с VC++ 19.35.32217.1 и получил вот такой результат:
S>

S>1
S>asdf
S>

Не, ну так не интересно! При вызове в шаблон подставляется тип переменной, а не тип объекта.

S>Т.е., нет, шаблонные методы виртуальными не стали. Что, имхо, ожидаемо.
Ну да... Ничего по настоящему нового не добавляют.

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

BFE>При вызове в шаблон подставляется тип переменной, а не тип объекта.

Так там от шаблона только синтаксис, а (как по мне) шаблоном это назвать сложно.

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

_>Более того раз это очевидно это может делать компилятор.
А если это не очевидно — то тогда как?

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

_>>Более того раз это очевидно это может делать компилятор.
BFE>А если это не очевидно — то тогда как?

Как обычно: отделяются котлеты от мух. Описание данных, представление, ограничения, алгоритм, порядок выполнения и инварианты должны описываться отдельно, а не смешиваться в кучу.
Надо описывать так что бы было удобно писать и читать, а компилятору было очевидно какие преобразования допустимы, а не строить домыслы на ложных предпосылках. И не вводить всякие pointer provenance и другие не чуждые понятия.
Более того я бы ввел помимо компиляции еще и стадию синтеза кода, вместо этих ваших метапрограммирований. Что бы можно было явно итерационно преобразовывать код.
Короче C++ для этих целей не подходит, т.к. он развивается в сторону усложнения, не давая ничего нового даже немного вредя.

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

_>Короче C++ для этих целей не подходит, т.к. он развивается в сторону усложнения, не давая ничего нового даже немного вредя.

что взамен?

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

_>>Короче C++ для этих целей не подходит, т.к. он развивается в сторону усложнения, не давая ничего нового даже немного вредя.

NB>что взамен?
Возврат к истокам, надстройки над платформо-независимым ассемблером.

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

NB>>что взамен?
_>Возврат к истокам, надстройки над платформо-независимым ассемблером.

названия?
не слишком низкоуровнево/многословно?

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

NB>названия?
Какие вам нужны названия?
NB>не слишком низкоуровнево/многословно?
Уровней может быть много. С чего вы взяли что будет многословно?
И да лучше пуcть будут длинные, но понятные, конструкции как vhdl чтобы можно было спокойно найти их поиском чем то что делают в swift, превращая его в инопланетянский язык.

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

NB>>названия?
_>Какие вам нужны названия?

готовые реализации. что гуглить.

NB>>не слишком низкоуровнево/многословно?
_>Уровней может быть много. С чего вы взяли что будет многословно?

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

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

NB>готовые реализации. что гуглить.
Отделение алгоритма от порядка исполнения: https://people.csail.mit.edu/jrk/halide12/halide12.pdf
Платформо-независимых ассемблеров много: LLVM IR, JVM, IL, C, JS, WebAssembly ...
Отделением данных от представления все занимаются постоянно особенно при передачи данных по сети или при попытках по максимуму использовать кэш.
Синтезом кода занимаются jit, а декларативные языки типа sql строят план выполнения.

NB>пока не совсем понятно, как это будет выглядеть на практике.
Если вы хотите узнать как это будет на практике практикуйте. Пока синтез кода встраивают в ide и то для языков попроще чем c++. Следующий шаг это copilot, но это путь в сторону потери контроля над происходящим. Языках типа CSharp java есть синтез кода, но он не удобен для анализа и требует много приседаний.
NB>а так в целом я тоже за все хорошее, против всего плохого.
Так кто вам сказал что есть готовое. Что бы оно появилось надо что бы умерло множество неудачных прототипов.
Я лично экспериментирую с+lua не сказать что прям что-то грандиозное, но прикольно (некоторые задачи решаются очень элегантно).

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

NB>>готовые реализации. что гуглить.
_>Отделение алгоритма от порядка исполнения: https://people.csail.mit.edu/jrk/halide12/halide12.pdf
_>Платформо-независимых ассемблеров много: LLVM IR, JVM, IL, C, JS, WebAssembly ...
_>Отделением данных от представления все занимаются постоянно особенно при передачи данных по сети или при попытках по максимуму использовать кэш.
_>Синтезом кода занимаются jit, а декларативные языки типа sql строят план выполнения.

иными словами, основная мысль, "выкиньте c++ и используйте dsl"?
мысль не новая, но пока какого-то массированного применения дсл для решения общих задач почему-то не наблюдается

NB>>пока не совсем понятно, как это будет выглядеть на практике.
_>Если вы хотите узнать как это будет на практике практикуйте. Пока синтез кода встраивают в ide и то для языков попроще чем c++. Следующий шаг это copilot, но это путь в сторону потери контроля над происходящим. Языках типа CSharp java есть синтез кода, но он не удобен для анализа и требует много приседаний.

это сразу в топку.

NB>>а так в целом я тоже за все хорошее, против всего плохого.
_>Так кто вам сказал что есть готовое. Что бы оно появилось надо что бы умерло множество неудачных прототипов.
_>Я лично экспериментирую с+lua не сказать что прям что-то грандиозное, но прикольно (некоторые задачи решаются очень элегантно).

не совсем понял, это написано "си и луа", или "экспериментирую с" +lua
если первое то тоже довольно старая комбинация, но на замену c++ никак не тянет

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

BFE>>При вызове в шаблон подставляется тип переменной, а не тип объекта.

S>Так там от шаблона только синтаксис, а (как по мне) шаблоном это назвать сложно.
Не, согласно пропазлу, это должен быть именно шаблон:

struct B
{
    template<class T> void vfun(T t) { std::cout << t << '\n'; }
    template <typename Self, class T> void f1(this Self&& self, T t) { self.vfun(t); }
};

struct D: B 
{
    template<class T> void vfun(T t) { std::cout << "D:t=" << t << '\n'; }
};

struct C: B 
{
    template<class T> void vfun(T t) { std::cout << "C:t=" << t << '\n'; }
};

int main()
{
    D d{};
    C c{};
    B* pb = &d;
    d.f1(1);        // обязан вывести D:t=1 
    pb->f1(1);      // output: 1 :(
    pb = &c;
    pb->f1("asdf"); // output: asdf  :(
    c.f1("asdf");   // обязан вывести C:t=asdf
    return 0;
}

я пока проверить не могу.

К тому же согласно пропазлу синтаксис не обязан быть шаблонным:

struct X {
  // explicit object has type X&
  void foo(this X&);

  // explicit object has type X const&
  void foo(this X const&);

  // explicit object has type X&&
  void bar(this X&&);
};

	От:	·
	Дата:	17.05.23 15:26
	Оценка:

От:	so5team	https://stiffstream.com
Дата:	17.05.23 16:14
Оценка:

	От:	·
	Дата:	17.05.23 16:30
	Оценка:

От:	so5team	https://stiffstream.com
Дата:	17.05.23 16:54
Оценка:

	От:	·
	Дата:	18.05.23 08:14
	Оценка:

	От:	B0FEE664
	Дата:	22.05.23 14:38
	Оценка:

	От:	B0FEE664
	Дата:	23.05.23 09:47
	Оценка:

	От:	B0FEE664
	Дата:	23.05.23 10:02
	Оценка:

	От:	kov_serg
	Дата:	23.05.23 10:20
	Оценка: