JXP Commander II 0.9.0

18.7.2006 11:06 | Přečteno: 3010× | JXP Commander II

Když poprvé někoho napadlo vytvořit něco jako JXP Commander měl jsem radost, že mohu sledovat vznik nového open-source projektu a co víc - dokonce se do jeho vývoje zapojit. První měsíc vývoje byl překotný - vznikl název, wiki projektu a IRC kanál, ale nikdo se dlouho neměl k tomu, aby napsal jediný řádek kódu.

Velice kladně hodnotím iniciativu Jaroslava Šmída, který se jako první rozhodl něco vytvořit. K mému zklamání se ale rozhodl zkombinovat nezkombinovatelné - C++ a GTK. Knihovna GTK je implementována v C a pracovat s ní v C++ je zbytečně nepřehledné a na objektovosti to programu nepřidá.

Již někdy během tohoto vývoje jsem se rozhodl napsat si vlastní JXP Commander (jenom pro sebe, abych si trochu zopakoval GTK). Je implementován v GTK+ 2.0 a napsán v céčku. Vycházel jsem ze screenshotů Total Commanderu 6 a dal jsem si za cíl "aby to vypadalo stejně" (jen nevím na co je to tlačítko se šipkou dolů ve skupině čtyř tlačítek vpravo nahoře v každém panelu - nemám nainstalované wine a rebootovat se mi nechtělo, tak jsem ho tam nedával) - k tomu příkazovému řádku dole jsem se ještě nedostal. Abych nikoho nemátl, pojmenoval jsem svoje dílo JXP Commander II.

JXP Commander II toho moc neumí - je to jenom GUI. Pouze parsuje /proc/mounts a všechny aktivní přípojné body nahází do combo boxu, který ve Windows slouží k přepínání mezi "disky". Jako výhody spatřuji správné použití Makefile, lokalizovatelnost (stačí v CFLAGS v Makefile změnit -DLANGCZ na -DLANGEN a vše je anglicky).

V open-source je pro uživatele důležitá možnost volby a pro vývojáře konkurence a možnost inspirace. Proto jsem se rozhodl svůj výtvor publikovat. Možná tím někoho inspiruji a vyrojí se nepřeberné množství různých JXP Commanderů, z nichž pouze jeden nejsilnější jedinec přežije přirozený výběr a stane se nejlepším file-managerem.

       

Anketa

Anketa

Komentáře

[David Watzke]

Heh, zkompiloval jsem si to, ale neumí to ještě nic, tak jak si o tom můžu něco myslet?

[mkoubik]

Jde o to, co si myslíš o tom projektu a myšlence plurality, ne o funkčnosti.

[David Watzke]

Aha. No, IMHO byste měli spíš spolupracovat na jednom. Ne?

[mkoubik]

Zaprvé neumím pořádně C++ (nekamenujte mě) a ani se mi nezdá pro GTK vhodné. A zadruhé jsem pro to, aby paralelně existovalo víc projektů. KDE a GNOME jsou tak dobré proto, že se předhánějí v tom, kdo bude lepší (i když každý trochu jiným směrem).

[David Watzke]

Zaprvé neumím pořádně C++ (nekamenujte mě)

Nebudu, já taky ne

A zadruhé jsem pro to, aby paralelně existovalo víc projektů.

Jasně, ale šlo by to rychleji a výsledek by byl lepší. No ale když to každý chcete psát v jiném jazyce, to je pak těžký, to je fakt...

[tezkatlipoka]

myslis ze nazvem JXP Commander II opravdu nikoho nezmates? to si teda opravdu nemyslim.

[mkoubik]

Fajn, diskuze je nato, aby se v ní diskutovalo, jestli někdo navrhne nějaký lepší název, rád to přejmenuju. Samotnému se mi JXP Commander II nelíbí - je to jen pracovní název.

[XMurder]

JXP Reloaded, Total Plesinger, JXP Twin

[Bluebear]

Jee, to jsou báječné názvy

[David Watzke]

Total Plesinger

LOL!

[VícNežNic]

Ten je můj. Ještě se mi líbí Comrade JXP.

[Jáchym Čepický]

hlasuju pro

[mkoubik]

A vítězem se stává ... se ziskem jednoho hlasu ... ... Total Plesinger. Gratulujeme.

[mkoubik]

Total Plešinger mě taky napadl (už to tu kdysi zaznělo), ale je to s diakritikou a se "s" by to nebylo ono. Asi budu uvažovat o JXP Reloaded.

[vogo]

co takhle "fatatl commander"

[Michal Vyskočil]

mkoubik commander, ale to má nevýhodu, že zkratka je mc

[mkoubik]

Že mě to nenapadlo dřív... Chtělo by to vymyslet nějakej název, kterej má zkratku JXP.

[Aleš Kapica]

Jo a ještě si nastav jako alternativu ke zrušení disku příkaz JXD

[vogo]

Eh, podle mě si můžeme vybrat buď: „Liga proti slintajícím monstrům“, či můj oblíbený návrh: „Komise pro Legalizaci Integrace Teroristických Organismů a jejich RehabilitacI ve Společnosti“. Eh, má to jednu nevýhodu - zkratka je „K.L.I.T.O.R.I.S.“.
-- Červený trpaslík - Polymorf

[Bluebear]

Jen houšť, open source vývoj přece je o chaosu

Ale jsi už druhý, kdo začíná práci návrhem GUI, nejsem si jistý, jestli je to dobrý nápad (netvrdím, že je to špatně, jen si prostě nejsem jistý).

[VícNežNic]

Ti co to vzali z druhé strany ještě nemají co prezentovat

[mkoubik]

Když začnu GUI, tak mi připadá, že se to strašně rychle vyvíjí. Tím ve mě vznikne motivace dělat ten zbytek.

[Bluebear]

Aha, tak to ano, to už je otázka vkusu.

Podle sebe jsem soudil tebe - já mám k programování GUI odpor

Nicméně je tu risk, že pokud pak naprogramuješ backend a zjistíš, že se k tomu to GUI nehodí, budeš ho muset předělávat. Jenže se obávám, že totéž platí i naopak, takže mě neber moc vážně.

[Kníže Ignor]

Na tomhle projektu se mi líbí, že si ho můžu zkompilovat v hlavě a nemusím trápit kompilátor ani instalovat knihovny

Dejte mi opici, co umí náhodně ťukat do klávesnice, dost času a slibuji vám, že vytvořím JXP Commander III, který bude dokonalým přenesením Total Commanderu do prostředí linuxu

[mkoubik]

Já budu jedině rád, ale opici si sežeň sám.

[D-Evil]

Flaška vodky by mohla stačit na dobrou opici ne?

[Michal Kubeček]

Neřekl bych, že je problém ve snaze používat Gtk z C++. Problém je IMHO níž: v tom, že je Gtk napsané v C, což je (podle mne) pro grafický toolkit naprosto nevhodný jazyk. Otázkou samozřejmě je, zda by nebylo vůbec nejlepší použít C++ a nějakou C++ nadstavbu nad Gtk.

[mkoubik]

To už bych to rovnou mohl napsat v QT. Problém je v tom, ž QT je zbytečně pomalá knihovna - právě kvůli C++.

[D-Evil]

Pomalá v čem? Z toho, co uživatel na první pohled uvidí, si jasně utvoří stejnej dojem právě o GTK, nikoliv o QT.

[mkoubik]

Také jsem jeden čas dělal v QT. Helloworld je sice na 3 řádky (narozdíl od dvaceti v GTK), ale při spuštění je to objektivně pomalejší </FLAME>

[D-Evil]

No to může mít několik příčin, např. prostředí, kde se to spouští. QT si tahá spoustu knihoven a pokud v paměti nejsou, tak to prostě trvá.

[msk]

Presne tak. Je totalny rozdiel, ked som pod gnome a pustim kde aplikaciu, ako ked som pod kde. V pripade kde uz mam kniznice loadnute a nacacheovane, ale v gnome sa musia vsetky zavislosti natahat do pamati a to chvilu trva. Subjektivne si dovolim tvrdit, ze nevidim ziaden handicap qt voci gtk co sa rychlosti tyka.

[msk]

QT je zbytečně pomalá knihovna - právě kvůli C++

Ktore QT myslis? Pomalost QT aplikacii vacsinou spociva na fakte, ze vyvojari danej aplikacie su prasce a hovada a v QT nevedia programovat ( zazil som jednu komercnu aplikaciu, kde "programatori" "vyvijali" linuxovu aplikaciu na windows, na vsetko pouzivali signaly a sloty a bez akehokolvek usudku boli schopny napisat namiesto metody GetCojaviemNejakyObjekt() totalne obskurdny hnus, ze niekde v konstruktore naconnectili nejaky signal na nejaky slot, v momente, ked normalny clovek zavola GetCojaviemNejakyObjekt() pouzili emit(nejaky_signal) a v nejakom nesuvisiacom slote ten objekt odchytili a cez membera vratili tej metode, ktora si ho vyziadala. Proste hnus.

Takze pisat, ze QT je pomale kvoli C++ je totalna hovadina. Naopak, nedokazem si predstavit, ako niekto dokaze napisat gui v c. To musi byt ultrahnus ( a verte, ze par pokusov s gtk som mal ). Takisto ma totalne dorazili prve pokusy s gstreamer, z toho mi bolo na zvracanie.
Konstrukcie ako
bus = gst_pipeline_get_bus (GST_PIPELINE (pipeline));
gst_element_set_state (pipeline, GST_STATE_PLAYING);
gst_object_unref (GST_OBJECT (pipeline));
su totalne obskurdnosti. Odvtedy mam totalnu averziu voci vsetkym "g-style" knizniciam.

[Luk]

Kvůli C++ to samozřejmě není. Je to tím, že se jednoduché věci dělají složitě, a zrovna to nadužívání signálů-slotů je typickým příkladem.

[msk]

Ale to zavisi na developerovi aplikacie. Ja osobne pouzivam signaly a sloty len tym sposobom, ze si v designeri naklikam, kam sa maju posielat signaly z tlacitok, listov a inych widgetov, zdedim z toho ui vlastnu triedu a dane sloty naimplementujem. Nenapisem tak ani raz rucne ziaden connect() ani emit(). A spomalenie medzi kliknutim na tlacitko a spustenim kodu obstaravajuceho tento klik ma v konecnom dosledku az tolko nezaujima ( nie, ze by to nejak trvalo, ale proste je mi to fuk ). To, ze je niekto prasa a kazdych 10ms emitne nejaky signal, najlepsie z nejakeho random-number generatora, aby ho nasledne odchytilo 100 slotov, ktore zistia, ze signal je len pre jedneho z nich, je jeho problem ( a bohuzial aj end-userov jeho aplikacie ).

[disorder]

Naopak, nedokazem si predstavit, ako niekto dokaze napisat gui v c. To musi byt ultrahnus ( a verte, ze par pokusov s gtk som mal ). Takisto ma totalne dorazili prve pokusy s gstreamer, z toho mi bolo na zvracanie.
Konstrukcie ako
bus = gst_pipeline_get_bus (GST_PIPELINE (pipeline));
gst_element_set_state (pipeline, GST_STATE_PLAYING);
gst_object_unref (GST_OBJECT (pipeline));
su totalne obskurdnosti. Odvtedy mam totalnu averziu voci vsetkym "g-style" knizniciam.

v tom pripade dufam, ze nepouzivas GIMP ani ine Gtk+ programy :P
zalezi len na programatorovi - mne sa taketo programovanie zda prehladnejsie, mam rad kontrolu nad tym co sa deje. a ako bonus mam lepsiu optimalizaciu kodu.

[Kníže Ignor]

Nepochopil jsem, co myslíš tou lepší optimalizací kódu. Jakože překladač kód lépe optimalizuje, když _________ než když _________. Prosím doplnit

[Michal Vyskočil]

Jakože překladač kód (v C++) lépe optimalizuje, když je to icc, nebo msvc než když je to gcc ... co tohle? Vyhrál jsem nějakou cenu?

[Kníže Ignor]

To sice dává smysl, ale otázka byla položena v nějakém kontextu, takže cenu pro vítěze ti bohužel předat nemohu.

[disorder]

Nepochopil jsem, co myslíš tou lepší optimalizací kódu. Jakože překladač kód lépe optimalizuje, když _preklada C kod_ než když _preklada C++ kod (teda vsetku tu abstrakciu OOP) _.

[Kníže Ignor]

No to mi právě není tak úplně jasné. Přece čím vyšší je úroveň abstrakce tím lépe se teoreticky může optimalizovat, ne?

Př.:

X(1:N) = X1(1:N) + X2(1:N)

vs

DO I = 1, N
  X(I) = X1(I) + X2(I)
ENDDO

v prvním případě překladač hned ví, že to může optimalizovat, zatímco ve druhém to musí zkoumat, aby došel k závěru, že výpočet v jednom cyklu neovlivňuje výpočet v cyklu jiném, takže to může vektorizovat

[disorder]

co tak:

b = a + a + a + a

ako ma prekladac vediet, ze to moze byt:

b = 4 * a

alebo dokonca:

b = a << 2

[Kníže Ignor]

že se jako dopředu neví, jaká funkce se pro to sečtení zavolá a zjistí se to až v době běhu programu

už tomu asi rozumim

[Michal Vyskočil]

V tom případě ještě může optimalizaci provádět runtime (nebo virtuální stroj, jak se tomu moderně říká).

[disorder]

ja do tejto problematiky velmi nevidim, ale v kazdom pripade to je spomalenie a na kriticke veci sa to pouzit neda.
a tiez neviem ci by to ta virtualna masina dokazala, pretoze by musela kompletne chapat objekt a vsetky vztahy aby mohla operacie na nom dokonale optimalizovat (a este je tu ta rezia...)

[wake]

tohle je jednoduchy. na zjednodusovani aritm. vyrazu zabere cca. 500 radek v Prologu. proc by tohle v sobe nemohl mit komplikator, nevim.

[Kníže Ignor]

až na to, že to vůbec nemusí být aritmetický výraz můžou to být nějaký drsný třídy s přetíženym operátorem +

[Michal Kubeček]

Ale to snad není žádný problém. Když je to POD, kompilátor ví, jaké vlastnosti ty operátory mají, a podle toho může optimalizovat. Když je to třída, tak nemůže předpokládat nic. Jenže to by samozřejmě nemohl ani v případě, že bych operátory neoverloadoval a psal to jako Plus(a,a), takže pořád nevidím, v čem C++ brání optimalizaci. Naopak, mohlo by jí pomoci, pokud by jazyk umožňoval specifikovat hint typu "tenhle operátor je komutativní", ale to bychom asi chtěli moc…

[Kníže Ignor]

Já jsem ten disorderův příklad pochopil tak, že Plus(a, b) klidně může být realizováno jako a.add(b) a že pak to a + a + a + a na 4 * a redukovat nejde, protože v okamžiku překladu nevím, co dělá to add. Když je to POD tak tam samozřejmě žádná překážka není.

Chtěl jsem to v této diskuzi hlavně pochopit, protože C++ skoro neznám.

[Michal Kubeček]

Komplikátor? Tak to jsem nikdy nepotřeboval, většinou bych spíš potřeboval opačný nástroj. :-)

[VícNežNic]

Komplikátor je v mém případě název funkce té osoby, co obsluhuje kompilátor.

[Michal Vyskočil]

Překladatelé, zbystřete pozornost. Konečně hezké české slovo na příšerné anglické obsfucator. Komplikátor doporučuje 4 z 5 obrozenců

[Ctirad Feřtr]

To už bych to rovnou mohl napsat v QT. Problém je v tom, ž QT je zbytečně pomalá knihovna - právě kvůli C++.

Prosím neFUDovat. QT je velmi rychlá knihovna, troufnul bych si dokonce říct, že rychlejší než GTK1.

Jako člověk, co dělá s hudebními programy to vidím denně. Tyto programy mají narozdíl od různých gimpů, email klientů a www browserů obrazovku posetou mraky pohyblivých elementů, skákají tam různé VU metry a posouvají se slidery. Je na tom krásně vidět, jak který toolkit tyto věci (ne)stíhá. Třeba takový ardour 0.9x (GTK1) jede na mém stroji dost dobře. Připravovaný ardour2 (pouze přepsání pro GTK2) už je skoro nepoužitelný, jak mu GUI "plave". A to není zatížením CPU, které je velmi malé. Ostatní GTK aplikace jakbysmet. Když pak vedle toho pustím třeba hydrogen (QT apikace - počet i design pohyblivých elementů je srovnatelný s ardourem), tak ten vyloženě "frčí". To samé se dá říct o srovnání dalších obdobných aplikací. A opravdu se mi nezdá, že je to tím, že by autoři aplikací nad GTK neuměli programovat a ti od QT jo.

[VícNežNic]

Na Gnomefiles furt vidím nějaký Squeak-GTK, musím se na to konečně podívat, jestli to opravdu bude tak praštěný jak si myslím Jestli jo, bude to super

[Josef Kufner]

Návrh a implementace jsou dvě věci, které spolu nemusí vůbec souviset. Teda až na to, že jedno je výsledkem druhého (občas).

[Michal Vyskočil]

No, dělat návrh v C je teda pěkná prasárna . C je skvělý jazyk, ale na prototypování ani omylem (možná snad ještě prototypování aplikací v assembleru).

[mkoubik]

