Только я ее видеть не буду, это уже кое-что
А насчет больших и маленьких проектов, ты слышал когда-нибудь про принцип DRY, разве ты не захочешь использовать повторно код, который ты писал для маленького проекта? В случае если это ООП код, то это легко сделать, если код, к примеру чтения из реестра размазан по коду программы, то даже в маленьком проекте его будет трудно изменить а использовать в другом проекте, то что ты уже делал крайне затруднительно. Мне однажды пришлось переписать такую "небольшую" программу. Там было всего около 4к строк, но это был абсолютно не сопровождаемый и не читаемый код, все состояло из пары десятков функций и такого-же количества глобальных переменных, все отправилось в унитаз =)

а комментарии там были читаемые? Готов поспорить, что их там не было или почти не было

неа

обычно я для этого использую CTRL-C  CTRL-V, но вообще обычно делать то, что уже делал раньше, не берусь. Как-то так получается

Это сообщение отредактировал(а) ksili - 29.12.2008, 13:35

какая разница были там комментарии или нет, мне что-бы что-то изменить в программе нужно весь код разбирать что-ли?
Don't Repeat Yourself  

вот представь, есть у тебя код для работы с реестром, скажем добавление ключа в реестр, ты его скопипастил в N проектов, потом выходит windows vista, в которой немного изменилась работа с атрибутами безопасности и этот код перестал работать, ты будешь руками править все эти N проектов?

если там много работы с реестром, то для этого у меня будет пара соответствующих функций. Собственно их и надо будет переправить. 

функция это уже какая-то абстракция, один шаг до ООП, к примеру функции такие:

это уже ООП, только ты не знаешь об этом  
лично я тут вижу класс registry, и два его метода, то что это его методы нам говорит название ф-й и то, что они принимают в качестве первого аргумента один и тот-же параметр, который определяет экземпляр объекта
Это все эквивалентно такому коду:

этот код с вашей с троллем точки зрения содержит много лишнего, а с моей точки зрения он понятней, к тому-же безопасней, так как нельзя вызвать метод с неверным аргументом  

 О да, void * — офигенческий ООП.
Тогда можно сказать, что асм - самый оопный язык, т.к. там вообще типов нет.

Добавлено через 13 минут и 42 секунды
Lazin, а представь, что ты наследуешь "класс", т.е. дополняешь структуру(на которую тьвой void* смотрит) новыми данными.
Что получишь? Рантайм-ошибку конечно же.

На самом деле тебе придется при наследовании ПЕРЕписывать все ф-ии, т.е. писать над ними обертку для наследника.

+ отсутствует контроль во время компиляции, не говоря уже о подчеркивании красным в IDE.

Это сообщение отредактировал(а) nerezus - 30.12.2008, 10:06

для этого надо будет ещё постараться.


не передергивай. Также можно сказать, что создание своего типа типа - еще один шаг до ООП.


для меня ООП - это классы со всей их байдой. Если у меня в программе много сложных данных, я разруливаю это при помощи структур и функций, работающих с этими структурами. Как то я вот так привык. 
Наверно скажешь - так это же ООП! 

Не используя классы, я избавляюсь от 
1) неявных действий в виде конструкторов/деструкторов
2) глупых ограничений, типа "эту функцию над этими данными выполнить нельзя, т.к. они вообще друг друга не знают" (как же они меня бесят)

ksili, ООП возможно и без классов, если все принципы ООП соблюдаются.

 Это не глупые ограничения, а глупые действия.

Ну я просто не знал, что их можно соблюсти и без классов

Добавлено через 7 минут и 56 секунд
А это реально бывает? или так, существует вероятность...

как видишь переписывать не пришлось, в общем, так выглядит наследование если убрать синтаксический сахар в виде классов  
что-бы такое не писать и придумали классы
вообще я тут не изображал виртуальные ф-ии, это не сложно в принципе, достаточно в my_base добавить указатель на таблицу виртуальных функций

1) используй explicit для конструкторов, что плохого в том что вызывается деструктор я не понял...
2) ради этого все и задумывалось, что-бы обходить ограничения есть шаблоны, например:

это плохо

а это хорошо, так-как будет работать как с std::vector<int>::intertor так и с int*

для меня ООП - это способ ясно выразить архитектуру приложения, классы в этом помогают  

Это сообщение отредактировал(а) Lazin - 30.12.2008, 10:58

У меня в legacy проекте есть комментарии и документация, два пункта из трёх. Но этого, оказывается, маловато. И даже переименовывание переменных не помогает. Чую отчётливый запах серы.


