Ukazatele a jazyk C (diskuse)

[JS]

Jeste bych k tomu dodal, ze kdyz definujeme v C pole, tak se ta promenna pak predat jako ukazatel na typ v tom poli.

A take, co jsem zapamatoval ja a hodne zmatku mi to vyjasnilo "reference (v C++) je vlastne ukazatel, ktery se pri kazdem pouziti dereferencuje" (takze treba nemuze byt NULL).

[Let_Me_Be]

V jazyce C se spravne nema pretypovavat navratovy typ mallocu.

[JS]

Aha, to jsem nevedel, ze jde o C++-ismus. Ale vzdycky mi to prislo citelnejsi.

[dad]

to ale pred 15 lety tak nebylo. Tam hlasil compiler warrning a proto to ve starych programech casto je. Ja to ze zvyku tak delam furt.

[Martin Mareš]

Správně to bylo vždycky, jen tu a tam některé překladače generovaly uhozené warningy. A jestli nevymřely, generují dodneš

[luky]

Zmena pointeru z void na jakykoliv pointer krome pointeru na funkci ma jit bez warningu urcite i v ANSI C a to je pres 20 let stary (starsi neznam).

[dad]

kdyz se zada v G '(char *)malloc' tak strycek ukaze 41 milionu hits.

[Sten]

A kolik z toho je zprasené C++?

[Miloslav Ponkrác]

"V jazyce C se spravne nema pretypovavat navratovy typ mallocu."

Neznám ideologii a politiku, která se nově vyvíjí z nějaké politického byra kolem jazyka C.

Ale za to jsem praktik. A vím, že C zkontroluje typovost každého pointeru kromě void *. A to mi říká, že na just budu přetypovávat všechny pointery void *, tedy i návratové hodnoty malloc(). A to proto, že si tím získám kontrolu od kompilátoru navíc a tedy vyšší spolehlivost a bezpečnost programu.

int * pole_int; char * pole_char;

pole_int = malloc(100 * sizeof(char)); // A kurna, spletl jsem se ale kompilator to zbastil, chtel sjem pole char.

pole_int = (char*)malloc(100 * sizeof(char)); // Spletl jsem se, ale kompilator me na to upozorni.

Nezajímá mě co se dělá nebo nedělá, zajímá mě co funguje. A proto vždy budu i v C přetypovávat výstup malloc(), stejně jako všechny void * pointery, protože tím získám vyšší kontrolu od kompilátoru a nižší počet možných chyb.

V C/C++ programuji 25 let a doporučuji namísto ideologie se řídit praktičností. Ona ta politika a pravidla co by se mělo - tam je keců a blbsotí až to hezké není.

Miloslav Ponkrác

[pavlix]

int * pole_int; char * pole_char;

pole_int = malloc(100 * sizeof(char)); // A kurna, spletl jsem se ale kompilator to zbastil, chtel sjem pole char.

pole_int = malloc(100 * sizeof(*pole_int));

[Miloslav Ponkrác]

A při nějakém dalších zásahu do zdrojáku změníte proměnnou a jste někde.

V tom je rozumnější C++ s jeho operátorem new, který je dokonale typové a s jeho zákazem automatického přetypování void *.

pole_int = new int[100]; je nepřekonatelné, zkontroluje se typově úplně všechno

případně

template<typename T> T* typed_malloc(::std::size_t count) { return reinterpret_class<T*>(::std::malloc(sizeof(T) * count)); }

A následně

pole_int = typed_malloc<int>(100);

Dokonce i funkce memcopy, memset, memcmp a další je možné obalit do šablony, takže se stanou dokonale typovými.

Základem programování není trikovat. To se pozná až po několika letech vytáhnete svůj zdroják a máte do něj významně zasáhnout - opravit chybu, předělat chování a přidat nové vlastnosti.

Pokud i dnes jsem nucen zasáhnout do C kódu, přemýšlím jak kód udělat jasný a pokud možno odolný proti chybě i programátorově překlepu. Kašlu na nějakou módu jak se to píše - jde mi o praktičnost.

[Sten]

Ač mám radší C++, tak tohle si zaslouží odpověď v C:

#define DYN_ARRAY(var, type, size) type *var = malloc(size * sizeof(type))

DYN_ARRAY(pole_int, int, 100);

[pavlix]

A při nějakém dalších zásahu do zdrojáku změníte proměnnou a jste někde.

Málokdy můžu něco takového napsat, ale... to se mi nestává. Používám ve vimu search&replace a ještě k tomu vždy po řádcích.

V tom je rozumnější C++ s jeho operátorem new.

Porovnání s new je úplně nové téma, nikde jsem nepsal, že by se mi operátor new nelíbil. Nicméně příklad od Stena je taky hezký.

Pokud i dnes jsem nucen zasáhnout do C kódu, přemýšlím jak kód udělat jasný a pokud možno odolný proti chybě i programátorově překlepu. Kašlu na nějakou módu jak se to píše - jde mi o praktičnost.

Což přidáním úplně zbytečného přetypování člověk rozhodně nedocílí. Ale tenhle názor už jsem tu myslím dal najevo dostatečně, takže pokud nemáš opravdu pádný argument (jakože nemáš), tak nemá smysl se v tom pitvat. Aneb, kecy nemaj cenu.

[Grunt]

Ježiš co to je za shit? Takhle se alokuje:

(gdb) call malloc(100)
$1 = 14324840

Pak CTRL+C, CTRL+V

[elenril]

pnaint = (int *) malloc(POCET * sizeof(int));

Dvě poznámky:

1) malloc vrací void*, ten se castuje implicitně. Explicitní cast z void* je ošklivý C++-ismus.

2) Je lepší použít sizeof(*pnaint) než sizeof(int), protože se to nerozbije když změníš typ.

[Miloslav Ponkrác]

Viz moje poznámka výše.

Je až dojemné, jak programátoři dávají přednost nenávisti k C++ před fungujícím řešením a vyšší kontrolou chyb v programu.

My ze staré školy dáváme přednost co nejvyšíš kontrole od kompilátoru před nenávistí, ideologií, politikou a ochcávání kompilátoru.

[pavlix]

Je až dojemné, jak programátoři dávají přednost nenávisti k C++ před fungujícím řešením a vyšší kontrolou chyb v programu.

Je až dojemné, jak někdo dokáže vyplodit takovou myšlenku a ještě se přitom dojmout.

My ze staré školy...

My, král programátorů, ředitel zeměkoule...? :)

[Miloslav Ponkrác]

Nenašel jsem bohužel v příspěvku ani jeden jediný bit informace či nějakého konkrétního argumentu.

Pouze slabošské kecy nějakého člověka, který nemajíce žádných argumentů se pokouší útočit ad hominem.

I tedy, pokračujte.

[pavlix]

Nenašel jsem bohužel v příspěvku ani jeden jediný bit informace či nějakého konkrétního argumentu.

Přesně toto je můj pocit z tvého předchozího příspěvku.

[Petr Bravenec]

Proč ty invektivy? Já s názory Miloslava Ponkráce na programování bez výhrad souhlasím. Jestli má díky nim pocit, že kraluje programátorům a řediteluje zeměkouli, budiž mu to přáno.

Já se snažím při programování postupovat podobně - mám-li prostředek, který mě dovede pohlídat, budu jej používat a budu se snažit mu ulehčit práci. Proto mám rád C++, které mě ochotně upozorní na každou blbinu, která by kdekoliv jinde prošla, i když to znamená, že se fáze překladu občas nepříjemně protáhne.

Zcela mimo debatu o C: Portoval jsem nedávno jednu svou menší databázovou aplikaci z SQLite3 na PostgreSQL. Těch deset tabulek jsem přenášel snad dva dni. I když aplikace původně "fungovala" (občas se chovala nevyzpytatelně), objevil jsem díky velmi striktním kontrolám v PostgreSQL množství chyb a překlepů, které databáze SQLite3 tiše překousla a neupozornila mě na ně. Kdybych nechal databázi v SQLite3, nikdy bych na žádnou z těchto chyb pravděpodobně nepřišel a aplikace by se chovala nevyzpytatelně dalších dvacet let. Ve výsledku jsem rád, že na mě aspoň jedna databáze byla tak přísná.

Nářky na příliš striktní prostředí slýchávám často od programátorů zvyklých na PHP a MySql při požadavku na fungování dotazů v PostgreSQL. Sql dotazy typu "select a,b,sum(c) from x group by a;" (v PostgreSQL neprojde, v mysql ano, ale těžko říci, co to vlastně vrátí) a neochotu je opravit taky komentuji slovy "kluku, ty jsi blbec" a je mi fuk, jestli, stejně jako Miloslav Ponkrác, vypadám jako král programátorů a ředitel zeměkoule. Důležitá je fungující aplikace, ne můj image.

[pavlix]

Proč ty invektivy?

Jaké?

[Martin Mareš]

Já s názory Miloslava Ponkráce na programování bez výhrad souhlasím.

No jo, a jiní je zase považují za hluboce pomýlené