Linuxové jádro by se taky nejlíp psalo v C++ nebo ruby, ale z technických důvodů to není nejvhodnější.

[Michal Vyskočil]

Skutečně? To bys to měl autorům unununia (strašný název) říct .

Hint: nemluvil jsem o tom, v čem by se to psalo líp, ale v čem by se lépe psal prototyp, což je to, co teď děláš.

[mkoubik]

class Process {
  uint pid;
  char *name;
  ...
};

class Filesystem {
  ...

LOL

[msk]

Jej, aky pekny a lahko citatelny kod.

[Kyosuke]

http://www.cse.ogi.edu/~hallgren/House/kernel/pfe.cgi?H.VirtualMemory http://www.cse.ogi.edu/~hallgren/House/kernel/pfe.cgi?H.PhysicalMemory http://www.cse.ogi.edu/~hallgren/House/kernel/pfe.cgi?H.Monad#tH

[Michal Vyskočil]

No, když jinak nedáš, tak IO kit XNU (jádro OS X) je v embeded C++. Navíc je v něm tuším Symbian

[Marek Bernát]

Hmm, Symbian je síce v C++, ale má dorobených kopec vecí navyše, ako vlastné exceptiony, garbage collection a všetko je to spravené cez makrá, takže výsledný jazyk sa na C++ podobá len vzdialene. IMO, C je na operačné systémy oveľa lepší jazyk, lebo má čistejší dizajn. S C++ je to také rozpačité. Keby som si mal na písanie kernelu vybrať jazyk z rodiny C a nesmelo by to byť C, tak by to bolo D

[mkoubik]

Mě to D přijde jako kompilované PHP

[Marek Bernát]

PHP je nehorázny humus, nevhodné na nič iné, ako pár riadkové skripty. Má nelogický design, je nekonzistentné, etc, etc.

D mi naopak pripadalo ako Java/C# tak ako som si ich predstavoval pôvodne, pretože ma oba dosť sklamali.

Kto programoval v C++ je schopný okamžite začať s D a byť plne produktívny. Sám som bol prekvapený, z toho, ako rýchlo som si naňho zvykol. Navyše sú v ňom už napísané veľmi pekné a obsiahle programy (to na porovnanie s tým PHP, kde už z definície pekný program napísať nejde). Ak prihodím, že nie je problém pribindovať ľubovoľnú knižnicu z C, tak myslím môžeme túto debatu rovno uzavrieť. Je to proste lahoda, robiť v tom jazyku. Ja teda mám radšej iné jazyky ako algoloidné, ale keď to musí byť, tak D.

Aby som to zhrnul, nevidel som v živote nič tak nepodobné PHP ako D.

[Michal Kubeček]

Aby som to zhrnul, nevidel som v živote nič tak nepodobné PHP ako D.

No, o tom bych si dovolil pochybovat. Sice D vůbec neznám, ale pokud je aspoň trochu podobné C, tak by se určitě něco našlo… :-)

[disorder]

akurat som chcel za kandidata navrhnut brainfuck :))

[Michal Kubeček]

Mne napadly Prolog, Forth, Lisp a PL/1… :-)

[Kyosuke]

Forth? Je to rozumné, psát v operačním systému operační systém?

[Michal Kubeček]

Já jsem netvrdil, že se v tom má psát operační systém, to mi nepřišijete. Uváděl jsem ho jako příklad jazyka, který se (pravděpodobně) od D liší víc než D od PHP.

[Marek Bernát]

Jedna nula pre vás

Predsa len som nemyslel na to, že oveľa nepodobnejšie PHP ako D je napríklad steblo trávy, alebo mločie žalúdky. Nabudúce budem opatrnejší

[Miloslav Ponkrác]

D mi přijde tak, že splnili jeden můj sen, a to jest odstranili nutnost psaní hlavičkových souborů. Špatný není ani pořádek ve strigách, kde se C++ moc nevyznamenalo. Standard C++ dodnes neumí klasický Unicode string stylu ucs4, ale D ano. Líbí se mi funkcionální prvky v tom jazyce, ale jinak bych D asi nepřijal. Rozhodně mě nezaujalo vyhozením vícenásobné dědičnosti, kterou považuji za výhodnou. Úplné vyhození preprocesoru mě taky nenadchlo. Řešení assertů pomocí výjimek nepovažuji za správné řešení.

Navíc D nemá moc kompilátorů pro různé platformy, ač obsahuje dobré nápady.

[Marek Bernát]

Asi tak nejak. Ale je to mladý jazyk, čo sa týka popularity a stále sa vyvíja a myslím, že má tendenciu kvalitné veci preberať do štandardu. Takisto kompilátory časom zrejme pribudnú. Alebo možno upadne do zabudnutia, uvidíme.

[Miloslav Ponkrác]

Symbian nemohl být napsán jinak, vezměte si datum standardu C++ a datum vzniku Symbianu. Už je to jasné? Jinak Symbian naprosto využívá C++ tak jak vypadalo v době vzniku Symbianu, vím to velmi dobře, neboť v C++ dělám od doby jeho vzniku a jeho bolestný vývoj před standardem jsem prožil. Mnohé dodělané věci do Symbianu by se dnes dodělávat nemusely.

C++ je na operační systém mnohem lepší jazyk. C++ má mnohem čistější design, co se týká programů. Je mi divné právě ve světle jazyka D, který doporučujete. Já kdybych psal operační systém, tak neváhám a C++ je jasná volba. Nevidím ani jeden důvod, proč sáhnout po čistém C kromě jednoho, a to že bych neměl k dispozici kompilátor C++. Při psaní v C++ máte obrovskou volbu, kdy můžete balancovat od prakticky čistého C kódu s lepšími kontrolami kompilátoru přes "C with classes" až po vysokoúrovňový kód využívající vymožeností C++ na maximum.

[Marek Bernát]

Tak prepáčte, ale že C++ má poriadnu garbage collection som skutočne netušil. Môžete mi k tomu povedať viac?

C++ má oveľa nečistejší design ako C. Možno sa nezhodneme, ale ja súhlasím s jedným múdrym pánom, ktorý povedal, že existujú len dva skutočne čisté designy jazyka a to sú C a LISP. Všetko ostatné je niečo medzi tým. S postupom času jazyky lispovatejú, taký python a ruby sa od lispu v podstate odlišujú už len neprítomnosťou makier. Takže aby som sa vrátil k C++, je to nástroj hlavne mierený na zvýšenie výkonu a kontroly a teda krok od C k LISPu, ale zároveň zachováva spätnú kompatibilitu. Skutočne vám toto pripadá ako čistý design?

K tomu môjmu D: D má z môjho pohľadu oveľa jednoduchšiu filozofiu a to je vidieť aj na niekoľkonásobne menšej špecifikácii jazyka. Je to proste jazyk pre ľudí, ktorá chcú efektivitu, produktivitu, stabilitu a tú aj prináša. Znie to síce ako reklama, ale stačí si to vyskúšať. Radosť z programovania v D sa blíži skoro radosti programovania v pythone, alebo v LISPe a to sa rozhodne o C++ nedá povedať. Nebol to náhodou ESR, kto povedal niečo ako ``UNIX is popular, because it is fun'' ?. Symbian mi teda rozhodne zábavny nepripadal, skôr to bol des a hrôza oproti UNIXu. <random_thought>že by to bolo kvôli C++, hmm?</random_thought>

[elviin]

Pekny clanek k pojednani o (redundanci) GC v C++ je zde (A Garbage Collector for C++) nebo zde (finally Revisited). Oba clanky jsou docela aktualni.

[Marek Bernát]

Neviem už celkom presne, aký problém bol s tým Symbianom, že, či to bolo kvôli vtedajším štandardom, alebo, že deštruktory neboli celkom thread safe, ale proste ho tam implementovali. A rovnako aj vlastné new, kvôli výnimkám pri vytváraní objektov. Určite je to zaujímavá problematika, ale viac o tom, obávam sa, neviem.

[Miloslav Ponkrác]

Symbian musel být perfektně rychlý, naprosto paměťově nenáročný a musel bez chyby běžet třeba celé roky. Tehdejší implementace výjimek byly děsně rozežrané, trvalo pár let, než tvůrci kompilátorů přišli na to, jak výjimky udělat dobře.

Jinak žádný automatický garbage collector v Symbianu neexistuje. Existují jen prostředky pro uklízení paměti, které ovšem funguj poloautomaticky. Programátor takový objekt musí zaregistrovat a pak dojde k automatickému úklidu při výjimce, nebo chybě.

Symbian nepoužívá výjimky, tudíž ani nemohl spoléhat na automatické volání destruktorů při výjimkách, proto si zavedl "cleanup stack", tedy to co se tu někdo snaží vydávat za garbage collector.

[Miloslav Ponkrác]

C++ nemá v základě žádnou gc, ale má jiné prostředky na uklízení paměti. Kromě toho gc můžete přilinkovat jako knihovnu.

Ohledně čistoty designu diskutovat nebudu. Můj poznatek je, že je-li prioritou čistý design = několikanásobný čas vývoje. Já sakra nechci strávit x hodin navíc s jazykem, který mi nabídne pouze pochybou výhodu čistého designu, přesněji řečeno, že ho kdosi možná za čistý design považuje.

C++ není zaměřený na zpětnou kompatibilitu, tu dostal jaksi navíc. C++ byl zaměřený na to, aby dokázal efektivitu vývoje Simuly skloubit s rychlostí C. C++ dokonce ani není zpětně s C kompatibilní a vyjmenuji Vám kupu příkladů, které v C přeložíte a v C++ nikoli. Cílem C++ určitě nebyl čistý design, cílem C++ je, když to trochu nadneseně řeknu je být absolutně nejrychlejším jazykem kompilovaným do strojového kódu a mající maximum konstrukcí pro efektivitu vývoje. Sice se to trochu překombinovalo, ale výsledek tu je.

Mě osobně programování v C++ přijde jako zábava. Programování v Pythonu taktéž. Ale požadavek na programování v C beru jako z nouze ctnost. A z programování v LISPu rozhodně radost nemám. To je ale věcí názoru.

Jazyk D je dobře navržen, ale trpí tím, že je minoritní, že neexistuje překladač na spoustu platforem, že není podporován, atd..

Všimněte si, že se ujaly jazyky, které řešily nějaký praktický problém. Jazyk C řešil programování jádra Unixu. Jazyk C++ řešil simulaci telefonní sítě. Python řešil vědecké programování. Co řeší D? Může být sebelepší, ale kde je nějaká referenční killer aplikace?

Děsím se jazyků, které jsou až moc čisté. S takovými jsou v praxi moc problémy a zjistíte, že často obcházíte jejich čistotu, abyste mohli udělat jenoduchou věc. Trochu nečistoty v jazyce beru jako skvělou devízu. A to mi věřte, že kdysi jsem měl na čistotu stejný názor jako Vy.

[Marek Bernát]

Mojím poznatkom zasa je, že ak je skutočne čistý design, ala LISP, Python, tak doba vývoja je niekoľkonásobne kratšia. Za čistý design nepovažujem Javu, Sun sa ju síce snaži marketingovať ako všetko možné, ale je to len další z nekonzistentných jazykov plných balastu.

To že sa dá gc prilinkovať ako knihovna nebudem riešiť. Ak si myslíte, že garbage collector sa dá poriadne spraviť mimo jadra jazyka, tak je to vaša vec. Iná vec je, že C++ garbage collector nepotrebuje, ale to je už skôr osobná filozofia. Ja zastávam názor, že overhead dobre spraveného garbage collectoru priamo v jazyku je minimálný, ale prináša to ohromný užitok vo veľkej minimalizácii memory leakov. A tie robí každý, nech je wizard v C++, aký chce.

Samozrejme, jazyk D je minoritný, neviem, čo by som k tomu dodal. Snád len, že Java je majoritná. Stači kus marketingu, silnú spoločnosť a z jazyku je hit raz dva.

Súhlasím s vami, že jazyky nezískavajú popularitu ľahko a dnes sa svet z hlboko vyšliapaných koľají len tak nevytrhne, ale to nie je dôvod zostávať pri horších variantoch. Ja osobne zažívám isté uspokojenie, ked idem svojou vlastnou cestou a postavím sa na odpor tej masovej organizovanosti C++/Java/PHP, ktorá v súčasnosti vládne svetu.

S posledným paragrafom opäť nemôžem súhlasiť. Vy asi nechápete, čo je to čistota designu. To znamená, že všetko sa dá spraviť jednoducho a intuitívne. Python je toho nádherným dôkazom a takisto LISP, aj ked v inom zmysle. Samozrejme, v pythone by som asi nepísal kernel, nie je to jazyk určený na niečo také, ale inak s ním viete spraviť všetko. V LISPe by sa kernel napísať dal, kedže je natívne kompilovaný; napríklad Common Lisp je rýchly skoro ako C, niekedy rýchlejší. Ale nechcem rozoberať takéto témy, od toho tu máme Linusa a Tanenbauma.

Back to design jazyka: ak design nie je čistý, tak celé dni premýšľate, ako sa robí to, ako ono a ktorý spôsob je lepší. Toto neplatí, len ak ste expert s 10 rokmi skúseností v jazyku, ale takých ľudí je minimum. Poznáte napríklad niekoho, kto dokonale ovláda STL a celý template systém? Ja nie. Ovládam základy celkom slušne, ale aj tak sa stále morím s príručkami, ked musím robiť vlastný template, alebo použiť niečo neštandartné, lebo ten systém je dokonca je pre pokročilých používateľov šialene komplikovaný.

Možno to tu vyzerá, že si odporujem, ani D nemá čistý design, kopec vecí sa dá robiť viacero spôsobmi, ale aj tak je intuitívny. Nie je ľahké povedať, ktorý jazyk je čistý, ale ak zoberieme PHP ako jeden extrém a python ako druhý, tak sa s tým dá niečo robiť.

Ja by som to ale nechal tak. Nechcem sa škriepiť. Každému, čo jeho je. Ak máte C++ rád a ste produktívny, tak nie je o čom.

[Michal Kubeček]

Stači kus marketingu, silnú spoločnosť a z jazyku je hit raz dva.

Zrovna u Javy bych tomu "raz dva" neříkal. Tam bylo potřeba několik let intenzivního plošného brainwashingu…

[Marek Bernát]

Stačilo pár rokov. To je v živote jazyka "raz dva". C# síce nastúpil rýchlejšie, ale dovolím si tvrdiť, že to bolo kvôli tomu, že je kópiou Javy a teda Sun spravil Microsoftu veľmi dorbú službu v tom, že naučil "programátorov" na taký typ jazyka. Myslím, že iný prípad takého masového presadenia jazyka ako Java už nie je.

[Michal Kubeček]

To asi ne, ale je otázka, zda by se našel (kromě zmíněného C#) jazyk se srovnatelně intenzivní propagační kampaní.

[Marek Bernát]

Máte pravdu. Uviedol som Javu ako príklad, ale v skutočnosti je jediná svojho druhu. Ostatné jazyky sa väčšinou ujali kvôli tomu, že niečo riešili. Fortran - simulácie, LISP - AI, etc... PHP - odporné stránky -- aby som si rýpol

Ale o vzniku C++ som počul len v súvislosti s plánovaným vylepšením C ako takého, podobne ako D je vylepšenie C++. Ale neviem. Nič z toho som nezažil. A vlastne je mi to jedno. Ja už som sa vyprofiloval ako nealgolista, to mi stačí

[Miloslav Ponkrác]

My co jsme řešili simulaci jsme měli k dispozici skvělý OOP jazyk Simula. Ten samý jazyk používal pan Stroustrup a měl řešit simulaci telefonní sítě. Ale Simula byla tak pomalá, že se rozhodnul napsat vlastní jazyk a tak vzniklo C++. Takže i C++ řešil, nevylepšoval C.

[Michal Kubeček]

Také jsem vždycky měl větší úctu k těm nástrojům, které se prosadily proto, že dokázaly samy přesvědčit určitou skupinu uživatelů, že jsou tím, co potřebují. Ať už to bylo C, PHP nebo třeba Delphi (i když třeba Delphi osobně nijak moc v lásce nemám). K nástrojům, které byly prosazeny tím, že někdo lidem tak dlouho tlačil do hlavy, že jsou tím, na co svět už od vynálezu kola napjatě čekal a co vyřeší všechny jeho problémy od hladomoru po globální oteplování, dokud nerezignovali a nepřestali odporovat, mám apriorní nedůvěru…

[Miloslav Ponkrác]

Základem prosazení se jazyka je mí dobrou grafickou knihovnu a umožnit rychlé a jednoduché vizuální vytváření grafických aplikací.

Proto taky C# nastoupil mnohem rychleji, protože Microsoft tohle umožnil. Java má problémy s grafickou po řadu let a ani dnes to není tak snadné a intuitivní jako to udělal Microsoft. To si myslím, že hodně stálo za prosazením.

Až bude mít jazyk D slušnou grafickou knihovnu a slušné grafické vizuální prostředí, bude mít stokrát větší šanci se prosadit. Dneska to bez toho nejde.

[Marek Bernát]

Hmm, má dobré bindingy na opengl a SDL. Neviem, čo presne chcete, ale ja som bol schopný za pár chvíľ robiť s grafikou to, čo v C++. Loadovanie Cčkovských libiek, sočiek a dlliek je jedna z najväčších výhod D. Proste ten jazyk je možno minoritný, ale čaká len na to, aby si ho niekto všimol

[Miloslav Ponkrác]

Takže databázová aplikace je v pohodě, každej bude databáze bastlit v GL. Ten jazyk nemá prakticky šanci, protože není pro něj žádné IDE, není pro něj nativní grafický návrhář, nejsou dokonce nativní wrappery do nějaké slušné grafické knihovny. Kromě toho není to přenositelné, existuje jediný rozumný kompilátor a právě se zrovna založil projekt na front end do GCC.

Možnosti jazyka D hladce překoná třeba Python, nebo jiný interpretovaný jazyk. Určitě je D lepší, než C++, ale vývoj kompilovaných jazyků je už za zenitem. To by musel jazyk D udělat toto:

1) Vytvořit killer aplikaci(e), které by nastartovaly zájem o D 2) Vytvořit slušné IDE pro tento jazyk 3) Zvolit dobrou grafickou knihovnu a vytvořit kvalitní wrapper do D 4) Vytvořit grafického návrháře pro toto grafické rozhraní 5) Vytvořit nástroj, který by automaticky generoval wrappery pro D z C/C++ 6) Automaticky připravit wrappery pro několik stovek základních knihoven 7) Vytvořit standard jazyka D, rozšířit jeho možnosti pro datové struktury 8) A prosazovat, prosazovat, prosazovat.

