Вот интересно, вообще существует ситуация где можно приметить тип TypeList(собственно не важно какая реализая, можно и из boost) именно как тип переменной, а не в качетсве typedef & template.
TypeList<........> tlist; ..для чего может понадобиться переменная tlist ?
И вопрос в догонку: почему С++ не позволяет делать следующее:
ЗЫ: Плиз не отвечайте таким образом: не позволяет стандарт
tlist::head h; //тут будет ошибочка
TypeList<........>::head h1; //тут гут
В чем тут сложность у компилятора то?
Re: Список типов
От:
Аноним
Дата:
20.05.04 07:42
Оценка:
Здравствуйте, Denwer, Вы писали:
D>Вот интересно, вообще существует ситуация где можно приметить тип TypeList(собственно не важно какая реализая, можно и из boost) именно как тип переменной, а не в качетсве typedef & template.
D>
D>TypeList<........> tlist; ..для чего может понадобиться переменная tlist ?
D>
Насколько я помню Александреску — список типов не содержит данных, он содержит определения типов. Поэтому в объекте этого типа имхо смысла нет.
D>И вопрос в догонку: почему С++ не позволяет делать следующее: D>ЗЫ: Плиз не отвечайте таким образом: не позволяет стандарт
D>
D>tlist::head h; //тут будет ошибочка
D>TypeList<........>::head h1; //тут гут
D>
D>В чем тут сложность у компилятора то?
Левый аргумент оператора разрешения видимости — namespace. В качестве него может выступать тип, но не переменная.
Здравствуйте, Аноним, Вы писали:
А> Левый аргумент оператора разрешения видимости — namespace. В качестве него может выступать тип, но не переменная.
Я это и сам знаю, спрашиваю именно почему так, а не иначе? В чем сложность данной реализации у компилятора, и почему это не всключили в стандарт? Вот что я хотел услышать.
Здравствуйте, Denwer, Вы писали:
D>И вопрос в догонку: почему С++ не позволяет делать следующее: D>ЗЫ: Плиз не отвечайте таким образом: не позволяет стандарт
D>
D>tlist::head h; //тут будет ошибочка
D>TypeList<........>::head h1; //тут гут
D>
D>В чем тут сложность у компилятора то?
Я так думаю, что проблема чисто идиологическая... Пример, поскольку ссылки фактически являются синонимами объектов, то если разрешить запись obj::some_type для объектов, то нужно разрешить и такую же запись для ссылок...
class Base
{
public:
typedef int SomeType;
};
class Child : public Base
{
public:
typedef double SomeType;
};
void func(Base &ref)
{
ref::SomeType testVal;
}
int _tmain(int argc, _TCHAR* argv[])
{
Child objChild;
Base objBase;
Base &ref1 = objChild;
Base &ref2 = objBase;
func(ref1);
func(ref2);
}
Какой тип должен быть у testVal при обоих вызовах func? Так как ref1 — это ссылка на Child, а ref2 — на Base, то в первом случае ref::SomeType должен быть double, а во втором int. Но эта информация может быть получена только во время исполнения программы, а информация о типах в C++ фактически присутствует только на этапе компиляции (RTTI не в счёт). То есть жёсткая типизация языка летит в тартар и мы получаем SmallTalk .
Всё это чистое IMHO, не претендующее на тезисы
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Denwer, Вы писали:
А>>Левый аргумент оператора разрешения видимости — namespace. В качестве него может выступать тип, но не переменная.
D>Я это и сам знаю, спрашиваю именно почему так, а не иначе? В чем сложность данной реализации у компилятора, и почему это не всключили в стандарт? Вот что я хотел услышать.
Дык typeof() тоже не включили в стандарт... Вроде собираются, двадцать лет спустя.
Здравствуйте, Mr. None, Вы писали:
MN>Здравствуйте, Denwer, Вы писали:
D>>И вопрос в догонку: почему С++ не позволяет делать следующее: D>>ЗЫ: Плиз не отвечайте таким образом: не позволяет стандарт
D>>
D>>tlist::head h; //тут будет ошибочка
D>>TypeList<........>::head h1; //тут гут
D>>
D>>В чем тут сложность у компилятора то?
MN>Я так думаю, что проблема чисто идиологическая... Пример, поскольку ссылки фактически являются синонимами объектов, то если разрешить запись obj::some_type для объектов, то нужно разрешить и такую же запись для ссылок... MN>
MN>class Base
MN>{
MN>public:
MN> typedef int SomeType;
MN>};
MN>class Child : public Base
MN>{
MN>public:
MN> typedef double SomeType;
MN>};
MN>void func(Base &ref)
MN>{
MN> ref::SomeType testVal;
MN>}
MN>int _tmain(int argc, _TCHAR* argv[])
MN>{
MN> Child objChild;
MN> Base objBase;
MN> Base &ref1 = objChild;
MN> Base &ref2 = objBase;
MN> func(ref1);
MN> func(ref2);
MN>}
MN>
MN>Какой тип должен быть у testVal при обоих вызовах func? Так как ref1 — это ссылка на Child, а ref2 — на Base, то в первом случае ref::SomeType должен быть double, а во втором int. Но эта информация может быть получена только во время исполнения программы, а информация о типах в C++ фактически присутствует только на этапе компиляции (RTTI не в счёт). То есть жёсткая типизация языка летит в тартар и мы получаем SmallTalk . MN>Всё это чистое IMHO, не претендующее на тезисы
В данном примере ненадо никаких сложностей придумавать, это у тебя не virtual typedef,так что тут именно тип int, т.е. от Base.
Здравствуйте, Mr. None, Вы писали:
MN>Я так думаю, что проблема чисто идиологическая... Пример, поскольку ссылки фактически являются синонимами объектов, то если разрешить запись obj::some_type для объектов, то нужно разрешить и такую же запись для ссылок...
<>
MN>Какой тип должен быть у testVal при обоих вызовах func? Так как ref1 — это ссылка на Child, а ref2 — на Base, то в первом случае ref::SomeType должен быть double, а во втором int. Но эта информация может быть получена только во время исполнения программы, а информация о типах в C++ фактически присутствует только на этапе компиляции (RTTI не в счёт). То есть жёсткая типизация языка летит в тартар и мы получаем SmallTalk .
Ну почему же. Статическая жёсткая типизация как была, так и осталась.
Base& ref имеет тип Base&, следовательно, ref::SomeType это int.
Больше того, с помощью некоторых танцев с бубном можно выцарапать информацию о типе. Например, частичная специализация шаблонов.
PS.
Ссылка — это не синоним! Не надо до такой степени упрощать понимание.
Здравствуйте, Кодт, Вы писали:
К>Ну почему же. Статическая жёсткая типизация как была, так и осталась. К>Base& ref имеет тип Base&, следовательно, ref::SomeType это int.
Тогда просто не вижу смысла в ref::SomeType, когда можно написать Base::SomeType — как мне кажется, так понятней и меньше путаницы... Хотя если честно, то где-то в глубине души я тоже хотел бы, чтобы было возможно написать my_map_obj::iterator, вместо std::map<std::string, std::vector<long double> >::iterator
К>Больше того, с помощью некоторых танцев с бубном можно выцарапать информацию о типе. Например, частичная специализация шаблонов.
Это опять таки будет информация периода компиляции, чтобы реализовать то, что я привёл в качестве примера, понятие типа данных должно присутствовать во время исполнения, а в C++ на этапе исполнения эта информация отсутсвует (RTTI не катит ).
К>PS. К>Ссылка — это не синоним! Не надо до такой степени упрощать понимание.
Ок, не буду
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Здравствуйте, Denwer, Вы писали:
D>И вопрос в догонку: почему С++ не позволяет делать следующее: D>ЗЫ: Плиз не отвечайте таким образом: не позволяет стандарт
D>
D>tlist::head h; //тут будет ошибочка
D>TypeList<........>::head h1; //тут гут
D>
D>В чем тут сложность у компилятора то?
Так tlist вроде как переменная, а TypeList<........> всё таки тип.
.
Перекуём баги на фичи!
