Učím se C++

7.4.2009 14:25 | Přečteno: 2862× | GNU/Linux

Jsem sice přesvědčený, že Java je skvělý programovací jazyk a je to také směr, kterému se chci i do budoucna věnovat. Ale na druhou stranu si připadám ještě příliš mladý, abych zůstal jen u jednoho jazyku* . Takže se teď učím i C++.

Vybral jsem si tento jazyk kvůli rozšířenosti a objektovosti … a taky proto, že mi přišel 1337 . V knížce Jádro systému Linux jsem se dočetl o technologii POSIX Message Queues, přišlo mi to zajímavé a tak jsem se rozhodl, že jeden z mých prvních programů v C++ bude sloužit k posílání zpráv pomocí této technologie.

Jedná se v podstatě o jednoduchý jednosměrný chat, více o programu se dočtete tady: Posílání zpráv pomocí fronty (POSIX MQ) a zdrojové kódy si můžete stáhnout z mercurialu (návod).

Program kupodivu dělá to, co od něj chci, ale určitě by to šlo napsat všechno mnohem líp. Takže pokud budete mít trochu času a stáhnete si zdrojáky, uvítám vaše připomínky.

*) nepočítám věci jako VisualBasic, PHP, JS nebo … SGP Baltazar

       

Anketa

Obrázky

Komentáře

[kozzi]

JJ C++ je skvělý jazyk. Jinak doporučuji knížku Mistrovství v C++.

[xkucf03]

Tu přesně mám ale je strašně tlustá, ještě jsem se jí celou neprokousal.

[vm]

Tak pro začátky bych spíš než mistrovství doporučil Eckela: http://mindview.net/Books/TICPP/ThinkingInCPP2e.html - příjde mi to minimálně o dost čtivější.

Po něm Meyers - Effective c++, more effective c++ a effective STL. A kniha kterou používám nyní nejčastěji je určitě Josuttis: The C++ Standard Library

[dad]

ctenari vzali na vedomi, ze vm je v c++ borec

[menphis]

ctenari vzali na vedomi, ze dad je blbec

[pozortucnak]

Tak to není jedinej... Dobrovolně se přidávám... Mimochodem nevíte nekdo něco o jazyku D ??

Jenak mě v anketě chybí jazyk Lua, zrovna o něm na root.cz vychází seriál...

PS: Programovat neumím! Jediný program kromě Pascalu co nas učili na škole je hello world v tcl...

[Let_Me_Be]

V principu je jazyk D zjednodusenou variantou C++. Stoji primarne na zjednoduseni v oblastech se kterymi maji problemy kompilatory. Vytvari ho relativne silna firma (ktera vytvari kompilatory i pro C/C++).

Ale uprimne, nevybiral bych si ho jako jazyk k nauceni. To uz radsi Eiffel (coz rozhodne neni spatny jazyk do zacatku).

Jinak chce se to rozhodnout. Budto jit do vicemene statickych jazyku - C, C++, Java, Pascal... nebo silne dynamickych Javascript, Python, Ruby.

[Ajka]

A co objective-C?

[xkucf03]

Jak (moc) se liší od C++?

[Let_Me_Be]

Dost. Objective C je pomerne cisty objektovy jazyk (vyrazne dynamictejsi nez C++). Ale na vyuku bych si ho nevybral.

[podlesh]

Lepší otázka by byla: co má společného s C++? Odpověď zní: C. Jo a v obou je něco co se nazývá "objekty".

[xkucf03]

Díky. A blíž k Javě má který?

[Martin Mareš]

C++, protože Java je svého druhu pokus o napravení C++. Objective C má v mnohém blízko spíš ke Smalltalku.

[podlesh]

Jak v čem, já bych řekl že k Javě má blíže Objective C.

[cronin]

Jednoznacne ObjectiveC.

[pozortucnak]

Nekolik (asi) blbejch dotazů...

Je možné v D nebo v objective-C používat C++ knihovny?

A jak se C++ knihovny dají použít v C?

Jak je vůbez možné že se knihovna vytvořená v Javě dá používat v C++?

Četl jsem že je možnost například knihovny qt nebo wxwidgets požívat i v jazycích objective-C, D...

http://wxd.sourceforge.net/

http://code.google.com/p/qtd/

http://www.equeltech.com/projects/qtobjective-c-bridge/

Co si mám představit pod pojmem wrapper?

[depka]

wrapper je presne to co rika slovnik - obal, napriklad sada funkci nejake knihovny zabalena do tridy jako treba gtkmm

[Let_Me_Be]

Knihovna (v binarni forme) ma presne danou strukturu (podle dane platformy) tudiz je uplne jedno v jakem jazyku je implementovana.

Muze byt trosku problem pokud knihovna exportuje nejake rozsirene veci, kterym rozumi jenom nejaky konkretni jazyk. Typicke napriklad u C++ -> C kde C++ pouziva name mangling a je nutne symboly ktere maji byt dostupne i pro Cecko pomoci extern "C";

[Milan Horák]

Já si pořídil Programovací jazyk C++ pro zelenáče od Petra Šalouna.

[dementni.lojzik]

Jestli umis Javu, tak doporucuju C++ for Java Programmers, da dobry prehled o zakladech C++, ale predpoklada znalost Javy, takze se nemusis zdrzovat ctenim kaiptol o tom, co je to objekt a pod.

[=^..^= AmigaPower®]

V anketě mi chybí "Karel"

[Václav HFechs Švirga]

Me ruby, protoze je to jedine v cem ted rubam :P (kdyz zrovna nechlastam samozrejme ).

[kozzi]

JJ a mě KTurtle . Ale na Karla rád vzpomínám

[Luk]

Náhodou, Karel je docela dobrá věc pro úplné začátečníky. Naučí se základům algoritmizace bez nutnosti se učit nějaký složitý jazyk.

[kozzi]

JJ, však já neříkám opak. Sám sem na Karlovi začínal.

[Luk]

Myslel jsem tím, že se na něj dá vzpomínat i z jiných důvodů než z čisté nostalgie

[kozzi]

Aha, tak to jo

[Ladicek]

Hnal bych na Karla všechny vysokoškoláky, kteří neumějí rekurzi. A že je jich požehnaně! To by, pravda, nebyla nostalgie, proč by na něj vzpomínali, ale čirá hrůza

[petr_p]

Rekurze bez razantního omezení vstupu je na x86 hodně špatný nápad.

[Ladicek]

Co to?

Jednak myslím, že programovat některé datové struktury bez rekurze je zábava pro vraha, a jednak myslím, že tail cally lze praktikovat i na x86

[petr_p]

Bavíme-li se stále o C(++), tak zjistíme, že zásobník, tak jak se dnes praktikuje, může velmi rychle dojít.

[Ondrej 'SanTiago' Zajicek]

Neni moc duvodu, proc by mel zasobnik dojit driv nez halda. V adresnim prostoru maji oba mista dost, a fyzicke stranky se, tipuji, prideluji celkem bez ohledu na to, zda se jedna o zasobnik nebo haldu. Oboje muze byt omezeno ulimitem, ktery ale v obou pripadech je mozne nastavit na unlimited.

Akorat si nejsem jist, zda proces nekdy uvolnuje stranky, ktere mu jsou pridelene pro zasobnik.

[Ivan]

Bohuzel to tak neni. Na linuxu mate 4 mega na stack. Pak nasleduje 1 zamcena stranka, na kterou kdyz slapnete tak naspaduje SEGFAULT. A za touhle strankou pokracuje stack dalsiho vlakna. Na FreeBSD je to tak ze 1. "hlavni" vlakno ma 16MB stack a dalsi uz dostavaji po ctyrech. Vsechno je to ale samozrejme konfigurovatelne.

 

[Martin Mareš]

Program dostane tolik zásobníku, o kolik si požádá. Na Linuxu (i386/amd64) defaultně 8MB, ale může si zavolat setrlimit() a přidat si.

[petr_p]

Kdysi jsem s tím dělal nějaké pokusy a vyšlo mi, že měnění velikosti zásobníku za běhu procesu moc nefunguje. Asi se na to podívám znovu.

[Ondrej 'SanTiago' Zajicek]

> Bohuzel to tak neni. Na linuxu mate 4 mega na stack

Coz je prave ten limit nastaveny ulimitem. Kdyz pred spustenim programu zadate 'ulimit -s unlimited', tak tam ten limit nebude.

[Ivan]

Nene, vas stack konci tam, kde zacina stack dalsiho threadu.

 

[Martin Mareš]

Pokud chcete (mermomocí) používat thready, stačí místo setrlimit() zavolat pthread_attr_setstacksize().

[Ondrej 'SanTiago' Zajicek]

No tak si to zkus:


 

test.c:

#include <stdio.h>
#include <stdlib.h>

int
recurse(int i)
{
        if (i < 10000000)
        {
                return 1 + recurse(i+1);
        }
        else
        {
                int j;
                printf("Hluboko\n");
                scanf("%d", &j);
                return j;
        }
}