[Marek Bernát]

Som zmätený z vaších rečí o grafickej knihovne. Pre mňa je to openGL (open Graphical Library) a to má v D dostatočnú podporu. Máte na mysli snáď grafické toolkity GTK/Qt ? GTK má bindingy snáď v každom existujúcom jazyku a D nie je výnimkou.

Čo sa týka IDE, tak ja osobne ich neznášam a mám na ne takýto názor: čím horší jazyk, tým väčšmi potrebuje IDE. Totiž, ak sa niečo nedá spraviť rozumne ľahko v jazyku, treba IDE. Extrémom budiž BEA weblogic, ktorá generuje ozrutné množstvá nechutne pomalého kódu na vytvorenie aj tej najjednoduchšej javovskej web aplikácie. Rovnaký efekt je obvykle možné dosiahnuť pomocou pár riadkov pythonovského kódu napísaného v milom, peknom editore, napríklad vim.

Viem o tom, že veľa ľudí bez IDE asi nedokáže žiť, ale to je podľa mňa rovnaký zlozvyk ako to, že nevedia žiť bez Javy.

Ja neviem, čo stále máte s tými wrappermi, pozrite sa na stránky D a uvidíte, že prakticky každá rozumná C knižnica je v D prístupná. Navyše D má nástroje na generáciu wrapperov priamo z API hlavičkových súborov C knižníc a stačí to už potom len doladiť. Proste, čo sa týka dostupnosti knižníc, tak je na tom skoro tak dobre ako C. Bodka.

Súhlasím s vami, že toto všetko nestačí na masové presadenie. Ale napokon, kto o také niečo stojí. Java je masovo presadená, používa ju snáď polovica veľkých firiem, ale to nič nemení na fakte, že s ňou nechcem mať nič spoločné. Samozrejme, že sú tu otázky ohľadom zamestnania a využitia minoritného jazyka, ale aj minoritné jazyky majú svoje uplatnenie. Web servery sídlia u vás doma, takže vás nemusí zaujímať, aký jazyk použijete, je dôležité len to, aby bol efektívny. Samozrejme, v dnešnej dobe nikto nič nevie, ľudia doštudujú školu, podajú si inzerát a všade od nich chcú Javu, tak sa ju naučia a tak to ide stále ďalej. Je to začarovaný kruh. Ale ja nebudem jeho súčasťou, ďakujem pekne.

[Miloslav Ponkrác]

Pro mě je základní grafická knihovna ta, která umí formuláře, dialogy, atd.. Nestačí binding do D, ale musí to být wrapper, který přirozeně zapadá do jazyka D.

Bez IDE se programovat dá, ale 99% lidí se Vám na to vykašle. Já jsem v C/C++/Pythonu/Javě a dalších jazycích začal programovat bez IDE. Pak jsem zjistil, že Microsoft Visual C/C++ je bezvadné IDE, které mi velmi ulehčí práci a tak jsem ho začal používat. V Pythonu jsem začal psát ve vimu, ale časem jsem přešel na SPE. Pro Javu jsem bohužel použitelné prostředí nenašel. Eclipse mě nezaujalo, prostředí Eclipse mi přišlo nic moc a NetBeans zkouším, ale pokaždé mi přijde, že to prostředí mi v Javě moc nepomáhá, spíše naopak.

IDE je bezvadná věc, protože proč by mi IDE nevygenerovalo makefile, proč bych nemohl debugovat přes IDE namísto gdb, proč nenavrhnout formuláře grafickým návrhářem, atd.. Dnes prostě bez IDE nechci dělat. Jde to, ale nevidím v tom výhodu. Snad jen to, že 90% IDE je špatných a nepoužitelných na práci.

Dostuponost knihoven z C je hezká věc, ale pak je to nanic. Krása jazyka, jako třeba D je v tom, že bude mít wrappery, které umožní přístup ve stylu toho jazyka. Takže mít třeba GTK a používat jí ve stylu jazyka C ztrácí smysl. Má to být zabalené do tříd, templates a datových struktur obvyklých v jazyce D a to je trochu víc, než pouhý binding z C. Podívejte se na C++ jak to vypadá, když nemá spoustu věcí přístupných jinak, než v C stylu.

Bohužel masovost Vás zajímá. Pokud chcete používat exotický jazyk a chcete třeba redakční systém, tak buď strávíte měsíc jeho programováním v exotickém jazyce, a nebo hodinu instalováním hotového redakčního systému v PHP, kde si můžete vybrat ze stovek hotových projektů. Bohužel je to tak. Proto každý jazyk musí najít prostor, killer aplikaci.

Jazyk, který nemá IDE, dobrou grafickou knihovnu na formuláře, dialogy, databáze atd.. s grafickým vizuálním návrhářem to má dnes těžké. Pokud by mi jazyk D něco přinesl do praxe, nevidím problém k němu přispět, ale já nevidím jedinou věc, kde by mi mohl posloužit snad kromě toho, že se mi v mnoha ohledech líbí víc, než C++. To je právě problém mnoha jazyků a technologií, které se mi líbí, a ke kterým bych i rád přispěl svým vývojem, ale musel bych najít záminku, kde je použít a kde pomocí nich vydělat.

[Marek Bernát]

To je asi zásadný rozdiel medzi nami, ja nehľadím na to, ako zarobiť a nesnažím sa za všetkým hľadať peniaze, stačí mi radosť a to, že veci sú pekné.

Ale zrejme je to len vekom. O pár rokov, na tom možno budem rovnako ako vy. Ale vo svojom záujme dúfam, že nie. Ono vôbec, toto je téma na dlho. V podstate sa to už dotýka free software, resp. peniaze verzus sloboda a krása. Tieto sa síce nevylučujú teoreticky, ale prakticky zväčša áno. Ale nie o tom som chcel. Proste som len chcel povedať, že D je vcelku pekný jazyk. V tom sa zhodneme a tým by som to rád uzavrel.

[Michal Kubeček]

To je asi zásadný rozdiel medzi nami, ja nehľadím na to, ako zarobiť

Jen počkejte, až si vezmete hypotéku… :-)

[Kyosuke]

Kdybych nepsal pěkné odborné překlady, neměl bych ji ani z čeho platit...

[Miloslav Ponkrác]

Python rozhodně čistý design není a právě proto je tak efektivní. S názorem na čistotu designu Javy jsme si blízko.

gc má jednu obrovskou, ale obrovskou nevýhodu. Pokud není udělán jako reference counting, pak sice dokáže efektivně zacházet s pamětí, ale už ne s dalšími prostředky systému (handly apod..) a stejně dochází k tomu, že se o to stará programátor. navíc s většími problémy, než v C++. volání úklidové funkce nic neřeší, protože se nemusí nikdy zavolat, a nebo třeba až za měsíc poté co paměť není potřeba. a mezitím je zbytečně blokováno mnoho prostředků systému. C++ má prostředky, které se starají o tohle všechno. vyberte si.

ten marketink u jazyků pracuje ať chcete, nebo ne. já jsem studoval řízení systémů a viděl jsem spoustu věcí, které bych rád používal. namísto toho se ujaly jiné, které jsou mnohem horší.

čistota designu je věc, která se liší názor od názoru. třeba C si s jednoduchostí a intuitivností opravdu nedokážu představit. jinak pokud mi někdo řekne, že cokoli je rychlejší, než C (kromě asm), vím, že se mýlí.

nemusíte využívat 100% jakéhokoli jazyka. ostatně kdo to dělá? nevidím tak velký problém ve zvládnutí STL, neboť je to poměrně logické. templaty jsou v C++ složité, ale řídí se jednoduchými pravidly. složité to není pochopit, ale aplikovat, protože přiznejme si, že template je sama o sobě abstraktní věc, totiž možnost generovat algoritmy podle předem připravených schémat. to už se pohybujete trochu ve výšinách.

co se týká jazyka D, nechci se prostě věnovat něčemu, co nikdo nepoužívá. může se mi to stokrát líbít, může mi připadat lepší, než jiné jazyky, ale schází mi důvod proč si s tím jazykem pohrát.

koukejte, já jsem proti tomu, aby lidi používali jazyky, které se jim nelíbí. nenutím nikomu C++, ale ať prostě ten někdo jasně řekne, nechci použít C++, a ne aby hledal falešné důvody, proč je ten jazyk špatný. vrcholem pokrytectví je zdůvodnění Linuse, proč nepoužít C++ pro operační systém, který je plný lží. já neříkám, že D je špatný jazyk, je vynikající, ale používat ho nebudu. stejně tak se mi líbí LISP svým pojetím, ale neumím ho využít v praxi. líbí se mi Python a horečně hledám, kde ho využít, protože se mi zdá jako použitelný jazyk. to je celé.

jsem rád za diskusi s Vámi. prostě se mi líbí, že řeknete takhle to cítím a nemáte potřebu všechno smést. je radost s Vámi diskutovat.

[disorder]

pisat v ASM uz nie je rychlejsie - prekladac to vie optimalizovat lepsie a da sa aj zvolit cielovy procesor...

[Miloslav Ponkrác]

špičkový assemblerista napíše rychlejší a lepší kód. ovšem 99,99% lidí znalých asm nejsou špičkovými assembleristy

[disorder]

nie nenapise. musel by dokonale poznat procesor - jediny procesor, viac by sa mu uz urcite plietlo. musel by dokonale poznat ako sa konkretny procesor sprava, detailne poznat spracovanie instrukcii na konkretnom type procesoru - rozdelit medzi pipeline a podobne srandy. vysledok nula bodov.

[Miloslav Ponkrác]

budete se divit, ale i takoví machři jsou kdyby nebyli, tak by ani kompilátory neměl kdo napsat nedělejte ale z toho zase takovou složitost, a taky si uvědomte, že pravověrný a špičkový assemblerista je na pomezí geniality a bláznovství takový člověk zvládne dokonale řadu procesorů

[Marek Bernát]

Heh, čo bolo prvé, assemblerista, alebo kompilátor?

[Kyosuke]

Případně „takový člověk zvládne dokonale navrhnout řadu procesorů“...

[disorder]

kompilator sa napise podla dokumentacie pre konkretny procesor. aj rozdiely i686, pentium4, k7 etc etc - kto by si trufol optimalizovat z hlavy? tam su naozaj rozdiely podla roznej postupnosti instrukcii, ktore pipeline sa kedy pouziju a rozne detaily. na x86 to procesory dnes vykonavaju v mikrokode, cize by musel vediet presnu postupnost toho co procesor spravi - a moznost napisat jednu vec roznymi sposobmi vytvara tolko moznosti. takze neverim na takych geniov o ktorych tu pisete, ani blazon by sa o to nepokusal - nieto pre radu roznych procesorov...

[Kyosuke]

„takze neverim na takych geniov o ktorych tu pisete, ani blazon by sa o to nepokusal - nieto pre radu roznych procesorov“

Jeden zcela blbý příklad:

http://www.swox.com/gmp/

a29k
alpha
 - ev5
 - ev6
 - ev67
arm
clipper
cray
 - cfp
 - ieee
generic (Cčko)
i960
ia64
m68k
 - mc68020
m88k
 - mc88110
mips32
mips64
ns32k
pa32
 - hppa1_0
 - hppa2_0
pa64
power
powerpc32
 - 750
 - vmx
powerpc64
 - mode32
 - mode64
 - vmx
pyr
s390
sh
 - sh2
sparc32
 - v8
 - v9
sparc64
thumb
vax
x86
 - fat
 - i486
 - k6
 - k7
 - p6
 - pentium
 - pentium4
x86_64
z8000
z8000x

To je seznam adresářů s machine-dependent soubory, povětšinou asm, zčásti C.

[disorder]

to je very cool, ale naozaj ich vie z pamati alebo hodiny sedel nad tym s dokumentaciou?

[Kyosuke]

To dělala hromada lidí spoustu let, aby vytáhla ze železa maximum, a to je hlavní důvod používání assembleru dneska.

Dokážu si ovšem živě představit i opravdové assemblerovské machry...napadá mě jeden zajímavý CAD software napsaný přímo do RAM hexeditorem paměti pomocí sedmitlačítkové klávesnice a později tímto způsobem naportovaný na několik platforem.

[disorder]

ja netvrdim, ze sa assembler nepouziva. ale nikto ti na povel nenapise nejaky zlozitejsi program optimalizovany pre zadany procesor z hlavy. toto uz nie su 386ky

[Kyosuke]

Opravil bych „nikdo“ na „jen hrstka lidí“... Samozřejmě, není to ideální způsob psaní čehokoli většího, to by bylo šílenství.

AMD má ale moc pěknou optimalizační příručku, doporučuju aspoň nahlédnout. Je dobré vědět, že pokud je výkon prioritou (masivní numerické výpočty? ), jsou k dispozici i takové prostředky.

[disorder]

ale pre kolko procesorov? jeden? a uplne vsetko realtime z pamati? o tom hovorim, nie podla prirucky a kusky kodu, ale normalne programovanie.

[Kyosuke]

Ehm, ehm...špičkový assemblerista si procesor, který mu vyhovuje, navrhne sám... (Tahle 500MHz resp 500MIPSová věc byla jako prototyp vyrobená technologií, kterou se vyráběl Intel 80486 DX2 a Pentium 60/66 MHz. Do the math... )

V případě slušných (!) architektur CPU podle mě _je_ možné a reálné psát výkonný kód ručně. Samozřejmě můžeme polemizovat o tom, jak moc je x86 vhodná platforma pro ruční psaní v assembleru nebo třeba i pro psaní kompilátoru, to je ale podle mě trošku jiný problém. (Steel Bank Common Lisp má z nutnosti (chabé registry) dvě verze prováděcího modelu: Jednu pro x86 a jednu pro slušné procesory.)

[Marek Bernát]

Podobne, ja som rád za diskusiu s vami. Vlastne s väčšinou vecí, ktoré hovoríte v podstate súhlasím, niekedy argumentujem len tak zo zábavy, aby som videl, čo ten druhý povie. Je to možno druh schízy, ale je dobré byť otvorený novým názorom

Takže sa vyjadrím už len k pár veciam, s ktorými celkom nesúhlasím.

S tým STLkom nejde o tú abstrakciu. To je vynikajúca vec a najvyššia kvalita ktorú programátor môže mať. A najlepšie sa uplatní v LISPe, kde vám makra dávajú možnosť oveľa väčšej abstrakcie, akú si vôbec viete predstaviť. Apropos, ak si nájdete čas: LISP v praktickom využití.

V STLku je problém, že každá kravina sa robí neúnosne zložito. A to IMO priamy dôsledok toho, že sa s tým nepočítalo a bolo to do pluspluska dorobené nasilu. Dá sa povedať, že je to elegantné riešenie v tom zmysle, že nič lepšie sa zrejme nedá v C++ na danú tému už spraviť. Podobne stringy s stringstreamy. Konvertovať s STL string do intu je síce elegantné a dá sa na to zvyknúť, ale predsa len je to oveľa viac kódu, ako by som chcel. Suma sumárum, STL nemá expresívnu silu. Nedá sa jednoducho povedať: chcem toto a toto krátkym a prehľadným kódom. Na druhej strane na obranu C++ sa dá povedať, že nie je veľa rovnako výkonných jazykov, ktorý zvládajú taký stupeň abstrakcie.

A k tomu pythonu. Tuším, som sa sám zamotal, takže sa opravím. Python nie je jazyk, ktorý má najčistejší design, tým je LISP. Myslím, že ako jediný je axiomatizovaný a formálne skúmaný (s výnimkou funkcionálnych jazykov). V praxi sú síce dialekty podstatne odlišné od tej čistoty, aby sa dali ľahšie používať, ale ten feeling tam je. Python možno nemá čistý design, ale má jasnú KISS filozofiu a teda v podstate design. Preto som sa zamotal. Ale rozhodne je to jeden z mála jazykov, kde môžete byť efektívny behom pár dní a učiť sa za pochodu. To sa mi okrem pythonu stalo len pri D. Ale idem si ľahnúť a utriasť myšlienky, lebo tuším už plácam len dve na tri

Ešte raz, bolo mi potešením. Dobrú noc.

[elviin]

V STLku je problém, že každá kravina sa robí neúnosne zložito.
No to nesouhlasim ani za mak. Naopak template tridy dovolujou rozdelit problem na podproblemy (politiky, traity), aniz by tam byla rezie navic. A pak se soustredite jen na jednu cast - podproblem. V STL je sila v tom, ze oddelite algoritmy od dat a jako interface slouzi kontejnery. Staci to pochopit a pak se celej koncept(sablon) v stl opakuje. Ale co se tady budu vypisovat, prectete si Alexandreska a mozna zmenite nazor.

Konvertovať s STL string do intu je síce elegantné a dá sa na to zvyknúť
Konverze mezi cisly a stringy je narocnejsi, ale v pristim standardu je proposal na konverzni funkce. Viz boost::lexical_cast Pak muzete spachat neco jako tohle:

template<typename T>
inline T convertToFrom( const std::string& fromString ) {
  T toT;
  std::istringstream tmStream(fromString);
  char c;
  if( !(tmStream >> toT) || tmStream.get(c))
    throw std::out_of_range( "convertToFrom is std::out_of_range." );
  return toT;
}

Suma sumárum, STL nemá expresívnu silu.
Dalsi podle mne unahleny nazor. Jestli povazujete STL za kompozici rozsiritelnych nastroju postavenych na zaklade sablon(a tak to je!), pak se podivejte na parser boost::spirit. Pouzivam jej a je to po urcite dobe pouzivani velmi intuitivni nastroj vyuzivajici sablony do takove urovne, ze prekladac jde do kolen, jak pise autor. Ale funguje to, je to rychly, intuitivni a spolehlivy.

[Marek Bernát]

Nemôžem a nebudem s vami súhlasiť, že STL je expresívne. To je v podstate pointa celej vašej reakcie. Rovnaké veci sa dajú vo vyšších jazykoch spraviť ďaleko jednoduchšie a čistejšie, vrátene abstrakcií a všetkého okolo. S čím súhlasím, a už som to povedal, je fakt, že pomer expresívnosť/výkon je v STL zrejme najvyšší možný zo všetkých jazykov. Alebo inak, STL trpím len preto, že je dostatočne rýchle.

Ak mi neveríte, skúste si python a jeho kontajnery a abstrakciu a vráťte sa k STLku.

[elviin]

Ja jsem pouze chtel vyvratit to, co jste napsal. Porovnavat Python a C++ je _mimo_ misu, protoze ty jazyky jsou v podstate komplementarni. Mne nejde o obhajobu C++ jako super-jazyka, ale o obhajobu pristupu, ktery je s ohledem na moje potreby (rychlost, rozsiritelnost, efektivita) dobrym kompromisem a tim STL je.

[Marek Bernát]

Opať nesúhlasím Porovnávať jazyky je celkom možné. Až na pár oblastí, kde treba veľký výkon je python použiteľný prakticky všade a teda v týchto ostatných oblastiach sú porovnateľné. A čo je dôležité (resp., malo by byť) zrejme pre každého programátora je prehľadnosť kódu a rýchlosť vývoja. A práve tu môžeme porovnať o koľko je jednoduchšie napísať v podstate hocičo v pythone, ako v C++. Ergo jazyky sú porovnateľné. Opak tvrdí len zaslepenec, ktorý nevidí za hranice svojho jazyka.

Teda ešte raz podstata, ak stratila. Nemám nič proti C++, v istých situáciách je to veľmi dobrá voľba. Ale nemusíte ho obhajovať len kvôli tomu, že ste naňho zvyknutý.

[Miloslav Ponkrác]

S čím souhlasím je, že jsem čekal od standardu C++, že zahrnou do jazyka větší podporu datových struktur, tedy něco co třeba byť zatím jen náznakově dělá jazyk D. To je totiž přesně to, co dělá Python a je to skvělá věc. Když jsem si četl poslední návrh standardu C++0x, byl jsem smutný a pochopil jsem, že jsou tam jen nepodstatné debility, že to tak musím říci. Podle mě v C++ právě chybí abstrakce na úrovni datových struktur, aby existoval literál typu pole, seznam, asiciativní pole. Tedy přidat do jazyka právě tyhle věci, což by obrovsky pozvedlo C++ a přitom by to téměř nic implementačně nestálo.

Dále mi chybí v C++ klíčové slovo finally pro výjimky.

V C++ mi dále chybí standardní a přenositelná podpora pro celočíselné typy pevné délky. Podle mě naprosto základní věc pro umožnění přenositelnosti, a takový standard C99 už takové typy má.

V C++ mi chybí spousta základních objektových knihoven, například třídy pro práci s datumem a časem, podpora threadů, atomických operací.

Dále jsem od nového standardu C++ čekal, že přestanou blbnout a honit nanosekundy a učiní základní knihovnu trochu flexibilnější. Pokud se pokusíte rozšířit třeba funkčnost streamů poděděním, zjistíte, že máte smůlu, protože neexistuje ani virtuální destruktor, ani virtuální metody, které by měly být logicky virtuální. Vše ve jménu ušetření několika taktů.

Stejně tak STL by měla býy trochu blbuvzdornější. Měla by házet výjimky při překročení mezí pole, při pokusu o přístupu přes neplatný iterátor a další kontroly.

Bohužel C++ asi zůstane takové jaké je. Nedá se od standardizační komise očekávat, že posune jazyk použitelnějším směrem.

Já mám C++ hrozně rád, ale nevidím jeho perspektivu. Ale pořád je to zatím jeden z nejlepších jazyků, pokud chci rychlost a kompilaci do strojového kódu.

[msk]

V C++ mi dále chybí standardní a přenositelná podpora pro celočíselné typy pevné délky

Asi celkom nechapem tuto vetu, ale co Vam konkretne chyba na uint32_t, int64_t a tak podobne?

[Michal Kubeček]

Že nejsou součástí standardu C++. To znamená, že vývojové prostředí nemusí nabízet hlavičkový soubor, který by je definoval. V Linuxu tento problém sice nepocítíte, ale píšete-li multiplatformní C++ aplikaci, nemůžete se na dostupnost těchto typů spolehnout. To je rozdíl proti C, kde každý překladač kompatibilní s C99 musí vybrané typy podporovat, includujete-li příslušný hlavičkový soubor. Mimochodem, zrovna uint32_t ani int64_t povinné nejsou ani podle C99…

[Sinuhet]

Podle mě v C++ právě chybí abstrakce na úrovni datových struktur, aby existoval literál typu pole, seznam, asiciativní pole.

Co presne mate na mysli? Navrhuje se umoznit podobne veci:

std::vector<int> vec = { 1, 2, 10, 16 };

Dále mi chybí v C++ klíčové slovo finally pro výjimky.

Mame RAII.

Pokud se pokusíte rozšířit třeba funkčnost streamů poděděním, zjistíte, že máte smůlu, protože neexistuje ani virtuální destruktor, ani virtuální metody, které by měly být logicky virtuální. Vše ve jménu ušetření několika taktů.

Ze navrh i/o v c++ neni z nejstastnejsich, se vi uz davno. Ale kvuli zpetne kompatibilite zmeny v teto oblasti muzete cekat jen velmi tezko.

[Miloslav Ponkrác]

A co tohle:

void f (const std::vector<int>& x);

f( {1,2,3,4} );

Nebo tohle:

{1,2,3,4}.begin();

RAII je sice hezký koncept, ale finally by se hodilo. Někdy je prostě balení věcí do zbytečných tříd jen zbytečná byrokracie tam, kde by to přehledně vyřešilo finally. Nehledě na to, že RAII v podstatě stejně vnitřně nedělá nic jiného, než finally.

Jinak nechápu, jak by použití slova virtual před některé metody porušilo zpětnou kompatibilitu.

[Miloslav Ponkrác]

Symbian zábavný není, protože až příliš moc věcí, které jsou dnes ve standardu C++ řeší jejich nepoužíváním a obtěžuje s tím programátora. Symbian taky až příliš nadužívá OOP. Tedy obrovská spousta tříd.

Symbian je systém pro mobilní zařízení, Unix nikoli. Ano, Unix lze ohnout, ale nikdy nebude tak přizpůsoben na mobilní věci jako Symbian, stejně tak jako khnutý Symbian nikdy nebude tak dobrý na servery jako Unix.

Jinak cílem většiny programů není být zábavným, ale být užitečným. To je takový drobný rozdíl.

Symbian je bezvadně dělán do prostředí s omezenými možnostmi a je schopen běžet i na zařízeních, kde Unix nic moc. A rozhodně C++ umožnilo Symbianu být tam kde je, protože si fakt nedokážu představit tu zábavu se Symbianem postavených na C API, a ne na třídách. To by byla desetkrát větší otrava, než to je a Vy byste nadával na Symbian mnohem víc.

[Marek Bernát]

Samozrejme, Symbian je stavaný od základu na minimálnu spotrebu baterky, etc, takže sa nedá ľahko porovnávať s UNIXom, ale aj tak mám z UNIXu rozhodne oveľa lepší pocit.

S tým, či by som nadával aj tak, to rozhodne netuším, alternatívne prítomnosti som nikdy neskúmal. Ale viem, že linux v C sa mi páči veľmi, takže skôr by som sa priklonil k tomu, že by som nenadával.

A nakoniec, ja som Symbian vyriešil tak, že už je k dispozícii celkom slušný port pythonu aspoň na väčšinu nokií, takže som mohol nechať Symbian a C++ Symbianom a C++om a za chvíľu spraviť aplikáciu, ktorú bolo treba v pythone, heh. Toľko k môjím skúsenostiam so symbianom

[Miloslav Ponkrác]

A jak byste to řešil před deseti lety? Představte si to tak, řekněme 8 MHz procesor, paměť nula nula nic. A takových Vašich aplikací by tam mělo běžet několik. Vaše řešení je dobré, ale dnes.

[Michal Vyskočil]

No, on Unix vznikal na ještě slabším HW, ale trochu nám od té doby nabobtnal, to je pravda

[elviin]

Myslim, ze jadro MAc OS X je postavny v C++. Kdyz chci vyvijet ovladac, tak podedim od tridy k tomu urcene. A je to asi dobra volba, kdyz to funguje.

[disorder]

no, ono Mac OS X mal vselijake problemy s vykonom (ale to sa tyka toho, ze to je hybridne jadro) a samotne jadro nie je v C++, je to "I/O Kit" v Embedded C++ (s obmedzeniami).

http://www.kernelthread.com/mac/osx/arch_xnu.html

[Josef Kufner]

Ano, dělat návrh v C je opravdu prasárna. Ale navrhnout něco objektově třeba na papíře a pak to implementovat v C, je celkem dobrá cesta.

[Luk]

Dá se to dokonce i napsat v C++ a pak přeportovat do C

[Michal Vyskočil]

je Gtk napsané v C, což je (podle mne) pro grafický toolkit naprosto nevhodný jazyk.

Tobě se nelíbí void*?

[Michal Kubeček]

Což o to, void* sám o sobě není špatná věc. Problém ale je, když ho někdo zneužívá jako berličku k čuňárnám. Hlavně když pak takový kód mám přeložit pomocí čtyřkového GCC, které si hned tak něco nenechá líbit…

BTW, nedávno jsem dokonce objevil v hlavičkových souborech jádra použití pointerové aritmetiky s void*. Potíž je, že zatímco gcc to spolkne, g++ pochopitelně prská…

[Martin]

Proč si myslíte, že je C pro grafický toolkit nevhodné? Neptám se proto, že bych se chtěl hádat a flamovat, jen mě to zajímá. GTK je sice napsané v C, ale (jak jsem si přečetl) bylo přece navrženo objektově. Mně se tenhle přistup dost líbí. Ale možná je to tím, že neumím C++ a tak mi unikají nějaké skryté poklady ;o)

[Michal Kubeček]

To je právě to, co se mi na tom nelíbí. Ten kód je nepřirozený, opravdu vypadá, jako by ho někdo napsal v C++ a pak ho nějakým automatem konvertoval do C. Spousta energie se věnuje řešení problémů, které by v C++ neexistovaly, protože by je automaticky vyřešil sám jazyk (magické přetypovávání, rukodělně simulovaný polymorfismus nebo dokonce RTTI).

Na druhou stranu je samozřejmě stejně nešťastné, pokud někdo sice formálně píše v C++, ale hlava mu stejně dál myslí v C.

[disorder]

nie, ziadne skryte poklady. OOP nie je vseliek. tak nejak podvedome som si to vzdy o C++ myslel, ale teraz mozem odkazovat na toto :)

[Martin]

Hmmmm, zase The Art Of Unix Programming. Na tu knihu už se dlouho chystám, ale moc se mi to nechce číst z monitoru. Buď si to nechám vytisknout a nebo si to koupím. Jo, druhá možnost bude nejlepší :o)

[disorder]

je to vazne dobra kniha, cital som ju z monitoru :) ale autor precenuje rychlost dnesnych pocitacov (dnesnych, a este viac tych z doby vydania) a presadzuje interpretovane jazyky az prilis horlivo. inac super :)

[Miloslav Ponkrác]

OOP rozhodně není všelék, ale vysvětlujte to Javistům, že. Jinak tu knížku jsem četl a ne zcela s ní souhlasím. Možná nemám autoritu a možná ani zkušenosti abych si to mohl dovolit, ale nemyslím si, že autor má 100% pravdu. Ale na takových 95% se s ním shodnu.

V čem mě autor potěšil je, že konečně někdo potvrdil teze o faktické nepoužitelnosti Perlu na cokoli nad pár řádek. Že někdo konečně je schopen napsat, že heslo "unix má být složen z malých jednoúčelových programů" má své výjimky.

S čím s autorem nesouhlasím je až přílišné odmítání OOP, ač souhlasím, že OOP není všelék. Také nesouhlasím s jeho odmítáním threadů, ač upozorňuje správně na jejich úskalí. A také se mi nelíbí jeho názor na C++, který dost odmítá, protože se C++ snaží napasovat do stejné role jako jazyk C, to jest "do role tenké spojovací vrstvy", což samozřejmě C++ není a ani nikdy nechtělo být.

[disorder]

upozornuje na uskalia C++/OOP (a nemyslim, ze nejak prehnane) a zaroven tvrdi, ze je najlepsie poznat viacere jazyky a vediet vzdy vybrat ten spravny...

[Miloslav Ponkrác]

Já si naopak myslím, že upozorňuje jednostranně. Dost jsem z toho cítil, že jazyk, ke kterému nesedne a nepíše, ale který vyžaduje nějaký framework, nebo delší přípravu prostě sepsuje jak malého psa. Řekl bych, že čím větší projekt, tím méně je autor v obraze se svými názory.

Jeho hlavní kritika C++ byla, že je to složitý jazyk, a že ho hackeři nepřijali plus citace posměšného citátu o C++. Dále pak už jen dost blábolí. Ano, jazyk C++ je složitý a co mi je do názoru hackerů?

O OOP se vyjadřuje s tím, že OOP prý údajně není vhodná na nic jiného, než grafické objekty plus pár dalších věcí. Evidentně autor nikdy nepsal větší projekty, kde se musely značné části kódu a rozhraní sdílet v týmu a kde vůbec přístupová práva, zapouzdření a také vlastně i existence speciálního prostoru jmen udělá tak dobrou službu, že už jen tohle stačí k tomu, aby OOP bylo prohlášeno za skvělou věc.

O threadech zase upozorňuje na jejich úskalí, ale končí to totálním zavržením threadů. Dost jednostranné.

Ale ač to vypadá, že je proti autorovi, jinak s většinou souhlasím. Je to chytrý člověk.

[disorder]

asi tento citat:

“If you know what you're doing, three layers is enough; if you don't, even seventeen levels won't help”

je to skor upozornenie, ze pokial nevie programator co robi, tak mu C++ nepomoze. ostatne o tom tam pisal, tento citat to len anekdoticky zhrnuje.

a autor je celkovo proti velkym monolitickym projektom (ved je to kniha o UNIX programming), takze kritika v tejto oblasti nie je prekvapujuca. ale ja som si zapamatal skor, ze treba vediet zvolit spravny jazyk, nez ze OOP je vsade zle okrem tych troch oblasti...

aj to, ze thready viac-menej zavrhuje sa dalo ocakavat - zase UNIX programming. ale ak by niekto potreboval nasadit thready, tak by sa urcite nespoliehal len na nazor z jednej knihy.

ja som z knihou tiez nesuhlasil uplne vo vsetkom, ale vacsina je IMO spravna a vedel som si to utriedit a urcite bola pre mna prinosom. a rad odkazujem tu cast o OOP, pretoze niektori zaciatocnici (dufam, ze len zaciatocnici) si aj dnes myslia, ze C++ je pupok sveta.

[Miloslav Ponkrác]

dobře vědět co děláte je určitě správná idea, ale příliš obecná

autor je proti velkým monolitickým projektům, ale svoji bezradnost nad emacsem ani neskrývá.

já chci vidět začátečníky, co dobře ovládají C++ ))

jinak C++ je spíš otloukánek, do kterého si každý kopne, než pupek světa

pokud se týká OOP a začátečníci, kteří mají pocit, že jsou pupek světa, obrátil bych se rozhodně na Javisty

kniha není správná, kniha je prostě jedním pohledem na problematiku, která v jiných případech a v jiných situacích nemusí platit. zejména si myslím, že platí pro malé a rychle programované věci.

