Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: pe25tr 04. 09. 2013, 13:00:47
-
double ***p
p = (double***) malloc(ni * sizeof(double**));
for (i = 0; i < ni; i++) {
p[i] = (double**) malloc(nj * sizeof(double*));
for (j = 0; j < nj; j++)
p[i][j] = (double*) malloc(nk * sizeof(double));
}
stačí:
free(p)nebo se musí opačně:
for (i = 0; i < ni; i++) {
for (j = 0; j < nj; j++)
free(p[i][j]);
free(p[i]);
}
free(p);
?
Dík.
-
ty radsi nic neprogramuj a jdi zametat chodniky
-
Je třeba volat free pro každý malloc. free nijak neanalyzuje, co je uložené v paměti, kterou uvolňuje. Mohla by tam být klidně čísla, která vypadají jako ukazatele.
-
Děkuji ;).
-
Just to be clear: Being called a ThreeStarProgrammer is usually not a compliment.
http://c2.com/cgi/wiki?ThreeStarProgrammer
-
Just to be clear: Being called a ThreeStarProgrammer is usually not a compliment.
http://c2.com/cgi/wiki?ThreeStarProgrammer
one would occasionally find a piece of code done by a three-star programmer and shiver with awe.
:-D
-
Mohli byste mi stručně říct, co je špatného na ukazateli na pole ukazatelů na pole doublů? Proč není tříhvězdičkový programátor kompliment?
-
Snaz sa robit cim menej mallocov - ak to ide. Defaultny malloc alokuje casto nie prilis dobre zarovnane adresy v pamati, ma nejaku reziu (musi si niekam zapisat, kolko toho alokoval) a niekedy vyzaduje syscall, co je zabijak vykonu.
Tu to ide nahradit jednym mallocom alebo este lepsie v C++ pomocou jedneho new.
-
Proč není tříhvězdičkový programátor kompliment?
To je dobry priklad tak na skusku - ale beznemu programatorovi sa to necita dobre "ako rozpravka". A ked ja musim rozmyslat aj nad tym, co vlastne programator kodom myslel*, tak mi neostava tolko kapacity mozgu na rozmyslanie nad tym, co ten kod robi.
Mimo tento problem je problem aj s vykonom, ako som uz pisal o prispevok vyssie.
Mohli byste mi stručně říct, co je špatného na ukazateli na pole ukazatelů na pole doublů?
To ti naozaj znie dobre? Vedel by si si hned predstavit abstrakciu za tym a vobec dovod takeho odkazovania? Netvrdim, ze to musi byt vzdy zle - urcite sa to skor bude podobat trileru ako rozpravke na dobru noc.
Mimo to, spominane double ***p; si predstavim ako ukazatel na ukazatel na ukazatel na double. A to je uz same dost zahmlene. Interpretacia "pointer je pole" je dost nepriezracna a nevidim dovod, preco to pisat takto.
-
Keby sa tie hviezdicky pisali na druhu stranu, tak vznikne p*** :D
-
Ze zkusenosti bych rekl, ze lide, kteri umi pouzivat ***p vetsinou umi i psat efektivni algoritmy (ne tak, ze pouziji STL, ktere je dobre na standardizovane veci, ale kdyz jde napr. o nejaky specificky parser tak je potreba mozek a ne chytrou knihovnu).
Programu s trojnasobnymi pointery jsem napsal uz desitky. Ono to neni o te obskurnosti, ale obcas je lepsi u vicerozmernych datovych struktur pouzit to ***p nez nejake p- [y][z]. U programu, ktery prochazi milionkrat nejaka data je potom kazda neoptimalizovana operace znat. Ani gcc neprijde na vsechno ;-).
Nepovazuji se za zadneho super programatora.
-
Můžu mít nesmělý polozačátečický dotaz? ;)
Proč, když už se jedná o C++ používat malloc() a free(), když lze využít přehlednější operátory new a delete? Je zde nějaký rozdíl v imlementaci, či výkonu nebo se je nepodstatné který způsob alokování paměti využiji?
Díky za odpověď.
-
ty radsi nic neprogramuj a jdi zametat chodniky
Každý nějak začíná. >:(
-
Mimo to, spominane double ***p; si predstavim ako ukazatel na ukazatel na ukazatel na double. A to je uz same dost zahmlene. Interpretacia "pointer je pole" je dost nepriezracna a nevidim dovod, preco to pisat takto.
stačí se podívat pár řádků pod double ***p; a je jasné, že je to myšleno jako trojrozměrné pole. Jak vyrobit efektivněji 3D pole s přístupem k prvkům pomocí p
-
Jak vyrobit efektivněji 3D pole s přístupem k prvkům pomocí p
boost::multi_array
http://www.boost.org/doc/libs/1_54_0/libs/multi_array/doc/user.html
-
Můžu mít nesmělý polozačátečický dotaz? ;)
Proč, když už se jedná o C++ používat malloc() a free(), když lze využít přehlednější operátory new a delete? Je zde nějaký rozdíl v imlementaci, či výkonu nebo se je nepodstatné který způsob alokování paměti využiji?
Díky za odpověď.
Nemám pocit, že by new a delete byly nějak výrazně přehlednější. Třeba pro alokaci pole čísel se dá použít oboje. new a delete jsou potřeba, když ty alokované objekty mají netriviální konstruktory a destruktory. new/delete zase nemají nic podobného realloc(). Ale realloc() se používá hodně špatně ve chvíli, když můžou lítat výjimky. Inteligentní ukazatele taky implicitně volají delete. Použít u nich malloc znamená trochu víc psaní.
Trocha čiré spekulace :
malloc se používá v C, kde je zvykem hodně konzervativní práce s pamětí. Takže bych čekal že new by se mohl chovat trochu líp při alokaci spousty malých objektů. Ale tohle se bude lišit mezi překladači a mezi prostředími. Obecně neexistuje alokátor paměti vhodný pro všechno, takže to chce měřit.
Když to shrnu :
Většinou bych v C++ používal new. malloc se může hodit ve speciálních případech (je potřeba realloc, budu stejný kód překládat i C překladačem, v mém překladači je new zabugovaný nebo používá nevhodný alokátor pro mé účely, ...)
A kdyby si chtěl někdo zaflamovat :
Osobně nemám new/delete moc rád. Mít klíčová slova pro alokaci paměti je myslím zbytečné. Stačila by nějaká možnost zavolat konstruktory nad prázdnou pamětí a vlastní alokaci nechat knihovním funkcím. new/delete jdou sice přetížit, ale je to nepřehledné a komplikované. Raději vytvářím objekty pomocí nějaké vlastní funkce.
-
Osobně nemám new/delete moc rád. Mít klíčová slova pro alokaci paměti je myslím zbytečné. Stačila by nějaká možnost zavolat konstruktory nad prázdnou pamětí a vlastní alokaci nechat knihovním funkcím. new/delete jdou sice přetížit, ale je to nepřehledné a komplikované. Raději vytvářím objekty pomocí nějaké vlastní funkce.
new a delete existuje především kvůli volání konstruktorů a destruktorů.
Konstruktor a destruktor si můžeš zavolat i bez práce s pamětí tak jako normální funkci, stačí si přečíst příslušnou dokumentaci.
Není problém alokovat 10 MB pomocí jednoho malloc a pak zavolat milion konstruktorů již bez alokace paměti.
-
boost::multi_array
http://www.boost.org/doc/libs/1_54_0/libs/multi_array/doc/user.html
A to jako vážně? Místo 6 řádků snad každému srozumitelného programu stahovat nějakou knihovnu s 373 MB? Ještě že neumím pořádně programovat, protože tohle není nic pro mě.
-
apt-get install libboost-all-dev
Hotovo. boost je standardní široce používaná knihovna a hodně věcí z boostu se dostalo do C++11. Skoro všechno v boostu je v šablonách, takže nemusíš přilinkovat žádnou statickou libku, stačí includovat headery. Že to nepoužíváš a znovuvynálézáš kolo je tvoje rozhodnutí ;).
-
A to jako vážně? Místo 6 řádků snad každému srozumitelného programu stahovat nějakou knihovnu s 373 MB?
Ano, vážně.
Těch 6 řádků stačilo jen na alokaci a uvolnění. Jak se s tím začne něco netriviálního dělat, tak začnou řádky bobtnat. O tom, že je těch 6 řádků srozumitelných, by se dalo pochybovat. Koukni se na ně a řekni mi jestli tam někde nechybí hvězdička. Schválně, jak dlouho ti to vezme.
Boost je velká knihovna, která obsahuje spoustu užitečných věcí. Nejen relativně malou multi_array. Nevím, kde jsi sebral 300 mega. Aktuální verze má třetinu (zip) a to je včetně dokumentace a hodně rozsáhlých testů.
Psát věci, na které se dají použít knihovny, znova a znova nepovažuju za rozumné využití času. Ano, znamená to si tu knihovnu stáhnout a přečíst si manuál. Ale pak můžeš psát kratší, jednodušší, čitelnější a spolehlivější kód.
Ještě že neumím pořádně programovat, protože tohle není nic pro mě.
Jeden ze znaků dobrého programátora je, že zbytečně znovu nevynalézá kolo.
-
Konstruktor a destruktor si můžeš zavolat i bez práce s pamětí tak jako normální funkci, stačí si přečíst příslušnou dokumentaci.
To samozřejmě umím. Co jsem chtěl říc bylo, že imho nemuseli do C++ přidávat celou tu obludnou mlátičku. Stačila by právě jen nějaká varianta placement new bez vlastní alokace a všeho toho přetěžování. Ale to jsou jen takové zbytečné řeči :)
-
Jednou se mi stalo že jsem v jednom programu mixoval new/delete a malloc/free při alokaci paměti a pak mi program náhodně padal při vykreslování bitmap do paměti. Ze zkušenosti proto mohu doporučit v C++ používat pouze new/delete, zvláště pokud vás okolnosti nutí kódovat něco pod widlemi...
-
apt-get install libboost-all-dev
Hotovo. boost je standardní široce používaná knihovna a hodně věcí z boostu se dostalo do C++11. Skoro všechno v boostu je v šablonách, takže nemusíš přilinkovat žádnou statickou libku, stačí includovat headery. Že to nepoužíváš a znovuvynálézáš kolo je tvoje rozhodnutí ;).
Ehm ... a ty potrebujes prehazet pytlik pisku a objednal sis na to velkorypadlo. Normalni clovek nepouziva knihovny z nihz nevyuzije aspon 10% funcionality.
-
Ehm ... a ty potrebujes prehazet pytlik pisku a objednal sis na to velkorypadlo. Normalni clovek nepouziva knihovny z nihz nevyuzije aspon 10% funcionality.
Asi bych se držel toho, co o sobě tvrdí Boost, a sice že je to "Boost C++ Libraries", tedy je to balík knihoven nikoliv knihovna. Takže je zcela normální, že člověk nevyužije většinu funkcionality.
-
Ehm ... a ty potrebujes prehazet pytlik pisku a objednal sis na to velkorypadlo. Normalni clovek nepouziva knihovny z nihz nevyuzije aspon 10% funcionality.
Znovu opakuji: BOOST SE NEKOMPILUJE!!! Je to celé v šablonách, ve výsledné binárce bude přilinkované jen to, co skutečně použiješ. Mimochodem kdybys použil 10% toho co je v boostu, můžeš se považovat za senior expert guru programátora ;)
-
A co když zvládnu v jednom programu využít 11,7845%? To mě rovnou přijede pogratulovat ředitel NASA a nabídne mi práci? Není to náhodou spíše tak, že každý projekt je unikátní a u některých složitějších se vyplatí používat knihovny? A u některých jednoduchých s omezenou pamětí, výpočetním výkonem apod se vyplatí používat ***, vlastní definici funkce sinus, vlastni printf...? Zatím jste mě nepřesvědčili, že double *** p; je něco, za co by se měl jeho autor popravit, nebo minimálně chodit kanálama. Často se setkávám s tím, že bojuju o každý bajt programu, abych se vešel i s bootloaderem do 8 kB. Při použití multi_array je velikost programu 88kB, s *** má 40 kB. S multi_array jel testovací program 28s a s *** byl za 5s hotov. Co je úspornější z hlediska RAM jsem nezkoušel, ale odhaduju, že to bude s multi_array zase horší.
-
BOOST SE NEKOMPILUJE!!! Je to celé v šablonách
Nutnou podmínkou použití šablon je jejich kompilace a to ještě se to kompiluje znovu v každém *.cpp kde je to použito. Proto to taky tak dlouho trvá, naštěstí máme rychlé počítače.
Přepsal bych *** na několik typedefů Level1, Level2, Level3. Rychlost stejná, orientace v kódu mnohem lepší.
-
Ehm ... a ty potrebujes prehazet pytlik pisku a objednal sis na to velkorypadlo. Normalni clovek nepouziva knihovny z nihz nevyuzije aspon 10% funcionality.
Ja to tak delam. Napr: nez abych se sr*l s tim ja porovnat dva STL stringy case-insensitive, tak radsi pouziju boost. Boost (popr. Loki) obsahuji spoustu zajimavych komponent, ktery bych nikdy sam nevymyslel. Vymyslenim kola bych akorat zabil spoustu casu, ktery muzu venovat i jinym vecem.
PS: V pripade Java, PHP, Pythonu, Perlu, .. je uplne normalni ze clovek nevyuzije vic jak 10% standartni knihovny. To je specifikum C++ ze jeho standartni knihovna dohromady nic moc neumi.
-
Hlavně se ohánět efektivitou. Pár pointerů navíc, čert je vem, pokud ti nejde o "každý bajt". Horší je ten milión dereferencí, když máš plnej procesor násobiček, který leží ladem.
#define pole(x, y, z) __pole[x*ix*iy+y*iy+z]
__pole = malloc(ix*iy*iz*sizeof(double));
...
free(__pole);Bez boostu, přehledně, rychle a jednoduše ;)
(Nemaťte mě za chybějící závorky v makru, vynechal jem pro přehlednost.)
-
...
Tak to je jasny, to kvuli tobe ma pak "hello world" 50MB ...
Mimochodem, srovnavas nesrovnatelny, java, php ... nejsou kompilovany jazyky. Zlaty lidi, co jeste dneska umej delat 64kB demace ...
-
boost multi array má úplně stejný výkon jako nativní implementace. Není důvod to nepoužít.
Nativně:
#include <iostream>
int main()
{
const int SIZE = 10;
double array[SIZE][SIZE][SIZE];
for (int i = 0; i < SIZE; ++i)
for (int j = 0; j < SIZE; ++j)
for (int k = 0; k < SIZE; ++k)
array[i][j][k] = i + j + k;
double result = 0.0;
for (int a = 0; a < 1000000; ++a)
for (int i = 0; i < SIZE; ++i)
for (int j = 0; j < SIZE; ++j)
for (int k = 0; k < SIZE; ++k)
result += array[i][j][k];
std::cout << "result: " << result << std::endl;
return 0;
}
Výsledky nativního pole:
g++ -s -O3 native.cc -o native
du -bs native
7760 native
time ./native
result: 1.35e+10
real 0m1.190s
user 0m1.172s
sys 0m0.020s
multi_array:
#include <iostream>
#define BOOST_DISABLE_ASSERTS
#include <boost/multi_array.hpp>
int main()
{
const int SIZE = 10;
typedef boost::multi_array<double, 3> array_type;
typedef array_type::index index;
array_type array(boost::extents[SIZE][SIZE][SIZE]);
for (index i = 0; i < SIZE; ++i)
for (index j = 0; j < SIZE; ++j)
for (index k = 0; k < SIZE; ++k)
array[i][j][k] = i + j + k;
double result = 0.0;
for (int a = 0; a < 1000000; ++a)
for (index i = 0; i < SIZE; ++i)
for (index j = 0; j < SIZE; ++j)
for (index k = 0; k < SIZE; ++k)
result += array[i][j][k];
std::cout << "result: " << result << std::endl;
return 0;
}
Výsledky multi_array:
g++ -s -O3 multi.cc -o multi
du -bs multi
8984 multi
time ./multi
result: 1.35e+10
real 0m1.175s
user 0m1.168s
sys 0m0.008s
multi_array je úplně stejně rychlé jako nativní pole a kód je o 1224 bajtů větší (to je opravdu hrozná režie...). Naopak implementace pomocí *** bude mnohem pomalejší a paměťově náročnější, zbytečně se tam několikrát provádí dereference a pamět není alokovaná v souvislém bloku, což způsobuje více cache misses a cache trashing. Ještě nějaké argumenty proti boostu a multi_array?
-
Hlavně se ohánět efektivitou. Pár pointerů navíc, čert je vem, pokud ti nejde o "každý bajt". Horší je ten milión dereferencí, když máš plnej procesor násobiček, který leží ladem.
#define pole(x, y, z) __pole[x*ix*iy+y*iy+z]
__pole = malloc(ix*iy*iz*sizeof(double));
...
free(__pole);Bez boostu, přehledně, rychle a jednoduše ;)
(Nemaťte mě za chybějící závorky v makru, vynechal jem pro přehlednost.)
Zmlátíme tě za používání maker v C++.
-
gamer: to s *** neni vubec pravda... ve skutecnosti to bude o krapet rychlejsi, vyzkousej s -O3 toto
#include <iostream>
#include <cstdlib>
int main(){
const int SIZE = 10;
double *** pole = (double ***) malloc(SIZE*sizeof(double**));
for(int i=0;i<SIZE;i++){
pole[i] = (double **) malloc(SIZE*sizeof(double *));
for(int j=0;j<SIZE;j++){
pole[i][j] = (double *) malloc(SIZE*sizeof(double));
for(int k=0;k<SIZE;k++){
pole[i][j][k] = i+j+k;
}
}
}
double result = 0.0;
for(int a=0;a<1000000;a++){
for(int i=0;i<SIZE;i++){
for(int j=0;j<SIZE;j++){
for(int k=0;k<SIZE;k++){
result += pole[i][j][k];
}
}
}
}
std::cout << "result: " << result << std::endl;
for(int i=0;i<SIZE;i++){
for(int j=0;j<SIZE;j++){
free(pole[i][j]);
}
free(pole[i]);
}
free(pole);
return 0;
}
u me to jede o par desitek milisekund rychleji nez nativni ci boost implementace (ty jsou rychlostne asi na stejne urovni)
-
#include "stdafx.h"
#include <time.h>
#define MULTI_ARRAY
#ifndef MULTI_ARRAY
#include "malloc.h"
#else
#include "boost/multi_array.hpp"
#endif
#include <cassert>
void fce() {
int ni = 3, nj = 4, nk = 2;
#ifdef MULTI_ARRAY
// Create a 3D array that is 3 x 4 x 2
typedef boost::multi_array<double, 3> array_type;
typedef array_type::index index;
array_type A(boost::extents[ni][nj][nk]);
index i, j, k;
#else
double ***A;
int i, j, k;
A = (double***) malloc(ni * sizeof (double**));
for (i = 0; i < ni; i++) {
A[i] = (double**) malloc(nj * sizeof (double*));
for (j = 0; j < nj; j++)
A[i][j] = (double*) malloc(nk * sizeof (double));
}
#endif
// Assign values to the elements
int values = 0;
for (i = 0; i != 3; ++i)
for (j = 0; j != 4; ++j)
for (k = 0; k != 2; ++k)
A[i][j][k] = values++;
// Verify values
int verify = 0;
for (i = 0; i != 3; ++i)
for (j = 0; j != 4; ++j)
for (k = 0; k != 2; ++k)
assert(A[i][j][k] == verify++);
#ifdef MULTI_ARRAY
#else
for (i = 0; i < ni; i++) {
for (j = 0; j < nj; j++)
free(A[i][j]);
free(A[i]);
}
free(A);
#endif
}
int _tmain(int argc, _TCHAR* argv[]) {
time_t t0 = time(NULL);
for (int i = 0; i < 500000; i++)fce();
time_t t1 = time(NULL);
printf("%d %d %d", (int) t0, (int) t1, (int) (t1 - t0));
return 0;
}Testováno Microsoft Visual Studio C++:
multi_array 28s
*** 5s
Jestli někomu vyjde multi_array rychlejší než *** s výrazným časovým rozdílem, tak dejte vědět.
PS: Ještě pořád nevím, co je špatného na "double ***A;", prosím o vysvětlení.
-
Zapomněl jsi na BOOST_DISABLE_ASSERTS, když to nenadefinuješ, dělá multi_array range checking. Přistup přes pointery bude výrazně pomalejší, pokud se to pole nevejde to cache. n-násobená dereference každá znamenající cache miss je zabiják výkonu.
-
prezek: s define MULTI_ARRAY a BOOST_DISABLE_ASSERTS (velikost 10384)
1378455254 1378455254 0
real 0m0.064s
user 0m0.056s
sys 0m0.004s
s define MULTI_ARRAY (velikost 14504)1378455308 1378455308 0
real 0m0.060s
user 0m0.056s
sys 0m0.000s
bez define MULTI_ARRAY (velikost 10376)1378455345 1378455345 0
real 0m0.340s
user 0m0.336s
sys 0m0.000s
vse kompilovano pod linuxem pres g++ 4.7.3 s O3
tak nam tady vysvetlete, jak je pouziti boostu nevhodne a ba primo kontraproduktivni... u vetsich poli a vetsich dat je *** mirne rychlejsi (viz muj predchozi test), nicmene ve vasem prikladu je temer 6x pomalejsi
argumentace tim, ze to kompilujete ve visual studiu neberu... dle vasich slov bojujete o kazdy byte
a propos, stdafx je proprietarni knihovna pro windows, vyborne na multiplatformni aplikace... a je vazne videt, ze programovat moc neumite, jinak byste vyuzil ty ni,nj a nk promenne
-
Testováno Microsoft Visual Studio C++:
multi_array 28s
*** 5s
Můžu se zeptat, jakou verzi Visual Studia a jaké nastavení překladače jsi použil? Ty časy jsou dost zoufalé. Hlavně by mě zajímalo nastavení optimalizací (/O...) a runtime testů (/RTC...).
Tohle totiž vypadá, že je vypnutý inlining a jsou zapnuté runtime testy zásobníku. To pak překladač každou funkcičku obalí dost náročným "balastem". Ty časy by tomu odpovídaly.
-
Tak to je jasny, to kvuli tobe ma pak "hello world" 50MB ...
A kolik by měl takový hello world mít? Počítá se do té velikosti jen exe, nebo i C++ runtime knihovny (nebo jinéo jazyka), systémové knihovny a podobně?
Opravdu má cenu osekávat pár bytů z kódu programu, když pak u toho programu bude několik set megabyte dat? Když máme disky v terabytech, paměť v gigabytech a platí pravidlo 90/10?
Mimochodem, srovnavas nesrovnatelny, java, php ... nejsou kompilovany jazyky.
Java je kompilovaný jazyk. Kompiluje se napřed do bytekódu a při běhu se ten bytekód kompiluje na instrukce procesoru. A než namítneš, že je to něco jiného, tak C++ se kompiluje podobně. Jen se ten "bytekód" neukládá.
Zlaty lidi, co jeste dneska umej delat 64kB demace ...
Kolik dem už jsi napsal? Protože tímhle způsobem ušetříš +-prd. U dem jsou důležité věci jako procedurální generování geometrie/obrazu/zvuku. Vyhýbat se header-only knihovnám z boostu je kravina.
-
prezek:
... a je vazne videt, ze programovat moc neumite, jinak byste vyuzil ty ni,nj a nk promenne
Můžu se zeptat, jakou verzi Visual Studia a jaké nastavení překladače jsi použil? Ty časy jsou dost zoufalé. Hlavně by mě zajímalo nastavení optimalizací (/O...) a runtime testů (/RTC...).
Já říkal, že "neumím pořádně programovat"... :)
Chtěl jsem jen prověřit, že boost je blbost (tam, kde se dá nahradit *** a 6 řádky programu navíc) a po cca 10 minutách jsem viděl výsledek, který mě uspokojil. To, že ten výsledek neodpovídal realitě mi nevadilo. S nastavováním optimalizace jsem si hlavu nelámal a použil defaultní při založení nového projektu. Teď jsem zkusil jen přepnout profil debug(/Od) na release(/O2) a výsledek se otočil. Přesvědčili jste mě, boost zřejmě má smysl ve většině případů a třeba ho někdy taky využiju. Takže díky.
-
Java je kompilovaný jazyk. Kompiluje se napřed do bytekódu a při běhu se ten bytekód kompiluje na instrukce procesoru. A než namítneš, že je to něco jiného, tak C++ se kompiluje podobně. Jen se ten "bytekód" neukládá.
GIMPLE či LLVM IR jsou podobné JVM asi tak jako Céčko Fortranu. Navíc JVM je na rozdíl od těch dvou stack-based, což dost ztěžuje kompilaci a kvůli tomu to má často mizerný výkon. Proto Dalvik v Androidu používá register-based bajtkód. Takže ano, oboje používá bajtkód, ale úplně jiný a úplně jinak.