int
main(void)
{
        int j = recurse(0);
        printf("Rv %d\n", j);
}


 

 

feanor:~$ gcc  test.c -o test
feanor:~$ ulimit -s unlimited     
feanor:~$ ./test
Hluboko
1
Rv 10000001


 

Zabrana pamet na stacku kolem 500 MB.

[Ondrej 'SanTiago' Zajicek]

> A za touhle strankou pokracuje stack dalsiho vlakna

Mimochodem, tusite nekdo, proc na Linuxu nejsou vlakna implementovana tak, ze by bylo kazde v odlisnem adresovem prostoru, pouze by sdilela vsechny adresove segmenty krome stacku (a pripadne prostoru pro thread-specific variables)? Respektive, zda by takova implementace mela nejake vyznamne nevyhody? Krom evidentni nemoznosti sahat z jednoho vlakna do stacku druheho (coz je IMHO stejne dost prasarna). Obecne by context switch mezi vlakny ve stejnem adresovem prostoru mohl byt rychlejsi, ale opravdu tomu v Linuxu tak je?

[Luk]

Mimochodem, tusite nekdo, proc na Linuxu nejsou vlakna implementovana tak, ze by bylo kazde v odlisnem adresovem prostoru, pouze by sdilela vsechny adresove segmenty krome stacku (a pripadne prostoru pro thread-specific variables)?

Tipuji, že čistě proto, že to prostě někdo implementoval takhle. Oddělené adresní prostory pro zásobníky by podle mého neměly být v rozporu se specifikací v POSIXu, čili nevidím jiný důvod, proč se používá zrovna tato implementace.

Respektive, zda by takova implementace mela nejake vyznamne nevyhody?

Měla by o něco málo větší režii při vytváření vlákna, ale je otázka, nakolik by to vadilo (už tak je režie vytváření vláken výrazně větší než na Windows; naopak režie vytváření procesů je podstatně nižší - skoro řádově - než u Win).

Obecne by context switch mezi vlakny ve stejnem adresovem prostoru mohl byt rychlejsi, ale opravdu tomu v Linuxu tak je?

Rychlejší je. Nevím o kolik (to by se musel změřit), ale každopádně se při přepínání úloh se sdíleným adresním prostorem nenačítají tabulky stránek. Jde ovšem o to, jaká je v praxi pravděpodobnost, že dvě po sobě následující naplánované úlohy jsou dvě vlákna téhož procesu.

[Martin Mareš]

Já myslím, že sahat na korektně zamykané proměnné na zásobníku jiného vlákna je zcela korektní.

Jinak přepnutí kontextu včetně stránkovacích tabulek je na většině procesorů podstatně dražší než bez nich. (Zejména na i386 a spol., které nemají MMU kontexty, takže při přepnutí tabulek procesor přijde o obsah TLB.)

[Luk]

Já myslím, že sahat na korektně zamykané proměnné na zásobníku jiného vlákna je zcela korektní.

Jenže jde o to, proč to vůbec dělat. Nenapadá mě nic rozumného, k čemu by to bylo dobré.

[Martin Mareš]

Situací, kdy by se to mohlo hodit, je spousta. Třeba tato: Mějme pracovní vlákno, které přijímá nějaké požadavky, jež mu padají do fronty, a odpovídá na ně (fronta je při tom nějaký patřičně uzamykaný seznam). Pak mějme nějaké jiné vlákno, které si chce od toho pracovního něco nechat spočítat a počkat, až to bude hotové. Vcelku přirozený způsob, jak to udělat, je založit si požadavek jako svou lokální proměnnou (tedy na svém zásobníku), zalinkovat ho do fronty a počkat, až se vrátí. Mezitím na něj kouká pracovní vlákno.

[Luk]

Toto je zrovna věc, kterou bych řešil jinak. Buď bych si danou věc spočítal přímo v původním vlákně (pokud by nebyly nějaké zvláštní požadavky, například na nějaká data, která má k dispozici pouze pracovní vlákno), nebo bych požadavek vytvořil na haldě.

[Michal Kubeček]

To ale není podstatné. Podstatné je, jestli specifikace POSIX threads uvádí, že není korektní přistupovat k obsahu zásobníku jiného threadu. Pokud to tam není napsáno - a nevzpomínám si, že bych tam něco takového viděl - pak to musí být možné.

[Luk]

Specifikace o tomto vůbec nehovoří, ani přesně neupravuje, jak má vypadat sdílení paměťového prostoru. Sdílený prostor (obecně) pouze "předpokládá", což lze vyložit jak jako nutnou podmínku, tak i jako něco, co je obvyklé.

[Martin Mareš]

Ale jistě, dá se to řešit i mnoha a mnoha dalšími způsoby, ale i ten, který jsem popisoval já, je smysluplný a nevím o tom, že by odporoval jakékoliv specifikaci. Vy snad ano?

[Luk]

Vy snad ano?

Také o ničem takovém nevím.

[Ondrej 'SanTiago' Zajicek]

> Já myslím, že sahat na korektně zamykané proměnné na zásobníku jiného vlákna je zcela korektní.

Korektni to sice je, ale asi bych se tomu radsi ve vetsine pripadu vyhnul. ;–)

[JS]

To by pak asi nemelo smysl rozlisovat mezi vlakny a procesy, ne?

Jinak, treba na zSeries procesu (ktery vychazi ze System/360) hardwarovy stack puvodne nebyl, a proto se treba v z/OS nepouziva. Misto toho tam jsou instrukce na ulozeni vicero registru do pameti. Vysledek je, ze zasobnik muze byt nesouvisly, a tedy teoreticky tam s pretecenim zasobniku jednoho vlakna nejsou problemy.

[Ondrej 'SanTiago' Zajicek]

Proc?

[zde]

C++ urcite neni ani trochu 1337.. nauc se radeji perl.

[dad]

perl se hodi tak max. pro 10 % populace, tedy pro lidi, kteri nemaji problem s tim, ze k cili vede nekolik cest. Lide , ktere nevysiluje svoboda svou neustalou nutnosti se rozhodovat. Pro lidi, kteri potrebuji ruznorodost, aby mohli kombinovat nove cesty, pristupy, reseni. Perl je narocny, protoze je mnohotvarny, nesvazany, chaoticky.

Vaclav Klaus nenavidi perl.

[Matlas]

jak vis? :)

[Ladicek]

Chápu, že ekonomická krize dopadá na nás všechny, ale opravdu si myslíte, že dělat ajťáckou variantu Petra Novotného je alternativa, která vám zajistí živobytí?

[pasmen]

K většině cílů vede několik cest, takže kde je problém?

[pc2005]

Bash, Pascal, C a assembler . Jo a teď mě ještě napadá jazyk konzole programovacích robotů (nejblíž to je k hodně ořezanýmu Basicu) .

[pc2005]

*programovatelných

[Milan Horák]

Kontrolní otázka: Čím se liší POSIX MQ od DBus?

[Luk]

Asi jako letadlo kategorie ultralight od obřího dopravního letounu. POSIX MQ je jednoduchá a nenáročná technologie, která umožňuje posílání zpráv mezi procesy (případně v rámci procesu) na jednom stroji. Kdežto D-Bus je složitá a rozsáhlá technologie, která umožňuje posílání zpráv mezi objekty v procesech běžících na stejném stroji, ale i na různých strojích. POSIX MQ je u Linuxu součástí jádra (pokud se zakompiluje), kdežto D-Bus běží jako samostatný proces a potřebuje příslušné knihovny. POSIX MQ je komunikace typu 1-to-1, kdežto D-Bus je obecně 1-to-n. A tak dále...

[Milan Horák]

Děkuji velmi pěkně.

[Ivan]

Dalsi rozdil je v tom, ze MQ je implementovano pres syscally, takze kdyz neco resite tak staci spustit lsof, strace, dbg a hned vite kdo na koho ceka a muzete z toho usoudit proc. U D-BUS nezjistite vubec nic, anebo je to velice slozite.

 

[Kvakor]

nebo … SGP Baltazar

Tak malé děti sem snad nechodí ... nebo ne?

[xkucf03]

Každý byl jednou mladý Já jsem začínal v DOSu, s quick basicem a právě tím Baltazarem, ale spíš než programování to bylo hraní.

[Kvakor]

Hmm, tak jsem zapátral, a on je Baltazarar mnohem starší, než jsem čekal. Já ho poprvé viděl až kolem roku 2000 (dokonce mám pocit, že na Invexu), ale podle Wikipedie existovala DOSovská verze už v roce 1993.

[rastos]

nebo … SGP Baltazar

Tak malé děti sem snad nechodí ... nebo ne?

V posledných týždňoch som mal možnosť si na to siahnuť a vyzerá, že je to Turing-complete. Má to premenné, konštanty, celé a reálne čísla, reťazce, bitové a logické operátory, riadiace štruktúry, možnosť definovať funkcie, knižnicu matematických funkcií, prácu so súbormi, ... Existuje C# verzia, ktorá má objekty, podporu pre DirectX, .NET, ...

Takže by som to až tak nezhadzoval.

[rastos]

Takže by som to až tak nezhadzoval.

Vlastne by som rád niečo také videl pod Linuxom.

[xkucf03]

BTW: jsou mezí vámi tací, kteří postupovali směrem Java → C++, nebo jste se všichni učili nejdřív céčko a pak až Javu?

Učit se C++ je docela dobrodružné , ale všechno tam dá mnohem víc práce. Už jen když srovnám knížky Mistrovství v C++ a Java: Programujeme profesionálně – obě jsou přibližně stejně tlusté, ale je dost velký rozdíl, jaké programy po jejich přečtení člověk umí vytvářet v C++  a jaké v Javě (gui, tisk, xml, databáze, corba…). Ale neberte to jako rýpání, jen taková poznámka na okraj doufám, že mě to céčko nepřestane bavit a bude to k něčemu dobré.

[kozzi]

No tak to je spíš způsobeno, tím jak je knížka napsána. Si můžeš sehnat knížko o programování c Qt4 a hned tam máš gui,xml,databáze,opengl,... . A možná bude i tenčí než to mistrovství v C++.

[Ladicek]

Nejdřív Pascal (zlatý!), pak Céčko, pak Java, pak C++ teoreticky (bez jediné napsané řádky kódu, ale jsem to schopný číst, pokud nejde o nějaké zběsilé šablony) a teď sbírám odvahu na C++ prakticky. Před časem jsem se v jedné diskusi ptal na doporučenou literaturu a vyšel mi z toho asi nejlíp ten Stroustrup, tak nevím, uvidíme.

[xkucf03]

ad čtení – přijde mi to, nebo se fakt C/C++ fakt snáze píše než čte? Připadá mi, že po pár hodinách studia jsem v tom schopný napsat program, který nějak funguje, ale abych byl schopný číst zdrojáky někoho jiného mi to často nestačí, často narážím na konstrukce, které neznám, které jsem zatím nepotřeboval – tohle se mi v Javě nestávalo ani na začátku.

[Luk]

To je dáno tím, že je syntaxe C a C++ výrazně volnější než syntaxe Javy. Některé konstrukty a způsoby psaní kódu se sice silně nedoporučují (právě pro nesrozumitelnost, i když třeba z funkčního hlediska je všechno v pořádku), ale stejně je leckdo zhusta používá.

[podlesh]

Nejenom že se to nezdá, je to dokonce záměr a hlavní důvod, proč se nakonec Java tolik rozšířila. A proč se tolik drží, přestože je toho tolik ke kritizování...

[Deleted [8409]]

Toto zažívám s Pythonem :)

[Luk]

jsou mezí vámi tací, kteří postupovali směrem Java → C++, nebo jste se všichni učili nejdřív céčko a pak až Javu?

To jsem třeba já. Nejdřív jsem se učil Javu. C a C++ jen v rozsahu nezbytně nutném k tomu, abych dokončil FEL. Prakticky to bylo jen C, to C++ jsem snad vůbec nepotřeboval. Teprve až o pár let později jsem se učil C++, a to především tvorbou aplikací postavených na MFC. Tehdy jsem v tom neustále hledal "javismy" a nadával jako špaček, že je tam všechno nějak horší. Nebylo to ale jazykem, byl to problém MFC

[Let_Me_Be]

IMHO smer Java -> C++ je dost spatny. Lide kteri se uci programovat na Jave maji pak priserne zkreslenou predstavu o programovani o tom jak funguje pamet pocitace, co to je kompilator, etc...

[kozzi]

No a co mám potom říkat já, sem přecházel s Visual Basic na C++. Sem se stále divil proč mám zaplněnej i 4GB swap

[Fluttershy, yay!]

Tak, to čumím, že ten VB někdy i někdo použil. Já to nikdy nechápal.

[kozzi]

Náhodou VB je perfektní jazyk . Když si vezmu že bych měl ve woknech vytvořit nějakou jednoduchou GUI aplikaci, tak VB je na to stvořené. Ono už fakt že v 6-7. tříde na ZŠ jsme v tom byl schopen vytvořit multimediální přehrávač lepší než WM player, naznačuje snadnost programování v tomto jazyce.

[Fluttershy, yay!]

Ono už fakt že v 6-7. tříde na ZŠ jsme v tom byl schopen vytvořit multimediální přehrávač lepší než WM player, naznačuje snadnost programování v tomto jazyce.

Spíše to ukazuje na kvality toho WM playeru. ^_^

[kozzi]

JJ to bylo taky cílem mého postu

[neaktivni]

Já zase nikdy nechápal, proč mají lidi tendence kopat do VB. Mám pocit, že si do něj kopnou především ti, co ho neovládají a tak jejich každý pokus o použití vypadá tragicky.

[xkucf03]

Mně zase přijde, že lidi, co k němu přičuchli hned zdrhli k něčemu lepšímu, nebo … jsou to zaměstnanci MS

Tehdy se mi to Visual Studio líbilo, jenže napovídání v kódu nebo tvorbu GUI klikáním má dneska kdejaké IDE a jako jazyk  mě VB nějak nezaujal.

[Pavel Stárek]

Já jsem v tom psal jednoduchá databázová kukátka (přes ODBC) a fungovalo to dobře. Ovšem další verze si napíšu v Pythonu a PyGTK - od té doby co jsem se naučil používat py2exe a Inno Setup Script.

[Ladicek]

Já teda mezi používaným jazykem a znalostmi "vnitřností" korelaci nevidím. Rozdíl bych viděl jinde: když takový neznalý člověk napíše kód v C++, bude to na vyhození, v Javě se to pravděpodobně bude dát použít a bude to i fungovat. Ponechávám bez komentáře, nakolik je či není rozumné takový kód akceptovat.

Mimochodem, co vlastně C++ naučí člověka o kompilátorech? Proboha, dyť ten jazyk není ani LALR!

[xkucf03]

BTW: už si někdo stáhl ten můj zdroják? Ještě jsem neslyšel žádnou kritiku (a že je určitě co kritizovat)

[...............23]

Pri takom rýchlom prebehnutí som si napríklad všimol že vo funkcii Fronta::prijmiZpravu() vraciaš staticky alokované pole...

[petr_p]

Že než si překladač uvědomí chybu, tak může uplynout několik obrazovek chybových hlášek.

[Ladicek]

Jo, na to jsem zapomněl. Učebnicový příklad toho, jak vypadá špatně navržený jazyk, který skoro nejde implementovat

[JS]

No tak proto se pak uci programovat v C++, ne? Co je na tom spatneho, ja to spis povazuji za pozitivni krok. Ja se ucil prvni (Spectrum) BASIC, a to o nem Dijkstra prohlasil, ze "cripples your mind".

Jinak, dnes v praci pouzivam mainframe assembler a C, a doma Python a zkousim Lisp.

[fakenickname]

pokud vim tak to rikal o COBOLu..

[JS]

Hm, zda se, ze to rikal o obou:

http://en.wikiquote.org/wiki/Dijkstra

[=^..^= AmigaPower®]

COBOLo, to bolo, terazky som majorom...

[dad]

nejak jsem nevyrozumnel, jestli mel Dijkstra pravdu ...

[Jirka]

Vás baví se ve volném čase ještě učit nějaký jazyk? Divím se, protože já už toho mám plné zuby. Každý semestr se muset zorientovat v dalších X různých jazycích, různých paradigmat, přístupů a jejich knihovnách ... je to strašně vysilující a k ničemu.

[kozzi]

Co to studuješ za školu . Já myslel že FIT prolezu se základnímy znalosti Javy, C++, C, Prolog a skriptovacími jazyky.

[Jirka]

V prváku to tak může vypadat. Ale stručně: Lisp, Haskell, AgentSpeak, různé assemblery, Smalltalk, VHDL, Modelica, Matlab, různé specialitky pro paralelní programování + tuna dalších skriptovacích jazyků a humusácké rozšíření SQL.

Jazyk není ani tak ten hlavní problém, ale musíš si projít i knihovny a spoustu dalších věcí.

[Fluttershy, yay!]

Programovací jazyky jsou jako bohové --- když se nepoužívají (respektive se v ně nevěří), jakoby nebyly.

[xkucf03]

A funguje to i naopak – Bůh existuje už jen tím, že v něj někdo věří

[xkucf03]

To u nás na škole (VŠE) se programování moc neučí, přestože studuji informatiku. Což je možná ten důvod proč se rád učím nový jazyk, když mě do toho nikdo nenutí Sice se programováním v C++ asi nikdy živit nebudu (to spíš tou Javou), ale přijde mi dobré mít alespoň základy.

[podlesh]

Tak to by možná stála za úvahu výměna oboru, případně úplné ukončení studia. Protože v programátorském oboru je to v podstatě hlavní smysl vysoké školy.

[Jirka]

Neříkám, že to není hlavní smysl. Říkám jenom to, že už by mohli brzdit. Ono, když už začínáte psát něco jako:

  for( integer i:=pole.length; 1; downto) begin (x (y (z (q (o (u )))))) }

Tak začíná být něco špatně.

[Martin Böhm]

Ještě že Vy a já studujeme naprosto jiné programátorské obory. :o)

[podlesh]

No dobře, "Computer Science" je také důležitá věc. Ale IMHO se dá lépe dostudovat dodatečně, alespoň pokud má člověk základy.

[JS]

No, nevim. Muj otec vzdycky rikal, ze matematiku se clovek musi naucit v mladi, jinak to uz nejde. Dal jsem na jeho radu, a ted je mi 30, a vidim, ze mel pravdu. Dnes by se mi do toho uz asi nechtelo.

[podlesh]

No jo, a nejen matematiku

[frEon]

nejak mi chybi v ankete ruby a lisp...

[David Watzke]

Mám jednu připomínku k tvýmu kódu: nepiš ho proboha česky!

[xkucf03]

Proč? Píšu to tak schválně

[Luk]

Protože se to pak slušně tluče s anglickými názvy identifikátorů systémových a knihovních funkcí.

[Andrej]

Například proto, že čeština vyžaduje diakritiku. Bez diakritiky získáš hnusný zprasený jazyk neandrtálců, což není čeština.

Ani kompilátor s podporou UTF-8 identifikátorů by nebyl dost dobrý důvod k použití češtiny. Velmi to ztěžuje sdílení toho kódu s ostatními. Drtivá větěšina dnešních zdrojových kódů je založená na angličtině. Netvrdím, že je to dobré nebo správné, ale je to prostě tak. Programátorů, kteří hovoří anglicky, je nesrovnatelně víc než těch, kteří hovoří česky.

[David Watzke]

Přesně... stačí si představit třeba zdrojovej kód řekněme ve francouzštině. To i když člověk vydá něco pod svobodnou licencí, tak většinu lidí připraví o jednu z hlavních výhod OSS.

[Marián Kyral]

 

Přesně... stačí si představit třeba zdrojovej kód řekněme ve francouzštině.

Já si to bohužel představovat nemusím

 

[xkucf03]

Francouzština je přece krásný jazyk

[pc2005]

Fantastic language especially to curse with.

You see? It's like wiping your ass with silk. I love it.

[kozzi]

a proč nee . Mě to příjde normální, je čech tak ať klidně píše česky.

[Andrej]

Normální by to bylo, kdyby tam nechyběla diakritika. Bez diakritiky nejde o češtinu, nýbrž o jakýsi nedefinovaný a těžko čitelný jazyk. Protože kompilátory zatím UTF-8 moc nemusí, taky bych se rozhodně přimlouval za angličtinu.

[kozzi]

Aha jé myslel že se bavíme o komentářích (jsou totiž česky a ne cesky), jelikož když jsem studoval různé OSS prográmky třeba od němců a francouzů, tak komentáře často byli v jejich rodném jazyce. To že on má pojmenované "cesky" i funkce, třídy a identifikátory, jsem si nevšiml. No ale popravdě pokud je to jen kód, na kterém se učí a je více méně jen pro něj. A případně pro pár dalších lidí, kteří jsou češi. Tak v tom nevidím zas tak problém. Je jasný, že pokud se budu snažit vytvořit aplikaci, která má být užitečná pro větší dav lidí. Je vhodné použít jako jazyk AJ z důvodů rozšíření tohoto jazyka.

[depka]

tak ja si rejpnu :)

program.h je naprosto zbytecny, extern "C"  uplne zbytecne...