OOP určitě není samospasitelné, ale stylem jakým je podáno v této knize každého znalého člověka jenom přesvědčíte, že je to trochu zaujaté. řekl bych, že právě ta pasáž o OOP patří k těm nejslabším v té knize (ovšem tvrdě vede pasáž o threadech a hned následuje OOP a pak C++, kde na názoru hackerů postavil celé hodnocení)

Jinak ale musím ocenit, že se hodně zamyslel a třeba pasáž, co je špatně v unixové koncepci a co se mělo udělat jinak je moc dobrá.

[disorder]

ja myslim, ze uviedol dost faktov a pre cloveka, pre ktoreho je nieco z tych kritizovanych veci aktualne, ma urcite ine zdroje a vlastne skusenosti a vie ake ma poziadavky. takze poukazat na neostatky je dobre, venovat sa kazdemu do detailov by knihu pokazilo.

viac sa mi pozdava modularny pristup (ano, ten unixovy) a tato kniha vyjadrila vela veci, co som citil a myslijm ze su spravne. ale viac to dokaze ocenit clovek, ktory ma rad C.

ja napr. emacs mam rad, aj ked jeho implementacia ma od mojej filozofie dost daleko :)

ked to niekto berie vsetko doslova a veri tomu, nieco nie je v poriadku s nim a nie s knihou. nic nie je ciernobiele, ze :)

[Miloslav Ponkrác]

kniha je skvělá.

jen prostě hrozí, že z ní někdo bude citovat s poukazem na autora.

modulární přístup je naprostá nutnost

[Michal Vyskočil]

Už si to nepamatuji doslova, ale OOP bylo kritizováno především pro tendece takových programátorů tvořit košaté hierarchie objektů se složitými vazbami, které v konečném důsledku vedou k tomu, že se je programátor musí naučit, pokud je chce používat (což je podle mě naprostá pitomost, OOP by mělo zjednodušovat a zakrývat co nejvíce detailů).

Mě se na tom nejvíce líbil fakt, že si ta kniha na nic nehrála. Řekla, ano, malé programy, které lze spojovat jsou skvělá věc, ale ne na všechno. Prostě ať zvolíte jakýkoliv přístup, nebo filozofii, není to univerzální řešení pro vše. A fakt, že unix stojí a padá s tím, jak se mu daří absorbovat nové trendy. V tom duchu byla celá (až na ty thready, C++ a OOP).

[Miloslav Ponkrác]

Myslím, že OOP je dobrá věc, ale jako každá technologie je jenom prostředkem. POkud se OOP stane cílem, je to tak jak říkáte.

Ta kniha je vynikající, rozhodně vysoký nadprůměr.

[Michal Kubeček]

Prostě dobrý sluha ale špatný pán. Jako většina užitečných nástrojů… :-)

[msk]

Moj osobny pocit je taky, ze kazdy widget, kazde tlacitko, cokolvek je na obrazovke ako objekt. Pristup C++ umoznuje do tohoto objektu zabalit jeho vlastnosti, metody ( cize funkcie, prikazy ) a tak podobne. Pride mi totiz prirodzenejsi tento pristup ( vyuzijem trosku zjednoduseny priklad pomocou QT ):

PES pes ( "rexo" ) {
 signals:
  brese_ako_hovado();
};

SUSED honza ( "pekny curak" ) {
 slots:
  rozsviet_svetlo_a_pozri_co_sa_deje();
};

ZLODEJ klepto ( "ma uz cosi za sebou" );
DOM dom ( "moje kralovstvo" );

connect ( pes, signal ( brese_ako_hovado ), honza, slot ( rozsviet_svetlo_a_pozri_co_sa_deje ) );

pes.straz ( dom );

Toto je sice exemplarny priklad zneuzivania slotoveho mechanizmu v qt, ale ako priklad postaci ( tymto prikladom som ale nechcel poukazat na system signal/slot v qt, ale skor na objektovost jazyka ). Psovi kazem strazit dom. Ak pride zlodej k domu, pes zacne stekat a sused rozsvieti svetlo aby sa pozrel, co sa deje.

V semi-objektovom C by to vyzeralo asi nejak takto:

main () {
 PES* pes = vytvor_novy_objekt_typu ( "PES" );
 nastav_popisok ( pes, "rexo" );

 SUSED* sused = vytvor_novy_objekt_typu ( "SUSED" );
 nastav_popisok ( sused, "pekny curak" );

 DOM* dom = vytvor_novy_objekt_typu ( "DOM" );
 nastav_popisok ( dom, "moje kralovstvo" );

 ZLODEJ* klepto= vytvor_novy_objekt_typu ( "ZLODEJ" );
 nastav_popisok ( klepto, "ma uz cosi za sebou" );

 // tymto cyklom nahradzam signal/slot mechanizmus
 // on sice v reale asi aj tak nejak funguje, ale ja sa o to v QT nemusim starat
 bool flag = true;
 while ( flag == true ) {
  if ( pes_brese ( pes ) == 1 ) {
   pes_brese_akcia ( pes, sused );
   flag = false;
  }
 }

 zrus_objekt_co_si_vytvoril ( pes );
 zrus_objekt_co_si_vytvoril ( sused );
 zrus_objekt_co_si_vytvoril ( dom );
 zrus_objekt_co_si_vytvoril ( klepto );

}

void pes_brese_akcia (PES* pes, SUSED* sused) {
 SVETLO* svetlo = daj_mi_pointer_na_svetlo_niekde_na_susedovom_dome ( cislo_svetla );
 rozsviet_svetlo ( sused, svetlo );
}

Na prvy pohlad to mozno pride ako zmatocne, ale ked sa k tomu prida polymorf, dedicnost, ine vlastnosti oo jazyka, zlozitejsi projekt, zo standardnym C by sa clovek posral nieco poriadne napisat, nehovoriac o nachylnosti k chybam a tak podobne. Objektovy jazyk totiz svojim navrhom viac pripomina realny zivot a tak sa v nom aj programuje.

PS. Snad som nepopisal nejake kraviny.

[Martin]

Ano, v případě, že někdo C++ ovládá, může to být jednodušší. Ale jelikož já se C++ teprve učím, tak kdybych se zároveň při učení pustil do nečeho většího v GTK, tak by z toho nejspíš vyšel hnusnej bastl :o) Tím neříkám, že jsem expert na C, jenom že ho umím lépe než C++.

Tvoje argumenty chápu a celkem jim i dávám za pravdu. S OOP jsem se poprvé setkal poměrně před nedávnem v Pythonu a __velice__ jsem si ho oblíbil (OOP, Python mám rád už dlouho). Jenže mám takový dojem, že mezi zvládnutím OOP v Pythonu a zvládnutím OOP v C++ je diametrální rozdíl. Proto se zkrátka zatím přikláním spíš k čistému C. Minimálně do doby, než to C++ alespoň trošku zvládnu.

[msk]

Python je super, akurat mi vzdy dlhsiu dobu trva zvyknut si na odlisnu syntax a formatovanie, ktore je sucastou synaxe. Co sa tyka C versus C++, pokial pochopis principy OOP ( je jedno ci v c++ alebo v pythone ci smalltalku alebo jave ), nebudes mat vacsi problem si zvyknut na akykolvek oo jazyk. Casto sa stretavam s nazorom, ze ucit sa C a potom C++ je strata casu a C znacne zkomplikuje vyuku C++. Z osobnych skusenosti potvrdzujem, ze nieco na tom bude ( samozrejme je potrebne sa naucit prvky, ktore c++ z c prebera, ale zbytocne si na c nezvykat ). Samozrejme ze pretlacat oo jazyk tam, kde nie je potrebny, je totalna blbost. Pokial niekomu staci proceduralny jazyk na dosiahnutie svojho ciela, nic proti. Ale ak sa raz projekt rozrastie, zacne nabalovat nove a nove veci, zacnu sa pod rukami menit zauzivane funkcie a zvyklosti, zakladne stavebne kamene projektu, tam dostava c++ vyhodu svojou objektovostou a moznostami, ktore by sa v c implementovat dali, ale zaberaly by privela cenneho programatorskeho casu bez vplyvu na vykon a s obrovskym vplyvom na stabilitu a citatelnost kodu. To ale pochopis casom sam, ked sa do toho ponoris. Ja som sa napriklad v c++ zo zaciatku takmer nestretol s dedicnostou, az kym som nezacal pouzivat qt. Tam som bol donuteny sa ju naucit a v mnoho chvilach som za nu vdacny.

[msk]

Ozaj a este dodam, ze mam problem so "zvladnutim oo v pythone". Mozno je to mojim c++ myslenim, mozno odlisnou syntaxou, ale v pythone objekty sice vytvaram, ale nedokazem s nimi robit ziadne zazraky :o)

[Michal Kubeček]

Osobně si myslím, že pro zvládnutí C++ je dobré umět i C, nemluvě o tom, že opravdu rozumět fungování unixových systémů bez aspoň základní znalosti C IMHO dost dobře nejde. Problém je jen v tom, aby člověk nepodlehl nabízející se představě, že C++ je jakési "céčko s objekty", ale vnímal od začátku C++ jako samostatný jazyk, který sice logicky vychází z C a přebírá z něj řadu myšlenek, ale v mnoha ohledech je jeho filosofile velmi odlišná. Pak podle mne člověku znalost C není na překážku, ale může naopak pomoci.

[Michal Vyskočil]

Možná šlo o směr, kterým má učení probíhat. Zda nejprve C a potom C++, nebo obráceně. Bohužel standardní knihovna C++ má "relikvie" z dob C. Například inputStream.open(const char*);. Ovšem s řetězci je také sranda, mimo C polí a std::string v C++ má navíc snad každá C++ knihovna starší sedmi let stringy vlastní.

[Michal Kubeček]

Zdá se, že nejsme jediní, komu se to používání const char* moc nelíbí, viz C++0x wishlist (hned třetí požadavek). Ale to samozřejmě bude ještě nějaký ten rok trvat. Co se týká vlastních stringů v každé knihovně, to bohužel není problém jen C++ knihoven, to dělají i céčkové. Obzvlášť příjemné je to ve chvíli, kdy je potřeba v projektu takových knihoven použít víc, to člověk pomalu nedělá nic jiného, než že castuje jedotlivé xchary a xstringy mezi sebou, což ohromně zvyšuje čitelnost zdrojáku… :-(

[Luboš Doležel (Doli)]

Zrovna u otevírání streamů mi připadá std::string trochu zbytečný, pokud si vezmu, že mám konstantní řetězec, std::string alokuje novou paměť, zkopíruje tam můj řetězec a ta funkce open s tím std::string-em dál pravděpodobně pracuje stále jako by byl konstantní.

[Miloslav Ponkrác]

tady nejde o to, co je efektivní, tady jde prostě o konzistenci interface. C++ je hodně zmršeno kvůli šetření nanosekund. já kdybych měl možnost upravit standard C++, tak první zavedu virtuální destruktory do všech streamů a polovina metod ve streamech dostane slovíčko virtual.

[Michal Kubeček]

Pochybuji, že by mělo dojít k nahrazení C-stringů std::stringy, spíš se prostě přidá sada metod, kde bude místo const char* jako argument const std::string&.

[Michal Vyskočil]

Přesně, vždyť C++ má přetěžování metod . Navíc, pokud mi std::string vrací nějaká jiná metoda jako výstup, tak se zbytečnou konverzí na const char* paměťové nároky naopak zvyšují.

[Luk]

tak se zbytečnou konverzí na const char* paměťové nároky naopak zvyšují

Minimálně v GNU implementaci ne. Protože zavolání c_str() pouze poskytuje ukazatel na vnitřní reprezentaci, nikde se nic nealokuje.

[freshmouse]

Čím více JXP commanderů bude, tím lépe, pokud z toho někdo bude mít radost nebo užitek.

Nicméně, moc nechápu tu sháňku po dvoupanelovém správci souborů. V GTK máme Tux CMD, Gnome CMD a další, v Qt máme Krusader a další. V příkazové řádce používáme Midnight CMD. Pro Windows máme Total CMD...

I když dvoupanelové souborové manažery moc nepoužívám, a tak nemohu posoudit kvalitu výše zmíněných, myslím si, že jich je docela dost a není třeba vytvářet další (ALE viz první odstavec).

[disorder]

bohuzial ziaden neprekona Midnight Commander, tak ako (IMO) FAR neprekona wincmd na windows.

[balda]

nemuzete sem davat aspon screenshoty at se muzem podivat jak moc je to total commanderu podobne? Kompilovat se mi to nechce...

[freshmouse]

To jsem také chtěl vědět, jen jsem se bál zeptat.

[mkoubik]

Původně jsem chtěl screenshot udělat, ale zjistil jsem, že nemám ve svém gentoo nic, čím by to šlo vyfotit. Nechce se mi teď nic shánět a tím míň to pak kompilovat. Takže to prosím někdo vyfoťte a dejte sem link, díky.

Gentoo ruleZ

[midar]

gimp eee?

[Honza Balák]

Screenshot zde. Akorat se mi nejak nepodarilo zachytit to rozbaleny combo

[Jardík]

Jen se nevytahuj. Včera v noci jsem tam už jsem si taky napsal normální Makefile a nehází mi gcc takovýhle voloviny:

gcc: -lgtk-x11-2.0: linker input file unused because linking not done
gcc: -lgdk-x11-2.0: linker input file unused because linking not done
gcc: -latk-1.0: linker input file unused because linking not done
gcc: -lgdk_pixbuf-2.0: linker input file unused because linking not done
gcc: -lm: linker input file unused because linking not done
gcc: -lpangocairo-1.0: linker input file unused because linking not done
gcc: -lpango-1.0: linker input file unused because linking not done
gcc: -lcairo: linker input file unused because linking not done
gcc: -lgobject-2.0: linker input file unused because linking not done
gcc: -lgmodule-2.0: linker input file unused because linking not done
gcc: -ldl: linker input file unused because linking not done
gcc: -lglib-2.0: linker input file unused because linking not done
gcc -c -Wall -g `pkg-config --cflags gtk+-2.0` `pkg-config --libs gtk+-2.0` -DLANG_CZ -I. gui/about.c
gcc: -lgtk-x11-2.0: linker input file unused because linking not done
gcc: -lgdk-x11-2.0: linker input file unused because linking not done
gcc: -latk-1.0: linker input file unused because linking not done
gcc: -lgdk_pixbuf-2.0: linker input file unused because linking not done
gcc: -lm: linker input file unused because linking not done
gcc: -lpangocairo-1.0: linker input file unused because linking not done
gcc: -lpango-1.0: linker input file unused because linking not done
gcc: -lcairo: linker input file unused because linking not done
gcc: -lgobject-2.0: linker input file unused because linking not done
gcc: -lgmodule-2.0: linker input file unused because linking not done
gcc: -ldl: linker input file unused because linking not done
gcc: -lglib-2.0: linker input file unused because linking not done
gcc -c -Wall -g `pkg-config --cflags gtk+-2.0` `pkg-config --libs gtk+-2.0` -DLANG_CZ -I. gui/panel.c
gcc: -lgtk-x11-2.0: linker input file unused because linking not done
gcc: -lgdk-x11-2.0: linker input file unused because linking not done
gcc: -latk-1.0: linker input file unused because linking not done
gcc: -lgdk_pixbuf-2.0: linker input file unused because linking not done
gcc: -lm: linker input file unused because linking not done
gcc: -lpangocairo-1.0: linker input file unused because linking not done
gcc: -lpango-1.0: linker input file unused because linking not done
gcc: -lcairo: linker input file unused because linking not done
gcc: -lgobject-2.0: linker input file unused because linking not done
gcc: -lgmodule-2.0: linker input file unused because linking not done
gcc: -ldl: linker input file unused because linking not done
gcc: -lglib-2.0: linker input file unused because linking not done
gcc -c -Wall -g `pkg-config --cflags gtk+-2.0` `pkg-config --libs gtk+-2.0` -DLANG_CZ -I. lib/mounts.c
gcc: -lgtk-x11-2.0: linker input file unused because linking not done
gcc: -lgdk-x11-2.0: linker input file unused because linking not done
gcc: -latk-1.0: linker input file unused because linking not done
gcc: -lgdk_pixbuf-2.0: linker input file unused because linking not done
gcc: -lm: linker input file unused because linking not done
gcc: -lpangocairo-1.0: linker input file unused because linking not done
gcc: -lpango-1.0: linker input file unused because linking not done
gcc: -lcairo: linker input file unused because linking not done
gcc: -lgobject-2.0: linker input file unused because linking not done
gcc: -lgmodule-2.0: linker input file unused because linking not done
gcc: -ldl: linker input file unused because linking not done

Na co předávat knihovny při obyčejné kompilaci? Si nech až na linkování.

[Jardík]

A ten about dialog se mi jaksi nevejde na šířku obrazovky (1280px).

[mkoubik]

To je přesně ta možnost inspirace, o které jsem mluvil. Ten Makefile jsem už opravil (původně jsem chtěl mít všechny CFLAGS v jedné proměnné). A k tomu about dialogu - původně byl ten text ve scrolled window, ale bylo to celý rozhozený tak jsem to zrušil. Plánoval jsem na tom zapracovat, ale nějak jsem na to zapoměl. Asi se podívám, jak jsi to vyřešil ty (ještě, že je GPL2 kompatibilní s BSD licencí Můžeš se těšit na další verzi.

[Jardík]

Můj, jeho.

[brk]

Zatím je tak o gram pozadu. ;o)

[Michal Vyskočil]

O gram? To poznáš ze dvou screenshotů?

[brk]

Poctivě jsem si je oba přeložil a hlavně sleduji spotřebu „tuhých paliv“ jednoho z autorů.

[Jardík]

:)

