Знатокам С/С++

Кто на ком стоял? Изъясняйтесь понятнее!

https://metanit.com/c/tutorial/2.10.php такого вида?

auto? но это в плюсах. в C23 есть typeof, но я им не пользовался, не в курсе подробностей применения.

Скорее всего он про auto в C++.

например

struct person
{
    char* name;
    int age;
} person_t;

struct hyman
{
    name % person_t.name ;
    age % person_t.age ;
} hyman_t;

auto видел, это не то.
Мне для заголовочных файлов, а не для файлов с реализацией.
вот насчет typeof - надо взглянуть.

Какой-то лютый в говнокод, не выпускай его дальше локалхоста.

Что мешает определить некоторый универсальный тип через typedef или #define?

typedef char* person_name_t;
typedef int   person_age_t;

struct person_t
{
  person_name_t name;
  person_age_t  age;
};

struct human_t
{
  person_name_t name;
  person_age_t  age;
};

В c++ есть decltype

https://en.cppreference.com/w/cpp/language/decltype.html

struct person {
  char* name;
  int age;
};

struct human {
  decltype(person::name) name;
  decltype(person::age) age;
};

struct bot {
  decltype(*person{}.name) name[100500];
  decltype(person{}.age * 100500ul) age;
};

Это что-ли? Это уровень рядового, а не знатока.

Так же и для сишки.

typedef struct {
  char* name;
  int age;
} person;

typedef struct {
  typeof((person){}.name) name;
  typeof((person){}.age) age;
} human;

Есть ли подвижки по этому весьма неплохому «синтаксическому сахару»?

И да, подвижки и сахар есть там, откуда спащено вот это - name % type.name. А в статических языках это базовая фича.

откуда спащено вот это

sql oracle если я правильно помню

P.S. всем спасибо вопрос закрыт.

Будет закрыт, когда отметишь тему решённой.

Что-то с точки зрения чтени кода это нифига не сахар, а напротив

вполне упрощает, если используешь некие структуры из библиотек и не хочешь фиксировать их _текущий_ тип, а типа говоришь «тип тот же что и у структуры такой».

С точки зрения написания кода, плюсы есть, да

Это что ли

https://en.cppreference.com/w/cpp/language/type_alias.html

Да нет, ты что-то перепутал. При написании плюсов как раз не особо есть и int/char* написать проще. А основные плюсы там при чтении.

Во первых, написан не какой-то рандомный int, а тип такой же, как где-то/в заданном выражении - и никаких вопросов «почему именно int» не возникает.

Во вторых, поменять тебе нужно будет только одно место и во всех остальных местах компилятор поменяет типы сам. А иначе тебе придётся вручную выискивать и менять половину из тысячи строк копипасты. Это как бы базовый анти-копипаста аргумент(которая чтение кода усложняет в разы). А так же один из аргументов за вывод типов/полиморфизм.

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

По-нормальному это делается через typedef unsigned int type_name_t; и использование везде только этого именованного типа.

А в твоём способе всё так же останется «рандомный int» в одном месте.

typeof() полезен там где ты не знаешь какой там вообще предполагается тип, а знаешь только название переменной, пришедшей из сторонней библиотеки. Либо для макросов.

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

По-нормальному это делается через typedef unsigned int type_name_t; и использование везде только этого именованного типа.

Неверно. typeof(f(0) * 100500u + g) - выражай через typedef. Тип из либы, о котором ты далее вспомнил, - так же выражай через typedef. Портянка typedef’ов - убирай, у меня этого мусора нет.

Это одна из распространённых проблем - зачем нужна возможность написать напрямую если можно забиндить на имя. Примерно то же самое, что и «чем mask[prev = current++] лучше чем prev = current; current = current + 1; mask[prev]». Куча биндов, нужных только для преодоления неспособности языка/писателя - вот чем лучше. Точнее, отсутствием этой бесполезной кучи.

А в твоём способе всё так же останется «рандомный int» в одном месте.

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

typeof() полезен там где ты не знаешь какой там вообще предполагается тип, а знаешь только название переменной, пришедшей из сторонней библиотеки.

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

Ты не можешь не знать «какой там вообще предполагается тип» в статическом языке - он всегда известен.

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

template <typename T>
void func(T obj) {
    decltype(obj.x) tmp = obj.x;
}

У тебя какая-то каша в голове.

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

шаблонный код

Не, на typedef шаблонный код не пишется, а сравнение шло с ним. До обобщённого кода обсуждение даже близко не дошло. А так да, все рассуждения про «написать тип руками/забиндить тип на имя» в этом случае ломаются окончательно.

