Цитата
Функция GetDlgItem(...) - это тоже метод класса Вашего диалога, из которого Вы её вызываете!
Спасибо, разъяснили.
Цитата
Вот. Это и есть образ мышления программиста, привыкшего к статическому программированию ! Так было, когда программисты хранили данные в структурах и обращались к ним по имени полей. И опять летят камни в адрес Microsoft ...
На самом деле MS тут ни при чём. Вы затронули один из краеугольных камней ООП, именуемый инкапсуляцией - это не только объединение кода и данных внутри объекта, как думают многие начинающие программеры. Это ещё и разделение интерфейса и реализации объекта (public, protected, private), а также сокрытие реализации, но не от разработчика, а от ошибок. Рассмотрим Ваш пример внимательнее.
pMyButton1->Text = "My New Button";
Это аварийный код по определению. Объясню почему.
1. Что за поле Text ? Если это указатель на строку, то его содержание будет утеряно, как только будет разрушена константа "My New Button" - и это произойдёт по выходу из локальной функции. Будет ошибка доступа к памяти.
2. Если это объект класса CString, то не надо заниматься самообманом - за оператором присваивания = стоит работа тех же методов класса CString, которые скопируют Вашу константу к себе в "недра".
3. А как Вы узнали при присваивании, что хватит памяти для Вашей строки ?
4. А Вы уверены, что поле Text есть внутри ?
В том то и дело, что прямой доступ к данным внутри объекта всегда чреват разрушением объекта из-за несоответствия данных размерам памяти. И вообще, динамическое программирование подразумевает, что память под данные (возможно, гигантского объёма) выделяется и освобождается динамически, и никогда "снаружи" класса неизвестно, сколько памяти и для чего уже выделено внутри объекта. Об этом "знает" только сам объект и поэтому он сам рулит менеджментом внутри, а снаружи только интерфейс из функций. Так что это не "бага" - это "фича", это надо прочувствовать, прелесть того, что ты не обязан помнить, какой длины массив у тебя, и ты всегда можешь безопасно добавить в него ещё один элемент !!!
Спасибо за обстоятельное пояснение.
Цитата
...а также сокрытие реализации, но не от разработчика, а от ошибок.
Понимаю: разработчик - причина ошибок.
Со строковым полем это я конечно загнул - последствия борланда, но с переменными типа int, например, ситуация не лучше. А что касается безопасного кода, это конечно словоблудие, философия, но кто ответит за баг в мое программе, возникающий по причине того, что MS чего-то там намутили? Любая кажущаяся простота упирается как правило в расслабленность программиста. Тем не менее, фичу прочувствовал!

Вот только ирония в мозгах возникает (это не про Вас) - многие из тех кто програмят на MFC они еще про динамические структуры дальше указателя на переменную чего-нибудь помнят\знают?
Цитата
здесь
pMyButton1->Text = "My New Button";
судя по всему подразумевалось "свойство", а не просто переменная-член, так что с точки зрения ООП тут все путем - это просто "сокращенная" форма записи вызова метода
pMyButton1->SetText("My New Button");
, активно используемая сугубо борландовским компилятором, как расширение в C++.
Согласен, так оно и есть.
Цитата
IMHO польза от такого расширения минимальна, зато вред (в плане переносимости) очевиден.
IMHO в случае написания под конкретный GUI в конкретной среде разработки не о какой переносимости речи вообще не может идти.