Jaderné noviny - 12. 9. 2007

24. 9. 2007 | Robert Krátký | Jaderné noviny | 5174×

Aktuální verze jádra: 2.6.23-rc6. Citáty týdne: Andrew Morton, Linus Torvalds. 2007 Kernel Summit. Exportované symboly a interní API. Kdo napsal a schválil 2.6.23.

Obsah

• Aktuální verze jádra: 2.6.23-rc6
• Citáty týdne: Andrew Morton, Linus Torvalds
• 2007 Kernel Summit
  • Den 1.
  • Den 2.
  • Skupinové foto
• Exportované symboly a interní API
• Kdo napsal a schválil 2.6.23

Aktuální verze jádra: 2.6.23-rc6

Aktuální předverze je (12. 9. 2007) 2.6.23-rc6, vydaná 10. září. Tentokrát je počet oprav relativně malý; částečně proto, že bylo minulý týden mnoho vývojářů na kernel summitu. Podrobnosti v dlouhém changelogu.

Do hlavního git repozitáře i nadále proudí patche - skoro určitě se před finálním vydáním dočkáme ještě -rc7.

Minulý týden nevyšly žádné -mm verze.

Starší jádra: 2.6.20.19 bylo vydáno 8. září s jednou bezpečnostní opravou v kódu IPv6.

2.4.35.2 vyšlo také 8. září; obsahuje povětšinou opravy týkající se kompilátorů. 2.4.36-pre1 vyšlo pro změnu 8. září; obsahuje několik oprav a patch umožňující zakázat procesům mapovat adresu NULL.

Citáty týdne: Andrew Morton, Linus Torvalds

Takže provádím obrácené reverzní polské půlící vyhledávání [inverted reverse polish bisection search], abych zjistil, který patch preemptivně opravuje clockevents-fix-resume-logic.patch. Zkuste to s gitem, cucáci.

-- Andrew Morton

C++ je děsný jazyk. A ještě horší ho dělá skutečnost, že ho používá spousta podprůměrných programátorů, takže je možné z něj vygenerovat totální a naprosté srágory. Upřímně, i kdyby C nesloužilo k *ničemu* jinému než k odrazování C++ programátorů, tak by to pořád stálo za to.

-- Linus Torvalds

2007 Kernel Summit

Linux Kernel Developers' Summit 2007 [setkání vývojářů linuxového jádra] se konal 5. a 6. září v Cambridge ve Velké Británii. Přibližně 80 vývojářů diskutovalo v rámci této konference jen pro zvané o mnoha různých tématech týkajících se všech aspektů vývoje jádra. Jako obvykle byl přítomen i Jonathan Corbet z LWN, který napsal své postřehy z jednotlivých setkání.

Den 1.

• Setkání distributorů. Správci jádra ze čtyř distribucí se účastnili setkání, jehož cílem bylo seznámit komunitu s tím, jak by - z jejich pohledu - mohl být proces vylepšen. Místo toho však proudily informace spíše opačným směrem, protože mnoho vývojářů vyjádřilo svou nespokojenost s různými praktikami distributorů.


• Zprávy z mini-summitů. Mini-summity byly na téma správy energie, souborových systémů a ukládání dat, virtuální paměti a virtualizace. Konaly se v průběhu měsíců předcházejících hlavnímu summitu.


• Širší ekosystém jádra a API pro uživatelský prostor. Diskuze o tom, jak jádro prezentuje rozhraní uživatelskému prostoru, a o nízkoúrovňovém softwaru, který s tím pomáhá. Zpráva popisuje i sezení, ve kterém se probíral návrh na formální kontrolní proces při schvalování nových systémových volání.


• Kvalita jádra. Andrew Morton nedokázal říci, jestli mu připadá, že se nové verze jádra zhoršují nebo zlepšují, ale nepochyboval o tom, že by situace mohla být lepší.


• Podpora hardwaru a sloučení i386/x86_64. Diskutovalo se o stavu ovladačů pro různé čipsety; součástí bylo i důležité oznámení AMD o otevření grafických procesorů. Jedno setkání se zabývalo tím, jestli by měly být stromy architektur i386 a x86_64 sloučeny.

Den 2.

• Setkání se zákazníky. Zajímavá diskuze o potřebách zákazníků se zástupci Dreamworks, Credit Suisse a Linux Foundation.


• Realtime a syslety. Jaký je stav sady patchů realtime a co se chystá se syslety?


• Škálovatelnost. Otázky zajímavé pro ty, kdo se snaží Linux provozovat na velmi malých nebo velkých systémech.


• Správa paměti. Diskuze o podpoře velkých stránek, testovací úlohy pro patche týkající se správy paměti a umožňování aplikacím, aby pomohly při nedostatku paměti.


• Kontejnery. Co zbývá udělat, aby mělo jádro kompletní implementaci kontejnerů.


• Vztahy vývojářů a vývojový proces. Jak může komunita přilákat další vývojáře a zabránit vytlačení těch, které už má? Kromě toho se mluvilo o několika dalších základních otázkách týkajících se vývojového procesu.


• Závěrečná setkání. Koncové setkání letošního jaderného summitu bylo o summitu samotném. Splnila akce očekávání účastníků, a jak by to mělo vypadat v budoucnu?

Skupinové foto

Jaký by to byl kernel summit bez skupinové fotky? Na obrázku je většina účastníků před kolejí Downing College, kde bylo mnoho vývojářů také ubytováno:

Fotku si můžete prohlédnout ve třech rozlišeních:

• střední (1200x500)
• vysoké (2573x1100)

Na četné žádosti byla připravena i verze s popisky, která má připsaná jména k co největšímu počtu tváří.

Exportované symboly a interní API

Natahovatelné jaderné moduly nemají automaticky přístup ke všem symbolům (funkcím a proměnným) definovaným v jádře. Přístup je omezen pouze na ty symboly, které byly výslovně exportovány pro použití v modulech. Důvodem pro tohle povolování [whitelist] je snaha udržet rozhraní pro moduly pod kontrolou, aby se nehrabaly v částech jádra, kde nemají co pohledávat. V praxi to však moc dobře nefunguje: současná jádra mají ve zdrojových kódech rozeseto více než 16 000 deklarací EXPORT_SYMBOL().

Není tedy nic překvapivého, že by někteří vývojáři chtěli počet exportovaných modulů snížit. Často je symbol vyřazen, ukáže-li se, že jej nepoužívá žádný z modulů, které jsou součástí jádra. Neexistuje však všeobecná shoda ohledně toho, jak by se mělo k tomuto procesu přistupovat; kvůli tomu se občas objeví debata o tom, nakolik by vlastně mělo být API pro moduly stabilní, a jaké ohledy se mají brát na moduly, jež nejsou součástí jádra.

Adrian Bunk nedávno poslal patch, který ruší export sys_open() a sys_read(). Tyto symboly (které implementují systémová volání open() a read()) už jsou na seznamu pro odstřel dlouho. Když jsou používány z jaderného prostoru, tak je snadné se dopustit katastrofických chyb. A neexistují skoro žádné situace, v rámci kterých by bylo otevírání a čtení souborů z jádra považováno za správné. Ale odstranění těchto exportů bylo až doteď obtížné - pořád byl v jádře kód, kvůli kterému musely být zachovávány.

V jádře 2.6.23 tomu brání už jen poslední kus kódu - zvukový ovladač wavefront, který sys_open() a sys_read() používá k natažení firmwaru do zařízení. Jádro už má léta řádné API pro práci s firmwary, takže by se žádný ovladač neměl snažit ho načítat sám přímo ze souborů. Aktuální vývojový strom ALSA obsahuje pro wavefront patch, který zařídí, že bude používat firmwarové API; jakmile bude tento patch začleněn, nebude už zmiňované symboly potřebovat žádný jaderný kód. Adrian, který neustále sleduje, co by šlo z jádra odstranit, si toho všiml a hned poslal patch.

Andrew Morton odpověděl takto:

Já myslím, že je lepší lidi nejprve varovat, když máme v plánu provést něco, kvůli čemu by kód, který není v jádře, mohl přestat fungovat. Občas dostávám zprávy typu "hele, ovladač X, který mám od Y, přestal fungovat". A často se jedná o open source věci. Nevidím důvod, proč bychom měli uživatele štvát víc než je nutné.

Andrew by byl radši, kdyby byly symboly po jeden vývojový cyklus označeny jako EXPORT_UNUSED_SYMBOL(), aby si vývojáři kódu, který není v jádře, mohli všimnout varování a opravit svůj kód. Rychle se však ukázalo, že je s tímto názorem mezi vývojáři v menšině. Zvláště otrávený byl Adrian, který si stěžoval, že zatímco jiní vývojáři smějí bez varování provádět změny, kvůli kterým nefungují skoro všechny existující moduly, jeho patch, který se dotkne jen několika málo modulů, musí procházet speciálním procesem. Řekl na to:

Andrew, definuj prosím pro API pravidla. Jinými slovy: pravidla pro přidávání, odstraňování a změny exportovaného kódu, která budou platit pro *každého*, nebo jdi s EXPORT_UNUSED_SYMBOL do háje.

Christoph Hellwig reagoval také zostra, což vedlo k tomuto zábavnému rozhovoru (možná ne tak zábavnému pro citlivější povahy). Chladnější hlavy uvedly několik argumentů proti varování:

• Tyto symboly už mají hlavu na špalku dost dlouho a většina autorů modulů, které nejsou součástí jádra, už si toho měla všimnout. Stojí však za povšimnutí že v plánu pro odstraňování v dokumentaci k jádru o sys_open() a sys_read() nic není.


• V těchto situacích jsou veškerá varování neúčinná. Uživatelé si jich většinou vůbec nevšimnou a i kdyby, tak je stejně nenahlásí. Alan Cox to vidí takhle: Pokud nepoužiješ jejich zvukovku, aby na ně počítač zařval 'Od další verze máš smůlu', tak si ničeho nevšimnou (a když to s tou zvukovkou uděláš, tak si budou myslet, že je někdo hacknul...).


• Udržování nepoužívaných symbolů nechává v jádře nepořádek a ztěžuje práci vývojářům, kteří si musejí pamatovat, že mají být v dalších verzích odstraněny.

Nevypadá to však, že by chtěl Andrew ustoupit. Nechce uživatele zbytečně otrávit:

Skutečnost je taková, že lidé používají i moduly, které nejsou přímo v jádře. Aby jejich počítače pořádně fungovaly, aby mohli dělat svoji práci, aby mohli dělat to, co chtějí.

Spousta z nich nejsou programátoři. Takže když si stáhnou nové jádro a zjistí, že modul, který používají, nefunguje kvůli něčemu, co jsme udělali my, naštvou se a my přijdeme o testera. To už se stalo mockrát.

Aby se tomuto problému zabránilo, chce symboly, které mají být odstraněny, označovat pomocí EXPORT_UNUSED_SYMBOL() (nebo EXPORT_UNUSED_SYMBOL_GPL()) na jeden vývojový cyklus. Exporty by také měly být označeny komentářem, který by říkal, kdy budou úplně odstraněny. Při každém vydání by se provedl rychlý grep, pomocí kterého by se zjistilo, které symboly mají být právě odstraněny:

Celkové náklady na takové řešení: možná deset minut práce při každém vydání a pár desítek bajtů navíc ve vmlinux. Myslím, že je to dobrá cena za několik dalších testerů a méně otrávených uživatelů. Toť vše.

Na jiném místě poznamenal, že pokud je varování na dostatečném počtu míst, někdo na něj někde zareaguje. Nezdá se však, že by se mu podařilo přesvědčit hodně vývojářů. Ale Andrew má díky své pozici možnost si tento postup vynutit. A většina ostatních si patrně myslí, že je snazší se mu v tomto případě podřídit. Výsledek bude stejný, jen to bude trvat trochu déle.

Kdo napsal a schválil 2.6.23

Ačkoliv vývojový cyklus jádra 2.6.23 ještě není uzavřen, už se blížíme ke konci, takže si můžeme říci o celkových statistikách nové verze. Do této chvíle (těsně po vydání 2.6.23-rc6) bylo do hlavního repozitáře jádra začleněno něco přes 6 200 sad změn. Pocházejí od 854 vývojářů - o něco nižší číslo než v případě 2.6.22. 350 z nich přispělo jedinou sadou změn.

Patche přidaly téměř 430 000 řádků, ale odstranily 406 000, což znamená, že jádro povyrostlo o 23 000 řádků - relativně malé číslo. Částečně to je zásluhou jaderného kata Adriana Bunka, který odstranil starý kód SpeedStep, několik ovladačů Open Sound System (OSS), podporu procesoru Rise a další věci - téměř 73 000 řádků. Jeff Garzik odsekal přes 41 000 řádků kódu síťových ovladačů a Jens Axboe se zbavil více než 25 000 řádků - většinou šlo o prehistorické ovladače CDROM.

Následuje seznam nejaktivnějších přispěvatelů do 2.6.23. Řazeno podle začleněných sad změn a změněných řádků:

Nejaktivnější vývojáři 2.6.23

podle sad změn Ingo Molnar 152 2,5 % Ralf Baechle 119 1,9 % Trond Myklebust 116 1,9 % Paul Mundt 111 1,8 % David S. Miller 107 1,7 % Tejun Heo 103 1,7 % Al Viro 95 1,5 % Patrick McHardy 93 1,5 % Adrian Bunk 92 1,5 % FUJITA Tomonori 91 1,5 % Avi Kivity 72 1,2 % Andrew Morton 71 1,1 % Greg Kroah-Hartman 62 1,0 % Alan Cox 58 0,9 % David Brownell 56 0,9 % Jeff Garzik 55 0,9 % Christoph Hellwig 54 0,9 % Stephen Hemminger 53 0,9 % H. Peter Anvin 52 0,8 % Jesper Juhl 52 0,8 %

podle změněných řádků Adrian Bunk 73254 11,0 % Jeff Garzik 43253 6,5 % Jens Axboe 28004 4,2 % Hirokazu Takata 20399 3,1 % Yoichi Yuasa 18368 2,8 % James Smart 15626 2,4 % Jeremy Fitzhardinge 15398 2,3 % David S. Miller 14752 2,2 % Matthew Wilcox 14750 2,2 % Christoph Hellwig 14550 2,2 % Rusty Russell 9452 1,4 % Imre Deak 8925 1,3 % Dan Williams 8510 1,3 % Ralf Baechle 8345 1,3 % Doug Thompson 7310 1,1 % Jošihiro Šimoda 6981 1,1 % Marc St-Jean 6888 1,0 % Luca Olivetti 6540 1,0 % Cyrill Gorcunov 6371 1,0 % Latchesar Ionkov 5375 0,8 %

Ingo Molnar je na prvním místě kvůli začlenění plánovače CFS - a následným opravám. Více než polovina jeho patchů byla přijata po vydání 2.6.23-rc1. Ralf Baechle a Paul Mundt přispěli mnoha změnami ve stromech architektur, Trond Myklebust pracoval na NFS a, ačkoliv měl David Miller hodně patchů v síťování, většina změn od něho se týkala stromu architektury SPARC. Čísla v tabulce řazené podle změněných řádků jsou ovlivněna odstraňováním kódu (vizte výše); Jens Axboe také pracoval na splice a začlenil obecný SCSI ovladač "bsg". Hirokazu Takata pracoval na architektuře m32r a James Smart přispěl změnami Fibre Channel. Jeremy Fitzhardinge začlenil jádro kódu Xen.

Následující tabulka ukazuje výsledky snahy o přiřazení patchů ke společnostem, které podpořily jejich vvoj. Je potřeba to brát s rezervou; mělo by to být z většiny správně, ale protože patche nemají žádnou kolonku "Za-vývoj-zaplatil:", tak je vždy potřeba trochu hádat.

Nejaktivnější zaměstnavatelé

podle sad změn (neznámý) 1180 19,0 % Red Hat 744 12,0 % (žádný) 559 9,0 % IBM 507 8,2 % Novell 421 6,8 % Intel 184 3,0 % Oracle 146 2,4 % Renesas Technology 134 2,2 % MIPS Technologies 119 1,9 % NetApp 116 1,9 % (konzultant) 103 1,7 % Google 99 1,6 % NTT 98 1,6 % Sony 93 1,5 % Astaro 93 1,5 % Linux Foundation 82 1,3 % MontaVista 81 1,3 % SGI 77 1,2 % Qumranet 72 1,2 % QLogic 62 1,0 %

podle změněných řádků (neznámý) 111777 16,9 % (žádný) 99649 15,0 % Red Hat 84224 12,7 % IBM 39449 5,9 % Oracle 36205 5,5 % Renesas Technology 33152 5,0 % HP 18718 2,8 % Tripeaks 18567 2,8 % Novell 17990 2,7 % Emulex 15942 2,4 % XenSource 15426 2,3 % Intel 14962 2,3 % Sony 11945 1,8 % Analog Devices 10345 1,6 % rPath 9678 1,5 % MIPS Technologies 9171 1,4 % Solid Boot Ltd. 8937 1,3 % MontaVista 8065 1,2 % PMC-Sierra 6888 1,0 % Astaro 6687 1,0 %

Red Hat si drží první pozici v seznamu řazeném podle sad změn, i když podíl je o trochu menší. Podle změněných řádků porážejí vývojáři pracující ve vlastním čase (řádek "žádný") všechny komerční přispěvatele. Stojí za zmínku, že většina započítaných řádků byla ve skutečnosti odstraněna.

Pohled na řádky Signed-off-by: (podepsal) je také zajímavý - zvláště když se podíváme na podpisy lidí, kteří nejsou autory podepisovaných patchů. Získáme tak představu o tom, kdo pracuje jako vrátný. Tentokrát byl výpočet proveden trochu odlišně: pokud patch podepsal jak Linus Torvalds, tak Andrew Morton, Linus se nepočítal. Protože všechno, co přejde přes Andrewa, podepisuje i Linus; když nepočítáme tato automatická podepsání, dostaneme věrnější obrázek schvalovacího procesu.

vývojáři s nejvíce podpisy (celkem 5653)
Andrew Morton	1247	21,6 %
Linus Torvalds	397	6,9 %
David S. Miller	381	6,6 %
Greg Kroah-Hartman	329	5,7 %
Jeff Garzik	287	5,0 %
James Bottomley	264	4,6 %
Paul Mackerras	223	3,9 %
Mauro Carvalho Chehab	150	2,6 %
Len Brown	128	2,2 %
Ralf Baechle	122	2,1 %
Roland Dreier	116	2,0 %
Andi Kleen	113	2,0 %
Russell King	101	1,8 %
Jaroslav Kysela	100	1,7 %
John W. Linville	70	1,2 %
Tony Luck	65	1,1 %
Takashi Iwai	63	1,1 %
Jens Axboe	58	1,0 %
Martin Schwidefsky	55	1,0 %
Ingo Molnar	51	0,9 %

Občas se objeví dotaz, jak tato čísla vypadají u jednotlivých částí jádra. Jonathan Corbet upravil svoje skripty, aby tyto informace získal. Následují tabulky se souhrnem výsledků - podle společností:

příspěvky v subsystémech podle zaměstnavatelů
/arch (celkem 1428) (neznámý) 222 15,5 % IBM 198 13,9 % Red Hat 128 9,0 % (žádný) 108 7,6 % Renesas Technology 101 7,1 % MIPS Technologies 89 6,2 % Sony 55 3,9 % Novell 46 3,2 % Intel 46 3,2 % rPath 42 2,9 %	/block (celkem 103) NTT 27 26,2 % Oracle 15 14,6 % (neznámý) 10 9,7 % IBM 8 7,8 % Red Hat 6 5,8 % (žádný) 5 4,9 % Miracle Linux 4 3,9 % Computer Consultants 3 2,9 % Novell 3 2,9 % Sony 3 2,9 %
/Documentation (celkem 241) (neznámý) 66 27,4 % Novell 27 11,2 % IBM 19 7,9 % Oracle 19 7,9 % (žádný) 18 7,5 % Intel 16 6,6 % Red Hat 13 5,4 % (Consultant) 6 2,5 % Freescale 5 2,1 % NEC 4 1,7 %	/drivers (celkem 2762) (neznámý) 572 20,7 % (žádný) 356 12,9 % Novell 237 8,6 % Red Hat 236 8,5 % IBM 191 6,9 % Intel 130 4,7 % (Consultant) 68 2,5 % NTT 65 2,4 % Qumranet 63 2,3 % QLogic 61 2,2 %
/fs (celkem 622) Red Hat 107 17,2 % Oracle 80 12,9 % NetApp 74 11,9 % (neznámý) 72 11,6 % Novell 63 10,1 % IBM 56 9,0 % Univ. of Michigan CITI 35 5,6 % SGI 26 4,2 % (Academia) 19 3,1 % SWsoft 17 2,7 %	/kernel (celkem 938) Red Hat 259 27,6 % (neznámý) 129 13,8 % IBM 119 12,7 % Renesas Technology 52 5,5 % (žádný) 44 4,7 % Novell 36 3,8 % MIPS Technologies 31 3,3 % Fujitsu 30 3,2 % Intel 28 3,0 % Linutronix 27 2,9 %
/mm (celkem 261) IBM 38 14,6 % (neznámý) 38 14,6 % Renesas Technology 33 12,6 % SGI 29 11,1 % Novell 24 9,2 % Google 19 7,3 % Red Hat 13 5,0 % (žádný) 10 3,8 % ARM 7 2,7 % igel 6 2,3 %	/net (celkem 833) (neznámý) 178 21,4 % Astaro 92 11,0 % Red Hat 87 10,4 % (žádný) 71 8,5 % IBM 53 6,4 % Linux Foundation 48 5,8 % NetApp 47 5,6 % Broadcom 23 2,8 % Intel 18 2,2 % HP 17 2,0 %

Z těchto čísel lze vyvodit, že vývojáři Red Hatu mají silné zastoupení v "jádře jádra" [core kernel], ale psaní dokumentace příliš neholdují. Hodně "nadšenců" se účastní práce na ovladačích - což není nijak překvapující. Akademici si rádi hrají se souborovými systémy, stejně jako společnosti Oracle a NetApp - opět nic překvapujícího.

Kromě toho, že jde o přibližná čísla, tak ještě před finálním vydáním 2.6.23, které je ještě nejméně tři týdny vzdálené, dojde ke změnám. Začleňovány by však měly být jen opravy, takže snad budou změny (při troše štěstí) malé. Na 2.6.23 je vidět, že máme aktivní vývojářskou komunitu s příspěvky od mnoha různých lidí - a nemálo firem, které je zaměstnávají.

(Dík patří Gregu Kroah-Hartmanovi za pomoc s přípravou skriptů použitých k vygenerování těchto statistik.)

       

Komentáře

[Michal]

To je priserny pohled. Linux je... ztracen.

[Zdenek Slama]

Jo jo, Jenom tri zastupkyne nezneho pohlavi , teda jestli jsem se nekde neprehlidnul.

[Mandarinka]

Oj, jaké "ztracen"? Takováhle hrůza to snad byla vždycky. ne...

[Peter S.]

Konečne viem ako vyzerá Linus ... a to linux používam už 5 rokov

[satanatas]

si děláš kozy ne? a jak vypadá RMS víš? já sem teda nevěděl jak vypadá alan cox, a vypadá dobře :-}

[jirí zika]

Nejlepší jaderné noviny. Tyhle si budu pamatovat.

[Čech Antonín]

+1

[kerala]

Nevidím žádné příspěvky od Canonicalu nebo *buntu, asi nepřispívají do GNU/Linux.

[Jan Kundrát (jkt)]

GNU/Linux je jmeno operacniho systemu, kernel zove "Linux".

[Michal Kubeček]

Ta tabulka zahrnuje pouze příspěvky do jádra, a to ještě jen změny mezi 2.6.22 a 2.6.23.

[Michal]

Hledej na fotce Kyle McMartin, https://launchpad.net/~kyle

[Jan Kundrát (jkt)]

Poznamka k Linusove citatu -- mozna by bylo lepsi to prelozit jako "Upřímně, i kdyby C v jádře nesloužilo k *ničemu* jinému než k odrazování C++ programátorů, tak by to pořád stálo za to."

[Tom.š Ze.le.in]

Asi ne. Podle kontextu mluví o gitu :)

[Jan Kundrát (jkt)]

jo, jasne, sorry. takze s/v jadre/v gitu/

[allstar]

Asi sem ten citat nepochopil. Nevim co má proti C++, je to prece jeden z vubec nejlepsich programovacich jazyku.

[mehturt]

precitaj si cely thread v mailing liste o tom..

[zde]

je to prece jeden z vubec nejlepsich programovacich jazyku.

Prvních pět let potom co jsem se C++ naučil jsem si to myslel taky. Stuuuupid me. Mimochdem Linux měl v té diskusi i ještě mnohem tvrdší názory, např.

And if you want a fancier language, C++ is absolutely the worst one to choose. If you want real high-level, pick one that has true high-level features like garbage collection or a good system integration, rather than something that lacks both the sparseness and straightforwardness of C, *and* doesn't even have the high-level bindings to important concepts. IOW, C++ is in that inconvenient spot where it doesn't help make things simple enough to be truly usable for prototyping or simple GUI programming, and yet isn't the lean system programming language that C is that actively encourags you to use simple and direct constructs.

S tímhle naprosto souhlasím. Potřebuju něco naprototypovat? Použiju python, perl, ruby, php. Potřebuju něco udělat velmi efektivní? Napíšu to v C. Pro C++ opravdu není (krom legacy věcí) místo.

[Michal Kubeček]

Ve vašem světě možná ne. V tom našem je ho až až.

[m0rph]

V tomhle pripade je IMHO polish = polsky podle vzoru Reverse Polish Notation.

[Robert Krátký]

Díky - přiznávám, že jsem vůbec neměl páru (tak to nejspíš Andrew chtěl...) - přeložil jsem to jen z legrace.

[Jiri]

No já nevím. Napsal to původně s velkým P? Jestli ne, tak bych se překladu "polský" raději vyhnul.

[Hynek (Pichi) Vychodil]

To je terminus technicus, jestli ti to nedošlo.

[andree]

tak to je pecka, moj cviciaci programka z prvaku - Honza Kara (dolny rad, viac vpravo) je na tej fotke... niiice

[Milan Jurik]

To opravdu nikomu neprijde zvlastni, ze distributori se snazi vyhovet zakaznikum a za to je vyvojari sprdavaji?

[michich]

Ani ne, ale nevím, o čem konkrétně mluvíš.

[Milan Jurik]

KS2007: The distributor panel - http://lwn.net/Articles/248195/

[Michal Kubeček]

Přečetl jsem si to pozorně a rozhodně jsem z toho neměl dojem tak ostré konfrontace, jak se to snažíte prezentovat. Prostě měla každá strana trochu jiné představy, jak by měla spolupráce vypadat, tak si je vyjasnili. Proč hned mluvit o sprdávání?

[Milan Jurik]

Psal jsem nekde, ze to byla ostra konfrontace? Sprdavat ma pro vas az tak vyrazne zabarveni? A ty jine predstavy uz tu existuji peknou radku let, nerekl bych, ze si to vyjasnili na tomto setkani, jak se tu snazite rici

Jen me proste zaujalo, ze vyvojare "prekvapuje", ze distributori kladou duraz na zajmy svych zakazniku. Sokujici

[Michal Kubeček]

Já bych neřekl, že je to nějak zvlášť překvapuje. Spíš se jim to jen moc nelíbí a rádi by to trochu posunuli směrem ke svým představám. Co by ovšem překvapilo mne, by bylo, pokud by se jim to v nějaké nezanedbatelné míře povedlo. Taková změna jaderného ABI během release cyklu, to by mohlo firemní zákazníky opravdu oslovit; nejspíš by brali nohy na ramena tak rychle, že by se ani nestihli rozloučit… :-)

[Jardík]

Není pondělí? Kde jsou Lubošem slibované "Distribuční novinky".

[Robert Krátký]

Ve frontě.

[Miloslav Ponkrác]

Koukám, že Linus zase prezentuje, jak neumí C++, a jak mu C++ dalo na prdel, když se ho pokoušel ho zvládnout. No jo, nikdo nezvládneme všechno...

[Michal Kubeček]

Neřekl bych, že se o to pokoušel, ale nedokázal to. Spíš k tomu od začátku přistupoval s tím, že si chce jen ověřit, že C++ za nic nestojí, takže výsledek odpovídal tomu, co od C++ chtěl.

[Jan]

no predevsim a hlavne C++ je nadstavba C takze programy v C jsou zaroven programy v C++. Ergo nadava sam sobe

[Michal Kubeček]

Jenže to je právě jedna ze základních chyb: dívat se na C++ jako na trochu rozšířené C a programovat v něm jako v "C s vylepšeními".

[Jan]

To prave ze ne. Za spatnou povest C++ muzou prave silenci, kteri si mysli, ze musi vyuzit vsecky ficury uz v Hello World. To pak vznikaji paskvily, jejichz jedinym ucelem je demonstrovat autorovo Ego a ty pravem odrazuji lidi jako je Linus.

V cecku to m.j. jde taky. Vzpomente si na vousaty priklad aplikace napsane jako prikaz for. Kultura a zdravy rozum zpusobuji, ze podobne vystrelky uz dnes vidime zridka. Zato v C++ se zkonstruovani objektu aplikace s overloadovanym operatorem funkcniho volani (misto volani main) povazuje nekterymi jedinci stale jeste za dobry (a jediny mozny) styl prace. Je to tim ze C++ je mladsi a slozitejsi. Ale lepsi se to.

[Michal Kubeček]

Za spatnou povest C++ muzou prave silenci, kteri si mysli, ze musi vyuzit vsecky ficury uz v Hello World.

Jenže C++ opravdu není "C s featurami". Je to samostatný jazyk s odlišnou filosofií. Pokud napíšete Hello World jako

#include <stdio.h>

int main()
{
  printf("Hello, world!\n");
  return 0;
}

pak to sice C++ překladačem přeložíte, dokonce to bude i správně fungovat, ale není to programování v C++.

[Jirka Wolny]

Rozdíly mezi C a C++ jsou sice velké, ale zrovna Hello world je nešikovně zvolený příklad. Kdybych měl v C++ vytvořit aplikaci Hello world, tak bude vypadat přesně takhle, implementace pomocí objektů by vypadala dost uměle.

[Michal Kubeček]

Proč myslíte? Mně na tom nic umělého nepřipadá:

#include <iostream>

int main()
{
  std::cout << "Hello, world!\n";
  return 0;
}

Svým způsobem je to možná i srozumitelnější než v tom C - hlavně pokud bychom pokročili kousek dál a do výstupu chtěli zahrnout třeba hodnoty nějakých číselných proměnných.

[Michal]

A takovy nesmysl vam nakukal kdo? Uz jen z duvodu vetsiho mnozstvi klicovych slov v C++ musi byt kazdemu, kdo ma alespon trosku o tech jazycich predstavu, jasne, ze vami uvadene tvrzeni je nepravdive.

[Michal Kubeček]

A co je na něm nepravdivého? Sice se dá vytvořit zdroják, který je korektním programem v C, ale není korektním programe v C++, ale rozhodně nevznikne přirozenou cestou - musíte znát rozdíly a snažit se o to.

[Miloslav Ponkrác]

Ano, přesně od lidí s takovými názory pak vznikne srovnávání C s C++. Ne, C++ chce naprosto jinou filozofii a způsob psaní programů, než C. Ty rozdíly jsou obrovské.

[Martin Doucha]

Jistě, ale to je právě smysl Linusova komentáře. Podle filozofie C++ nejsou hlavní body návrhu Gitu zajímavé, ale podle filozofie C jsou. Proto je pro ten projekt výhodnější C než C++.

[Tom.š Ze.le.in]

Dovolil bych si oponovat. Viděl jsem autentický zdroják v C, který bylo nutné upravit aby prošel v C++ kompilátoru. Stačilo, že autor považoval za vhodné pojmenovávat dočasné proměnné vzniklé xorováním jako xor.

[Michal Kubeček]

Jenže to jen potvrzujete moje slova - to je přesně ten případ, o kterém jsem mluvil.

[Tom.š Ze.le.in]

Jaká slova? Tahle ne:

rozhodně nevznikne přirozenou cestou - musíte znát rozdíly a snažit se o to

[Michal Kubeček]

OK, takže doplním "…nebo se do nich nešťastnou náhodou trefit." Osobně bych xor jako identifikátor nepoužil v žádném jazyce, protože mi nestojí za to pamatovat si, ve kterém jazyce je to rezervované slovo a ve kterém ne, tak taková potenciálně nebezpečná jména nepoužívám raději nikde.

[Michal]

Vazeny pane, kdybyste nekdy prevadel algoritmus z jednoho jazyka do druheho tak byste nikdy nic takoveho nepsal. Konstrukce vyvolavajici syntakticke chyby se v C naprosto bezne pouzivaji.

A vznikaji rozdily nejen syntakticke ale nekdy i semanticke- obcas se program prelozi ale dela neco jineho. Nedavno jsem resil asi dva dny zahadnou nefunkcnost programu a duvodem bylo v podstate jen to, ze

double bz;

void main() {
  struct bz { int fn;}
  printf("%d",sizeof(bz));
}

vypise v C i v C++ neco jineho akorat v mem pripade to bylo ve velkem programu a zasmodrchane.

[Michal Kubeček]

Promiňte mi mou upřímnost, ale pojmenovat si globální proměnnou a lokální strukturu stejně, to je prasárna bez ohledu na C a C++. Že to syntaxe jazyka umožňuje, ještě neznamená, že je správné to používat.

[Michal]

Obe casti zrejme psali jini lide s odstupem (hrubym odhadem) 15 let a na obou mistech pojmenovani davalo smysl. To je ale nepodstatne jestli to je nebo neni osklive. Podstatne je, ze se takove veci v realnych zdrojacich proste vyskytuji.

[Michal Kubeček]

V tom případě bych ale spíš vyčítal oběma jazykům, že takovou kombinaci připouštějí. A gcc, že to nehlásí aspoň jako warning ani při -Wall.

[Miloslav Ponkrác]

A je naprosto správné, že to nehlásí, protože se nejedná o nic špatného. Vzhledem k tomu, že duplikace názvů objektů se v mnoha vydáních zcela automaticky objeví v každém rozsáhlejším projektu - a je to zcela přirozené a v pořádku, nechápu, proč by to měl být warning.

[Michal Kubeček]

Pokud by se jednalo o objekty stejného typu a vždy platilo, že lokální deklarace má přednost, měl byste pravdu. Tady jde ale o kolizi jména proměnné a typu a jazyky C a C++ se chovají každý jinak.

[Miloslav Ponkrác]

A nejenom, že se při kolizi jmen chovají C a C++ zcela jinak, protože některá jména objektů prostě C i C++ zařazí do jiného prostoru jmen. Ono jde o to, že třeba i konstanty mají v C i C++ jiný typ a mnoho dalších drobných odlišností. Třeba 'x' je v C typu int, zatímco v C++ typu char. A to bychom o těch rozdílech mezi C a C++ mohli mluvit ještě hodně dlouho. Ten člověk, co psal, že C je bez problému C++ zdroják musel mít řádně vypito z láhve, a nebo - což je pravděpodobnější - věděl o tom hovno. Omlouvám se, ale nemám proč si dělat servítky.

[Michal Kubeček]

Ten člověk, co psal, že C je bez problému C++ zdroják musel mít řádně vypito z láhve, a nebo - což je pravděpodobnější - věděl o tom hovno.

Bez ohledu na vaše silné výrazivo je to ovšem v naprosté většině případů pravda. Vážně byste jednou mohl zkusit argumentovat věcně, bez urážení oponentů a neustálého zdůrazňování, jaké jsou to nuly a jak ničemu nerozumějí. Pokud jste toho tedy schopen…

[Miloslav Ponkrác]

Pane Kubečku, Vy jste asi nikdy nic většího, než několik řádek zdrojáku asi nenapsal, co?

Za prvé, proč bych si měl starat ve větším projektu, jestli náhodou nepojmenovávám lokální objekt stejně jako globální? Proč bych se o to vůbec měl starat, jestli globální objekt v lokálním scope nepotřebuji, a nebo dokonce o existenci globálního objektu ani nevím, což je zvláště u rozsáhlých projektů a týmové práci více, než běžné?

Pokud dělá na projektu více lidí, pak nelze neustále hlídat co kde je jak pojmenováno a právě pravidla o přebití názvu objektu v lokálním scope nad stejně pojmenovanými objekty v nadřazených scope je právě myšlena prakticky hlavně pro tento případ.

[Michal Kubeček]

Invektivy si laskavě nechte od cesty, nejsem na ně zvědavý. Odpověď vám dává právě ta ukázka, o které je tu řeč. Dva příbuzné jazyky (C a C++) umožní pojmenovat dva objekty rozdílných typů stejně, ale pak ve stejné konstrukci každý z nich použije jiný.

[Miloslav Ponkrác]

Jaké invektivy? Těch ukázek co demonstrují odlišné chování stejného C a C++ zdrojáku by to mohlo být mnohem více - protože těch rozdílů, kdy stejný zdroják pochopí jinak C a jinak C++ je poměrně slušné množství.

Ale já už si všiml, že jakmile někdo napíše, že C a C++ je totéž jen s malými rozdíly - že to znamená, že onen člověk prostě neumí pořádně ani C, ani C++. C a C++ jsou velmi odlišné jazyky s odlišnou filozofií, které jen stavěji na společném syntaktickém základu.

[Michal]

Musim souhlasit. Stroustrup udelal hroznou chybu. Navrhl odlisny jazyk ovsem se syntaxi velmi zblizenou k C. A z toho vznikaji takove divoke predstavy.

Cela tato diskuze vznikla z duvodu tvrzeni "programy v C jsou zaroven programy v C++".

Na toto lze nahlizet na tri zpusoby:

a)Logicky - pak lze snadno ukazat silou matematickeho dukazu, ze toto tvrzeni neplati.

b)Prakticky - tvrzeni neplati pac v bezne se vyskytujicich zdrojacich psanych v C jsou konstrukce syntakticky nepripustne v C++ nebo dokonce semanticky odlisne.

c)Filosoficky - tady bych si dovolil dokonce tvrdit opak. Zadny netrivialni program v C neni soucasne "politicky korektnim" programem v C++. I "Hello World!" vypada jinak.

Pan Kubecek neni schopen nic z toho pripustit a porad rika svou... Dalsi diskuze za techto podminek myslim nema zadny vyznam.

[Michal Kubeček]

Ani jednou jsem nenapsal, že každý program v C je zároveň programem v C++, natož pak stejně fungujícím. Takže pokud z takového tvrzení hodláte vyvozovat, že jsem blb, račte si posloužit, ale vypovídá to jen a jen o vás, ne o mně.

[Michal]

Jakto, ze nenapsal? To v uvozovkach byla presna citace. Univerzalni kvantifikator tam neni uveden explicitne neni ale implicitne tam je.

[Michal Kašpar]

Ano. Skoro přesná citace. Jen ne pana Kubečka.

[Michal Kubeček]

Přesná citace to sice je, ale ne z mého příspěvku. Takže pokud nemáte jinou, je mi líto…

