Psát to v C?

3.3.2006 15:43 | Přečteno: 1921× | První linie

Dnes spíš jenom do diskuse. Ábíčko si slovy zadejte hodnotu vynucuje titulek zápisu, ale to je těžký něco vymýšlet, když zápis hodnotu nemá

Semtam (nebo také skoro pořád, záleží nakonec na úhlu pohledu) se porůznu na internetu objeví diskuse, zdali je vhodné psát uživatelské aplikace v Céčku nebo už tomu dáno odzvonilo a hodí se to jenom maximálně do kernelu (které už různé skupinky taky iniciativně začínají tvořit v lecčems). Není důvod to vyvolávat znovu, ale taky není důvod proč to neudělat

Po včerejší diskusi o ukazatelích v C jsem neodolal pokušení a dobrou půl hodinu jsem si s tím hrál, což se ukázalo jako docela dobrá zábava. Je hezké, jak lze v céčku poměrně elegantně a nenáročně dělat spoustu zajímavých věcí (může být odlišný pohled na to co je zajímavé). Na druhou stranu je škoda, že zdrojáky glibc jsou takové moc, no, praktické a není tam vždy zcela jasná myšlenka, jako by byla z nějakého hezkého školního příkladu

Každopádně z toho plyne, že správu paměti můžete dělat různými způsoby a na různých úrovních, přičemž z každého plynou nějaké ty výhody a nevýhody. Někde se ovšem soustředili na eleganci z trochu jiného hlediska a co do paměti (nejen) tolik možností nemáte, protože se o ní stará třeba něco trochu jiného. Je zase fakt, že nemáte tolik starostí. Nicméně je zase hezky vidět, že i malloc má nějakou tu režii, nad tím má nějakou tu režii to něco trochu jiného a tak dál, no, müže toho být hafo.

To by asi nerozhodovalo. Další zajímavá věc jsou GObjecty. Místo toho, aby byly objekty dané něčím trochu jiným, máte je napsané přímo v céčku, je do nich celkem hezky vidět a to i z vašeho programu, takže můžete dělat další zajímavé věci, které by jinde třeba tak hezké nebyly. Je zase fakt, že normální určení a použití třeba takových virtuálních metod je v C++ přeci jenom o trochu hezčí.

Ale abychom se k něčemu konečně dostali. Na jakou úroveň máme kdy jít? Vyplatí se nám vzdát se vlastní správy paměti a náhledu do všeho možného výměnou za pěkný jazyk, který nám všechny (možná) potřebné věci nabídne úhledně zabalené přímo v balíčku s interpretrem (zcela konkrétně to bude Python )? Nebo spíš při jakých příležitostech je to lepčí.

Když se podívám na všechny ty diskuse a na aplikace co tu v systému mám, moc mi to nesedí. Spousta grafických aplikací různé velikosti je napsaná přímo v C a přitom fungují docela hezky, stejně hezky jako ty co jsou třeba v C# a pod monem, třeba. A já do nich moc nevidím, jestli to dalo víc práce, jestli s tím nebo tím bylo víc problémů. Udělat hezké demo Gtk.TreeView se zdá být v C# snazší než v C, ale když se na to podíváte podruhé, tak je to nakonec stejné.

Nějak tomu chybí revoluční blogovací zápal, co? Jojo, když nemáte konkrétní věc/osobu co chcete naštvat/shodit, tak se bloguje hrozně špatně

       

Komentáře

[hm]

Přínos "vyšších" programovacích jazyků vidím já především v tom, že neskutečně zrychlují vývoj aplikací...

[VícNežNic]

Na to se právě ptám Protože když o tom tak přemýšlím, proč by nestačila nějaká hezká C knihovna?

[hm]

no já nevím, já vždycky když něco zkoušel psát v C, tak to bylo rychlé a efektivní a tak, ale vývoj (hlavně do nějakého použitelného) trval děsně dlouho, nemluvě o tom, když bylo potřeba něco přepsat od začátku... většinou to skončilo tím, že jsem to během pár dní přepsal do perlu

Ale třeba jenom neumím programovat (i když mě to celkem slušně uživí ) nebo tak něco...

[trekker.dk]

Ono asi dost záleží na tom, kolik toho člověk musí napsat sám a kolik najde v nějakých knihovnách.

[Kyosuke]

Ocaml, Ocaml...rychlost Cčka, jednoduchost skutečně vyššího jazyka...

Takový šikovný C++kař si ovšem poradí i s větším kanónem. Musí být ale opravdu hodně šikovný, aby to sekal rychle. Pro nás méně zdatné je tu SWIG a možnost kus napsat rychlý a zbatek rychle...

