Vypadá to jako nějaké stínování :)
Příspěvky odeslané z IP adresy 86.49.188.–
#152 KIIV
Však ten tvůj příspěvek je jasný, pokud si to člověk pořádně přečte - reagoval jsi v druhé osobě na p3cana, který reagoval na Kita a pak tu poznámku v závorce jsi psal ve třetí osobě - z toho je (alespoň pro mě) patrné hned, že ta poznámka v závorce byla na Kita.
Ale je pravda, že pokud má někdo horší jazykový cit, nemusí to v tom hned vidět :)
#147 Kit
Pokud jsi nepochopil, že ten text
(ja osobne tipuju, ze je to bude neco jako ucitel - taky nulova sebereflexe, nemoznost/neschopnost uznat jakoukoliv chybu a tak - ale muzu se samozrejme plest)
se vztahuje na tebe, tak jsme možná u jádra pudla - problém s neporozuměním psanému textu :)
#6 Matěj Andrle
A proč to neděláš jako běžní smrtelníci? :)
Algoritmem vlny si celou mapu ohodnoť čísly, podle kterých poznáš jejich vzdálenost od startu.
Pak ti stačí jen jít od cíle po nejnižších hodnotách a podle těch políček konstruovat cestu, dokud nedojdeš do startu.
EDIT: 10 biliard (ani miliard) cest za minutu to nebude, pochybuji, že bys měl tolik operační paměti :)
#4 Matěj Andrle
Ref je tam proto - přeci nebudu posílat celé pole - ne
Pole se přeci neposílá celé ani když tam ref nedáš, posílá se jen reference.
Jinak podle mě máš trochu zmatek v path/currentPath. Ideálně si tam hoď breakpoint a krokuj, aby jsi viděl, co přesně se tam děje :)
#60 Kit
Pokud algoritmy sestavuješ tak, že voláš knihovní funkce, bývá program i rychlý. Není důvod vynalézat kolo. Knihovní funkce bývají mnohem výkonnější, než nejrůznější frameworky, proto jim dávám přednost.
To platí možná v PHP pro jednoduché aplikace, ale při psaní čehokoliv většího (složitějšího) ti nestačí jen lepit dohromady knihovny a navíc i ty knihovny musel někdo napsat a použít nějaký algoritmus :)
Funkce jako parametr jiné funkce C# umí.
#58 Kit
V PHP neprogramuji, ale předpokládal jsem, že musíš spustit nějakého Apache nebo něco podobného.
Ne na vše jsou knihovny, v reálném světě musíš občas napsat i nějaký algoritmus
Ano, using ti zabezpečí, že ten signál odešleš hned při opouštění scopu a to i pokud došlo k chybě.
#56 Kit
PHP používám i na klientské aplikace.
Hodně štěstí v reálném světě s PHP aplikacemi na klientských strojích, kde porty blokuje kde co - od firewalu po Skype běžící na portu 80 :).
Jinde zase vítězí PHP.
Ukaž mi kód, kde je PHP rychlejší než C# / C++ / Java. A nebo uznej, že je to blábol (což je)
Stačí mi fungující destruktory, které na ten GC nečekají, ale spouští se už v okamžiku, kdy je zrušena poslední reference na objekt. To v PHP funguje, ale v jazycích Java/C#/C++ ne.
Už tu několikrát bylo zmíněno, že např. v C# se na tohle používá kosntrukce using.
#25 KIIV
Proto mam rad C#, je to takovy svycarsky nuz - umi v podstate vsechno - v zakladu je podobny jako Java, muzes v nem intenzivne pouzivat LINQ a pak to mas jak SQL, ale zaroven mu muzes (pres unsafe) vnutit pointery a programovat v nem v obdobne jako v C++.
A dnes uz je i multiplatformni, takze ho clovek rozjede temer vsude.
#20 Kit
Jo, to je super, když ti třeba z nějaké knihovny choděj unsigned bajty a ty si to pak v Java aplikaci musíš buďto převést na něco většího, aby to číslo odpovídalo a nebo počítat s tím, že třeba čísla nad 127 tam máš uložená jako záporná :)
#15 Kit
C# to má už od počátku.
Zavření souboru byl jen příklad toho, že když chci něco zavolat při zániku platnosti objektu, nemohu se v C# ani v Javě spolehnout na destruktor.
V C# můžeš.
Použitím konstrukce using - objekt je platný jen uvnitř téhle konstrukce. V destruktoru se obvykle jen volá metoda Dispose(), ve které máš napsané třeba to zavření souboru. Pak se ti to zavolá na konci toho bloku using.
EDIT: Ale to jsme trochu odbočili, co tedy v C++ kromě memory managementu podle tebe nevyhovuje OOP v porovnání s Javou a C#?
#11 Kit
Destruktory nejsou ani v C#
Odkdy? :)
#8 Kit
Ptal jsem se dřív :-)
- Na co jsi se ptal? Nikde žádnou otázku nevidím :)
C++ umí toho ohledně OOP mnohem méně, než C#
C++ neumí (bez doplňků) zlikvidovat objekt, na který nevede odkaz - programátor se o to musí postarat sám. To značně ovlivňuje programátora, který na to musí myslet a přizpůsobovat tomu kód - jinak dochází k memory leakům. Tím se vzdaluje od OOP.
Že toho C++ ohledně OOP umí "mnohem méně" je tedy v tom, že má jiný memory management, což se vlastně OOP skoro netýká? Navíc si v C++ můžeš přece vybrat - je možné psát managed kód a nechat to za tebe řešit GC, případně můžeš používat smartpointery, pokud si po sobě nechceš uklízet sám.
Zajímaly by mě ty ostatní rozdíly, co C++ ohledně OOP neumí :)
Také jsem si všiml, že nejen já, ale i pár lidí v okolí programuje raději v C# než v Javě - prostě se mi v C# programuje o něco pohodlněji než v Javě - nevím ani, jestli je to vývojovým prostředím, těmi rozdíly v jazycích nebo tím, že .NET je na Windows nativnější než JVM (takže běží nativně na více počítačích).
Nevím, co je na C# komfortnějšího než na Javě. Podle mne jen to, že se v něm snáze prasekóduje.
- Prasekódovat se dá v obou jazycích stejně, nemyslím, že by na tom bylo C# nějak hůře v tomhle ohledu.
Jazyky C/C++ jsou nízko- až středněúrovňové. Na ovladače dobré, ale nezvládají vyšší úroveň abstrakce OOP.
- C jako takové OOP neumí, ale u C++ nesouhlasím - C++ umí (co se týče OOP) v podstatě to samé, co C# nebo Java - v některých směrech více (šablony, dědění od více tříd, ...) a v některých méně (RTTI, reflexe, ...).
#15 hlucheucho
Pokud to není něco, co je časově kritické, pak ty řetězce jsou dobrá volba (jen případně bacha na floaty - tečka vs čárka).
Zauvažoval bych i nad změnou zarovnání dané struktury - např. v MSVC přes #pragma pack http://msdn.microsoft.com/en-us/library/2e70t5y1.aspx , pokud to kompilátor, který používá, podporuje a máš jak zaručit všude stejný Endian.
Pak stačí vzít jen strukturu jako pole bajtů a spočítat hash z něho.