Co se velkého kvantifikátoru týká, v běžné řeči nebývá zvykem ho implicitně používat v plném rozsahu. Nebo snad podle vás každý, kdo si povzdechne "lidi jsou svině", tím automaticky myslí všech šest miliard včetně sebe a toho, komu to říká? Asi ne… Proto také, pokud chceme v běžné řeči opravdu použít velký kvantifikátor, používáme pro zdůraznění každý, všichni apod. Ale to je stejně jedno, jak už jsem upozornil, příspěvek, na základě něhož mne pranýřujete, jsem nepsal já.

[Michal Kubeček]

Jaké invektivy?

Už v dřívějších diskusích jsem si všiml, že nedokážete udržet diskusi ve věcné rovině a jakmile si s vámi někdo dovolí nesouhlasit, a co hůř, i po prvním okřiknutí si drze dovolí stát za svým názorem, okamžitě prokládáte své příspěvky poznámkami naznačujícími, jaký je ten člověk blbec, jak ničemu nerozumí, jak nikdy nic pořádného nenaprogramoval atd. Možná si to ani neuvědomujete, ale vězte, že je to nedůstojné a nechutné. Prosím vás proto, abyste toho nechal.

Ale já už si všiml, že jakmile někdo napíše, že C a C++ je totéž jen s malými rozdíly - že to znamená, že onen člověk prostě neumí pořádně ani C, ani C++. C a C++ jsou velmi odlišné jazyky s odlišnou filozofií, které jen stavěji na společném syntaktickém základu.

Nic takového jsem ovšem nenapsal. Pouze jsem napsal (nebo spíš podpořil kolegu, který to napsal první), že C je z hlediska syntaxe téměř podmnožinou C, protože těch odlišností, kdy se céčkový program nedá přeložit jako C++, je docela málo. A že vznikají buď tak, že se úmyslně snažíte takový program zkonstruovat, nebo že máte zatracenou smůlu (a mnohdy si za to můžete sám - jako třeba ve výše uvedené ukázce). To je prostě fakt - a kolik takových umělých ukázek tu zkonstruujete, to na věci nic nezmění.

[Miloslav Ponkrác]

Ad první odstavec. Nejsem si vědom toho, že bych taky z někoho dělal blbce, myslím, že jste přecitlivělý. Nikdy jsem o nikom nenapsal, že je DANÁ OSOBA blbec, nebo jakoukoli jinou urážku. NIKDY!!! Nikdy jsem nezaútočil nad rozdíl od mnohých jiných přímo na osobu! Jediné co jsem napsal, že JEJÍ NÁZORY považuji za nesprávné, špatné, že s nimi nesouhlasím a v krajním případě že ví o daném problému (censored). Vždy jsem napadal pouze věcnou rovinu, tedy argumenty. Všimněte si prosím toho. A pokud jsem někomu (asi tak 2x v životě) napsal, že ví o daném problému kulové, dlouho jsem nad tím přemýšlel, a bylo to v oboru, ve kterém se bezvadně orientuji a mám v něm rozsáhlé znalosti.

Na druhé straně jsem tu dostal daleko drsnější chování a řada lidí mě vůbec nešetřila. Většinou jsem to oplácel vtipem a humorem a nikdy jsem to neoplácel stejně tvrdě. Řada lidí tu bezostyšně (za potlesku mnoha dalších) prezentuje, jak nesnášejí tu osobu, nebo jinou. Řada lidí tu neustále dokazuje méněcennost druhých zveřejňováním seznamu, koho blokují (jako by to někoho zajímalo), či neustálým vyjmenováváním, jakých přestupků se daná osoba/y dopustila v minulosti a omlacováním všeho možného nevěcného přes ústa až do zblbnutí. Já to nedělám, nikdy jsem nikoho nezatratil a nikdy jsem nikomu nedal najevo, že se s ním nebudu bavit, protože je to xy.

Vždy a to absolutně jsem reagoval pouze a jedině na argumenty a názory a to bez ohledu, ať je napsal kdo chce. Dokažte mi opak.

[Michal Kubeček]

Zajímavé. Proč mne tedy místo uvedení věcných argumentů hned na začátek příspěvku napadáte, že jsem nikdy nenapsal nic většího než pár řádků? A to se mi ani nechce dohledávat všechny ty povýšené pošklebky na mou adresu v minulé diskusi, kdy jsme se neshodli.

Stěžujete si, že tu na vás byli oškliví a že vás uráželi daleko hůř. Tomu docela dobře věřím. Ale dělal jsem to já? Zpochybňoval jsem snad vaši odbornou erudici? Psal jsem, že jste jakživ nic netriviálního nenaprogramoval? Nejsem si toho vědom. Takže pokud nejste schopen doložit že ano, znovu vás prosím, abyste se takových výpadů v komunikaci se mnou zdržel. Zkuste urážet a zesměšňovat jen ty, kdo se k vám chovají stejně, nedělejte to preventivně.

[Miloslav Ponkrác]

Proč mne tedy místo uvedení věcných argumentů hned na začátek příspěvku napadáte, že jsem nikdy nenapsal nic většího než pár řádků?

Protože bylo okamžitě z Vašich argumentů zřejmé, že obhajujete přístup, který lze použít jen u malých projektů.

Ke zbytku řeknu tolik - nebylo mým cílem Vás urazit, a určitě jsem měl volit jinou formu, za což se omlouvám. Jsem zvyklý osobně na tvrdé zacházení a nemám právo to posílat dál - takže si dám příště pozor, aby to nevyznělo urážlivě.

[Michal Kubeček]

Protože bylo okamžitě z Vašich argumentů zřejmé, že obhajujete přístup, který lze použít jen u malých projektů.

Mně se osvědčil i u větších. Za prvé se snažím, aby těch globálních objektů bylo co nejméně (ne víc, než je nezbytně nutné). Za druhé zastávám zásadu, že každý modul by měl navenek poskytovat jen to, co je opravdu potřeba. Za třetí ten (programátor), kdo ty deklarace includuje, by se měl seznámit s tím, co includuje a na kolize dávat pozor. Za čtvrté se snažím udržet nějaké jmenné konvence, které by měly v co největší míře eliminovat možnost kolize mezi objekty různých typů (třeba proměnná vs. typ resp. tag struktury); ne že bych byl příznivcem takových těch prefixových orgií (t_ pro typy, m_ pro metody apod.), ale myslím si, že není takový problém najít rozumný kompromis. Myslím si, že jsou to poměrně rozumné zásady, které se dají uplatnit i u projektů, na kterých se podílí větší počet programátorů, a IMHO jsou v takových případech ještě důležitější než u projektu, který je dílem jednotlivce.

[Miloslav Ponkrác]

