Příspěvky

406

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 11. 12. 2010, 00:14:12 »

... nejsem velký zastánce nadužívání šablon, pokud to nemá smysl. A nemá to smysl tam, kde nepotřebuju honit výkon na úkor čitelnosti a flexibilnosti. Prostě běžná rozhraní mám klasicky abstraktní s virtuálními metodami a používám šablony opravdu tam kde to je třeba. Třeba tam, kde si se standardním rozhraním nevystačím, například proto, že rozhraní nejde ani popsat pomocí vyjadřovacích prostředků C++ (například, "objekt musí mít defaultní konstruktor", atd)

....

Psát program celý v šablonách s tím, že místo konkrétního rozhraní tam mám všude T... to se samozřejmě dá, ale člověk se musí připravit na jiné obtíže, například že díky neexistuence konceptů bude často chyby hledat v nějaké desáté úrovni vnoření a louskat hlášky GCC, proč zrovna tenhle objekt nejde do funkce použít a co mu ještě chybí, aby to šlo (třeba nemá defaultní konstruktor)

...

Jinak rozhraní program nic nestojí. Implementace rozhraní stojí jednu tabulku VT navíc a dynamic_cast je asi nejnáročnější operace, která tam je (a taky není potřeba vždy).

...
No a teď si vem, že máš v požadavcích BINÁRNÍ kompatibilitu. Nicméně nevidím nutnost simulovat stará rozhraní nějak zásadně. Vždycky to funguje tak, že se simulace šoupne do jiného zdrojáku aby se nepletla s originální obsluhou... a dál se na ní nesahá, jen se pak nakonec přilinkuje. Koho zajímá, že simulace volá simulaci vola simulaci a nakonec volá původní obsluhu? Smyslem je "aby to fungovalo" a ne aby to fungovalo efektivně.

Já nejsem příznivcem nadužívání, nebo protěžování čehokoliv. Všechno co bylo vymyšleno, jsou jen nástroje, které mají za úkol mi nějak ulehčit, zefektivnit, nebo umožnit práci jejich použitím - proto tvrdím, že je pitomostí vždy a všude tvrdošíjně prosazovat objektový, nebo naopak procedurální přístup. To jsou extrémismy a ty jsou od přírody špatné. Nicméně ty nástroje existují a je zas na druhou stranou škoda jich nevyužít, v případech kdy je to vhodné - a ty případy zas určuje konkrétní člověk (lidé), který daný kód tvoří.

Souhlasím s Logikem, že ten akademický příklad je už od začátku špatný, a takový kód je nejlepší omlátit autorovy o hlavu, a pak jej celý přepsat do použitelnější podoby. Jednou z vhodných možností je použít zásad. Žel bohu v praxi (a tady souhlasím s Vámi) je však pro toho kdo s ním pracuje nejlepší na něj nabalit další vrstvy a pak děj se vůle boží. To že tu vrstvu oddělíte do externích modulů, či jakkoliv jinak, však neřeší základní nepříjemnost celého tohoto postupu, a to tu že celou věc znepřehledňuje, zanáší do ní spoustu nových stavů a potencionálních chyb. Vy se v tom možná vyznáte, ale jakmile někdo projekt převezme po Vás, může si jít hodit smyčku (bez urážky, nemyslím tím nic špatného směrem k Vám, vidím to prostě tak i z vlastní zkušennosti).

Celé to připomíná přístup javovských programátorů, kde si vezmete jednu konkrétní funkci z jedné konkrétní knihovny a než se dostanete k tomu co a jak to dělá, prolezete mraky dalších knihoven, vrstev a nadstaveb... A to je špatně (bez ohledu na to zda to někdo řeší či ne, a že to někoho určitě bude zajímat, na to vemte jed ).

Jinými slovy, Vaše řešení podle mě problém se neřeší, jen obchází. Neřeší se nemoc, pouze se odstraňují symptomy.

Navíc je omyl, si myslet, že používání šablon může vést k vyššímu výkonu. Mám zkušenosti i s opakem. Hlavně papačka je to ladit - skoušel jste si někdy seznamy typů z Loki? Krása, ne? (Pravdou je, že tu chybu jsem si tam zanesl sám v jedné ze tříd, ale než jsem ji našel, měl jsem okousaný všechny nehty, tužku, nervy v kýblu a o třicet procent víc šedin) 

Prosím, při přetypování v hierarchii nedymaickou cestou doporučuj static_cast. reinterpret_cast nikdy!

Operátor reinterpret_cast<>( ) jsem uvedl z důvodu, že umožňuje převod i na jiné nesouvisející struktůry - může v tom být do jisté míry podobnost se zásadou, avšak u zásady to není účel. já jej osobně nevyužívám (nevěřím buď jemu, nebo sobě - vysledek je stejný  ). Ovšem pokud je někdo tak dobrý, proč ne...

Přislo mi, že v knize pod slovem "Zásada" se rozumí Traits. Jinak Trait se překládá jako "rys" (traits jsou rysy). Nevím. každý máme jinou terminologii a úplně nejhorší jsou překlady od různých autorů.

Pokud to dobře chápu, pak rys je něco mezi strategií a zásadou. Poskytuje sice šabloně nové rozhraní, ale jeho zaměřením je interní implementace nějaké funkčnosti - tedy tak nějak jsem to pochopil...

Používání vícero rozhraní přibližuje C++ spíš k jazykům s dynamickým typování, což se občas může hodit. Sice se s tím asi nedocílí takové výkonnosti jako u šablon, ale je to jako se vším. Otázka ceny.

No, otázka je zda se s tou cenou počítá i do budoucna. Pokud někdo navrhne skříň do níž dám pouze jede hrnek, nebo myslivce, který může mít jen jednoho psa a finito, pak si nejsem tou cenou až tak jist.... Pokud je kód ještě navíc uzavřený, myslím že to může to být v budoucnu velmi drahá záležitost. A určitě sám ze zkušenností víte, že peníze mohou být v takovém případě ještě pořád to nejmenší. Ale - je to asi jen věc pohledu...   

407

Vývoj / Re: SDL-Sources

« kdy: 10. 12. 2010, 01:04:15 »

Asi ti nerozumím  fce IMG_Load( ) slouží k načtení jednoho konkrétního obrázku (např. ve formátu PNG) do paměti, těžko ji můžeš použít na popisový soubor zdrojů (rc) nebo defacto na balíček (dat).

A co se týče práce se zdroji v SDL zkus se mrknout třeba na toto : http://gpwiki.org/index.php/SDL:Tutorials:Displaying_a_Bitmap_from_a_Custom_Resource_File_using_SDL_RWops

408

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 09. 12. 2010, 11:28:49 »

[Logik] Nemyslím, že by Ondra byl začínající programátor (nevypadá na to ), ale i tak díky.

Faktem je, že myslet na všechny aspekty nějaké třídy je mnohdy opravdu téměř nadlidský úkol a zohlednit je v nějaké konkrétní (nedej bože abstraktní) deklaraci je potom sisifofský úkol. Jenže pokud se nezvládne už samotný počáteční návrh, je potom dodatečná úprava (pouze prostředky jazyka - nikoliv úpravou původní implementace) hotová pohroma 

Proto je kolikrát podle mě asi nejlepší to co navrhuješ - pokud to jde, upravit, otestovat, odladit a poslat patch. V případě DX ti však nezbývá asi jiná možnost, než násilím nabalovat na původní implementaci další a další vrstvy a modlit se aby to někde neškobrtlo

409

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 09. 12. 2010, 11:15:16 »

Teorie pěkná, ale my jsme ve fázi, kdy máme rozhraní IMyslivec (I znamená Interface a má všechny metody abstraktní). Taky asi nešlo o šablony, protože by to mělo být aplikovatelné i na Javu a jiné jazyky :-)

Není to teorie Používá to knihovna Loki (Alexandrescu - doufám, že to jméno píšu správně), a klientské rozhraní zásad IMyslivec<> lze považovat též za určitou abstrakci. Záleží jen na přístupu. nicméně sám jsem zásady už párkrát ke své spokojenosti použil.

Požadavku na portabilitu do jiných jazyků jsem si nevšiml, reaguji jen na diskuzi kolem  tříd které "umějí běžně více rohraní" - která se vyvinula až do tohoto příkladu. Jak vidíte rozhraní založené na zásadách také, a navíc se obejde bez polymorfních tříd (zasady nesmí být virtuální a nesmějí ani takové funkce obsahovat), nepotřebují k tomu žádný z konverzních "cast" operátorů ( oproti dynamic_cast<>( ) má tu výhodu že není omezena jen na přímou linii hierarchie dědičnosti, a oproti reinterpret_cast<>( ) je přenositelný a korektní )     

Takže mám výhradu i k "Traits", protože původní rozhraní Traits nemá a tedy to opět znamená přepsat všechno (i kdyby se tam daly defaultní Traits) ty šipítka se tam psát musí. Možná přes nějakou kombinaci typedefů. Ale jak jsem psal, o to tady nešlo).

"Traits"? Jako zvláštnosti? Žádné nevidím... 
Ano, ale píšu - muselo by se to tak navrhnout od začátku. Chybu celého tohoto příkladu vidím už v počátečním návrhu. S dobrým návrhem by bylo řešitelné, aby k veterinářovy chodily všichni lidé - nejen majitelé psa, ale trochu jinou metodou , samozřejmě bez zásahu do třídy IMyslivec.

Představte si, že by produkťák si namyslel, že chce mimo požití více psů při honu taky možnost střílet z různých zbraní a jejich kontrolu, a k tomu měnit uniformu a před honem ji nechat protáhnout čistírnou. Ano s Vaším řešením to upravit lze a rychle, jenže nedej bože aby se tam zanesla chyba a nedej bože aby se to za rok začalo opravovat znova.   

Běžnou chybou programátorů v C++ je, že se totiž hodně rádi nechávají unést myšlenkami OOP, ale (už jsme se toho jednou dotkly) C++ je typový jazyk - a to je jeho síla....   
 

Řešení se psí směčkou na místo psa ale beru, je to další řešení, nicméně problém se přesouvá z myslivce na psa. Pokud rozrhaní psa má metody štekej a přines kořist, pak u štekej si dokážu představit, že budou štekat všichni psy, ale jak smečka donese kořist to nevím... ale určitě by to nějak šlo.   

och sorry mea culpa. poslední kód měl vypadat takto (i tak se občas projevuje únava ):

Kód: [Vybrat]

  HajnyA->JdiNaLov( hon );
  HajnyB->AktualniPes( 1  );   /// Predpokladam, ze jich ma ve smecce vice nez jednoho :)  
  HajnyB->JdiNaLov( hon );
  HajnyC->JdiNaLov( hon );  

Jinak u zásad jde o to, ze záleží pouze na Vás jak, s jakými psi bude třída IMyslivec operovat ve Vašem kódu. Nabízejí pouze možnost dodat vhodné rozhraní určité třídě a to až při jeho ptřebě. Já tedy vytvořím (navrhnu) Myslivce. Vy jej použijete s multipsem (se vším co s tím souvisí) a třeba Logik jej použije bez psa. Ale myslivec bude vždy myslivec. Veterinář kontroluje psa, ne myslivce, roto taky bude fungovat korektně. Myslivec půjde na hon a pošle tam konkrétního psa - taky ok.  Je to jen a pouze rozhraní - jaké bude a jak jej použijete, je už jen čistě Vaše věc. Rozumíme si?     