Já se snažím při programování postupovat podobně - mám-li prostředek, který mě dovede pohlídat, budu jej používat a budu se snažit mu ulehčit práci.

To se někdy hodí, jindu zase takový prostředek ve výsledku přidělá daleko víc práce, než jí ušetří.

Typický příklad je warning na "if (a=b)" – prakticky žádný zkušenější Céčkový programátor omylem "=" místo "==" do podmínky nenapíše, ale nejeden z nich připisuje závorky navíc, aby hloupý warning umlčel.

[Sten]

Typický příklad je warning na "if (a=b)" – prakticky žádný zkušenější Céčkový programátor omylem "=" místo "==" do podmínky nenapíše, ale nejeden z nich připisuje závorky navíc, aby hloupý warning umlčel.

Možná nenapíše, ale při hledání, proč se hodnota a mění, když to nečekám, ty závorky navíc hodně pomůžou

[pavlix]

Taky mi závorky v tomhle případě vyhovují, ačkoli MJ narozdíl od pana astrologa považuju v programování za autoritu.

[Petr Bravenec]

Hluboce pomýlené? Samozřejmě, proč ne

K těm závorkám: napíšu-li

if ((a=b))

vnímám to jako znamení překladači, že má být v klidu, že vím, co dělám.

Na druhou stranu, pokud napíšu

if (a=b)

jsem rád, že překladač kafrá. Praxe mi říká, že "=" místo "==" skutečně nenapíšu ani omylem, ale překlep se může vyskytnout kdykoliv a kdekoliv, a protože já bych to přece nenapsal ani omylem, je velmi pravděpodobné, že bych takovou chybu hledal dlouho.

[JS]

Pokud clovek nedavno programoval v jazyce, v kterem se == zapisuje skutecne jen jako =, pak muze byt v C sebezkusenejsi, ale stejne mu to muze ujet a napsat jen jedno =.

[Václav HFechs Švirga]

Je to tak, ono stačí občas změnit jazyk (třeba ve škole se mi to stává často) na nějaký co místo == používá =, například VHDL a pak když se člověk zas dostane k C, semtam se "uklepne" (než přepne myšlení)).

[Sten]

Dvourozměrné pole, které má fixní jeden rozměr, je lepší definovat takto:

int (*pole)[POCET1];

pole = malloc(POCET2 * sizeof(*pole));

Tenhle zápis má výhodu v tom, že se používá jenom jeden ukazatel, což je na moderních počítadlech o hodně rychlejší.

Jestli je to C++-izmus, tak mě prosím nekamenujte

[kralyk z abclinuxu]

Je třeba zdůraznit, že ukazatel je vždy "na něco", tedy ukazatel na int, ukazatel na char apod.

To není pravda, můžeš mít klidně void *p; aneb polymorfismus á la C

[Let_Me_Be]

Ale bacha na strict aliasing.

[Kvakor]

Teoreticky je tu ještě problém se zarovnáváním - minimálni na intelích procesorech musí být určité typy zarovnané na určité mocniny dvou (většinou odpovídající vlastní délce nebo 16B), jinak je procesor musí nejen "načíst" nadvakrát (což by dnes zas tak nevadilo, protože je tu 64bit+ datová sběrnice a cache), ale může hodit vyjímku (obzvlášť u FPU, MMX a SSEx). Naštěstí malloc() alokuje paměť vždy na adrese zarovnané na násobek 16 a pokud se neuvede pragma pack/u GCC __attribute__((__packed__)), tak to dělá i u prvků struktur. To, že má ukazatel typ, ovlivňuje i to, jak s ním překladač zachází (tedy měl by, jak moc jsem v praxi jsem to netestoval).

[Kvakor]

Tedy, ne že by prvky struktury zarovnával vždy na 16B, ale na tu hodnotu, na jakou je chce mít zarovnaný přislušný procesor.

[Radek Hladik]

Nedá mi to, abych nepopřál pevné nervy při práci s pointery v C. Je to silná vlastnost C, ale díky tomu umožňuje dělat různá zvěrstva. Pokud má funkce měnit hodnotu parametru (volání odkazem), pak se předává jako pointer na pointer. To je ještě poměrně elegantní, jen si člověk musí spárvně ohvězdičkovat.

Další obvyklou konstrukcí je přetypovávání void pointeru. Například takové MS CryptoAPI má spoustu funkcí, které dostanou void pointer a číslo. Podle číselné konstanty poznají, co by volající chtěl a to mu do pointeru uloží. Takže jednou je to pointer na strukturu x, podruhé y a těch možností je třeba 50.

No a poměrně časté je různé zanořování a spol. Máme pointer, přetypujeme ho na strukturu, z té vezmeme void pointer, ten přetypujeme, tím dostanemene nějakou strukturu, z ní vememe prvek, který pomocí & převedeme na pointer.... Moje oblibene je (potkal jsem to při práci s OpenSC):

sc_path_print(pbuf, sizeof(pbuf),(sc_path_t *) &(env->file_ref)); 

O co jde? Máme (pointer na) strukturu, která obsahuje prvek file_ref typu sc_path, ale potřebujeme (pointer na) sc_path_t, přiznám se, že jsem nepochopil proč, ty struktury jsou obě shodné. Každopádně pomocí -> z env vytáhneme to file_ref, které ovšem není pointer, takže & a tento pointer přetypujeme na pointer na sc_path_p...

[michich]

Jestliže je sc_path_t definováno takto:

typedef struct sc_path {
/*...*/
} sc_path_t;

..., a ten file_ref je definován jako struct sc_path file_ref, tak je tam to přetypování opravdu k ničemu a musí to fungovat i bez něj:

sc_path_print(pbuf, sizeof(pbuf), &env->file_ref);

[Radek Hladik]

Oboje je to definováno přesně tak. A taky bych byl očekával, že to půjde. Ostatně šlo o triviální debug, který měl vypast jednu hodnotu... Možná to bylo nějakým nastavení gcc nebo tak. Už si moc nepamatuju detaily, ten příklad jsem vytáhl z emailu kolegovi, už jsem s tím nějakou dobu (naštěstí) nemusel pracovat. Jen si vzpomínám, že to jednoduché řešení nějak zlobilo (možná i kvůli nějaké mé chybě) a musel jsem to takhle pohobitovat (tam a zase zpátky).

Btw: já bych si to raději ozávorkoval &(env->file_ref). Přiznám se, že nevím, jestli má přednost & před ->, ale představa, že z pointeru na env udělám pointer na pointer na env a z něj se budu snažit brát file_ref mě docela děsí Až se dostanu do pekla, tak mně nebudou smažit v hrnci plném oleje, ale nutit ladit a opravovat pointerové konstrukce

[michich]

Konstrukci &p->prvek používám docela často, takže zrovna u těchto operátorů jsem si prioritami jistý. Navíc překladač by protestoval při pokusu o získání file_ref přímo z něčeho typu pointer na pointer.

[JS]

Ja tenhle pripad take radeji zavorkuji. Musim rict, ze mi zapis pointeru v C prijde dost prasteny (hlavne fakt, ze * ma 2 ruzne role je dost matouci, a C++ tomu nasadilo korunu tim, ze pridalo jeste dalsi roli &). Kdyz srovnam nektere veci zapsane v C s (mainframe) assemblerem, ten assembler je leckdy citelnejsi.

[kralyk z abclinuxu]

No on znak * má v C a C++ tři různé role, v praxi se ale v 99% nestane, že by se pletly...

[JS]

V praxi se to nestane, to by nedavalo pak smysl (neni to Perl), ale zacatecnika to muze mast.

[kralyk z abclinuxu]

to by nedavalo pak smysl (neni to Perl)

[JS]

No, ted si tak pohravam s myslenkou zkrizit Forth a APL (zbyly mi nejake volne klavesy co jsem si konecne definoval UCW klavesnici - celkem 42 novych ne-ASCII znaku), takze mozna to i prekonam.

[Petr Bravenec]

Další obvyklou konstrukcí je přetypovávání void pointeru. Například takové MS CryptoAPI má spoustu funkcí, které dostanou void pointer a číslo. Podle číselné konstanty poznají, co by volající chtěl a to mu do pointeru uloží. Takže jednou je to pointer na strukturu x, podruhé y a těch možností je třeba 50.

To jako vážně? Humus. V c++ toho dělám poměrně dost, ale na tyhle konstrukce v podstatě nenarážím (qt).

[Radek Hladik]

Viděl jsem to už u víc věcí, nejen u WinAPI, ale to MS CryptoAPI to využívá dost zhusta....

http://msdn.microsoft.com/en-us/library/windows/desktop/aa380196%28v=VS.85%29.aspx

[Petr Bravenec]

Notykrávo, v tom bych chtěl dělat!

Většinu kódu v současnosti tvořím pro knihovnu Qt. Tam se takové konstrukce vyskytují nejspíš taky, ale C++ je umožňuje hezky schovat. Typická je například struktura QEvent, kde se může posílat opravdu kde co, ale různé wrappery mi vždy úslužně předloží právě takový obsah, o který si řeknu.