[VícNežNic]

SWIG, hm, jak spolehlivě a hezky to vlastně funguje? Někde jsem čet, že to používají i v Googlu, ale nejsem si jistý.

[Kyosuke]

Vyvinuli to v Los Alamos. Tam vždycky vyvíjeli věci, které spolehlivě fungují a naplňují lidstvo úžasem a bázní...

[VícNežNic]

To zní dobře

[Josef Kufner]

Na vysokourovnovych jazycich mi vzdycky desne chybi moznost hezky a pohodlne manipulovat se stringama. Zni to dost silene, ale v C je to celkem propracovana vec... i napric tomu, ze tam vlastne string neexistuje...

[Luboš Doležel (Doli)]

A právě proto používám C++: na běžné úkony high-level funkce, ale kdykoliv chci, můžu pracovat s daty přímo.

[Petr Zelenka]

Napodruhé k věci :)

Nedávno jsem narazil (no, vlastně to bylo při zkoušce :) na tzv. Format String Attack. To je tak, když je programátor líný (každý programátor je líný :) a místo printf("%s", str) volá printf(str). Jaké moc pěkné věci se s tím dají dělat si můžete přečíst třeba v tomto pdfku.

[VícNežNic]

To někdo opravdu dělá? Ja myslel, že je to dostatečně profláklé

[Petr Zelenka]

Netuším, třeba to byl jen takový typický školní příklad. Ale napsal jsem to sem proto, že mě vždycky dostane, co se s Céčkem dá dělat za psí kusy.

[Petr Zelenka]

Ani jsem se nestihl začíst, jak rána lopatou (nic ve zlém, asi je to mnou :) na mě zapůsobila druhá věta:

Ábíčko si slovy zadejte hodnotu vynucuje titulek zápisu, ale to je těžký něco vymýšlet, když zápis hodnotu nemá

Četl jsem ji asi desetkrát, a nic. Prozraď mi prosím, co znamená. Jinak mi to nedá spát.

[VícNežNic]

To máš z toho, že nemáš blog

[Petr Zelenka]

Sakra, tak tím to je... No, ale blog se mi kvůli tomu zakládat nechce. I když "tenhle blog vznik proto, abych časem pronikl do tajů češtiny a snad, někdy, byl schopen porozumět blogům Honzy Bartoše..." nezní zle :)

[VícNežNic]

Pro ten druhý důvod by to ale byla jenom marná snaha Nedávno jsem znova četl první zápisky co jsem tu napsal a už jim taky moc nerozumím

[Petr Zelenka]

Hmm, tak teď už nezbývá nic než abys mi to prozradil :)

[VícNežNic]

Ta věta vznikla až po napsání celého textu, dodatečně. Nenapsal jsem totiž žádný titulek článku a ábíčko mělo blbé poznámky. A on mě žádný hezký titulek nenapadl, tak mě to trochu naštvalo

[User682]

zdravim,

napiste, co chcete primo napsat. toto vice pomuze.

nicmene graficke aplikace muzou byt rychle skoro v cemkoli.

osobne:

- objektovy jazyk

- java

- xml mapovani hodnot a to same xml mapujete na model pro grafiku

- jadro aplikace je pro vice vystupu

- pamet dneska je za pakatel, to same rychlost.

- hotove knihovny

- rychlost je otazkou dobreho kodera

- modely - uzivejte je. skutecne. a nevymyslet zbytecne.

- udalosti - taktez super

- .NET je hezky, ale nema smysl dohanet casem microsofty. lidi stejne budou chtit spesl featury, ktere bezi pouze na win. zapomente asi moc na kompatibilitu. nema smysl resit kompatibilitu Win a Lin.

- rychlost nereste. tak ci tak je rychlost uzivatele priplizna jako reakcni rychlosti ridice v aute. a aplikace je tedy potom rychlejsi.

overeno. ale zverejnim casem, predevsim navrhove vzory aplikace a kodu. stalo me to par mesicu prace. predevsim ty desktopy.

bye gf

[VícNežNic]

Neptám se na nic konkrétního, spíš jsem chtěl obecnou diskusi na téma výhod a nevýhod. Ale když už tak konkrétně, tak ještě konkrétněji. Vím, že existuje něco jako Java/GTK, ale nevím jak dobře je to použitelné. Stejně tak nevím, jak dobře jsou v tom použitelné ostatní složky GNOME desktopu (co multimédia, GStreamer? mohl bych napsat applet do panelu? GConf?).

