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

P>>>>нельзя кастануть указатели разных типов к void* и вычислить разницу между ними?
E>>>А разве есть гарантии, что объект всегда будет лежать в одном сегменте памяти?
P>>вы о чём вообще?
E>Вообще-то в С++ можно вычетать не любые два указателя, а только два указателя внутрь одногои того же сегмента памяти...

1. можете дать ссылку на стандарт? хотя бы приблизительно где об этом говорится, может ключевые слова.
я нашёл только три слова содержащие "seg", и все были SIGSEGV
2. По вашему мнению, объекты в памяти фрагментируются или нет? (это вопрос не про alignment)

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

E>>Вообще-то в С++ можно вычетать не любые два указателя, а только два указателя внутрь одногои того же сегмента памяти...

P>1. можете дать ссылку на стандарт? хотя бы приблизительно где об этом говорится, может ключевые слова.
P>я нашёл только три слова содержащие "seg", и все были SIGSEGV

Там не сегмент памяти, там все строже:

Unless both pointers point to elements of the same array object, or one past the last element of the array object, the behavior is undefined.

5.7.6

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

E>Вообще-то в С++ можно вычетать не любые два указателя, а только два указателя внутрь одногои того же сегмента памяти...

но в винде ведь страничная организация памяти (как и сегментация, страничная организация памяти связана с преобразованием виртуального адреса (в данном случае линейного) в физический) так что можно вычетать любые два да и в линуксе тоже единственное кому стоит задуматься это тем кто пишет под "недооси" c cегментной организацией памяти (при сегментной организации у программы нет единого линейного адресного пространства. виртуальный адрес состоит из двух частей: селектора сегмента и смещения от начала сегмента) и да вот еще что а это правило относится к операциям < <= > => ???? потому что их я точно видел применными к абсолютно разным указателям там правда в скобках писалось что это нарушает стандарт но из за того что используется страничная организация памяти все будет хорошо работать "поддержка такого режима присутствует в большинстве 32битных и 64битных процессорах. такой режим является классическим для почти всех современных ОС, в том числе windows и семейства unix" (кстати эта библиотека GLIB)

вообщем если предположить что операторы == != можно применять только к указателям в один массив относится ли тоже самое и к < <= > => ???

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


E>>>Вообще-то в С++ можно вычетать не любые два указателя, а только два указателя внутрь одногои того же сегмента памяти...
P>>1. можете дать ссылку на стандарт? хотя бы приблизительно где об этом говорится, может ключевые слова.
P>>я нашёл только три слова содержащие "seg", и все были SIGSEGV
Ops>Там не сегмент памяти, там все строже:
Ops>

Ops>Unless both pointers point to elements of the same array object, or one past the last element of the array object, the behavior is undefined.

5.7.6

ясно.
походу стандартно это можно реализовать только через явное хранение указателя на агрегирующий объект в каждом случае.

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

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

E>Что смещение от this не изменится ни в каком MDT...
MDT?

J>>Я бы не сказал что моя обёртка такие уж "хаки", нормальная типобезопасная имплементация, пусть кривоват синтаксис но если надо... Плюс, есть же __declspec( property .. пусть даже непортируемое.

E>Ну да. Беда только в том, что проперти в С++ вообще криво смотрятся. И вообще это всё в целом криво.

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

Одной из причин может быть то, что синтаксический сахарок достаточно жиденький: a = value вместо a(value); работая с переменной ты не ожидаешь каких то сайд-эффектов а тут как раз цель проперти — спрятать сайд эффекты под ликом переменной; ну и конечно достаточно сложно в плане перегрузки всех возможных операторов += и т.д...

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

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

P>>да, я видел, и?
E>И
E>2) Оба макроса требуют, что бы объемлющий класс был POD...