Blbě:

void MUJOBJEKT::event(QEvent *e) {
    switch(e->type()) {
        case QEvent::KeyPress:
            // přetypovat
            QKeyEvent *ke = dynamic_cast<QKeyEvent *>(e);
            if (ke->key() == atd atd) 
        }
}

můžu velmi snadno napsat i takto:

void MUJOBJEKT::keyPressEvent(QEvent *e) {
    if (e->key() == atd atd) 
}

Zlaté C++

[Josef Kufner]

Však proto má Qt krásnou věc jménem QVariant.

Pokud je potřeba to řešit mimo Qt, vyplatí se udělat něco podobného, tedy strukturu obsahující enum povolenými typy a union s hodnotou. Celé to pak doplnit o přetypovávací operátory/metody.

[Petr Bravenec]

Ano, QVariant je skvělá věc. Pokud tam zrovna nepotřebuju nacpat ukazatel na QWidget, například do QStandardItemModel Ale i to lze zařídit, jenom už to nevypadá tak hezky.

[Sten]

QVariant je omezená slabota. Takový boost::variant těmi omezeními kvůli enumu vůbec netrpí.

[Petr Bravenec]

Boost mi nechodí na ARM

[Sten]

Jestli je to Android, tak je potřeba jako STL použít gnustl_static, jinak Boost shazují výjimky a RTTI.

Kdyžtak napsat rekurzivní šablonu pro variant není moc složité (a v C++11 to díky variabilním šablonám ani není moc kódu).

[Petr Bravenec]

Ne, není to Android. K Androidu se dá najít spousta nezávislých informací na internetu. K mému ARMu je jediným zdrojem informací naprosto šílený programátor kdesi v číně...

[pc2005]

Tohle je tuším ve formátovači pro printf a scanf (a pokud ne, tak minimálně já jsem to musel tak napsat ).

[Ivan]

Podobne se chova OCI od Oracle. Funkce ma jako parametr void*, a vy musite z kontextu uhadnout jestli se to pretypovava na char* anebo char**.

Matne si vzpominam, ze na divokych (a nedokumentovanych) pretypovanich void pointeru byl postaven i XPCOM ve FF3.

[s0]

teď jsem to chtěl napsat. OCI je to největší prasomaso v okrese.

[Kvakor]

To není nic neobvyklého, např. u IOCTL (přes které se dělá všechno možné) je jen handle otevřeného souboru (int), příkaz (int) a (nepovinný) ukazatel (void *, i když historicky to býval char *), zbytek je na programátorovi.

[kralyk z abclinuxu]

Důsledek toho ale bohužel je, že je dost náročné získat kompletní dokumentaci ioctl().

[Sten]

Hlavně by ioctl mělo být něčím rozumným obaleno v libc, tenhle systém je tam kvůli tomu, že je to jaderné volání.

[Petr Bravenec]

Poznámka k ukazatelům v C a C++ obecněji:

Ukazatele jsou něco, co je vhodné dobře znát, a čemu je lépe se vyhýbat.

Tím samozřejmě nechci tvrdit, že nejlepší je mít všechno na zásobníku, v automatických proměnných.

Vím, že C není C++, jednoduché C je často nenahraditelné (cizí programy, jednočipy a podobně). Ale mnohdy vidím použité různé alokace a new tam, kde by můj zdravý rozum velel použít čistě preventivně něco jiného. Občas uvažuji, co k takové konstrukci dotyčného programátora vedlo - docházím k závěru, že nejspíš pouze představa, že "takhle se to správně dělá".

Většinu svého C++ kódu píšu pro knihovnu Qt - tam je starost o alokaci/dealokaci paměti a objektů přenechaná převážně toolkitu. Vzdal jsem i různé alokace jedno-dvou-tří-atd rozměrných polí, kontejnery a modely v Qt poslouží obvykle mnohem lépe a bezpečněji.

V Qt se snažím programovat tak, abych pokud možno nemusel vůbec používat operátor delete. Každé použití operátoru delete ve mně rozsvítí varovné světýlko: "nedělám něco špatně?" Ve svém posledním velkém projektu mám použitý operátor delete jednou na dva tisíce řádků, a to ještě v polovině případů kvůli vláknům, kde automatická likvidace objektů nefunguje, nebo funguje jinak. To už i goto používám častěji

Kupodivu se mi paměť nikam neztrácí, jakmile uvolním všechna vlákna a datové objekty, z původně alokovaných pěti GB se stane znovu jen 500 MB (aspoň ve Windows, v Linuxu to očividně funguje jinak)

Na C a C++ je sympatické, že prakticky vždy je z datového typu jasné, s čím vlastně pracujete. Dělá se mi zle například z Javy, kde ukazatele neexistují, ale parametry se předávají někdy ukazatelem, jindy hodnotou, a programátor to má šanci vyčíst pouze z dokumentace.

[podlesh]

Na C a C++ je sympatické, že prakticky vždy je z datového typu jasné, s čím vlastně pracujete. Dělá se mi zle například z Javy, kde ukazatele neexistují, ale parametry se předávají někdy ukazatelem, jindy hodnotou, a programátor to má šanci vyčíst pouze z dokumentace.

WTF?

[Petr Bravenec]

C++:

void funkce(Objekt*); // předávám ukazatel
void funkce(Objekt&); // předávám referenci
void funkce(Objekt);  // předávám hodnotu

Java:

public void funkce(int i) // předávám hodnotu
i=i+1; // nemá vliv na volající objekt
}

public void funkce(String s) // předávám ukazatel
s="pojapený nesmysl"; // rozhodí volající objekt
}

Stejný zápis, pokaždé však znamená něco diametrálně odlišného.

Co se kdy předává hodnotou a co ukazatelem musím vědět, nebo vyčíst z dokumentace, zdrojový tvar mi nijak nenapoví. Javu nemám v oblibě i z mnoha jiných důvodů, používám ji málo. A proto, když už do Javy vlezu, nechávám se často nachytat právě takovými detaily, které se zapisují sice stejně, ale podle kontextu dělají různé věci.

Neberte mě úplně za slovo, nevím, jestli se funkci funkce(String) předávají parametry ukazatelem, nebo hodnotou. Podívejte se do dokumentace.

[kovariadam]

Java vzdy predava parametre hodnotou. Aj primitivne typy, aj referencie na objekt - su skopirovane.

public void funkce(String s) // předávám ukazatel
s="pojapený nesmysl"; // rozhodí volající objekt
}

Na to neviem kde ste prisli, je to nezmysel, s v tele tej metody sa zmeni, nema to vsak vplyv na povodny parameter.

[xxx]

Autor puv. prispevku mel spis na mysli veci z Collections atp.

[Petr Bravenec]

Nevím, co jsem měl na mysli.

Pokud je mi známo, Java předává parametry vždy hodnotou, zásadně hodnotou, nikdy jinak, odkazem už vůbec nikdy. Ehmmmm, kromě toho případu, který mě stál několik bezesných nocí, kdy se parametr odkazem předával a ano, v dokumentaci to takto bylo uvedeno.

Kdybych já si jen vzpomenul...

[Petr Bravenec]

Odvolávám. Blbnu.

[Petr Bravenec]

Nastudoval jsem si dokumentaci a je to přesně, jak jsem uvedl původně. Java to jednou předávává hodnotou, jindy odkazem. Jenom programátorům v Javě se do příruček píše, že se to předává vždy hodnotou, protože něco tak šíleného, jako odkazy, v Javě přece není.

Příklad:

Objekt A;
A = new Objekt();
funkce(A);

static void funkce(Objekt x) {
   x.property = "xyz"; // přepisuji A, protože x je pouze ukazatel
}

je přesně totéž, jako v C++

Objekt *x;
x = new Objekt();
funkce(x);

static void funkce(Objekt *x) {
    x->property = "xyz";
}

Java operátorem new vytváří ukazatel a ten pak - přesně podle příručky - předává hodnotou. Java se vůbec neunavuje programátora informovat, kdy používá hodnotu a kdy používá ukazatel. Ukazatele přece v Javě nejsou, aspoň to tak psali v příručce, tak proč tam ještě navíc nenapsat, že parametry se předávají vždy hodnotou!

V C a C++ je jasno vždy - s hvězdičkou ukazatel, bez hvězdičky hodnota.

[Martin Mareš]

V C a C++ je jasno vždy - s hvězdičkou ukazatel, bez hvězdičky hodnota.

V C++ žel nikoliv, předávání referencí je potvora :)

[kovariadam]

Java operátorem new vytváří ukazatel a ten pak - přesně podle příručky - předává hodnotou. Java se vůbec neunavuje programátora informovat, kdy používá hodnotu a kdy používá ukazatel. Ukazatele přece v Javě nejsou, aspoň to tak psali v příručce, tak proč tam ještě navíc nenapsat, že parametry se předávají vždy hodnotou!