410

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 09. 12. 2010, 00:44:46 »

Ondra.novačisko.cz

já si nejdřív dovolím trochu hnidopišství :

Kód: [Vybrat]

class IMyslivec2: public IMyslivec {
  int akt_pes;
public:
   void selectPes( int id = 0 ) { if( ( get_psy( ).size( ) > id ) && (0 >= id ) ) { act_pes = id }; }
   virtual PsiKontejner &getPsy() = 0;
   virtual IPes *getPes() {return getPsy().empty()?0:&getPsy()[ act_pes ];}
};

... nikde v zadání není psáno ni o tom, že myslivec co má víc psů bude používat jen jednoho - pak by taková úprava byla IMHO trochu o zbytečná (ještě tam chybí informace o tom, kolik těch psů vlastně má) :-)

Vaše řešení třídy myslivec není přímo prasácké, určitě je funkční a v mnoha situacích určitě lepší než přepisovat celou knihovnu, ale mě to přijde trochu ... násilné.

Mě kdysi učily, že když mám skříň (myslivce) mohu do ni dát jeden šálek (může mít psa). Pokud ovšem nikde není napsáno, že do této skříně mohu dát jen a pouze jeden šálek (tedy myslivec smí mít pouze jen jednoho psa) musí jit do skříně dát více šálku (každý myslivec může mít psů více). A hlavně nám bylo zdůrazněno, že musíme počítat s tím, že dřív či později bude někdo chtít dát do té skříně šálku hned dva, deset, ... (tedy, myslivec půjde na hon s celou smečkou). Nemluvě o tom, že do skříně mohu dát také talíře, sváteční košile, nebo sbírku angličáků (tedy myslivec může mít kokršpaněly, jezevčíky, ... nebo třeba pudly). Popřípadě od všeho něco. Vyhoví třída myslivec těmto požadavkům? Takže otázku "Koho jsem si to sakra do firmy nasadil?", bych si položil při pohledu na nedodělanou bázovou třídu IMyslivec.

a co to skusit už od začátku třeba takto nějak "

Kód: [Vybrat]

class z_JedenCokl {
  ...
  IPes* get_Pes( );          /// Pes ;-)
};

class z_PsiSmecka {
  ...
  int no( )  { ... }                        /// Pocet ratafaku
  void AktualniPes( int id ) {...}     /// Vyberu si psa ze smecky
  IPes* get_Pes( ) { ... }             /// A budu s nim neco vyvadet 
}


template <typename T> class IMyslivec : public T {
  
 /// Metody rozhrani myslivec
 JdiNaLov( IHonidba *h );
};

Tak to bychom měly Myslivce máme jasně definovaného, a nijak nezasahujem do jeho deklarace a přesto mohu určit s jakymi a kolikati psy bude konkretni myslivec fungovat :

Kód: [Vybrat]

    class z_NoPes { };
    ...

  IMyslivec<zasada_JedenCokl> *HajnyA = new IMyslivec<z_JedenCokl>;
  IMyslivec<z_PsiSmecka> *HajnyB = new IMyslivec<z_PsiSmecka>;
  IMyslivec<z_NoPes> *HajnyC = new IMyslivec<z_NoPes>;
     
  ...
  IHonidba *hon;

 

Tomuto způsobu se říká zásady. A jde v podstatě o to, že vaše šablona myslivec určuje základní rozhraní a chování (řekl bych jakýsi rámec) objektu. Zásady jsou potom malé moduly, vyhovující přesně vaším požadavkům, kterými doplníte možnosti původního objektu. Nejde tu to jak jsou jednotlivé třídy implementovány, ale o jejich rozhraní (proto jsem se ze své vrozené lenosti neobtěžoval dopisovat implementaci metod, zde je opravdu nepodstatná) :