Имхо слишком сильное ограничение, похоже ребята хотят оградить от потенциальных измерений межклассовых смещений мемберов в дереве наследования, типа как от derived класса к мемберу в базовом. Опять же если мерять только внутри класса, то в какой иерархии наследования этого класса и POD он или не POD должно быть побоку. POD/или не POD мембер — sizeof & align в рантайме не меняются, отсюда и смещения — компайл-тайм константы.

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

E>>Что смещение от this не изменится ни в каком MDT...
J>MDT?

Most derived type, как подсказывает гугл.
В случае одной линии наследования подавляющее большинство реализаций расширяет классы добавлением в конец (и даже смещение до указателя на VMT может быть произвольным, в зависимости от того, какой класс в иерархии первым завёл хоть что-то виртуальное), но в случае множественного наследования уже не так.
В случае class C: A, B { ... } возникают интересные эффекты — если cc типа C, то (B*)cc и его static_cast аналог это уже указатель, не совпадающий с указателем на cc.

Ещё интереснее, если есть, например, общий класс A, его потомки B и C (причём в обоих A — virtual base) и D — производный от B и C. При этом тела объектов B и C будут содержать указатель на часть A, а не включать её напрямую как часть структуры, и доступ будет выполняться с резолвингом этого указателя; компилятор не имеет права это оптимизировать, кроме случая, когда он будет гарантированно уверен, что объект — типа B или C. В составном объекте D, будет одна копия A; где она будет находиться — дело компилятора, и из B и C будут указатели на неё, которые будут резолвиться при доступе к чему-то из A. Думаю, поэтому для этого механизма появилось слово virtual: неизвестно, кому принадлежит эта база.

Так что в общем случае всё настолько туманно, что нельзя надеяться...

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

