Нужно определиться с выбором

[ACE Valery]

Ну то что вы умными словечками раскидываться умеете, я это уже увидела. И все же я прошу привести КОНКРЕТНЫЙ пример хотя бы проблем инкапсуляции в MFC. И каким образом идет нарушение идиом ООП. Не надо воды, умоляю. Конкретный код.

дурацкие оБожеПисецКакаяДлиннаяФигня названия методов

дают понимание того, что этот метод делает. Не вижу тут минусов.

[Obey-Kun]

Ну то что вы умными словечками раскидываться умеете, я это уже увидела. И все же я прошу привести КОНКРЕТНЫЙ пример хотя бы проблем инкапсуляции в MFC. И каким образом идет нарушение идиом ООП.

Как будто вы без меня не знаете, что классы MFC пестрят открытыми полями.

дают понимание того, что этот метод делает. Не вижу тут минусов.

Ок. Но почему нет единообразия? CObject, но CObList.

Вы выдернули пару предложений из моего текста. С остальным согласны?

[ACE Valery]

Если я по некоторым вопросам не спорю, то это не значит, что я согласна. Просто я попросила процитировать стандарт, а вы мне кинули кучу ссылок. Но дело в том, что я не так уж хорошо дружу с инглишем. А если я там что-то недопоняла, то не вижу смысла спорить.
Про gcc я не в курсе, так же как и про Qt. Также я ни разу не программировала на VS2010, возможно, там стандарт соблюден. Поэтому я тоже спорить тут не могу.

Как будто вы без меня не знаете, что классы MFC пестрят открытыми полями.
Но почему нет единообразия? CObject, но CObList.

Вы работали когда-нибудь в фирме? Большой? Огромнейшей фирме, где несколько сотен человек пишут в течение нескольких лет один и тот же продукт? Мне кажется, нет.
Давайте представим ситуации:
а) нам до завтра надо выпустить какой-то модуль студии. Мы нифига не успеваем физически. Если не выпустим до завтра, денег мы не получим. А тут еще надо писать всякие get и set для закрытых полей. А это все время-время... Поэтому мы рещаем, что сделаем их пабликами, выпустим модуль, а потом, когда будет время, закроем. Другое дело что времени "потом" тоже не бывает
б) мы с вами вдвоем работаем над одним проектом. Вы пишите класс CObject. Я пишу класс CObList. Ну захотелось мне так его назвать. Ну ленивая я и не нравится мне писать длинные слова. В конце мы сливаем это все в одну кучу. И получается, что вы назвали свой класс так, я так. Ваша функция удаления называется remove(), а моя delete() и т.п. А теперь скажите: кто из нас должен переделывать свой класс, чтобы у нас было единообразие? Вы? Но разве вы не считаете, что вы все правильно сделали? Я? Но почему я? Я ведь тоже считаю, что я права. Или вы думаете, что там есть человек который будет говорить: тааак, называем функцию удаления так, добавления - так? Не, таким вряд ли кто-то будет заниматься.
Или еще такая ситуация: когда-то давно в каком-то классе какой-то человек написал функцию deleteThisObjectFromProgramm(). Вы понимаете, что название это идиотское. Во-первых, необоснованно длинное, во-вторых, перегруженное ненужными объяснениями. В своем классе вы пишите функцию delete() - просто и понятно. Что имеем на выходе? Функции, выполняющие одно и то же действие над вызывающими их объектами, называются по-разному. Снова нет единообразия.
Оно физически невозможно, когда сроки горят. А по своему опыту знаю, что они горят всегда)))

Что касается стандартов - не пойму одного. Я заметила, что есть категория программистов, которые просто помешаны на стандартах. Почему? Я не подкалываю, мне реально интересно, зачем так труситься за стандартами, если оно работает и без стандартов. Допустим, многие вещи написаны на VisualStudio, и пофиг, что в их компиляторе соблюдены не все стандарты. Проги работают нормально. Кому от этого плохо?

[profi]

Почему? Я не подкалываю, мне реально интересно, зачем так труситься за стандартами

Та потому что они на то и стандарты, что бы можно было ваш код одинаково и без ошибок на компиляторах разных производителей компилировать. Типичный случай: http://programmersforum.ru/showthread.php?t=135025

[Obey-Kun]

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

Variable length arrays это одно из нововведений C99. Почитайте список нововведений C99, он находится в начале стандарта.

Вы работали когда-нибудь в фирме? Большой? Огромнейшей фирме, где несколько сотен человек пишут в течение нескольких лет один и тот же продукт? Мне кажется, нет.

В opensource проектах, которые одновременно пишут сотни людей, описанные вами ситуации не встречаются. А так-то да, рефакторингом работающего кода в больших фирмах, пишущих проприетарное ПО, заниматься вряд ли будут, ведь это коммерчески невыгодно. Слава богу, в opensource-мире всё иначе.
У Qt открытых полей нет. А недокументированного функционала на порядок-другой поменьше.

Насчёт нужности стандартов написали выше. И вообще, это как минимум этично, писать с их соблюдением.