[Michal Vyskočil]

Tak to pa ja

[Josef Kufner]

Mno, vzhledem k tomu, že ani jeden nemá nic víc než gui...

[Jardík]

To těžko. Už mám skoro hotové lokální vfs - za chvíli se bude brouzdat po disku a možnost kopírování, přesouvání, přejmenování, ...

[Michal Karas]

Když tak koukám na ten druhý screenshot, tak si říkám, že asi není moc dobrý nápad nastavovat klávesovou zkratku na Alt + F4.

[mkoubik]

Tu klávesovou zkratku nehodlám ve skutečnosti nastavovat. Po stisknutí toho tlačítka se program ukončí a popisek slouží jenom jako informace, že se to dá udělat i pomocí Alt + F4. Stejně je to v Total Commanderu a připadá mi to jako dobrý nápad (lepší než zbytečně mapovat klávesu F10).

[Michal Karas]

Total Commander je ale program pro Windows, takže se to dá celkem pochopit. Mně se ale například po Alt + F4 přepne window manager na čtvrtou virtuální plochu. A stejně tak očekávám, že každá slušná GTK+ aplikace se vypne zkratkou Ctrl + Q.

[Michal Kubeček]

Ten jeho je rozhodně napřed - už má verzi 0.9.0, vy teprve 0.0.1… :-)

[Michal Čihař]

A co teprv až někdo přijde s JXP Commanderem 2006 .

[franta]

Co zkusit dodelat gnome-commander, misto zakladani dalsich novejch projektu? Jen otazka, zadne rypnuti

[Mikos]

Gnome Commander nesplňuje jeden z naprosto zásadních požadavků na JXP Commander - nezávislost na desktopovém prostředí (ať už KDE nebo GNOME).

[Josef Kufner]

Ono myslím, že by nemusel být problém, tu závislost odstranit nebo učinit při překladu odstranitelnou.

[mkoubik]

Ještě mě napadá, je-li tu někdo, kdo si to stáhnul a vyzná se v céčku, nechť se podívá na to parsování /proc/mounts v libs/mounts.c. Připádá mi to dost prasácký. Jde to vyřešit nějak elegantněji? Neexistuje náhodou nějakej hotovej parser pro podobný věci? Jak byste to řešili?

[Jardík]

rootfs / rootfs rw 0 0
none /dev ramfs rw 0 0
/dev/root / ext3 rw,data=ordered 0 0
none /dev ramfs rw 0 0
none /proc proc rw 0 0
none /sys sysfs rw 0 0
none /proc/bus/usb usbfs rw 0 0
none /dev/pts devpts rw 0 0
none /dev/shm tmpfs rw 0 0
/dev/hda1 /boot ext2 rw 0 0
/dev/hdb2 /home ext3 rw,data=ordered 0 0

Můžeš tam alespoň vynechat, aby se nevipisovali ty s "none"? Dvakrát / a /dev se mi tam také nelíbí, nechápu proč to je v /proc/mounts 2x

[Jardík]

Nebo co takhle použít výstup df?

[mkoubik]

Nemám rád řešení typu co takhle použít výstup z df, ls, egrepu atd. Lepší řešení by bylo podívat se, jak to dělá df a pak to podle toho opsat.

[disorder]

podla mna je lepsie pouzit vystup - preto boli napisane tak ako boli napisane.

[Michal Vyskočil]

Ne, ty byly napsané proto, aby se daly používat z konzole. Binární soubory pochopitelně používají knihovní funkce

[disorder]

samozrejme nie je na skodu pozriet sa ako to robi a urcite ich parsovat v inych jazykoch nie je problem. aj tu by sa teoreticky dalo zavolat df | sed. ja som to myslel ako na sposob myslenia - nestavat monolity, ale vyuzivat uz napisane veci (pokial mozno oddelene)

[Michal Vyskočil]

V C parsovat textový výstup příkazu df? Nejjednodušším způsobem, jak zjistit, jak se to doopravdy dělá, bude náhled do zdrojáků df (výhoda OpenSource), nebo třeba busyboxu (jednodušší a tím pádem i přehlednější). Jenom, ten, kdo chce mít výsledek pod BSD licencí, ať se raději podívá na neGPL utilitky .

[Marcel Šebek]

Dvakrát je to tam proto, že jádro 2.6 umí namountovat na jeden mountpoint více filesystémů. Toho se využívá třeba při startu systému, jako / se namountuje nejdříve initramfs (to je ten rootfs), později je / přemountován skutečným root filesystémem. Je to čistší řešení než pivot_root.

[Michal Čihař]

Samozřejmě že existuje, tak jako skoro všechno ... getmntent(3)

[mkoubik]

To vypadá dobře. Asi to přepíšu. Je to rozhodně lepší řešení, než sosat standardní výstup z df. Mimochodem, stejně ho budu asi muset sosat kvůli volnému místu na disku. Nevíte někdo jak se to má správně dělat (pomocí exec()?)

[Michal Vyskočil]

Co se skutečně mrknout do zdrojáků df?

Jenom proboha žádné parsování standardního výstupu příkazů. K tomu, co chceš udělat slouží příslušné knihovní funkce.

[Michal Čihař]

statfs(2) … a zkuste se už oprostit od parsování výstupu.

[mkoubik]

Tak jsem to přepsal takhle:

#include <gtk/gtk.h>
#include <stdio.h>
#include <mntent.h>
#include <include/locale.h>
#include <include/version.h>
#include <include/panel.h>

extERN VOID Set_mounts(struct myPanel panel)
{
        GList *glist = NULL;
        gchar **name;
        struct mntent mnt;
        gint i;

        FILE *fd = setmntent("/etc/mtab", "r");

        i = 0;
        while (getmntent(fd)){
                name[i] = mnt.mnt_dir;
                glist = g_list_append(glist, name[i]);
                i++;
        };

        endmntent(fd);

        gtk_combo_set_popdown_strings(GTK_COMBO(panel.mounts), glist);

        return;
}

Zkompiluje se to bez problému, ale při spuštění to hází Segmantation fault. Nevíte někdo kde je chyba? Asi nějaký zapomenutý ukazatel. Nejspíš jsem lama, ale já tam fakt nic nevidim.

[disorder]

omg, aspon zaklady gdb by sa ti zisli ;)

[mkoubik]

Nechceš mě aspoň nakopnout, kde mám hledat? Jsem samouk a narozdíl od tebe nemám státnici z datovejch typů v céčku a z ladění v gdb. Nadávat umí každej.

[disorder]

heh, ja sam tiez co ucit. ale nejake lesie howto najdes aj na nete.

skompiluj -ggdb3
spusti gdb jxp
zadaj run
ked to padne zadaj bt - takto zistis kde to pada (backtrace)

[Michal Čihař]

Zapni si -Wall, předpokládám, že pak ti gcc napíše že mnt není inicializované

[Michal Vyskočil]

Samozřejmě hledej na google

BTW: pokud tohle bereš jako nadávání, pak se nad sebou zamysli. Uznej sám, že programovat cokoliv netriviálního tímto stylem (nevím, tak se zeptám ve fóru) je zhola nemožné. Zvlášť nechápu, proč to musí být v C, které moc neovládáš. Proč nenapíšeš pár prototypů třeba v Ruby, nebo Pythonu, abys to trochu dostal do ruky? Na přepis do C bude potom času dost .

BTW2: já mám raději debugovací výpisy, než gdb.

[msk]

já mám raději debugovací výpisy, než gdb

Ja ani moc nie, ale mnohokrat je to jedina moznost, ako sa dopatrat vysledku/bugu ( hlavne v situaciach, ked na danom stroji zije podivne prostredie, ktore bud gdb neobsahuje, alebo v nejakej ultra obsolete verzii ).

[Josef Kufner]

Dobře udělané ladicí výpisy jsou velice užitečná věc. Hlavně když jich je kolem jednotek MB/s

[mkoubik]

Tak jsem to opravil, pokud to někoho zajímá, tak jsem to napsal takhle:

#include <gtk/gtk.h>
#include <stdio.h>
#include <mntent.h>
#include <string.h>
#include <stdlib.h>
#include <include/locale.h>
#include <include/version.h>
#include <include/panel.h>

extern void set_mounts(struct myPanel panel)
{
        GList *glist = NULL;
        gchar *name[255];
        struct mntent *mnt;
        gint i;

        FILE *fd = setmntent("/etc/mtab", "r");

        i = 0;
        while ((mnt = getmntent(fd)) && i < 256){
                name[i] = (char*) malloc(strlen(mnt->mnt_dir)+1);
                strcpy(name[i], mnt->mnt_dir);
                glist = g_list_append(glist, name[i]);
                i++;
        };

        endmntent(fd);

        gtk_combo_set_popdown_strings(GTK_COMBO(panel.mounts), glist);

        return;
}

[Michal Čihař]

Teď už tam je jenom buffer overflow . Proč místo té magie s polem nepřidávat rovnout do seznamu?

                glist = g_list_append(glist, mnt->mnt_dir);

[mkoubik]

Protože by to dopadlo následovně:

• do mnt->mnt_dir se uloží hodnota č. 1
• 1. položka v seznamu je mnt->mnt_ent
• do mnt->mnt_dir se uloží hodnota č. 2
• 2. položka v seznamu je mnt->mnt_ent
• do mnt->mnt_dir se uloží hodnota č. 3
• 3. položka v seznamu je mnt->mnt_ent
• 1., 2., i 3. položka v seznamu odkazuje na mnt->mnt_dir, v níž je hodnota č. 3

Bez magie s polem jsem to zkoušel včera celý den...

[Michal Čihař]

Aha, já myslel, že si to g_list_append kopíruje ... no jestli ne, tak ten pointer po skončení funkce stejně vede do pryč.

[mkoubik]

Nevím, jak g_list funguje, ale takhle to jde a bez toho kopírování mi to nešlo (všecny položky byly stejné jako ta poslední).

[Michal Kubeček]

To myslíte vážně? Tedy že opravdu nevíte, jestli si g_list ten string někam zkopíruje nebo jestli si jen zkopíruje pointer, jestli to po sobě ve druhém případě uklidí atd.?

[VícNežNic]

Je pravda, že tak nějak zjevně to v dokumentaci nevidím. Tohle je u Glibu a spol. pěkná otrava (no, v céčku obecně). Zjistit co musím uklidit a jak to musím uklidit.

[Michal Kubeček]

Chtěl jsem hlavně naznačit, že bych určitě nevyprodukoval kód, který ty funkce používá, aniž bych si nejdřív ověřil, jak to vlastně přesně je.

[VícNežNic]

Takový gob má nějaké lehké možnosti, jak dát najevo co a čím se má rušit, nicméně i tak by to chtělo do dokumentace výslovně napsat. Nemluvě o tom, že gob je věc sama o sobě lehce úchylná

[trekker.dk]

Zkopíruje si pointer a ne, je potřeba uklidit ručně (aspoň tak chápu dokumentaci)

[VícNežNic]

Já taky (s tím, že si ještě nesmím zapomenout zrušit list a jednotlivé GListy), ale ruku do ohně bych za to teda nedal.

[mkoubik]

Pomohlo by to pole po skončení while zrušit pomocí free() v cyklu? Ty proměnné už stejně nejsou potřeba, když hned o 3 řádky dál (return) zaniknou...

[Michal Kubeček]

Záleží na tom, co s těmi pointery, které jste nasypal do glistu, udělá tento řádek:

  gtk_combo_set_popdown_strings(GTK_COMBO(panel.mounts), glist);

[VícNežNic]

No, nevím, nejsem si jistý, jestli po nich GtkCombo nebude ještě potom toužit. Skoro bych řekl, že jo. Každopádně se v dokumentaci píše, že GtkCombo je zavrženo ve prospěch GtkComboBox.

[mkoubik]

Data si nekopíruje (to by mi to v prvním případě fungovalo správně), tudíž kopíruje ukazatel. Ten samozřejmě zaniká se zánikem g_listu. Jen jsem nechápal, jaktože to funguje i mimo funkci, což mi osvětlil tento příspěvek.

[trekker.dk]

Jaktože vede do pryč?

Když udělám pointer, alokuju pro něj paměť (pointer = malloc()) a pointer potom kopíruji do nějaké globální struktury, tak sice pointer po skončení funkce zmizí, ale jeho kopie stejně jako data zůtanou na místě.

[Michal Čihař]

jj, asi bych si to měl pořádně přečíst, než do toho začnu kecat

[mkoubik]

A jaký buffer overflow? Každou proměnnou v tom poli to alokuje na velikost mnt->mnt_dir_ent + 1 (ukončovací znak řetězce), takže mě nemůže překvapit žádný výstup z getmntent()

[Michal Čihař]

name[255] není nadefinované, takže se na konci cyklu přepíše jeden z pointerů okolo a při troše štěstí to nespadne.

[mkoubik]

Až teď mi to došlo... Už jsem to opravil. Ale stejně - nevím jestli má někdo 256 položek v mtabu...

[Michal Kubeček]

A na této jednoduché filosofii je postavena většina programů, které vedou hitparádu bugtraqu… :-)

[trekker.dk]

To je pravda, moc-mounts-proof verze by mohla vypadat nějak takhle:

gchar **name; int names=256;

...

        name = (gchar **) malloc (sizeof(gchar*)*names);
        i = 0;
        while ((mnt = getmntent(fd))){
                if (i == names) {
                   names+=256;
                   name = (gchar **) realloc (name, sizeof(gchar*)*names);
                }
                name[i] = (char*) malloc(strlen(mnt->mnt_dir)+1);
                strcpy(name[i], mnt->mnt_dir);
                glist = g_list_append(glist, name[i]);
                i++;
        };

...

free (name); /*uvolní seznam, ale nikoliv řetězce, které obsahuje */
return; 

(Teď ještě prosím kohokoliv, aby našel a opravil nějakou strašně pitomou chybu, kterou jsem v tom určitě udělal )

[disorder]

predpokladam, ze testovanie navratovej hodnoty malloc() je vynechane z dovodu zachovania jednoduchosti :)

[Michal Kubeček]

No, když bude mít opravdu dobrý handler na SEGV… :-)

[trekker.dk]

Tiše předpokládám, že paměti je dost a NULL to vracet nebude, ale aby měly dušičky pokoj:

p = malloc();
if (!p) abort();

Nic moc, ale už testuju, jestli to nevrátilo NULL. Spokojenost?

[disorder]

preferujem zapis

void *p;

if ( ( p = malloc(size)) == NULL ) {
    /* rob s tym neco vole :) */
}

[trekker.dk]

Už jsem si posloužil sám, gchar je char, nikoliv řetězec, takže to nahoře je úplná pitomost

[trekker.dk]

Beru zpět. Začínám mít pocit, že dneska bylo programování dost.

[Josef Kufner]

Proč mám pocit, že pole vůbec nepotřebuješ? Prostě jen:

while ((mnt = getmntent(fd))){
    glist = g_list_append(glist, strdup(mnt->mnt_dir););
};
return;

[Josef Kufner]

... jo a ten středník tam nepatří

[mkoubik]

Tady vidíš výhodu svobodné licence. To s tím strdup() mě vůbec nenapadlo. Tím se vyřeší spousta problémů (třeba s tou dynamickou alokací). Jen doufám, že v tom nebude žádnej háček, jdu to vyzkoušet.

[Josef Kufner]

Problémy by s tím být neměly. Je to ekvivalentní tomu tvému, jen je tam nejspíš méně chyb a ten pointer se zahazuje (ale paměť se neuvolňuje) hned.

[mkoubik]

Funguje to v pohodě. Díky.

[Michal Kubeček]

Nějak tam nevidím kontrolu, zda malloc() náhodou nevrátil NULL. To je mimochodem zrovna věc, která by byla v C++ podstatně jednodušší. Jinak doufám, že ten panel.mounts se postará o řádné dealokování všech stringů, které jste mu předal.

[disorder]

no, to je dovod preco ludia od C++ nadavaju na C - najcastejsia vycitka. ja na priklad kontrolujem aj ci fclose() spravne zatvori, ked nie, tak sup s tym do stderr. kontrolovanie navratovych hodnot treba mat permanentne na mysli.

[Miloslav Ponkrác]

A nebo prostě napsat abstrakční vrstvu, která tyhle věci jednou provždy vyřeší za vás. A takové výjimky se přehlédnout prostě nedají. Další důvod pro C++.

[Josef Kufner]

Napsat si wrapper okolo malloc je celkem běžná věc. Alespoň to pak na chybu reaguje podle potřeb konkrétního programu. Není to důvod pro C++, je to důvod pro „nepsat jak prase“.

[Miloslav Ponkrác]

a jak se píše wrapper, který vyhazuje výjimky v C? tedy ne že to v principu nejde, ale je to poněkud pracnější a člověk by se na to vybodnul

[Josef Kufner]

Napíše se děsně jednoduše: Nijak. Vyjímky v C nejsou a je to jen dobře.

Ten wrappet může třeba zobrazit zprávu, že program padnul na hubu, nebo vypsat nějakou smysluplnou hlášku a korektně ukončit program.

