Каморка

ajkj2em писал(а):

Stanislav писал(а):Ассемблер - то что нужно, я на ассеблере Виндовз напишу - легко!

я работал с парнем, который ради прикола написал простенький
notepad-like редактор на чистом ассемблере над win32 api ... по
сути просто WinMain и WinProc, но всё это было impressive waste
of time

Ну да, вспоминается анекдот про вырезание гландов через жопу

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

Разве что добавлю если юзер вызывает функцию которую вы не реализовали то юзера ждет больщой сюрприз, суппорт ждет головная боль, манагера проекта ждут неприятности а девелопера ждет небольшая ... а гхм ну скажем промывка брайна:)

А вот теплайты средствами Си не решить никак. От такие дела

Вы меня тоже удивили, потому что то, что вы написали во втором посте, никак не отражает то, что написано в первом...

Про мышление ...

А недолжно быть никакого мышления.... Ни ООП, ни пережитков и привязанностей асемблтровщины.
Мышление должно тыть оптимальным в _каждом_конкретном_случае_.
Даже в пределах одного проекта, или его куска - разных "мышлений" может быть множество (когда темплейты приладим, когда класс напишем, когда до класса со статик мемберами опустимся, когда просто напишем функции в глобалскоп ). Всё остальное - ложные чувста и стремления "соответствовать".
Вот пример - спрашивают парня, а зачем тебе то, что ты пишешь (некий глобально используемы объект, сделаный синглентоном) - поректировать в виде класса. Никакого наследования не предполагается. Ответ был - так надо же иметь ООП мышление! Дикость... Мышление ради мышления.

vg писал(а):Про мышление ...

А недолжно быть никакого мышления.... Ни ООП, ни пережитков и привязанностей асемблтровщины.
Мышление должно тыть оптимальным в _каждом_конкретном_случае_.
Даже в пределах одного проекта, или его куска - разных "мышлений" может быть множество (когда темплейты приладим, когда класс напишем, когда до класса со статик мемберами опустимся, когда просто напишем функции в глобалскоп ). Всё остальное - ложные чувста и стремления "соответствовать".
Вот пример - спрашивают парня, а зачем тебе то, что ты пишешь (некий глобально используемы объект, сделаный синглентоном) - поректировать в виде класса. Никакого наследования не предполагается. Ответ был - так надо же иметь ООП мышление! Дикость... Мышление ради мышления.

Абсолютно согласен ! Мышление ради мышления.- действительно прекрасное определение того, что я вижу в последние лет 6-7 у многих программистов. Одна из причин – засилье UML/Design Pattern-овых программистов, которые смотрят на любую задачу сквозь призму неких шаблонов. Я лично знаком с программистом, у которого ВСЕ классы названы так ։
<something>Factory
<something>Visitor
<something>Singleton
...

Т.е. не шаблоны используются для решения задач, а задачи используются для применения шаблонов То же самое с OOP подходом. Вот сейчас появился уже новый – AOP подход. Надо ждать нового поколения AOP-ориентированных программистов

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

Мне кажется все полезно что в рот полезло, если задача решается паттернами - надо ее решать паттернами, если она ими не решается - надо доказать себе что она ими не решается. У нармального мастера обычно большой набор гаечных ключей...

Такие дела.

aissp писал(а):Не вижу в етом ничего плохого, если код читаем.
...

Мне кажется все полезно что в рот полезло, если задача решается паттернами - надо ее решать паттернами, если она ими не решается - надо доказать себе что она ими не решается. У нармального мастера обычно большой набор гаечных ключей...

Такие дела.

Позвольте мне не согласится с одним Вашим определением (я его выделил наверху). Первична всегда задача. Т.е. надо доказывать, что тот или иной pattern (aka гаечный ключ) подходит для решения этой задачи, а не наоборот. В противном случае можно получить то, о чем я писал выше. Любая более–менее сложная задача несравненно сложнее любого patterna.

Что касается читаемости кода, то применение design patterns далеко не всегда помогает этому делу.

P.S. Про депутатов и мат совсем не понял, к чему Вы это. Я про переменные вообще ничего не писал. Разве что соглашусь, что некоторых депутатов без мата вспоминать не всегда получается

Gandalf писал(а): Что касается читаемости кода, то применение design patterns далеко не всегда помогает этому делу.

Я бы добавил - никогда (если речь чисто о читаемости).

ПС.
Разве, что ежели UML-кубизмы рисуют ( ) и жирно шрифтом 16 Bold New Times пишут - это, мол, для тех кто в танке Mediator, а это вот - подписано же Subscriber (мол, не видишь чё ли?).

Хотя надо признаться были случаи у меня, когда вот, например, UML картинки, так сильно помогали (как помощь к описанию жутчайше могутного XML-представления данных одной из известных контор).

А так .... иногда вводят людей в конфуз, ибо не всегда различают они template и design patterns (тута как-то обсуждали ) ни по сути ни формально в использовании.

Ну возможно я неудачно выразился, ок попробую перефразировать. Паттерны ето неплохо и знать их необходимо, как впрочем и многое другое, чтобы считать себя проффесионалом, ну скажем в с++ или в яве... От такая от загогулина понимаешь=) Что касается переменных = голословно говорить deputatVisitor ето плохое определение, имхо, низзя, надо смотреть помогает ли ето читать код али нет - я ето имел ввиду когда про депутатов грил.

aissp писал(а): чтобы считать себя проффесионалом

Да пустое это... Важнее - чтоб на работу приглашали.

насколько мне известно ни в одной конторе уровня SONY/Microsoft/IBM/Corel/..... не используют UML а уж OOP используется чем меньше тем лучше.

В SONY даже STL и AxtiveX свои на Cи написаны и чужое ни в коем случае не допускаоется

Lepsik писал(а):STL .. на Cи написаны

aфтор жжёт

ajkj2em писал(а):

Lepsik писал(а):STL .. на Cи написаны

aфтор жжёт

Да ладно. Всеже поняли о чём речь. А кстати COM написать экстрима ради на C несложно (только никому не нужно ). А вот ActiveX - проблематично на плайн С биться.

Lepsik писал(а):насколько мне известно ни в одной конторе уровня SONY/Microsoft/IBM/Corel/..... не используют UML а уж OOP используется чем меньше тем лучше.

В SONY даже STL и AxtiveX свои на Cи написаны и чужое ни в коем случае не допускаоется

Reuters подойдёт?

ajkj2em писал(а):

Lepsik писал(а):STL .. на Cи написаны

aфтор жжёт

stl свой конечно на С++, а activex свой на чистом Си и они несовместимы с виндовыми. Уж не знаю зачем им эти извращения.
У меня приятель постоянно жалуется на сонькевские прибамбахи.
В начальстве ярые сишники засели и инакомыслие подавляют.