Kód: [Vybrat]

 if( VeterinarniKontrola( HajnyA->get_pes( ) ) != TRUE ) {
  ....
 }
 ...
  for( int i = 0; i != HajnyB->no( ); i++ ) {
    HajnyB->AktualniPes( i );
    if( VeterinarniKontrola( HajnyB->get_Pes( ) ) != TRUE ) {
    /// Neco s tim udelej  
    ...
    }
  }

Výhodou je to, ze programátor primo až při psaní kódu rozhoduje co bude daná třída podporovat, ale myslivec bude vždy myslivec - i presto, ze žádného psa mýt nebude.... Navíc, v zásadách se zásadně nepoužívají virtuální metody, takže nedochází k zbytečnému nafukování výsledného binárního kódu, když změníte zásadu za jinou s jiným rozhraním, sám překladač vás upozorní na změny a nakonec, zásady jsou velice variabilní, takže je lze různě řetězit, nebo kombinovat....

Kód: [Vybrat]

  ...
  HajnyA->JdiNaLov( hon );
  HajnyB->JdiNaLov( hon );
  HajnyC->JdiNaLov( hon );  
 ...

411

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 28. 11. 2010, 21:20:03 »

[jk & blizzboz]

Myslím, že pravdu máte oba. Objety v "realitě" existují - konec konců i člověk sám je objekt... objekt, který vykonává zažité procedůry...   

412

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 28. 11. 2010, 20:51:35 »

[Ivan]

Váš předpoklad při vší úctě nestačí, je lepší to napsat - protože z vašeho příspěvku vyplývá, že procedurální programování je pasé úplně. Jinak asi jste špatně informován, na filtrech je založena velká část unixových a like-unixových systémů. Asi jste nepsal nikdy třeba v GTK, Win32API, nebo SDL, kde se právě docela často mnohem složitější aplikace, s mnohem více ovladacích a aktivních prvků (než formulář s jedním tlačítkem) tvořilo (a dodnes i často tvoří) procedurálně v C.