[Miloslav Ponkrác]

Výjimky v C lze nasimulovat a pokud bych dnes měl před sebou perspektivu delšího vývoje v C, tak je to jedna z prvních věcí, co bych si napsal.

Koneckonců většina překladačů pro Windows obsahuje rozšíření pro výjimky, ono je totiž v C napsané i jádro Windows a výjimky používá též.

Právě že od wrapperu, stejně tak jako od knihovny neočekávám, že mi bude ukončovat můj program, nebo vypisovat hlášky způsobem odlišným od zbytku programu. Dávám přednost tomu, když se knihovna chová jako knihovna, tedy řeší si svoje věci a globální věci nechává hlavnímu programu.

Přeji Vám hodně takových knihoven, nejlépe aspoň padesát, kdy každá z nich bude abortovat program kdykoli se jí něco znelíbí, každá si bude vypisovat hlášky jiným způsobem a úplně na jiné místo a alespoň u poloviny to nepůjde změnit jinak, než tvrdým zásahem do zdrojáků jak je u mnohých fantastických C knihoven zvykem.

[Josef Kufner]

Tak ještě jednou:

Ten wrapper může třeba zobrazit zprávu, že program padnul na hubu, nebo vypsat nějakou smysluplnou hlášku a korektně ukončit program.

Kde je něco o nějaké knihovně? Kde je něco o tom, že ten wrapper bude pro všechny programy?

[Miloslav Ponkrác]

Proboha, Vy chcete jednou napsaný wrapper zahodit a psát v jiném projektu znovu? Sodoma gomora, vidíš to taky Cecilko?

[Josef Kufner]

A co jiného dělat s funkcí, která v každém programu vypadá jinak?

[Miloslav Ponkrác]

Pokud v každém programu plní v zásadě stejnou funkci (jako třeba malloc, který jsme tu uvažovali) a wrapper jí v každém programu obalí tak, že v každém programu vypadá jinak, je to chyba wrapperu a rozhraní, kterým jsem jí obalil. Je to špatně navržený interface.

[Josef Kufner]

Tak malá ukázka, jak by vypadal takový wrapper pro konsolovy program:

void *my_malloc(...) {
  void *ret;
  if (!(ret = malloc(...))) {
     perror("Malloc se porouchal");
     exit(1);
  }
  return ret;
}

A teď kousek v GTK+:

void *my_malloc(...) {
  void *ret;
  if (!(ret = malloc(...))) {
     show_error("Malloc se porouchal"); // zobrazi chybu
     gtk_main_quit(1);
  }
  return ret;
}

A ted mi rekni, co je na tom spatne.

[Miloslav Ponkrác]

Moc věcí. Nejvíc asi to, že program nijak nemůže reagovat na nedostatek paměti a je prostě násilně ukončen aniž by řekl švec.

Zlé jazyky by řekly, že je možné zaregistrovat funkci pomocí atexit, ale to má spoustu háčků. Pokud taková funkce zaregistrovaná pomocí atexit se pokusí zavolat tento wrapovaný malloc, dojde k nekonečné rekurzi, nebo ke zvláštnímu chování. A zase taková funkce zaregistrovaná pomocí atexit nemůže na to nijak reagovat. Jediné co může je wrapovanou funkci nepoužívat a duplikovat její funkci.

O co jednoduší je řešení pomocí výjimek. Prostě při nedostatku paměti se vyhodí výjimka. Kdo chce, tak to ošetří, kdo ne, nechá to prohučet do ukončení programu. Při vyhození výjimky se automaticky ukončují a ošetřují věci, dojde k zavírání handlů, k automatickému úklidu a při ukončení programu je uklizeno, je-li to potřeba. Je to čistější a univerzálnější a přitom jednodušší.

[Josef Kufner]

Program reaguje, protoze program je ten wrapper.

Funkce zaregistrovana v atexit nepotrebuje malloc, protoze jejim jedinym ucelem je uklizet. A i kdyby, nebude prece volat wrapovanou verzi...

[Miloslav Ponkrác]

No a to je právě krása C++ a vlastně všech trochu lepších jazyků. Nepotřebujete používat více funkcí téhož jako v tomto případě wrapovanou a newrapovanou verzi. Stačí jedna funkce na alokaci paměti, která v případě problému vyhodí výjimku a je to. To je právě jedna z věcí, která mě donutila přestat používat C, několik věcí dělá totéž, protože v C schází prostředky na slušné a efektivní programování.

To co tu předvádíte je hezké, ale je to vlastně ve stylu dodělej si sám. Zajímavé je, že v C++ nikdo takové wrappery na alokaci paměti psát nemusí.

C je hezký jazyk, ale na větší věci je zoufale neefektivní. Člověk se plácá na nízké úrovni a řeší věci, které by jinde řešit nemusel. Všimněte si, že každý větší projekt psaný v C, kde mají rozum se snaží překlopit do C++, Pythonu, nebo jiného vyššího jazyka. To je příklad třeba Firebirdu.

[disorder]

nema dovod sa tu natahovat. povedzme si pravdu - nie vela projektov je tak zlozitych, aby C nebol VELMI vhodny kandidat - mailovy klient, feed reader, gaim, irssi, gstreamer, gimp... takze realne priklady vyvracaju vase tvrdenia o neefektivnosti C.

[Miloslav Ponkrác]

Pro všechny tyhle případy je C++ mnohem vhodnější kandidát. Dokážu si velmi dobře představit projekt podobné složitosti jako třeba gimp, kde jeden tým ho bude vyvíjet v C a druhý v C++. Řekněme, že tým v C++ ho udělá rychleji, ale i kdyby ne, kód v C++ bude čistější, udržovatelnější, bude obsahovat méně chyb a snadněji se bude měnit. Tohle je realita, o které se moc projektů a týmů přesvědčilo.

Ono jde v zásadě všechno, klidně i strkat C všude. Ale jsou prostě věci, se kterými to jde lépe a snadněji. Vidím pouze dva důvody, proč lidé dávají přednost C před C++, a to buď že kompilátor C++ není k dispozici, nebo že lidi prostě C++ neumí. C je samozřejmě možné v těchto případech použít, ale C++ je rozhodně na vývoj jednoznačně efektivnější při zavchování všech výhod, které má C. Použití C++ přidává jen výhody.

[disorder]

ano, aj C++ "jde strkat vsude" :)

fakt je, ze si zvolili C a su spokojni, ja som rad za skvele programy (takze tazko polemizovat o tom, ci by bolo C++ vhodnejsie).

a pokracovat by som mohol donekonecna: mplayer, xfce, gkrellm, screen, mc, ...

takze veta Použití C++ přidává jen výhody. je mytus, ktory davno padol a v svete UNIXu sa nastastie nikdy ani neuchytil... to je ta veta proti ktorej bojujem :)

takze vobec nie len jadro a utility okolo toho...

(ale pozor: netvrdim, ze je C++ nahovno ani, ze nemoze byt niekedy nesporne vyhodnejsie)

[Miloslav Ponkrác]

C++ jde strkat všude, a pokud potřebujete maximální rychlost programu a rozumnou efektivitu vývoje, a nedej bože ještě v týmu, tak nemáte lepší volbu, než C++

já třeba JXP commander, který se tu vytváří bych rozhodně nedělal v C. upřímně řečeno, já bych ho nedělal ani v C++, ale rovnou bych nasadil vyšší jazyk, třeba Python

to, že někdo zvolil C nemusí znamenat, že by C++ nebylo lepší.

řekněte mi prosím ty nevýhody, které použití C++ oproti C přidává. zatím jste napsal jen, že je to mýtus, proti kterému bojujete, ale žádná konkrétní výhoda použití C oproti C++ z Vaší strany nepadla. tedy nepočítám-li lži o vyšší efektivitě jazyka C oproti C++, to počítat jako nebudeme. naopak já zatím vidím jen výhody ve všech projektech, kde se C++ dalo přednost před C. nevidím zatím žádný projekt, kde by použití C++ litovali. dokonce i ve světě+ open source často slyším větu chcete přepsat C projekt do C++.

můj názor je, že i jádro by bylo lépe dnes napsat v C++. ale v době, kdy Linus začal LInux vyvíjet by C++ byla špatná volba, C++ tehdy nemělo dobré kompilátory a nemělo standard. dnes už je jednoznačně C++ lepší volba i pro kernel a mnohé úspěšné operační systémy mají kernel v C++. napovím, například každá Nokie má operační systém napsaný v C++.

[disorder]

maximalnu rychlost s C++ nejde dosiahnut, pretoze pozostava s veci abstraktnych, procesoru nic nehovoriacich a tazko optimalizovatelnych. fakt.

jxp commander sa tu vytvara aj v C++, ale ja by som to na porovnanie urcite nebral - obaja to vzali z opacneho konca.

a vy tu tiez nepisete konkretne nevyhody C, ktore by skuseny Ceckar nepovazoval za nevyhodu ale za realitu, s ktorou ma skusenost a vie co od toho ma ocakavat. takze to, ze je mnozstvo uzitocnych programov v C by malo postacovat ako dokaz toho, ze C++ vzdy a vsade je mytus.

tak napiste lepsie programy aj jadro, ked su tie v C tak na obtiaz a podla vas by to bolo neporovnatelne lepsie v C++. vseobecny nazor je, ze C je na jadro aj dnes vyhodnejie. rovnako ako je mikrokernel teoreticky vyhodnejsi. real-time kernel asi dost tazko, alebo ano?

[Miloslav Ponkrác]

maximální rychlost naprosto stejnou s C lze v C++ dosáhnout. třeba takové používání tříd není nic, co by brzdilo procesor.

já tu konkrétní nevýhody C píšu. je to nízkoúrovňový jazyk, který neobsahuje ani základní věci. nemá slušnou práci se stringy, nemá objekty, nemá téměř žádnou abstrakci. v podstatě C bylo vymyšleno jako portable assembler a tuto funkci plní.

neříkám, že C++ vždy a všude, jen píšu, že všude, kde se použije C a projekt je větší, než pár tisíc řádek je mnohem výhodnější použít C++. pokud na projektu dělá víc, než jeden člověk, je použití C++ díky přítomnosti tříd, přístupových oprávnění, zapouzdření a jmenných prostorů ještě daleko výhodnější a nemusíte tak řešit spoustu konfliktů názvů a nevhodných použití jako v C.

já neříkám, že C je na obtíž. dokonce přímo říkám, že před deseti lety bych udělal to samé a psal jádro v C. že je dnešní kernel v Linuxu v C je hlavně z historických důvodů a nemá smysl to měnit. mikrokernel je výhodnější jen někdy. rozhodně bez mikrokernelu budete jen stěží dělat spoustu věcí a i Linux konvertuje čím dál více k mikrokernelu, byť jen po malých částech. čistě makrojádrový systém dnes neexistuje. poznámku s real-time jsem nepochopil. třeba QNX je mikrokernelový real-time operační systém.

jinak vývoj jádra Linuxu je typickým příkladem, kde se efektivita vývoje řešit nemusí. jádro LInuxu vyvíjí tolik lidí, že kdyby firma vyvíjela programy se stejnou efektivitou pracovní síly jako se vyvíjí jádro Linuxu, dávno by zkrachovala. kdyby se vývojáři měli skutečně platit, myslím si, že i manažer projektu by v mnoha případech přešel z C na efektivnější jazyky.

[disorder]

real-time kernel v C++.

nema to zmysel, proste "big fan" C++ a nechapete co mam na mysli. zda sa, ze ste afektovany voci C od doby co ste poznal C++. [no offense]

[Miloslav Ponkrác]

real time kernel v C++ je realita, nejenom teoretická záležitost.

já nejsem big fan C++, prostě jen vím, že všechno co je v C je i v C++ a ještě mnohé navíc. efektivita výsledných programů může být stejně dobrá jako v C. já prostě nevidím ani jeden důvod, proč kdykoli nedat přednost C++ před C, pokud je to proveditelné.

stejně tak Vám řeknu, že C++ bych v mnoha případech nepoužil. ale tam, kde se používá C, tam bych to na 100% nahradil C++.

já prostě oprqavdu nechápu jedinou výhodu použití C oproti C++. nikdo tady zatím žádnou neuvedl, ani Vy ne. pokud budu vědět, že C je lepší varianta, udělám to. nezajímá mě teorie, jde mi o praxi.

[disorder]

prostě jen vím, že všechno co je v C je i v C++ a ještě mnohé navíc

já prostě nevidím ani jeden důvod, proč kdykoli nedat přednost C++ před C

ale tam, kde se používá C, tam bych to na 100% nahradil C++.

ako sa hovori: afekt ako hovado. vas nazor nemam sancu zmenit ani trosku.

praktickych ukazok je dost, uviedol som. to ze vy by ste to robili v C++ nic nemeni na ich kvalite. bodka. ked niekto vie robit v C, tak robi ked je mu to vyhodne - ale vy by ste pouzili C++. bodka. nema zmysel pokracovat.

[Miloslav Ponkrác]

no vašimi výkřiky ve stylu "toto je mýtus, proti kterému bojujeme" a "afekt jako hovado" můj názor opravdu nezměníte. pokud mi uvedete konkrétní (a pravdivý) argument, budete určitě úspěšnější.

jinak já netvrdím, že neexistuje hodně kvalitních programů psaných v C. já jen tvrdím, že v situaci, kdy člověk umí C i C++ (což není vždycky) a v situaci, kdy je k dispozici dobrý kompilátor pro C++ (což není vždycky, viz vývoj jednočipových procesorů), pak není žádný důvod použít dnes (všimněte si toho dnes) nemám žádný důvod preferovat C (nepočítám-li averzi některých lidí vůči C++).

pokud máte rád C, pište projekty v C. to je celé. já naprosto chápu, že máte raději C, ale já se prostě chci bavit v praktické rovině, ne v rovině emocionální, citové a v rovině mýtů.

[disorder]

bojujem, nie bojujeme. nie je to ziadna konspiracia :)

ja vseobecne nemam rad predsudky, zaslepenost a hlupost. takze ten boj u mna nie je prekvapujuci, pretoze vas nazor je jednoznacne skresleny.

zato, ze vy by ste vsade preferoval C++, nemusite hned sirit nazor "vzdy a vsade C++" i ked ste to v dalsom prispevku viac-menej poprel. toto ma uplne dostalo. ked nieco poviem, tak bud priznam chybu alebo si za tym stojim a nepozmenim nazor na: "su veci kde by bolo C lepsie, ale take som este nevidel"

o tom to cele bolo.

[Miloslav Ponkrác]

v čem je můj názor zkreslený? já opravdu ještě neviděl projekt, kde by se víc hodilo C oproti C++, mám-li na výběr mezi těmito dvěma možnostmi. a to jsem programoval v C na Amize, na Atari, na MS-DOSU, na VAXu, na Solarisu, na Linuxu, na Windows, na jednočipech, a možná ještě jinde za svých 18 let praxe. všude kde jsem co dělal od malých, středních i velkých projektů bych jednoznačně volil z praktických důvodů C++ oproti C, pokud by bylo na výběr, což nebylo vždy. opravdu jsem nenašel jediný projekt a jediný argument proč volit C před C++ pokud tu svobodu volby mám. jediné co jsem uvedl je, že jsou případy, kdy prostě svoboda volby není. ale po technické i praktické stránce je podle mě C++ vždy lepší volba, než C. možná je to pro Vás zaslepenost, ale já si fakt sám před sebou nedokážu zdůvodnit z technického hlediska volbu C před C++ a najít jediný kladný argument, proč bych to dobrovolně udělal. dokážu si zdůvodnit, proč bych použil třeba Python před C++, nebo Lisp před C++, nebo spoustu dalších věci, ale nedokážu si prostě obhájit volbu jakzyka C před C++. to je celé. a zatím jsem prostě nenašel praktický argument v čem je C lepší. to je celé.

[disorder]

já opravdu ještě neviděl projekt, kde by se víc hodilo C oproti C++

to ale neznamena, ze to je objektivny nazor. a zjavne s nim vela ludi nesuhlasi, takze tak.

zatím jsem prostě nenašel praktický argument v čem je C lepší

ano, vy by ste preferoval C++ aj na kernel.

uz sa to opakuje. stacilo.

[Miloslav Ponkrác]

a Vy jste zatím nedal jediný skutečný argument, pominu-li emoce. stejně tak není objektivní názor, že je hodně projektů v C, takže proto musí být C lepší. jinak věta "vela ludi nesuhlasi" taky není nic objektivního. pokud "vela lidi bude nesuhlasit", že koule, kterou pustim nespadne dolů, ale budou si myslet, že poletí nahoru, tak neznamená, že budou mít pravdu.

proboha chlape, ukažte mi jediný objektivní pravdivý argument, kde jste něco konkrétního říkal? já jsem argumenty dával, Vy jste je přešel a nevyvrátil.

klidně zůstaňte u C, kde je problém? já jsem jenom psal, že u svých projektů nebudu C volit, ale do Vašich já vám mluvit nebudu. dělá-li Vám to radost, proč ne?

[disorder]

a tu je zasadny problem - vobec nechapepte o com som pisal. ja tu netvrdim ze C ruleZZ a vsetko ostatne sux - vyvraciam nazor, ze C je nanic. tzn. ze realita je dobrym prikladom, ze to tak nie je.

ziadne vyhody tu pisat nebudem, pretoze: 1) o to tu nejde 2) co je v konkretnom pripade (pre projekt alebo programatora) vyhoda, nemusi byt inom

