Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Já Vánoce juchuchu
oslavím na Lopuchu!

Lopuch.cz
Jméno:
Heslo:
Podpora LCD:
 
Klub C, C++ [ŽP: neomezená] (kategorie Programování) moderuje Šéf Lopuchu.
Archiv

Články

Jak bezpečně ukončit vlákno z DllMain
FastAllocPool - urychlení častých alokací a dealokací
Akce a zpráva jako objekt
Tuply v C++
Efektivní alokátor malých objektů a tady druhý a třetí díl
Šablony: Být vládce kvalifikátorů
Vracíme z funkce objekty
Základy komunikace mezi procesy (ve Windows)
Multiple Interface a Instance Factory
Multithreading v C++ (ve Win32)
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: zdbjhxj
[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
bredy 17.9.2007 01:23  643
Dodatek k příkladu: Zapomněl jsem napsat, že tohle je výsledek IntellSense (integrovaný do Visual C++). Ve Visual Assistu by mi už k napsání deformers stačilo napsat def a slovíčko by na mne vyskočilo v seznamu pod kurzorem. Při napsání IFB by na mne zase vyskočil seznam všech tříd začínající na IFB, což jsou momentálně jen dvě (import a export). V Eclipse bych dopadl asi stejně jako v IntellSense.
bredy 17.9.2007 01:18  642
huh Javovske souborové API je v základu navržené mnohem lépe, než STLskovké iostreamy. Ovšem čím výš se člověk dostává, tím má pocit, že práci přebírali horší a horší programátoři. Nevim...

King Hlavním smyslem nástrojů má být zrychlení práce. Představ si, že pro napsání následujícího kódu mi stači: 
if (deformers) control->EnableWhatImportGroup(IFBXImportControl::importSkinning)

if (defo<c+sp>) cont<c+sp>->Ena<ent>(IFBXIm<c+sp>::importSk<ent>)
Legenda:
<c+sp> - control+space 
<ent> - enter

Místo původních 81 stisků mám 42. Což vede na dvojnásobnou rychlost kódování. A to jsem si nezapočítal nahlížení do dokumentace.

(Ještě dodatek: C+SP mačkám pro doplnění symbolu, a když na mne vykočí seznam, musím jej ještě potvrdit enterem, když ne, pak rovnou vyskočí symbol. Po šipce a čtyřtečce vyskakuje seznam automaticky, proto jen Enter.)

Jinak také nemám rád generované kódy, i když wizardem pro UI nepohrdnu, ale většinou si výsledný kód pak upravím. Co se mi vůbec nelíbí jsou vlastní preprocesory (qmake v Qt), to už ukazuje spíš na neschopnost vývojářů vymyslet nekteré konstrukce lépe (např. pomocí šablon)
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 16.9.2007 23:21  641
Neni pravda, aplikace napsana v Perlu bude vypadat uplne jinak nez aplikace delajici totez napsana v Jave. Toho jsem ostatne zivoucim dukazem, kdy jsem jeden zapoctak, kterej byl povinne v Perlu, odevzdal sice v Perlu, ale objektove orientovanej a s tridama navrzenejma tak, jako kdybych to delal v Jave. Kdyz jsem to predvadel, tak na me ostatni (jak spoluzaci, tak vyucujici) koukali, jako kdybych spadnul z visne. Takze ona je sice pravda, ze v kazdem programovacim jazyce se daji psat fortranovske programy, ale kupodivu se to nedela.
huh huh 16.9.2007 22:51  640
Kdokoliv [639]: Promin, ale struktura aplikace nijak nesouvisi s jazykem, ve kterem je napsana.
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 16.9.2007 22:32  639
Nehlede na to, ze v Jave proste nacitani textoveho souboru neni operace, kterou by bezny programator bezne delal - i ten textovej soubor bude mit typicky nejakou strukturu a my chceme jako vysledek dostat nejaky objekt (ci sadu objektu) v pameti, ktere budou tuto strukturu reprezentovat - takze si typicky napiseme nejake vlastni tridy, factory a providery, ktere budou toto poskytovat - pri implementaci sice budeme potrebovat nacist ten soubor po radkach, ale to budem delat jenom jednou (a vlastne piseme svym zpusobem knihovnu), zatimco pro vlastni pouzivani tohoto typu textoveho souboru uz nebude potreba vubec vedet, jak se textovy soubor nacita. Jinymi slovy bude-li na tom projektu delat padesat lidi, tak jeden z nich napise patricne providery a ostatni uz to budou jenom pouzivat, takze nepotrebujou vubec umet zonglovat s BufferedReadery a podobne. To je tak nejak filosofie celeho javovskeho vyvoje.
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 16.9.2007 22:27  638
huh: A to ja Te zase ubezpecim, ze jelikoz v C uz drahna leta nedelam, tak bych na fopen, fgets a podobne chvili vzpominal (pravdepodobne bych si nakonec vzpomenul) a uz vubec ted treba nevim, jak je to s tema streamama v C++, ja proste veci, ktere nepouzivam, rychle zapominam - at uz jsou jednoduche, nebo slozite; naopak veci, ktere pouzivam, si pamatuju, at uz jsou jednoduche, nebo slozite. Proc nemuze mit File metodu getBufferedReader svuj duvod urcite ma, ale nechce se mi nad tim premyslet (krom toho asi nejsem ten nejpovolanejsi, kdo by mohl delat prednasky ohledne objektove hierarchie javovskych streamu).
sekory Sekory The journey of thousand miles - starts with a single step. 16.9.2007 22:23  637
Bredy: Dík, ale ta cena mi příjde dost přehnaná, možná ne pro někoho kdo se programováním živý, ale mně určitě. Možná zkusím ten IntelliSense.
huh huh 16.9.2007 22:23  636
A to já zase musím souhlasit s Kingem (a se mnou i Bruce Eckel ☺), na pythonovské
f = file("jmeno", "r")
nebo ceckovské
FILE* f  = fopen("jmeno", "r")
si vzpomenu i po pul roce nepouzivani, na to, jak to udelat v Jave zapomenu do deseti minut po nadatlovani. Ano, javovske API je nejflexibilnejsi, ale hlavne mu uplne chybi zkratky pro casto pouzivane operace. Proc proste nemuze mit File metody jako getBufferedReader() ?
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 16.9.2007 20:36  635
King: Tohle ale zase neni pravda. Ja napsal celou javovskou diplomku v emacsu bez jakehokoliv inteligentniho doplnovani - mel jsem jenom v Opere otevrenu dokumentaci s javovskym API a s SWT API (coz byla knihovna, kterou jsem pouzival). Mimochodem kod, ktery otevre a precte textovy soubor, bych pravdepodobne dohromady dal. Nicmene obdobne obtize s tymz ukolem bych mel v libovolnem jazyce - C, php, perl, ruby - ve vsech jsem to delal a v zadnym si to po urcite dobe nepamatuju. Navic proste typicky programator enterprise java aplikaci nema jako svoje denni ulohy otevirani textovych souboru, stejne tak kdyz vezmes prvniho ruby-on-rails programatora (kterych imho bude vic a vic pribyvat), ktery posledni dobu nedela nic jinyho nez weby, tak mozna tuhle ulohu v ruby taky nezvladne, jakkoliv je to tam trivialni.
Nezapominejme u te Javy, ze ona ma snad nejsirsi standardni API (tj. bez nejakych dalsich rozsirovacich knihoven) ze vsech jazyku, to si proste nemuze pamatovat nikdo. Na druhou stranu pro nejakou omezene pole pusobnosti, se kterym zrovna pracuju, se to pamatovat da a pak clovek ty nastroje nepotrebuje. Ty nastroje se hodi, kdyz clovek casto dela jednorazove s necim neobvyklym (ale to zase plati pro vsechny jazyky).
king King Born to be king - ... 16.9.2007 20:20  634
jeste duvod - prijde mi ze kdyz je jazyk tak slozity, ze potrebuje takove nastroje (nebo vskutku znatelne zlepsi praci), tak je s tim jazykem neco v neporadku ;)
king King Born to be king - ... 16.9.2007 20:19  633
ja obecne nesnasim jazyky kde jsem zavisly na nastrojich - viz treba java, kde se bez generovani kodu a napovedy neobejde snad nikdo (viz ma oblibena otazka pro javisty: umite z hlavy napsat kod, ktery otevre a precte textovy soubor?) - je to proste styl prace ktery mi nevyhovuje...
ve vetsi mire pouzivam python, bash, SQL a C a ani v jednom z tech jazyku mi napovidac nechybi... kdyz uz pisu neco v cem se tolik nevyznam, nebo si chci usetrit psani dlouhych nazvu funkci, pouziju trivialni doplnovani ve ViMu, ktere na to bohate staci a funguje i bez kontextu (coz u dynamickych jazyku stejne dost dobre nejde)...
bredy 16.9.2007 20:08  632
SekoryVisual Assist X je opravdu program do Visual C++. $149 plná verze. Na linuxu používám Eclipse CDT a ten má svůj napovídač a poslední verze se hodně zlepšila, jako že už umí napovídat i na některé templatované konstrukce. IntellSense se většinou nechytá. Visual Assist X má nejlepší parser a index, takže velmi často je jeho nápověda dost relevantní.