oteviraci zavorku bloku { davej v c++ na novy radek(toto je ale hodne o zvyku a konvenci)

argumetny metod a konstruktoru ktere mas char* by meli byt const char*

zbytecne globalni promene

co kdyz funkce mq_open() selze?

[Franta]

program.h je naprosto zbytecny, extern "C"  uplne zbytecne...

Jako že bych tam neměl psát tu příponu? Četl jsem, že se nepoužívají, ale soubor bez přípony mi prostě přijde divný A taky je fakt, že by tam nemusel být vůbec, protože ten program.h asi sotva bude někdo používat jako knihovnu (to leda fronta.h).

oteviraci zavorku bloku { davej v c++ na novy radek(toto je ale hodne o zvyku a konvenci)

njn, zvyk z Javy, asi to nechám jak to je.

argumetny metod a konstruktoru ktere mas char* by meli byt const char*

Na to se podívám...

Zbytecne globalni promene

To je asi pravda, původně jsem to psal bez tříd a ten program vůbec vypadal trochu jinak. Třeba ta fronta nemusí být globální.

co kdyz funkce mq_open() selze?

Tak se to nepozná hned, ale odeslání zprávy nebo pokus o příjem vrátí chybu. Co s tím -- vyhazovat výjimku při vytváření fronty?

 

BTW: je nutný ten bezparametrický konstruktor? Asi jo Bez něj mi to nefungovalo (nešlo přeložit).

[Luk]

Tak se to nepozná hned, ale odeslání zprávy nebo pokus o příjem vrátí chybu. Co s tím -- vyhazovat výjimku při vytváření fronty?

Návratové hodnoty funkcí, které mohou selhat, je potřeba vždy testovat. Zrovna mq_open() může vracet až 9 různých chybových kódů. V C++ je dobrým zvykem v takovém případě vyhodit výjimku.

[spang]

Doporučil bych zapomenout na char* a používat std::stringy, ušetříš si starosti a bugy. (snad se na mě teď nesesype hromada mikrooptimalizátor-expertů)

[Deleted [8409]]

Nedíval jsem se na zdrojáky, ale char* má v C++ taky své místo. std::string je podle mě moc chudý string, v porovnáním třeba s Qt.

[Luk]

Také mi kdysi vadila chudost třídy std::string (zejména možnost automatických konverzí na jiné typy a naopak), proto jsem si vyrobil třídu s potřebnými metodami, do které jsem std::string zapouzdřil (šlo samozřejmě použít i dědění, ale vzhledem k různým existujícím implementacím jsem šel raději jinou cestou a zveřejnil ze std::string jen ty metody, které podle standardu má mít).

[spang]

Chudý sice je, ale o ukončovací nulu a vhodnou velikost se postará. Není důvod si na string nezvyknout, zvlášť když char* už má vyzkoušené .

[Deleted [8409]]

Otázka je, zda je ta ukončovací nula opravdu nezbytná, pokud znám velikost;)

[Jardík]

Je to na hovno ... ten program je pod GPL, tak to radši ani nebudu zkoumat ten zdroják, aby se neřeklo, že jsem to opsal a nezveřejnil zdrojáky.

[xkucf03]

To by se asi neřeklo, protože v tom programu jsou dost rutinní věci. Taky pochybuji, že by se vůbec někdo dostal do pokušení porušit GPL, protože ten program moc užitečný není, resp. určitě není užitečný v tom, abys ho vzal a začlenil do svého systému. Slouží spíš pro inspiraci a ukázku, jak ty fronty zpráv fungují. Takže je celkem jedno, pod jakou licencí to je – ale GPL používám z principu

[kozzi]

Tak jsem na to kouknul. A až na již zmíněné věci (globální proměnné, nekontrolování selhání funkce) nemám moc co dodat. Jen možná co se týče tojo string vs. char *, v tomto případě opravdu nevidím příliž důvod používat string. char sám o sobě dostačuje. Já si to přepsal sice, takže mám char *, nahrazenej za std::string, ale je to spíš jen zvyk. Jinak v C++ je docela zvykem (aspoň u někoho) psát hvězdičku (myšleno u ukazatelů) mezi typ a identifikátor. Takže například char * text = "neco";. Důvod je ten, že se nemohli někteří lidi dohodnout zda ta hvězdička pokud je blíž k typu, zanmená že daný identifikátor je typu například int ukazatel, nebo zda pokud je blíž k identifikátoru, tak identifikátor je ukaztel na daný typ . Jo a nějak sem nepochopil proč tam používáš printf? No a ohledně používání signálů, doporučuji se zaměřit spíš na novější a schopnější verzi sigaction. Je sice mírně komplikovanější, ale nabízí mnohem lepší prostředky.

[Dalibor Smolík]

Pro mé skromné účely úplně postačí PHP v kombinaci s MySQL, větší ambice v této oblasti nemám, programováním se neživím (naštěstí)

[Luk]

Ono PHP lze použít i pro docela neskromné účely. Tento jazyk není vázán jen na web, dají se v něm dělat úplně normální aplikace (včetně GUI), dá se pracovat třeba nad databází Oracle apod. Jiná věc je, že jsou knihovny dost nesystematické (organizace, názvy identifikátorů atd.) a že jazyk samotný svádí k prasení.