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

Když diskuse,
tak s Lopuchem

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: uyqxrun
[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
mach 18.10.2007 13:16  653
via mj Dark side of C++
bredy 18.10.2007 09:58  651
Deadve VC2008 Express Beta 2 zrovna dělám. Je to o trochu lepší než 2005, ale má to taky své mouchy. Mám pocit, že IntelliSense je o píď chytřejší, Edit & Continue si o píď lépe poradí s některými změnami, které dříve nešly, ale v zásadě nic převratného jsem neobjevil. Ani tato verze neumí překlad na vícejádrovém procesoru (Komu to chybí, doporučuju tento návod, jak to udělat, funguje i na VC2008). O jak moc optimální překlad je jsem nezkoumal.

Jinak to trpí stále stejnými vadami. Nápověda jednoznačně preferuje CLI (takže 95% stiskem F1 nenajdete nic použitelného a člověk musí ručně do search). Debugger občas spadne a sebe celé VC. Beta bohužel často padá, například když při běhu programu spustím překlad po edit & continue. Sestřelit aplikaci, slinkovat edit & continue a následně provést nový překlad vede na okamžitý pád.

Knihu ti poradí někdo z přítomných. Já už si to nepamatuju. Vím že jsem se učil Pascal, pak jsem měl knižku pro přechod z Pascalu do C a nakonec nějakou učebnici pro přechod z C do C++. Souběžně s výukou C++ doporučuju knihu na téma objektového modelování, nebo o objektech obecně. Zvlášť pokud jsi dosud o objekty nezavadil. Síla v C++ je totiž hlavně v objektech. Dost často se setkávam s lidmi, kteří C++ používají jen jako pozměnený C. Ale, to je chyba!
dead 17.10.2007 19:26  650
Skusal tu niekto Visual 2008 beta2? a chcel som sa este opytat aku knihu by ste odporucili uplnemu zaciatocnikovi(to jest mne) na c++?
huh huh 17.9.2007 16:11  649
Bredy [648]: Proti tomu nic nenamitam.

Kdokoliv [647]: kdyz v tom Pythonu si staci pamatovat dve slova: "file" a "read", tedy 8 pismenek, v Jave jich je proste mnohem vic :-)
bredy 17.9.2007 09:23  648
huhCoz nic nemeni na tom, ze si pro praci s nejakym formatem souboru napises funkce (knihovnu), pokud teda neni uplne trivialni.
Soubor většinou knihovna neotvírá. Dostává na vstup již otevřený stream. Je to lepší, pokud chceš například formát poslat po síti, rourou nebo s ním provádět jiné techtlemechtle :-)

Javovské streamy jsou k tomu perfektní. Bohužel následně člověk zjistí, že RandomAccessFile nedědí InputStream, takže nemůžeš z něj číst standardním způsobem. A objekt určený k transformaci RandomAccessFile na InputStream je od jisté verze deprecated a náhradu jsem nenašel (možná jsem se špatně díval).
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 17.9.2007 09:09  647
Bredy: No, zase si priznejme, ze ona to dvojnasobna rychlost nebude, protoze neco jineho je psat cisty text a neco jineho je zmacknout C-space, koukat co Ti to vyhodi, jestli opravdu jedinou vec nebo jestli vic, ze kterejch musis vybrat, a tak dal. Zrychli to, to jo, ale urcite ne o polovinu.

huh: Jeste jsem zapomnel na jednu vec - kdyz potrebujes pri beznem pouzivani pocitace (tj. ne nutne v ramci programovani nejakeho projektu) nacist textovej soubor, nejak ho projit a neco s tim udelat, tak je velmi pravdepodobne, ze sahnes prave po perlu, pythonu, ruby nebo awk (pokud to nepujde nejak hezky rovnou v shellu), po Jave spis ne (a ne jenom kvuli tomu, jak v ni je nebo neni slozite ten kod napsat), stejne tak asi ne po C++ nebo C#. Tudiz mozna tez prave proto, ze takovehle ulozky casto resis ve svem oblibenem scriptovacim jazyce, si pamatujes, jak se v tom jazyce prochazeni textoveho souboru resi. Kdybys pri kazde takovehle prilezitosti psal ten kod v Jave, tak si to taky budes pamatovat.
huh huh 17.9.2007 01:55  646
Bredy [644]: A ?
huh huh 17.9.2007 01:50  645
Bredy [642]: Ano, prave proto, ze Javovska knihovna je navrzena pomerne komplexne a flexibilne (a tudiz je i relativne slozita), by mela obsahovat zkratky pro nektere "relativne casto provadene" (coz je samozrejme do znacne miry subjektivni) operace. Jako je treba otevreni souboru.

Kdokoliv [641]: Coz nic nemeni na tom, ze si pro praci s nejakym formatem souboru napises funkce (knihovnu), pokud teda neni uplne trivialni.

Ja se proste v ruznych jazycich/knihovnach musim do dokumentace divat ruzne casto, jak psal Eckel, v Pythonu si casto tipnu a casto se trefim ☺, za to psat v Jave (zejmena pre 1.5) bez doplnovani je pro me naproste utrpeni.
bredy 17.9.2007 01:26  644
huhSprávně C++ 
std::ifstream soubor("jmeno",std::ios::in);
if (!soubor) throw NepodariloSeOtevritSouborVyjimka("jmeno");
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).
[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt