Здравствуйте, Maxim S. Shatskih, Вы писали:
E>>Например? Только фичи языка, а не STL, etc.
MSS>CMyClass& как параметр вызовов.
MSS>Получается, что вызов f(obj) может модифицировать obj, и при этом нет никакой видимой подсказки.
MSS>Если бы не было такой фичи, то параметр f имел бы тип CMyClass* — и вызов пришлось бы писать в стиле f(&obj). Это лучше, потому как явная подсказка, что obj может быть изменен в результате вызова.
Надо использовать модификатор const. И тогда все намного будет проще. А твой метод не спасает — это яркий пример not well design.
MSS>Namespaces и особенно оператор using.
MSS>Почему в ядре Windows функции имеют явные лексические префиксы? IoCreateDevice, KeSetEvent... прекрасный путь. Во-первых, ищется грепом по всему проекту. Что будет в Си++? Kernel::SetEvent? Сразу лишний визуальный шум в виде ::. Но это еще полбеды. А если использовался using? Тогда одна и та же сущность может быть поименована и как set, и как CMyTooSmartNamespace::set, попробуй проищи по всему проекту.
Ну и в чем проблема? SetEvent, он что только у Kernel-а может быть? Как-то надо разделять.
MSS>Уже нужен BSCMAKE вместо grep, и вдобавок код лишается локальной понятности. Позвано просто — set() и все. И чтобы понять, что за set(), надо листать код на начало файла, где стоит using.
Все от программиста зависит. Если в одном фале ипользуются разные namespace, то и пользоватся using надо аккуратнее.
MSS>Operaror overloading. Скрытая семантика. Читаешь a+b и не знаешь, а что тут значит +. Чтобы узнать — надо лезть в башку, и хорошо, если этого класса, а не одного из предков.
А реализация "+" может быть разная у разных объектов. Никак не звязанная с арифметическим сложением. Ты об этом не задумывался?
MSS>Но это еще цветочки. Тут хоть лексема + есть. А если operator T()? Вот тут даже никакой видимой подсказки нет, что зовется какая-то процедура сбоку. Прям хоть венгерскую нотацию используй :)
А одно другого не отменяет. Венгерская нотация достаточно хороша в определенных ситуациях.
MSS>RTTI. Уродство. Если язык претендует на ОО, и считает полиморфизм важной фичей языка (а против полиморфизма я ничего сказать не могу, прекрасная идея) — то на кой черт поощрять не-полиморфные стили программирования? Сам же Страуструп писал в 90ом году, что УМЫШЛЕННО не стал делать RTTI как часть языка. И приводил очевидные аргументы. Во-первых, это поощрение не-полиморфного стиля программирования (который однозначный отстой, и кандидат на рефакторинг). Во-вторых, невозможно раз и навсегда придумать правильную раскладку class object. В-третьих, если надо, то несложно сляпать самому, и к чему язык загромождать?
MSS>Теперь он что, передумал? На кой черт эта фича в языке? Если уж очень сильно надо — что бывает редко — чем плох DECLARE_DYNAMIC из MFC? Однозначно лучше, чем что бы то ни было compiler-generated (а компилятор сгенерит то же самое, это очевидно). Например, тем, что можно откастомайзить под себя class object.
Реализация RTII в MFC не самый удачный пример. Явно хуже чем RTTI в C++. Хотя бы тем что обязывает наследовать от CObject.
MSS>Такое ощущение, что рефакторинг кода на Си++ должен состоять главным образом в выбрасывании из него этих маразмов, и приближении его к коду на Си :).
Ощущение неправильное.
E>>Читайте Буча, первое издание. Там примеры были на Smalltalk. Про энтропию — опять же >>квалификация программистов.
MSS>Программисты (и часто даже очень толковые программисты) есть народ, очень склонный к сверхценным идеям и поиску "серебряных пуль" на все случаи жизни. Вбил он себе в башку, что ОО — это круто, и будет потом писать программу для чтения SMART данных с винчестера в ОО стиле, при этом делая идиотства типа открытия файла в конструкторе. И невдомек ему, что OO — это круто для inherently object oriented задач типа UI, а вовсе не панацея на все случаи жизни.
А чего ты взял такую напрввленность ОО? Смотри конец поста.
MSS>Почти каждая фича, каждый подход, каждый язык и каждая библиотека имеет своих маньяков. Даже такая шиза, как юниксные condvar. :)
MSS>И нет никакой гарантии, что программист, которого нанимаешь, не будет маньяком какой-то заумной бредятины, и не свернет весь проект на ее использование. Рынок труда и HR таких гарантий уж точно не дадут. :)
MSS>Заумь написать мы все можем, дурное дело нехитрое. А ты (абстрактный "ты", не Exhumer) попробуй простой код написать. Существенно сложнее.
"Сложные проблемы всегда имеют простые, легкие для понимания неправильные решения" (C) — не помню кто.
MSS>А в силу сложности этого — лучше пользоваться инструментом, который не даст писать заумь. По крайней мере в ответственных проектах, где высока цена баги в человеко-часах, и превышает цену печати кода.
Переведи понятие "цена печати кода".
E>>С C++ вообще в командной строке тяжело работать. Но в оболочке — не вызывает никаких > >>атруднений. Особенно если VC + VisualAssist. Удобство работы на порядок улучшается.
MSS>О! Уже даже MSVC мало, нужен еще какой-то VisualAssist. Энтропия инструмента такова, что требует дополнительных тулов для ее обуздания :)
Для облегчения работы. А уж почему VC сделали таким как он есть — вопрос к товарищу из MS. Например у borland-а это все есть. Хотя знаю зачем — что бы не было конкуренции VB.
MSS>И вот только не надо мне говорить, что project workspace в MSVC лучше, чем файл SOURCES или Makefile. Потому как это не так :) аргументы могу привести. Project workspace — это иллюзия юзабилити для начинающих.
E>>Ну это типичное мнение linux-оидов. Частично как следствие инертности мышления.
MSS>Можно заглянуть ко мне в профайл, чтобы узнать, какой я знатный линуксоид :)
Так я о мышлении.
MSS>Я работал на Си++ годы. С 93 по эдак 99. И что я могу сказать... если выкинуть оттуда половину бреда (административным путем), то хороший инструмент для своего круга задач. Для всего UI, например.
MSS>Вот только в системном программировании вряд ли он хорош. Потому как бы и не приживается он там. Инструмент старый. Давно зрелый. Уже в 93ем году был зрелый — тот же Борланд 3.1. А в системном программировании не прижился.
А так вот ты о чем! Ну так маленькие задачи и ОО там не нужен. И не спорю. Не понимаю как это соотносится с темой: "C++ и большие проекты".
Еще раз. Очень много от программиста зависит и достаточно мало от языка
MSS>> Творческое пользование темплейтами также сможет доставить потомкам MSS>> немало приятных минут. S>Бывает. Но если нет шаблонов, то вместо них на помощь приходят макросы... А S>это вообще жопа.
Темплейты как раз хорошая фича. Одна из лучших в Си++.
MSS>> Вышли из блока -- значит, вышли, и нечего кроме. S>И забыли закрыть половину хэндлов....
Сразу видно. Локально видно. Легко править.
MSS>> Очевидно, что чем проще язык программирования, тем трудней сделать на MSS>> нем семантическую ошибку. S>Если б это было правдой, все бы до сих пор писали на ассемблере.
Ассемблер сложнее Си.
Си — оптимальный язык для близкого к машине программирования. Позволяет все, что и ассемблер (ай, ну да, кроме CPUID — и при этом не содержит скрытой семантики.
Прятать мелочи — глупо. Баги будут именно в них. The devil is in the details. Потому имеет смысл выставить эти детали бесстыдно наружу, чтобы быстрее баг увидеть, если он там есть.
Д>>Это значит "сложение"! (чтобы понять, совсем не нужно даже иметь высшее >>образование ) Д>>А уж как и где оно делается, это уже дело десятое.
MSS>Да правда что ли?
Конечно. Такие вещи позволяют разбираться в сути программы, не отвлекаясь на мелочи (конкретную реализацию сложения). Читая текст программы и зная, какие объекты складываются, в первом приближении ты можешь догадаться что для них означает сложение (например, для строк — слияние). Если же для этого будет использована функция, то нужно будет лезть в нее чтобы понять что она делает.
Разумеется, если operator+ выполняет действия, не имеющие ничего общего со сложением, то с таким программистом надо разбираться в другом месте. Но ведь и для функции можно выбрать имя, не имеющее ничего общего с ее работой!
Здравствуйте, Maxim S. Shatskih, Вы писали:
G>>Да чушь полная. ООП — это такой же инструмент как и любой другой. Все зависит от того >>кто как этим инструментом пользуется. Если руки из жопы растут, то хоть ооп, хоть >>процедурное программирование — один хрен будет куча ошибок и проблем. Вопрос не в >>инструменте а в квалификации товарищей, которые его пользуют.
MSS>Типичное возражение, и совершенно неверное.
Опять же у тебя налицо попытка решить проблемы человеческого фактора с помощью технических средств. А Globus совершенно прав.
MSS>У любого человека, независимо от квалификации, ограничен объем внимания. И если его засорять, например, визуальным шумом — то это в минус.
MSS>Необходимость много листать несколько файлов (заголовки этого класса и предков) для чтения кода — в минус.
Я никогда файлы не листаю. Для чего class view имеется?! Файлы листать — последнее дело.
P.S. Я согласен — писать драйвера (Win и *nix) используя ООП — не надо. Это другого класса задачи.
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>В том-то и фишка, что надо ЗАГОЛОВОК смотреть. В случае f(&obj) — все видно в месте вызова, без заголовка.
Ничего не понятно. Большие обьекты всегда передаются по ссылке (указателю) модифицируется обьект или нет должно следовать из имени функции.
object_gradeUp(obj);
object_name_get(obj);
Четко и ясно. Все зависит от прямоты рук.
На самом деле С++ это тот же С только гораздо лучше. К примеру для GUI паттерн signal/slot крайне полезен. Попробуйте сделать это на голом С, так чтобы это было удобно использовать, а мы посмотрим.
MSS>>Если бы не было такой фичи, то параметр f имел бы тип CMyClass* — и вызов пришлось >бы писать в стиле f(&obj). Это лучше, потому как явная подсказка, что obj может быть >изменен в результате вызова. E>Надо использовать модификатор const. И тогда все намного будет проще.
Ничего не будет проще. Останется f(obj), а за словом const лезть в заголовок. Намного лучше использовать CObject*, чем const CObject&
E>Все от программиста зависит. Если в одном фале ипользуются разные namespace, то и >пользоватся using надо аккуратнее.
Дело в том, что подавляющее большинство программистов злоупотребят этим. У многих менталитет на уровне "есть фича, надо пользоваться" . Дай такому в руки Си++ — получишь write-only language.
E>А реализация "+" может быть разная у разных объектов. Никак не звязанная с >арифметическим сложением. Ты об этом не задумывался?
Я именно об этом, и именно это и есть бред. Лучше уж тогда метод Add. Скажем:
container.Insert(obj);
лучше, чем
container += obj;
E>А одно другого не отменяет. Венгерская нотация достаточно хороша в определенных >ситуациях.
Например?
E>Реализация RTII в MFC не самый удачный пример. Явно хуже чем RTTI в C++. Хотя бы тем >что обязывает наследовать от CObject.
А чем это плохо-то? RTTI нужна на крайне небольшом количестве классов (на CString она не нужна, например), и обязать все такие классы наследоваться от одного корня — что плохого?
>E>"Сложные проблемы всегда имеют простые, легкие для понимания неправильные решения" >(C) — не помню кто.
Keep it simple and stupid. Принцип такой в инженерии. Почти в любой. Усложнения делаются только тогда, когда иначе НИКАК.
E>Переведи понятие "цена печати кода".
Количество нажатий на клавиши, нужное для набора кода. Фичи Си++ — тот же класс строки — полезны практически только в этом.
MSS>>Можно заглянуть ко мне в профайл, чтобы узнать, какой я знатный линуксоид E>Так я о мышлении.
Ну тут, наверное, да. Я скорее буду заодно с линуксоидами, чем с маньяками "серьезного проектирования".
И самый прикол, что эти маньяки почему-то все больше выше бухгалтерий не поднимаются...
E>А так вот ты о чем! Ну так маленькие задачи и ОО там не нужен. И не спорю. Не понимаю >как это соотносится с темой: "C++ и большие проекты".
Тема была — Си++ и серьезный код. Очевидно, что кернел модуль в любой ОС — более серьезный код, чем, например, абсолютно любой UI.
SWW>Конечно. Такие вещи позволяют разбираться в сути программы, не отвлекаясь на >(конкретную реализацию сложения).
"Суть программы" — фигня полная. Во-первых, это просто. Практически всегда.
Во-вторых, зачем читают код? Для саппорта, то бишь а) баги править б) фичи дописывать и в) рефакторинг.
Для всех трех вышеперечисленных вещей нужно знать досконально все детали того куска кода, с которым работаешь, а не одну лишь "суть". И тут упрятывание вредит.
>Читая текст программы и зная, какие объекты складываются, в первом приближении ты >можешь догадаться что для них означает сложение (например, для строк — слияние).
А если валится оно в этом месте — мне тоже не надо знать, что означает + там?
Почему не написать obj.Add(obj2)? Оно имеет преимущество всегда, кроме сложных арифметических выражений, которые с кастом-классами встречают очень редко.
SWW>Разумеется, если operator+ выполняет действия, не имеющие ничего общего со >сложением, то с таким программистом надо разбираться в другом месте.
Во! Золотые слова! А такое ведь почти всегда бывает. Например, оператор <<, означающий печать.
E>Опять же у тебя налицо попытка решить проблемы человеческого фактора с помощью >технических средств.
Совершенно верно! Только почему это плохо?
Фирма Макдоннел-Дуглас сильно гордилась тем, что уменьшила на F-15 число приборов на доске до 30, вместо 48 у "Фантома". Ну наверное, не зря гордилась, правда?
А ведь могли бы сказать — "настоящий летчик и 48 приборов осилит"...
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Чем плохи макросы? Всяко лучше встроенной в компилятор функции. Она не кастомизируется, а макрос — кастомизируется.
Ха-хах, и сразу (по аналогии с операторами) найдутся умельцы, которые напишут:
Дело тут не в слишком большой "продвинутости" языка, а в слишком большой "продвинутости" программеров. Я могу написать на Си нечитаемую хрень (да что я — см. многие исходники ID-а с хитрым закосом под ОО), а могу такую же на C++, в объектах, быстро и просто. Или наоборот.
Дело в уместности инструмента, а не в его мнимой вредоносности
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>>>Если бы не было такой фичи, то параметр f имел бы тип CMyClass* — и вызов пришлось >>бы писать в стиле f(&obj). Это лучше, потому как явная подсказка, что obj может быть >>изменен в результате вызова. E>>Надо использовать модификатор const. И тогда все намного будет проще.
MSS>Ничего не будет проще. Останется f(obj), а за словом const лезть в заголовок. Намного лучше использовать CObject*, чем const CObject&
ЧЕМ??? f( const CObject * ) — это лучше (нагляднее) чем f( const CObject & )???
E>>Все от программиста зависит. Если в одном фале ипользуются разные namespace, то и >>пользоватся using надо аккуратнее.
MSS>Дело в том, что подавляющее большинство программистов злоупотребят этим. У многих менталитет на уровне "есть фича, надо пользоваться" :). Дай такому в руки Си++ — получишь write-only language.
Опять же человеческий фактор.
E>>А реализация "+" может быть разная у разных объектов. Никак не звязанная с >>арифметическим сложением. Ты об этом не задумывался?
MSS>Я именно об этом, и именно это и есть бред. Лучше уж тогда метод Add. Скажем:
А кто мешает тогда сделать метод Add, который будет реализовывать арифметическое вычитание?
MSS> container.Insert(obj); MSS>лучше, чем MSS> container += obj;
ЧЕМ???
E>>А одно другого не отменяет. Венгерская нотация достаточно хороша в определенных >>ситуациях.
MSS>Например?
Например когда у тебя нет class view (а-у, командная строка). И листая файл ты не занешь, что это за переменная. По префиксу можно понять, примерно, что это такое.
E>>Реализация RTII в MFC не самый удачный пример. Явно хуже чем RTTI в C++. Хотя бы тем >>что обязывает наследовать от CObject.
MSS>А чем это плохо-то? RTTI нужна на крайне небольшом количестве классов (на CString она не нужна, например), и обязать все такие классы наследоваться от одного корня — что плохого?
А если мне совершенно нельзя наследовать от CObject? В Acad-е для custom objects именно так.
>>E>"Сложные проблемы всегда имеют простые, легкие для понимания неправильные решения" >>(C) — не помню кто.
MSS>Keep it simple and stupid. Принцип такой в инженерии. Почти в любой. Усложнения делаются только тогда, когда иначе НИКАК.
Именно.
E>>Переведи понятие "цена печати кода".
MSS>Количество нажатий на клавиши, нужное для набора кода. Фичи Си++ — тот же класс строки — полезны практически только в этом.
Хм. Какой-то странный подход к оценке труда программиста. Образца 60-х годов прошлого века.
А в C++ нет класа строки. Только в библиотеках (MFC и STL). Учите мат. часть.
MSS>>>Можно заглянуть ко мне в профайл, чтобы узнать, какой я знатный линуксоид :) E>>Так я о мышлении.
MSS>Ну тут, наверное, да. Я скорее буду заодно с линуксоидами, чем с маньяками "серьезного проектирования".
MSS>И самый прикол, что эти маньяки почему-то все больше выше бухгалтерий не поднимаются...
Так все прикладные програмисты работают на конечного пользователя. И только системные непонятно на кого (вспомним как любимый принтер не печатал после установки новой версии драйверов видеокарты). Без обид, Ok?
E>>А так вот ты о чем! Ну так маленькие задачи и ОО там не нужен. И не спорю. Не понимаю >>как это соотносится с темой: "C++ и большие проекты".
MSS>Тема была — Си++ и серьезный код. Очевидно, что кернел модуль в любой ОС — более серьезный код, чем, например, абсолютно любой UI.
А пользователю все равно, будет ли рабочим ядро, если висит UI.
По причине серъезных и непреодолимых разногласий предлагаю закончить
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Я именно об этом, и именно это и есть бред. Лучше уж тогда метод Add. Скажем:
MSS> container.Insert(obj);
MSS>лучше, чем
MSS> container += obj;
Полностью согласен. Но сдругой стороны Point p = a + b; гораздо лучше чем point_add(&p,&a,&b).
Все должно быть на своих местах. Если человек ставит сапоги в холодильник, то кто в этом виноват? Сапоги или холодиоьник?
E>>А одно другого не отменяет. Венгерская нотация достаточно хороша в определенных >>ситуациях.
MSS>А чем это плохо-то? RTTI нужна на крайне небольшом количестве классов (на CString она не нужна, например), и обязать все такие классы наследоваться от одного корня — что плохого?
Действително не полохо. Многие так и делают.
MSS>Тема была — Си++ и серьезный код. Очевидно, что кернел модуль в любой ОС — более серьезный код, чем, например, абсолютно любой UI.
Вот к примеру ядро ос на С++: http://l4ka.org/projects/pistachio/
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>В том-то и фишка, что надо ЗАГОЛОВОК смотреть. В случае f(&obj) — все видно в месте вызова, без заголовка.
ничего не понятно — см ниже
MSS>Как говорится, лучше перебдеть, чем недобдеть.
если отказаться от ссылок, то любому хорошему програмеру придется передавать указателем ВСЕ объекты. Чтобы избежать ненужных накладных расходов. И что, тебе от этого легче станет?
MSS>RpcChannelIsTcp — пойдет? такой функции нет, но могла бы и быть.
пойдет. Когда функций мало.
MSS>Порядка 1100 функций. Это маленькое подмножество???
я бы сказал, очень маленькое. Если взять в качестве примера FCL, то мне даже подумать страшно, сколько там всего функций (точнее, методов). На порядок больше — это точно.
MSS>Да правда что ли? То есть, что тут автор кода имел в виду под сложением (а прийти в безумную голову может все, что угодно, например, << для печати) — это неважно?
повежливее, пожалуйста.
В безумную голову может прийти мысль назвать функцию print_file, а на самом деле этот файл удалять. И что, есть какая-то разница?
MSS>Чем плохи макросы? Всяко лучше встроенной в компилятор функции. Она не кастомизируется, а макрос — кастомизируется.
Тем, что они ничего "не знают" о языке как таковом. Это — просто инструмент для обработки текстов, и последствия его применения могут быть непредсказуемыми даже для автора макроса. Ну а для кого-то постороннего это может стать засадой много хуже перегруженных методов и шаблонов, кстати говоря.
Здравствуйте, Дарней, Вы писали:
MSS>>Чем плохи макросы? Всяко лучше встроенной в компилятор функции. Она не кастомизируется, а макрос — кастомизируется.
Д>Тем, что они ничего "не знают" о языке как таковом. Это — просто инструмент для обработки текстов, и последствия его применения могут быть непредсказуемыми даже для автора макроса. Ну а для кого-то постороннего это может стать засадой много хуже перегруженных методов и шаблонов, кстати говоря.
Кстати, никто не знает тайную причину того, что в С/С++ так популярны макросы? Во многих других языках их вообще ведь нет. И даже как-то не хочется!
Здравствуйте, Voblin, Вы писали:
V>Промежуточный вывод: те, кто сочинял модуль учёта в 1С думали в основном о логике предметной области (ну там проверить остатки, снять резервы, двинуть взаиморасчёты и т.д.), а навижионистам пришлось сделать всё вручную и, соответственно, до оптимальности алгоритмов дело вообще не дошло.
V>А если всё это реализовывать чисто на С, то результат мог бы получиться ещё более плачевным: программа, скомпилированная самым супероптимизирующим компилятором, вполне может оказаться тормознутее, чем то же самое, исполняемое интерпретатором 1С.
V>Вывод:важна не только и не столько оптимизация, заложенная в средство разработки, но и закладываемые в "философию" средства разработки средства обеспечения простоты и ясности реализации целевого функционала. V>(что, в общем, совпадает с выводами, следующими из "текста написанного нашим соотечественником, работающим в микрософтовской команде компиляторов").
Еще важно, что бы сам модуль проведения был бы внутри хранимой процедуры и написан на C# или Delphi.Net или Basic.Net
С остальным полностью согласен.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
SWW>>Конечно. Такие вещи позволяют разбираться в сути программы, не отвлекаясь на >>(конкретную реализацию сложения).
MSS>"Суть программы" — фигня полная. Во-первых, это просто. Практически всегда. MSS>Во-вторых, зачем читают код? Для саппорта, то бишь а) баги править б) фичи дописывать и в) рефакторинг.
Нормально! То есть, чтобы баг найти — не надо вникать в суть программы. Мне главное — баг найти!
MSS>Для всех трех вышеперечисленных вещей нужно знать досконально все детали того куска кода, с которым работаешь, а не одну лишь "суть". И тут упрятывание вредит.
Я же написал: в первом приближении. Если есть подозрение, что баг "где-то здесь" — исследуешь это место подробнее.
А ты считаешь, чтобы разобраться с программой, нужно прочитать ее всю и сразу, мешая в одну кучу реализацию основного алгоритма и функции-хелперы?
MSS>А если валится оно в этом месте — мне тоже не надо знать, что означает + там?
...нет слов... одни выражения...
MSS>Почему не написать obj.Add(obj2)? Оно имеет преимущество всегда, кроме сложных арифметических выражений, которые с кастом-классами встречают очень редко.
А почему надо вырезать из поего поста ту часть, где есть ответ на этот вопрос?
Но ведь и для функции можно выбрать имя, не имеющее ничего общего с ее работой!
SWW>>Разумеется, если operator+ выполняет действия, не имеющие ничего общего со >>сложением, то с таким программистом надо разбираться в другом месте. MSS>Во! Золотые слова! А такое ведь почти всегда бывает. Например, оператор <<, означающий печать.
Но ведь и для функции можно выбрать имя, не имеющее ничего общего с ее работой!
Так что, не перегрузка операторов виновата, а программист.
Здравствуйте, Maxim S. Shatskih, Вы писали:
E>>Опять же у тебя налицо попытка решить проблемы человеческого фактора с помощью >>технических средств.
MSS>Совершенно верно! Только почему это плохо?
MSS>Фирма Макдоннел-Дуглас сильно гордилась тем, что уменьшила на F-15 число приборов на доске до 30, вместо 48 у "Фантома". Ну наверное, не зря гордилась, правда?
MSS>А ведь могли бы сказать — "настоящий летчик и 48 приборов осилит"...
Физичексие ограничения человеческого организма — 7 объектов наблюдения / внимания.
А пример реализации твоей идеи — McDonalds. Ничего не умеющие студенты, делающие низкого качества еду.
E>Физичексие ограничения человеческого организма — 7 объектов наблюдения / внимания.
Ага. И если забивать башку девелоперу нюансами типа — а protected это у нас поле или private? — то не останется объема внимания на понимание логики.
E>А пример реализации твоей идеи — McDonalds. Ничего не умеющие студенты, делающие >низкого качества еду.
Hi "Maxim S. Shatskih" <29705@news.rsdn.ru>!
Fri, 11 Jun 2004 11:34:18 GMT you wrote:
MSS> Необходимость много листать несколько файлов (заголовки этого MSS> класса и предков) для чтения кода — в минус.
При грамотном проектировании на C++ кода будет меньше, чем на C.
Одна из хороших черт ООП: инкапсуляция. Если классы правильно
реализованы и документированы, то разобраться что делает код можно
быстрее, чем на C.
Здравствуйте, Maxim S. Shatskih, Вы писали:
E>>Физичексие ограничения человеческого организма — 7 объектов наблюдения / внимания.
MSS>Ага. И если забивать башку девелоперу нюансами типа — а protected это у нас поле или private? — то не останется объема внимания на понимание логики.
А не надо файлы исходников листать. Надо диаграммы классов и состояний смотреть. Это следующий уровень абстракции.
E>>А пример реализации твоей идеи — McDonalds. Ничего не умеющие студенты, делающие >>низкого качества еду.
Мне было противно там работать.
MSS>Прекрасный пример! Многомиллиардная корпорация!
Ну если ты считаешь, что делает McDonalds — хорошо, то у меня просто нет слов. А если это еще и применить к программированию, то вообще...
Ты свою семью в McDonalds поведешь?
— и при этом не содержит скрытой семантики.