Co je to zase za nezmysel?

Prestudujte si to este raz a poriadne. V Jave je kazda objektova premenna referenciou na instanciu daneho objektu - "ukazatel". V pripade predavania parametrov sa tato premenna skopiruje, stale vsak odkazuje na instanciu povodneho objektu.

[Petr Bravenec]

To není nesmysl, cituji:

Java vzdy predava parametre hodnotou. Aj primitivne typy, aj referencie na objekt - su skopirovane.

Máte v tom vůbec jasno? Máte představu o tom, jak je v počítači implementovaný ukazatel a hodnota?

[kovariadam]

Mate predstavu na co som reagoval? :) Kazda premenna v Jave je "ukazatel", ak to chcete takto nazyvat. Predanie parametru hodnotou v takom zmysle ako je v C++ v Jave neexistuje, resp. mozte si vytvorit kopiu objektu, ale to uz je na programatorovi. Preto nechapem preco Vam chybaju hviezdicky v Jave, ved by sa museli pisat pred kazdou premennu, aky zmysel by to malo? O com Vas ma teda este prirucka informovat, ked toto plati vzdy? Toto sa samozrejme netyka primitivnych typov, tam je to este jednoduchsie a su vzdy hodnotove.

[Petr Bravenec]

Tenhle krátký odstavec mělo být možná to první, co jsem si měl o Jave přečíst. Bohužel jedna z prvních informací, kterou jsem si v publikacích o Javě přečetl, byla ta, že Java je objektová a že nemá ukazatele. Ani jedno není tak úplně pravda.

[Petr Bravenec]

Aááááááááá, sláva. Už jsem našel ten případ, kdy jedno a totéž zdaleka není totéž:

funkce(int x) // předává se hodnotou
funkce(Int x) // předává se odkazem

Jiný datový typ, stejný zápis, naprosto odlišný způsob předávání parametru.

[kovariadam]

Tento autoboxing primitivnych typov naozaj sposobuje zmatky, aj nizsie v diskusii som sa o tom zmienil. Stale vsak plati, ze vsetky parametre su predane hodnotou - tak ako to chape Java, nie C++ a teda "ukazatel" je skopirovany, stale vsak odkazuje na povodnu instanciu. Mate ale pravdu, ze to pre neJavistov moze byt matuce a obcas aj pre nich :)

[Petr Bravenec]

Ten ukazatel se kopíruje i v C. Nevím, jak v Javě, v C se na zásobník natlačí potřebné hodnoty předávaných parametrů (ano, ukazatel je předávaný hodnotou i v C), odkud si je pak funkce vybere.

V C mám ale podle parametru vždy celkem jasno, co v zásobníku najdu. Jasno má i překladač, takže na rozdíl mezi Int a int by mě upozornil - Java ne.

[kovariadam]

100% suhlas, problem primitivnych typov a autoboxingu, tiez ma to stalo nejednu hodinu hladania chyby.

[Petr Bravenec]

Koukám do nějaké učebnice a asi začínám tušit, proč se mi jeví Java tak matoucí.

Pominu-li fortran, mým prvním dobře zvládnutým programovacím jazykem bylo C++, a to ještě v době, kdy Java dosud vůbec neexistovala.

Java se v době svých počátků chvástala absencí ukazatelů (nejsme jako C!) a objektovostí (nejsme jako C!). To je první obrázek, který jsem si o Javě udělal: je objektová, nemá ukazatele... je to takové lepší C++.

Nemá-li Java ukazatele, nemůžeme přece ani tvrdit, že Java někam nějaké funkci ten neexistující ukazatel předává. I přizpůsobilo se názvosloví a všude jsem se dočetl, že Java vždy předává hodnotu. Že tou hodnotou je ukazatel a že mechanismus, jakým se hodnota předává, je naprosto shodný s předáváním ukazatele v C (to my neděláme, na ukazatele si v Javě nehrajeme), to už se v učebnicím Javy nedočtu. Jde přece o učebnici Javy, proč zmiňovat C, že?

Podle mě to udělali tvůrci Javy záměrně, ve snaze se distancovat od C a C++, a proto taky mě Java tak dlouho mátla. Pojmem "záměrně" nemyslím, že by si tvůrci řekli "tak, teď si uděláme z céčkarů prdel", spíš jen podřídili Javu, názvosloví a dokumentaci původní myšlence: "Java není C!"

Na "objektovost" javy jsem už taky tvrdě narazil... když jsem byl postaven před požadavek přepsat několik desítek tříd v C++ do Javy, přičemž každá třída měla v průměru pět předků

[JS]

Ja bych spis rekl, ze problem je v tom nazvoslovi "predavat parametr odkazem a hodnotou" (driv jeste bylo predavani jmenem, a to bylo teprv matouci!). Protoze problem neni v tom predavani, ale co se pak deje pri prirazovani v tele te funkce, jak popisuji niz. Mnohem lepsi je rozlisovat binding (tedy vazbu objektu v pameti a symbolu ve zdrojovem kodu) a zmenu hodnoty objektu, ale to se zase tezko mapuje na Cckovy, low-level model toho, jak funguje pocitac.

[Petr Bravenec]

Už taky vím, proč na ty bezesné noci strávené hledáním chyby vzpomínám s takovou nechutí. Překlepy se špatné hledají, zvlášť, pokud jsou syntakticky správně.

[deda.jabko]

Nic ve zlem, ale ma to byt typ `int' a `Integer'. Je to vec, ktera spolecne s autoboxingem muze udelat paseku, ale vic nez o navrhu jazyka to vypovida o spatnych znalostech programatora.

[Petr Bravenec]

OK. Beru. S daleko větší pravděpodobností to bylo Double a double.

[Petr Bravenec]

Vypovídá to o návrhu jazyka hodně.

Já se jako programátor můžu splést a přepsat se - použít Double místo double. To se mi stává denně.

V C++ takový omyl neprojde.

V Javě takový omyl ladím celou noc.

[kujon]

Vypovídá to o návrhu jazyka hodně.

Já se jako programátor můžu splést a přepsat se - použít Double místo double. To se mi stává denně.

V C++ takový omyl neprojde.

V Javě takový omyl ladím celou noc.

Možná by nebylo na škodu poohlédnout se po jiném zaměstnání. Tohle jsou problémy studentů z úvodních kurzů programování.

[podlesh]

Ale což o to, stane se, při použití neznámého jazyka celkem běžně. Zvlášť u "COBOLu 21. století". Spíš je docela zajímavé uvádět C++ jako příklad přehledného jazyka ve kterém i ten začátečník nespadne do žádné pasti.

[Petr Bravenec]

OK. Zkusím marketing.

[JS]

Možná by nebylo na škodu poohlédnout se po jiném zaměstnání.

Mozna bylo. Sam jsem v situaci, kdy musim pro zamestnavatele delat veci, v kterych jsem zacatecnik, protoze on v podstate nema moc na vyber (a i tak je spokojeny).

[podlesh]

Vypovídá to o návrhu jazyka hodně.

Já se jako programátor můžu splést a přepsat se - použít Double místo double. To se mi stává denně.

V C++ takový omyl neprojde.

V Javě takový omyl ladím celou noc.

Odolám pokušení říct něco jedovatého, takže jen pro informaci:
Veškeré "wrappery" (Integer, Double, Long, Short, Boolean) jsou totiž immutable, stejně tak String. A to právě z toho důvodu, že je pak jedno zda je v parametru int nebo Integer, double nebo Double. Chová se to konzistentně jako předávání hodnotou.

void do1(double d) {
d = 10.0;
}
void so2(Double d) {
d = 12.0;
}

void test() {
  double d1 = 1.0;
  Double d2 = 2.0;
  do1(d1);
  do1(d2);
  do2(d1);
  do2(d2);
  System.out.println(d1);
  System.out.println(d2);
}

Vypíše 1.0 a 2.0

Nejsem si zcela jistý proč tady dolik lidí píše že autoboxing je problém, ale s největší pravděpodobností naráží na problém s porovnáváním (operátor ==). Ten opravdu nefunguje u wrapperů dobře, ale nemá to naprosto nic společného s předáváním parametrů. V C# tento problém není a programátor ani nemusí vědět že tam nějaký boxing a autoboxing je. Groovy dtto. A to ani nezačnu o "dynamických" jazycích, kde je toto od začátku míněno jako implementační detail.

[Luboš Doležel (Doli)]

Ano. Zrovna porovnávání chování referencí/ukazatelů v C++ a předávání v Javě jsem měl u státnic.

//C++
void metoda(Typ* obj)
{
    obj->neco = 5; // projevi se u volajiciho
    obj = new Typ; // neprojevi se u volajiciho
}

// Java - bude se chovat identicky
void metoda(Typ obj)
{
    obj.neco = 5; // projevi se u volajiciho
    obj = new Typ(); // neprojevi se u volajiciho
}

Snad to trochu pomohlo objasnit. Z tohoto je pak jasné, že když v Javě napíšete

// arg je String
arg = "abcdef"

tak to odpovídá něčemu jako

// arg je std::string*
arg = new std::string("abcdef");

Ještě je nutné říct, že boxované typy v Javě jsou stejně jako řetězce neměnné. Takže když člověk přiřadí do Integeru novou hodnotu, vytvořil tím nový objekt, tudíž se to u volajícího neprojeví.

[kujon]

funkce(Int x) // předává se odkazem

Nejspíš je myšleno Integer. Opět se to oboje předává hodnotou, protože Integer x je reference na objekt a int x je primitivní typ.

public class a {
        static void funkce(Integer x) {
                x = 5;
        }

        public static void main(String args[]) {
                Integer x = 4;
                funkce(x);
                System.out.println(x);
        }
}

Vypíše se 4 a ne 5.

[mich]

Přesně tak. Díky tomu, že obalové třídy primitivních typů jsou immutable se ten překlep mezi double - Double nebo int - Integer stejně neprojeví.

[kovariadam]

Mate pravdu a zaroven to neni vzdy take jednoduche. Primitivny priklad:

public class Test {
        public static void main(String [] args) {
                Integer i = null;
                t2(i);

                System.out.println(i);
        }

        public static void t2(int i) {
                i = 10;
        }
}

Exception in thread "main" java.lang.NullPointerException
	at Test.main(Test.java:8)

V zlozitejsom kode, kde sa autoboxuje hore dole z Integeru na int a naspat a niekde tam prebuble null moze byt celkom blbe hladat chybu.

[kujon]

Projevit se to může v případě použití operátoru ==. Např.

Integer a = 10000;
Integer b = 10000;
System.out.println(a == b); // hodnota reference a se liší od hodnoty reference b

Výstup na openjdk 1.7 je false (může se to lišit podle implementace, protože instance třídy Integer můžou být cachované). Ale tohle je klasický případ programu co dělá to co programátor napsal a ne to co chce napsat.

[podlesh]

Hlavně je to příklad programu kde se parametry nepředávají ani hodnotou, ani referencí

[Martin Mareš]

No já myslím, že to je spíš příklad jazyka, který poněkud zmateně míchá dvě různé rovnosti, totiž rovnost hodnoty a identitu objektů (a jak koukám, tak také přiřazení objektů a inicializaci hodnoty).

[kujon]

Rovnost hodnoty je vždy == a identita objektů je vždy metoda equals. Operátor == se chová naprosto stejně jako nepřetížený operátor == v C/C++.

[JS]

Javu moc neznam, ale spis naopak, ne? Ve vyse uvedenem prikladu je 10000 ta stejna hodnota, ale objekty a a b maji ruzne identity (adresy v pameti).

[Martin Mareš]

No to je právě ten problém... "equals" je pro něco tak často používaného jako porovnání hodnoty dvou čísel tak nepohodlné, že každý píše "==", kdykoliv mu to projde.

(Nehledě na to, že používat u jazyka se syntaxí založenou na Céčku "==" k něčemu jinému než k porovnání hodnot, je vrchol nevkusu.)

[mich]

No to je právě ten problém... "equals" je pro něco tak často používaného jako porovnání hodnoty dvou čísel tak nepohodlné, že každý píše "==", kdykoliv mu to projde.

Každý určitě ne. Asi neexistuje jazyk, který by neměl svá, nováčky matoucí, specifika. Alespoň mírně zkušenější java programátor by ovšem == místo equals prostě nenapsal.

(Nehledě na to, že používat u jazyka se syntaxí založenou na Céčku "==" k něčemu jinému než k porovnání hodnot, je vrchol nevkusu.)

Nemůžu si pomoct, ale v C dělá operátor == to samé co v Javě.

[Martin Mareš]

Nemůžu si pomoct, ale v C dělá operátor == to samé co v Javě.

Nedělá. Pokud mám v C dvě čísla, tak operátor == porovná jejich hodnoty. V Javě mám čísla, kde porovnává hodnotu, a jiná čísla, kde to nedělá.

[mich]

Já bych to zkusil rozepsat, ať zjistíme v čem se mýlím (Pozn. budu brát jak velikost int tak velikost ukazatele 4B).

V C:

1)
int i1 = 3; //Lokální proměnná velikosti 4B (do těch se uloží hodnota 3)
int i2 = 4; //Lokální proměnná 4B (uloží se 4)
i1 == i2; //Dej na stack 4B co patří i1, pak dej na stack 4B co patří i2, porovnej dvě poslední hodnoty na stacku.

2)
struct neco *s1 = ...; //Lokální proměnná velikosti 4B, je to jen reference (uloží se do nich hodnota alokované adresy)
struct neco *s2 = ...; //To samé
s1 == s2; //Dej na stack 4B co patří s1, pak dej na stack 4B co patří s2, porovnej dvě poslední hodnoty na stacku.

3)
struct neco s1; //Lokální proměnná o velikost sizeof(struct neco)
struct neco s2; //To samé
s1 == s2; //error

V Javě:

1)
úplně stejné jako v C.

2)
Integer i1 = 3; //Vytvoří se instance třídy Integer a ta se uloží na heapu. i1 je zase jen reference - všechno je pointer, proto se ani nepíše. i1 je vlastně zase jen 4B adresa.
Integer i2 = 4; //To samé
i1 == i2; //Dej na stack 4B co odkazují na objekt i1, pak dej na stack 4B co odkazují na objekt i2, porovnej dvě poslední hodnoty na stacku.

3)
nemožné zapsat

Já tam ten rozdíl prostě nevidím.

[Martin Mareš]

"int i=1" a "Integer i=1" jsou po syntaktické stránce tatáž konstrukce, takže by člověk čekal, že se také chovají stejně. Jenže ouha, jedna z nich vyrábí referenci, zatímco ta druhá nikoliv. Proto "==" v jednom případě doopravdy porovná čísla a v druhém reference, přestože i v druhém případě vše v zápisu nasvědčuje tomu, že se jedná o číslo.

To je vidět i na případě "2". Sám u Céčka píšete "uloží se do nich hodnota alokované adresy". V Céčku ta alokace vidět je. V Javě se stane automagicky a dokud si člověk nepamatuje tabulku výjimek, tak nepozná, kdy se stane a kdy ne.

Jistě, je to všechno dobře definované, ale naprosto nepřirozené a pro programátora zbytečně matoucí.

[Ivan]

Ten rozdil se to pozna v okamziku kdyz s tema cislama zacnes delat neco poradnyho. Treba, kdyz zacnes s cislama pocitat:

int i = abs( 2 + 1 / 2);

zatimco:

BigDecimal i = ( BigDecimal(2).add(BigDecimal(1)).divide(Bigdecimal(2)).abs();

Numrika v Jave je peklo.

PS: ty dva priklady jsou zamerne neekvivalentni.

[JS]

Ja nechapu, co lide proti pretezovani operatoru tak maji. Vzdyt je to funkce jako kazda jina, akorat ma jiny identifikator. Je to znakovy rasismus. Znaky + a * nemuzou prece za to, ze nejsou soucasti abecedy. Proto mam rad jazyky, ktere respektuji neabecedni (popr. ne-ASCII) znaky a dovoluji identifikatorum, aby je obsahovaly.

[Ivan]

Primitivni datove typy (ty co zacinaji malym pismenem) jsou vyjimka.

Jinak jsou v Jave vsechny promenne reference. A s nicim jinym nez s referencemi a ani neda pracovat. Operator == oznacuje shodu referenci, zatimco pro "ekvivalenci" instanci objektu se pouziva metoda equals.

Cele se to zamota pri pouziti autoboxingu kde se typ int konvertuje na Int a zpet.

[JS]

Primitivni datove typy (ty co zacinaji malym pismenem) jsou vyjimka.

A jak znamo, bez podpory vyjimek by neslo o ten spravy objektovy jazyk.

[Sten]

Jen tak by mě zajímalo, proč operátor == porovnává reference a ne hodnoty. Vždyť ani tohle potom nemůže fungovat:

boolean isEqual(Object first, Object second) {
    return first == second;
}

String a = "A";
isEqual(a, a); // == false nebo true, podle implementace

[kovariadam]

Preco by to nemalo fungovat? x == y je true, pokial odkazuje na instanciu rovnakeho objektu.

[podlesh]

Tohle jednoznačně funguje a fungovat musí, žádný prostor pro implementační rozdíly tam není (viz specifikace). Jiná věc je, jak moc je to užitečné...

[Sten]

Aha, takže ten operátor porovnává hodnoty referencí (protože reference se kopírují, moc dobře znám z JNI). Tak už je to jasné

[Ladicek]

Myslím, že podlesh měl v tomhle případě hlavně na mysli internování řetězcových konstant…

[podlesh]

Ne, Sten to opravdu trefil. Internování je až další level, to už bych sem raději netahal - jsem rád když si alespoň někdo ujasní co jsou to vlastně ty hodnoty co se předávají.

[Ladicek]

Taky fakt…

[Sten]

Jenom doplním, že důvod toho zmýlení byl ten, že v JNI takový kód *je* implementačně závislý. Ale to je problém toho, jak strašně je JNI udělané.

[kralyk z abclinuxu]

Operator == oznacuje shodu referenci, zatimco pro "ekvivalenci" instanci objektu se pouziva metoda equals.

Takže chápu to správně, že pro porovnání hodnoty nemá Java jazykový prostředek, pouze konvenci?! ... To je tedy velmi vtipný jazyk, jak tak na to koukám

[mich]

Není dobré hodnotit věci jen podle "koukání". Metoda equals je metodou třídy Object, která je předkem všech tříd v Javě. Není to jen konvence, to už bychom mohli i "==" nazývat konvencí.

[kralyk z abclinuxu]

Oh, mea culpa, tak to pak jo.

[kovariadam]

http://docs.oracle.com/javase/6/docs/api/java/lang/Object.html#equals(java.lang.Object)

[elenril]

V C a C++ je jasno vždy - s hvězdičkou ukazatel, bez hvězdičky hodnota.

Dokud se nenajde chytrák co udělá typedef void* gpointer; a tvrdí, že

An untyped pointer. gpointer looks better and is easier to use than void*.

[Petr Bravenec]

Hehe, to mi něco říká. Gtk?

[elenril]

glib

Takovéhle lidi, které buď děsí pohled na hvězdičku, nebo neumí počítat do tří (víc úrovní hvězdiček člověk prakticky nikdy nepotřebuje), bych odsoudil k doživotnímu programování v BASICu.

[Petr Bravenec]

...bych odsoudil k doživotnímu programování v BASICu.

Pro Excel

[pavlix]

Já jsem v Glib něco málo napsal, a typedef na gpointer mi připadá příjemný. Glib totiž není jenom knihovna, ale i způsob práce, a musím říct, že způsob práce, který bere vítr z plachet většině odpůrců čistého C.

[elenril]

Nějak mi uniká čím vlastně má být gpointer easier to use. Jediné co přináší je obfuskace -- ta hvězdička není vidět. Ale pořád si musíš pamatovat, že tam je.

[JS]

Takze jste proti typedefum na pointery obecne?

[elenril]

Ano. Nenapadá mě jediný dobrý důvod proč by se měly používat.

[JS]

Me take ne. Ale prijde mi, ze hodne lidi to dela, ze treba definuje pointer na strukturu jako typ.

[kralyk z abclinuxu]

Třeba libpng to tak má. Pointa mi ale uniká... Asi se někomu nechtěj psát hvězdičky.

[podlesh]

Také jsem nevěděl, ale tato diskuse mi to objasnila: je to kvůli lidem co si myslí že bez hvězdičky se jedná o předávání hodnotou, s hvězdičkou se jedná o předávání odkazem.

[Sten]

Pokud je to typedef na čistý pointer a ne na chytrý pointer, tak ta hvězdička navíc přeci nikoho nezabije, ne? (Obzvlášť když ten pointer stejně mívá prefix nebo suffix „p“ nebo „p_“)

Jediný, co mě napadá jako trochu rozumný důvod, je:

struct neco *a, b; // b není pointer

typedef struct neco* p_neco;
p_neco a, b; // b je pointer

Btw. proto píšu hvězdičku k tomu, k čemu se vztahuje, u typedefu ke struktuře, u proměnných k proměnným.

[miso]

Obzvlášť když ten pointer stejně mívá prefix nebo suffix „p“ nebo „p_“

Hungarian notation sa urcite nepouziva vsade

[pavlix]

ta hvězdička není vidět

Mno já nevím, já si vždycky myslel, že ta hvězdička v C znamená pointer. A že by slovo pointer v názvu gpointer nebylo vidět... není to spíš problém očí?

[kralyk z abclinuxu]

Název je pouhá konvence, proč se spoléhat na konvenci?

[Martin Mareš]

To ano, ale zapisovat referenci na objekt stejnou syntaxí, jako by se jednalo o objekt samotný, je svého druhu čuňačina. Ta pak vede k tomu, že existují dva integery (primitivní a objektový), které se zapisují takřka stejně, ale předávají úplně jinak. Ouvej.

[kovariadam]

Problem je v tom, ze primitivne typy vobec existuju a z historickych dovodov sa ich nemozno zbavit. V syntaxi by som problem nehladal.

[kralyk z abclinuxu]

A na primitivních typech je tak špatného co?

Ono totiž oprostit se od faktu, že počítač má taky nějaký hardware, tak úplně nepůjde nikdy...

[kovariadam]

Nevyhodou je to, ze nie su objektove a teda tak nejak nezapadaju do zvysku sveta v Jave. Vyhodou by mohlo byt, ze maju mensie pamatove naroky, otazne je, ci by neslo optimalizovat pouzitie objektovych typov na urovni JVM tam kde to ma zmysel. Tu poznamku s hardwarom nechapem, existuje predsa mnozstvo jazykov bez primitivnych typov.

[kralyk z abclinuxu]

No, jde o to, že člověk občas přecijen potřebuje nízkoúrovňové věci na základních typech, třeba manipulovat s bity a podobně. Ono všeobecně, pokud by se okolo základních typů lepila další vrstva, práci s nimi by to spíš komplikovalo. Když už by někdo potřeboval, aby se k tomu přistupovalo stejně jako k objektům (třeba integer.toString() a podobně), určitě by se to dalo nějak vhodně syntakticky pocukrovat.

[kovariadam]

Nizkourovnove ako aj hociake ine operacie mozes implementovat objektovo, nevidim dovod preco nie. Ja mam pocit, ze dnes pracu komplikuje skor pouzitie primitivnych typov(nemoznost mat hodnotu null) ako ich objektove varianty. Okrem toho vznikaju nedorozumenia pri volaniach funkcii, autoboxing hore-dole... Celkovo je to len zmatok ak su v jazyku aj objektove aj primitivne typy na ten isty ucel.

[kralyk z abclinuxu]

Nizkourovnove ako aj hociake ine operacie mozes implementovat objektovo, nevidim dovod preco nie.

No, tak nejsem si jist, jestli vidím důvod, proč ano. No ale dejme tomu, já v zásadě nejsem proti, pokud se to napíše rozumně - čili tak, aby ty objektové vlastnosti byly pouze asociovány s tím samým primitivním intem, oproti návrhu, kdy vytvářejí okolo primitivních typů vrstvu, to je akorát bloat.

nemoznost mat hodnotu null

No to je snad dobře, ne? Možnost null mi u integeru přijde zbytečná obtíž. Ona je to teda zbytečná obtíž i u objektů obecně, což je důvod, proč se v C++ na null nehraje...

[Ladicek]

nemoznost mat hodnotu null

No to je snad dobře, ne? Možnost null mi u integeru přijde zbytečná obtíž. Ona je to teda zbytečná obtíž i u objektů obecně, což je důvod, proč se v C++ na null nehraje...

Co je ve skutečnosti potřeba jsou nullable a non-nullable typy. Nullable v případě, že potřebujeme vyjádřit singulární situaci "aktuální hodnota není známá". Magické konstanty (typicky oblíbená -1) nejsou řešení.

[kralyk z abclinuxu]

Ok, osobně si teda myslim, že by se člověk měl situacím "aktuální hodnoty není známa" vyvarovat, no ale když už to teda chce někdo používat, melo by se důrazně oddělit null ve smyslu nullable a null ve smyslu null reference/pointer/object, protože oboje je něco úplně jiného...

[deda.jabko]

Co je ve skutečnosti potřeba jsou nullable a non-nullable typy. Nullable v případě, že potřebujeme vyjádřit singulární situaci "aktuální hodnota není známá". Magické konstanty (typicky oblíbená -1) nejsou řešení.

null je celkove kontroverzni zalezitost a nechtel bych do toho zabredavat. Nicmene, zavedeni ,,null'' jako nedefinovane hodnoty je de facto stejny hack, jako zavedeni magicke konstanty.

[pavlix]

U dynamicky typovaného jazyka to pak hack není, protože to perfektně zapadá do způsobu práce s dynamicky typovanými proměnnými. Příkladem budiž Pythoní None.

[Ladicek]

Výhoda je, že null může být pořešené na úrovni typového systému, toho s magickými konstantami nedosáhneš. Problém je v tom může být… ono totiž často není

[Sten]

Tohle by se bez problémů dalo řešit pomocí inline implementace toho objektu. Ale to jsme zase u C++

[Ladicek]

Jedinou rozumnou manipulaci s bity jsem viděl v Erlangu (což je dost vysokoúrovňový jazyk). Ten Céčkový styl s bitovými operátory je šílený.

A žijeme ve třetím tisíciletí, dneska už si můžeme dovolit vynechat primitivní typy, použít (objektová) čísla s libovolnou přesností (aspoň ta celá) a nechat na překladači/runtimu, aby to zoptimalizoval.

[Martin Mareš]

Až takové překladače budeme umět vyrobit, tak bezpochyby

[Ladicek]

IMHO už to umíme, řekl bych, dostatečně dobře pro velkou většinu případů.

[kralyk z abclinuxu]

A když si třeba potřebuju napsat vlastní číselný typ? Třeba nějaký ten big int, fixed-point real, BCD a já nevim jaké další speciality? To se pak asi můžu jít klouzat...

Krom toho, takový kompilátor je šíleně složitý a náročný (nehledě k tomu, že v praxi by stejně problém neřešil), a to všechno za jakým účelem? Aby pár lidí mělo nejasný hřejivý pocit konzistence z jazyka, kde všechno je objekt...

[Ladicek]

Když potřebuješ vlastní číselný typ, tak si ho prostě napíšeš, stejně jako kdekoli jinde.

Hledáš problémy kde nejsou (opět viz Erlang) a označuješ za hřejivý pocit kriticky důležité zásady (o tom, jak jsou kritické, svědčí půlka téhle diskuse). Na to můžu snad jenom: proč lžeš?

[kralyk z abclinuxu]

Aha, ok, v tom případě mi není jasný, v čem ono "zbavit se primitivních typů" spočívá, když v podstatě jediný změny jsou arbitrary precision arithmetic a to, že tomu budem nově říkat "objekt"...

[pavlix]

No, když jsi někde na úrovni Javy... tak se stačí podívat na Python, ten sice umí nějakým způsobem pracovat s primitivními typy, ale pracuje s nimi jen zabalenými do objektů a jen v případech, kdy potřebuje interfacing s céčkovským kódem.

Obvykle je lepší volit opačný proces, tedy doplnit céčkovský kód o wrapper, který zpřístupní data Pythonímu kódu, protože tak vzniká přirozené Pythoní API s možnostmi optimalizace a provádění výpočtů na úrovni céčka.

Vtipné je, že v Pythonu (3) vůbec nepotřebuješ řešit nějaká malá a velká celá čísla, Python si řídí vnitřní implementaci automaticky bez vlivu na API, to je pro obecná celá čísla.

[Ladicek]

V tom, že se ta čísla budou chovat jako objekty. Né že bych potřeboval nebo chtěl na čísle metodu sin (i když abs bych skousnul), ale například je půjde cpát do kolekcí (konkrétně v Javě).

[Martin Mareš]

Pokud jazyk některé věci předává odkazem a jiné hodnotou, a tak to prostě na syntaktické úrovni v Javě je – existenci referencí syntaktická úroveň zcela zamlčuje &ndash, pak je taková syntaxe zvolena nevhodně.

[kovariadam]

Primitivne typy su zaroven klucove slova v Jave, su teda syntakticky odlisene od ostatnych premennych. Nestaci to?

[Martin Mareš]

Rozdíl mezi klíčovým slovem a identifikátorem je spíš formální a pokud člověk zrovna nepíše překladač, narazí na něj jen tehdy, když nějaký identifikátor nemůže použít proto, že se tak jmenuje nějaké klíčové slovo.

(To je v Javě vůbec veselé: jestli mě paměť neklame, tak const a goto jsou klíčová slova, jejichž libovolné použití je syntakticky špatně )

[kovariadam]

Takze kolko krat je este treba zvyraznit, ze primitivne su hodnotove, vsetky ostatne referencne? Klucove slova nestacia, mala by sa davat vsade este hviezdicka alebo aspon 10 vykricnikov, aby to uz konecne kazdy pochopil? :)

Tu zatvorku nechapem, ktorych klucovych slov je lubovolne pouzitie syntakticky korektne?

[Martin Mareš]

Takze kolko krat je este treba zvyraznit, ze primitivne su hodnotove, vsetky ostatne referencne?

Však ano, ale problém je v syntaxi, která tento rozdíl zamlčuje.

Jsou v zásadě dvě možnosti, jak tuto situaci rozumně vyřešit: buďto explicitně rozlišovat mezi referencí a hodnotou (což dělá Céčko), nebo naopak přiblížit chování primitivních typů těm objektovým a nemíchat různé typy rovnosti (viz třeba Perl6).

Tu zatvorku nechapem, ktorych klucovych slov je lubovolne pouzitie syntakticky korektne?

Ve slušné společnosti má každé klíčové slovo aspoň jedno syntakticky korektní použití. V Javě ho ani const, ani goto nemají.

[kovariadam]

Aha tak, no idealne by podla mna bolo keby primitivne typy neboli a nebol by problem. To riesenie typu perl6 mi pride ako znesitelne.

No goto sa normalne da pouzivat pred cyklom napriklad, const teda neviem, mozno malo nejake planovane vyuzitie a nevyuzilo sa alebo naopak sa rezervovalo len tak pre istotu...

[Ladicek]

Takze kolko krat je este treba zvyraznit, ze primitivne su hodnotove, vsetky ostatne referencne?

Však ano, ale problém je v syntaxi, která tento rozdíl zamlčuje.

Referenční typy jsou v Javě pole a objekty (instance tříd). V místě deklarace proměnných (tedy i parametrů) se rozdíl mezi primitivním a referenčním typem pozná snadno – za typem pole jsou závorky [], třídy zase z konvence začínají velkými písmeny. V místě použití… hmm, a fakt to tolik vadí? S výjimkou toho šíleného auto(un)boxingu, kde může spadnout shůry NPE, bych řekl, že to není problém.

Ovšem souhlasím, že primitivní typy by bylo nejlepší vykopat (a s nimi spoustu dalších věcí).

[deda.jabko]

Referenční typy jsou v Javě pole a objekty (instance tříd). V místě deklarace proměnných (tedy i parametrů) se rozdíl mezi primitivním a referenčním typem pozná snadno – za typem pole jsou závorky [], třídy zase z konvence začínají velkými písmeny. V místě použití… hmm, a fakt to tolik vadí?

Presne tak.

Ovšem souhlasím, že primitivní typy by bylo nejlepší vykopat (a s nimi spoustu dalších věcí).

Hromada tech veci je dana historicky a nejde s tim nic moc delat, ale myslim, ze Java je na tom jeste docela v pohode. V C# je tech zverstev daleko vic, napr. class vs. struct, modifikatory argumentu out/ref, ... a osobne si myslim, ze i pretezovani operatoru je zlo

[kralyk z abclinuxu]

a osobne si myslim, ze i pretezovani operatoru je zlo

No počkat, zbavení se primtivních typů by bez přetěžování operátorů vůbec nešlo. Jakpak bys bez něj nadefinoval třeba operátor + pro (objektové) integery? Leda by se definice operátoru + svázala s nějakým konkrétním typem nějaké konkrétní knihovny a to mi přijde jako vyloženě blbej nápad...

[JS]

Struct v C# smysl ma, stejne jako pointery. Je to sice mozna osklive, ale da se to pochopit. S out/ref si nejsem jisty, ale mozna se to chova jinak v optimalizacich. C# je takovy dort co varili pejsek s kocickou. Je tam vsechno, i kdyz to dokupy nedava smysl a divne to chutna.

[Ladicek]

Určitě, C# je dost šílený slepenec. Přetěžování operátorů jsem taky považoval za zlo, ale v rozumně omezené podobě (kdy existuje jen předem daná sada operátorů, které jde přetěžovat, a jsou to vlastně jen jinak zapsané metody) jsem ho před časem rehabilitoval. Čísla přece jenom potřebujeme. A nedávno jsem měl chuť přetížit operátory logického součtu a součinu, ale naštěstí to v daném jazyce (Dartu) nejde

Out a ref jsou ještě jiná věc: někdy by se fakt hodily, protože velká většina jazyků umí vrátit z funkce/metody jenom jednu hodnotu. Radši bych viděl vracení libovolného počtu hodnot (nebo aspoň podporu tuplů), ale out/ref parametry jsou taky řešení. A dá se na to nahlížet tak, že out parametry jsou vlastně jen jinak zapsané návratové hodnoty.

[Martin Mareš]

No právě, výstupní parametry jsou v podstatě jen ošklivý hack na obejití toho, že jazyk neumí vracet více hodnot :)

[JS]

No C#, podobne jako Python, muze vracet Tuple, ale ta syntaxe je asi priserna..

[Roger]

Asi? :) Párkrát jsem ho použil, jenže vždycky jsem z toho měl mrazení v zádech.

Python (bohužel) neznám, ale moc se mi líbila syntaxe v PHP, kde šlo napsat něco jako:

list($var1, $var2) = funkce_vracejici_dvouprvkove_pole()

[JS]

No, C# jeste nemam prilis zazite, prestoze jsem nucen v nem programovat. Tusil jsem, ze tam neco jako Tuple jsou, ale predpokladal jsem (spravne - shodou okolnosti jsem je dnes zrovna pouzil), ze destructuring C# neumi.

[JS]

Jo, k tomu Pythonu, Python ma unpacking tuplu (i kdyz tam se tomu rika unpacking), takze muzete napsat treba:

t = (x,y,z)   # vytvoreni tuple t
...
x,y,z = t     # unpacking tuple t do promennych x,y,z

