SDL, OpenGL... (diskuse)

[Luboš Doležel (Doli)]

Python nemá konstruktory?

[midar]

ja nevim, to sem jenom tak placl, vsechno me to se**...€[đł@°wl ~Ł:-0

[VícNežNic]

Psát v Pythonu bez toho aby člověk věděl co je konstruktor je přeci jen o poznání snazší, než v C++.

[Marek Bernát]

To myslíš vážne?

[VícNežNic]

Ano Tak do sta řádků a za předpokladu, že i v tom C++ budu používat objekty

[Marek Bernát]

Ale čo? Takže

class A{
    A(){}
};

je oveľa ťažšie ako

class A:
    def __init__(self):
        pass

?
Hmm.

[VícNežNic]

No, nevím proč by tohle někdo psal

Prostě si myslím, že bych se dostal dál (aniž bych věděl co je konstruktor) v Pythonu než v C++.

[Marek Bernát]

A ako chceš v pythone písať objekty bez konštruktoru? Daj nejaký príklad. Nemusí byť storiadkový

[VícNežNic]

No, řekněme, že nemusím vědět, že jsem použil konstruktor Vždyť nakonec stačí jenom:

x = nejakaTrida ()

Alébrž v C++ bychom dělali:

nejakaTrida *x = new nejakaTrida ();

To minimálně svádí k zamyšlení, k čemu je to new

[Marek Bernát]

Tak to si pletieš C++ s Javou. Pokiaľ budeš deklarovať na stacku a nie na heape, tak je to

nejakaTrida x;

Takže kde ti vydrži dlhšie neznalosť konštruktora?

[VícNežNic]

Já si nic nepletu, vždyť jsem tam poctivě dal tu hvězdičku. Já jenom čekal, že to třeba nikoho nenapadne :o)

[Marek Bernát]

V Jave je tiež tá hviezdička, len sa tam nepíše

Tak teda, keď si to nepletieš, stále myslíš, že je to v pythone ľahšie?

[VícNežNic]

Stále si to myslím! Ale už to raději nebudu rozvádět

[Daniel Kvasnička ml.]

Asi se na to programování vybodnu a budu dělat skrpity v Pythonu...

to jako ze Python neni programovani?!

[midar]

Neeeeeee, to je přeci skriptování

[toor]

V C dneska programuje uzivatelske programy pro osobni pocitace jenom silenec. C++ je 20 let stary nedodelek, ktery zazil svou nejvetsi slavu v roce 1990. Nechtel bys psat rovnou v ASM-86, nebo jeste lip, ve strojovem kodu? Budes pak nejvetsi boss ve tride :-/

Java, C#, python, perl,... - nic?

[Luboš Doležel (Doli)]

Java, C#, python, perl fakt ne-e.

Ten kdo tvrdí, že C++ je starý nedodělek asi moc C++ nezná nebo nikdy nevyužil jeho plný potenciál. Kdyby bylo C++ tak špatné, tak proč ho tolik programátorů používá?

[Spike]

Někdy mám pocit, že jim nic jiného prostě nezbývá. Nebo je nějaký jiný slušný neinterpretovaný jazyk (tj. je zvykem překládat ho do nativního kódu)?

[Luboš Doležel (Doli)]

To nevím.

To že není jiná kvalitní nativní varianta neznamená, že C++ je špatné. Dokud budou aplikace v jiných jazycích tak líné, jak jsou, tak nevidím žádný důvod něco jiného používat. Pokud nesouhlasíte, že jsou líné, tak vám to neberu.

[toor]

- protoze jsou liny naucit se neco noveho - kvuli kompatibilite (s .....) - ve svete Windows je na ustupu a nahrazovan C#, nebo Javou muzes si vybrat

Jinak, proc ne Javu,.... ? Vyvoj je rychlejsi, kod je prehlednejsi, mnozstvi knihoven, nezatezovani programatora s nepodstatnyma vecama (uvolnovani pameti,...), plne objektove, vetsinou platformove nezavisle, ... atd. atd.

[toor]

tak, formatovani nejak nevyslo.....

jeste neco: porovnej si takovou blbost jako je "Hello World!" v pythonu a C, kolik je to radku a pismen. A ihned po napsani to muzes spustit na Linuxu, ve Windows, .... co ja vim, treba v mobilnim telefonu

[Luboš Doležel (Doli)]

#include <stdio.h>
int main()
{
        puts("Hello world");
}

Mě to přijde dostatečně krátké. Podívejte se na tu dokonalou, objektovou Javu.

Když to napíšu v Pythonu, tak to sice můžu spustit všude, ale až po tom, co si tam nainstaluju obrovský interpreter. Tohle hello v C u mě zabírá jen 2996 bytes.

[Luboš Doležel (Doli)]

Ten #include můžete taky vyhodit, jde to i bez něj.

[Nejsemtu]

Na to bych se rozhodně nespoléhal. Překladač nehlásí varování jen tak pro nic za nic. Kdysi jsem se na to naivně spolehl a věřte mi, že je skutečně fajnové hledat chybu, která se objeví jenom občas, nedefinovatelnou shodou okolností.

[Luboš Doležel (Doli)]

Tohle je ukázkový Hello world a 100% vím, že fce puts(const char*) existuje...
Já běžně používám C++, takže tohle mi tam neprojde.

[Nejsemtu]

A chybí Vám tam návratová hodnota ;).

[Luboš Doležel (Doli)]

Nechybí.

[Nejsemtu]

Ano? A jaká tedy bude návratová hodnota do shellu, čili jak poznám, že program skončil korektně nebo zda došlo během běhu k chybě? Proč mi příkaz

./programek && echo "1"

nevypíše jedničku, ačkoli by měl, neboť k žádné chybě nedošlo?

Popravdě mi na mysl přichází spousta ošklivých slov, protože už jsem měl zkušenost s programátorama, co kašlou na návratové hodnoty, a je jim naprosto putna, co to vrací. Je utrpením (spolu)pracovat s takovými lidmi.

[#Tom]

Proč hned takové škaredé odsudky? Některé programy se na konci funkce main neukončují, je tedy zcela zbytečné tam nějakou hodnotu nastavovat. Ani GCC s vypnutými optimalizacemi ji tam nenastaví, je-li v době překladu zřejmé, že se tam procesor nedostane.

[Nejsemtu]

Proč? Právě kvůli těm hodinám stráveným hledáním. Nějak se mi to vybavilo... :-/. A tohle přeci nebyl odsudek a ani jsem nemluvil škaredě. Nebo to fakt vyznívá až tak zle?

[#Tom]

Ne až tak. Jen jsem chtěl naznačit, že nastavovat návratovou hodnotu někdy nemá cenu. Jsou programy, které se neukončují (/sbin/init), jsou programy, u kterých je návratová hodnota vždy ztracena, protože běží v pozadí, pak jsou také programy, jejichž návratová hodnota je k ničemu, protože jsou celé k ničemu, jako to Hello world.

[Jiří (BoodOk) Kadeřávek]

protože jsou celé k ničemu, jako to Hello world.

No, tvurci HQ9+ si to asi nemysleli

[Luboš Doležel (Doli)]

Jeeeeej. Přísahám, že návratové hodnoty píšu. Ale tohle je Hello world a šlo tu o krátký kód.

[Nejsemtu]

Jasně, že to je v pohodě. Šlo mi o to, že jste tvrdil, že tam nic nechybí.

Myslím si, že tohle dělání věcí napůl ve stylu "ono to nějak funguje" je velmi špatná známka dnešní doby. Ale to by bylo úplně na jinou diskusi .

[Nejsemtu]

Jasně, že to je v pohodě. Šlo mi o to, že jste tvrdil, že tam nic nechybí.

Myslím si, že tohle dělání věcí napůl ve stylu "ono to nějak funguje" je velmi špatná známka dnešní doby. Ale to by bylo úplně na jinou diskusi .

[--.----...--.-.]

print "Hello World!"

..... v pythonu. Interpreter ma 8.5 MB, disk mam 160+40 GB = 200 GB . Kde je problem? V Jave je to sice delsi jako v pythonu, ale do vyvojoveho casu se zapocitava i debugovani, compilovani ...

[DjAARA]

Myslim, ze resit u takovychto programu jak je co v jakem programovacim jazyce dlouje je uplny nesmysl. Vyhody jednotlivych programu se projevuji az u projektu radu stovek/tisic radku.

Jinak c++ osobne moc nemusim, vic se mi libi java. A to ze je obcas pomalejsi (obzvlaste gui) je mi celkem jedno (zatim, treba se to casem zmeni).

[Luboš Doležel (Doli)]

Když vy tak, tak já jinak

lubos@ares ~ $ time ./hello
Hello world

real    0m0.002s
user    0m0.000s
sys     0m0.000s
lubos@ares ~ $ time python -c "print 'Hello world'"
Hello world

real    0m0.023s
user    0m0.016s
sys     0m0.004s

[Luboš Doležel (Doli)]

Debugování C++ není problém, kompilace u automake projektů nejsou dlouhé.

[Luboš Doležel (Doli)]

Já rozhodně nejsem líný se učit cokoliv nového - ba naopak. Ale když vidím, že to mým účelům neslouží... Jako jsem nedavno psal na fóru Živě.cz: to že v Microsoftu nejsou s to vytvořit kvalitní objektovou knihovnu na tvorbu GUI neznamená, že za to může programovací jazyk. Podívejte se na GTKmm, QT a jiné - takhle vypadá využitý potenciál C++ (i když u toho QT, no, nebudu se hádat).

Vývoj pro mě v Javě rychlejší nikdy nebyl a to jsem se ji naučil dřív než C++. Na Javě mi strašně vadí přísnost u přetypování, nehorázná náročnost na RAM a i CPU (teď řeknete, že to není pravda; opět vám to neberu). Chybí mi tam i šablony...

Delete se v mých (nových) programech moc nevyskytuje - stačí vědět jak na to a delete nemusíte vůbec použít. Plná objektovost je nevýhoda, v Javě je objektovost dohnaná do extrémů. Ad nezávislost na platoformě, co třeba zmiňované QT...

[#Tom]

Není potřeba se omezovat na uživatelská rozhraní. Na matematické výpočty se mi nechce učit Fortran nebo Octave, psát to v C je sice možné, ale šílené. Jde to pěkně třeba v C++, jsou na to i knihovny, třeba Blitz - matice se tam docela povedly.

[VícNežNic]

Kde je problém u přetypování? Prostě se to hlídá i za běhu, objekt se nedá jen tak ze srandy přetypovat na něco jiného, jenom na to co opravdu je. Já to tedy beru jako výhodu.

[Luboš Doležel (Doli)]

Co třeba tohle:

char a,b,c;
a = 'a';
b = 'b';

c = a ^ b;

Zkuste si to v Javě.

Ono se stačí třeba jen podívat na podmínky... podmínkou v if() mohou být jen výrazy s výsledkem boolean a podobných příkladů pruzení by se našlo dost.

Způsob v C++: použijte dynamic_cast. V Javě se vždy použije něco jako dynamic_cast, v C++ je to po vůli programátora.

[VícNežNic]

Hm. Primitivní datové typy pro přetypování moc odpor nekladou, boolean z podmínky v if uděláte mrknutím oka… To je kosmetika.

Svoboda je otroctví

[VícNežNic]

Ono ve výsledku je to nakonec stejně jedno

[Miloslav Ponkrác]

Pane, naprosto s Vámi souhlasím! Kde to mám podepsat?

Umím Javu i C++, a pokud můžu, dávám přednost C++. Mě osobně na Javě vadí, že je jako jazyk hrozně osekaná. V Javě musím strašně ohýbat své myšlenky na osekané možnosti Javy, prakticky v jakémkoli jiném jazyce se cítím svobodnější.

Nevýhodou C++ je hlavně náročnost na učení. Podle mého je C++ zatím nejsložitější jazyk na zvládnutí, který znám a to je podle mě hlavní příčinou toho, že C++ je méně populární. Jinak pokud máte C++ dobře v ruce, je to nesmírně efektivní a pružný jazyk.

Taky souhlasím s tím, že v dobře navrženém C++ programu prakticky není potřeba psát téměř žádné uvolňování paměti a věta, že programátor v C++ věnuje spoustu času zařizováním alokace a dealokace paměti je jenom rádobypřání zastánců Javy.

[Kero]

Souhlas, sice v C++ neumím psát tak dobře, jak bych si přál, ale new a delete, hluboká a mělká kopie a všechny tyto věci nejsou moc často potřeba. Občas jsou ale vhodné - například pro interakci s Cčkovejma knihovnama, u OpenGl vytváření textur atp.

V jednom programu si musím v opengl vykreslovat pozadí pomoví gldrawpixels, zrovna tam bych chtěl vektor<>, ale bohužel pro předávání do opengl funkce je to špatné (nebo myslím, že to nejde).

Co mi dost chybí je možnost auto_ptr pro pole, ne jen jednotlivé instance, na to jsou právě ty vektory, mapy, sety linky atd.

Pro ty co neví, auto_ptr je bezva věc, když alokujete několik nových objektů a alokace u některého selže - které mám dealokovat, do kdy už jsem alokoval, kde nastala chyba, nezůstane paměť viset? new selže, vyhodí vyjímku a ta při propagaci výše zavolá destruktory všech lokálních proměných, v tomto případě těch auto_ptr, které už byly vytvořeny, a ty destruktory auto_ptr dealokují paměť, šikovné.

Teď jsem udělal jednoduchý program porovnávající rychlost vector a alokovaného pole, vector vyšel asi 2 krát horší.

Na konec jedna hezká stránka - Guru of the week, stránka s různými C++ problémy a zajímavými řešeňími.

Doufám, že jsem sem nedal moc bludů.

[Kero]

adresa - guru of the week http://www.gotw.ca/gotw/

[Luboš Doležel (Doli)]

V jednom programu si musím v opengl vykreslovat pozadí pomoví gldrawpixels, zrovna tam bych chtěl vektor<>, ale bohužel pro předávání do opengl funkce je to špatné (nebo myslím, že to nejde).

std::vector má metodu data(), nebude to ta, co potřebujete?

[Kero]

Odkud to prosím víte(respektive korektní popis metody)? Já obvykle čerpám informace z

http://cppreference.com/

http://www.sgi.com/tech/stl/table_of_contents.html

tam to není, pokud znáte lepší zdroj, prosím podělte se, tyhle jsou zatím nejlepší, co znám.

Trochu jsem to hledal v includech, zatím nic. Každopádně to ale musí být odkaz přímo na pole těch typů soustavně za sebou, žádný balast okolo, který by tam mohl zůstat (jako třeba že mimo samotného integeru je tam ještě položka značící platnost/neplatnost).

[Luboš Doležel (Doli)]

Mě stačí man std::vector - nevím, jestli starší GCC má u sebe tyto man pages, ale GCC 4.1 prerelease je u sebe má.

Pokud mi nevyhovuje man, tak chodím sem, respektive na snapshot této dokumentace, co jsem si stáhnul na disk.

[machr]

> V jednom programu si musím v opengl vykreslovat pozadí pomoví gldrawpixels, zrovna tam bych chtěl vektor<>, ale bohužel pro předávání do opengl funkce je to špatné (nebo myslím, že to nejde).

jak uz tady nekdo zminil:

vec.data()

nebo:

&vec[0]

[Lukoko]

No tak nevim ... s Pythonem, kterej je obejtovej a konstruktory a podobny brebery tam sou denim chlebem si asi moc nepomuzes zkus treba bash ... tam te to trapit nebude na ale co se tyka SDL a Open GL kdyz uz bojujes s Pythonem, tak se podivej na knihovny PyGame a PyGL tam bys moch najit co hledas.

[#Tom]

C++ je vynikající jazyk, ale chvilku trvá, než do něj človek pronikne. Obdobně jako C je to na první pohled nic neříkající změť složených a jiných závorek. C++ je navíc přeplněno přetěžováním konstruktorů, metod, funkcí, operátorů atd. Šablony na přehlednosti taky moc nepřidají. Programy v C++ vypadají někdy šíleně divoce, ale dá se na to zvyknout. Nejde to ale ze dne na den.

[midar]

Takze co jsem pochytil z diskuze. Python se ucit zatim nebudu, dodelam C++. Az dodelam C++ podivam se este jednou na SDL (mozna budu moudrejsi). Po SDL se kouknu na Python.

Myslim ze mam budoucnost naplanovanou. Diky vsem

[#Tom]

Lepší by bylo mrknout se na všechno.

[Marek Bernát]

Len jednu malú radu. Možno by si mal zvážiť, či nezačať radšej s GLUTom, ako s SDL. SDL je fajn knižnica na rôzne veci, máš tam timere, dokonca aj nejakú kontrolu joystickov a tuším aj thready; neviem presne, už to bolo dávno. Ale ak sa chceš učiť openGL, tak glut je podľa mňa priamočiarejšia cesta. Mám taký subjektívny pocit, že na vytvorenie okna stačí menej balastu. Ale ruku do ohňa by som za to nedal

[Marek Bernát]

Aha a ešte som zabudol na povzbudenie. OpenGL nie je ťažké. Niektoré veci sú možno pre začiatočníka zložitejšie, ale to je kvôli tomu, aby sa s ním [s openGL] dali robiť pokročilejšie veci. Na začiatok nemusíš rozumieť úplne všetkým nastaveniem svetiel, materiálov a ako sa to počíta. Stačí, že sa niečo nakreslí a to, ako to presne funguje, budeš zisťovať časom.

[VícNežNic]

Nikdo nikoho nenutí ty timery, vstupy a i vlákna (jo, něco tam na ně je) využívat Myslím, že okno se snáž vytvoří v SDL, ale nevím, páč jsem to zkoušel jenom v SDL

[Marek Bernát]

No jo. Len som chcel povedať, že SDL je multimediálnejšie (ostatne, má to v názve ) a glut openglovejší.

[VícNežNic]

No, zase jestli chce zkoušet nějakou hru, tak se mu ty věci jako timery nebo vstup budou hodit (přiznám se, že nevím jestli to glut taky nějak umí). A v SDL jsou skutečně jednoduché a dokonce i bez problémů opsatelné z dokumentace

[Marek Bernát]

Tak tak, preto som tam aj napísal, že glut len v prípade, že sa chce učiť openGL. Handlovanie vstupu v glute samozrejme je (ako inak by sme vypli program, že ), ale ostatné veci tam netreba.

Inak, veľmi dobrý dôvod pre glut je napríklad aj to, že má funkciu na vyrenderovanie čajníku. Tam sa SDL nechytá