информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Блокировка российских аккаунтов... 
 Отзыв сертификатов ЦБ РФ, ПСБ,... 
 Памятка мирным людям во время информационной... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Самое забавное, что я и сам всего пару лет назад был так категоричен 15.11.06 07:06  Число просмотров: 3053
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Это, когда сначала знаешь С в совершенстве, а потом читаешь
> сырцы - понятно, ито - долго, а если толком С не изучил, а
> за МФС взялся - полный бред.

Ну так плюсы и стоит для начала учить в отрыве от конкретной платформы

> Plain С, как раз - оптимальный компромис.

Ну уж нет. Холивор так холивор. А в гамаке и стоя так в гамаке и стоя.

> Как я уже сказал: Примитивы сами примитивные и
> замороченные. Конфликт с МФСями, как раз и начинается с
> потребности рассширить и слегка модифицировать интерфейс. И

Ну наследуйся напрямую от CWnd и переопределяй его виртуальные функции. Кто мешает? Но при этом у тебя под рукой все равно останется тот же ClassWizard и нормальный фреймворк. И это экономит немало времени.

> тут сразу возникает проблема: МФС, как все универсальное,
> позволяет всегда сделать "почти то, что надо", но никогда
> "именно то, что надо", потому, что по теории вероятности

Продолжая твою мысль, можно заключить, что сам USER/GDI - тоже никогда не позволяет сделать то что надо. Универсальное ж.

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

Собственно для решения подобных проблем и придуман ООП. Вот PlainC гуй практически невозможно не то что кастомизировать под новую задачу, но и вообще реюзнуть в том виде, как он есть. А MFC не запрещает тебе определять все те же обработчики сообщений, только завернутые в довольно удобные врапперы. Более того, удобных MFC классов, готовых к употреблению реально много. Вот скажи мне для примера, сколько тысяч лет тебе потребуется, чтобы создать на PlainC скажем вот такой интерфейс
http://www.bcgsoft.com/download/BCGCBDotNetExampleS.exe

А сколько тысяч лет тебе понадобится, чтобы перетащить часть контролов в другой проект, попутно немного поменяв поведение?

> Вот, уж, нет! Это садиться за C++ и OOD/OOP без знания
> > собственно ,гуи а также без понимая сути МессаджАПИ не
> стоит.
А с каких это пор, C++/OOD привязан к какому то там API, что без изучения оного API не стоит даже пытаться понять OOD?
<programming> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach