C++ hacking (diskuse)

[Heron]

char& foo()
{
        static char inner = 'a';

        return a;
}

Má tam být return inner;

[paskma]

Zalepeno. Dík.

[Michal Marek (twofish)]

foo() = 'b'; // přiřadí do proměnné inner 'b' cout << foo(); // vytiskne béčko

Čili máme nádherný getter - setter, o kterém se žádnému javistovi ani nesní .

To se od C liší jen ve hvězdičce před foo(), the C++ way by byla třída foo s operátorem=, operátorem<< pro ostream, konverzním operátorem na char a tak dál

[paskma]

Liší se to tou hvězdičkou a právě proto to v kódu vypadá tak kouzelně.

[Luk]

...a proto je to taky pěkná prasárna. Na čitelnosti kódu to rozhodně nepřidá.

[Heron]

Kdo si myslí, že pole a ukazatel je v céčku jedno a to samé, ten C neumí.

OK, neumím C, jaký je tedy rozdíl mezi polem a ukazatelem?

[Michal Marek (twofish)]

Do pole nejde přiřadit.

[Michal Marek (twofish)]

$ cat array.c 
#include <stdio.h>

void f(char**p)
{
        *p += 1;
}

int main()
{
        char a[5] = "ahoj";
        char *p = a;

        printf("a (%p): \"%s\";  p (%p): \"%s\"\n", a, a, p, p);
        f(&p);
        printf("a (%p): \"%s\";  p (%p): \"%s\"\n", a, a, p, p);
        f(&a);
        printf("a (%p): \"%s\";  p (%p): \"%s\"\n", a, a, p, p);

        return 0;
}
$ gcc -Wall array.c 
array.c: In function ‘main’:
array.c:17: warning: passing argument 1 of ‘f’ from incompatible pointer type
$ ./a.out 
a (0xbffc1d43): "ahoj";  p (0xbffc1d43): "ahoj"
a (0xbffc1d43): "ahoj";  p (0xbffc1d44): "hoj"
a (0xbffc1d43): "bhoj";  p (0xbffc1d44): "hoj"

[Michal Kubeček]

Např.

  char a[] = "Hello, world!";
  char* p;

  p = a; /* OK */
  a = p; /* nelze */

  printf("sizeof(p) = %lu\n", sizeof(p));
  printf("sizeof(a) = %lu\n", sizeof(a));

[Heron]

Díky tobě i twofishovi, už je mi to docela jasné.

[Luk]

A navíc:

char a[] = "abcd";
char* b = "abcd";

a[0] = 'x';  // OK
b[0] = 'y';  // viz níže

Tohle je velice záludné a nebezpečné, protože to mnohé kompilátory neodhalí, a program někdy běží a jindy padá. a je normální pole vytvořené na zásobníku a inicializované příslušným řetězcem. Kdežto b je ukazatel na konstantní řetězec (mělo by tedy správně být const char* b). Kompilátory ale většinou dovolí (dokonce bez varování) použít nekonstantní pointer, a problémy se vyrojí až za běhu.

[Ladislav Thon]

Kdo si myslí, že pole a ukazatel je v céčku jedno a to samé, ten C neumí.

Neumím C a jsem přesvědčen, že pole a ukazatel je v Céčku jedno a to samé. Lépe řečeno, že pole je syntaktický cukr pro ukazatelovou aritmetiku.

[#Tom]

Je mnoho případů, kdy je to úplně stejné. Lépe řečeno - vypadá to úplně stejně. Pořádná sranda začíná teprve s vícerozměrnými poli.

void funkce(char *parametr) {
  int i;
  for (i = 0; i < 256; i++)
    parametr[i] = 0;
}

void slozitejsi(char *pole[256]) {
  int i, j;
  for (i = 0; i < 256; i++)
    for (j = 0; j < 256; j++)
      pole[i][j] = 0;
}

int main() {
  char prvni_pole[256];
  char *druhe_pole = (char *) malloc(256);
  char *treti_pole[256];
  char **ctvrte_pole = (char **) malloc(256*sizeof(char *));
  char pate_pole[256][256];
  int i;
  for (i = 0; i < 256; i++) {
    treti_pole[i] = (char *) malloc(256);
    ctvrte_pole[i] = (char *) malloc(256);
  }

  /* toto se chová stejně */
  funkce(prvni_pole);
  funkce(druhe_pole);

  /* tohle také */
  slozitejsi(treti_pole);
  slozitejsi(ctvrte_pole);

#if 0
  /* tohle nejde */
  slozitejsi(pate_pole);
#endif
  
  return 0;
}

[paskma]

Ne, Ladislave. Pole je uspořádana homogenní n-tice. Ukazatel je ukazatel. S polem se většinou pracuje pomocí ukazatele na první prvek. Proto to lidi nerozlišují.

Pole je auto. Ukazatel je volant, kterým se auto řídí. Je volant auto?

[Ladislav Thon]

Pole je uspořádana homogenní n-tice.

Což vyžaduje kontrolu mezí, která jak známo v Céčku co? No není :)

OK, pár příspěvků v této diskusi mne přesvědčilo o tom, že skutečně nelze zaměňovat pole a ukazatel. Ale na tom, že céčkovské pole není skutečné pole, trvám :)