Ano porovnávat C++ s Javou (a C#) je OFF TOPIC, ale když si přečtete Váš příspěvek, tak je takových OFF TOPIC srovnání PLNÝ.

Java je ve srovnání C/C++ pomalá. IMHO protože automatizovaná správa zdrojů něco stojí (a má další své mouchy - nedá se optimalizovat a občas bývá i nespolehlivá, už se to tu několikrát řešilo), navíc kód který musí být při spuštění dodatečně zpracováván, je IMHO vždycky pomalejší než strojový kód, no a nakonec jsou tu už samotné javovské aplikace, které jsou oproti jiným aplikacím stejného typu a zaměření opravdu pomalejší a navíc jejich odezva na nějakou událost bývá také často viditelně malátnější.

Imho způsob uvolnění z paměti si musíte občas implementovat i v Javě, gc pouze hlídá referece na daný objekt a jakmile žádné nejsou, pak objekt uvolní (jinými slovy, nemusíte např. volat operátor delete - jako v C++). Jednak já osobně to za žádnou výhodu (tak abych to musel používat vždy a v každé aplikaci) nepovažuji a jednak pokud bych o to stál, mám k dispozici v C++ např. inteligentní ukazatele, továrny a pod. No probléma.

Chcete mi tvrdit, že v Javě nemusíte ošetřovat vyjímky? No toto.... Nikde jsem netvrdil, že špagetový kód je přímou vinou Javy. ne jen k tomu spůsob programování v Javě dost svádí - o moc víc než v C/C++, avšak ano je to hlavně chyba programátorů. Jenže, tím se právě spousta zastánců Javy a C# ohání -> prý jedním z cílů jejich existence je psát efektivní kód bez nešvarů jejich předchůdců. A se špagetovým kódem se zápasilo (v trochu jiné formě) už na BASICU ;-) Navíc tento problém javě na výkonosti asi moc nepřidá.

Nakonec, je rozdíl, když kód pracuje na silném stroji jako modul serveru a je rozdíl když pracuje na obyčejném PC jako samostatná aplikace s plným GUI.

Já jsem zkusil jazyků myslím, že docela dost. Některé více a některé méně do hloubky, a nakonec jsem zůstal  u C++. Asi jednak proto, že pro většinu problému, které řeším, mi poskytuje dostatčné nástroje a možnosti ( a pokud mi něco chybí, tak už to někdo implementoval, nebo mi to implementovat umožní - s mnohem menším úsilím, než v jazycích vyšší úrovně), nic za mě nedělá a nic přede mnou neschovává,  a nakonec mi umožnuje samostatně rozhodovat co, kdy a jak se bude dělat. Mohu použít téměř jakýkoliv styl programování. (Je libo typy/objekty, funkce, metaobjekty, nebo něco speciálnějšího... např lispovské seznamy typů?) Je tedy velice flexibilní a výkonný. Ano, má to i své mouchy - a co nemá? Mě však předešlé vlastnosti C++ za to stojí. Toliko k mercedesu v garáži.
   

413

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 27. 11. 2010, 12:10:44 »

[Ivan]

No, jste ukázkový příklad toho co jsem už tu jednou psal - totiž používání děla na komára. Nechápu kde jste přišel na to, že na moderních platformách nemá procedurální programování co dělat. Přijde mi to stejně geniální prohlášení asi jako tvrzení, že dneska jsou klasické vývojové diagramy o ničem, a mají se používat jen strukturogrami. tak jako některé principy a myšlenky mnohem lépe, přehledněji a jednodušeji vyjadřuje vývojový diagram, stejně tak nechápu proč nepoužívat procedurální programování, když to mnohem zjednodušší a zpřehlední konkrétní úlohu.  Přikladem budiž aplikace typu filtr, na něž stačí několik dobře napsaných funkcí. Navíc stejně se procedůrám nevyhnete, protože ve všech třech jayzcích, které jste zmínil (C++, Java, C#) je rozhraní objektů implementováno z velké části procedurálně.

Hlavní ( a z mého pohledu jedinou) výhodu kterou Java oproti C++ má, je její přenositelnost, což by mělo teoreticky znamenat, že jednou aplikaci napíšu a zkompiluji a potom ta stejná aplikace by měla běžet na všech podporovaných platformách. Jejími zásadními problémy je pomalost (virtual machine + gb) a onen "špagety kód", ke kterému tak rádi programátoři v Javě inkliminují (což je dalším argumentem proti kecům typu: "Vytvořily jsme super jazyk xxx, který budete používat, protože jsme v něm odstranily nebo schovaly všechny špatnosti jazyka yyy ". Pravda, s novím jazykem však přišli nové, nebo staronové nešvary). To je takz důvod proč se snažím Javovským aplikacím na desktopu vyhýbat (ono to bohužel v mém případě stoprocentně nejde, ale snad česem lidé trochu zmoudří...)

Kdysi jsem podobnému blábolu propadl taky - někdo někde plácl, že klasická makra nemají v C++ co dělat. Všichni jsme to jak idioti bez přemýšlení papouškovaly po něm. Dneska jsem o něco moudřejší....

414

Software / Re: Nastavení KGet v Opeře a Firefoxu

« kdy: 23. 11. 2010, 01:29:14 »

Něco je tady: https://bbs.archlinux.org/viewtopic.php?id=56340
Že nastavíš otevíraní souboru pomoci KGet, ale Operu nepoužívám, takže nemůžu to vyzkoušet

Díky, ale bohužel to není ono. 

Přidání položky do kontextové nabídky řeší problém jen částečně, jednak proto, že je nutno jej dát pro každý typ objektu zvlášť (Jiná kontextová nabídka pro stažení obrázku, jiná třeba pro link na soubor) a jednak se musí jednat o přímý link (tedy negenerovaný, třeba přes PHP, nbo nějaké CGI a pod, jinak stáhne místo požadovaného souboru ten skript, nebo mi KGet nadá, že adresa není platná...).

Asociace typu souboru mi nefungovala. Zase moc položek, ale to není to nejhorší. Větší problém je, že se soubor nejdřív stáhne pomocí interního download managera a pak teprve spustí pomocí pomocí zadané aplikace - což je v tomto případě pasé.

Já bych potřeboval nějak vyšachovat ze hry interního zprávce stahování v opeře a jeho funkci nahradit KGetem...  Našel jsem k tomu dvě aplikace FlashGet a jakýsi ogot. Jenže obě jsou pro os.Windows a navíc ta druhá je dost zvláštní...    

415

Software / Re: Nastavení KGet v Opeře a Firefoxu

« kdy: 22. 11. 2010, 10:26:34 »

Do Firefoxu se to řešilo přes Flashgot: http://www.abclinuxu.cz/poradna/linux/show/224358

Děkuji, FlashGot funguje s Firefoxem (Iceweaselem) parádně  . Pořád však řeším KGet ještě pro Operu, pokud by jste tedy někdo znal(a) nějaký postup, jak na to, prosím o radu...

 

416

Software / Nastavení KGet v Opeře a Firefoxu

« kdy: 21. 11. 2010, 20:24:52 »

Zdravím,

potřeboval bych nastavit v prohlížečích Opera a Firefox jako download managera KGet místo nativních nástrojů. Je sice možnost použít volbu "otevřít v...", jenže to vždy nefunguje spolehlivě. Nemohu na to za Boha přijít.  Pokud to někdo řešil prosil, bych o radu jak to nastavit. Dopředu díky.

417

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 09. 11. 2010, 22:59:54 »

Neduh číslo 4: špagetový kód
Nadměrné používání objektů a metod způsobuje, že většina metod jen předává své parametry jiným metodám a nedělá vůbec nic. Pro nalezení výkonné části musíte projít třeba deset úrovní. V takovém kódu se nedá vyznat a špatně se ladí.

Nelze než nevzpomenout na tu tolik milovanou Javu....

418

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 08. 11. 2010, 23:56:21 »

Pokud mám mluvit za sebe, řekl bych, že nejsem skalním zastáncem žádného programovacího stylu nebo techniky. Podle mě  IMHO mnohem více záleží na typ úlohy/problému,  který jsem se rozhodl řešit pomocí vlastního programu a na tom co umím, nebo znám. Tahle univerzálnost je jeden z důvodů proč je pro mě C++ no. 1 - mohu v něm v základu volit mezi strukturálním a určitým typem objektového programovaní. A pokud chci tak mi nabízí možnosti jak implementovat / simulovat vlastnosti jiných jazyků (programovacích technik a stylů). Je to sice už mnohdy vyšší dívčí - přiznávám, že bych si na ledacos asi netroufl , ale vím, že to v C++ jde...  V mnohých jiných "čistých" jazycích by to znamenalo mnohem větší problém. 

Když se na různé svaté války (flamewary) za ten jediný správný jazyk, styl, techniku, ... (doplnte si, prosím, patřičný pojem) dívám z tohoto pohledu, neubráním se pobavenému úsměvu a myšlence na to, že "každá liška chválí svůj ocas..."     

419

Distribuce / Re: Debian a rozsypaný apt

« kdy: 08. 11. 2010, 11:05:38 »

Dobře, pochopím to na mašinách v mezinárodním prostředí. Ale proč  by si proboha neměl lokalizaci nastavovat člověk na své mašině (popř. ve firmě kde nehrozí, že dojde k jazykovým kolizím) podle svých potřeb? Konec konců i mě samotnému je příjemné když na mě aplikace mluví rodným jazykem.

420

Distribuce / Re: Debian a rozsypaný apt

« kdy: 07. 11. 2010, 18:07:34 »

... A velmi razatne som ostavil navyk kolegov nastavovat $LANG na de_DE.utf8...

... A zabralo to?