Здравствуйте, ДимДимыч, Вы писали:
S>>в VCL — все окна работают в одном потоке.
ДД>В VCL, насколько помню, есть класс TThread. Ничто не мешает с его помощью разделить потоки обработки GUI-сообщений и функционал приложения.
Но GUI весь будет работать в одном потоке.
Проблема России не в том, что она не может накормить бедных, а в том, что богатые никак не нажрутся
Dopolnu skazannoe vishe.
delphi predstavlyaet soboy etakuu smes buldoga s nosorogom: sama VCL napisana s dovolno gramotnim sobludeniem paradigmi OOP, hotya i v ney est lyapi v etom otnoshenii, no architecturno VCL gorazdo pravilnee uzaet OOP chem naprimer MFC (uzhas esche tot), no QT naprimer v etom otnoshenii delaet VCL. U VCL est drugaya problema — tormoznaya ona, v chem i uprekaut obichno delphyatnikov. No tormoznaya i pravilnaya VCL eto ne est beda Delphi. Osnovnaya beda v tom chto IDE delphi nastoychivo tolkaet programmista uzat FP paradigmu pri programmirovanii. Vot i poluchaetsa chto kod napisanniy tipichnim Delphi programmerom — eto FP-style kod uzauschiy objecty predostavlyaemie VCL, samoy po sebe napisannoy v otnositelno normalnom OOP stile. Etim i objyasnaetsa prostota delphi dlya nachinauschih — posle izuchenia v shkole tipichno funkcionalnogo podhoda legko perekluchitsya na delphi, ibo podhod tam po suti tozhe funkcionalny. No uzanie OOP-style bibliouteki kak VCL vovse ne oznachaet togo chto _vash_ kod napisan v paradigme OOP. Beda IDE opyat zhe ne v tom chto ona silno prostaya,- on-click components drops, events handlers generator etc — eto vse ochen horosho. Beda v tom chto vse etot avtomaticheski sgenerenniy kod na samom dele skoree FP nezheli OOP.
Za primerami daleko hodit ne nado: berem formu, kidaem na nee button, doubleclick'aem na etot button, poluchaem chtoto tipa:
TMainForm.ButtonHelloClick(Sender: TObject)
begin
end;
Pishem mezhdu begin i end ShowMessage('Hello'); i raduemsya. Vse ok. NO! Eto ved pryamoe narushenie paradigmi OOP! Pochemu eto pri clicke na object TButton u menya avtomaticheski vipolnyaetsa method TForm?? Vot i poluchaetsya — chto kod napisanniy programmerom v delphi pronizan logikoy mezhdu _raznimi_ logicheskimi unitami-objectami, chego bit _ne_dolzhno_ po osnovnoy paradigme OOP. Kak po drugomu? Posmotrite naprimer kak eto delaetsya by default v Java.
Vozvraschayas c subju v tekuschem contexte C++ — sam po sebe yazik vesma neprihotlivy, chem i objasnyaetsa ego populyarnost i dolgozhivuchest'. Tipichnie Delphyatniki perehodya na C++ prodolzhaut kodit' v privichnom dlya sebya FP stile, Java programmeri generyat kod perenagruzhenniy ispolzovaniem OOP — slishkom mnogo svyazey po nasledovaniyu tozhe ne est good. Delphisti kstati vidya kod napisanniy javistami nifiga v nem ne ponimaut . A javisti vidya kod napisanniy dekphistami figeut ot skvozyaschego v nem FP. I both delphisty i javisty figeut ot koda napisannogo true-Cpp'shnikami, napisannogo s uzaniem templatov, multiple inheritance etc I lish true Cpp'shniki svisoka smotray na kod bivshih delphistov i javistov, predstavlyauschiy dve kraynosti — pure FP & pure OOP
PS Vobschem vsem delphistam rekomenduu izuchit java. I ne na urovne hello worl, a poizuchat stil koda realnih proekov. Chisto dlya sebya hotyabi.
PPS sorry, nabolelo :/
Здравствуйте, apple-v-otpuske, Вы писали:
AVO>PPS sorry, nabolelo :/
Слуш, найди транслитератор а... А то мне например твою писанину читать тоже "наболело"
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
CC>Слуш, найди транслитератор а... А то мне например твою писанину читать тоже "наболело"
gm sorry no na poisk "transliterator" mne predlagaut chegoto skachat i postavit. Eslib ya mog chegoto postavit na etoy machine mne bi ne bil bi nuzhet transliterator.
Ni odna iz etih linok tozhe ne pomogla: http://www.mashke.org/Conv/ http://www.cifirica.ru/cifirica.php http://www.privet.com/decoder — eto vrode to... no ne rabotaet applet.
Здравствуйте, apple-v-otpuske, Вы писали:
CC>>Слуш, найди транслитератор а... А то мне например твою писанину читать тоже "наболело" AVO>gm sorry no na poisk "transliterator" mne predlagaut chegoto skachat i postavit. Eslib ya mog chegoto postavit na etoy machine mne bi ne bil bi nuzhet transliterator.
re-translitted (ne mogu ispravit.. ibo net russkogo :
Дополну сказанное висхе.
делпхи представлыает собоы етакуу смес булдога с носорогом: сама ВCЛ написана с доволно грамотним соблудением парадигми ООП, хотыа и в неы ест лыапи в етом относхении, но арчитеcтурно ВCЛ гораздо правилнее узает ООП чем например МФC (ужас есче тот), но QТ например в етом относхении делает ВCЛ. У ВCЛ ест другаыа проблема — тормознаыа она, в чем и упрекаут обично делпхыатников. Но тормознаыа и правилнаыа ВCЛ ето не ест беда Делпхи. Основнаыа беда в том что ИДЕ делпхи настоычиво толкает программиста узат ФП парадигму при программировании. Вот и получаетса что код написанниы типичним Делпхи программером — ето ФП-стыле код узаусчиы обйеcты предоставлыаемие ВCЛ, самоы по себе написанноы в относително нормалном ООП стиле. Етим и обйыаснаетса простота делпхи длыа начинаусчих — после изучениа в схколе типично функcионалного подхода легко переклучитсыа на делпхи, ибо подход там по сути тоже функcионалны. Но узание ООП-стыле библиоутеки как ВCЛ вовсе не означает того что _васх_ код написан в парадигме ООП. Беда ИДЕ опыат же не в том что она силно простаыа,- он-cлиcк cомпонентс дропс, евентс хандлерс генератор етc — ето все очен хоросхо. Беда в том что все етот автоматически сгенеренниы код на самом деле скорее ФП нежели ООП.
За примерами далеко ходит не надо: берем форму, кидаем на нее буттон, доублеcлиcкьаем на етот буттон, получаем чтото типа:
ТМаинФорм.БуттонХеллоCлиcк(Сендер: ТОбйеcт)
бегин
енд;
Писхем между бегин и енд СховМессаге(ьХеллоь); и радуемсыа. Все ок. НО! Ето вед прыамое нарусхение парадигми ООП! Почему ето при cлиcке на обйеcт ТБуттон у меныа автоматически виполныаетса метход ТФорм?? Вот и получаетсыа — что код написанниы программером в делпхи пронизан логикоы между _разними_ логическими унитами-обйеcтами, чего бит _не_должно_ по основноы парадигме ООП. Как по другому? Посмотрите например как ето делаетсыа бы дефаулт в Йава.
Возврасчаыас c субю в текусчем cонтеxте C++ — сам по себе ыазик весма неприхотливы, чем и обйасныаетса его популыарност и долгоживучесть. Типичние Делпхыатники переходыа на C++ продолжаут кодить в привичном длыа себыа ФП стиле, Йава программери генерыат код перенагруженниы исползованием ООП — слисхком много свыазеы по наследованиыу тоже не ест гоод. Делпхисти кстати видыа код написанниы йавистами нифига в нем не понимаут . A йависти видыа код написанниы декпхистами фигеут от сквозыасчего в нем ФП. И ботх делпхисты и йависты фигеут от кода написанного труе-Cппьсхниками, написанного с узанием темплатов, мултипле инхеританcе етc И лисх труе Cппьсхники свисока смотраы на код бивсхих делпхистов и йавистов, представлыаусчиы две краыности — пуре ФП & пуре ООП
ПС Вобсчем всем делпхистам рекомендуу изучит йава. И не на уровне хелло ворл, а поизучат стил кода реалних проеков. Cхисто длыа себыа хотыаби.
ППС сорры, наболело :/
apple-v-otpuske wrote: > delphi predstavlyaet soboy etakuu smes buldoga s nosorogom: sama VCL > napisana s dovolno gramotnim sobludeniem paradigmi OOP, hotya i v ney > est lyapi v etom otnoshenii, no architecturno VCL gorazdo pravilnee > uzaet OOP chem naprimer MFC (uzhas esche tot), no QT naprimer v etom > otnoshenii delaet VCL.
А их всех делает Swing — там везде используется MVC.
AndrewVK wrote: > C>А их всех делает Swing — там везде используется MVC. > А Swing делает WPF, потому что там разделение аспектов лучше
Нет, это уже более высокий уровень — так что сравнивать не совсем корректно.
Здравствуйте, Cyberax, Вы писали:
>> А Swing делает WPF, потому что там разделение аспектов лучше C>Нет, это уже более высокий уровень — так что сравнивать не совсем корректно.
С чего это он более высокий? Тот же самый MVC, только называется по другому.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, ShibaON, Вы писали:
SON>Я ни разу не сталкивался с багами компилеров Borland's. Ни разу! Где они? Покажите мне их? Некорректная работа на всяких там {{{{{{{{{{{{{{{{{{{{{}}}}}}}}}}}}}}}}}}}}} — это не довод!
А вот я постоянно сталкивался когда на багланде писал... интересно почему?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
. A javisti vidya kod napisanniy dekphistami figeut ot skvozyaschego v nem FP. I both delphisty i javisty figeut ot koda napisannogo true-Cpp'shnikami, napisannogo s uzaniem templatov, multiple inheritance etc I lish true Cpp'shniki svisoka smotray na kod bivshih delphistov i javistov, predstavlyauschiy dve kraynosti — pure FP & pure OOP 
no na poisk "transliterator" mne predlagaut chegoto skachat i postavit. Eslib ya mog chegoto postavit na etoy machine mne bi ne bil bi nuzhet transliterator.
:
