offsetof() без UB - C/C++

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

_>>Пока думаешь. Я говорю примерно про такое

R>Да идею-то я понял. Я не понимаю, каким образом тебе мешает то, что выражение &D::a имеет тип int A::*. Что для тебя изменилось бы, если бы тип был int D:*?

Еще вариант где мешает. Если бы был int D::* то

  int* (*p1)(D*)=ptr_to<&D::a>; // я бы мог писать так
  int* (*p2)(A*)=ptr_to<&D::a>; // а пиходится так

То есть что бы работало в общем виде придётся писать ptr_to<D,&D::a>

ps: И тогда можно вместо offset спокойно использовать этот указатель, при желании преобразовав его в intptr_t

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

_>Очень просто это мешает единообразно вычислять смещение от начала класса D т.к. указатель приводится к классу A. То есть придётся еще дополнительно явно указывать класс D.

Теперь понял.

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

_>Еще вариант где мешает. Если бы был int D::* то
_>

_>  int* (*p1)(D*)=ptr_to<&D::a>; // я бы мог писать так
_>  int* (*p2)(A*)=ptr_to<&D::a>; // а пиходится так
_>

_>То есть что бы работало в общем виде придётся писать ptr_to<D,&D::a>

_>ps: И тогда можно вместо offset спокойно использовать этот указатель, при желании преобразовав его в intptr_t

Твою мотивацию я понял. Тем не менее, несмотря на определенные неудобства, концептуально более чистым мне видится текущая имплементация, когда выражения &D::a и &A::a имеют один и тот же тип и одно и то же значение. В то же время, достаточно веских доводов для того, чтобы отстаивать свою позицию у меня нет. Скорее всего, это просто привычка и закреплённый временем и практикой стереотип.

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

R>Твою мотивацию я понял. Тем не менее, несмотря на определенные неудобства, концептуально более чистым мне видится текущая имплементация, когда выражения &D::a и &A::a имеют один и тот же тип и одно и то же значение. В то же время, достаточно веских доводов для того, чтобы отстаивать свою позицию у меня нет. Скорее всего, это просто привычка и закреплённый временем и практикой стереотип.

Вот тут приходим к мысли что &D::a и &A::a не имеют понятного простого типа и значения. А имеют астрактный тип и такое же (непришей к воротнику рукав) значение. И текущая имплементация создаёт больше проблем чем решает.

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

_>Вот тут приходим к мысли что &D::a и &A::a не имеют понятного простого типа и значения. А имеют астрактный тип и такое же (непришей к воротнику рукав) значение. И текущая имплементация создаёт больше проблем чем решает.

Ну а как должно быть, чтоб тебе понравилось?

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

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

_>>Вот тут приходим к мысли что &D::a и &A::a не имеют понятного простого типа и значения. А имеют астрактный тип и такое же (непришей к воротнику рукав) значение. И текущая имплементация создаёт больше проблем чем решает.

R>Ну а как должно быть, чтоб тебе понравилось?

так:

int* (*pointer)(D*)=&D::a;

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

R>>Ну а как должно быть, чтоб тебе понравилось?

_>

_>так:
_>

_>int* (*pointer)(D*)=&D::a;
_>

Ну да, и чтоб вот так нельзя было:

int* (*pointer)(А*)=&D::a;

Да?

И чем твой вариант принципиально лучше чем:

int D::*pointer = &D::a;

?

Да и вообще, пользоваться указателями на функции в наше время, это что-то странное. Пережитки полиморфизма времени выполнения.

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

R>Ну да, и чтоб вот так нельзя было:

R>

R>int* (*pointer)(А*)=&D::a;
R>

Так никто не мешает преобразовывать типы. Просто указатель &D::a имел бы тип int* (*)(D*);
А вот &A::a имел бы int* (*)(A*); В чем вопорос-то? Где типы преобразовывать? Или что?

R>И чем твой вариант принципиально лучше чем:

R>

R>int D::*pointer = &D::a;
R>

Тем что я могу его передать в сторонню динамическую библиотеку.

R>Да и вообще, пользоваться указателями на функции в наше время, это что-то странное.
у вас есть какие-то предубеждения против указателей на функцию? Впролне понятное и конкретное значение, в отличии от int D::*

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

_>у вас есть какие-то предубеждения против указателей на функцию?

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

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

R>Да, я считаю, что это отстой. Я предпочитаю иметь дело с абстрактными вызываемыми сущностями, а требования к ним описывать при помощи концептов и констрейнтов.
Чем указатель на функцию отстой. Он ничем не хуже вашей абстрактной абстракции с концептами. Но проще и не требует дополнительных понятий, концептов и сущностей. Сплошные плюсы. Но у вас какие-то предубеждения, или может быть Вас укусил кто-то из комитета?

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

