Здравствуйте, Аноним, Вы писали:

L>>А что делать ненормальным?
А>Задуматься, с чего это у них this == 0

VC позволяет вызвать метод класса, если он не виртуацльный, через нулевой указатель.

class A
{
public:
    void Method()
    {
        void* p = this;
    }
};

int main()
{
    A* a = NULL;
    a->Method();
    return 0;
}

ЗЫ
Наверно так исторически сложилось.
В M$ работает много индусов, среди которых не принято проверять укзатели, коды возвратов и пр.

я например, subj присал.

class TreeItem
{
public:
 TreeItem* m_pRightHand;
 TreeItem* m_pLeftHand;
 void KillSubTree()
 {
   if ( pRightHand )pRightHand->KillSubTree();
   if ( pLeftHand  )pLeftHand->KillSubTree();
   delete this;
 };
};

Здравствуйте, <Аноним>, Вы писали:


L>>А плохо от такого не будет?
А>если отвлечься от явной ненужности такого кода, вполне можно написать
А>

А>class A
А>{
А>public:
А>   operator A *()
А>   {return this;}
А>   void fun(){delete *this;}
А>};
А>

Написать можно. Но что будет? Имхо будет плохо. Это не так давно обсуждалось, только я так и не проникся, к чему же все-таки такое приведет?

RB>VC позволяет вызвать метод класса, если он не виртуацльный, через нулевой указатель.

Дак это известно. А идея про подлых индусов

Здравствуйте, Аноним, Вы писали:

>А идея про подлых индусов

Другой причины для функций типа GetSafeHwnd я не вижу...

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

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

RB>Потому что this может быть NULL-ом.
RB>Смотрите код CWnd::GetSafeHwnd() для примера.

Так и знал, что к этому придет ПОИСК рулит! Undefined behavior! Млин.

ssm>Собственно сабж.

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

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

LM>я например, subj присал.

LM>

LM>class TreeItem
LM>{
LM>public:
LM> TreeItem* m_pRightHand;
LM> TreeItem* m_pLeftHand;
LM> void KillSubTree()
LM> {
LM>   if ( pRightHand )pRightHand->KillSubTree();
LM>   if ( pLeftHand  )pLeftHand->KillSubTree();
LM>   delete this;
LM> };
LM>};
LM>

с таким кодом надо быть осторожнее... А если TreeItem будет объявлен так:

class Tree
{
public:
    TreeItem root;
}

То вызов KillSubTree хорошего ничего не сделает, это уж точно. Я бы сказал, что это плохая идея.

Здравствуйте, Leshi, Вы писали:
L>То вызов KillSubTree хорошего ничего не сделает, это уж точно. Я бы сказал, что это плохая идея.
Там был более сложный пример на эту тему. Но прога доблестно работает и по сей момент

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

L>с таким кодом надо быть осторожнее... А если TreeItem будет объявлен так:
L>

TreeItem root;
L>

Да чего осторожничать? Закрыть все конструкторы и сделать производящую функцию/фабрику-шмабрику

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

L>>с таким кодом надо быть осторожнее... А если TreeItem будет объявлен так:
L>>

ssm>TreeItem root;
L>>

ssm>Да чего осторожничать? Закрыть все конструкторы и сделать производящую функцию/фабрику-шмабрику
Мне кажется, что такой подход в данном случае не оправдан. Убийство поддерева можно было и в деструктор повесить. Да и кода меньше было бы, и читабельность повыше... Хотя, конечно, это могло быть обусловлено другими требованиями. Но я бы так все-равно делать не стал.

Здравствуйте, <Аноним>, Вы писали:


L>>А плохо от такого не будет?

А>если отвлечься от явной ненужности такого кода, вполне можно написать

А>

А>class A
А>{
А>public:
А>   operator A *()
А>   {return this;}
А>   void fun(){delete *this;}
А>};
А>

Почему же сразу и ненужности, а как насчет реализации класса с подсчетом ссылок

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

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

L>>>Что-то мне подсказывает, что в TC 2.0 (задолго до С++) я уже использовал ссылки... Или я все-таки не прав?
L_L>>Задолго до С++ == это ты еще в 70х писал и использовал TC 2.0 ?????
L>Нет, в 70х меня только проектировали. Но ТС 2.0 это начало 80-х. Если память моя не глючит, С++ в то время даже под стол пешком не ходил.
Нет, не начало... 88-й вроде... Или 89-й.

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

L>>>>Что-то мне подсказывает, что в TC 2.0 (задолго до С++) я уже использовал ссылки... Или я все-таки не прав?
L_L>>>Задолго до С++ == это ты еще в 70х писал и использовал TC 2.0 ?????
L>>Нет, в 70х меня только проектировали. Но ТС 2.0 это начало 80-х. Если память моя не глючит, С++ в то время даже под стол пешком не ходил.
_>Нет, не начало... 88-й вроде... Или 89-й.
Эх, не нашел такого раритета у себя. Вот ВС++ 3.1 датирован 92 годом Из этого можно предтоложить, что ТС++ 3.0 был в году этак 90-91, а вот ТС 2.0 думаю, что все-таки не позже 85 (уж очень много там изменилось) Хотя, чисто теоретически, он мог выйти и в 92, только чуть-раньше Однако, я не думаю, что его успели бы сертифицировать для военных нужд к тому времени. Это обычно 3-5 лет занимает, а я точно знаю, что в 93 он уже был сертефицирован и какое-то время уже использовался.

2All: Может быть кто-нибудь раскопает ТС 2.0 у себя в архивах да посмотрит? Уже самому итересно стало

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

L>2All: Может быть кто-нибудь раскопает ТС 2.0 у себя в архивах да посмотрит? Уже самому итересно стало

TC 2.0 датирован 1988 годом, imho. TC++ 1.0 — где-то 1989 (во всяком случае, в конце 1989 г. видел его IDE).
а вот TC++ 3.0, imho, сильно урезанный BC++ 3.x (нет IDE для Windows и много чего еще). Кстати, и в обзорах тогда я его не встречал.
Откровенно говоря, совершенно не помню, были ли уже ссылки в TC++ 1.0.

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

L>Что-то мне подсказывает, что в TC 2.0 (задолго до С++) я уже использовал ссылки...

Никаких ссылок в TC 2.0 не было и быть не могло — это ж классический ANSI C