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

НИ>Для нахождения смещения члена есть стандартный макрос offsetof (для использования в C надо подключать stddef.h, в C++ — cstddef). А то, что предложил Мухин, — это хак.

#define offsetof(s,m) (size_t)&(((s *)0)->m)
#define FIELDOFFSET(type, field) ((short)&(((type *)0)->field))

Хак, говоришь?

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

V>>Всмысле? У себя инклуд так и назову..
E>Ну и не получится скомпилировать.
Ну и получит производитель пачку багов от кастомеров.
Затем путем нехитрых но неприятных действий менеджмент производителя компилера донесёт до автора подобных "оптимизаций" простую и очевидную мысль: "нехрен выделываться".

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

CC>Здравствуйте, Николай Ивченков, Вы писали:

НИ>>Для нахождения смещения члена есть стандартный макрос offsetof (для использования в C надо подключать stddef.h, в C++ — cstddef). А то, что предложил Мухин, — это хак.

CC>#define offsetof(s,m) (size_t)&(((s *)0)->m)
CC>#define FIELDOFFSET(type, field) ((short)&(((type *)0)->field))

CC>Хак, говоришь?

Конечно хак.

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

CC>Затем путем нехитрых но неприятных действий менеджмент производителя компилера донесёт до автора подобных "оптимизаций" простую и очевидную мысль: "нехрен выделываться".

Почему это получит? Это же по стандарту...
MSVC так не делает, но на какой-нибудь хитрой платформе компилятор вполне может так делать.
В С++ очень много чего для нужд реализации зарезервировано. Ключевые слова, например, макросами подменять, тоже нельзя...

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

CC>>Затем путем нехитрых но неприятных действий менеджмент производителя компилера донесёт до автора подобных "оптимизаций" простую и очевидную мысль: "нехрен выделываться".

E>Почему это получит? Это же по стандарту...
А на самом деле многим крупным конторам плевать что там есть какой то стандарт.
Ты вспомни как МС приходилось обеспечивать совместимость багов и глюков версий винды.
С компилером будет то же самое.

E>MSVC так не делает, но на какой-нибудь хитрой платформе компилятор вполне может так делать.
Ни один известный мне компилер так не делает.
Потому как на самом деле разрешить замену стандартной библиотеки куда более логичное и правильное решение чем запрет ее менять.
Потому как бывает что на реальной задаче это реально нужно.

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

CC>Потому как на самом деле разрешить замену стандартной библиотеки куда более логичное и правильное решение чем запрет ее менять.
CC>Потому как бывает что на реальной задаче это реально нужно.

Ну вот в лялихе, например, рантайм С -- это часть интерфейса системы фактически. Менять его нехорошо. Почему на какой-то платформе (например последовательно приплюснутой) не может быть такой же фигни и с STL?
Заменяемость стандартной библиотеки, кстати, стандарт не требует...

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

E>Заменяемость стандартной библиотеки, кстати, стандарт не требует...
Зато иногда задача того требует.

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

E>>Заменяемость стандартной библиотеки, кстати, стандарт не требует...
CC>Зато иногда задача того требует.

Интересно, зачем? Можно же своей просто пользоваться?

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

E>>>Заменяемость стандартной библиотеки, кстати, стандарт не требует...
CC>>Зато иногда задача того требует.

E>Интересно, зачем? Можно же своей просто пользоваться?
а стандартную куда деть чтоб не путалась?
имеется в виду не просто STL а весь CRT

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

CC>имеется в виду не просто STL а весь CRT
Дык CRT и так часто нельзя подменять. Например, если ты подменишь CRT в линуксе, что что будет с клеинтами malloc?