[#Tom]

V C++ lze nadefinovat pole podle vlastního vkusu. Přetíží se operátor [] tak, aby se kontrolovaly meze, a je to.

[Miloslav Ponkrác]

Ach jo. Céčkové pole JE SKUTEČNÉ POLE. Mnoho jiných programovacích jazyků ukládá pole v paměti naprosto stejným způsobem jako C, a přitom nemají s tímto jazykem nic společnému a třeba se mu ani vzdáleně nepodobají a třeba nemají ani adresovou aritmetiku.

Céčkové pole není ukazatel, a to ani náhodou. Pole je prostě pole se vším všudy a chová se jako pole v ijných jazycích, tedy nikoli jako ukazatel. Specialita C je pouze to, že název pole lze použít jako ukazatel na začátek pole, ale to z pole ještě nedělá ukazatel.

Uspořádáná homogenní n-tice samozřejmě kontrolu mezí nutně nevyžaduje. A C++ je tak flexibilní, že vyrobit obecné pole s kontrolou mezí je záležitost na několik málo řádků.

[Ladislav Thon]

Uspořádáná homogenní n-tice samozřejmě kontrolu mezí nutně nevyžaduje.

Pětice, která mi je ochotna vrátit svůj šestý (nebo nedej bože mínus prvý) prvek podle mne není pětice, nýbrž hodně divný způsob nepřímého přístupu k paměti (ukazatel ;) ).

[paskma]

Ale on ho obecně nevrátí

[Ladislav Thon]

Právě že ho obecně vrátí -- akorát jí v tom občas zabrání OS :)

[#Tom]

C++ mám taky rád. Třeba Turbo Pascalu se jednotky daly inicializovat třeba tak, že se v nich udělal klasický begin end. blok. Tato věc mi v C chyběla.

static void __attribute__((constructor))
je_mi_smutno_po_begin_end_bloku() {
  /* něco si tu udělám */
}

Ale není to moc podle normy...

V C++ lze dělat i takovéto skopičiny. (Pro zajímavost přikládám celý program, který je inspirován tímto zadáním: http://www.fi.muni.cz/usr/jkucera/pb161/color.htm)

#include <iostream>
#include <string>

using namespace std;

class ColorMap {
private:  
  ColorMap();
public:  
  static ColorMap colormap;
  static const int colorcount;
  static char colors[];
  static int inv_colors[256];
};

const int ColorMap::colorcount = 8;
char ColorMap::colors[] = "KRGYBMCW";
int ColorMap::inv_colors[256];
ColorMap ColorMap::colormap;

ColorMap::ColorMap() {
  int i;
  for (i = 0; i < 256; i++) inv_colors[i] = -1;
  for (i = 0; i < colorcount; i++) {
    inv_colors[static_cast<int>(colors[i])] = i;
    inv_colors[static_cast<int>(colors[i]) + 0x20] = i;
  }
}

class color {
public:
  color(const char _color = 'K') :
    color_int(ColorMap::inv_colors[static_cast<int>(_color)]) { }
  color(const color& _color) : color_int(_color.color_int) { }
  color operator+ (const color& c) const {
    color newcolor(*this);
    newcolor.color_int |= c.color_int;
    return newcolor;
  }
  color operator* (const color& c) const {
    color newcolor(*this);
    newcolor.color_int &= c.color_int;
    return newcolor;
  }
  friend std::ostream& operator<< (std::ostream& s, const color c) {
    return s << ColorMap::colors[c.color_int];
  }
  friend std::istream& operator>> (std::istream& s, color& c) {
    char _color;
    int color_int;
    while (s >> _color) {
      if ((color_int = ColorMap::inv_colors[static_cast<int>(_color)]) >= 0) {
        c.color_int = color_int;
	break;
      }
      cout << "Zadání barvy bylo chybné, zadejte, prosím, jedno z písmen "
        << ColorMap::colors << ": "; 
    }
    return s;
  }
  int color_int;
private:
};

[Miloslav Ponkrác]

Náhodou C++ je nádherný jazyk! Jeho kouzlo je v tom, že vás zbytečně nevodí za ručičku a nepřekáží vám tam, kde to nechcete. Kdyby C++ mělo lepší knihovny, tak je to nepřekonatelný jazyk. Přiznám se, že C++ je jeden z několika mála programovacích jazyků, kde programovat mě skutečně baví.

A jen tak mimochodem, v čem jsou jako reference bezpečnější, než ukazatele? Pokud byste psal v C++ víc, tak byste věděl, že reference jsou daleko záludnější. Ukazatele jsou naprosto průhledné a je jasné, co děláte. Reference se občas tváří jako chameleón, takže třeba vaším výrazem &ref byste vůbec nemusel obdržet adresu objektu, ale také podle kontextu zavolat operator&. Takové věci se vám s ukazatelem nestanou. Takže výrazem &ref nemusíte nutně dostat adresu objektu. Na druhé straně existují triky, jak získat z reference adresu objektu i tehdy, když je přetížen operator&, ale to je vyšší dívčí a není to pro začátečníky v C++. Takže já jsem po čase začal v C++ dost preferovat ukazatele.

A kdybyste chtěl skutečné hacky v C++, existují daleko zajímavější věci. Co takhle třeba přetížit operátor, a pak se divit?

[paskma]

Reference v C++ jsem vždy používal jenom pro to, abych mohl předat objekt jako argument metodě. Aby se to nepředávalo hodnotou, a přitom nemusel psát ty ampersandy a v té metodě s tím pracovat přes ->.

Dělat reference na proměnné typu int je samozřejmě blbost. Ano, ukazatelé jsou průzračnější, s tím nelze než souhlasit. Prostě u reference jen odpadá pointerová aritmetika a samo se to dereferencuje.

Jinak ad přetěžování operátorů. S tím by se mělo velice, _velice_ šetřit. Pokud přetěžuji operátor * nebo &, musím pro to mít _zatraceně_ _dobrý_ důvod. Udělat místo toho metodu je v 99% případů lepší řešení.

Přetěžování operátorů se hodí jen pro pár věcí. Matice, řetězce. Co dál? Operátor += nastavující titulek okna fakt ne. Což je taky důvod, proč třeba v Javě tato fíčura vůbec není a nikomu to moc nevadí.

[Michal Kubeček]

Přetěžování operátorů se hodí jen pro pár věcí. Matice, řetězce. Co dál?

Třeba v STL by se pár užitečných příkladů našlo.

[paskma]

Jo, taky proto mi STL přijde docela šílená. Já to teda moz nezažil, od C++ jsem utekl, než byly použitelné implementace.

Dodnes si vzpomínám, jak jsem našel chybu v std::list v nějaké verzi C++Builderu (asi tak 3). Od té doby mám k tomu averzi. Jen málokde jsem viděl drsnější kód, než uprostřed STL, to je fakt maso, na to nemám.

[#Tom]

Hlavičkové soubory vypadají místy opravdu trošku divoce...

[Miloslav Ponkrác]

Máte pravdu, vývoj C++ byl docela maso a trvalo ředu let, než se konečně vytvořil standard.

Jinak vás můžu uklidnit, že v Borlandských kompilátorech jsem našel tolik chyb, že jsem si místy připadal spíš jako betatester Borlandu, než jako programátor. Když jsem si uvědomil, že už pokolikáté lezu do strojového kódu a marně přemýšlím, co to ten kompilátor Borlandu zase vymyslel za ptákovinu, která ve zdrojáku vůbec není, zdravě jsem se naštval. Poslední kapkou byl u Borlandu takto přeložený kód:

int Trida::GetValue() { return 3; }

který byl Borlandkým kompilátorem přeložen zhruba takto:

push eax ret

To jse si řekl dost a od té doby se Borlanským kompilátorům vyhýbám a mám klid.

Jinak kód uprostřed STL je dost šílený, ale tak dopadne každý kód, který uděláte moc moc obecně pomocí šablon.

[podlesh]

Zajímavé, mám stejné zkušenosti. Po prvním pokusu o napsání dvacetiřádkového programu v C++ Builderu jsem toho zanechal, semestrálku ze ZPG udělal pěkně v plain C a využil toho že v učebně byl na jednom stroji i Visual C.

[paskma]

No, zas tak hrozné to snad není. Já v tom udělal asi 10k program a šlapalo to, když se člověk vyhnul šablonám.

Jak by řekl klasik: Když víš, které konstrukce způsobují interní chybu překladače, můžeš v pohodě programovat.

V BCB jsem narazil ještě na jedu krásnou chybu. Při debugování se po najetí myší nad proměnnou zobrazí v bublině její hodnota. Problém byl, když ta proměnná byl integer ve tvaru i++ nebo ++i. Pak to nejen zobrazilo hodnotu, ale rovnou to číslo i inkrementovalo. Takže po prvním najetí tam bylo 1, pak 2, 3 atd. Trvalo mi pár hodin, než jsem na to přišel

[podlesh]

No, zas tak hrozné to snad není. Já v tom udělal asi 10k program a šlapalo to, když se člověk vyhnul šablonám.

Jak by řekl klasik: Když víš, které konstrukce způsobují interní chybu překladače, můžeš v pohodě programovat.

V mém případě tou konstrukcí bylo if. A programovat bez if je velmi obtížné.

V BCB jsem narazil ještě na jedu krásnou chybu. Při debugování se po najetí myší nad proměnnou zobrazí v bublině její hodnota. Problém byl, když ta proměnná byl integer ve tvaru i++ nebo ++i. Pak to nejen zobrazilo hodnotu, ale rovnou to číslo i inkrementovalo. Takže po prvním najetí tam bylo 1, pak 2, 3 atd. Trvalo mi pár hodin, než jsem na to přišel

Naštěstí jsem v té době ještě byl zvyklý debugger nepoužívat (jedine pro post-mortem). Bohužel jsem od té doby vyměkl.

[#Tom]

V Turbo Vision se třeba přetíženým operátorem + skládaly nabídky. Bylo to snadné a rychlé na zápis. Na rozdíl od Turbo Pascalu se nemusely hlídat závorky (tam se to dělalo vnořeným voláním funkcí). Tehdy ale ještě nebylo STL.

Mimochodem, unární operátor * se třeba přetěžuje v iterátorech.

[Miloslav Ponkrác]

Operátory nejsou nic jiného, než syntaktický cukr. Hodí se pro mnoho věcí, ale samozřejmě je blbost používat je neuváženě. A není pravda, že by operátory měly dobré využití jen pro matice a řetězce. Dokáži si představit daleko širší smysluplné využití. Co třeba práce s regulárními výrazy? Co práce s datovými strukturami typu seznam, slovník, apod.? Dobře zvolené operátory v datových strukturách jsou k nezaplacení! Třeba hledání hodnoty ve slovníku pomocí klíče realizovaného pomocí operátoru[] je naprosto bomba a IMHO ten nejpřehlednější zápis, co můžete mít! Nabo přidávání prvku na konec senzamu pomocí operátoru+= považuji také za výborné řešení. Co třeba vstupy a výstupy? Myslíte si, že použití operátoru<< a operarátoru>> pro vstupy a výstupy v C++ není dobrým příkladem použití operátorů? A to nemluvím o matematice. Co komplexní čísla? Nebo třída pro práci s reálnými čísly s nekonečnou přesností, kde můžete používat přirozené matematické operátory? Nebo práce s datumem a časem, kde se také dají krásně uplatnit operátory pro zpřehlednění práce. Co čtení sloupců z databáze, kde lze úspěšně a dobře použít operátor[] pro čtení hodnoty z daného sloupce. A tak bych mohjl pokračovat ještě dlouho. Dobře zvolené operátory jsou požehnáním. Takový program je mnohem přehlednější, čitelnější a tím pádem většinou obsahuje i méně chyb a je udržovatelnější, než bez operátorů.

V Javě jsem toho napsal hodně a nepřítomnost operátorů v Javě mi hodně vadí. Tím spíš, že prakticky každý moderní jazyk operátory zavedl, protože jsou užitečné. Java je spíš výjimka v jazycích, co se nepodpory operátorů týče. Dobře zvolené operátory sakra výrazně zpřehlední program.

Osobně si myslím, že když Microsoft zaváděl svoje C# jakožto vlajkovou loď jazyků pro .NET framework, tak dobře věděl, proč operátory zavést.

Mimochodem, to že Java nemá operátory taky není tak docela pravda. Když už nic jiného, tak Java zavedla alespoň + operátor pro stringy. Takže Java je v tomhle dost pokrytecká.

[paskma]

V javě je dokonce operátor klíčové slovo, třeba se dočkáš.

Mě to v Javě nevadí, mám na to dost jiný názor, než ty. Vyhledávání ve slovníku mi přijde čitelnější přes metodu get nebo valueForKey. Prvek do seznamu rád přidám přes add. Přijde mi to míň kryptické, zřetelnější.

Pro matematické objekty a řetězce OK, ale s citem.

No a ty IO operátory << a >>, to je fakt úlet. Funguje to hezky, ale je to úlet.

Je to věc vkusu, respektuji tvé preference.

BTW: No, třeba super je, jak se odlišuje postfixová a prefixová a postfixová verze operátoru ++. Jedním (formálním) parametrem typu int. Kouzelné.

[Miloslav Ponkrác]

Já vím, že se dočkám. Naštěstí existuje Microsoft, který se svým .NET prostředím dokázal to, co jsem si dlouhá léta myslel, že nebude možné. A to probudit Sun ze svého bahýnka sebechvály na Javu a ukázat, že Java má co zlepšovat. Takže jsem se třeba dočkal šablon, autoboxu a věřím, že se dočkám i operátorů. A pak ještě pár maličkostí a Java se mi jako jazyk začne opravdu líbit.

Ačkoli mnohem raději programuji v Javě, než v C#, tak blahořečím za to, že tu Microsoft je! Nebýt toho, tak by Java usnula na vavřínech a stala se živoucím dinosaurem, který se jaksi zapoměl vyvíjet a smrděl by jednak sebechválou Sunu. No to jen tak trochu na pošťouchnutí

[podlesh]

Já vím, že se dočkám. Naštěstí existuje Microsoft, který se svým .NET prostředím dokázal to, co jsem si dlouhá léta myslel, že nebude možné. A to probudit Sun ze svého bahýnka sebechvály na Javu a ukázat, že Java má co zlepšovat. Takže jsem se třeba dočkal šablon, autoboxu a věřím, že se dočkám i operátorů.

To se snad nikdy nestane. Bohatě stačí již udělané boty. Zvláště autoboxing+autounboxing .

[Miloslav Ponkrác]

Nutnost autoboxingu je důsledkem špatného návrhu Javy. Kdyby byla Java skutečně objektový jazyk, jakože není, tak by problémy s autoboxingem vůbec řešit nemusela. Kdyby třeba i int bylo objektem odvozeným od třídy Object, jako je tomu ve všech skutečně objektových jazycích, nemusela by Java zavádět duplicitní třídy typu Integer a řešit pak nějaký autoboxing, apod..

[podlesh]

Ale o to přeci vůbec nejde, to je jasné. Primitivní typy jsou nepěkným kompromisem, ale pravděpodobně jsou jedním z důležitých faktorů úspěchu Javy.

Problém s jednoduchým přidáním autoboxingu+autounboxingu je operátor == . Přesněji to, že je přetížený a má dvě zcela rozdílné funkce: buď porovnává hodnoty (u primitivních typů) nebo reference (u objektů). Typická ukázka, kam vede přetěžování operátorů...

Správně by měly být operátory dva: jeden pro porovnání hodnoty, druhý pro porovnání referencí.

[zde]

Viz Python a operátory '==' a operátor 'is'. Ale nejlepší řešení je runtime systém který zaručuje že totožné integery nebo totožné stringy mají identické reference, pak není druhý operátor opravdu potřeba.

[podlesh]

Viz Python a operátory '==' a operátor 'is'. Ale nejlepší řešení je runtime systém který zaručuje že totožné integery nebo totožné stringy mají identické reference, pak není druhý operátor opravdu potřeba.

Jistě. Ale to se motáme pořád dokola - že primitivní typy do opravdu objektového jazyka nepatří. Nu, co se dá dělat...

Mnohem víc mi ale v Javě chybí metody tříd.

[Pavel Stárek]

Mnohem víc mi ale v Javě chybí metody tříd.

Možná mi něco uniklo, ale mám li třeba třídu:

public class Trida {

  private final int a = 5;

    // metoda tridy
  public static int vratA() {
    return(this.a);
  }

}

Tak potom můžu volat metodu třídy takto:

int moje_a = Trida.vratA()

Tedy alespoň ve všech učebnicích Javy se tomuto volání říká volání metody třídy. Ale možná si měl na mysli něco jiného.

[paskma]

Jenže ve statických metodách žádné this není... A ono by možná být mělo a mělo by se odkazovat na třídu. A pak by to byla pořádná metoda třídy.

[Pavel Stárek]

No přiznám se, že s tím this sem si nebyl jistej. Ale je pravda, že o metodách třídy i o metodách instance se zmiňuje pan Herout ve své (dle mne docela dobré) knize "Učebnice jazyka Java".

[Miloslav Ponkrác]

Ale o to jde. Java prostě zvolila špatnou cestu. Dokonce i Microsoft, když tvořil svůj .NET toto podstatně zdokonalil, i když také zůstal na půl cesty. U .NET existuje daleko více primitivních typů, ale všechno je objektem. I int je objektem a třeba konstrukce 123.ToString() je v C# platná. Stejně tak to funguje třeba ve Smalltalku, nebo v jiných, opravdu objektových jazycích.

Nechápu, proč Java dělala kompromis v primitivních typech, když se tím získaly akorát problémy. Co tím Java získala kromě bordelu? V C# jsou prostě jenom objekty a přitom je práce s int efektivní a rychlá, protože kompilátor to převede na primitivní instrukce namísto volání metody. .NET nepotřebuje na rozdíl od Javy definovat např. třídu typu Integer jako to musí dělat Java. Pak je pro Javu autoboxing jenom dalším prvkem bordelu, který tam vnesla. Prostě Java se jenom topí v bordelu, který si způsobila tím, že neprohlásila promitivní typy za objekty, což by jí nic nestálo a bylo by to efektivnější řešení.

Bordel v operátorech není způsoben použitím operátorů, ale tím, že se prostě nezvolily vhodné operátory. Co je jednoduššího, než prostě vymyslet jeden operátor, který bude vždycky porovnávat hodnotu a druhý operátor, který bude vždycky porovnávat adresu? Můj názor je, že prostě Sun převzal C++ syntaxi, aniž by se nad tím zamyslel a tak vytvořil nekoncepčnost. V C++ neexistuje problém tohoto typu. V C++ je naprosto jasné z použití operátorů, zda porovnáváte hodnotu, nebo adresu. Operátory == a != v C++ vždycky porovnávají hodnotu. Jenomže Sun si prostě myslel, že když vezme C++, ořeže ho a zapomene se nad svojí Javou zamyslet, takže získá dokonalý jazyk. Tohle není příklad na to, že jsou operátory nevhodné, ale klasický učebnicový příklad toho, že návrháři jazyka Java jsou prasata, a že neumějí s operátory zacházet. A jak říká Werich, zlobí se na zrcadlo, kdo má křivou hubu.

[podlesh]

Ale o to jde. Java prostě zvolila špatnou cestu. Dokonce i Microsoft, když tvořil svůj .NET toto podstatně zdokonalil, i když také zůstal na půl cesty. U .NET existuje daleko více primitivních typů, ale všechno je objektem. I int je objektem a třeba konstrukce 123.ToString() je v C# platná. Stejně tak to funguje třeba ve Smalltalku, nebo v jiných, opravdu objektových jazycích.

Ale prdlajs. C# převzalo primitivní typy z Javy, jenom tam dali autoboxing/autounboxing hned..

Pravda je, že je to daleko více zaintegrované a programátor o tom ani nemusí vědět... do jisté míry. Více viz například zde Uznávám že se to dá brát jako podstatné zdokonalení.

Pak je pro Javu autoboxing jenom dalším prvkem bordelu, který tam vnesla. Prostě Java se jenom topí v bordelu, který si způsobila tím, že neprohlásila promitivní typy za objekty, což by jí nic nestálo a bylo by to efektivnější řešení.

No jo, dneska se to lehko mluví, když to víme... Ale jak jsem již zmínil, asi by to bylo rozhodnutí správné technicky, ale velmi špatné politicky.

V C++ neexistuje problém tohoto typu. V C++ je naprosto jasné z použití operátorů, zda porovnáváte hodnotu, nebo adresu. Operátory == a != v C++ vždycky porovnávají hodnotu.

To je nějaký fór? Schválně jsem se podíval, a == i != by měly být přetížitelné.

Ale je to perfektní ukázka toho, co je na přetěžování operátoru špatného: i když se může zdát že je zcela bezpečné, stejně o něj člověk zakopne a rozbije si hubu. I kdyby to bylo za 10 let.

[Miloslav Ponkrác]

Ale prdlajs. C# převzalo primitivní typy z Javy, jenom tam dali autoboxing/autounboxing hned..

To je trochu jinak. Oni nepřevzali primitivní typy. V .NETu jsou typy rozdělené na hodnotové a odkazové (což je asi nejblíže chování primitivních a objektových typů v Javě). Autoboxing na hodnotové typy dali hned a vyřešili to podle mě daleko čistějším stylem. Hodnotový typ si klidně můžete v .NET vytvořit sám, takže pak se s ním zachází vnitřně trochu jinak, třeba je ukládán na zásobníku, apod.. Ale to už začínáme zabíhat do detailů. A co jste taktně ignoroval byla moje poznámka, že v C# neexistují nic než objekty. Tedy neexistuje, že by třeba int nebyl objekt, jako je tomu třeba v Javě.

No jo, dneska se to lehko mluví, když to víme... Ale jak jsem již zmínil, asi by to bylo rozhodnutí správné technicky, ale velmi špatné politicky.

Vědělo se to už tehdy. Už tehdy existovaly objektové jazyky, které měly všechny typy jako objekty. Otázkou je, jak říkáte, co bylo průchodné politicky.

To je nějaký fór? Schválně jsem se podíval, a == i != by měly být přetížitelné.

A to vadí? Vždyť je naprosto logické, že porovnávání dvou hodnot je operace, kterou je potřeba často naprogramovat podle potřeb toho kterého typu. To nic nemění na faktu, že pomocí těchto operátorů se vždycky porovnává hodnota. Jasně,že si klidně můžete naprogramovat operator==, který vám třeba zformátuje disk, ale to už klidně můžete tvrdit, že metoda equals je naprd ze stejného důvodu.

Ale je to perfektní ukázka toho, co je na přetěžování operátoru špatného: i když se může zdát že je zcela bezpečné, stejně o něj člověk zakopne a rozbije si hubu. I kdyby to bylo za 10 let.

Ne, to není ukázka toho, co je na operátorech špatného.

Jednak se chováte trochu neseriózně už tím, že dokazujete špatnost přetěžování operátorů na jazyce Java, který touto featurou nedisponuje. Takže vlastně nedokazujete nic jiného, než prostě špatnou práci návrhářů jazyka Java. A nějaké operátory, alespoň zabudované do syntaxe jazyka má většina programovacích jazyků a pokud holt návrháři jazyka nepřemýšlí, tak to prostě zkoní a operátory za to nemůžou.

A druhak váš důkaz není nic jiného, než co můžete provést s jakoukoli vlastností programovacího jazyka. Špatně se dá použít naprosto všechno a to, že někdo špatně použije třeba objekty není důvod k zavrhnutí objektového programování. Takže analogicky to, že někdo špatně použije operátory není důvod k tomu je odepsat.

[podlesh]

O value a reference typech v C# vím, ale nepovažuji to za podstatný rozdíl (hodnotové typy v Javě jsou prostě jen omezeny na int, long, short a char). Koncepce hodnotových typů je jasně převzata (je otázka odkud).

A co jste taktně ignoroval byla moje poznámka, že v C# neexistují nic než objekty. Tedy neexistuje, že by třeba int nebyl objekt, jako je tomu třeba v Javě.

Pokud budeme hodnotové typy považovat za objekty - pak je to ovšem jen otázka terminologie. Nebo pokud přistoupíme na to, že boxing/ungoxing je zcela transparentní (což není).

Ani s jedním nesouhlasím. Nelze situaci v C# srovnávat se Smalltalkem, CLOS či dalšími - sice se to tak napůl tváří, ale ne zcela.

No jo, dneska se to lehko mluví, když to víme... Ale jak jsem již zmínil, asi by to bylo rozhodnutí správné technicky, ale velmi špatné politicky. Vědělo se to už tehdy. Už tehdy existovaly objektové jazyky, které měly všechny typy jako objekty. Otázkou je, jak říkáte, co bylo průchodné politicky.

Přesně to jsem měl na mysli.

A druhak váš důkaz není nic jiného, než co můžete provést s jakoukoli vlastností programovacího jazyka.

Jednak nebyl žádný důkaz, jenom poznámka mimochodem. Druhak jsem jasně napsal, že měly být vytvořeny operátory dva, jak se ukázalo při rozšiřování.

Přetěžování operátorů je velmi kontroverzní věc a v podstatě se nedá vyřešit (flamewar není řešení). Každopádně je zcela proti základní filozofii jazyka Java a nepatří tam. Přidáváním takovýchto featur by se z toho stal úplně jiný jazyk.

[Ladislav Thon]

V javě je dokonce operátor klíčové slovo

V Javě jsou (neimplementovaná) klíčová slova goto a const, ale o klíčovém slovu operator slyším prvně. Našel jsem akorát tohle: http://jira.opensymphony.com/browse/WF-281, na java.sun.com ani slovo.

třeba se dočkáš

Doufám že ne, úplně mi stačí statické importy a auto(un)boxing :)

Jsem rád, že Anders Hejlsberg dělá na .NETu a ne na Javě :)

[paskma]

Hm, tak jsem kecal. Ale mám pocit, že v nějaké starší verzi to bylo vyhrazené. Každopádně v 5.0 int oprerator = 10 není problém.

[Kyosuke]

Operátory ale nejsou vůbec zapotřebí, stačí se zbavit závorek při volání metod a povolit speciální znaky v názvech metod a pak už jsou všechno jen metody. Ehmm, nepsal jsem to už někde?

[Miloslav Ponkrác]

Jasně. Všechno jde směrem k LISPu, než nakonec pochopíme, že je to nejlepší a nejefektivnější programovací jazyk

[Kyosuke]

Já myslím, že je docela fajn, že se ten kotel jazyků vaří a že evoluce pracuje. Myslím, že na tom jednoho dne vyděláme.

[Miloslav Ponkrác]

To je otázka. Ono se neprosazuje to nejlepší, ale to co někdo vytáhne nahoru. Jinak řečeno je to otázka spíš reklamy, propagace, marketinku, podpory, než kvality jazyka. Výsledkem toho je, že se až příliš mnoho sw píše v jazycích, které pro to nejsou úplně ideální. Toť můj osobní názor.

Nebo vám se běžně stává, že si můžete zvolit programovací jazyk, ve kterém píšete? Mě se to stává jen velmi málo, většinou mám rovnou předepsáno v čem to budu psát. Když přeci jenom občas dostanu volnost ve výběru jazyka, většinou ten samý problém naprogramu i několikrát rychleji.

Někdy se dokonce vyplatí napsat si vlatní jazyk, který je speciálně určený na problém, který řešíte a většinu napsat v něm. Už to někdy příšerně urychlí vývoj.

[Kyosuke]

„Někdy se dokonce vyplatí napsat si vlatní jazyk, který je speciálně určený na problém, který řešíte a většinu napsat v něm. Už to někdy příšerně urychlí vývoj.“

Ehm, LISP. A makra. A doménově-specifické jazyky.

Jo, stává. Nejsem fulltimový programátor a nástroje pro urychlení práce si můžu psát, v čem chci. Mému vedení je jedno, co kancelářským krysám ušetří čas. Z praktických důvodů jsem si oblíbil Ruby a OCAML (Ruby jako nedostižný high-level jazyk a OCAML jako mnohem lepší náhradu C++ Jsem ovšem s OCAMLem teprv na začátku.)

[Michal Kubeček]

Někdy se dokonce vyplatí napsat si vlatní jazyk, který je speciálně určený na problém, který řešíte a většinu napsat v něm.

Cynická poznámka: nevzniklo takhle nějak céčko? :-)

[#Tom]

Co vypíše tento program?

#include <iostream>
#include "pretizeni.h"

using namespace std;

main()
{
  int a = 3;
  int b = 4;
  cout << (a + b) << endl;
  return 0;
}

I když to zní divně, tak vypíše -1. Je poněkud vylepšen hlavičkovým souborem pretizeni.h:

#ifndef __PRETIZENI_H
#define __PRETIZENI_H

#include <ostream>

class INT {
public:
  INT() : hodnota(0) { }
  INT(int _hodnota) : hodnota(_hodnota) { }
  friend INT operator+ (INT&, INT&);
  friend INT operator- (INT&, INT&);
  friend std::ostream& operator<< (std::ostream&, INT&);
  friend std::ostream& operator<< (std::ostream&, INT );
private:
  int hodnota;
};

INT operator+ (INT& a, INT& b) { return INT(a.hodnota-b.hodnota); }
INT operator- (INT& a, INT& b) { return INT(a.hodnota+b.hodnota); }
std::ostream& operator<< (std::ostream &s, INT& a) { return s << a.hodnota; }
std::ostream& operator<< (std::ostream &s, INT  a) { return s << a.hodnota; }

#define int INT

#endif

[zde]

1) Nejde subclassovat int, musí se tedy růčo zavést class INT a 'int hodnota' (boxing). Odporné.

2) Ten konstruktor ': hodnota (_hodnota)' vypadá jako syntaktický šum, zašifrovat inicializaci proměnné jako volání funkce musel vymyslet opravdu velků blb.

3) C++ neumí jednoduše delegovat, takže jako vůl musíš při zaboxování hodnoty reimplementovat celý její interface.

[#Tom]

Jsou i horší věci. Obyčejné proměnné, jako je tady ta int hodnota, si můžu inicializovat klidně i vevnitř a normálně, zatímco běžné objekty jdou jen před konstruktorem. Ještě můžu mít tu smůlu, že na sobě nějak závisí. To už pak je rovnou lepší použít ukazatele, new a delete.

P.S.: Ve výše uvedeném příkladu jsem ještě jaksi zapomněl v operátoru << použít const INT&, takže jsem jej zavedl dvakrát. To mám z toho ponocování.

[zde]

Pravda. Hergot ty jsi chytrej člověk! Proč teda používáš to C++ ???

[#Tom]

Vlastně ho moc nepoužívám, jen s s ním občas hraju. Zatím mi to ještě k ničemu dobrý nebylo.

[Michal Kubeček]

A kdybyste chtěl skutečné hacky v C++, existují daleko zajímavější věci. Co takhle třeba přetížit operátor, a pak se divit?

Přetěžování operátorů je ještě celkem srozumitelné. Skutečné depresi jsem propadl až tehdy, když jsem objevil pointery na metody… :-)

[Miloslav Ponkrác]

Já jsem propadl skutečné depresi až tehdy, když jsem v C++ objektům měnil za běhu ukazatele na tabulku virtuálních metod a dělal jsem z nich tak za běhu instance úplně jiných tříd, než byly původně. Bylo to sice trochu hackerské, ale občas dost efektivní. Člověk ale musel velmi dobře vědět co dělá, jinak by byl nahraný.

[Kyosuke]

Hehe, sounds smalltalkish...

[paskma]

Tedy ty seš ale trikař. Jako akademické experimenty je to dobré, ale netvrď mi, že jsi to psal do komerčního softu, co bude muset někdo někdy udržovat?

Věci mají být tak jednoduché, jak je to možné. Ale ne jednodušší. (A.Einstein)

[Miloslav Ponkrác]

Jasně, že bych se neodvážil něco takového dát do komerčního softu.

[Pedro Alvarez]

Pointer na funkci jde, zkus si prestavit pointer na pointer na pole pointeru na pointery na funkce, ktere vraci pointer na pointer na hodnotu, to je teprve mazec . Kdyz jsem prevzal projekt po jednom kolegovi, co z firmy odesel a nasel jsem tuhle konstrukci, tak jsem trikrat napsal vypoved... Dneska uz muzu s klidem rict, ze mi trvalo dva dny, nez jsem to rozlustil.

[Michal Kubeček]

Neměl jsem na mysli pointer na funkci, to je naprosto standardní záležitost, která se používá i v klasickém C. Mluvil jsem o pointeru na metodu. Tj. třeba tohle:

  #include <iostream>

  class T
  {
  public:
    T() {};
    void ma(int x) { std::cout << "T::ma(" << x << ")\n"; }
    void mb(int x) { std::cout << "T::mb(" << x << ")\n"; }
  };

  typedef void (T::*method_pointer)(int);

  void call(T* x, method_pointer m, int n)
  {
    (x->*m)(n);
  }

  int main()
  {
    T x;

    call(&x, &T::ma, 1);
    call(&x, &T::mb, 2);
  }

[Michal Kubeček]

Jediné štěstí je, že když jsem propadl iluzi, že by se mi pointery na metody mohly hodit, poměrně rychle jsem zjistil, že při netriviálním použití celkem spolehlivě přivádějí (tehdejší verze) gcc do kolen.

[miho]

To mi pripomina jak jsme kdysi na foru zive lustili nejaky problem a resenim bylo:

class Trida { 
   public: 
        void metoda(void); 
} instance; 

void Trida::metoda(void) { 
      printf("To JE ale prasarna!\n"); 
   } 


void (Trida::*funkce(void))(void) { 
   return Trida::metoda; 
} 

void main() { 
   void (Trida::*uk)() = funkce(); 

   (instance.*uk)(); 
}

[Miloslav Ponkrác]

Tak to uznávám a upřímnou soustrast. Naštěstí jsem nic tak strašného luštit nemusel a pokud jste program nakonec pochopil tak vám opravdu gratuluji.

[Michal Kubeček]

To mi připomíná, jak byl Jim Starkey konsternován při spatření

  const dsql_nod* const* const end

:-)

[zde]

3x 'const' i 2x reference jsou naprosto v pořádku. Problém je pouze s dsql_nod: pravděpodobně jde o typedef'd struct (nebo o kus C++ zdrojáku), což někteří lidé (včetně mne) neradi vidí.

Typedef na základní typy, pro účely nezávislosti na platformě je OK, ale když je něco struct nebo enum, mělo by to být vidět i v .C, ne jenom v .H. Typedef zbytečně míchá namespace, které jsou navrženy jako oddělené.

[Kumar]

THAAAAAAAAAAAAAAAAATS COOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOL :)))

[podlesh]

Nemohu se zbavit dojmu, že toto za mých "mladých let" v C++ nebývalo. A pokud ano, tak se to pěkně ignorovalo.

Co se týká polí v C: častá (a myslím že velmi rozumná) praxe je pole pohřbít a zapomenout na ně.

[podlesh]

Mimochodem, to indexování čísla polem - opravdu to "sežerou" všechny kompilátory?

[paskma]

Zkoušeno pod BCB, MSVC, GCC. Možná je to dáno závazným způsobem vyhodnocení té konstrukce, nevím.

I když to by možná mohlo dělat problémy na AS/400

[podlesh]

Zkoušeno pod BCB, MSVC, GCC. Možná je to dáno závazným způsobem vyhodnocení té konstrukce, nevím.

Chtělo by to nahlédnout to K&R Bible. Jestli zítra (vlastně už dnes...) vzpomenu.

[zde]

1) Když už trváš na tom místo 'l-value' říkat 'l-hodnota', měl bys místo 'r-value' říkat 'p-hodnota'.

2) Reference nejsou 'bezpečnější', jsou víceméně na pikaču.

3) C++ cucá a nemá a nikdy nemělo s hackery nic společného.

4) Jediná trochu zajímavá věc jsou C++ templates, ale jsou udělány blbě, viz http://www.kuro5hin.org/story/2003/5/26/22429/7674