Ad druhý odstavec. Ale ano, Céčkový program se často (zdaleka ne vždy) dá přeložit jako C++ kový, ale zhusta bude dělat něco trochu jiného - to je ten problém. Nemusíte se vůbec o nic snažit, odlišností mezi C a C++ je docela dost. Já to totiž na rozdíl od Vás vidím úplně naopak, pokud chci aby se zdrojový kód dal přeložit jako C i jako C++ program, tak na to musím myslet už při psaní toho zdrojového kódu. Náhodně přeložit C program jako C++ a riskovat, že si tam tak zavléknete náhodné chyby? Copak jsem nezodpovědný šílenec? Pokud už chci přeložit C zdrojový kód (u kterého se nepočítalo s C++kovým využitím) jako C++ - pak musím provést revizi toho kódu, důkladně ho projet a přesvědčit se, že interpretace toho zdrojového kódu bude stejná i v C++ - a provést případné korekce.

A prosím, strčte si ty "umělé ukázky" za klobouk, protože ... ale škoda slov.

[Michal Kubeček]

Ale no tak… Když vezmu náhodně céčkové projekty a z nich náhodně sto zdrojáků, přejmenuji jim přípony na cc a zkusím je přeložit, u kolika se mi to podle vás povede? Podle toho, co tu píšete, by to vypadalo, že tak s bídou deset. Já tvrdím, že spíš od devadesáti výš. A kdyby to bylo všech sto, ani trochu by mne to nepřekvapilo.

[Miloslav Ponkrác]

Jedna věc je to přeložit a druhá zaručit stejnou funkčnost. To jak budete úspěšný, záleží na tom, co překládáte - C++ například nepovoluje určitá automatická přetypování, která v C jdou:

třeba

char* buffer; buffer = malloc(20);

by Vám v C prošlo, ale v C++ to nepřeložíte.

Dále prototypy funkcí v C a v C++ mají jiný význam:

třeba

int funkce();

int main() { ... a = funkce(); ... };

projde v C bez varování a C to pochopí jako dostatečnou informaci, zatímco C++ si bude stěžovat.

A tak bych mohl pokračovat dál a dál - je toho opravdu dost, kde jsou rozdíly mezi C a C++. Takže záleží na tom, co je konkrétně ve zdrojovém kódu, zda budete mít problémy s přeložením, a nebo (což je daleko záludnější) s jinou funkčností téhož v C a v C++.

Proto říkám, že já osobně bych si neodvážil udělat překlad C zdrojového kódu naslepo do C++ - očekával bych zde záludné chyby a to i v případě, že by to bezchybně prošlo C++ kompilací.

[Michal Kubeček]

Proto říkám, že já osobně bych si neodvážil udělat překlad C zdrojového kódu naslepo do C++ - očekával bych zde záludné chyby a to i v případě, že by to bezchybně prošlo C++ kompilací.

Sice jsem to výslovně nenapsal, ale to bych se samozřejmě neodvážil ani já. Jedna věc je (akademická) otázka, zda typický C zdroják funguje i jako C++, ale vzít cizí céčkový zdroják a vrazit ho bez kontroly coby C++ kód do C++ projektu, to je samozřejmě něco úplně jiného. Vzhledem k tomu, že se u vlastních zdrojákům určitým zavánějícím praktikám vyhýbám i v C (třeba té ukázce s implicitním přetypováním pointerů), řekl bych, že u mých zdrojáků by to zase takové riziko nebylo (ale zkontroloval bych je stejně). Ostatně kdo píše střídavě v C i C++, ten si ve vlastním zájmu zvykne se takovým problémovým konstrukcím vyhýbat.

Ta druhá ukázka v C++ projde, ale asi tuším, co jste měl na mysli - že v C ta deklarace reprezentuje jakoukoli funkci vracející int, zatímco v C++ jen funkci bez parametrů.

[Michal Kubeček]

Mimochodem, kdybyste si místo urážení oponentů ráčil přečíst, co píší, třeba byste si všiml, že prakticky totéž jako

C a C++ jsou velmi odlišné jazyky s odlišnou filozofií, které jen stavěji na společném syntaktickém základu.

jsem tu před pár hodinami napsal i já. Ale ono je jednodušší si honit triko, jak oponent nikdy nic nenapsal a vůbec nechápe, že je C++ něco jiného než C, že?

[zde]

Aha, pan Kubeček neumí C. Jinak by věděl že "struct bz" a "bz" jsou pojmenovány jinak. To že C++ ke každému struct/class dělá i zbytečný a pomýlený typedef (a nestará se o to co tím rozbije) je pak logicky jenom jeho problém...

[Michal Kubeček]

Spíš ho neumíte vy. Jinak byste věděl, že klíčové slovo struct rozhodně nelze považovat za součást jména a identifikátorem je zde samotné bz, i když samo o sobě nemůže sloužit jako specifikace typu.

P.S.: koukám, že jste převzal argumentační styl pana Ponkráce (když už nemůžeme oponenta přesvědčit argumenty, prohlásíme ho aspoň za blbce), tímto mu gratuluji ke skvělému pedagogickému úspěchu.

[egg]

Až na to, že C programátor ví, že identifikátory bz a struct bz jsou každý v jiném namespace.

[Michal Kubeček]

Takový C programátor by spíš měl vědět, že

1. 'struct bz' není identifikátor
2. v C žádné namespaces v pravém slova smyslu nejsou
3. jazyk C sice umožňuje v jednom zdrojáku korektně použít tentýž identifikátor asi tak v pěti různých významech (nechce se mi teď přemýšlet, kolik je to přesně), ale využívat toho je zlozvyk, který se člověku dříve či později velmi ošklivě vymstí

[Miloslav Ponkrác]

ad 2) v každém programovacím jazyce několik prostorů jmen je - ať přímo, či nepřímo. minimálně globální a lokální namespace.

ad 3) ano, jenže to neuhlídáte - ve větším projektu, nebo v týmu to nemusí jít, respektive náklady na takové hlídání nemají opodstatnění

[Michal Kubeček]

Ad 3. V tom se asi opravdu neshodneme. Já jsem přesvědčen, že právě v týmovém projektu jsou taková opatření ještě důležitější než pokud jde o práci jednotlivce.

[BrainLess]

Sakra tak to tak podle clanku vypada ze se nam v jadre ztraceji radky kodu a to rovnou v tisicich.

[BrainLess]

Patche přidaly téměř 430 000 řádků, ale odstranily 406 000, což znamená, že jádro povyrostlo o 23 000 řádků

[Robert Krátký]

Klíčové je slovo "téměř"

[David Watzke]

Ono se jich zas tak moc neztrácí, spíš se měněj

[Hynek (Pichi) Vychodil]

A to je snad dobře, ne? Nebo se jedná o nějaký maximum code lines contest? Jestliže při stejných features a neklesajícím výkonu mi klesá počet řádků tak s největší pravděpodobností dělám něco sakramentsky dobře.