Нет, просто у тебя ц89/паскаль/ещё что-то немощное в голове. Поэтому тебе непонятно, как так можно - писать ёмко/без копипасты.

Ты расскажи лучше вот что. Самый элементарный случай для примера:

typedef int age;
typedef char* name;
typedef struct { name name; age age; } person;
typedef struct { name name; age age; } human;

typedef struct { char* name; int age; } person;
typedef struct { typeof((person){}.name) name; typeof((person){}.age) age; } human;

Зачем мне дополнительно простыня биндов, если их можно не писать/читать? Зачем писать/читать то, что можно не писать/читать? Зачем писать/читать больше, если можно писать/читать меньше?

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

Как интересно куда-то потерялся другой абзац, а также поиск тысяч копипасты. Не считается что-ли?

Вот предположите, что вы смотрите на код, в котором используется значение поля объявленного таким образом. Скажите, при сравнении с каким-то другим значением возможно переполнение? Или сравнимы ли значения?

Вот предположите, что вы смотрите на код, в котором используется значение поля объявленного таким образом(type_t val). Скажите, при сравнении с каким-то другим значением возможно переполнение? Или сравнимы ли значения?

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

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

Ты сам не видишь что второй вариант выглядит ужасно?

Да и не только «выглядит», он и логически дефективен. С чего это структура human должна зависеть от person? Если ты хотел сделать наследование то надо было person первым полем human вставить вместо этого дроча с копированием типов. Если у них просто случайно совпали типы полей то очевидно незачем person делать первоисточником этих типов.

Что-то эксперт совсем поплыл, и даже свой тезис про переполнение/сравнение позабыл. Наверное, это тоже не считается. Всё неудобное не считается и вот ты уже эксперт. Крайне сильная позиция.

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

Да. Причём настолько немощное, что ответить нечего. Быть нулём в сравнении с немощным - это пять.

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

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

Кстати, тут эксперт запутался в показаниях.

Вся ваша выдуманная копипаста решается тайпдефом

Если копипаста выдуманная и проблемы нет, что же он собрался «решать» тайпдефом? Типичная картина.

Ты сам не видишь что второй вариант выглядит ужасно?

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

С чего это структура human должна зависеть от person?

С того, что они логически связаны и типы в хумане должны быть такие же, как в персоне. Точно так же, с чего хуман должна зависеть от typedef’ов? Да ни с чего, это внешние предусловия, которые здесь не обсуждаются.

Если ты хотел сделать наследование то надо было person первым полем human вставить вместо этого дроча с копированием типов.

Не, мне не нужно наследование или его подобие. Мне нужны хранить в хумане пару полей как в персоне. Пару полей - это не все.

Если у них просто случайно совпали типы полей то очевидно незачем person делать первоисточником этих типов.

Если случайно совпали, зачем ты предлагал typedef’ать их? Просто напиши int/char* и всё.

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

Хочу того, не знаю чего.

Читать проще первый вариант ИМХО. Особенно, если таких мемберов будет гораздо больше. С другой стороны имеет место быть конечно.

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

Я против имха не возражаю, каждому своё, все дела. Но имох не особо применим в обсуждениях - это не объективно. Вот выше имха не было, а заявка на объективность была. В таком случае уже нужно как-то аргументировать свою позицию, с чем у экспертов в очередной раз как-то не задалось. Это прям рак, сводящий любое обсуждение к клоунаде.

Я против имха не возражаю, каждому своё, все дела. Но имох не особо применим в обсуждениях - это не объективно.

Твое мнение на счет того, что второй вариант читабильнее - это тоже имхо.

Объективно - это например сказать, что один из вариантов короче, потому что там символов меньше.

Неверно. Как-то плохо ты читал тему и даже коммент на который отвечаешь. У меня нет сказок навроде «ухудшает читабельность/выглядит плохо/мне больше нравится» с нулём обоснований. Тезисы и обоснования я выше приводил. Ты и прочие эксперты опровергли хоть что-то из этого? - нет. До тех пор мои тезисы это объективная реальность.

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

А фантазии навроде «все мнения равны/любое мнение имхо» - это ты оставь, то просто оправдания неспособных в аргументацию.

typedef struct { typeof((person){}.name) name; typeof((person){}.age) age; } human;

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

Зачем писать/читать то, что можно не писать/читать? Зачем писать/читать больше, если можно писать/читать меньше?

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

Во-вторых, и это абсолютно объективно, ты написал больше. Вот это:

typeof((person){}.name) name;

name_t name;

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

В Си поскромнее, но есть decltype, в некоторых ситуациях (всякие макросы) помогает.

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

