А>ЗЫ ... взять ту же 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 плохо разработало принции библиотеки по важному критерию приемственности.
Во всяком случае плохо что микрософт открыто не опубликовала список рпоблем и их решений,
— копайтесь сами — у нас есть новое слово — "стандарт".
Здравствуйте, tyomchick, Вы писали:
T>Вопрос в том кто в этом виноват. Я отнюдь не вхожу стройные ряды пинателей мелкомягких, но всё же думаю что в данном случае они поступили не совсем разумно.
Они объединили два класса (CString и STL строку) в один. Мне кажется, это разумно. Зачем иметь два класса, представляющих одно и то же?
T>В MFC десятки открытых атребутов. Найдите в MSDN указатель "Data members" и посмотрите список классов за ним. Как же вы пользуетесь необъектноориентированной библиотекой? Может напишите в Microsoft, расскажите что их код не может считаться ОО и попросите прислать вам апгрейд?
Тут же все строится на доброй воле. Я или беру их код как есть, без претензий к ним, или пишу свой. Указывать им как писать я не могу, потому что они меня не спрашивают.
T>На счёт примера. Скажем некоторые методы класса выполняют некоторые расчёты или операции другого рода. При этом они используют некоторые параметры, которые явяляются достаточно постоянными и не требующими частого изменения,что делает разумным хранение этих параметров в данных объкта класса (причиной так же может быть необходимость передача этих параметров в другие, возможно скрытые, методы). При этом эти параметры не имеют ограничение на значение или проверка этих значений не имеет смысла и гораздо эффективнее обойтись скажем ASSERT-ом, который можно разместить в вызывающей процедуре (в сущности какая разница где глюк обнаружится). Какой смысл делать GetSet-ы? T>Вот в MFC например валидность многих хендлов проверяеться (ASSERT-ом) непосредственно перед операциями с нимию.
Если у вас private переменная, которая не видна извне и используется только внутри, никаих GetSet делать, конечно, не надо. Но ведь речь не об этом. Речь о дотупе к переменной извне. Если же вам нужен доступ к переменной извне, то делать GetSet предпочтительнее, чем делать переменную public.
T>Ну ё моё. Ну сколько можно. Повторяю, инкапсуляция это лишь инструмент, который позволяет скрыть детали реализации, там где это необходимо. А внесение открытого атрибута не делает код менее ОО. Тут можно говорить о стиле, во многих книгах пишут что открытые данные это "плохой стиль", но мало кто ради "хорошести стиля" будет закрывать и писать ненужные GetSet-ы
Ради хорошего стиля я именно так и делаю. Но повторюсь, функции GetSet добавляются обычно когда нужен доступ к переменной извне. Ко всяким внутренним флажкам и т.д. доступ обычно напрямую.
"Хороший стиль" — это очень важно. В моем теперешнем проекте ситуация такова — разношерстный (в смысле уровня квалификации) народ понаписал ботвы, а я теперь сижу и кусочек за кусочком потихоньку выбрасываю и переписываю. А все потому, что они, видимо, тоже считали, что стиль дело десятое.
T>(таже песня с goto, неодной сколько нибудь сеьёзно й библиотеки не обходиться без него).
Следствие низкой квалификации разработчиков?
S>>При чем тут кит? MDSN является документацией. T>Я всё же наставиваю на том, что протокол класса являеться документом.
Я тоже настаиваю. Я настаиваю на том, что Земля имеет форму чемодана. Ну и что? Перестала Земля быть круглой от этого? Вы тоже можете настаивать на чем угодно, от этого H файлы документацией не станут.
Здравствуйте, vgrigor, Вы писали:
V>Если открытый атрибут — его будут использовать и это очевидно.
CString::m_pchData не есть открытый атрибут.
V>Во всяком случае плохо что микрософт открыто не опубликовала список рпоблем и их решений,
Каких проблем? Возникающих вследствии неправильного использования библиотеки? Так таких проблем неквалифицированные разработчики могут создать на свою голову неограниченное количество. Как вы предлагаете описать и предложить решение неограниченного количества проблем?
S>Каких проблем? Возникающих вследствии неправильного использования библиотеки? Так таких проблем неквалифицированные разработчики могут создать на свою голову неограниченное количество. Как вы предлагаете описать и предложить решение неограниченного количества проблем?
Если код компилировался, без хакерских приемов, значит тот атрибут открытый,
иначе бы вы о нем не знали в своем коде.
Если неквалифицированные могли написать успешно компитлируемый код — то проблема очевидна:
политика безопастности простым видом не использовалась корректно самой Микрософт.
Здравствуйте, vgrigor, Вы писали:
S>>Каких проблем? Возникающих вследствии неправильного использования библиотеки? Так таких проблем неквалифицированные разработчики могут создать на свою голову неограниченное количество. Как вы предлагаете описать и предложить решение неограниченного количества проблем?
V>Если код компилировался, без хакерских приемов, значит тот атрибут открытый, V>иначе бы вы о нем не знали в своем коде.
Хм. Какое интересно определение открытости.
Определимся в терминологии?
Я считаю, что когда мы говорим "Открытый" — мы имеем ввиду, что он объявлен с ключевым словом public. А каково ваше определение "открытости"?
V>Если неквалифицированные могли написать успешно компитлируемый код — то проблема очевидна: V>политика безопастности простым видом не использовалась корректно самой Микрософт.
Написание успешно компилируемого кода не есть признак квалификации.
Ну, и соответственно вывод об очевидной проблеме неверен, потому что следует из неверного положния.
S>Я считаю, что когда мы говорим "Открытый" — мы имеем ввиду, что он объявлен с ключевым словом public. А каково ваше определение "открытости"?
мое, то же, но с учетом private, для наследования,
в данном случае это не играет роли — никто не наследовал.
Значит если не public -значит ошибка должна быть, выдаваться компилятором,
либо полностью законное использование, особенно в неквалифицированных случаях.
S>Написание успешно компилируемого кода не есть признак квалификации. S>Ну, и соответственно вывод об очевидной проблеме неверен, потому что следует из неверного положния.
Написание компилятора и библиотеки, который не ругается на неквалифицированное использование
и говорит что все в порядке — "свидетельство неквалификации".
Здравствуйте, vgrigor, Вы писали:
S>>Каких проблем? Возникающих вследствии неправильного использования библиотеки? Так таких проблем неквалифицированные разработчики могут создать на свою голову неограниченное количество. Как вы предлагаете описать и предложить решение неограниченного количества проблем?
V>Если код компилировался, без хакерских приемов, значит тот атрибут открытый, V>иначе бы вы о нем не знали в своем коде.
V>Если неквалифицированные могли написать успешно компитлируемый код — то проблема очевидна: V>политика безопастности простым видом не использовалась корректно самой Микрософт.
Здравствуйте, vgrigor, Вы писали:
S>>Я считаю, что когда мы говорим "Открытый" — мы имеем ввиду, что он объявлен с ключевым словом public. А каково ваше определение "открытости"?
V>мое, то же, но с учетом private, для наследования, V>в данном случае это не играет роли — никто не наследовал.
Играет. Наследование имело место быть.
Речь шла о то, что некто унаследовался от CString, напрямую использовал m_pchData, при переходе на Visual 7 код перестал компилироваться, потому что в новой CString переменной m_pchData нету
V>Значит если не public -значит ошибка должна быть, выдаваться компилятором, V>либо полностью законное использование, особенно в неквалифицированных случаях.
"Полностью законным" может считаться только использование документированных функций и переменных. Все остальное — под вашу ответственность, на ваш страх и риск. CString::m_pchData в MDSN не упоминается как член класса CString.
V>Написание компилятора и библиотеки, который не ругается на неквалифицированное использование V>и говорит что все в порядке — "свидетельство неквалификации".
Типа "во всех моих ошибках виноват кто угодно, но только не я сам"?
А использование напрямую CString::m_pchData однозначно считаю ошибкой.
Компилятор не брался вас учить программированию. Это должны были сделать в институте.
Здесь вы перешли в плоскость субективности и личных впечатлений,
в то время как смысл компилятора, и хорошо разработанной библиотеки —
позволять кодировать так чтобы если компилировалось — то это законно,
так как не уследишь за тысячами аспектов, — для этого компилятро и эти правила и составляли.
И неквалицированный тот — кто это не учел, т.к основы компилерства.
Здравствуйте, al, Вы писали:
al>Можно вообще написать в начале stdafx.h
al>
al>#define private public
al>#define protected public
al>
Не поможет. Откомпилируется, но не слинкуется. protected и private функции вроде не экспортируются, хотя, может быть, я и неправ.
al>Смысл этого в том, что наследоваться от CString в ясном уме и твердой памяти никто не будет.
Почему нет? Вполне. Важно, чтобы в наследнике вы использовали только документированные функции — это сделает вашу жизнь легкой и радостной.
А насчет зачем это надо:
Например, у вас есть DLL, в ней куча ресурсов строк. Когда вы вызываете LoadString, надо переключать ресурсы. Стандартный LoadString этого не делает. Чтобы избежать постоянного повтора кода переключения ресурсов, я наследуюсь и пишу свой LoadString, который переключает ресурсы прежде чем строку из ресурсов грузить. Класс мой называется CString4MyDLL. И что со мной не так? Ум не ясен или память не тверда? И каково было бы ваше решение?
T>>На счёт примера. Скажем некоторые методы класса выполняют некоторые расчёты или операции другого рода. При этом они используют некоторые параметры, которые явяляются достаточно постоянными и не требующими частого изменения,что делает разумным хранение этих параметров в данных объкта класса (причиной так же может быть необходимость передача этих параметров в другие, возможно скрытые, методы). При этом эти параметры не имеют ограничение на значение или проверка этих значений не имеет смысла и гораздо эффективнее обойтись скажем ASSERT-ом, который можно разместить в вызывающей процедуре (в сущности какая разница где глюк обнаружится). Какой смысл делать GetSet-ы? T>>Вот в MFC например валидность многих хендлов проверяеться (ASSERT-ом) непосредственно перед операциями с нимию.
S>Если у вас private переменная
Ну ё мой, я уже психовать начинаю, ну какая нафиг private , мы уже третий день про открытые атрибуты базарим а вы мне private ... ну хоть немного надо уважать собеседника.
, которая не видна извне и используется только внутри, никаих GetSet делать, конечно, не надо. Но ведь речь не об этом. Речь о дотупе к переменной извне. Если же вам нужен доступ к переменной извне, то делать GetSet предпочтительнее, чем делать переменную public.
Ну нафига:
.......
private:
int m_Val;
public:
inline int GetVal()
{
return m_Val;
};
inline void SetVal(int Val)
{
m_Val=Val;
};
.......
Вместо:
.......
public:
m_Val;
.......
T>>Ну ё моё. Ну сколько можно. Повторяю, инкапсуляция это лишь инструмент, который позволяет скрыть детали реализации, там где это необходимо. А внесение открытого атрибута не делает код менее ОО. Тут можно говорить о стиле, во многих книгах пишут что открытые данные это "плохой стиль", но мало кто ради "хорошести стиля" будет закрывать и писать ненужные GetSet-ы
S>Ради хорошего стиля я именно так и делаю. Но повторюсь, функции GetSet добавляются обычно когда нужен доступ к переменной извне. Ко всяким внутренним флажкам и т.д. доступ обычно напрямую.
Ну неужели я так на дурака похож?
S>"Хороший стиль" — это очень важно.
"Хороший стиль" это понятие относительное. Я вот не считаю вышеуказанный "пухлый" код хорошим стилем.
T>>(таже песня с goto, неодной сколько нибудь сеьёзно й библиотеки не обходиться без него).
S>Следствие низкой квалификации разработчиков?
Да, напиши об этом, майкрасофту, борланду или ещё кому нть. Да же в MSDN туча примеров с goto. А выход как из 3-4-ох вложенных циклов как делать. Самый шик конечно исключение бросить .
S>Я тоже настаиваю. Я настаиваю на том, что Земля имеет форму чемодана. Ну и что? Перестала Земля быть круглой от этого? Вы тоже можете настаивать на чем угодно, от этого H файлы документацией не станут.
Они такими и задумывались .
И вообще спросите у любого профессионального программера на VC. Почти любой скажет что лучшая документация по MFC это её исходники.
Даже самую простую задачу можно сделать невыполнимой, если провести достаточное количество совещаний
Здравствуйте, tyomchick, Вы писали:
S>>Если у вас private переменная T>Ну ё мой, я уже психовать начинаю, ну какая нафиг private , мы уже третий день про открытые атрибуты базарим а вы мне private ... ну хоть немного надо уважать собеседника.
Сорри. Я все время уточняю, чтобы не получилоь, что мы о разном говорим.
T>Ну нафига: T>
2. Чтобы гарантрировать, что используемя Val всегда валидна.
int GetVal()
{
АССЕРТ(m_Val >= 0);
return max(m_Val, 0);
};
3. Чтобы точку прерывания было где поставить.
А то вот представьте, проект у вас большой, количество содаваемых объектов исчисляется тысячами, и в какой-то момент m_Val получает значение невалидное значение 666. Как будете отлавливать, откуда это значение выставлется, если поиск строки "m_Val =" по исходникам выдаст вам 200 вхождений? Будете ставить 200 точек прерывания?
А так — в одно месте:
void SetVal(int Val)
{
АССЕРТ(Val != 666);
m_Val=max(0, Val);
};
И вас ASSERT уведомит, что птичка поймалась.
4. Чтобы код был легче модифицуруем. Например, вы решили, во всех местах, где m_Val использувтся, использовать только половинку этого значения.
Я делаю изменение только в одном месте:
int GetVal()
{
АССЕРТ(m_Val >= 0);
return max(m_Val, 0)/2;
};
А вы опять запускаете поиск строки "m_Val =", получаете свои 200 вхождений и аккуратненько 200 раз добавляете "/2", заметьте, без гарантии, что вы чего-либо не пропустите.
Считаю, что этих 4-х причин достаточно, чтобы написать Set и Get функции.
T>>>Ну ё моё. Ну сколько можно. Повторяю, инкапсуляция это лишь инструмент, который позволяет скрыть детали реализации, там где это необходимо. А внесение открытого атрибута не делает код менее ОО. Тут можно говорить о стиле, во многих книгах пишут что открытые данные это "плохой стиль", но мало кто ради "хорошести стиля" будет закрывать и писать ненужные GetSet-ы
S>>"Хороший стиль" — это очень важно. T>"Хороший стиль" это понятие относительное. Я вот не считаю вышеуказанный "пухлый" код хорошим стилем.
А теперь, когда я вам раскрыл все плюсы подобного подхода? К тому же код не "пухлый". Если поставить 200 строчек m_Val=xxx против 12 на Get и Set функции, то счет пухлости получится 16:1 в мою пользу
T>>>(таже песня с goto, неодной сколько нибудь сеьёзно й библиотеки не обходиться без него). S>>Следствие низкой квалификации разработчиков? T>Да, напиши об этом, майкрасофту, борланду или ещё кому нть.
Зачем? Они меня не спрашивают и сами это отлично понимают.
T>Да же в MSDN туча примеров с goto.
Следствие низкой квалификации писателей MSDN?
MSDN пишут такие же люди, как мы с вами. Я так понимаю, вы, если бы MDSN писали, написали бы примеры с goto, а потом мне кто-нибудь на этом форуме на это бы указывал. Круг замкнулся. Примеры с goto появляются в MSDN потому что писатели MSDN не считают это неправильным, а oни не считают это неправильным потому что даже MDSN содержит примеры с goto.
T>А выход как из 3-4-ох вложенных циклов как делать. Самый шик конечно исключение бросить .
Самое простое и надежное — флажок выставить.
S>>Я тоже настаиваю. Я настаиваю на том, что Земля имеет форму чемодана. Ну и что? Перестала Земля быть круглой от этого? Вы тоже можете настаивать на чем угодно, от этого H файлы документацией не станут. T>Они такими и задумывались .
Интересно, а что тогда в книге Undocumented Windows написано? Ведь все функции, которые там упоминаются, есть в H файлах, иначе бы у вас проект не собрался? Не находите, что ваше определение докумантации немного противиречит общепринятому?
T>И вообще спросите у любого профессионального программера на VC. Почти любой скажет что лучшая документация по MFC это её исходники.
Это для красного словца. Источник информации — да. Источник новых знаний — да. Но никак не документация. Документация -это MSDN.
S>1. Чтобы не позволять ставить переменной невалидные значения
S>void SetVal(int Val) S>{ S>АССЕРТ(Val >= 0); S>m_Val=max(0, Val); S>};
S>2. Чтобы гарантрировать, что используемя Val всегда валидна.
S>int GetVal() S>{ S>АССЕРТ(m_Val >= 0); S>return max(m_Val, 0); S>};
Ну я же писал об этом в предыдущих письмах. Не всегда есть ограничения на значения, зачем передёргивать 8ой раз (в данном случае к стате достаточно было сделать данные беззнаковыми). Иногда, даже если проверка нужна, гораздо разумнее делать её в месте использования данных, как и делаеться в MFC. (в общем всё это я уже писал)
S>3. Чтобы точку прерывания было где поставить. S>А то вот представьте, проект у вас большой, количество содаваемых объектов исчисляется тысячами, и в какой-то момент m_Val получает значение невалидное значение 666. Как будете отлавливать, откуда это значение выставлется, если поиск строки "m_Val =" по исходникам выдаст вам 200 вхождений? Будете ставить 200 точек прерывания?
S>А так — в одно месте: S>void SetVal(int Val) S>{ S>АССЕРТ(Val != 666); S>m_Val=max(0, Val); S>}; S>И вас ASSERT уведомит, что птичка поймалась.
Привер явно надуман. Возможно если будет такой маразматический код, то я и зделаю метод, но это 1 из 1000.
S>4. Чтобы код был легче модифицуруем. Например, вы решили, во всех местах, где m_Val использувтся, использовать только половинку этого значения. S>Я делаю изменение только в одном месте: S>int GetVal() S>{ S>АССЕРТ(m_Val >= 0); S>return max(m_Val, 0)/2; S>};
Это не подпадает под описанный выше случай. Тут есть явная обработка данных перед выдачей, и вдруг это захотеться не может. Если это вдруг захочеться, то разработчику надо будет намылить лысину.
S>А вы опять запускаете поиск строки "m_Val =", получаете свои 200 вхождений и аккуратненько 200 раз добавляете "/2", заметьте, без гарантии, что вы чего-либо не пропустите.
А Replace на что .
T>>>>Ну ё моё. Ну сколько можно. Повторяю, инкапсуляция это лишь инструмент, который позволяет скрыть детали реализации, там где это необходимо. А внесение открытого атрибута не делает код менее ОО. Тут можно говорить о стиле, во многих книгах пишут что открытые данные это "плохой стиль", но мало кто ради "хорошести стиля" будет закрывать и писать ненужные GetSet-ы
S>>>"Хороший стиль" — это очень важно. T>>"Хороший стиль" это понятие относительное. Я вот не считаю вышеуказанный "пухлый" код хорошим стилем. S>А теперь, когда я вам раскрыл все плюсы подобного подхода? К тому же код не "пухлый". Если поставить 200 строчек m_Val=xxx против 12 на Get и Set функции, то счет пухлости получится 16:1 в мою пользу
Извините за некоторую грубость, но никакой идиот не будет ставить даже 10 таких строчек. Я описывал по вашей прозьбе конкретный пример, а вы тут кучу если. Тока я не понял чем SetGet от "=" отличаеться?
T>>>>(таже песня с goto, неодной сколько нибудь сеьёзно й библиотеки не обходиться без него). S>>>Следствие низкой квалификации разработчиков? T>>Да, напиши об этом, майкрасофту, борланду или ещё кому нть. S>Зачем? Они меня не спрашивают и сами это отлично понимают.
T>>Да же в MSDN туча примеров с goto. S>Следствие низкой квалификации писателей MSDN? S>MSDN пишут такие же люди, как мы с вами. Я так понимаю, вы, если бы MDSN писали, написали бы примеры с goto, а потом мне кто-нибудь на этом форуме на это бы указывал. Круг замкнулся. Примеры с goto появляются в MSDN потому что писатели MSDN не считают это неправильным, а oни не считают это неправильным потому что даже MDSN содержит примеры с goto.
T>>А выход как из 3-4-ох вложенных циклов как делать. Самый шик конечно исключение бросить . S>Самое простое и надежное — флажок выставить.
S>>>Я тоже настаиваю. Я настаиваю на том, что Земля имеет форму чемодана. Ну и что? Перестала Земля быть круглой от этого? Вы тоже можете настаивать на чем угодно, от этого H файлы документацией не станут. T>>Они такими и задумывались . S>Интересно, а что тогда в книге Undocumented Windows написано? Ведь все функции, которые там упоминаются, есть в H файлах, иначе бы у вас проект не собрался? Не находите, что ваше определение докумантации немного противиречит общепринятому?
T>>И вообще спросите у любого профессионального программера на VC. Почти любой скажет что лучшая документация по MFC это её исходники. S>Это для красного словца. Источник информации — да. Источник новых знаний — да. Но никак не документация. Документация -это MSDN.
Даже самую простую задачу можно сделать невыполнимой, если провести достаточное количество совещаний
T>Ну я же писал об этом в предыдущих письмах. Не всегда есть ограничения на значения,
Не всегда. Но они могут появлятся, когда программа уже написана и сдана. (Пример см. ниже) А ваша задача — заложить возможность легкого изменения с самого начала. Set/Get функции эту возможность закладывают.
T>зачем передёргивать 8ой раз
Это всего лишь пример. Проверка может быть сколь угодно сложной.
T>(в данном случае к стате достаточно было сделать данные беззнаковыми). Иногда, даже если проверка нужна, гораздо разумнее делать её в месте использования данных, как и делаеться в MFC. (в общем всё это я уже писал)
А если код проверки валидности значения занимает десять строк? Будте 10 линий кода везде копировать?
S>>3. Чтобы точку прерывания было где поставить. S>>А то вот представьте, проект у вас большой, количество содаваемых объектов исчисляется тысячами, и в какой-то момент m_Val получает значение невалидное значение 666. Как будете отлавливать, откуда это значение выставлется, если поиск строки "m_Val =" по исходникам выдаст вам 200 вхождений? Будете ставить 200 точек прерывания? S>>А так — в одно месте: S>>void SetVal(int Val) S>>{ S>>АССЕРТ(Val != 666); S>>m_Val=max(0, Val); S>>}; S>>И вас ASSERT уведомит, что птичка поймалась. T>Привер явно надуман. Возможно если будет такой маразматический код, то я и зделаю метод, но это 1 из 1000.
Что значит надуман? Такое случается сплошь и рядом. Вы смотрите в отладчике, а у вас переменная имеет какое-то левое значение. "Ах ты ж ексель-моксель, когда она успела его получить?" Как искать предполагаете, с вашими двумя сотнями m_Val=ххх, разбросанными по всему коду?
S>>4. Чтобы код был легче модифицуруем. Например, вы решили, во всех местах, где m_Val использувтся, использовать только половинку этого значения. S>>Я делаю изменение только в одном месте: S>>int GetVal() S>>{ S>>АССЕРТ(m_Val >= 0); S>>return max(m_Val, 0)/2; S>>}; T>Это не подпадает под описанный выше случай. Тут есть явная обработка данных перед выдачей, и вдруг это захотеться не может.
Почему не подпадает? Вы спросили, какие преимущества у Set/Get против public переменной. Данный пункт иллюстрирует гибкость Set/Get, которой нет у public переменной.
T>Если это вдруг захочеться, то разработчику надо будет намылить лысину.
Простой пример. Вам выдали спецификации. Вы написали программу, версию 1. Протестировали. Сдали. Все довольны. Дальше переходим к версии два. Выдаются спецификации, и тут вы видите, что, чтобы им соответствовать, надо везде поделить m_Val на два. Это называется "вдруг захотелось", не так ли? Такое возможо? При многолетнем контракте — вполне. Кто разработчик? Вы. Вам придется самому себе лысину мылить. А чтобы такого не было, надо придерживаться такого стиля, который бы позволил с заданиями легко и быстро справляться. Что я и делаю и вам советую.
S>>А вы опять запускаете поиск строки "m_Val =", получаете свои 200 вхождений и аккуратненько 200 раз добавляете "/2", заметьте, без гарантии, что вы чего-либо не пропустите. T>А Replace на что .
Наделаете ошибок при Replace. Гарантирую.
T>>>"Хороший стиль" это понятие относительное. Я вот не считаю вышеуказанный "пухлый" код хорошим стилем. S>>А теперь, когда я вам раскрыл все плюсы подобного подхода? К тому же код не "пухлый". Если поставить 200 строчек m_Val=xxx против 12 на Get и Set функции, то счет пухлости получится 16:1 в мою пользу T>Извините за некоторую грубость, но никакой идиот не будет ставить даже 10 таких строчек.
Я надеюсь. А то же тогда делать, если ваша переменная public, ей присвивается значение в 200 местах и где-то в каой-то момент ей присваивается невалидное значение? Как отлавливать будете?
T>Я описывал по вашей прозьбе конкретный пример, а вы тут кучу если.
Так ведь программа — она в развитии. "Если" — это все те проблемы, с которыми вы столкнетесь рано или поздно, если над одним проектом будете работать долго.
T>Тока я не понял чем SetGet от "=" отличаеться?
Возможностью легкой модификации кода в одном месте без ненужного дублирования кода. Облегчением процесса отладки.
Get Set — крайне полезные вещи,
в смысле изоляции аспектов обращения к какому-то аспекту, который может быть усложнен,
это инкапсуляция лишней сложности которую не надо потом иметь во всей программе.
Но когда дело касается, уже четко определенных вещей,
типа вложенных контейнеров, или очевидных применений, это может быть и лишним.
document.window.line.symbol -лучше обращение.
в обще для немного важных вещей -надо вставлять.
Для абсолютно всего — кажется лишним.
T>>Ну я же писал об этом в предыдущих письмах. Не всегда есть ограничения на значения,
S>Не всегда. Но они могут появлятся, когда программа уже написана и сдана. (Пример см. ниже) А ваша задача — заложить возможность легкого изменения с самого начала. Set/Get функции эту возможность закладывают.
Да ничего не может появиться. Вы просили конкретный пример, я как мог описал ситуацию. В ней по сути даже не требуеться чтение атребута. Заложить можно всё что угодно.
T>>зачем передёргивать 8ой раз
S>Это всего лишь пример. Проверка может быть сколь угодно сложной.
Опять 25. Да, это конечно это всего лишь пример, ну так что и требовалось, я же не говорю что нужно всегда применять открытые атребуты, это глупо, если действительно нужна проверка или ещё какеи либо действия при установки, чтении данных то без Set/Get не обойтись. Я всего лишь протестовал против того, что повление открытого атрибута делает код не ОО и всё.
T>>(в данном случае к стате достаточно было сделать данные беззнаковыми). Иногда, даже если проверка нужна, гораздо разумнее делать её в месте использования данных, как и делаеться в MFC. (в общем всё это я уже писал)
S>А если код проверки валидности значения занимает десять строк? Будте 10 линий кода везде копировать?
Нет, я напишу функцию или макрос. И потом валидность многих данных может меняться со временем (пример — хендлы) и потому перед использованием их всё равно нужно проверять.
S>>>3. Чтобы точку прерывания было где поставить. S>>>А то вот представьте, проект у вас большой, количество содаваемых объектов исчисляется тысячами, и в какой-то момент m_Val получает значение невалидное значение 666. Как будете отлавливать, откуда это значение выставлется, если поиск строки "m_Val =" по исходникам выдаст вам 200 вхождений? Будете ставить 200 точек прерывания? S>>>А так — в одно месте: S>>>void SetVal(int Val) S>>>{ S>>>АССЕРТ(Val != 666); S>>>m_Val=max(0, Val); S>>>}; S>>>И вас ASSERT уведомит, что птичка поймалась. T>>Привер явно надуман. Возможно если будет такой маразматический код, то я и зделаю метод, но это 1 из 1000.
S>Что значит надуман? Такое случается сплошь и рядом. Вы смотрите в отладчике, а у вас переменная имеет какое-то левое значение. "Ах ты ж ексель-моксель, когда она успела его получить?" Как искать предполагаете, с вашими двумя сотнями m_Val=ххх, разбросанными по всему коду?
У меня такого не случаеться. Я не себе такой код не представляю, ну то есть не писал никогда. И потом повторяю в 10ый раз, был приведён конкретный пример, показывающий лишь то, что бываюьт ситуации, когда закрывать данные не имеет смысла.
S>>>4. Чтобы код был легче модифицуруем. Например, вы решили, во всех местах, где m_Val использувтся, использовать только половинку этого значения. S>>>Я делаю изменение только в одном месте: S>>>int GetVal() S>>>{ S>>>АССЕРТ(m_Val >= 0); S>>>return max(m_Val, 0)/2; S>>>}; T>>Это не подпадает под описанный выше случай. Тут есть явная обработка данных перед выдачей, и вдруг это захотеться не может.
S>Почему не подпадает? Вы спросили, какие преимущества у Set/Get против public переменной. Данный пункт иллюстрирует гибкость Set/Get, которой нет у public переменной.
В 11 раз повторяю, про конкретны пример, когда это не нужно. Я могу привести ещё сотнбю примеров когда инкопсуляция необходима, но зачем? Я всего лишь говорю что она не обязательна.
T>>Если это вдруг захочеться, то разработчику надо будет намылить лысину.
S>Простой пример. Вам выдали спецификации. Вы написали программу, версию 1. Протестировали. Сдали. Все довольны. Дальше переходим к версии два. Выдаются спецификации, и тут вы видите, что, чтобы им соответствовать, надо везде поделить m_Val на два. Это называется "вдруг захотелось", не так ли? Такое возможо? При многолетнем контракте — вполне. Кто разработчик? Вы. Вам придется самому себе лысину мылить. А чтобы такого не было, надо придерживаться такого стиля, который бы позволил с заданиями легко и быстро справляться. Что я и делаю и вам советую.
В 12 ый раз ...
S>>>А вы опять запускаете поиск строки "m_Val =", получаете свои 200 вхождений и аккуратненько 200 раз добавляете "/2", заметьте, без гарантии, что вы чего-либо не пропустите. T>>А Replace на что .
S>Наделаете ошибок при Replace. Гарантирую.
Вообще то это была шутка, но гарантии здесь не уместны.
T>>>>"Хороший стиль" это понятие относительное. Я вот не считаю вышеуказанный "пухлый" код хорошим стилем. S>>>А теперь, когда я вам раскрыл все плюсы подобного подхода? К тому же код не "пухлый". Если поставить 200 строчек m_Val=xxx против 12 на Get и Set функции, то счет пухлости получится 16:1 в мою пользу T>>Извините за некоторую грубость, но никакой идиот не будет ставить даже 10 таких строчек.
T>>Я описывал по вашей прозьбе конкретный пример, а вы тут кучу если.
S>Так ведь программа — она в развитии. "Если" — это все те проблемы, с которыми вы столкнетесь рано или поздно, если над одним проектом будете работать долго.
T>>Тока я не понял чем SetGet от "=" отличаеться? S>Возможностью легкой модификации кода в одном месте без ненужного дублирования кода. Облегчением процесса отладки.
Мы же о пухлости говорили про какие то 16:1. Эт то тут причём.
Даже самую простую задачу можно сделать невыполнимой, если провести достаточное количество совещаний
Здравствуйте, tyomchick, Вы писали:
S>>Это всего лишь пример. Проверка может быть сколь угодно сложной. T>Опять 25. Да, это конечно это всего лишь пример, ну так что и требовалось, я же не говорю что нужно всегда применять открытые атребуты,
Вы говорите, что НЕ ВСЕГДА можно применять открытые отрибуты, а я говорю что что НИКОГДА нельзя применять открытые атрибуты.
T>это глупо, если действительно нужна проверка или ещё какеи либо действия при установки, чтении данных то без Set/Get не обойтись.
Если сегодня проверка не нужна, это не означает, что она не понадобится через пару лет. Вам же с вашим public атрибутом придется горы кода перелопатить. Почему бы не сделать сразу правильно и навека?
T>Я всего лишь протестовал против того, что повление открытого атрибута делает код не ОО и всё.
А использование не public переменной MFC в своем коде делает его менее OO?
S>>Что значит надуман? Такое случается сплошь и рядом. Вы смотрите в отладчике, а у вас переменная имеет какое-то левое значение. "Ах ты ж ексель-моксель, когда она успела его получить?" Как искать предполагаете, с вашими двумя сотнями m_Val=ххх, разбросанными по всему коду? T>У меня такого не случаеться. Я не себе такой код не представляю, ну то есть не писал никогда. И потом повторяю в 10ый раз, был приведён конкретный пример, показывающий лишь то, что бываюьт ситуации, когда закрывать данные не имеет смысла.
А я вам показываю ваш пример в развитии. И показываю, что имеет смысл данные закрывать с самого начала, даже если Set делает простое присвоение, а Get возвращает переменную без каких-либо манипуляций над ней, потому что завтра (которое нам не дано предугадать) и Set, и Get могут сильно усложнится, и наличие public переменной вместо Set/Get сильно испортит вам жизнь.
S>>Простой пример. Вам выдали спецификации. Вы написали программу, версию 1. Протестировали. Сдали. Все довольны. Дальше переходим к версии два. Выдаются спецификации, и тут вы видите, что, чтобы им соответствовать, надо везде поделить m_Val на два. Это называется "вдруг захотелось", не так ли? Такое возможо? При многолетнем контракте — вполне. Кто разработчик? Вы. Вам придется самому себе лысину мылить. А чтобы такого не было, надо придерживаться такого стиля, который бы позволил с заданиями легко и быстро справляться. Что я и делаю и вам советую. T>В 12 ый раз ...
Дык и я вам одно и то же повторяю — что код вашего примера может потребовать изменений затра же. Что делать будете?
S>>>>А вы опять запускаете поиск строки "m_Val =", получаете свои 200 вхождений и аккуратненько 200 раз добавляете "/2", заметьте, без гарантии, что вы чего-либо не пропустите. T>>>А Replace на что .
S>>Наделаете ошибок при Replace. Гарантирую. T>Вообще то это была шутка, но гарантии здесь не уместны.
Почему? Лично пробовал и к такому выводу пришел. Так что вполне уместны.
К тому же если это шутка, то вы не ответили на вопрос. Как справлятся с такой ситуацией будете?
T>>>Тока я не понял чем SetGet от "=" отличаеться? S>>Возможностью легкой модификации кода в одном месте без ненужного дублирования кода. Облегчением процесса отладки. T>Мы же о пухлости говорили про какие то 16:1. Эт то тут причём.
Ну, если о пухлости и 16:1 — то SetGet получается намного компактнее чем "="
S>Если сегодня проверка не нужна, это не означает, что она не понадобится через пару лет. Вам же с вашим public атрибутом придется горы кода перелопатить. Почему бы не сделать сразу правильно и навека?
Потому что бывают программы не на века во первых,
во вторых —
т.е нужно быстро написать так, а потом если понадобится усовершенствовать
всавляются Set/Get и все в порядке и оптимально во времени — без лишней работы.
В третьих когда запись удобнее, нагляднее, а пользы от Set/Get нет.
пример микрософт:
CWnd::m_hWnd — гораздо удобнее так и писать, чем вызов функции.
Тем более что вызов такой что на века, нет на него проверок разумных,
зачем код усложнять?
Здравствуйте, tyomchick, Вы писали:
T>Здравствуйте, Serguei666, Вы писали:
S>>Здравствуйте, tyomchick, Вы писали:
T>>>А выход как из 3-4-ох вложенных циклов как делать. Самый шик конечно исключение бросить . S>>Самое простое и надежное — флажок выставить.
T>А примерчик в студию можно для 4ох циклов?
Здравствуйте, vgrigor, Вы писали:
V>Или мешает основному содержанию?
На мой взгляд, не имеет отношения к изначальной теме — несовестимость MFC разных версий и баги MFC 7.0/7.1
V>Тогда — здравое предложение.
Рад, что Вы согласны.
S>>Если сегодня проверка не нужна, это не означает, что она не понадобится через пару лет. Вам же с вашим public атрибутом придется горы кода перелопатить. Почему бы не сделать сразу правильно и навека?
V>Потому что бывают программы не на века во первых,
Это вы про лабы в институте? Тогда конечно.
А любой коммерческий продукт делают с расчетом, чтобы доить его и доить.
V>во вторых - V>т.е нужно быстро написать так, а потом если понадобится усовершенствовать V>всавляются Set/Get и все в порядке и оптимально во времени — без лишней работы.
"если понадобится усовершенствовать" — скажите, а как вы оцените степень надобности?
V>В третьих когда запись удобнее, нагляднее, а пользы от Set/Get нет.
V>пример микрософт: V>CWnd::m_hWnd — гораздо удобнее так и писать, чем вызов функции.
Это субъективно. Мне удобнее писать CWnd::GetSafeHwnd()
V>Тем более что вызов такой что на века, нет на него проверок разумных, V>зачем код усложнять?
Потому что "на века" не бывает Рано или поздно придется менять.
Здравствуйте, vgrigor, Вы писали:
S>>А любой коммерческий продукт делают с расчетом, чтобы доить его и доить.
V>Вообще, в серьезных проектах — да. V>Это стилевое требование, несложное но полезное, V>там везде надо вставлять, если вы не один пишите.
V>А если один и хотите быстро, V>то можете и быстрее -без get/ set.
V>Степень надобности оценивается так: V>если модуль один, если только вы его пишите, V>если вы запланировали его самое простое использование, V>тогда ...
Так это все возможно только при написании маленьких примеров для личного пользования. А мы же тут про работу говорим. Которая, само собой, связана с очень серьезными проектами
Вам может захотеться написать пилотный проект быстро,
не оформляя его по мелочам круто, не отвлекаясь.
Это Типичная практика.
Когда заработает, видно лучше все части которые стоит удалить
не переписывая, какие существенно усовершенствовать,
главное чтобы быстро заработала общая картина,
Здравствуйте, vgrigor, Вы писали:
V>Вам может захотеться написать пилотный проект быстро, V>не оформляя его по мелочам круто, не отвлекаясь. V>Когда заработает, видно лучше все части которые стоит удалить V>не переписывая, какие существенно усовершенствовать, V>главное чтобы быстро заработала общая картина,
Вот у нас примерно так и было. "Пилотный проект" начался 4 года назад. До сих пор мусор из кода убираю. А его много, и главное, вам никто не дает время на то, чтобы его убирать. Пользователи платят деньги не за некие внутренние оптимизации, которые им не дадут ничего, а вам облегчат жизнь. Пользователи хотят за свои деньги получить след. версию лучше чем предыдушая. А времени на то и другое не хватает.
"Нет ничего более постояного, чем временные явления". Если вы работаете в команде, если проект более чем просто примерчик для самого себя — то лучше сразу все делать правильно. Это мое мнение, основанное на моем же опыте.
Если первый проект получтся за три месяца, а такое бывает — вы просто пробуете все применяемые технологии,
про годы никто не говорит, это не пилотный проек а неудача,
нечего оформление усложнять ненужное крючочками.
Крючочки потом вставляются за пару дней. А терять время на простановку в процессе — это неприятно — терять нить
идеи.
S>"Нет ничего более постояного, чем временные явления". Если вы работаете в команде, если проект более чем просто примерчик для самого себя — то лучше сразу все делать правильно. Это мое мнение, основанное на моем же опыте.
Во всяком случае вы его ничем реальным не подтвердили, так что эти слова не вполне в вашу пользу.
Хотя писать надо сразу правильно конечно, где важно — но надо понимать почему и где — а не просто так получается.
Если в коллективе свой кусок,- это важно,
а если изолированный кусок от него, с интерефейсом — то можете быстро попробовать, все равно о вашем внутреннем коде
никто не узнает.
Это вроде как современная технология, а не взаимопереплетение если вы пишете расширяемую библиотку, что редкость среди прикладны товарищей .
Так что по крайней мере технологически это обходится.
Винтовку добудешь в бою!
Re[15]: Изменения в MFC 7.0/7.1
От:
Аноним
Дата:
03.06.03 17:22
Оценка:
Эт tymchick, просто у меня cook-исы слетели а пароль забыл.
T>>А примерчик в студию можно для 4ох циклов?
S>bool ToContinue = true; S>int Counter = 0;
S>while(true) S>{ S> while(true) S> { S> while(true) S> { S> while(true) S> { S> Counter++; S> if(Counter == 666) S> { S> ToContinue = false; S> break; S> } S> } S> if(!ToContinue) S> break; S> } S> if(!ToContinue) S> break; S> } S> if(!ToContinue) S> break; S>}
Вот, вот. Это я называю маразмом псевдоструктурного программирования в чистом виде. Снижаеться производительность, читабельность только что б не страшный goto, несмотря на то что применение goto здесь выгодно во всех отношениях.
Re[17]: Изменения в MFC 7.0/7.1
От:
Аноним
Дата:
03.06.03 17:54
Оценка:
Здравствуйте, Serguei666, Вы писали:
S>Дык и я вам одно и то же повторяю — что код вашего примера может потребовать изменений затра же. Что делать будете?
Я всё же с вами не соглашусь.
1. Для многих данных можно сказать что их преобразование или проверка не может понадобиться никогда.
2. Приведённый вками пример про m_Val/2 абсолютно не корректен. Если вы так пишите программы то вам надо задуматься о вашей квалификации. Так не проектируют. Что бы реализация класса менялась из-за того, что программист решил что один из параметров расчётов нужно сделать в 2 раза меньше ... эт полный аут. Я себе представляю документацию к программе.
"Ну вот это параметр надо установить в 2 раза больше чем необходимо для расчёта. Ну это потому что этот класс использовался в таком то коде и программеру лень было лазить по коду и менять его."
3. Я всё же не представляю кода в котором может быть не то, что 200, а даже и 10 установок параметра при том что все эти куски кода были абсолютно разнородны и их никаким образом не нелльзя было оформить в виде отдельной функции.
S>>>>>А вы опять запускаете поиск строки "m_Val =", получаете свои 200 вхождений и аккуратненько 200 раз добавляете "/2", заметьте, без гарантии, что вы чего-либо не пропустите. T>>>>А Replace на что .
S>>>Наделаете ошибок при Replace. Гарантирую. T>>Вообще то это была шутка, но гарантии здесь не уместны. S>Почему? Лично пробовал и к такому выводу пришел. Так что вполне уместны.
То есть вы мне гарантирууту, что я возьму 100 примеров, зселаю там Replace и в каждом случае у меня будет ошибка? Смело однако.
S>К тому же если это шутка, то вы не ответили на вопрос. Как справлятся с такой ситуацией будете?
На счёт этой ситуации я уже ответил.
T>>Мы же о пухлости говорили про какие то 16:1. Эт то тут причём. S>Ну, если о пухлости и 16:1 — то SetGet получается намного компактнее чем "="
Я не понию почему тут если
И ещё я наверно туплю, почему это SetGet получаються компактнее.
SetVal(Val); // 12
m_Val=Val; // 10
+ протокол и реализация методов.
Мдя, до каких вопросов опустилиь
Re[15]: Изменения в MFC 7.0/7.1
От:
Аноним
Дата:
03.06.03 18:03
Оценка:
Здравствуйте, Serguei666, Вы писали:
S>Здравствуйте, tyomchick, Вы писали:
T>>И попробуйте переделать вот такой код из MSDN, ну хотя бы на словах.
S>
B превратился и так не сильно удобоваримый "COM-код" в абсолютный ужас. И заметте это можно сказать только начало кода, а дальше должен идти разбор XML-документа с поджключением многих интерфейсов и много чего ещё. А 10-20 вложенных if-ов эт конечно "красиво", а уж как "структурировано" и "читабельно". Только бы в скобочках не запутаться. Хотя нет, всемогущий редактр VS нас конечно спасёт? Жаль что не все редакторы так всемогущи.
Re[16]: Изменения в MFC 7.0/7.1
От:
Аноним
Дата:
03.06.03 18:11
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Serguei666, Вы писали:
T>>>И попробуйте переделать вот такой код из MSDN, ну хотя бы на словах.
А> А 10-20 вложенных if-ов эт конечно "красиво", а уж как "структурировано" и "читабельно".
Правда справедливости ради надо сказать, что тут как раз уместны исключения.
А>Вот, вот. Это я называю маразмом псевдоструктурного программирования в чистом виде. Снижаеться производительность,
Кого волнует производительность в данном случае? Меня — нет. Вы снижение производительности и замерить-то не сможете — настолько оно будет незначительным.
А>читабельность
читабельность — дело субъективное. По мне так читабельность моей версии вполне OK. Ну, конечно, при правильном форматировании, которое потерялось, потому что тэг "code" забыл поставить
А>только что б не страшный goto
А что, этого мало?
А>несмотря на то что применение goto здесь выгодно во всех отношениях.
Не вижу никаких выгод. Что мне дает goto, кроме головной боли?
Производительность не упоминать без численной оценки и описания способов измерения.
Читабельность не упоминать, потому что, как я уже сказал, это дело субъективное.
Здравствуйте, Аноним, Вы писали:
А>B превратился и так не сильно удобоваримый "COM-код" в абсолютный ужас.
"Ужас" — это эмоции. У меня они другие. Исходный код действительно не сильно удобоваримый, после моих изменений он стал значительно лучше, не находите?
А>И заметте это можно сказать только начало кода, а дальше должен идти разбор XML-документа с поджключением многих интерфейсов и много чего ещё. А 10-20 вложенных if-ов эт конечно "красиво", а уж как "структурировано"
Разве нет других способов 10-20 вложенных if-ов разнести кроме как использовать goto?
А>Только бы в скобочках не запутаться.
Будете писать аккуратно — не запутаетесь, даже без "всемогущего редактра VS". Я фичами по поиску пар для скобочек даже и не пользуюсь, потому что пишу аккуратно. Скобочка под скобочкой, каждий блок смещается вправо на один Tab символ
А>Жаль что не все редакторы так всемогущи.
А мне не надо, чтобы все были такими. Достаточно одного.
Хотите сказать 'спасибо'? Тогда поставьте оценку
Re[17]: Изменения в MFC 7.0/7.1
От:
Аноним
Дата:
03.06.03 19:24
Оценка:
Здравствуйте, Serguei666, Вы писали:
S>Здравствуйте, Аноним, Вы писали:
А>>B превратился и так не сильно удобоваримый "COM-код" в абсолютный ужас. S>"Ужас" — это эмоции. У меня они другие. Исходный код действительно не сильно удобоваримый, после моих изменений он стал значительно лучше, не находите?
Нет, абсолютно нет. Он стал более громоздким и менее читабельным.
А>>И заметте это можно сказать только начало кода, а дальше должен идти разбор XML-документа с поджключением многих интерфейсов и много чего ещё. А 10-20 вложенных if-ов эт конечно "красиво", а уж как "структурировано" S>Разве нет других способов 10-20 вложенных if-ов разнести кроме как использовать goto?
Какие? Хотя могу заранее сказать все они увелмчат код и сделают его абсолютно не читабельным. (правда повторю, что в данном и конкретном случае преминимы исключения, правда скорее всего надо будет написать свой класс исключения),
А>>Только бы в скобочках не запутаться. S>Будете писать аккуратно — не запутаетесь, даже без "всемогущего редактра VS". Я фичами по поиску пар для скобочек даже и не пользуюсь, потому что пишу аккуратно. Скобочка под скобочкой, каждий блок смещается вправо на один Tab символ
Не это не для меня. Я просто выделяю код и давлю Alt+F8.
Но как бы вы аккуратно не писали код, всё же найти нужную скобку не легко, потому как даже 5 вложенных if-ов не помещаеться в экран.
Здравствуйте, Аноним, Вы писали:
А>1. Для многих данных можно сказать что их преобразование или проверка не может понадобиться никогда.
Кино такое было — "никогда не говори никогда".
А>2. Приведённый вками пример про m_Val/2 абсолютно не корректен. Если вы так пишите программы то вам надо задуматься о вашей квалификации.
Спасибо, я о ней все время думаю.
А>Так не проектируют. Что бы реализация класса менялась из-за того, что программист решил что один из параметров расчётов нужно сделать в 2 раза меньше ... эт полный аут. Я себе представляю документацию к программе.
Документация тоже поменяется, если необходимо. Это часть цикла.
А>"Ну вот это параметр надо установить в 2 раза больше чем необходимо для расчёта. Ну это потому что этот класс использовался в таком то коде и программеру лень было лазить по коду и менять его."
Это же пример. К чему эти фантазии?
А>3. Я всё же не представляю кода в котором может быть не то, что 200, а даже и 10 установок параметра при том что все эти куски кода были абсолютно разнородны и их никаким образом не нелльзя было оформить в виде отдельной функции.
Ну, что я могу сказать. Не представляете, потому что не видели. А я видел. Было, конечно, не 200 присвоений, но 110. И мне пришлось весь этот мусор чистиь. Занятие на недели, между прочим.
Вы вообще криво написанные проекты видели в жизни? Состоящие из 900 файлов? Написанные второпях и непонятно кем? А пытались в таких проектах разбираться? Уверяю вас, вас приятно удивит, насколько программеры могут быть неквалифицированными. А все в том числе и потому, что к советам не прислушиватся. Тоже, видимо считают, что чего-то там НИКОГДА не произойдет.
S>>>>Наделаете ошибок при Replace. Гарантирую. T>>>Вообще то это была шутка, но гарантии здесь не уместны. S>>Почему? Лично пробовал и к такому выводу пришел. Так что вполне уместны. А>То есть вы мне гарантирууту, что я возьму 100 примеров, зселаю там Replace и в каждом случае у меня будет ошибка? Смело однако.
Я не сказал про каждый случай. Я сказал, что количество опибок будет ненулевое.
T>>>Мы же о пухлости говорили про какие то 16:1. Эт то тут причём. S>>Ну, если о пухлости и 16:1 — то SetGet получается намного компактнее чем "=" А>Я не понию почему тут если А>И ещё я наверно туплю, почему это SetGet получаються компактнее. А>SetVal(Val); // 12 А>m_Val=Val; // 10 А>+ протокол и реализация методов.
Так я вам говорю, завтра вам понадобится добавить строку, исполнямую всякий раз, когда вы делаете m_Val=Val, и ваш код увеличится на (количество "m_Val=Val") строк. А мой — на одну-единственную строку. А при рассмотрении долгосрочного проекта разница будет расти, и ваш размер вашего кода будет проигрывать размеру моего все больше и больше.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Serguei666, Вы писали:
S>>Здравствуйте, Аноним, Вы писали:
А>>>B превратился и так не сильно удобоваримый "COM-код" в абсолютный ужас. S>>"Ужас" — это эмоции. У меня они другие. Исходный код действительно не сильно удобоваримый, после моих изменений он стал значительно лучше, не находите? А>Нет, абсолютно нет. Он стал более громоздким и менее читабельным.
Ну вот. Приплыли.
А я вот говорю. "Он стал менее громоздким и более читабельным". Причем АБСОЛЮТНО. Ваше слово против моего слова. Хотите предложить способ оценки громоздкости и читабельности? Если нет, то перестаньте такими словами бросаться. Они ценности не имеют, ибо нет способа оценки их правдивости.
А>>>И заметте это можно сказать только начало кода, а дальше должен идти разбор XML-документа с поджключением многих интерфейсов и много чего ещё. А 10-20 вложенных if-ов эт конечно "красиво", а уж как "структурировано" S>>Разве нет других способов 10-20 вложенных if-ов разнести кроме как использовать goto? А>Какие? Хотя могу заранее сказать все они увелмчат код и сделают его абсолютно не читабельным. (правда повторю, что в данном и конкретном случае преминимы исключения, правда скорее всего надо будет написать свой класс исключения),
Например, разбить код на насколько функций.
А>>>Только бы в скобочках не запутаться. S>>Будете писать аккуратно — не запутаетесь, даже без "всемогущего редактра VS". Я фичами по поиску пар для скобочек даже и не пользуюсь, потому что пишу аккуратно. Скобочка под скобочкой, каждий блок смещается вправо на один Tab символ А>Не это не для меня. Я просто выделяю код и давлю Alt+F8. А>Но как бы вы аккуратно не писали код, всё же найти нужную скобку не легко, потому как даже 5 вложенных if-ов не помещаеться в экран.
Вы мне рассказываете, как мне нелегко? Не надо. Я лучше знаю, легко мне или нет. Докладываю: легко. Никогда не было проблем.
Хотите сказать 'спасибо'? Тогда поставьте оценку
Re[17]: Изменения в MFC 7.0/7.1
От:
Аноним
Дата:
03.06.03 20:35
Оценка:
Здравствуйте, Serguei666, Вы писали:
S>Здравствуйте, Аноним, Вы писали:
А>>Эт tymchick, просто у меня cook-исы слетели а пароль забыл.
T>>>>А примерчик в студию можно для 4ох циклов?
S>
А>>Вот, вот. Это я называю маразмом псевдоструктурного программирования в чистом виде. Снижаеться производительность, S>Кого волнует производительность в данном случае? Меня — нет. Вы снижение производительности и замерить-то не сможете — настолько оно будет незначительным.
Конечно, если это процедура не вызываеться где нибудь пару милилонов раз.
А>>читабельность S>читабельность — дело субъективное. По мне так читабельность моей версии вполне OK. Ну, конечно, при правильном форматировании, которое потерялось, потому что тэг "code" забыл поставить Эт вы написали только потому что в любом случае нужно возразить. В данном (и не только в данном) случае "читабельность" абсолютно объективна. Это скажет любой разумный человек. Даже если отбросить элементарную громоздкость кода и трезво оценить читабельность.
Скажем просматривает человек ваш код (я всё же думаю что реальный код будет немного более сложнее, не так примитивен) и видит.
ToContinue = false;
break;
он ищет глазами конец цикла ...
"- ура, нашёл "
но там он видит
if(!ToContinue) break;
Ну ничего. Он ищет следующий конец цикла.
"- ура, нашёл "
но там
if(!ToContinue) break;
Тут он начинает вспоминать "хорошими словами" того, кто это писал.
Он ищет следующий конец цикла.
Уже без особой радости и с подозрением он его находит.
И что он видит? Правильно
if(!ToContinue) break;
И он уже готов убить того, кто это писал.
С трудом совладав с чувствами он всё же находит в себе силы проюолжить поиски.
И о счастье, вот оно избавлениею
Что же происходит если человек видит goto.
— Ё моё, кто это писал, это же не структурное пр-е
Но тем неменее он переваривает отвращение и просто находит метку ... находит он её быстро, потому что она одна большими буквами и с жирным коментарием.
И потом, если читабельность это дело субъективное, нто из-за чего весь сыр бор? Ведь главный минус (и практически единственный) goto это снижение читабельности при его злоупотреблении. Вы когда нибудь видели старые большие программы на Байсике или Фортране? Это то, что называеться Write only code. Это действительно ужас, невозможно понять
куда какие переходы и почему.
Есть конечно другой негативный аспект goto. Это так называемое нарушение логики программы. Ну то есть нелогичный оператор, не имеющий отношение к логике и выполняющий просто навигацию по коду. Но это из разряда чистой филисофии не связанной с практикой. В данном случае невозможно ненарушить логику. Суть в том что нужно завершить итеративный процесс ... но "логичные" операторы языка не позволяют это сделать сразу. А все извращения с поступенчатым выходом из циклов с помощью флажка есть так же не имеют под собой алгоритмической логики ... они не несут смысловой логической нагрузки. Суть в том что надо выйти из цыклов и для реализации этого вы пишите длинную последовательность операций которая сводиться к простой новигации по коду с целью достичь нужной точки, при этом затрачиваються как вычислительные ресурсы так и память, вместо того что бы зделать goto, cуть котрого в простом изменении указателя команд.
Я вас убедил? Неужели всё это я писал зря .
А>>только что б не страшный goto S>А что, этого мало?
Так что в нём страшного?
А>>несмотря на то что применение goto здесь выгодно во всех отношениях. S>Не вижу никаких выгод. Что мне дает goto, кроме головной боли?
У вас что компьютер пронзительно пищит на строчке goto ... так его S>Производительность не упоминать без численной оценки и описания способов измерения.
Ну такты можно посчитать ))) без учёта оптимизации )))
Re[19]: Изменения в MFC 7.0/7.1
От:
Аноним
Дата:
03.06.03 21:10
Оценка:
Здравствуйте, Serguei666, Вы писали:
S>Здравствуйте, Аноним, Вы писали:
А>>Здравствуйте, Serguei666, Вы писали:
S>>>Здравствуйте, Аноним, Вы писали:
А>>>>B превратился и так не сильно удобоваримый "COM-код" в абсолютный ужас. S>>>"Ужас" — это эмоции. У меня они другие. Исходный код действительно не сильно удобоваримый, после моих изменений он стал значительно лучше, не находите? А>>Нет, абсолютно нет. Он стал более громоздким и менее читабельным. S>Ну вот. Приплыли. S>А я вот говорю. "Он стал менее громоздким и более читабельным". Причем АБСОЛЮТНО. Ваше слово против моего слова. Хотите предложить способ оценки громоздкости и читабельности? Если нет, то перестаньте такими словами бросаться. Они ценности не имеют, ибо нет способа оценки их правдивости.
1. Громоздкость — количество строк кода при условии конечно того, что один операторы, одна строка.
2. Читабельность. Ну один из примеров "хорошей" читабельности я уже привёл в письме про goto. В данном случае что бы определить следующий оператор программы вам нужно найти скобку, для чего вам нужно либо проанализировать вложенность скобок либо (если вы аккуратно писали) оценить по отступам. Как первое так и второе (при большой вложенности и удалённости) скобок является значительно более сложной задачей для человеческого мозга чем отыскание в тексте метки, отмеченной жирным коментарием.
Всё абсолютно объективно. Разве нет? Или ваш мозг как то иначе устроен?
А>>>>И заметте это можно сказать только начало кода, а дальше должен идти разбор XML-документа с поджключением многих интерфейсов и много чего ещё. А 10-20 вложенных if-ов эт конечно "красиво", а уж как "структурировано" S>>>Разве нет других способов 10-20 вложенных if-ов разнести кроме как использовать goto? А>>Какие? Хотя могу заранее сказать все они увелмчат код и сделают его абсолютно не читабельным. (правда повторю, что в данном и конкретном случае преминимы исключения, правда скорее всего надо будет написать свой класс исключения), S>Например, разбить код на насколько функций.
В данном случае это мало поможет.
А>>>>Только бы в скобочках не запутаться. S>>>Будете писать аккуратно — не запутаетесь, даже без "всемогущего редактра VS". Я фичами по поиску пар для скобочек даже и не пользуюсь, потому что пишу аккуратно. Скобочка под скобочкой, каждий блок смещается вправо на один Tab символ А>>Не это не для меня. Я просто выделяю код и давлю Alt+F8. А>>Но как бы вы аккуратно не писали код, всё же найти нужную скобку не легко, потому как даже 5 вложенных if-ов не помещаеться в экран. S>Вы мне рассказываете, как мне нелегко? Не надо. Я лучше знаю, легко мне или нет. Докладываю: легко. Никогда не было проблем.
Дело не в "легко" или "тяжело" ... дело в "легче", "тяжелее".
Здравствуйте, Аноним, Вы писали:
А>>>Вот, вот. Это я называю маразмом псевдоструктурного программирования в чистом виде. Снижаеться производительность, S>>Кого волнует производительность в данном случае? Меня — нет. Вы снижение производительности и замерить-то не сможете — настолько оно будет незначительным. А>Конечно, если это процедура не вызываеться где нибудь пару милилонов раз.
Дык хоть газиллионов. Какая мне разница, если вы численную оценкы представить не можете?
А>>>читабельность S>>читабельность — дело субъективное. По мне так читабельность моей версии вполне OK. Ну, конечно, при правильном форматировании, которое потерялось, потому что тэг "code" забыл поставить А> Эт вы написали только потому что в любом случае нужно возразить.
Да уж, только и делаю, что вам возражаю
S>>В данном (и не только в данном) случае "читабельность" абсолютно объективна. Это скажет любой разумный человек.
Вы так говорите специально, чтобы я либо признал себя неразумным, либо с вами согласился?
S>>Даже если отбросить элементарную громоздкость кода и трезво оценить читабельность.
По каким критериям громоздкость оценивать будем?
А>Скажем просматривает человек ваш код (я всё же думаю что реальный код будет немного более сложнее, не так примитивен) и видит.
А>ToContinue = false; А>break; А>он ищет глазами конец цикла ... А>"- ура, нашёл " А>но там он видит А>if(!ToContinue) break; А>Ну ничего. Он ищет следующий конец цикла. А>"- ура, нашёл " А>но там А>if(!ToContinue) break; А>Тут он начинает вспоминать "хорошими словами" того, кто это писал.
Не надо глазами искать. Надо F3 нажимать (Find Next)
А>Он ищет следующий конец цикла. А>Уже без особой радости и с подозрением он его находит. А>И что он видит? Правильно А>if(!ToContinue) break; А>И он уже готов убить того, кто это писал. А>С трудом совладав с чувствами он всё же находит в себе силы проюолжить поиски. А>И о счастье, вот оно избавлениею
А что же вы хотели, с циклом вложенности 4? Это вам не шуточки. Я за восемь лет ни одного цикла вложенностью 4 не написал, написал пару циклов вложенности 3. Раз в восемь лет можно и напрячься, не находите?
А>Что же происходит если человек видит goto. А>- Ё моё, кто это писал, это же не структурное пр-е А>Но тем неменее он переваривает отвращение и просто находит метку ... находит он её быстро, потому что она одна большими буквами и с жирным коментарием.
Да-да. Находит, чтобы сразу стереть и написать без goto . Я бы именно так и сделал.
А>И потом, если читабельность это дело субъективное, нто из-за чего весь сыр бор? Ведь главный минус (и практически единственный) goto это снижение читабельности при его злоупотреблении. Вы когда нибудь видели старые большие программы на Байсике или Фортране? Это то, что называеться Write only code. Это действительно ужас, невозможно понять
Ну и что? То, что код Write only — не делает чести его разработчикам.
А>куда какие переходы и почему. А>Есть конечно другой негативный аспект goto. Это так называемое нарушение логики программы. Ну то есть нелогичный оператор, не имеющий отношение к логике и выполняющий просто навигацию по коду. Но это из разряда чистой филисофии не связанной с практикой. В данном случае невозможно ненарушить логику. Суть в том что нужно завершить итеративный процесс ... но "логичные" операторы языка не позволяют это сделать сразу. А все извращения с поступенчатым выходом из циклов с помощью флажка есть так же не имеют под собой алгоритмической логики ... они не несут смысловой логической нагрузки. Суть в том что надо выйти из цыклов и для реализации этого вы пишите длинную последовательность операций которая сводиться к простой новигации по коду с целью достичь нужной точки, при этом затрачиваються как вычислительные ресурсы так и память, вместо того что бы зделать goto, cуть котрого в простом изменении указателя команд.
Ну, про траты вычислительных ресурсов и памяти я сказал. Оценить-то все равно не сможете.
А>Я вас убедил? Неужели всё это я писал зря .
А что вы хотите? Чтобы я начал писать goto? "Скорее небо упадет на Землю и Дунай потечет в другую сторону" ((c) турки в ответ на ультиматум Суворова).
А>>>только что б не страшный goto S>>А что, этого мало? А>Так что в нём страшного?
Вы же сами и написали, чего. См.выше, читайте начиная с "Есть конечно другой негативный аспект goto"
А>>>несмотря на то что применение goto здесь выгодно во всех отношениях. S>>Не вижу никаких выгод. Что мне дает goto, кроме головной боли? А>У вас что компьютер пронзительно пищит на строчке goto ... так его
Упражняемся в остроумии? Как же комьютер может определить наличие у меня на экране строчки goto?
S>>Производительность не упоминать без численной оценки и описания способов измерения. А>Ну такты можно посчитать ))) без учёта оптимизации )))
Считайте. Результатами поделИтесь.
Хотите сказать 'спасибо'? Тогда поставьте оценку
Re[19]: Изменения в MFC 7.0/7.1
От:
Аноним
Дата:
03.06.03 22:08
Оценка:
Здравствуйте, Serguei666, Вы писали:
S>Здравствуйте, Аноним, Вы писали:
S>>>В данном (и не только в данном) случае "читабельность" абсолютно объективна. Это скажет любой разумный человек. S>Вы так говорите специально, чтобы я либо признал себя неразумным, либо с вами согласился?
Нет, как вы заметили ниже и в другом письме я привёл способ оценки читабельности.
Она объективна и это факт. В столь любимом вашем институте нам (да и вам, я уверен) говорили "Код пишеться не для компьютера, код пишеться для человека", то есть он должен быть легкочитаем. Как же это может быть .. если это понятие субъективное? Что и требовалось доказать. И надо сказать что goto в большинстве случаев этому злейший враг, но далеко не всегда иногда это лучший выбор.
S>>>Даже если отбросить элементарную громоздкость кода и трезво оценить читабельность. S>По каким критериям громоздкость оценивать будем?
Я уте уже написал и повторяться не буду. А>>Скажем просматривает человек ваш код (я всё же думаю что реальный код будет немного более сложнее, не так примитивен) и видит.
А>>ToContinue = false; А>>break; А>>он ищет глазами конец цикла ... А>>"- ура, нашёл " А>>но там он видит А>>if(!ToContinue) break; А>>Ну ничего. Он ищет следующий конец цикла. А>>"- ура, нашёл " А>>но там А>>if(!ToContinue) break; А>>Тут он начинает вспоминать "хорошими словами" того, кто это писал. S>Не надо глазами искать. Надо F3 нажимать (Find Next)
Искать по F3 скобки? Оригинально-с Эт точно нельзя назвать продвинутым средством навигации по коду. Там в промежутке может быть много скобок и надо ещё оценить какая нужная, а это не просто сделать когда её пара уже скрылась за горизонтом .
А>>Он ищет следующий конец цикла. А>>Уже без особой радости и с подозрением он его находит. А>>И что он видит? Правильно А>>if(!ToContinue) break; А>>И он уже готов убить того, кто это писал. А>>С трудом совладав с чувствами он всё же находит в себе силы проюолжить поиски. А>>И о счастье, вот оно избавлениею S>А что же вы хотели, с циклом вложенности 4? Это вам не шуточки. Я за восемь лет ни одного цикла вложенностью 4 не написал, написал пару циклов вложенности 3. Раз в восемь лет можно и напрячься, не находите?
Ну это вполне реально. Мне покрайней мере часто приходиться писать такие конструкции, по крайней мере это значительно реальне 200 операторов m_Val=Val.
А>>Что же происходит если человек видит goto. А>>- Ё моё, кто это писал, это же не структурное пр-е А>>Но тем неменее он переваривает отвращение и просто находит метку ... находит он её быстро, потому что она одна большими буквами и с жирным коментарием. S>Да-да. Находит, чтобы сразу стереть и написать без goto . Я бы именно так и сделал.
Я не сомневаюсь, эт что б следующему чтецу свинью подложить
А>>И потом, если читабельность это дело субъективное, нто из-за чего весь сыр бор? Ведь главный минус (и практически единственный) goto это снижение читабельности при его злоупотреблении. Вы когда нибудь видели старые большие программы на Байсике или Фортране? Это то, что называеться Write only code. Это действительно ужас, невозможно понять S>Ну и что? То, что код Write only — не делает чести его разработчикам.
Безусловно. Я это привлё для того, что бы показать истинные причины неприятия goto.
А>>куда какие переходы и почему. А>>Есть конечно другой негативный аспект goto. Это так называемое нарушение логики программы. Ну то есть нелогичный оператор, не имеющий отношение к логике и выполняющий просто навигацию по коду. Но это из разряда чистой филисофии не связанной с практикой. В данном случае невозможно ненарушить логику. Суть в том что нужно завершить итеративный процесс ... но "логичные" операторы языка не позволяют это сделать сразу. А все извращения с поступенчатым выходом из циклов с помощью флажка есть так же не имеют под собой алгоритмической логики ... они не несут смысловой логической нагрузки. Суть в том что надо выйти из цыклов и для реализации этого вы пишите длинную последовательность операций которая сводиться к простой новигации по коду с целью достичь нужной точки, при этом затрачиваються как вычислительные ресурсы так и память, вместо того что бы зделать goto, cуть котрого в простом изменении указателя команд. S>Ну, про траты вычислительных ресурсов и памяти я сказал. Оценить-то все равно не сможете.
НУ вы же не станете отрицать что они больше и под флаг таки нужна физическая или регистровая память и при этом абсолютно неоправдано?
А>>Я вас убедил? Неужели всё это я писал зря . S>А что вы хотите? Чтобы я начал писать goto? "Скорее небо упадет на Землю и Дунай потечет в другую сторону" ((c) турки в ответ на ультиматум Суворова).
Да нет, это не реально.
Я лишь хочу, что бы вы перестали считать наличие goto признаком низкой квалификации ... так же как про открытые атребуты в ООП.
А>>>>только что б не страшный goto S>>>А что, этого мало? А>>Так что в нём страшного? S>Вы же сами и написали, чего. См.выше, читайте начиная с "Есть конечно другой негативный аспект goto"
Я же сказал, что это читая философия ... то есть из области чистых идей не несущих ничего ценного в наш материальный мир. Вы же укланяясь от goto нарушаете логику работы программы ещё более извращённым и нелепым образом.
А>>>>несмотря на то что применение goto здесь выгодно во всех отношениях. S>>>Не вижу никаких выгод. Что мне дает goto, кроме головной боли? А>>У вас что компьютер пронзительно пищит на строчке goto ... так его S>Упражняемся в остроумии? Как же комьютер может определить наличие у меня на экране строчки goto?
Догадаеться! Всё, всё больше шутить не буду.
S>>>Производительность не упоминать без численной оценки и описания способов измерения. А>>Ну такты можно посчитать ))) без учёта оптимизации ))) S>Считайте. Результатами поделИтесь.
Признаюсь честно ВЛОМ. Профайлера хорошего под рукой нет а за справочником по командам процессора Intel идти тоже не хочеться. Большого проигрыша здесь не будет, просто он неоправдан, и это не самая большая роблема этого кода.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Serguei666, Вы писали:
S>>Здравствуйте, Аноним, Вы писали:
S>>>>В данном (и не только в данном) случае "читабельность" абсолютно объективна. Это скажет любой разумный человек. S>>Вы так говорите специально, чтобы я либо признал себя неразумным, либо с вами согласился? А>Нет, как вы заметили ниже и в другом письме я привёл способ оценки читабельности. А>Она объективна и это факт.
Нет, не объективна, и это тоже факт
Иногда полезно для поднятия читабельности количествои строк увеличивать — ну, делать там пустые строку, переносы, комментарии писать. Так что ваш способ оценки — "чем меньше строк, тем лучше", не подходит.
А>В столь любимом вашем институте нам (да и вам, я уверен) говорили "Код пишеться не для компьютера, код пишеться для человека", то есть он должен быть легкочитаем. Как же это может быть .. если это понятие субъективное? Что и требовалось доказать. И надо сказать что goto в большинстве случаев этому злейший враг, но далеко не всегда иногда это лучший выбор.
Иногда — это как часто? Мне за 8 лет ни разу не пришлось этим выбором пользоваться. И не придется. Вывод: goto не нужен. Как вы выражаетесь — "и это факт"
Уж если на институт будем ссылаться, то нам там прямо говорили — goto не использовать. "Что и требовалось доказать"
S>>>>Даже если отбросить элементарную громоздкость кода и трезво оценить читабельность. S>>По каким критериям громоздкость оценивать будем? А>Я уте уже написал и повторяться не буду.
Понятно. Прочитал. Моя оценка вашего критерия — см. выше
А>>>Скажем просматривает человек ваш код (я всё же думаю что реальный код будет немного более сложнее, не так примитивен) и видит.
А>>>Тут он начинает вспоминать "хорошими словами" того, кто это писал. S>>Не надо глазами искать. Надо F3 нажимать (Find Next) А>Искать по F3 скобки?
Не по скобкам. Искать слово "ToContinue"
S>>А что же вы хотели, с циклом вложенности 4? Это вам не шуточки. Я за восемь лет ни одного цикла вложенностью 4 не написал, написал пару циклов вложенности 3. Раз в восемь лет можно и напрячься, не находите? А>Ну это вполне реально. Мне покрайней мере часто приходиться писать такие конструкции, по крайней мере это значительно реальне 200 операторов m_Val=Val.
Каждый занимается своим делом.
А>>>Что же происходит если человек видит goto. А>>>- Ё моё, кто это писал, это же не структурное пр-е А>>>Но тем неменее он переваривает отвращение и просто находит метку ... находит он её быстро, потому что она одна большими буквами и с жирным коментарием. S>>Да-да. Находит, чтобы сразу стереть и написать без goto . Я бы именно так и сделал. А>Я не сомневаюсь, эт что б следующему чтецу свинью подложить
Не, это чтобы убрать свинью, положенную предыдушим писателем
А>>>И потом, если читабельность это дело субъективное, нто из-за чего весь сыр бор? Ведь главный минус (и практически единственный) goto это снижение читабельности при его злоупотреблении. Вы когда нибудь видели старые большие программы на Байсике или Фортране? Это то, что называеться Write only code. Это действительно ужас, невозможно понять S>>Ну и что? То, что код Write only — не делает чести его разработчикам. А>Безусловно. Я это привлё для того, что бы показать истинные причины неприятия goto.
Истинные причины — нас так в институте учили. Ни Бейсиковским, ни с Фортрановсим кодом я близко не сталкивался.
А>>>куда какие переходы и почему. А>>>Есть конечно другой негативный аспект goto. Это так называемое нарушение логики программы. Ну то есть нелогичный оператор, не имеющий отношение к логике и выполняющий просто навигацию по коду. Но это из разряда чистой филисофии не связанной с практикой. В данном случае невозможно ненарушить логику. Суть в том что нужно завершить итеративный процесс ... но "логичные" операторы языка не позволяют это сделать сразу. А все извращения с поступенчатым выходом из циклов с помощью флажка есть так же не имеют под собой алгоритмической логики ... они не несут смысловой логической нагрузки. Суть в том что надо выйти из цыклов и для реализации этого вы пишите длинную последовательность операций которая сводиться к простой новигации по коду с целью достичь нужной точки, при этом затрачиваються как вычислительные ресурсы так и память, вместо того что бы зделать goto, cуть котрого в простом изменении указателя команд. S>>Ну, про траты вычислительных ресурсов и памяти я сказал. Оценить-то все равно не сможете. А>НУ вы же не станете отрицать что они больше и под флаг таки нужна физическая или регистровая память и при этом абсолютно неоправдано?
То, что нужна память, орицать не буду. То, что неоправданно — буду.
Все оправданно. Вы занимаете лишние 4 байта (или сколько там переменная ToContinue занимает) из 512 Мегов памяти (у меня даже разрядности калькулятора не хватит, чтобы посчитать, как это мало) в течении очень малой доли секунды (потому что переменная на стеке), а в результате получаете код без goto. Разве это не стоит того? По-моему, еще как стоит.
Чай не XX век на дворе, не на ассемблере пишем. Вона винт купил — 120 Гиг. У нас в институте компы были с винтами 20 мег. Та же фигня и с памятью. Кого колышат какие-то 4 байта, если взамен получается программа, написанная правильно?
А>>>Я вас убедил? Неужели всё это я писал зря . S>>А что вы хотите? Чтобы я начал писать goto? "Скорее небо упадет на Землю и Дунай потечет в другую сторону" ((c) турки в ответ на ультиматум Суворова). А>Да нет, это не реально.
Что небо на землю упадет? Скорее всего нет, конечно. В это и была изюминка такого ответа.
А>Я лишь хочу, что бы вы перестали считать наличие goto признаком низкой квалификации ... так же как про открытые атребуты в ООП.
Не перестану Потому что это и есть признаки низкой квалификации. Такие программисты понапишут, а я сиди исправляй. Думаете, море удовольствия?
А>>>>>только что б не страшный goto S>>>>А что, этого мало? А>>>Так что в нём страшного? S>>Вы же сами и написали, чего. См.выше, читайте начиная с "Есть конечно другой негативный аспект goto" А>Я же сказал, что это читая философия ... то есть из области чистых идей не несущих ничего ценного в наш материальный мир. Вы же укланяясь от goto нарушаете логику работы программы ещё более извращённым и нелепым образом.
Мой матераильный мир — это время, которое я провожу, исправляя чужие ошибки, в том числе и связанные с public переменными (от goto Бог миловал). Так что лучше их в зародыше задушить, научив народ писать как надо.
А>>>>>несмотря на то что применение goto здесь выгодно во всех отношениях. S>>>>Не вижу никаких выгод. Что мне дает goto, кроме головной боли? А>>>У вас что компьютер пронзительно пищит на строчке goto ... так его S>>Упражняемся в остроумии? Как же комьютер может определить наличие у меня на экране строчки goto? А>Догадаеться! А> Всё, всё больше шутить не буду. Это тоже типа шутка была.
А>Признаюсь честно ВЛОМ. Профайлера хорошего под рукой нет а за справочником по командам процессора Intel идти тоже не хочеться. Большого проигрыша здесь не будет, просто он неоправдан, и это не самая большая роблема этого кода.
Так я об этом. Большего проигрыша не будет. Тогда что мы экономим, уродуя программу goto и public переменными?
Ест всеми признанные классические соображения, что гото —
это плохо, так как неструктурно,
но разумно его применять в только в одном случае выходи из большого числа вложенных цклов.
Все согласились уже с этим.
Код должен быть читаем, комментированным,понятным
раз люди понимают похоже то и читабельность обьективна,
как Пушкин поэт и обезьяна- не поэт.
Потому что вы будете в следующий раз ошибки в нем искать,
парсировать, линковать и прочее.
S>>>>>В данном (и не только в данном) случае "читабельность" абсолютно объективна. Это скажет любой разумный человек. S>>>Вы так говорите специально, чтобы я либо признал себя неразумным, либо с вами согласился? А>>Нет, как вы заметили ниже и в другом письме я привёл способ оценки читабельности. А>>Она объективна и это факт. S>Нет, не объективна, и это тоже факт
Слушайте, ну это не серьёзно просто. Помоему я вполне убедительно доказал её объективность и я думаю что вы это поняли ... ну зам же возражать ради возражения. S>Иногда полезно для поднятия читабельности количествои строк увеличивать — ну, делать там пустые строку, переносы, комментарии писать. Так что ваш способ оценки — "чем меньше строк, тем лучше", не подходит.
Пустые строки и коментарии я к коду не отношу. И потом где я писал о связи громоздкости и читабельность? Я рассматривал эти понятия отдельно, но всё же лишний код затрудняет чтение исходников и помоему привёл очень яркий пример и дело тут не в 4ох циклах, даже при 2ух циклах goto уместен.
S>Уж если на институт будем ссылаться, то нам там прямо говорили — goto не использовать. "Что и требовалось доказать"
Странные у вас преподы были, наверно они в книжке прочитали "goto — плохо", потом сказали вам, но не потрудились объяснить почему. Если бы этого оператор был совсем не нужен, его бы небыло. Ведь даже новомодный C# и тот без goto не обошёлся.
А>>>>И потом, если читабельность это дело субъективное, нто из-за чего весь сыр бор? Ведь главный минус (и практически единственный) goto это снижение читабельности при его злоупотреблении. Вы когда нибудь видели старые большие программы на Байсике или Фортране? Это то, что называеться Write only code. Это действительно ужас, невозможно понять S>>>Ну и что? То, что код Write only — не делает чести его разработчикам. А>>Безусловно. Я это привлё для того, что бы показать истинные причины неприятия goto. S>Истинные причины — нас так в институте учили. Ни Бейсиковским, ни с Фортрановсим кодом я близко не сталкивался.
Ну что это. Я же говорил об истинных причинах непрятия goto, а не о том, почему вы его неиспользовали.
А>>>>куда какие переходы и почему. А>>>>Есть конечно другой негативный аспект goto. Это так называемое нарушение логики программы. Ну то есть нелогичный оператор, не имеющий отношение к логике и выполняющий просто навигацию по коду. Но это из разряда чистой филисофии не связанной с практикой. В данном случае невозможно ненарушить логику. Суть в том что нужно завершить итеративный процесс ... но "логичные" операторы языка не позволяют это сделать сразу. А все извращения с поступенчатым выходом из циклов с помощью флажка есть так же не имеют под собой алгоритмической логики ... они не несут смысловой логической нагрузки. Суть в том что надо выйти из цыклов и для реализации этого вы пишите длинную последовательность операций которая сводиться к простой новигации по коду с целью достичь нужной точки, при этом затрачиваються как вычислительные ресурсы так и память, вместо того что бы зделать goto, cуть котрого в простом изменении указателя команд. S>>>Ну, про траты вычислительных ресурсов и памяти я сказал. Оценить-то все равно не сможете. А>>НУ вы же не станете отрицать что они больше и под флаг таки нужна физическая или регистровая память и при этом абсолютно неоправдано? S>То, что нужна память, орицать не буду. То, что неоправданно — буду.
Я даже нестал читать что вы там писали про мегабаты? Просто нет никкой объективной причины тратить эти, пусть даже небольшие ресурсы.
S>Чай не XX век на дворе, не на ассемблере пишем. Вона винт купил — 120 Гиг. У нас в институте компы были с винтами 20 мег. Та же фигня и с памятью. Кого колышат какие-то 4 байта, если взамен получается программа, написанная правильно?
А правильно, это значит без goto? Да? ТОлько вы даже не пытаетесь понять почему goto это не правильно ...вам просто сказали. А>>>>Я вас убедил? Неужели всё это я писал зря . S>>>А что вы хотите? Чтобы я начал писать goto? "Скорее небо упадет на Землю и Дунай потечет в другую сторону" ((c) турки в ответ на ультиматум Суворова). А>>Да нет, это не реально. S>Что небо на землю упадет? Скорее всего нет, конечно. В это и была изюминка такого ответа. А>>Я лишь хочу, что бы вы перестали считать наличие goto признаком низкой квалификации ... так же как про открытые атребуты в ООП. S>Не перестану Потому что это и есть признаки низкой квалификации. Такие программисты понапишут, а я сиди исправляй. Думаете, море удовольствия?
Я не знаю чего они понапишасли у вас там. А переписывать код с goto на код без него, это действительно мало удовольствия, но зачем? Наверно это вам нравится.
Я вот поискал по исходникам VC и обнаружил около 40 файлов с goto, а сколько открытых атребутов в MFC, ужас. Вы хотите сказать что Мелкомягкие отваливают такие бабки неквалифицырованным программерам?
А>>>>Так что в нём страшного? S>>>Вы же сами и написали, чего. См.выше, читайте начиная с "Есть конечно другой негативный аспект goto" А>>Я же сказал, что это читая философия ... то есть из области чистых идей не несущих ничего ценного в наш материальный мир. Вы же укланяясь от goto нарушаете логику работы программы ещё более извращённым и нелепым образом. S>Мой матераильный мир — это время, которое я провожу, исправляя чужие ошибки, в том числе и связанные с public переменными (от goto Бог миловал). Так что лучше их в зародыше задушить, научив народ писать как надо.
Так какие могут быть ошибки с goto?
А>>Признаюсь честно ВЛОМ. Профайлера хорошего под рукой нет а за справочником по командам процессора Intel идти тоже не хочеться. Большого проигрыша здесь не будет, просто он неоправдан, и это не самая большая роблема этого кода. S>Так я об этом. Большего проигрыша не будет. Тогда что мы экономим, уродуя программу goto и public переменными?
Нет, дело именно в том (и это я не раз аргументировал, только вы не хотите слушать), что уродуеться программа и траттятся ресурсы только ради того, что бы соответстоввать некоторым догматам, которым вас научили в институте.
Даже самую простую задачу можно сделать невыполнимой, если провести достаточное количество совещаний