А>ЗЫ ... взять ту же MFC — где от версии к версии они творят, что хотят.
Гх-м-м... прошу прощения, что влезаю — можно об этом поподробнее? Я несколько своих проектов, написанных на MFC 4.21 компилил 7-й студией (в экспериментальных целях) и ничего плохого не заметил, все компилилось и работало без единой ошибки. Поскольку в перспективе переход на 7.0/7.1 неотвратим, хотелось бы Ваших пояснений по поводу выделенного текста.
А>>ЗЫ ... взять ту же MFC — где от версии к версии они творят, что хотят.
SDB>Гх-м-м... прошу прощения, что влезаю — можно об этом поподробнее? Я несколько своих проектов, написанных на MFC 4.21 компилил 7-й студией (в экспериментальных целях) и ничего плохого не заметил, все компилилось и работало без единой ошибки. Поскольку в перспективе переход на 7.0/7.1 неотвратим, хотелось бы Ваших пояснений по поводу выделенного текста.
Вот тебе две проблемы, с которыми я столкнулся:
1. Выкинули Construct/DestructElements — пришлось переделывать контейнеры (я имею ввиду CArray, CMap и т.д). Сразу говорю: я от MFC-шных контейнеров отказался давно, поэтому у меня проблем не было, а вот у моих товарищей — были.
2. Ошибка в CFileDialog — в результате все работает под Win2000/XP и не работает под WinNT4 и Win9x. Кстати, эту ошибку в MFC7.1 они таки поправили. Ошибка связана с тем, что в конструктор ввели параметр по умолчанию dwSize — размер структуры OPENFILENAME. Так вот, в MFC7.0 этот параметр на этапе компиляции жестко задается как sizeof(OPENFILENAME) — а размеры то разные в разных OS. В MFC7.1 его поменяли на 0.
Это в принципе пока все, с остальным пока проблем нет, вроде
ЗЫ В MFC7.1 все, что связано с DAO — объявлено deprecated, но слава Богу, пока не убрано.
Здравствуйте, Андрей, Вы писали:
А>1. Выкинули Construct/DestructElements — пришлось переделывать контейнеры (я имею ввиду CArray, CMap и т.д). Сразу говорю: я от MFC-шных контейнеров отказался давно, поэтому у меня проблем не было, а вот у моих товарищей — были.
Вы знаете, мне как-то не приходилось явным образом вызывать эти функции, хотя MFC-шные контейнеры я использую достаточно интенсивно (собственно, только их и использовал до недавненго времени). Надеюсь, что их "выкидывание" не отразилось на корректности работы самих контейнеров. Или я слишком наивен?
А>2. Ошибка в CFileDialog — в результате все работает под Win2000/XP и не работает под WinNT4 и Win9x. Кстати, эту ошибку в MFC7.1 они таки поправили. Ошибка связана с тем, что в конструктор ввели параметр по умолчанию dwSize — размер структуры OPENFILENAME. Так вот, в MFC7.0 этот параметр на этапе компиляции жестко задается как sizeof(OPENFILENAME) — а размеры то разные в разных OS. В MFC7.1 его поменяли на 0.
Да, неприятная "фича", ничего не скажешь. Буду иметь ввиду.
А>Это в принципе пока все, с остальным пока проблем нет, вроде
Не так и страшно, как мне кажется.
А>ЗЫ В MFC7.1 все, что связано с DAO — объявлено deprecated, но слава Богу, пока не убрано.
Слава Богу , DAO я не юзал, не юзаю, и не собираюсь. Предпочитаю ODBC или нативные интефейсы (типа OCI для Oracle).
Огромное спасибо за интересный и поучительный ответ.
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Здравствуйте, Андрей, Вы писали:
А>>1. Выкинули Construct/DestructElements — пришлось переделывать контейнеры (я имею ввиду CArray, CMap и т.д). Сразу говорю: я от MFC-шных контейнеров отказался давно, поэтому у меня проблем не было, а вот у моих товарищей — были. SDB>Вы знаете, мне как-то не приходилось явным образом вызывать эти функции, хотя MFC-шные контейнеры я использую достаточно интенсивно (собственно, только их и использовал до недавненго времени). Надеюсь, что их "выкидывание" не отразилось на корректности работы самих контейнеров. Или я слишком наивен?
skip
Нет, если не используешь свои функции Construct/Destruct, все работает
Здравствуйте, Андрей, Вы писали:
А>Нет, если не используешь свои функции Construct/Destruct, все работает
Это хорошо. Еще вопрос, если можно : насколько... э-э-э... "успешно" компилятор 7.1 собирает крупные MFC-шные проекты? Помню, у нас тут проскакивало мнение, что он сыроват и имеет привычку "вылетать" с internal compiler error.
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Здравствуйте, Андрей, Вы писали:
А>>Нет, если не используешь свои функции Construct/Destruct, все работает
SDB>Это хорошо. Еще вопрос, если можно : насколько... э-э-э... "успешно" компилятор 7.1 собирает крупные MFC-шные проекты? Помню, у нас тут проскакивало мнение, что он сыроват и имеет привычку "вылетать" с internal compiler error.
internal compiler error — обычно следствие ошибки в коде. Если код без ошибок, то все отлично компилируется. В нашем проекте 900 файлов (CPP & H)
Здравствуйте, vgrigor, Вы писали:
V>Бываю обоснованные поправки, V> а бывают и всякие -под них маскируемые.
Это, я так понимаю, как в анекдоте (не помню, как он точно звучит, но где-то так):
Компания Microsoft выступила с заявлением, что впредь, все ошибки их программных продуктов принято называть не багами, а особенностями и внести их описание в документацию.
skip
SDB>Это хорошо. Еще вопрос, если можно : насколько... э-э-э... "успешно" компилятор 7.1 собирает крупные MFC-шные проекты? Помню, у нас тут проскакивало мнение, что он сыроват и имеет привычку "вылетать" с internal compiler error.
Не замечал. У меня, наоборот, компилятор стал гораздо стабильнее по сравнению с шестеркой. Правда, это про 7.0, на 7.1 я в тестовых целях несколько раз собирал свой проект — тоже без проблем (мы на него пока еще только собираемся переходить).
Правда, я не уверен, что мой проект крупный — ядро компиляется примерно 20 минут на P4-2.4HGz с 1GB памяти.
Здравствуйте, SchweinDeBurg, Вы писали:
А>>ЗЫ ... взять ту же MFC — где от версии к версии они творят, что хотят.
SDB>Гх-м-м... прошу прощения, что влезаю — можно об этом поподробнее? Я несколько своих проектов, написанных на MFC 4.21 компилил 7-й студией (в экспериментальных целях) и ничего плохого не заметил, все компилилось и работало без единой ошибки. Поскольку в перспективе переход на 7.0/7.1 неотвратим, хотелось бы Ваших пояснений по поводу выделенного текста.
Я не знаю, может я не везучий, но на первом же моём проекте, которые я хотел перенести, вылетела куча ошибок.
1. CString теперь не тот. Он теперь
Здравствуйте, tyomchick, Вы писали:
T>Я не знаю, может я не везучий, но на первом же моём проекте, которые я хотел перенести, вылетела куча ошибок. T>1. CString теперь не тот. Он теперь T>
Ну и что? Если код правильно написан, то для вас должно быть все равно...
T>Эт вносит ряд проблем, хотя методы не поменялись ... а вот атрибуты да. Так что пришлось править.
Так вы, видимо, не объектно-ориентированно пИшете. Если бы вы писали объектно-ориентированно, вам было бы все равно, поменялись атрибуты или нет. Они же скрыты. Называется "инкапсуляция" — сокрытие данных. Один из трех китов ООП.
Здравствуйте, Serguei666, Вы писали:
S>Здравствуйте, tyomchick, Вы писали:
T>>Я не знаю, может я не везучий, но на первом же моём проекте, которые я хотел перенести, вылетела куча ошибок. T>>1. CString теперь не тот. Он теперь T>>
S>Ну и что? Если код правильно написан, то для вас должно быть все равно...
Что значит правильно? Эт понятие относительное. T>>Эт вносит ряд проблем, хотя методы не поменялись ... а вот атрибуты да. Так что пришлось править. S>Так вы, видимо, не объектно-ориентированно пИшете. Если бы вы писали объектно-ориентированно, вам было бы все равно, поменялись атрибуты или нет. Они же скрыты.
Какой пафос )). Если бы открытые атребуты не соответствовали ООП, их бы вообще не было. Иногда очень полезно их открыть. В прочем это не имеет отношение к делу.
Просто в староМ стринге был такой атрибут
protected:
LPTSTR m_pchData; // pointer to ref counted string data
И как ты наверно понимаешь при public-наследовании от CString он открывался. Но к сожалению в Atl-строке такого атрибута нет в следствии чего глюк. Так что всё по правилам и в соответствии )))
S> Называется "инкапсуляция" — сокрытие данных. Один из трех китов ООП. а я и не знал
Даже самую простую задачу можно сделать невыполнимой, если провести достаточное количество совещаний
Здравствуйте, tyomchick, Вы писали:
S>>Ну и что? Если код правильно написан, то для вас должно быть все равно... T>Что значит правильно? Эт понятие относительное.
Да, действительно.
В моем понимании "правильно" — это в соответствии с теорией программирования, которой вас наверняка научили в институте.
T>>>Эт вносит ряд проблем, хотя методы не поменялись ... а вот атрибуты да. Так что пришлось править. S>>Так вы, видимо, не объектно-ориентированно пИшете. Если бы вы писали объектно-ориентированно, вам было бы все равно, поменялись атрибуты или нет. Они же скрыты. T>Какой пафос )).
Не вижу никакого пафоса. Я вам расскзываю то, чему меня учили.
T>Если бы открытые атребуты не соответствовали ООП, их бы вообще не было. Иногда очень полезно их открыть. В прочем это не имеет отношение к делу. T>Просто в староМ стринге был такой атрибут
T>
T>protected:
T> LPTSTR m_pchData; // pointer to ref counted string data
T>
T>И как ты наверно понимаешь при public-наследовании от CString он открывался. Но к сожалению в Atl-строке такого атрибута нет в следствии чего глюк. Так что всё по правилам и в соответствии )))
Использование недокументированного атрибута класса — это НЕ по правилам и НЕ в соответствии. Это и есть ваша ошибка. Вы не должны использовать m_pchData в вашем коде напрямую.
S>> Называется "инкапсуляция" — сокрытие данных. Один из трех китов ООП. T> а я и не знал
Ну вот видите, ваши знания не позволяют вам избежать ошибок. Это значит, что вы не умеете ими пользоваться.
S>>>Ну и что? Если код правильно написан, то для вас должно быть все равно... T>>Что значит правильно? Эт понятие относительное. S>Да, действительно. S>В моем понимании "правильно" — это в соответствии с теорией программирования, которой вас наверняка научили в институте.
Что ещё за теория программиролвания? А в институте мне кром5е всего прочего говорили, не надо идеологию ООП до обсурда доводить, "назакрываете всё что можно, а потом пишите десятки Set..., Get...".
S>>>Так вы, видимо, не объектно-ориентированно пИшете. Если бы вы писали объектно-ориентированно, вам было бы все равно, поменялись атрибуты или нет. Они же скрыты. T>>Какой пафос )). S>Не вижу никакого пафоса. Я вам расскзываю то, чему меня учили.
"Объектгноориентированность" длалеко не определяеться иснкопсуляцией, эт есть правило а не закон.
T>>Просто в староМ стринге был такой атрибут
T>>
T>>protected:
T>> LPTSTR m_pchData; // pointer to ref counted string data
T>>
T>>И как ты наверно понимаешь при public-наследовании от CString он открывался. Но к сожалению в Atl-строке такого атрибута нет в следствии чего глюк. Так что всё по правилам и в соответствии ))) S>Использование недокументированного атрибута класса — это НЕ по правилам и НЕ в соответствии. Это и есть ваша ошибка. Вы не должны использовать m_pchData в вашем коде напрямую.
Ну во первых класс наследник писал не я, это из библиотеки Ultimate Toolbox, хотя я не вижу в этом ничего предосудительного. И заголовочный файл считаю таким же документом (в общем то это так и есть).
S>>> Называется "инкапсуляция" — сокрытие данных. Один из трех китов ООП. T>> а я и не знал S>Ну вот видите, ваши знания не позволяют вам избежать ошибок. Это значит, что вы не умеете ими пользоваться.
Я всё же думаю что это явный недосмотр Microsoft. m_pchData являлся частью интерфейса класса при определённых условиях и его не надо было менять. Другое дело что менять пишлось всего одну строчку кода в моём случае, и меня это не сильно побеспокоило (правда придёться теперь таскать всю 10 метровую библиотеку вместе с исходниками).
Совсем другое дело с поддержкой справки ... пришлось переписывать полностью.
Даже самую простую задачу можно сделать невыполнимой, если провести достаточное количество совещаний
Здравствуйте, tyomchick, Вы писали:
S>>>>Ну и что? Если код правильно написан, то для вас должно быть все равно... T>>>Что значит правильно? Эт понятие относительное. S>>Да, действительно. S>>В моем понимании "правильно" — это в соответствии с теорией программирования, которой вас наверняка научили в институте. T>Что ещё за теория программиролвания?
Совокупность предметов, которые преподают на мей специальности 2204, например. "ООП" — в их числе.
T>А в институте мне кром5е всего прочего говорили, не надо идеологию ООП до обсурда доводить, "назакрываете всё что можно, а потом пишите десятки Set..., Get...".
Так именно это и называется "инкапсуляция". Вас что, учили, что инкапсуляция есть абсурд? Странно. С моей точки зрения у класса вообще не должно быть public переменных. Так что "назакрываеть всё что можно, а потом писать десятки Set..., Get..." — это именно то, что нужно делать. И я именно так и делаю, причем давно.
S>>>>Так вы, видимо, не объектно-ориентированно пИшете. Если бы вы писали объектно-ориентированно, вам было бы все равно, поменялись атрибуты или нет. Они же скрыты. T>>>Какой пафос )). S>>Не вижу никакого пафоса. Я вам расскзываю то, чему меня учили. T>"Объектгноориентированность" длалеко не определяеться иснкопсуляцией, эт есть правило а не закон.
Не определяется. "Необходимо, но недостаточно". Инкапсуляция — это всего лишь одна из составляющих. Одной инкапсуляции недостаточно, есть еще и другие элементы, без которых ваш код нельзя будет считать объектноориентированным.
А насчет "правило а не закон" — конечно, не закон. C++ язык мощный и гибкий и позволяет вам делать все, что вы захотите, в том числе и ошибатся в дизайне. А плата за ошибки — это невозможность быстро перейти на Visual7
T>>>И как ты наверно понимаешь при public-наследовании от CString он открывался. Но к сожалению в Atl-строке такого атрибута нет в следствии чего глюк. Так что всё по правилам и в соответствии ))) S>>Использование недокументированного атрибута класса — это НЕ по правилам и НЕ в соответствии. Это и есть ваша ошибка. Вы не должны использовать m_pchData в вашем коде напрямую. T>Ну во первых класс наследник писал не я, это из библиотеки Ultimate Toolbox,...
В таком случае это не ваша ошибка, а ошибка производителя продукта Ultimate Toolbox. У нас в компании, например, в таких случаюх просто покупают у производителя новую версию, оптимизированную под Visual7. Если это их ошибка, то голова болеть об этом должна у них.
T>...хотя я не вижу в этом ничего предосудительного.
В чем не видете ничего предосудительного? В том, что Ultimate Toolbox использует недокументированные переменные? Вообще такого лучше избегать.
T>И заголовочный файл считаю таким же документом (в общем то это так и есть).
Это неверно. Документом является MSDN. Все, что не в MDSN, считается недокументированным. Если бы C++ позволял, вам бы никто заголовочных файлов не предоставлял. А то вот предоставишь таким как этот производитель Ultimate Toolbox, они попользуются неумеючи, а потом на Visual 7 пеняют. Хотя Visual 7 тут ни при чем.
S>>>> Называется "инкапсуляция" — сокрытие данных. Один из трех китов ООП. T>>> а я и не знал S>>Ну вот видите, ваши знания не позволяют вам избежать ошибок. Это значит, что вы не умеете ими пользоваться. T>Я всё же думаю что это явный недосмотр Microsoft.
Во-во. Именно так. "Му-му написал Тургенев, а памятник почему-то Пушкину." Ошибся Ultimate Toolbox, а виноват Microsoft. Вот почему-то все так думают, хотя это в корне неверно. Раз ошибся Ultimate Toolbox, то он и виноват, не находите?
T>m_pchData являлся частью интерфейса класса при определённых условиях
Интерфейсом класса является все, что описано в MSDN. Смотрим на CString документацию. Упоминания m_pchData не находим. Вывод — то, что вы написали — ошибка. m_pchData НЕ являлся частью интерфейса класса.
T>и его не надо было менять.
Постулат, следующий из ошибочного постулата, сам является ошибочным. Надеюсь, понятно, почему...
T>Другое дело что менять пишлось всего одну строчку кода в моём случае, и меня это не сильно побеспокоило (правда придёться теперь таскать всю 10 метровую библиотеку вместе с исходниками).
Зачем таскать? Купите Update у Ultimate Toolbox. Это будет верным решением.
T>Совсем другое дело с поддержкой справки ... пришлось переписывать полностью.
Про это я ничго сказать не могу. Help я не писал.
Здравствуйте, Serguei666, Вы писали:
S>Здравствуйте, tyomchick, Вы писали:
T>>Что ещё за теория программиролвания? S>Совокупность предметов, которые преподают на мей специальности 2204, например. "ООП" — в их числе.
Там нигде не говорится, что запрещены открытые атребуты.
T>>А в институте мне кроме всего прочего говорили, не надо идеологию ООП до обсурда доводить, "назакрываете всё что можно, а потом пишите десятки Set..., Get...".
S>Так именно это и называется "инкапсуляция". Вас что, учили, что инкапсуляция есть абсурд?
Нет, имеется ввиду то, что не неследует злоупотреблять философией ООП, там где это не разумно. Инкапсуляция это только инструмент, но применение его не обязательно. Вы же надеюсь не наслеждуете всё от CObject или ещё от чего только потому, что наследование один из "китов" ООП.
S, Странно. С моей точки зрения у класса вообще не должно быть public переменных.
Это ваше право иметь свою точку зрения, но ненадо считать что код, соответствующий только вашей точке зрения может считаться ОО .
S>Так что "назакрываеть всё что можно, а потом писать десятки Set..., Get..." — это именно то, что нужно делать. И я именно так и делаю, причем давно.
Это не всегда есть разумно.
T>>"Объектгноориентированность" длалеко не определяеться иснкопсуляцией, эт есть правило а не закон. S>Не определяется. "Необходимо, но недостаточно".
Это не есть "необходимо", точнее не всегда.
Инкапсуляция — это всего лишь одна из составляющих. Одной инкапсуляции недостаточно, есть еще и другие элементы, без которых ваш код нельзя будет считать объектноориентированным. глупость S>А насчет "правило а не закон" — конечно, не закон. C++ язык мощный и гибкий и позволяет вам делать все, что вы захотите, в том числе и ошибатся в дизайне.
Также это позволяет SmallTalk, Object Pascal, C#, VB ...
А плата за ошибки — это невозможность быстро перейти на Visual7
T>>И заголовочный файл считаю таким же документом (в общем то это так и есть). S>Это неверно. Документом является MSDN. Все, что не в MDSN, считается недокументированным. Если бы C++ позволял, вам бы никто заголовочных файлов не предоставлял. А то вот предоставишь таким как этот производитель Ultimate Toolbox, они попользуются неумеючи, а потом на Visual 7 пеняют. Хотя Visual 7 тут ни при чем.
S>>>>> Называется "инкапсуляция" — сокрытие данных. Один из трех китов ООП. T>>>> а я и не знал S>>>Ну вот видите, ваши знания не позволяют вам избежать ошибок. Это значит, что вы не умеете ими пользоваться. T>>Я всё же думаю что это явный недосмотр Microsoft. S>Во-во. Именно так. "Му-му написал Тургенев, а памятник почему-то Пушкину." Ошибся Ultimate Toolbox, а виноват Microsoft. Вот почему-то все так думают, хотя это в корне неверно. Раз ошибся Ultimate Toolbox, то он и виноват, не находите?
T>>m_pchData являлся частью интерфейса класса при определённых условиях S>Интерфейсом класса является все, что описано в MSDN.
Эт что, ещё один кит ООП? Неужели и компилятор заглядывает в MSDN и выдаёт ошибки если чего то там не находит?
Предлагаю закрыть разговор потому как он становиться безпредметным.
Даже самую простую задачу можно сделать невыполнимой, если провести достаточное количество совещаний
Здравствуйте, tyomchick, Вы писали:
T>S, Странно. С моей точки зрения у класса вообще не должно быть public переменных. T>Это ваше право иметь свою точку зрения, но ненадо считать что код, соответствующий только вашей точке зрения может считаться ОО .
Жизнь вам показывает, кто прав, а кто нет. Ваш проект при переходе на Visual 7 имел проблемы, а мой — нет. Вот и делайте выводы.
S>>Так что "назакрываеть всё что можно, а потом писать десятки Set..., Get..." — это именно то, что нужно делать. И я именно так и делаю, причем давно. T>Это не всегда есть разумно.
Можете привести пример, когда это неразумно?
T>>>"Объектгноориентированность" длалеко не определяеться иснкопсуляцией, эт есть правило а не закон. S>>Не определяется. "Необходимо, но недостаточно". T>Это не есть "необходимо", точнее не всегда. T>Инкапсуляция — это всего лишь одна из составляющих. Одной инкапсуляции недостаточно, есть еще и другие элементы, без которых ваш код нельзя будет считать объектноориентированным. T> глупость
Не надо так. Если называете что-то "глупостью" — потрудитесь объяснить почему. Иначе вы начинаете быть похожим на малыша из песочницы.
T>>>m_pchData являлся частью интерфейса класса при определённых условиях S>>Интерфейсом класса является все, что описано в MSDN. T>Эт что, ещё один кит ООП?
При чем тут кит? MDSN является документацией. Все, что там не упоминается, является недокументированным. Следовательно, вы используете это на свой страх и риск и несете ответственность за это. Не Microsoft, а вы (ну, в данном случае не вы лично, а производители этой самой Ultimate Toolbox).
T> Неужели и компилятор заглядывает в MSDN и выдаёт ошибки если чего то там не находит?
При чем тут это? Я говорю, что если используете недокументированные функции, будьте готовы к неприятностям при переходе на новые версии Visual и не вините в этом Microsoft.
T>Предлагаю закрыть разговор потому как он становиться безпредметным.
Хорошо. На ваш следующий пост (если он последует) я отвечать не буду, если вы специально не попросите.
Не мог не ответь на ваш пост, так как меня тут Малышом из песочницы обозвали.
S>Жизнь вам показывает, кто прав, а кто нет. Ваш проект при переходе на Visual 7 имел проблемы, а мой — нет. Вот и делайте выводы.
Вопрос в том кто в этом виноват. Я отнюдь не вхожу стройные ряды пинателей мелкомягких, но всё же думаю что в данном случае они поступили не совсем разумно.
S>>>Так что "назакрываеть всё что можно, а потом писать десятки Set..., Get..." — это именно то, что нужно делать. И я именно так и делаю, причем давно. T>>Это не всегда есть разумно. S>Можете привести пример, когда это неразумно?
В MFC десятки открытых атребутов. Найдите в MSDN указатель "Data members" и посмотрите список классов за ним. Как же вы пользуетесь необъектноориентированной библиотекой? Может напишите в Microsoft, расскажите что их код не может считаться ОО и попросите прислать вам апгрейд?
На счёт примера. Скажем некоторые методы класса выполняют некоторые расчёты или операции другого рода. При этом они используют некоторые параметры, которые явяляются достаточно постоянными и не требующими частого изменения,что делает разумным хранение этих параметров в данных объкта класса (причиной так же может быть необходимость передача этих параметров в другие, возможно скрытые, методы). При этом эти параметры не имеют ограничение на значение или проверка этих значений не имеет смысла и гораздо эффективнее обойтись скажем ASSERT-ом, который можно разместить в вызывающей процедуре (в сущности какая разница где глюк обнаружится). Какой смысл делать GetSet-ы?
Вот в MFC например валидность многих хендлов проверяеться (ASSERT-ом) непосредственно перед операциями с нимию. T>>Инкапсуляция — это всего лишь одна из составляющих. Одной инкапсуляции недостаточно, есть еще и другие элементы, без которых ваш код нельзя будет считать объектноориентированным. T>> глупость S>Не надо так. Если называете что-то "глупостью" — потрудитесь объяснить почему. Иначе вы начинаете быть похожим на малыша из песочницы.
Ну ё моё. Ну сколько можно. Повторяю, инкапсуляция это лишь инструмент, который позволяет скрыть детали реализации, там где это необходимо. А внесение открытого атрибута не делает код менее ОО. Тут можно говорить о стиле, во многих книгах пишут что открытые данные это "плохой стиль", но мало кто ради "хорошести стиля" будет закрывать и писать ненужные GetSet-ы (таже песня с goto, неодной сколько нибудь сеьёзно й библиотеки не обходиться без него). Вот поэтому я и назвал фразу "... код нельзя будет считать объектноориентированным.", и не надо мне тут дешовых наскоков про песочницу, это не серьёзно. T>>>>m_pchData являлся частью интерфейса класса при определённых условиях S>>>Интерфейсом класса является все, что описано в MSDN. T>>Эт что, ещё один кит ООП? S>При чем тут кит? MDSN является документацией.
Я всё же наставиваю на том, что протокол класса являеться документом.
T>>Предлагаю закрыть разговор потому как он становиться безпредметным. S>Хорошо. На ваш следующий пост (если он последует) я отвечать не буду, если вы специально не попросите.
Даже самую простую задачу можно сделать невыполнимой, если провести достаточное количество совещаний
Важнее — политика приеемственности при написании библиотеки.
Если открытый атрибут — его будут использовать и это очевидно.
Раз это очевидно, то надо либо признавать,
что новая версия по определенным причинам не совместима — и поставлять утилиту предбразования,
а не получать сообщение о неизвестных ошибках.
Либо сообщить что MS плохо разработало принции библиотеки по важному критерию приемственности.
Во всяком случае плохо что микрософт открыто не опубликовала список рпоблем и их решений,
— копайтесь сами — у нас есть новое слово — "стандарт".
, DAO я не юзал, не юзаю, и не собираюсь. Предпочитаю ODBC или нативные интефейсы (типа OCI для Oracle).
: насколько... э-э-э... "успешно" компилятор 7.1 собирает крупные MFC-шные проекты? Помню, у нас тут проскакивало мнение, что он сыроват и имеет привычку "вылетать" с internal compiler error.
.jpg)
а я и не знал
глупость 