R>А твой подход навязывает пользователю лишние знания и ограничивает его возможности. Прямо пахнуло затхлым воздухом Win API с его коллбэками.
Этот подход позволяет не изолироваться от внешнего мира. И не вводит никаких ограничений, а даже наоборот даёт больше возможностей, а еще он прост и понятен. И да WinAPI это C-шный апи. Т.к. c++ не способен предоставть вообще никакого вменяемого бинарного апи которое смогут использовать другие даже c++шки

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

_>Чем указатель на функцию отстой.

Я уже объяснил, чем.

_>Но у вас какие-то предубеждения, или может быть Вас укусил кто-то из комитета?

Признайся честно, что не умеешь в концепты, я пойму и прощу.

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

R>Я уже объяснил, чем.
Объяснение не убедительное.

_>>Но у вас какие-то предубеждения, или может быть Вас укусил кто-то из комитета?
R>Признайся честно, что не умеешь в концепты, я пойму и прощу.
Концепты, как раз это очень просто. Но инварианты значительно полезнее для валидации кода.
Но я более чем уверен что в C++ концепты сделают максимально ~~е6@%y*ыми~~ неудобными

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

_>Объяснение не убедительное.

Так я и не ставил себе целью тебя переуждать.

_>Концепты, как раз это очень просто. Но инварианты значительно полезнее для валидации кода.
_>Но я более чем уверен что в C++ концепты сделают максимально ~~е6@%y*ыми~~ неудобными

Да какие там инварианты. Лоховство чистой воды. Кстати, указатель на функцию далеко не всегда является компайл-тайм значением и хуже поддаётся оптимизации.

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

_>>Объяснение не убедительное.
R>Так я и не ставил себе целью тебя переуждать.

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

R>Кстати, указатель на функцию далеко не всегда является компайл-тайм значением и хуже поддаётся оптимизации.
Никто не запрещает им быть compile time значениями.

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

R>>Кстати, указатель на функцию далеко не всегда является компайл-тайм значением и хуже поддаётся оптимизации.
_>Никто не запрещает им быть compile time значениями.

Ну это как повезет. Как код написан, как оптимизатор отработает. В любом случае, ранняя пессимизация налицо. Но не это самое плохое. Это как довесок к тому, что я писал ранее.

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

R>Ну это как повезет. Как код написан, как оптимизатор отработает. В любом случае, ранняя пессимизация налицо. Но не это самое плохое. Это как довесок к тому, что я писал ранее.

Ну хз. Мне такие указатели гораздо удобнее чем то что в C++ нагородили

https://godbolt.org/z/Y7xMsE6qo

struct A {
    int x=10;
    virtual int fn(int y) { return x+y; }
};

int main(int argc, char **argv) {
    A a[1];
    int  (*pfn)(A*,int) = mfn <A,&A::fn>;
    int* (*px)(A*)      = mptr<A,&A::x>;
    printf("px=%p pfn=%p\n",px,pfn);
    printf("x=%d fn(20)=%d\n",*px(a),pfn(a,20));
    return 0;
}

px=0x40076a pfn=0x40072b
x=10 fn(20)=30

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

_>Чем указатель на функцию отстой.
Тем, что он указатель и тем, что похож на вычислимое goto.
Но это не главное. Главное, что указатель на функции — это работа на низком уровне, что провоцирует программиста писать запутанный, сложный для чтения код. Что сделать ревью кода с указателями на функции нужно раза в два больше времени, чем без них.

_>Он ничем не хуже вашей абстрактной абстракции с концептами.
Указатель на функцию — это и есть абстрактная абстракция времени выполнения.

Если хотите возразить, то скажите, чем указатель на функцию принципиально отличается от ссылки на функцию?

_> Но проще и не требует дополнительных понятий, концептов и сущностей.
Указатель на функцию сам по себе дополнительное понятие, концепция и сущность.

_>Этот подход позволяет не изолироваться от внешнего мира.
Это минус.

_>И не вводит никаких ограничений,
Это минус.

_> а даже наоборот даёт больше возможностей, а еще он прост и понятен.
Указатель на функцию — это просто и понятно?
Тогда может вы расскажите, как правильно перегрузить operator << для своего потока и std::endl ?

_>И да WinAPI это C-шный апи.
C-шный апи — это чисто зло. Вот прямо сегодня половину дня (из-за C-шного апи) я искал ошибку в чужом коде.

_>Т.к. c++ не способен предоставть вообще никакого вменяемого бинарного апи которое смогут использовать другие даже c++шки

И это правильно.

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

_>>Чем указатель на функцию отстой.
BFE>Тем, что он указатель и тем, что похож на вычислимое goto.
o_O приплыли.

BFE>Но это не главное. Главное, что указатель на функции — это работа на низком уровне, что провоцирует программиста писать запутанный, сложный для чтения код.
Вы вообще когда-нибудь пользовались указателями на функцию? А анонимными функциями? А замыканиями? Вы считаете это сложным?

BFE>Что сделать ревью кода с указателями на функции нужно раза в два больше времени, чем без них.
Вообще не факт. Кода может быть в десятки раз меньше с указателями на функции. Благодяря узбавлению от десятка лишнах абстракций и пачки переходников.
Яркий пример java.