Tohle navíc ilustruje o čem mluvím, Java je velký samostatný balík, kde je sice všechno co je potřeba, ale když chcete níž nebo něco do okolního světa, je to problém.

[User682]

neni problem komunikovat s okolnim svetem. zalezi, co tedy delate.

UI-Gtk - vice ci mene je. presneji se to vylepsuje a dost v 1.6 jave. ale jedu na UI od Sunu. zatim GTK-UI nechavam uzrat. jinak jsou ostatni UI hodne pouzitelne. min v 1.5 jave.

osobne mi blblo s compierem gtk-ui s tim, ze textova pole nekdy az prilis zmensila. nicmene to chce sledoval zmeny a podle me sun s gtk hodne pocita, alespon podle zmen.

zalezi na delce projektu. sice je treba dana technologie nepouzivana, ale az to dovyvinete, tak bude. a na tom bych stavel. at si ostatni lepi aplikace v html a textu, vyuzivaji prapodivne sablonovaci systemy a grepuji obsah, kdyz dneska jedu na XML ,XSLT, a XPath2.0.

komunikace s okolnim svetem - zalezi, co je potreba. osobne pouzivam nektere veci, co nejsou pouzitelne od sunu a nahrazuju je jinymi. viz parsery xml od sunu. osobne komunikuju pres nejake xml a nezavadim jine formaty.

asi priklad: delam ted generovani certifikatu pro uzivatele z database pres webove sluzby. takze komunikace s okolnim svetem tu je. od toho ty webove sluzby a idealne xml je.

hodne zalezi, co chcete. osobne se priklonim, ze treba integrace s okolnim svetem tu prilis neni jeste idealne rozvinuta. implmentujte si ji.

asi jako priklad udam pretahovani souboru do nejake aplikace. chce to si to asi dopsat. i kdyz to treba chodi na jinem OS.

osobne nejak jsem zatim nenarazil na to, ze by neco neslo ci nestacilo. vzdy jde nejak vyjet v modelu ci tridach o meta nahoru. a neni -li to, tak si to doimplementujte.

skutecne to chce konkretizovat. idealne zacit hledat pouzitelne komponenty a pripadne pocitat, co me bude stat implementace.

osobne delam dost swing-y. ale primo konkretnim desktopum a implementaci namiru temto desktopum se vyhybam. jinak se utopite v mori optimalizaci a tudy cesta prilis nevede.

i kdyz minimalne nejak e to drag&drop mezi aplikacemi a pokrocilejsi funkce s clipboardem to bude chtit doimplementovat.

zkuste jit cestou webovych sluzeb. idealne xml. ale nebal bych se treba toho, ze aplikaci nekam podhodim data a ona nasloucha a zmeny v jejim 'virtualnim datovem systemu' si zaregistruje a neco udela.

prilis konkretne asi neporadim. vice vam pomuze asi se mrknout, jak funguji modely v jave a xml. ono mozna ani nejde o to, jak ten jazyk a knihovny vypadaji a kolik zere pameti. ale jak je navrzen. po par vasich pocatecnich travicich bolestech vam to usetri hodne casu. chce to se rozhodnout, kam se chcete radit. mezi lepice a busice kodu nebo mezi navrhare a kodera zaroven. to druhe je podle me zajimavejsi.

to je neco jako s databasemi. ono ani nejde o to, co jste do db ulozil za data. ale jake logiky tam mate ulozeny.

asi vam moc neporadim. ale myslim, ze predposledni 2 odstavce naskytaji otazky, ktere rozhodnou. musite je vsak najit sam.

bye gf

[VícNežNic]

Swing je docela pěkná vymyšlenost. Teď jsem se i někde díval na prezentaci nových možností co se plánují a nevypadalo to zle. No, ale na tom nesejde.

Trochu konkrétněji by to taky šlo. Co se týče webových služeb a všech těch věcí okolo, od spousty z toho mě hodně odrazuje co všechno to s sebou vleče. Ale jak jenom jednoduše realizovat propojení swingového klienta a javového serveru, aby z toho nebyla obrovská příšera pro jejíž nasazení bude potřeba nějaký ošklivý aplikační server. Komplikovat s XML se to dá, jenže proč, na obou koncích je javová aplikace a nezdá se, že by se na tom něco mělo měnit. A u serveru co by používal http něco mě trochu trápí nutnost posílat zprávy na oba směry a to kdykoliv. Všechno se samozřejmě dá nějak řešit.

[Lukáš Zapletal]

JavaGTP = SWT = Eclipse. Což už je "docela" použitelný.

[paskma]