Specialne pak v Pythonu:

a,b = b,a     # prehodi a a b

V obecnejsi podobe tohle umi (Common) Lisp a rika se tomu destructuring.

[pavlix]

Jen tě doplním, ty závorky nejsou potřeba v žádném z tvých případů:

t = 1, 3, 5                   # ulozi do promenne t tuple (1, 3, 5)
x, y, z = t                   # rozbali tuple do promennych x, y, z
a, b, c = 1, 2, 4             # ulozi a=1, b=2, c=4
a, b = b, a                   # prohodi a s b
a, b, c = b, c, a             # rotuje a, b, c
podil, zbytek = divmod(7, 3)  # ulozi do promennych celociselny podil 
                              # a zbytek, pricemz delenec je 7 a delitel 3

[JS]

Ja vim, ale vetsinou je tam pisu, pro prehlednost. A chtel jsem v tom prvnim pripade zduraznit, co se deje.

Ono by jeste stalo za zminku operator *, kterym se da ignorovat libovolny pocet prvku pri unpackovani, ale v Pythonu uz jsem nejaky cas nedelal, takze si to uz z hlavy nepamatuji.

[pavlix]

Python (bohužel) neznám, ale moc se mi líbila syntaxe v PHP, kde šlo napsat něco jako:

Python je v tomhle přirozenější, viz níže.

[Ondrej 'SanTiago' Zajicek]

Takze kolko krat je este treba zvyraznit, ze primitivne su hodnotove, vsetky ostatne referencne?

Však ano, ale problém je v syntaxi, která tento rozdíl zamlčuje.

A je to problem? Pokud by to bylo striktne takhle (primitivni typy predavane hodnotou, vse ostatni referenci), tak to je IMHO konzistentni, protoze na hodnoty primitivnich typu[1] lze nahlizet jako na referenci na 'idealni immutable objekt' (ktery je navic jednoznacny pro kazdou hodnotu), a tedy pro ne neni rozdil mezi predavanim hodnotou a referenci [2].

[1] takhle se bezne chovaji primitivni typy, ale obecne lze toto chovani rozsirit i na jine 'immutable' objekty, ve Scheme se tak treba chovaji i symboly a bignumy.

[2] samozrejme je treba rozlisit mezi predavanim reference na (realny ci idealni) objekt a predavanim reference na promennou/cell, kde je ta reference na ten objekt.

[podlesh]

[1] takhle se bezne chovaji primitivni typy, ale obecne lze toto chovani rozsirit i na jine 'immutable' objekty, ve Scheme se tak treba chovaji i symboly a bignumy.

V Javě je typický příklad String.

[Martin Mareš]

Pokud by se jako ideální immutable objekty chovaly i objektové integery, pak je to samozřejmě konsistentní. Jenže v Javě se tak pokud vím nechovají.

[JS]

Ve slušné společnosti má každé klíčové slovo aspoň jedno syntakticky korektní použití. V Javě ho ani const, ani goto nemají.

To mi divne neprijde. Co je na tom divne je spis to, kdyz uz mit v jazyce rezervovana klicova slova, ktera (zatim) nemaji semanticky vyznam, proc nerezervovat nekonecnou mnozinu spis nez 2-prvkovou.

[Martin Mareš]

Já za tím zrovna u Javy vidím spíš poněkud povýšenecký názor tvůrců jazyka, že goto je zlo, než plánované rozšíření jazyka

[JS]

Nevim, to se mi zda prehnane. Rezervovat to, aby to nikdy nemuseli pridat? Jak to bylo v pripade enum? Ale uznavam, ze ten nazor maji.

[JS]

Me prijde ze je to sveho druhu neresitelny problem. Treba Python predava vsechno odkazem (nebo hodnotou reference?), ale pak se ten rozdil presune do problemu imutabilni/mutabilni typ. Rad bych videl jazyk, ktery to nedela (mozna Haskell nebo jine funkcionalni bestie, kde lze priradit neco jen jednou a provzdy).

[pavlix]

Mě tedy přijde, že tohle je typický příklad předávání referencí (tedy víceméně odkazem), opak předávání hodnotou.

[podlesh]

Je to předávání hodnotou, akorát někdy je ta hodnota typu "ukazatel". Úplně stejně jako v C. Že tam chybí hvězdička? V C být nemusí, viz uváděný gpointer.

[pavlix]

Je to předávání hodnotou, akorát někdy je ta hodnota typu "ukazatel".

Kterýžto typ mimochodem údajně v Javě neexistuje a údajně je to jedna z jejích hlavních výhod oproti C/C++.

Že tam chybí hvězdička? V C být nemusí, viz uváděný gpointer.

Souvislost s hvězdičkovou syntaxí mi zcela uniká.

[kovariadam]

Je to předávání hodnotou, akorát někdy je ta hodnota typu "ukazatel".

Kterýžto typ mimochodem údajně v Javě neexistuje a údajně je to jedna z jejích hlavních výhod oproti C/C++.

Typ ukazatel v ponimani Cecka v Jave skutocne NEEXISTUJE. To, ze sa to tu obcas v uvodzovkach objavi, na tom nic nemeni. Ukazatel v cecku ma definovanu ukazovatelovu aritmetiku, pricom nic take v Jave neexistuje. V Jave je kazda premenna s vynimkou primitivnych typov referencnou premennou, tzn. odkazuje na instanciu nejakeho objektu a to je asi tak vsetko co ma spolocne s ukazatelom v Cecku.

[pavlix]

tzn. odkazuje na instanciu nejakeho objektu

To mimochodem odkazuje i obyčejná „hodnotová“ proměnná v C nebo C++, jak dokazuje i operátor &.

[kovariadam]

V cecku operator & vracia adresu v pamati. Snad uznate, ze v Jave nic take nebude mozne.

[pavlix]

V cecku operator & vracia adresu v pamati.

Thank you, Captain Obvious.

Snad uznate, ze v Jave nic take nebude mozne.

Thank you, Captain Obvious.

[kovariadam]

Chcel som poukazat na odlisnu uroven abstrakcie Javy a Cecka a tym ukoncit to nekonecne porovnavanie ukazatelov s referencnymi typmi. Kazdopadne nemate zac.

[JS]

Rozdil je IMHO v tom, ze pri prirazeni do promenne predavane odkazem se modifikuje stejne misto v pameti, kdezto pri prirazeni do promenne predane hodnotou se jen meni vazba. Proto nektere jazyky (treba Lisp) rozlisuji mezi vazbou (binding, coz se dela treba pomoci LET/DEFVAR) a prirazenim (coz se dela treba pomoci SETF/SETQ).

[pavlix]

Asi budeš mít v zásadě pravdu, ale IMO je celý problém v tom, že se používá úplně nesmyslná terminologie, která v Javě nefunguje.

Předávání objektů hodnotou tak jako je to v C a C++ totiž Java podle toho, co jsem pochopil, obecně vůbec neimplementuje.

Předávání referencí v pravém smyslu neimplementuje C. Implementuje ho C++ v plném rozsahu. Objekt lze uvnitř funkce modifikovat. Java dělá prakticky úplně to samé, liší se pouze tím, co dělá operátor přiřazení. Zatímco v C++ standardně provádí mělkou kopii, v Javě zřejmě provádí změnu lokální reference (která je v C++ neměnná). Všechno ostatní funguje stejně, tedy lze modifikovat atributy objektu a nelze původní proměnná nijak přesměrovat.

C (a C++) navíc implementuje ukazatel a tím pádem předávání ukazatelem čili předává se paměťová adresa objektu. To s trochu jinou syntaxí dokáže to, co reference v C/C++ a k tomu zřejmě přesměrovávat lokální ukazatel jako to umí Java. Tedy nic nového pod sluncem.

C a C++ ještě navíc implementuje dvojitý ukazatel, čímž se do funkce přenese možnost zapisovat do vzdáleného ukazatele na objekt. Proměnná tak funguje jako výstupní. V Javě se to bude muset nejspíš řešit přes nějaký kontejner, například jednoprvkový seznam (alespoň tak to funguje třeba v Pythonu).

Takže když si z toho všeho vyberu, tak zvlášťě za nepřítomnosti pointerů v Javě, podle mě Javovské předávání parametrů v praxi přesně odpovídá C++kovému předávání parametrů odkazem.

[podlesh]

Ano, je to nesmyslná terminologie. Máme tři možnosti:

1. Popsat chování pomocí "céčkových" termínů. To není takový problém, protože tyto termíny odpovídají i reálné implementaci: kdekoliv se pracuje s objekty, tak je tam stejně interně ukazatel.
2. Používat "necéčkové" koncepty. Pomůže podívat se na místa kde tyto koncepty vznikly (LISP, Smalltalk, atd) a ignorovat popisy kategorie "from C to Java in 5 minutes" (nemluvě o kategii "Java for enterprise managers").
3. Divoce spekulovat na diskusním fóru.

[vencour]

Přidal jsem do digestu.