_>>Он ничем не хуже вашей абстрактной абстракции с концептами.
BFE>Указатель на функцию — это и есть абстрактная абстракция времени выполнения.

BFE>Если хотите возразить, то скажите, чем указатель на функцию принципиально отличается от ссылки на функцию?
Да вы за??али ссылка и указатель это одно и тоже. И принципиально ничем не отличается, кроме особенностей которые введены искуственно.

_>> Но проще и не требует дополнительных понятий, концептов и сущностей.
BFE>Указатель на функцию сам по себе дополнительное понятие, концепция и сущность.
Это не должно быть дополнительной концепцией и сущностью, это должно быть first class citizen и лучше если оно выражено через уже имеющиеся концепции не вводя новых.

_>>Этот подход позволяет не изолироваться от внешнего мира.
BFE>Это минус.
Это минус только для теоретика. Инженерам не нужен изолированный язык. Нуже тот что позваляет решать практические задачи.

_>>И не вводит никаких ограничений,
BFE>Это минус.
Наручники это тоже плюс, но не для того на ком они.

BFE>Указатель на функцию — это просто и понятно?
BFE>Тогда может вы расскажите, как правильно перегрузить operator << для своего потока и std::endl ?
Элементар но же. Не используйте std::endl есть милион и маленькая тележка сделать иначе, а не это убожество с потоками.

_>>И да WinAPI это C-шный апи.
BFE>C-шный апи — это чисто зло. Вот прямо сегодня половину дня (из-за C-шного апи) я искал ошибку в чужом коде.
Зло. Хорошо. Сделайте лучше. Или хотя кривую альтернативу.

_>>Т.к. c++ не способен предоставть вообще никакого вменяемого бинарного апи которое смогут использовать другие даже c++шки

BFE>И это правильно.
Аргументация прям огонь.

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

_>Ну хз. Мне такие указатели гораздо удобнее чем то что в C++ нагородили

_>https://godbolt.org/z/Y7xMsE6qo

#include <utility>

template<class P,auto field>class mptr_t {
    template<class A,class B> static A helper(A B::*);
public:
    typedef decltype(helper(field)) field_t; typedef P class_t;
    typedef field_t* (*type)(class_t*);
    static  field_t* value(class_t* p) { return &(p->*field); }
};

template<class P,auto mfn>class mfn_t {
    template<class T> struct helper;
    template<class C,class R,class...Args> struct helper<R(C::*)(Args...)> {
        typedef R result_t; typedef R (*type)(C*,Args...);
        template<class FP,auto m>static R value(FP* p,Args... args) {
            return (p->*m)(std::forward<Args>(args)...);
        }
    };
    using h=helper<decltype(mfn)>;
public:
    typedef P class_t; typedef typename h::result_t result_t;
    typedef typename h::type type;
    constexpr static type value=h::template value<P,mfn>;
};

template<class P,auto m> inline constexpr typename mptr_t<P,m>::type 
mptr = mptr_t<P,m>::value;
template<class P,auto m> inline constexpr typename mfn_t<P,m>::type 
mfn = mfn_t<P,m>::value;

//------------------------------------------------------------------------------

struct A {
    int x=10;
    virtual int fn(int y) { return x+y; }
};

#include <stdio.h>
int main(int argc, char **argv) {
    A a[1];
    auto pfn=mfn<A,&A::fn>;
    auto px=mptr<A,&A::x>;
    printf("px=%p pfn=%p\n",px,pfn);
    printf("x=%d fn(20)=%d\n",*px(a),pfn(a,20));
    return 0;
}

Мда уж. Демонстрация того, что даже самые простые вещи можно делать черeз жопу. А проверять указатели на null кто за тебя будет, Пушкин?

Хотя, казалось бы, чего уж проще:

https://godbolt.org/z/1aEEdoE96

#include <stdio.h>

template <auto member>
requires (member != nullptr)
struct Accessor
{
   constexpr decltype(auto) operator()(auto&& object) const {
      return object.*member;
   }
   constexpr decltype(auto) operator()(auto&& object, auto&&...args) const {
      return (object.*member)(args...);
   }
};
template <auto member> constexpr Accessor<member> accessor;

struct A {
   int x = 10;
   virtual int fn(int y) { return x + y; }
};

int main() {
   A a[1];
   auto fn = accessor<&A::fn>;
   auto x = accessor<&A::x>;

   printf("x=%d fn(20)=%d\n", x(*a), fn(*a, 20));
}

	От:	kov_serg
	Дата:	28.03.25 13:28
	Оценка:

	От:	kov_serg
	Дата:	28.03.25 13:48
	Оценка:

	От:	rg45
	Дата:	28.03.25 14:19
	Оценка:

	От:	rg45
	Дата:	28.03.25 14:25
	Оценка:

	От:	kov_serg
	Дата:	28.03.25 19:40
	Оценка:

	От:	B0FEE664
	Дата:	31.03.25 16:49
	Оценка: