В книге Майерса (35 новых способов улучшить ваш срр) в примечании написано, что для каждого типа объект type_info единственен, что дает нам право юзать его адрес. У Страуструпа написано обратное — он не единственен. В стандарте тоже вроде не нашел про единственность. Кто ошибся? Майерс?

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

_>В книге Майерса (35 новых способов улучшить ваш срр) в примечании написано, что для каждого типа объект type_info единственен, что дает нам право юзать его адрес. У Страуструпа написано обратное — он не единственен. В стандарте тоже вроде не нашел про единственность. Кто ошибся? Майерс?

type_info уникален в рамках отдельного модуля — .exe или .dll, например. Но если в состав программного продукта входит несколько динамических линкуемых библиотек, то для одного и того же класса в каждом модуле будет свой собственный экземпляр type_info. Но, тем не менее, на уникальности type_info можно реализовывать множество разных полезных вещей, фабрик, например. Для этого вся возня с type_info должна быть инкапсулирована в одном модуле, из которого наружу торчит только интерфейс более высокого уровня.

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

_>>В книге Майерса (35 новых способов улучшить ваш срр) в примечании написано, что для каждого типа объект type_info единственен, что дает нам право юзать его адрес. У Страуструпа написано обратное — он не единственен. В стандарте тоже вроде не нашел про единственность. Кто ошибся? Майерс?

R>type_info уникален в рамках отдельного модуля — .exe или .dll, например.

Да вроде бы никто этого не обещает. Да и вообще, если у меня в выражении 2 разных временных type_info про один тип — с чего бы у них одинаковым адресам быть?

R>Но если в состав программного продукта входит несколько динамических линкуемых библиотек, то для одного и того же класса в каждом модуле будет свой собственный экземпляр type_info. Но, тем не менее, на уникальности type_info можно реализовывать множество разных полезных вещей, фабрик, например. Для этого вся возня с type_info должна быть инкапсулирована в одном модуле, из которого наружу торчит только интерфейс более высокого уровня.

У type_info есть функция before и операторы равенства/неравенства — вполне достаточно для всяких реестров и фабрик.

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


ТКС>У type_info есть функция before и операторы равенства/неравенства — вполне достаточно для всяких реестров и фабрик.

Он не copy и не assign, поэтому вроде бы недостаточно.
У Александреску еще обертка какая то была...

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

_>для каждого типа объект type_info единственен, что дает нам право юзать его адрес.
нам позволено использовать адрес по другим причинам — время жизни type_info описано в стандарте
_>У Страуструпа написано обратное — он не единственен. В стандарте тоже вроде не нашел про единственность. Кто ошибся? Майерс?
соглашусь с тем, что про единственность не написано. мы можем использовать сохраненные указатели для сравнения самих type_info, но не следует сравнивать сами указатели

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

U>соглашусь с тем, что про единственность не написано. мы можем использовать сохраненные указатели для сравнения самих type_info, но не следует сравнивать сами указатели

Ну тут вопрос опять же возникает: можно ли использовать сами указатели в одном модуле, если между модулями указатели не передаются?

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

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

Сами указатели для сравнения.

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

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

U>>соглашусь с тем, что про единственность не написано. мы можем использовать сохраненные указатели для сравнения самих type_info, но не следует сравнивать сами указатели

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

лично у меня этот вопрос не возникает, и я на него дал уже ответ (см. выше)

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

ТКС>Да и вообще, если у меня в выражении 2 разных временных type_info про один тип — с чего бы у них одинаковым адресам быть?

В том-то и дело, что не два временных объекта, а две ссылки, причем, судя по экспериментам, именно на один объект. Вот проверь:

std::cout << (&typeid(double) == &typeid(double)) << std::endl;

R>>type_info уникален в рамках отдельного модуля — .exe или .dll, например...

ТКС>Да вроде бы никто этого не обещает.
ТКС>У type_info есть функция before и операторы равенства/неравенства — вполне достаточно для всяких реестров и фабрик.

Тут согласен. К сожалению, никто не обещает, и действительно, достаточно before и операторов равенства/неравенства для того, например, чтоб построить ассоциативный контейнер, с ключами на основе type_info.

Но иногда, когда борьба за быстродействие достигает критической точки, начинаешь пускаться во все тяжкие и использовать недокументированные возможности. Сравнение двух указателей-то быстрее, чем вызов before, а эмпирически установлено, что в серии компиляторов VS адреса объектов type_info действительно уникальны. Хотя, если смотреть строго, то даже правомерность сравнения таких указателей на больше/меньше под вопросом — никто ведь не гарантирует, что адресуемые объекты расположены в одном массиве, следовательно, само сравнение таких указателей на больше/меньше — UB — согласно стандарту. Что поделаешь, таковы реалии.

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

R> Хотя, если смотреть строго, то даже правомерность сравнения таких указателей на больше/меньше под вопросом — никто ведь не гарантирует, что адресуемые объекты расположены в одном массиве, следовательно, само сравнение таких указателей на больше/меньше — UB — согласно стандарту.

Вы слишком строги Данное утверждение верно для языка C.
В C++ с этим по-лучше

Pointers to objects or functions of the same type (after pointer conversions) can be compared,
with a result defined as follows:
— If two pointers p and q of the same type point to the same object or function, or both point one past the
end of the same array, or are both null, then p<=q and p>=q both yield true and p<q and p>q both
yield false.
— If two pointers p and q of the same type point to different objects that are not members of the same
object or elements of the same array or to different functions, or if only one of them is null, the results
of p<q, p>q, p<=q, and p>=q are unspecified.
— If two pointers point to nonstatic data members of the same object, or to subobjects or array elements of
such members, recursively, the pointer to the later declared member compares greater provided the two
members are not separated by an access-specifier label (11.1) and provided their class is not a union.
— If two pointers point to nonstatic data members of the same object separated by an access-specifier label
(11.1) the result is unspecified.
— If two pointers point to data members of the same union object, they compare equal (after conversion to
void*, if necessary). If two pointers point to elements of the same array or one beyond the end of the
array, the pointer to the object with the higher subscript compares higher.
— Other pointer comparisons are unspecified.

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

ТКС>>Да и вообще, если у меня в выражении 2 разных временных type_info про один тип — с чего бы у них одинаковым адресам быть?

R>В том-то и дело, что не два временных объекта, а две ссылки, причем, судя по экспериментам, именно на один объект. Вот проверь:
R>

R>std::cout << (&typeid(double) == &typeid(double)) << std::endl;
R>

Да, насчет временных объектов я протупил — какие же они временные, раз живут до конца программы... С таким требованием логично предоставлять ссылку на статический объект.

R>>>type_info уникален в рамках отдельного модуля — .exe или .dll, например...

ТКС>>Да вроде бы никто этого не обещает.
ТКС>>У type_info есть функция before и операторы равенства/неравенства — вполне достаточно для всяких реестров и фабрик.

R>Тут согласен. К сожалению, никто не обещает, и действительно, достаточно before и операторов равенства/неравенства для того, например, чтоб построить ассоциативный контейнер, с ключами на основе type_info.

R>Но иногда, когда борьба за быстродействие достигает критической точки, начинаешь пускаться во все тяжкие и использовать недокументированные возможности. Сравнение двух указателей-то быстрее, чем вызов before, а эмпирически установлено, что в серии компиляторов VS адреса объектов type_info действительно уникальны.

Проверил на gcc 4.4 — та же картина.

R> Хотя, если смотреть строго, то даже правомерность сравнения таких указателей на больше/меньше под вопросом — никто ведь не гарантирует, что адресуемые объекты расположены в одном массиве, следовательно, само сравнение таких указателей на больше/меньше — UB — согласно стандарту. Что поделаешь, таковы реалии.

На практике, думаю, можно просто завернуть сравнение type_info в свою (инлайновую для скорости) функцию и не париться по этому поводу. Если вдруг сломается (что вряд ли) — перейти на before.
Хотя, был у меня разок случай, когда и before между модулями неправильно работал — но это скорее можно отнести к багам компилятора, там тип сильно вычурный был, указатель на виртуальную функцию.

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

ТКС>>У type_info есть функция before и операторы равенства/неравенства — вполне достаточно для всяких реестров и фабрик.

_>Он не copy и не assign, поэтому вроде бы недостаточно.
_>У Александреску еще обертка какая то была...

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

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




ТКС>>У type_info есть функция before и операторы равенства/неравенства — вполне достаточно для всяких реестров и фабрик.

Пара "ключ-значение" должна поддерживать присваивание и копирование, у type_info они же закрыты.
private:
type_info (const type_info& rhs);
type_info& operator= (const type_info& rhs);

Значит тут еще извращаться надо.

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

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

ТКС>>>У type_info есть функция before и операторы равенства/неравенства — вполне достаточно для всяких реестров и фабрик.

_>Пара "ключ-значение" должна поддерживать присваивание и копирование, у type_info они же закрыты.
_>private:
_> type_info (const type_info& rhs);
_> type_info& operator= (const type_info& rhs);

_>Значит тут еще извращаться надо.

Ну да, подразумевалось, что, в примитивном варианте, ключ — это указатель на type_info и в дополнение специальный компарер(или хешер) для ассоциавного контейнера. Ну а по-хорошему ключ — это обертка, инкапсулирующая указатель, для которой определены все операции сравнения.

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

R>> Хотя, если смотреть строго, то даже правомерность сравнения таких указателей на больше/меньше под вопросом — никто ведь не гарантирует, что адресуемые объекты расположены в одном массиве, следовательно, само сравнение таких указателей на больше/меньше — UB — согласно стандарту.

U>Вы слишком строги Данное утверждение верно для языка C.
U>В C++ с этим по-лучше
U>

U>Pointers to objects or functions of the same type (after pointer conversions) can be compared,
U>with a result defined as follows:
U>— If two pointers p and q of the same type point to the same object or function, or both point one past the
U>end of the same array, or are both null, then p<=q and p>=q both yield true and p<q and p>q both
U>yield false.
U>— If two pointers p and q of the same type point to different objects that are not members of the same
U>object or elements of the same array or to different functions, or if only one of them is null, the results
U>of p<q, p>q, p<=q, and p>=q are unspecified.
U>— If two pointers point to nonstatic data members of the same object, or to subobjects or array elements of
U>such members, recursively, the pointer to the later declared member compares greater provided the two
U>members are not separated by an access-specifier label (11.1) and provided their class is not a union.
U>— If two pointers point to nonstatic data members of the same object separated by an access-specifier label
U>(11.1) the result is unspecified.
U>— If two pointers point to data members of the same union object, they compare equal (after conversion to
U>void*, if necessary). If two pointers point to elements of the same array or one beyond the end of the
U>array, the pointer to the object with the higher subscript compares higher.
U>— Other pointer comparisons are unspecified.

Полагаешь, unspecified behavior на много лучше, чем undefined?

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

_>Кто ошибся? Майерс?

По идее того, что утверждает Майерс стандарт не гарантирует.
Но, с другой стороны, можно рассчитывать на то, что указатель на type_info не утратит валидности во время работы программы. Так что надо просто использовать отображение N->1 для перехода от типов к указателям.

Скажем иметь, для скорости, кэш из хэша из указателей во что-то ещё и для поиска пока ненайденного в кэше указателя иметь отсортированный по before массив указателей...

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

R>Полагаешь, unspecified behavior на много лучше, чем undefined?
Конечно, лучше =) На одном и том же компиляторе поведение сохраняется =)
Думаю, вы со мной согласитесь по поводу убогости стандарта в плане полноты описания операторов ==, !=, <, > , <=, >=. В стандарте даже не описана их взаимосвязь (ведь это понятия из математики). Сам результат сравнения &a < &b действительно может быть неинтересен для разных объектов (и может отличаться на разных компиляторах, это и есть unspecified). Ведь главное — сохранять инварианты:
&a < &b = !(&b <= &a)
&a < &b && &b < &c => &a < &b
и тд
а это в стандарте не зафиксировано =\

1.3.12 undefined behavior [defns.undefined]
behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this
International Standard imposes no requirements.
<skip>
1.3.13 unspecified behavior [defns.unspecified]
behavior, for a well-formed program construct and correct data, that depends on the implementation. The
implementation is not required to document which behavior occurs. [Note: usually, the range of possible
behaviors is delineated by this International Standard. ]
1.3.14 well-formed program [defns.well.formed]
a C + + program constructed according to the syntax rules, diagnosable semantic rules, and the One Definition
Rule (3.2).

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

_>В книге Майерса (35 новых способов улучшить ваш срр) в примечании написано, что для каждого типа объект type_info единственен, что дает нам право юзать его адрес. У Страуструпа написано обратное — он не единственен. В стандарте тоже вроде не нашел про единственность. Кто ошибся? Майерс?

Во второй главе той самой книги Александреску

Автор(ы): Андрей Александреску

В книге изложена новая технология программирования, представляющая собой сплав обобщенного программирования, метапрограммирования шаблонов и объектно- ориентированного программирования на С++. Настраиваемые компоненты, созданные автором, высоко подняли уровень абстракции, наделив язык С++ чертами языка спецификации проектирования, сохранив всю его мощь и выразительность. В книге изложены способы реализации основных шаблонов проектирования. Разработанные компоненты воплощены в библиотеке Loki, которую можно загрузить с Web-страницы автора. Книга предназначена для опытных программистов на С++.

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

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

_>В книге Майерса (35 новых способов улучшить ваш срр) в примечании написано, что для каждого типа объект type_info единственен, что дает нам право юзать его адрес. У Страуструпа написано обратное — он не единственен. В стандарте тоже вроде не нашел про единственность. Кто ошибся? Майерс?
чинил однажды библиотеку, где использовалось предположение Майерса. Однако, разработчики gcc эту книгу не читали, поэтому сравнение объектов type_info по значению указателя на имя класса давало неравенство при одинаковых типах класса.

ИМХО, лучше сравнивать через strcmp и все. Надежно.

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

R>>Полагаешь, unspecified behavior на много лучше, чем undefined?
U>Конечно, лучше =) На одном и том же компиляторе поведение сохраняется =)

По-моему, тут всё-таки белое пятно в стандарте. Конечно, поведение не специфицировано, но оно — в отношении указателей — стабильно.
Тогда как другие примеры UnsB могут быть нестабильными.

int inc(int& x) { return ++x; }
int sub(int x, int y) { return x-y; }

int x1 = 1;
int d1 = div(inc(x1), inc(x1)); // 1-2 или 2-1 - как компилятор оптимизирует

int x2 = 1;
int d2 = div(inc(x2), inc(x2)); // 1-2 или 2-1 - независимо от того, что было выше