ja som vam nehovoril do vasej volby jazyka, ale do nazoru "C sux a nie je na nic dobry". keby tam bolo "IMO C sux", tak si to nevsimam...

a uz to asi tretikrat opakujem...

[Miloslav Ponkrác]

ok, souhlasím. nikde jsem netvrdil, že C je nanic, jen, že existují lepší volby. jinak já jsem výhody popsal včetně konkrétního vyjmenování, proč se někde musí použít C namísto C++. myslím, že nejsme názorově v rozporu, jen si nerozumíme.

[Kyosuke]

Jenže C++ nejde umět. Možná pan Stroustrup ho zná do detailů, ale v tomhle má Raymond pravdu – ten jazyk je šíleně překomplikovaný. Proto se o to ani nesnažím.

[Miloslav Ponkrác]

Nemusíte ho používat celý. Já sám, když jsem přecházel z C na C++ jsem ho nejdříve používal jako C, pak jako C s třídami a postupně jsem přidával. I jako C s třídami je C++ velmi jednoduše naučitelný a už tohle je výhoda jako býk.

Analogie: Kdo z Vás do detailů umí celý bash? A přesto se používá a bash se dá používat, i když znáte jenom desetinu. A s C++ je to stejné.

[Kyosuke]

„Kdo z Vás do detailů umí celý bash?“

Jeden můj kamarád. Akorát že bash je o dost jednodušší a skripty v něm povětšinou taky. Kdybych měl číst a chápat nějaký kód od někoho jiného, kdo by používal zrovna ty části, co já ne, asi bych spíš upřednostnil kulku do hlavy.

[Miloslav Ponkrác]

Řekněme, že lidí, kteří umí C++ na 100% je možná více, než lidí umějící na 100% bash. Nemusíte přeci chápat kód někoho jiného, stačí, když chápete rozhraní. V projektu s deseti milióny řádků nic jiného dělat nemůžete.

[Luboš Doležel (Doli)]

Když se vám porouchá malloc, tak se vám ten dialog pravděpodobně neukáže...

[Michal Vyskočil]

No, bývá dobrým zvykem si nějaký podobný dialog vytvořit hned na začátku, aby, v případě potřeby, šel vůbec zobrazit

[Miloslav Ponkrác]

Vytvoření dialogu na začátku není záruka, že nebude potřebovat další paměť při zobrazení.

[Michal Vyskočil]

Jo, to je pravda, tak jako bych nic neřekl .

[Kyosuke]

Ještě se může zobrazit a pak někam minimalizovat. Jenom ho zobrazit na straně X serveru by pak mělo být zaručeně bez alokací, ne?

[Miloslav Ponkrác]

Nikdo Vám to nezaručí.

[Kyosuke]

To byl žert. Já se obávám, že vyčerpání paměti aplikací může způsobit problémy i v ne-GUI handleru. Nejsem si teď úplně jistý, ale mám pocit, že Java ve Windows trpěla tím, že se občas při handlingu výjimky OutOfMemory pokoušela alokovat další paměť, za což ji systém s radostí odstřelil, čímž ta výjimka byla napůl k ničemu. Tedy doufám, že to byla Java. Teď to nemůžu nikde najít.

[Miloslav Ponkrác]

V Javě, ani v .NET prostě nejde ošetřit nedostatek paměti a elegantně uvést program do stabilního stavu, uložit rozdělanou práci a ukončit program. V C++ to jde.

[Michal Vyskočil]

Nejlepší ho bude přímo zobrazit ... takhle by se to ještě prodalo jako reklama některému výrobci pamětí (asi začínám myslet jako manažer ).

[VícNežNic]

Možná by se mohl upravit systém a X server, aby dokázal zaručit, že na zobrazení chybových hlášek o nedostatku paměti vždy pamět zbyde

[Kyosuke]

Když se na monitor přilepí žárovička "Došla paměť", dá se s ní blikat přes I/O port pomocí operací, které zaručeně žádnou paměť nealokují.

[disorder]

nie abstrakcnu vrstvu, ale wrappery. takto ale clovek zabudne a nemusi to mat vzdy po ruke... a na pisanie kniznic je stale vyhodne C, pretoze sa daju vsade vyuzit a su dobre optimalizovane...

nie, SIGSEGV sa naozaj neda prehliadnut ;))

[Miloslav Ponkrác]

mě prostě přijde C nevýhodné. C znám velmi dobře, před C++ jsem si s ním užil, ale právě proto C nikdy dobrovolně nevolím. nevidím prostě jedinou výhodu volit C

knihovna v C++ se také dobře využít a program v C++ také umí exportovat C like rozhraní

z C++ chodí naprosto stejně optimalizaované programy jako z C

každý slušný člověk si napíše něco jako:

int main() { set_terminate(moje_funkce_na_zobrazeni_nezachycenych_vyjimek);

... }

nebo v GCC máte dokonce i speciální funkci, která zobrazí detailnější informace o nezachycené výjimce

[msk]

Hmm, ja som potom taky polo-c++ programator. Ked som zacinal s C++, vynimky som nejak vynechal, potom som zacal robit projekty v kdevelop3, ktoreho c++ projekty mali defaultne vynimky zakazane ( mozno z vykonnostnych dovodov ) a pouzivam ich velmi zriedkavo. Existuje nejaka aspon ciastocne relevantna studia o vplyve exceptions na vykon?

[Miloslav Ponkrác]

Ano, pokud není vyhozena výjimka, pak používání výjimek je naprosto stejně rychlé jako kdybyste je nepoužíval, ba dokonce často mnohem rychlejší, protože Vám odpadají různé kontroly návratových hodnot a další kód, který rozhoduje, zda došlo k chybě, a tuto funkčnost teď řešíte výjimkami.

Pokud je vyhozena výjimka, její zpracování je pomalejší, než pouhá kontrola návratového kódu. O dost pomalejší. Nicméně se nepředpokládá, že Vám v programu budou lítat milióny výjimek za sekundu.

Na druhé straně ovšem stojí za zmínku, že zpracování výjimek automatizuje takové množství operací od automatického úklidu kódu přes přenesení obsluhy chyb tam, kde je to vhodné obsloužit, atd.. Protože v běžném programu vznikají chyby zřídka, je kód s výjimkami většinou rychlejší, než bez nich, viz výše o odpadnutí kódu na kontrolu chyb.

Kód s výjimkami je mnohem čistější a přehlednější, a tím nepřímo způsobuje i menší množství logický chyb v programu.

Na druhé straně je nutné říci, že výjimky nejsou jediným způsobem, jak se vypořádat s chybami, takže pokud je někdo používá na všechno, tak je to taky nic moc.

[Smazáno]

/etc/mtab

[Michal Kubeček]

Možná trochu naivní otázka: k čemu vlastně potřebujete ten seznam mounting pointů v comboboxu?

[mkoubik]

V Total Comanderu ve windows je podobný combobox pro přepínání mezi disky (A:, C:, D: atd). V unixových systémech ale nic takového není a jako nejlepší náhrada mi připadá seznam pro přepínání mezi přípojnými body.

[Josef Kufner]

Tak když nemáme disky, tak proč máme combobox?

[mkoubik]

Sice nemáme disky označené písmeny, ale to neznamená, že nemáme diskové oddíly, disketové a optické mechaniky a síťové disky.

[Michal Kubeček]

To sice máme. Ale princip mountování filesystémů spočívá IMHO právě v tom, že jsou jednotlivé diskové oddíly transparentně začleněny do adresářové struktury, že uživateli by mělo být (až na pár výjimek) jedno, co je samostatný filesystém a co ne. Tedy přinejmenším u permanentně připojených filesystémů, u výměnných médií by to asi jakýs takýs smysl mělo, ale otázka je, zda je dokážete spolehlivě poznat.

[mkoubik]

Výměnná média se dají spolehlivě rozeznat podle typu filesystému, ale IMHO je to užitečné i pro oddíly. Já mám dualboot s windows Me a fat32 oddíl mám připojený na /mnt/hda1 a tento adresář mám ve všech možných bookmarcích a v KDE na ploše.

[Michal Kubeček]

Výměnná média se dají spolehlivě rozeznat podle typu filesystému

Jak?

[Josef Kufner]

No přece podle vfat. Například /mnt/windows na /dev/hda2.

[Michal Kubeček]

Ano, to je typický příklad výměnného zařízení. Něco takového totiž přímo volá po výměně… :-)

[Michal Vyskočil]

To bych nechal na jádře, které tyto informace exportuje do /sys/block/*/removable (proboha, hlavně neparsovat). Ale nevím, zda existuje nějaké univerzální API, nebo se to musí pro každý unix řešit jinak.

Kio to také nějak rozpoznají, takže jde jenom o to, zjistit jak

[Michal Čihař]

libsysfs?

[Michal Vyskočil]

To ano, ale sysfs je Linux only, ne? Nebo bude i na BSD?

[Michal Kubeček]

Spíš Linux 2.6 only…

[Kníže Ignor]

V příští jaderné řadě to už nebude?

[David Watzke]

Asi jo, ale ta ještě neexistuje. Takže 2.6 only

[Michal Kubeček]

Vzhledem k tomu, že dnes nejspíš ani Linus netuší, kdy (a jestli vůbec) bude 2.7, těžko spekulovat, zda tam bude sysfs…

[trekker.dk]

Nebylo by lepší, kdyby si uživatel mohl nastavit, co tam chce mít?

[Michal Kubeček]

Výborně. Takže už jsme (nejméně) dva, kdo si myslí, že takhle by to bylo nejlepší.

[disorder]

to ma napadlo ihned ako niekto spomenul bookmarky. takto tam moze mat kazdy co chce a nie je to obmedzene len na mtab alebo co...

[VícNežNic]

Nebylo by lepší mít tam třeba bookmarky z Gtk fileselectoru? Přišlo by mi to užitečnější.

[Josef Kufner]

Na bookmarky není potřeba combobox, na to je lepší obyčejné menu.

[Michal Kubeček]

Přesně toho jsem se obával. Myslím, že by byla chybou se snažit za každou cenu přebírat i věci, které v Linuxu nedávají smysl. Nemyslím si, že mounting pointy jsou typicky adresáře, do kterých bude chtít uživatel často přecházet. Když už tam takový combobox chcete mít, co z něj udělat něco na způsob bookmarks - tj. seznam adresářů, které si uživatel sám vybere. Na začátku by tam mohl být dejme tomu jen jeho domácí a postupně by si tam přidával další (nebo odebíral). To bych považoval za řádově užitečnější funkci než možnost rychle přepnout na kterýkoli mounting point.

[D-Evil]

Jednu výjimku v užitečnosti zobrazování mounting pointů bych viděl, floppy a USB storage. Ale jinak souhlasim, že obecně je to skoro k ničemu.

[Michal Kubeček]

Prostě obecně výměnná média. Otázka je, zda je jsme schopni spolehlivě poznat. Na FHS-compliant systémech by to měly být podadresáře /media (doufám, že se teď nestanu terčem útoků FHS-haters :-) ). Nebo že by se ze seznamu mounting pointů vyřadily ty, které jsou v /etc/fstab a nemají tam noauto?

[Josef Kufner]

Jo, to by mohlo být rozumné, ale proč to nedát do bookmarků, jako hromádku generovaných položek a combobox zahodit?

[D-Evil]

To už je zase námět na další diskusi a nakonec by nemusela bejt špatná ani možnost volby. Ale nejdřív je potřeba vymyslet a realizovat obsah, pak se teprve můžeme bavit o formě.

[Michal Kubeček]

Já si zase myslím, že je vhodnější si napřed ujasnit, jak ten program má fungovat, a pak ho teprve začít psát. Ale možná jsem jen zaspal dobu a patřím do jiného století… :-)

[D-Evil]

No, na FHS by se to postavit určitě dalo a osobně to považuju za dobrej základ. Nejrozšířenější distribuce s tim problém zřejmě nemaj a zbytek by se ošetřil jinak. Failsafe možností může bejt třeba zjištění fyzickejch zařízení v /dev, který jednotlivý mountpointy reprezentujou, těch možností imho moc neni.

Naopak na fstab bych moc nespoléhal (možná spíš mtab), protože ve spoustě moderních distribucí se tahle část systému o připojování hotplug výměnnejch médií nestará, v případě USB disků to může bejt třeba ivman, nebo hotplug ve spolupráci s ručně napsanejma skriptama, případně např. KDE si to taky řeší po svym ve spolupráci s hotplugem.

[Michal Kubeček]

Naopak na fstab bych moc nespoléhal (možná spíš mtab), protože ve spoustě moderních distribucí se tahle část systému o připojování hotplug výměnnejch médií nestará

To nijak neodporuje tomu, co jsem napsal: za pevná by se považovalo to, co je v /etc/fstab a nemá to v parametrech noauto. Ostatní - tedy i to, co v fstab není vůbec - by bylo považováno za výměnné. Zdůrazňuji ale, že za vůbec nejlepší řešení považuji to, že by si uživatel sám vybral adresáře, které tam chce mít.

[D-Evil]

Jo, máš pravdu. Jinak co se týká toho, že by si uživatel moh sám vybrat, úplně nejlepší je imho provést "autodetekci" (třeba tak, jak jsme jí popsali) a v nastavení mu dát možnost změnit si to podle vlastní chuti (včetně individuálního seřazení).

[VícNežNic]

Nebylo by lepší zkusit je vyčuchat spíš HALem?

[D-Evil]

I to je zřejmě možnost, ale o HALu nevim vůbec nic (kromě toho, že existuje), takže jsem o něm nepřemejšlel.

[VícNežNic]

hal-find-by-capability --capability block

To vypadá docela zajímavě. Jenom to moc nekamarádí s věcma, co hardware nejsou. Například NFS oddíly.

[Michal Kubeček]

To je právě největší průšvih: že (skoro) co distribuce, to vlastní řešení automagického managementu výměnných médií. Momentálně to ale vypadá, že HAL má nejslibnější budoucnost, tak se to snad v dohledné době sjednotí…

[disorder]

s cistym svedomim mozem prehlasit, ze u mna nema buducnost ziaden ;)

ja ale nie som typicky uzivatel JXP Commanderu... :)

[Michal Kubeček]

Chce to chladnou hlavu. Já z podobných věcí také obvykle moc nadšený nejsem, ale když se na to podíváte objektivně, měl byste si přiznat, že klasické unixové mountování není pro práci s výměnnými médii na uživatelské pracovní stanici zrovna optimální model.

[disorder]

to som uviedol ako vlastny nazor a dovolim si povedat, ze nazor uzivatelov midnight commanderu :) ja si vsetko mountujem prikazom a /media som zmazal a fstab prepisal :)

a vobec sa neviem co v tejto oblasti leti a ako sa to pouziva ;)

[Michal Kubeček]

Vidíte, já nepoužívám ani ten midnight commander (no, možná tak jednou za měsíc až dva). A přesto považuji za velmi praktické, že stačí zastrčit flashdisk, chvíli počkat a můžu kopírovat (příkazem cp). A nemusím přemýšlet, jestli je to zrovna /dev/sda1, /dev/sdb1, /dev/sdc1 nebo kýho výra. Prostě to chce odložit předsudky a zabývat se praktickou stránkou věci. Aneb "Image je nanic, poslouchej žízeň."

[disorder]

ja mam flashdisk jeden a mam ho vo fstab a vzdy je to sda1 :) (a velmi casto ho nepripajam) ja to proste nepotrebujem. a bez mc by som neprezil, je to moj jediny file manager/FTP klient :)

[Michal Kubeček]

Možná to chce jen trochu rozšířit obzory. V jednom počítači mám SATA disk (tj. /dev/sda je on), ve druhém ne. Kromě flashdisku mám ještě foťák a čtečku paměťových karet (která se chová jako tři samostatné diskové jednotky). Takže ono to není vždycky tak jednoduché.

[disorder]

ked to niekedy bude problem, tak to budem riesit.

aj som v repozitari videl usbmount (automatically mount and unmount USB mass storage devices), takze to by som pouzil. ale na CD/DVD a floppy mechaniku nic take nikdy potrebovat nebudem :)

[Josef Kufner]

Místo "chvilku počkat" dávám přednost aliasu "mntsd" a nastavenému udev, aby vyráběl v /dev správné symlinky. Další mám třeba "mntcd"... a samozřejmě i jejich bratříčky s 'u' na začátku.

[mkoubik]

To je pravda ... pojďme uvažovat jako v microsoftu. Co udělá typický uživatel JXP Commanderu - stylem next-next-finish si nainstaluje nějakou user-frienly distribuci (s předinstalovaným JXP Commanderem) a předpokládá, že mu všechno bude správně fungovat. Otázka je, co takový uživatel očekává že bude mít v tom combo-boxu?

[Michal Kubeček]

Domácí adresář a výměnná média. Možná přimountované lokální win-oddíly (if any).

[mkoubik]

Je pravda, že do adresáře /proc/bus/usb moc často nelezu. Spíš jsem od toho čekal něco jako drives:/ v KDE.

[Michal Kubeček]

Přesně tohle jsem původně chtěl uvést jako odstrašující příklad toho, jak by to nemělo vypadat. Připadá mi to totiž jako klasická feature typu "je to sice nesmysl, ale uživatelé z Windows jsou na to zvyklí, tak jim to tam dáme, ať z toho nemají trauma".