E>>Вообще-то в С++ можно вычетать не любые два указателя, а только два указателя внутрь одногои того же сегмента памяти...
J>но в винде ведь страничная организация памяти (как и сегментация, страничная организация памяти связана с преобразованием виртуального адреса (в данном случае линейного) в физический) так что можно вычетать любые два да и в линуксе тоже единственное кому стоит задуматься это тем кто пишет под "недооси" c cегментной организацией памяти (при сегментной организации у программы нет единого линейного адресного пространства.

Вопрос не в формальной возможности вычитания, а в том, как потом использовать результат этого вычитания. Да, есть случаи, когда вычитание вообще не может быть однозначно определено, и хороший пример на это — сегментированная адресация в far модели (заметим, но не в huge). Или те архитектуры, которые слишком гарвардские и в которых указатели на разные типы данных, или на код и данные, могут совсем по-разному представляться (слышал такие — например, данные адресуются байтами, а код — 32-битными словами). В случае только виртуальной памяти таких проблем нет, ok. Но остаются другие — а что значит полученная разность между двумя областями, выделенными по неизвестному правилу неконтролируемым источником?

J>вообщем если предположить что операторы == != можно применять только к указателям в один массив относится ли тоже самое и к < <= > => ???

Даже если это не вызовет облома выполнения, смысла в них практически нет за пределами узких областей (таких, как реализация malloc).

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

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

E>>>Что смещение от this не изменится ни в каком MDT...
J>>MDT?
N>Most derived type, как подсказывает гугл.
Он мне подсказывал что то другое

N>Так что в общем случае всё настолько туманно, что нельзя надеяться...

Это всё понятно, токо я непрерывно намекаю на то что тут указатель нужно получить на владельца проперти, т.е. если ты описал проперти в классе А то и указатель this мы считаем c мембера класса А на this самого класса A. Весь этот туман просто идёт мимо в данном случае.

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

J>Имхо слишком сильное ограничение, похоже ребята хотят оградить от потенциальных измерений межклассовых смещений мемберов в дереве наследования, типа как от derived класса к мемберу в базовом. Опять же если мерять только внутри класса, то в какой иерархии наследования этого класса и POD он или не POD должно быть побоку. POD/или не POD мембер — sizeof & align в рантайме не меняются, отсюда и смещения — компайл-тайм константы.

Когда кто-то считает себя умнее разработчиков компилятора, то это и называется, обычно UB...

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

E>>Что смещение от this не изменится ни в каком MDT...
J>MDT?

J>Это да, это был один из моментов в моём начальном посте. Несмотря на то что техническая возможность есть (я добавлял проперти в код, потом убрал) мне они оказались не нужны.

+100500
Тем более, что у MS есть тот самый __declspec, для тех, кому надо убедиться в ненужности пропертей в С++

J>Одной из причин может быть то, что синтаксический сахарок достаточно жиденький: a = value вместо a(value); работая с переменной ты не ожидаешь каких то сайд-эффектов а тут как раз цель проперти — спрятать сайд эффекты под ликом переменной; ну и конечно достаточно сложно в плане перегрузки всех возможных операторов += и т.д...

И тут соглашусь.

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

J>вообщем если предположить что операторы == != можно применять только к указателям в один массив относится ли тоже самое и к < <= > => ???

Вот, как раз == != модно к любым, а — + < > -- только к указателям из одного блока памяти.

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

P>походу стандартно это можно реализовать только через явное хранение указателя на агрегирующий объект в каждом случае.

Или через наследование.

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

J>Это всё понятно, токо я непрерывно намекаю на то что тут указатель нужно получить на владельца проперти, т.е. если ты описал проперти в классе А то и указатель this мы считаем c мембера класса А на this самого класса A. Весь этот туман просто идёт мимо в данном случае.

Так где гарантии, что "туман идёт мимо"?

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

P>>походу стандартно это можно реализовать только через явное хранение указателя на агрегирующий объект в каждом случае.
E>Или через наследование.

это как? какой синтаксис получится?
"object.some_property=some_shit" ?

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

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

J>>Это всё понятно, токо я непрерывно намекаю на то что тут указатель нужно получить на владельца проперти, т.е. если ты описал проперти в классе А то и указатель this мы считаем c мембера класса А на this самого класса A. Весь этот туман просто идёт мимо в данном случае.

E>Так где гарантии, что "туман идёт мимо"?

Хорошо, я принимаю твой выпод про разработчиков компиляторов, допустим они что то знают такое, чего я нет. Что то такое, что нарушает данную гарантию.

Давай порассуждаем, как иерархия наследования, в которой не-POD класс А участвует, может изменять смещения мемберов в классе А? Вообще, что может произойти с не-POD классом, чтобы трюк с OFFSETOF ломался (Причём именно в зависимости от: класс POD/не POD).

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

E>+100500
E>Тем более, что у MS есть тот самый __declspec, для тех, кому надо убедиться в ненужности пропертей в С++

Такие кривые properties, как в MSVC — да, не нужны.
В такой реализации, как я описывал — никто реально не проверял.

IRO>getMatrix пересчитает матрицу только в том случае если данные изменились, в противном вернет as is
Ага. А потом окажется, что "изменение данных" определено не верно, и данные не пересчитываются, возвращается старьё. Или наооборот — всё каждый раз пересчитывается.
Ненавижу не константные методы с названием "get..."

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

P>это как? какой синтаксис получится?
P>"object.some_property=some_shit" ?

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

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

Ну типа, есть шаблон

template<typename T, typename Tag = void> class AsProperty {
    //  Тут типа реализация методов, операторов и прочего.
};

а в клиентском коде пишем

class MyClass : AsProperty<int> {
public:
    AsProperty<int>& MyProp;

   MyClass() : MyProp( *this ) {};
   MyClass( const MyClass& other ) : AsProperty<int>( other), MyProp( *this ) {}
};

и надеяться на то, что оптимизатор рюхнёт, что для этой ссылки не нужно хранилище

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

J>Давай порассуждаем, как иерархия наследования, в которой не-POD класс А участвует, может изменять смещения мемберов в классе А? Вообще, что может произойти с не-POD классом, чтобы трюк с OFFSETOF ломался (Причём именно в зависимости от: класс POD/не POD).

Лэйаут POD-типов описан в стандарте. Для остальных руки у компилятора развязаны...