Ой, ну объективный ты наш.

Вот твои «объективные доводы» (часть):

Зачем мне дополнительно простыня биндов, если их можно не писать/читать?

Не понял, какая мысть этого довода. Типа твой вариант короче? (если да, то об этом далее будет).

Зачем писать/читать то, что можно не писать/читать?

Опять таки не указана мысть этого, снова про то, что второй вариант короче?

Зачем писать/читать больше, если можно писать/читать меньше?

Ну это точно про то, что второй вариант короче. Итак!!!! Внимание!!!! Смотрим:

Вариант 1:

typedef int age;
typedef char* name;
typedef struct { name name; age age; } person;
typedef struct { name name; age age; } human;

126 симолов.

Вариант 2:

typedef struct { char* name; int age; } person;
typedef struct { typeof((person){}.name) name; typeof((person){}.age) age; } human;

130 символов.

Да здравствует объективность. Ура!!!

Мало конкретики. Какой C? Какой С++? Что значит в зависимости от переменной?

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

Снова у экспертов ничего, кроме пустых лозунгов.

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

Значит. Комментарии нужны тогда, когда язык/писатель не смог выразить всё что нужно в коде, а далее комментарием описывает недостающее из головы писателя. Как например назначение каждого typedef в простыне. Ты запутался в показаниях.

Во-вторых, и это абсолютно объективно, ты написал больше.

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

В любом случае, про количество символов, которое ничего не значит, никто не говорил. Как и про количество «синтаксических элементов». Меньше элементов семантически независимых/несвязанных. Это будет очень сложно для тебя, но я тебе помогу - начать можно с количества имён.

Так вот, у меня этих лишних имён 0, только имена структурок, которые и так есть по условию. У тебя лишних имён даже в хэлворде 2, а в не-хэлворде будут тысячи.

Не понял, какая мысть этого довода. Типа твой вариант короче?

Да, мой вариант короче.

Опять таки не указана мысть этого, снова про то, что второй вариант короче?

Снова.

Итак!!!! Внимание!!!! Смотрим:

Смотрим.

126 симолов.

130 символов.

Ты даже с этим сел в лужу, поскольку на не-хэлворде будет как минимум так:

typedef int person_age;
typedef char* person_name;
typedef struct { person_name name; person_age age; } person;
typedef struct { person_name name; person_age age; } human;

Это 170 символов. Так же нужно учится считать для начала. А про то, что такое меньше, я написал в ответе предыдущему эксперту.

Да здравствует объективность. Ура!!!

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

sql oracle если я правильно помню

Вот тоже первое, что в голову пришло - это из PL/pgSQL

v_r1 tab1%ROWTYPE;
v_f1 tab2.col9%TYPE;

Хахаха, подкрутил свой пример, чтобы в свою пользу было. Хотя ты конкретно привёл тот код. А тут уже выкручиваться, да?

person_age

person_name

Чего мелочиться то? Давай уже так:

struct_person_member_age_int_type
struct_person_member_name_char_type

А про то, что такое меньше, я написал в ответе предыдущему эксперту.

Даааааа, меньше - это не про количество символов. Тяжелее - это не про массу. Холоднее - это не про температуру. 🤣🤣🤣

Хахаха, подкрутил свой пример, чтобы в свою пользу было. Хотя ты конкретно привёл тот код.А тут уже выкручиваться, да?

Чего мне там выкручиваться. Иди показывай принадлежность name именно к person в том коде. Она должна быть ясна из кода, а не из контекста моего комментария. Как она ясна в моём коде, где ссылка идёт через person.

Просто рандомный name никак к person не относится и своего происхождения из person никак не отражает. person_name тоже не особо относится, но там хотя бы общая часть имени есть.

Про случаи наподобие typedef char* name1; typedef char name2[100]; struct { name1 name; ... }; struct { name2 name; ... }; я тебе даже говорить не буду - слишком сложно для тебя.

Даааааа, меньше - это не про количество символов. Тяжелее - это не про массу. Холоднее - это не про температуру.

Да, не про количество символов. Да, «процесс 1 тяжелее процесса 2» - это не про массу, представляешь. А «холодный старт процесса» - это не про температуру. Но эксперт расскажет что всё не так.

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

Да, братиш. Ты просто кладезь.

Да, братиш. Ты просто кладезь.

Поплыл.

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

Исход очевиден.

Да, ты обосновал как Боженька. Все по факту разобрал 😂😂😂.

убегающих после пары вопросов

Не, ну против такого четкого эксперта конечно не попрешь.

Сдается мне, что вы сейчас самим Царем разговариваете.