Forkněte to glibc už někdo (diskuse)

[Pindal]

Žabomyší války v jazyku který nemá namespaces. Svět je prostě bizarní a nehostinné místo

[Mrkva]

K čemu jsou namespaces? Krom toho, že tady pak Doli bude brečet že si nemůže vybrat jméno namespace jaké chce :)

[xkucf03]

Slušné jazyky mají jmenné prostory a k nim doporučení, aby jejich název vycházel z tvojí domény (např. Java) nebo z tvého URL (např. XML), takže ke konfliktům zpravidla nedochází (pokud někdo není záškodník a nepoužívá tvoji doménu, nebo pokud ty nejsi blb a nepoužíváš cizí domény, nebo nejsi arogantní blb a nepoužíváš prostor, který vůbec není doménou).

[Martin Mareš]

A ony namespaces v Javě nějak řeší přibývání klíčových slov do jazyka?

[xkucf03]

Klíčových zrovna ne*, ale ty ostatní ano – pojmenování tříd/metod/proměnných, se kterými měl Doli problém.

*) i když ani tak v Javě tyhle konflikty nebývají – jediné, co jsem zaznamenal bylo zavedení „enum“, které mi „rozbilo“ jeden program (ale výhody z výčtových typů to bohatě převýšily)

[Luboš Doležel (Doli)]

A teď si představ, že by skupina javistů začala trvat na tom, že se jejich proměnná prostě _bude_ jmenovat enum. Říkám skupina, protože nástupci Ulricha nejsou o moc lepší.

[xkucf03]

Tak by jejich kód nešel přeložit a oni by museli proměnnou přejmenovat. Tohle ale není ten případ, ne?

[Sten]

Prostě by stejně jako Ulrich řekli, že novou Javu nepodporují a že pokud ji chcete používat, máte do Sunu napsat bug report

[Michal Kubeček]

Jestli narážíte na tu část o Austin group, tak on tam neříká, že se to má reportovat jako bug, ale že si máte nechat od nich vypracovat závazný výklad, že je to v rozporu se specifikací, a pak se tím teprve (možná) bude zabývat.

[tom]

A teď si představ, že by skupina javistů začala trvat na tom, že se jejich proměnná prostě _bude_ jmenovat enum. Říkám skupina, protože nástupci Ulricha nejsou o moc lepší.

V C tato situace nemuze nastat, protoze pridani noveho klicoveho slova vyzaduje include hlavicky. Pokud by v C nebylo enum a pridali by ho, musel byste si pro jeho pouziti naincludovat stdenum, takze stary kod vam to nerozbije.

[Martin Mareš]

Jenže zrovna tohle byl problém kolize s nově přidaným klíčovým slovem.

[Michal Čihař]

EGLIBC (neleknout se slova embedded), používá ji třeba Debian.

[Luboš Doležel (Doli)]

Jojo, zrovna v případě 1) reagovali prostým opravením názvu argumentu. Kompatibilita API/ABI zachována a všichni jsou šťastní.

[Ivan]

Tak jsem si tipnul, jestli v tech odkazech najdu jedno jmeno - a vyhral jsem. To je asi tak jediny co me muze tesit. Fakt nechapu, jak to cely GNU funguje. Linux kernel, gcc, core utils - vsechno jsou pragmaticky projekty, ktery jsou vstricny k uzivatelum. Krome glibc - jak vubec muzou mezi sebou komunikovat?

[Luboš Doležel (Doli)]

Jo, je to to hovado. To hovado, co reaguje slovy:

Strange, I never saw your name on my paycheck. Since if that's not the case you cannot order me around.

Na blogu o přechodu Debianu na eglibc jsou pěkné odkazy.

[Luboš Doležel (Doli)]

Tak jsem zjistil, že Drepper už dělá v Goldman Sachs (), ale taktéž zjišťuju, že ostatní lidi z Red Hatu nejsou o moc lepší.

[Michal Kubeček]

To myslíte vážně? Všude se najdou lidé, se kterými je - slušně řečeno - poněkud obtížná komunikace. Ale nevěřím, že by tam takoví byli všichni.

[Luboš Doležel (Doli)]

Špatně jsem se vyjádřil. Myslel jsem kolem glibc.

[Lol Phirae]

To myslíte vážně? Všude se najdou lidé, se kterými je - slušně řečeno - poněkud obtížná komunikace. Ale nevěřím, že by tam takoví byli všichni.

To se mu vážně divíte? Z poslední doby např. Gnome Bug 680118 - pokud vidím správně, "angažují" se tři vývojáři, všichni z RedHatu, jedno tydýt větší než druhý.

A to bych neměl zapomenout na patrně "nejslavnější" případ - Are you autistic or just a cunt? - RedHatu trvalo přes dva roky, než dotyčného konečně vyrazili.

[David Watzke]

OMG, to jsem zas na něco kliknul.

[Mrkva]

A to bych neměl zapomenout na patrně "nejslavnější" případ - Are you autistic or just a cunt? - RedHatu trvalo přes dva roky, než dotyčného konečně vyrazili.

Wow, tak to je hardcore.

[xxx]

Co to je za picuse, si stezuje, ze ho nekdo nazve picou, kdyz si ocividne dela picu ze vsech okolo. Spis je smutny, ze si v RH nedokazou pohlidat lidi co tam pracujou.

[alkoholik]

A zaregistrovali jste u toho bugu: Assigned To: Paul Nasrat?
Mozna to je nejaky brnensky vtip.
;)

[Michal Kubeček]

Člověk toho jména podle všeho existuje a Linuxem se zabývá, dokonce se i angažuje ve Fedoře, ale je přinejmenším zvláštní, že jako assignee za celou dobu nenapsal jediný komentář…

[Lol Phirae]

ale je přinejmenším zvláštní, že jako assignee za celou dobu nenapsal jediný komentář…

To je celkem pochopitelné vzhledem k tomu, že pan Nasrat ten bug zdělil až poté, co pan Píča (coby původní assignee) nuceně RH opustil a stačil mezitím jakožto "maintainer" uvést RPM do takového stavu, že se z toho několik let vzpamatovávali.

[smazáno]

neco mi rika ze jeho krestni jmeno zacina html symbolem pro necislovany seznam a pokracuje anglickym slovem pro "bohaty"

[tom]

Tak pouzivat glibc na aio mi prijde jako hloupost, protoze nevyuziva kernelovou implementaci aio, ale dela to pres thready.

[Luboš Doležel (Doli)]

Viz první odstavec blogového zápisku. Já to nepoužívám, protože chci, ale protože to potřebuju nějak podporovat na Linuxu.

[kotyz]

Třeba takovej Lennart s tim systemd a usrmerge...

[tom]

A neslo by pouzit libaio, ktera interne vyuziva implementaci v kernelu?

[Luboš Doležel (Doli)]

To je taky možnost, tam to wrapování bude o něco složitější.

[tom]

jestli si to dobre pamatuji, tak se s tim dodavala i hlavicka, ktera implementovala aio_* API pomoci io_* API, takze by mela stacit rekompilace.

[Jardík]

glib, to je ta knihovna, kde fce tmpfile() maže jiný soubor, než který vytvoří?

[Jardík]

glib/glibc

[Martin Mareš]

Ulrich už v glibc nevládne, takže by se mohlo blýskat na lepší časy. Uvidíme.

Jinak (1) je opravdu blbost glibc (nevidím jediný důvod, proč by se ten argument měl jmenovat s podtržítky), (2) smutný úděl těch, kdož si zapnou _GNU_SOURCE, což zanese namespace nekontrolovatelnou spoustou balastu, a konečně (3) typická Ulrichovina (ale ono POSIXové aio je ve většině implementací stejně dost nanic, tak na tom příliš nesejde).

[phr]

Důvodem může být prasácky naprogramovaná syntaktická analýza...

[Luboš Doležel (Doli)]

ale ono POSIXové aio je ve většině implementací stejně dost nanic, tak na tom příliš nesejde

I ta jaderná v (Free)BSD?

[pavlix]

Forkněte to glibc už někdo

Můžeš začít :).

Na OS X se používá rozšíření jazyka C nazvané Blocks, na Linuxu jej podporuje zejména Clang. Zapnutí podpory Blocks znamená, že přibudou určitá vyhrazená klíčová slova, mezi nimi je i __block.

V odkazovaném bugreportu je i návod, jak to obejít, který je jednodušší než fork knihovny.

Chcete pojmenovat svou proměnnou neškodným názvem major? Máte smůlu, glibc má takhle pojmenované makro a prostě se to měnit nebude. Musíte si to sami #undefnout nebo pojmenovat proměnnou jinak. Na major a minor tu máme právo jen my.

Jeden undef taky nikoho nezabije. Klidně by se to mohlo řešit v rámci výše uvedeného.

Očekáváte, že se API bude chovat v souladu s POSIXem?

Vzhledem ke stavu POSIXu to až tak 100% neočekávám :). U tohoto konkrétního příkladu jsi zapomněl napsat, v čem je problém.

Tak nevím, je to mnou?

Z velké části ano :).

[Luboš Doležel (Doli)]

V odkazovaném bugreportu je i návod, jak to obejít, který je jednodušší než fork knihovny.

Není lepší se konfliktům názvů vyhýbat, tím spíš jsou-li tak zbytečné.

Jeden undef taky nikoho nezabije. Klidně by se to mohlo řešit v rámci výše uvedeného.

Jenže to je prasárna. Že něco musím všelijak obcházet mi nepřijde u komponenty jako (g)libc normální.

Vzhledem ke stavu POSIXu to až tak 100% neočekávám. U tohoto konkrétního příkladu jsi zapomněl napsat, v čem je problém.

Stačí se podívat do mailu, na který Ulrich reagoval. Jedna věc je být nekompatibilní, druhá věc je být nekompatibilní a stát si za tím. Ostatně takových věcí má Ulrich na svědomí víc, jako předpoklady, že /bin/sh je Bash a další perly.

[pavlix]

Není lepší se konfliktům názvů vyhýbat, tím spíš jsou-li tak zbytečné.

Je. Nicméně pokud vidím blogpost na tohle téma, tak očekávám, že uvidím taky upřímnou aktuální snahu o nápravu.

Jenže to je prasárna. Že něco musím všelijak obcházet mi nepřijde u komponenty jako (g)libc normální.

Prasárna to je, jen mi přišlo, že to popisuješ fatálnější, než to je. Já teda mám osobně pocit, že v GLIBC narážím na závažnější nedostatky, než na které narážíš ty, ale to samozřejmě záleží na úhlu pohledu.

Stačí se podívat do mailu, na který Ulrich reagoval.

Jako jo. Ale jak už psal Martin, Ulrich nemá v současné době na GLIBC zas až tak zásadní vliv, takže bych se tím, co k tomu napsal, až tak moc nezabýval.

[Luboš Doležel (Doli)]

Je. Nicméně pokud vidím blogpost na tohle téma, tak očekávám, že uvidím taky upřímnou aktuální snahu o nápravu.

Právo commitovat do glibc nemám a správci změnu nechtěji, pod ten bug jsem psal. V eglibc to je opravené, tzn. patch na to existuje. Co mám asi tak dělat?

Ale jak už psal Martin, Ulrich nemá v současné době na GLIBC zas až tak zásadní vliv, takže bych se tím, co k tomu napsal, až tak moc nezabýval.

To bude mít očividně smysl, až glibc nebude pod kontrolou Red Hatu. Současní zaměstnanci RH se sami odkazují na komentáře Ulricha, takže je to evidentně "firemní linka" a ne jen jeden výjimečný sprosťák.

[pavlix]

Právo commitovat do glibc nemám

Sám jsi tady pana Jirsáka upozorňoval, že mít na něco technická práva ještě neznamená, že se mají používat v rozporu z pravidly, takže by ti to asi stejně nepomoholo.

V eglibc to je opravené, tzn. patch na to existuje. Co mám asi tak dělat?

Tvůj post vyznává tak trochu jako „hater“ článek a komentáře v diskuzích tomu vcelku odpovídají.

To bude mít očividně smysl, až glibc nebude pod kontrolou Red Hatu.

Takže to už asi nemá smysl, až dodělám články pro fedora.cz, abych se znovu pouštěl do něčeho pro Abclinuxu, když jsem teďka součástí té špatné firmy, která kazí celý ten open source :).

Současní zaměstnanci RH se sami odkazují na komentáře Ulricha

Věci se často nemění ze dne na den :).

takže je to evidentně "firemní linka" a ne jen jeden výjimečný sprosťák.

No je to velmi jednoduché. Buď chci, aby mi někdo pomohl, nebo chci všechny bez rozdílu poslat do háje. Mně se stává, že to se svojí snahou trochu přepísknu, ale fakt se snažím být konstruktivní.

Každopádně je dobře, že jsi na problémy upozornil i tady.

[Luboš Doležel (Doli)]

Uff, co to je za argumenty? Říkals, že s tím nic nedělám a já jsem vysvětlil, proč nemůžu. A ty pravdivé vysvětlení používáš jako odrazový můstek pro osobní útok?

Mně se stává, že to se svojí snahou trochu přepísknu, ale fakt se snažím být konstruktivní.

Zrovna tenhle tvůj komentář je úžasnou ukázkou konstruktivity.

[Lol Phirae]

Zrovna tenhle tvůj komentář je úžasnou ukázkou konstruktivity.

Asi má ještě pořád své dny

[pavlix]

I tobě se omlouvám za vše zlé, co jsem ti způsobil.

[pavlix]

A ty pravdivé vysvětlení používáš jako odrazový můstek pro osobní útok?

Asi jsem se spletl. Měl jsem za to, že jsem tu někde u tebe zahlédl osobní útok vůči všem mým novým kolegům a mně bez rozdílu. A z nějakého důvodu jsem měl pocit, že ti píšu přátelskou reakci. Tedy promiň.

[Michal Kubeček]

IMHO je to spíš věc (ne)kultury příslušného projektu než toho, z jaké firmy maintainer je. Lidé z Red Hatu maintainují spoustu projektů a naprostá většina takhle nevypadá.

[kralyk z abclinuxu]

+1

[Luboš Doležel (Doli)]

To rád slyším.

[kralyk z abclinuxu]

Jeden undef taky nikoho nezabije. Klidně by se to mohlo řešit v rámci výše uvedeného.

Zabije, a sice v situaci, kdy píšeš header pro knihovnu. Nějaký uživatel tvý knihovny může chtít i _GNU_SOURCE... Ten tě pak bude obviňovat, že mu undefuješ makra.

[pavlix]

Kolize je s platformou samotnou a tam bych klidně po undefu sáhnul, když to nejde jinak.

[CiV]

Zajimava alternativa za glibc je musl.

[kavol]

k tomu prvnímu, chápu správně, že borci v Applu si vymysleli nějakou píčovinu, a ty teď nadáváš, že v celým širým světě se přecejenom najde pár jedinců, co před tím narozdíl od ostatních nepadnou na prdel a nezmění svůj kód kvůli tomu, aby se Applu okamžitě přizpůsobili?

[Michal Kubeček]

Jestli jsem to dobře pochopil, problém je v tom, že ISO norma jazyka C specifikuje, že identifikátory začínající dvěma podtržítky jsou rezervované (sekce 7.1.3). V glibc je ale takový identifikátor použit jako jméno parametru, takže při pokusu přeložit něco kompilátorem, který ho použije jako klíčové slovo, proti hlavičkám glibc dojde k chybě. Vzhledem k tomu, že norma jazyka to jméno označuje za rezervované, je chyba na straně glibc.

[chrono]

Nemyslím si, že z tej sekcie 7.1.3 vyplýva, že taký identifikátor je vyhradený len pre kompilátor.

[Michal Kubeček]

Mně to připadá dost jednoznačné:

— All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.

…

No other identifiers are reserved. If the program declares or defines an identifier in a context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved identifier as a macro name, the behavior is undefined.

V sekci 7.1.4 nevidím nic, co by umožňovalo používat vyhrazená jména jako parametry funkcí.

A v annexu J.2 je pak explicitně:

The behavior is undefined in the following circumstances:

…

— The program declares or defines a reserved identifier, other than as allowed by 7.1.4 (7.1.3).

Viz též např. poznámku pod čarou v sekci 6.4.2.2:

Since the name __func__ is reserved for any use by the implementation (7.1.3), if any other identifier is explicitly declared using the name __func__, the behavior is undefined.

[tom]

Tak jednoznacne to neni, protoze nektera omezeni se vztahuji jen na globalne viditelne entity, takze jejich pouziti jako jmena parametru funkce je OK. Meli to pojmenovat spis _Block nebo __block__.

[Michal Kubeček]

…always reserved for any use.

[tom]

Jenze toto je omezeni pro uzivatelsky program a ne libc. V praci jsem zahledl dokument, ktery popisoval, jak delat prekladace, aby se nerozesralo linkovani modulu z ruznych prekladacu a tam to bylo rozvedeno hloubeji. Jestli si na to vzpomenu, tak sem hodim nazev.

[Michal Kubeček]

Jenze toto je omezeni pro uzivatelsky program a ne libc.

A kde konkrétně se to tam píše? Já tam nic takového neviděl.

[Ondrej 'SanTiago' Zajicek]

Ja bych to tam videl implicitne - ten standard rika, co nabizi implementace jazyka C. V GNU ci Linuxu je implementace jazyka C rozdelena do dvou casti - gcc a glibc. Z toho bych tedy soudil, ze kdyz se ve standardu pise, ze dany identifikator je vyhrazen pro implementaci, tak ho jak gcc tak glibc muze definovat jako sve rozsireni implementace jazyka C.

Koneckoncu, kdybych se drzel tve interpretace, ze glibc je vzhledem k bodu 7.1.3 programem, tak se dostanu brzy do sporu, nebod ta sekce za rezervovane oznacuje take vsechna jmena funkci z nasledujicich sekci, ktere definuji standardni C knihovni objekty. Takze by takova interpretace znamenala, ze glibc nesmi definovat errno, coz je nesmysl.

[tom]

To fakt jako myslite vazne? Vzdyt jste jste sam odkazoval na sekci 7.1.3 Library: Reserved identifiers.

[Martin Mareš]

Problém je, že norma popisuje jako implementaci systém překladač + standardní knihovna a glibc zde hraje roli té standardní knihovny, takže jí jsou dovoleny i věci, které běžné programy nesmí.

[Michal Kubeček]

Těžko říct… ona glibc je mnohem víc než jen standardní C knihovna - a tohle je zrovna v té části, která je "navíc".

[tom]

Myslim, ze rezervovane jsou jen ty zacinajici na __[A-Z] a _[a-zA-Z] a cokoliv mezi __ a __. Kdyz se v GCC zapne chovani podle std, tak vsechny rozsireni funguji jen ve tvaru __keyword__

[Luboš Doležel (Doli)]

Jednak to není píčovina, ale z hlediska jazyka C/ObjC užitečná věc, co je teď v nějaké podobě i v C++11. A jednak tu nejde o padnutí na prdel, ale o princip, že by se v glibc měli snažit o pokud možno nejvyšší kompatibilitu.

Kdyby se __block jmenovalo něco důležitého (třeba funkce), tak jejich postoj pochopím. Ale trvat na konfliktech i přesto, že by ničemu neublížilo to pojmenovat jinak (a nezainteresované by to neovlivnilo), to je debilita hodná velkých korporací, ale nikoliv open source projektu.

[tom]

Osobne povazuji prejmenovani toho __block v glibc na neco jineho jako vstricne reseni. Systematicky spravne mi ale prijde prejmenovani rozsireni na _Block.

Meli to proste udelat tak, jako se to delalo s ostatnima rozsirenima a zavest _Block. Kdyz se pak block dostane do std, vznikla by hlavicka stdblock.h, ktera udela #define block _Block. Stejnou cestou prosel bool a spousta dalsich veci. Vyhodou je zpetna kompatibilita, protoze stdblock si zadnej puvodni kod includovat nebude, takze nehrozi, ze by mu to rozbilo vlastni definice.

[Martin Mareš]

To jde ovšem udělat stejně dobře s __block jako s _Block. Obojí jsou identifikátory rezervované pro implementaci. Ale máte pravdu, že _Block by lépe odpovídalo tradici zavedené v C99 a C11.

[kavol]

Jednak to není píčovina, ale z hlediska jazyka C/ObjC užitečná věc, co je teď v nějaké podobě i v C++11.

otázka názoru, kterou tady nemá smysl rozebírat

A jednak tu nejde o padnutí na prdel, ale o princip, že by se v glibc měli snažit o pokud možno nejvyšší kompatibilitu.

hm, a proč se o tu "kompatibilitu" (uvozovky!) v glibc snažit musí a v Applu nemusí?

co je tohle za princip?

Kdyby se __block jmenovalo něco důležitého (třeba funkce), tak jejich postoj pochopím. Ale trvat na konfliktech i přesto, že by ničemu neublížilo to pojmenovat jinak (a nezainteresované by to neovlivnilo), to je debilita hodná velkých korporací, ale nikoliv open source projektu.

ano, jistě, je to debilita hodná velké korporace Applu - ještě jednou, proč to má přejměnovat glibc, proč to nepřejmenuje Apple?

[Luboš Doležel (Doli)]

Otázka názoru? Zrovna u closures bych nemyslel, že o tom bude někdo pochybovat.

Jinak Apple je to úplně jedno, protože "překvapivě" se na Darwinu glibc nepoužívá a obecně Blocks nejsou něco, co by mimo Applí systémy bylo rozšířené. Navíc chtít přejmenovat keyword kvůli tomu, že si tak někdo pojmenoval argument, by mohl chtít jenom blázen

A vůbec, když už tomu tak rozumíte, jak to teda ti debilové měli pojmenovat?

[tom]

A vůbec, když už tomu tak rozumíte, jak to teda ti debilové měli pojmenovat?

_Block, uz jsem to tu psal ;)

[Martin Mareš]

Jenže jste opomněl zmínit, v čem by to mělo být lepší, když to padá do téhož rezervovaného namespace.

[tom]

Neopomnel - napsal jsem, ze se to tak delalo i s dalsimi rozsirenimi prekladacu, takze je to defacto standardni postup.

[kavol]

Jinak Apple je to úplně jedno, protože "překvapivě" se na Darwinu glibc nepoužívá a obecně Blocks nejsou něco, co by mimo Applí systémy bylo rozšířené. Navíc chtít přejmenovat keyword kvůli tomu, že si tak někdo pojmenoval argument, by mohl chtít jenom blázen

hm, a nedá se náhodou přesně ta samá argumentace použít i na opačnou stranu?

když se na Darwinu glibc nepoužívá, proč by glibc nemělo být úplně jedno, jak se u Applu co jmenuje?

chtít přejmenovat argument v libc kvůli tomu, že si tak někdo pojmenoval keyword, by mohl jen blázen, ne?

[stativ]

ano, jistě, je to debilita hodná velké korporace Applu - ještě jednou, proč to má přejměnovat glibc, proč to nepřejmenuje Apple?

Protože pojmenovávat argument vyhrazeným jménem je naprostá kravina? Kdyby to byla funkce, makro, nebo nějaký typedef, tak bych to bral. Ale argument!?

To, že to asi nebude úplně košer dokazuje i to, že i pro gcc se musí hlavičkové soubory zpracovat pomocí fixincludes.

[Martin Mareš]

Protože pojmenovávat argument vyhrazeným jménem je naprostá kravina?

Kravina možná, naprostá ne :)

Je to snaha autorů libc nekolidovat s čímkoliv, co kdo nadefinuje mimo libc. Kdyby argument pojmenovali "block", header file by se rozbil, kdyby si program, který ho includuje, nadefinoval své vlastní makro "block", což podle normy smí udělat.

Jiná věc samozřejmě je, že kdo definuje takhle genericky pojmenovaná makra, neměl by se divit, že tím něco rozbije. A jako že rozbije: stačí includovat headery od libovolné jiné knihovny.

Osobně si myslím, že snažit se v headerech zabraňovat kolizím tímto způsobem je boj s větrnými mlýny, který nelze vyhrát, a že je tedy lepší headery psát přímočaře a spoléhat na programátora, že blbosti s makry vyvádět nebude. Ale chápu, že zrovna v tomto případě mohou mít správci glibc jiný názor.

[stativ]

Je to snaha autorů libc nekolidovat s čímkoliv, co kdo nadefinuje mimo libc. Kdyby argument pojmenovali "block", header file by se rozbil, kdyby si program, který ho includuje, nadefinoval své vlastní makro "block", což podle normy smí udělat.

OK, tohle beru. Pak by asi nebylo od věci použít jméno __glibc_block, protože tam by kolize hrozit už opravdu neměla.

[stativ]

Koukám, že v Lubošem odkazovaném bugreportu je zmínka i eglibc, kde to přesně takto vyřešili.

[kralyk z abclinuxu]

Osobně si myslím, že snažit se v headerech zabraňovat kolizím tímto způsobem je boj s větrnými mlýny, který nelze vyhrát, a že je tedy lepší headery psát přímočaře a spoléhat na programátora, že blbosti s makry vyvádět nebude.

+1, případně by imho bylo nejlepší ten argument v headeru vůbec nepojmenovávat, stejně pokud někdo chce vědět, k čemu ten argument je, koukne se do dokumentace.

[Jardík]

řešením je vyhodit makra úplně. C podporuje inline fce, nevidím důvod je nepoužít. Má to pak i výhodu při použití v C++, že mi to nebude prasit všechny namespaces a názvy fcí ve třídě a tak. Makro = prasárna. Např. výše zmiňované makro minor/major by mohlo být úplně klidně inline fce, jenže bohužel se někdo rozhodl pro makro, protože stará norma jazyka, a ani po jánevímasitřinácti letech se to nemohlo změnit.

[kralyk z abclinuxu]

Inline fce v C máš, ale konstanty afaik nemáš (a i kdybys je měl, ne vždy to je vhodné)...

[zxtlpn]

Kde ty lidi berou že v C nejsou konstanty?

[Martin Mareš]

A jak že se tam zapisují?

[tom]

Mezi #define jedna 1 a const int jedna = 1; je zasadni rozdil v tom, ze tomu prvnimu se nevyhrazuje misto v pameti a protoze const je defaultne extern je pozdeji obtizne se ho zbavit i kdyz dana konstanta neni vubec pouzita.

To slovo const je totiz celkem matouci, mnohem lepsi by bylo pojmenovat to readonly.

[Martin Mareš]

Makra inline funkcemi úplně nahradit nejde (a šablonami také ne), mimo jiné proto, že jsou netypovaná. Ale jinak souhlasím, že kdekoliv jde použít inline funkce, je lepší tak učinit.

Pěkný příklad konstrukce, která se bez maker dělá obtížně, je třeba:

#define KEYWORDS K(if) K(then) K(else) K(begin) K(end)

#define K(x) KEYWORD_##x,
enum keywords { KEYWORDS };
#undef K

#define K(x) [KEYWORD_##x] = #x,
const char * const keyword_names[] = { KEYWORDS };
#undef K

[Václav HFechs Švirga]

A umí ty inline funkce gcc vůbec? Udělal jsem si malý test a nadefinoval funkci jako normální, vyjel si z gcc asm, pak jsem nadefinoval funkci jako inline, rovněž jsem si vyjel asm a žádná změna - funkce se volala přes call, žádné inline se nekonalo. Samozřemě při nějakém -O2 už to gcc zoptimalizoval úplně jinak (call bylo pryč), ale rovněž na to keyword inline neměl vliv. Takže pokud gcc keyword inline úplně neignoruje, tak ho bere pouze jako doporučení (asi jako register) a při překladu bez optimalizací gcc na inline sere úplně. Naopak makro je jistota. To je aspoň mé pozorování, rád se nechám přesvědčit o opaku.

[Lol Phirae]

6.39 An Inline Function is As Fast As a Macro.

[Václav HFechs Švirga]

GCC does not inline any functions when not optimizing unless you specify the `always_inline' attribute for the function, like this...

Hm, to vysvětluje, proč se to inline bez optimalizace nekonalo. Přijde mi to trošku nelogické, gcc optimalizace chápu jako něco, o co se překladač snaží sám, naopak keyword inline jako něco, co si přeje programátor a proto není důvod, aby se to s vyplou optimalizací neprovedlo, ale budiž.

Situace, kdyby programátor nechtěl gcc optimalizace, ale chtěl inline funkce a proto je inline keyword na nic a musí je přepsat do maker asi normálně nenastává.

[Martin Mareš]

GCC bez optimalizace nespouští hromadu průchodů pro analýzu kódu, jejichž výsledky jsou potřeba i pro inlinování. Překlad bez optimalizací se snaží především být rychlý a generovat co nejdebugovatelnější kód. A ani jednomu inlinování nepomůže.

Hlavně pokud vám na rychlosti kódu nesejde (kdyby sešlo, optimalizujete), není inlinování funkcí k ničemu dobré.

[Václav HFechs Švirga]

Dobrá, to zní jako rozumný argument. Aspoň jsem chytřejší .

[deda.jabko]

Překlad bez optimalizací se snaží především být rychlý a generovat co nejdebugovatelnější kód.

Ted me s tim GCC docela nastvalo. Bez optimalizaci neprovadi ani prevod tail-callu na smycky, takze jsem si mohl vybrat, budto mit blbe debugovatelny kod, nebo kod, ktery pada kvuli malemu zasobniku.

[kralyk z abclinuxu]

Afaik má gcc různý podrobný command-line switches, kterejma se daj zapnout/vypnout jednotlivý optimalizace, ale jestli tam je konkrétně takhle, to opravdu nevim... man gcc

[tom]

keyword inline jako něco, co si přeje programátor

... a co pro prekladac neni zavazne. Stejne jako treba keyword register.