Сложно? Создаётся объект - вызывается конструктор, уничтожается объект - вызывается деструктор. Другое дело, что в них можно любой лишний код засунуть, ну так это не от ООП зависит. Опять же - действия конструкторов/деструкторов разрешено документировать так же свободно, как любой другой код.

Неявный вызов деструкторов? Это не std::auto_ptr ли в коллекциях замешан? Тут несколько другая ситуация, неоднократно упомянутая в различных источниках. Другой случай? Давай разберёмся - я искренне заинтересован.

Чем дальше, тем больше в программировании неявных действий. Ты же не ругаешься, что компилятор без твоего участия сам PE заголовок виндовому экзешнику выстраивает, секции кода/данных/стека размечает. Никогда не было трудностей с пониманием работы коллбеков (мне крышу сорвали в своё время начисто)? Сейчас даже в программировании на ассемблере неявностей выше крыши, и сделано это не ради запутывания несчастных мятущихся программерских душ, но для упрощения процесса программирования. И это ты ещё АОП не видел!

А по факту, современные скриптовые языки (самые известные - перл, пайтон, руби), все как один обладают вагоном неочевидных на первых взгляд тонкостей. Перловые "$<symbols>", пайтоновые "__<functions>__", и так далее. Я лично от таких плюшек в полном восторге.

Да, процесс программирования имеет постоянную тенденцию к усложнению, обсуждено тысячи раз. А всё для того, чтобы один программист мог как можно дольше удерживать в голове картинку происходящего.

Да я хотел обсудить этот случай на форуме, но некогда было. Потом просто переделал там способ достучаться до члена класса - и он перестал уничтожаться. Если вспомню как там это было - создам тему, но это наверно уже после праздников. auto_ptr там не было


Ну это как бы не повод называть топикстартера троллем. Ему ООП нафиг не нужно, т.к. он не сталкивался с большими проектами. А тут ему ещё стали втирать, что надо и любой мелкий проект писать с использованием ООП.

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

я думаю это заблуждение, программирование развивается в сторону большей абстракции, так-как:

• железо стоит дешево
• программисты стоят дорого

то-есть, нанимая 10 программистов на Си, работодатель получает через какое-то время готовый проект который относительно быстро работает, но он его разработка обошлась дорого и его сложно поддерживать, так-как для этого опять-же нужны программисты на Си. 
В то-же время можно нанять одного ООП-шника программиста на python, java, C# etc (в зависимости от задачи), который сделает то-же самое, но быстро, этот проект сможет поддерживать кто угодно, а разницу в скорости работы программы можно очень недорого компенсировать лучшим железом. В общем это намного дешевле, соответственно конечный продукт при том-же функционале будет стоить намного меньше.
Кстати, контроллеры нынче часто программируют на java, и в этом нет ничего плохого 



Это сообщение отредактировал(а) Lazin - 30.12.2008, 12:54

Можешь привести парочку наименований? Я хоть для общего развития почитаю про них, а то не слышал про такое... Кстати, хорошего на мой взгляд в этом ничего нет, но возможно, у меня взгляд замылен, и технологии уже утопали настолько далеко, что я безнадежно отстал от них. Тогда надо наверстывать 
Я думаю, ksili не зря упомянул про реальный сектор. А там - всякие питоновцы, пхп-вцы, C#-цы и прочие (около)web-кодеры места себе не найдут или найдут, но где-то на очень высоком уровне абстракции от собственно реального уровня промышленного оборудования... 
Для темы общесофтварной разработки - ты, конечно, прав...  
Опять же, сертифицированное железо, применяемое в реальном (т.е. околотехнологическом) производстве, стоит ОЧЕНЬ дорого (по сравнению с себестоимостью, конечно). Несертифицированное - просто мало кто применяет, а кто применяет - на свой страх и риск и как правило на некритичных\вспомогательных участках и\или в условиях недофинансирования...
правильно сказал, я бы даже немного добавил - очень нехватает людей, которые могут с легкостью обучиться чему-то нестандартному и подхватить на лету "идею", и именно люди с незашоренным философией ООП взглядом могут проявить себя в таком качестве максимально эффективно. Собственно, берусь это утверждать именно потому, что за несколько лет работы в этой отрасли из всех студентов, что у меня были - только два смогли реально быстро включиться в работу и оба, как ни странно, очень хорошо знали только ассемблер\базовый С, ну и аппаратно\электронную сторону железа. Всякие ООП им нафиг не сдались на то время...

вот например

Добавлено через 3 минуты и 23 секунды

реальный сектор это не только встраиваемые системы  


так ведь это не проблема ООП подхода а проблема обучения, кто мешает знать и то и другое?