Každý se musí najít. Chce to napsat netriviální prográmky v různých jazycích. Já jsem byl postupně nadšený z VB, OP, C/++, Ady, Javy/C#. Každé nadšení mi něco dalo. Momentálně pokukuju po Pythonu/Ruby, ale sedí mi spíš silnější typová kontrola, tak pořád nevím .

Osobně si myslím, že čisté C už je opravdu trochu mimo (pro "běžné" použití), C++ už považuju za použitelnější kompromis. Osobně si též myslím, že kvalitní runtime (žádné hloupé segfaulty, ale výjimky, a GC) ala C#/Java obvykle za nějakou tu režii stojí.

[llook]

Kdysi bývalo zvykem psát aplikace v C nebo Pascalu a části kritické na výkon potom přepisovat do assembleru. Na dnešních strojích si už ale můžeme dovolit psát aplikace ve vyšších programovacích jazycích a kritické části přepisovat do nižších jazyků.

V céčku můžeš blbnout s ukazateli (když tě to baví), python má zase jiné výhody. Výkon bych do toho netahal, optimalizovat se dá vždycky, důležitější je, v čem se ti píše líp.

Když jsem viděl helloworld k wxWidgets pro C++ (se všemi těmi #ifdef a #ifndef) a to samý ve wxPython, tak mi připadal vývoj v pythonu jednodušší (i když třeba ne tak napínavý ).

[VícNežNic]

Výkon mě nijak extra nežere a mám tu věci napsané celé v Pythonu/Javě/C# a bůhvíčem dalším a funguje to dost hezky, to je mi jedno. Zaujala mě právě integrace se zbytkem světa. V C dosahnu na skoro všechno přímo a bez nějakých obstrukcí, zatímco všechny tyhle další uváděné jazyky (jazyk asi není přesné, měl bych říkat spíš prostředí nebo něco takového?) mi tam vrší něco navíc (C++), nebo jsem tam rovnou do čehosi uzavřen (Java).

[Miloslav Ponkrác]

Dotaz: Co Vám tam vrší C++? V C++ máte ty samé prostředky, co v C a ještě řadi věcí navíc. Co Vám brání si na cokoli sahat přímo?

[VícNežNic]

Kdybych to nepoužíval, kde je pak to C++?

[Miloslav Ponkrác]

Můžete mi prosím Vás napsat, co Vám v C++ brání si na něco sahat přímo? A co navíc v C++ nemůžete používat, abyste nepřišel o to přímé sahání? Já osobně používám C++ od té doby, co ho pan Stroustrup vymyslel a nestačil jsem si všimnout, že by tam něco takového bylo, tak prosím poučte neznalého.

[Luk]

Ještě bych dodal, že není jen jedno C. Máme třeba původní K&R C, pak je např. ISO C90 nebo ISO C99. Hlavně to poslední převzalo hodně věcí z C++, ale přitom je to pořád C v plné parádě. O rozšířeních jako GNU C nemluvě. A takové kompilátory jako GCC umožňují vybrat si, které C mají zpracovávat.

[Miloslav Ponkrác]

Ono je ve skutečnosti mnohem více C! Dám vám úplně jednoduchý příklad, zkuste si přeložit linuxové jádro standardním kompilátorem C, které jede tvrdě podle standardu C a nepřipouští extenze. A je jedno, jestli se budeme bavit o standardu K&R, nebo C90, nebo C99. Velmi rychle přijdete taky na to, že spousta GPL projektů se vlastně standardním kompilátorem jazyka C nedá vůbec přeložit.

[Luk]

To samozřejmě vím. Proto jsem také uvedl příklad GNU C, protože mnoho programů některé věci z tohoto rozšíření využívá.

I když zrovna to linuxové jádro je ještě relativně konzervativní, je skoro celé napsané podle C90. Mnohé jiné věci jsou v tomhle horší.

[Miloslav Ponkrác]

Jasně, to je to slovo relativně a to slovo skoro. Já osobně znám jen velmi velmi málo programů, které lze přeložit standardním kompilátorem jazyka C nez proprietárních extenzí, ať už v jakékoli normě Céčka. Svým způsobem je standardní jazyk C prakticky nepoužívaná věc, která je a vždycky byla na vyhynutí.

[VícNežNic]

Doufám, že se mi nepovedlo říct, že by tam bylo něco co by mi v tom bránilo, to by nebyl dobrý krok Ale ty věci co jsou v C++ navíc mohou dost zásadně měnit chování progamu, takže aby je bylo možno používat je třeba je znát a přitom jsou dány jazykem, takže si tedy troufám říci, že v C++ je navršeno něco navíc (oproti C). Samozřejmě, cokoliv navíc z tohoto pohledu znaméná… hm, něco navíc

Neříkám ani, že se to musí používat všechno. Náhodou jsem nedávno natrefil na seznam toho co se v Mozille z C++ z důvodu kompatibility zapovídá a říkal jsem si co jim z toho tedy ještě zbylo

Tohle už doufám není tak pobuřující.

[Miloslav Ponkrác]

Já bych nesouhlasil ani s tímto. C++ není C + něco navíc, i když se to tak na první pohled může zdát. Některé věci v C++ jsou jinak oproti C a někdy ve výjimečných případech tentýž zápis v C a C++ znamená odlišné věci. Existuje plno bludů týkajích se C a C++ a jedním z nich je blud, že "C++ je C plus něco navíc". Nůžky mezi C a C++ se navíc rozevírají a třeba C99 obsahuje spoustu věcí, které jsou v C++ zcela odlišné. Další obvyklý blud je, že "pole a ukazatele jsou v C totéž" a vůbec spousta dalších ptákovin. Snad ještě jedno tvrzení mě dokáže spolehlivě naštvat a to tvrzení, že "C++ je jen C s třídami", další z ptákovin.

Co se týká toho seznamu v Mozille, tak jsem to také četl. Pochopil jsem, že snad dvě třetiny omezení je tam proto, že to nezvládá HP-UX, a něco proto, že to nezvládá Applovský překladač.

Ale na Mozille se mi líbí, že vlastně nedělá nic jiného, než Microsoftí COM model, jenže na rozdíl od Microsoftí implementace to není jazykově nezávislé, ani distribuované.

[VícNežNic]

Tak já už nevím jak to mám říct

[dad]

aplikace se pisi vlastnimi prostredky - jestlize se chci zivit psanim aplikacniho software. A ty prostredky si vytvari softwarova firma sama.

Vpodstate je dnes u aplikace potreba servrova cast, klient s vlastnim interpretrem pro vytvareni dialogu "on-the-fly" a interpreter pro vystupy.

Pro servrovou cast si vytvorite vlastni jazyk nejlepe jako definice v C a michate kod sestavajici z definic a ciste C. Samozrejme, ze se pouze v C nic nepise, kvuli tomu nebyla C vytvorena, jejim ucelem je napsat si ty vlastni vyvojove prostredky. Napr:

_GET_MEM(p) ... namisto allocu _TF(FIELD_1,FIELD_2) ...transfer obsahu databazovych poli apod.

Client asi musite napsat v C++ protoze slusne toolkity jsou jenom v tomto jazyku. Samozrejme, ze 2/3 totho kodu bude cista C, ale to vas nemusi vzrusovat, proste tem souborum naparite .cpp koncovku.

Jako interpreter v clientu pouzijete vlastni, ktery si vyrobite za pomoci lexu a yaccu. V tom clientu totiz nepotrebujete jako interpreter takove delo jako perl.

No a pro vystupy pouzijete perl, ktery bohate vyuziva C knihovny, ktere mu zpristupnite pres swig.

Tedy, vpodstate budete pouzivat C, ale vlastne nebudete. Tak jednoduche to je.

No a samozrejme, ze je neustale treba pri tom vsem trenovat logicke mysleni a za tim ucelem doporucuji si vytisknout prispevky goldenfishe a pred spanim si to procitat a snazit se pochopit, co chtel rici )

[VícNežNic]

Že bych si kvůli němu kupoval tiskárnu? No, nevím

[springer]

tiskarnu si musite koupit tak jako tak - pro testovani tech vystupu, aby to vase software nedozravalo u zakazniku

[User682]

pokud nechapete, co jsem psal, tak neni od veci se zeptat.

ja jsem tak nejak nepochopil vas posledni odstavec a nevim, zda to je pouze bonmot anebo i nejaky duvod tvrzeni zaroven. vite, ono neni ani prilis cilem, toho co pisi, aby to clovek pochopil hned. jsou to znalosti za mesice. a pokud budete neco resit za par mesicu, tak mozna ten muj prispevek muze pomoci.

jinak musim priznat, ze jdete dobrou cestou. predevsim lex a yacc jsou hodne dobre cesty.

bye gf

[springer]

zdravicko pane kolego, bylo to pouze takove zertovne "nakopnuti", protoze i kdyz ja tak trochu chapu co chcete rici (po letech treninku), presto si myslim, ze vase "utrzkovita rec" je skutecne pro neznale narocna. To neznamena, ze nemate pravdu. Proste jenom pozoruji, ze se to nelepsi a myslim si ze je to skoda.