Bez napovídače bych si nedokázal představit žádné programování. Už mi to skoro připomíná programování na ZX Spektrum, kde se příkazy psaly jedním stisknutím klávesy. Stačí napsat dve písmena a zmáčknout Control+Space a buď na mne vyskočí rovnou symbol, nebo seznam, kde je pár položek. Někdy to používám, když hledám příkaz o němž vím, že zhruba vím, jak se jmenoval. Zmáčknu C+S a začnu psát a většinou po pár písmenech příkaz vidím a po odklepnutí i seznam parametrů. Nebo když potřebuju rychle vidět seznam metod, napíšu jméno třídy, čtyřtečku (nebo this se šipkou) a hned na mě vyskočí seznam metod a proměnných té třídy.

Můj nadřízený, senior programmer dodnes programuje ve vimu a v programu se orientuje pomocí grepu. Neviděl jsem, že by tam měl nějaký napovídač ani nejzákladnější obarvovač syntaxe. Jednou jsem s ním dělal úpravu v programu. Úprava v eclipse byla hotova za 10 minut, ale na jeho vimu jsme nad tím ztrávili hodinu. Tak nevím.

PS: Napovídač používám i pro PHP (PSPAD nebo PHPEclipse). Pro zajímavost, nejlepší obarovač syntaxe je v Eclipse. Visual Assist X zase přes obarvovač ukazuje syntaxtické chyby už v době psaní, takže opravdu ušetří spoustu času překladem.
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 14.9.2007 17:26  631
Sekory: Tak to by se zase melo casem zlepsit, ty nejcastejsi veci si proste zapamatujes.
huh huh 14.9.2007 16:25  630
Sekory [625]: Jo, presne tak.
sekory Sekory The journey of thousand miles - starts with a single step. 14.9.2007 15:54  629
No občas se někam kouknout, v tom problém nevidím, šlo mi o to, že v tom WinApi prakticky nic jinýho nedělám, než že odněkud opisuju.
[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt