LLVM a clang 3.4

2. ledna 2014 byla vydána nová verze 3.4 překladačové infrastruktury LLVM a překladače jazyků rodiny C clang. Mezi hlavní novinky patří plná podpora clangu pro nadcházející C++14, výrazné vylepšení statického analyzátoru kódu při analýze C++ kódu, nový nástroj clang-format pro formátování zdrojových kódů dle uživatelem specifikovaných standardů (využívající knihoven clangu), clang driver s command-line syntaxí kompatibilní s MSVC, lepší diagnostika, lepší optimalizace a další. Více informací je v Release Notes pro clang a LLVM.

9.1.2014 00:24 | Boris Dušek | Nová verze

Komentáře

[vencas]

A OpenMP zase nic, a to už několik let porůznu čtu, že na tom pracují.

[JoHnY3]

Docela jim to trva, ale podle http://clang-omp.github.io/#status uz by to snad mohli stihnout do LLVM 3.5

[Luboš Doležel (Doli)]

No, u C++11 jsem si říkal, že ten jazyk není až tak moc složitej, když si někdo stěžoval. Právě nám ale vyrostla konkurence Perlu. Tohle je docela síla.

[Sid]

algoritmus vyvoja C++ for (Language l : allLanguages()) { for (Feature f : l.allFeatures) { if (cpp.contains(f) == false) { cpp.addFeature(cppObfuscator(f)); } } }

niezeby ma niektore veci nepotesili ale zacinam mat pocit, ze po case bude na svete tak 10 ludi co budu plne rozumiet vsetkym drobnym detailom. vid napr. auto lambda = [](auto x, auto y) {return x + y;}; Though it uses the C++11 keyword auto, generic lambdas do not follow the syntax of auto type deduction. je naozaj super idea ked v urcitom kontexte to znamena vzdy troska nieco ine.

[unsigned long long]

Uprime receno netusim, co ma ta poznamka na wiki znamenat a pouziti auto v tomhle pripade mi pripada intuitivni. V cem by mel byt hacek?

[Jardík]

template<typename T> [](T bla, T bla2) -> decltype(T+T) {} by bylo hezčí

[Jardík]

Hlavně teda proto, že oba typy třeba mají být stejné a né různé. Ta lambda s auto, to prakticky můžou být 2 různé typy pro x a y (?).

[unsigned long long]

Pokud chcete nejakym zpusobem omezit typy argumentu nad ramec toho, co telo te funkce pobere, tak tuhle lambda syntaxi asi nepouzijete. IMHO je to zamyslene pro pripady, kdy s typama saskovat nechcete, v podstate takove makro.

[Sid]

mne to tiez navadi, akurat som narazal na to, ze nie je moc dobre ked to iste slovo znamena v roznych kontextoch troska inu vec. nieco na sposob ze v jednom kontexte by long bol mysleny ako napr unsigned long a v inom ako signed long.

[kralyk z abclinuxu]

Už od začátku je v C++ slůvko static, taky v každém kontextu něco úplně jinýho, a přesto si nikdo nestěžuje

[Peter Fodrek]

Lenze v C sa da studentom vysvetlit jeden kontext celkom dobre na dvoch prikladoch resp. jednom (bud sa static pouzije, alebo nie). Aj ked je to neefektivne az zvrhle vyuzivat funkcionalne konstrukcie na toto. Aj ked je desive, ze ked toto skompilujem bez static clangom v XCODE, tak to hodi SEGFAULT ale pri gcc kod nespdne, ale vypise ciastocne dobre hodnoty a ciastocne blbosti. Realne by som cakal pad vzdy.

//.... include stdio.h a time.h

time_t * myTime(void)
{
    //static \
    time_t cas;
    cas=time(NULL);
    return (&cas);
}

int main(void)
{
    printf("prave je: %d:%d:%d\t\t%d.%d.%d \n", localtime(myTime())->tm_hour, \
localtime(myTime())->tm_min, localtime(myTime())->tm_sec,\
    localtime(myTime())->tm_mday, 1+(localtime(myTime())->tm_mon), \
1900+(localtime(myTime())->tm_year));
}

[little.owl]

Realne by som cakal pad vzdy.

To zalezi na tom, jestli jste u nejaky pouzil stack protector nebo address sanitiser, obecne nejaka ocharna stacku krome buffer overflow se nedela.

[kralyk z abclinuxu]

To je celkem běžné. Už hodněkrát jsem narazil na to, že třeba dangling pointer nebo reference nezpůsobily pád nebo dokonce fungovaly správně. No a pak se změní konstelace hvězd a spadne to...

Jinak v C++ máme ty kontexty hned tři: static proměnná ve funkci, static non-member funkce, static member funkce/proměnná.

[little.owl]

static non-member funkce,

To je ale uplne neco jineho nez ostatni dva priklady, v C je to jasne, C++03 je to bylo deprecated a v C++11 to soudruzi planovaci opet un-deprecated.

[vencas]

Já doufám, že přibude ještě "static if". To by pro ten bordel v šablonách byla docela užitečná věc.

[Sten]

template <bool condition,
          typename if_true,
          typename if_false>
struct static_if;

template <typename if_true,
          typename if_false>
struct static_if<true, if_true, if_false>
{
    using result = if_true;
};

template <typename if_true,
          typename if_false>
struct static_if<false if_true, if_false>
{
    using result = if_false;
};

[vencas]

To já vím, že se to dá nějak upatlat, ostatně na to máme std::enable_if, když už, ale čitelné je to omezeně.

[kralyk z abclinuxu]

Já doufám, že přibude ještě "static if". To by pro ten bordel v šablonách byla docela užitečná věc.

V C++14 mohou constexpr funkce obsahovat if.

[vencas]

To je něco jiného, "static if" umožňuje selektivně kompilovat/nekompilovat část šablony podle vlastností šablony.

[xnov22]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3613.pdf

[little.owl]

Prinosny link, diky, schvalene veci z WG21 ctu, ty zamitnute moc ne.

[Sten]

Ono by to naopak nemělo padat. Bez static se to alokuje na zásobníku, takže ten ukazatel pořád ukazuje na platnou paměť. Akorát to bude velmi rychle obsahovat nesmysly.

[little.owl]

To 'ukazuje na platnou paměť' by bral s velkym nadhledem, ukazatel vrcholu zasobniku je uz jinde. To jestli je ci ma byt pouzita nejaka ochrana je zalezitost ciste implementacni, takze i seg fault je na miste, mozna mensi zlo nez nesmyslna data.

[Sten]

Sice existují věci jako Address Sanitizer, ale jsou dost pomalé, protože musí kontrolovat každý ukazatel. Stack protectory se běžně používají jako ochrana proti přepsání, ne čtení.

[little.owl]

Ano, kontrola pameti je pekelne draha, pokud to nekdo potrebuje, at si vybere jiny jazyk nez C/C++.

[Luboš Luňák]

Už od začátku je v C++ slůvko static, taky v každém kontextu něco úplně jinýho, a přesto si nikdo nestěžuje

Jak, pokaždé něco jiného? Kdy to znamená něco jiného než "globální proměnná/funkce s omezenou viditelností" ?

[Sten]

static void funkce() // Jeden význam
{
	static int hodnota = 1; // Druhý význam
}

class Class
{
	static void funkce() // Třetí význam
	{}
};

[Miloslav Ponkrác]

Stále je to jeden a ten samý význam. Znamená to samé. Statickou funkci/proměnnou. 1) statickou funkci modulu. 2) statickou proměnnou funkce, 3) statickou funkci (aka metodu) třídy.

Termín „statická metoda/funkce“ znamená, že jeho namespace (prostor jmen) patří k nadřazené strukteře, ve které je daná statická metoda/funkce definována.

Pokud C++ umí se do takové „namespace“ podívat, pak se do ní dá dostat operátorem čtyřtečka (::), což jde typicky u tříd.

Protože C++ (zatím v současných normách) se neumí podívat do jiných modulů nebo dovnitř jiných funkcí (což může, ale teoreticky nemusí být tomu tak navždy), budí to vnější zdání, že static umožňuje skrýt funkci/proměnnou uvnitř modulu či funkce.

Ale až bude existovat v C++ (nejspíše nebude, ale v budoucnu klidně může) modul::proměnná, pak statická proměnná modulu bude přístupná i z jiných modulů. A teoreticky až bude v C++ existovat (nejspíše nebude) operátor funkce::proměnná, tak se můžete dostat i dovnitř statické proměnné funkce.

Vše je tedy stále stejné, static má jeden význam a jednu logiku v C++.

Ne nadarmo se pro ukrývání tříd/proměnných a dalších identifikátorů definovaných v modulů striktně doporučuje anonymní namespace, nikoli static.

Protože static neznamená a nikdy neznamenal, že nějaký identifikátor je ukryt v modulu – příští norma C++ vás třeba může nemile překvapit. Znovu: klíčové slovo static v C++ (na tozdíl od C) nebyl, není a nikdy nebude určeno pro ukrývání identifikátorů. A touto logikou půjdou i příští normy C++.

Jazyk C++ je logický, a proto jednoduše pochopitelný. Není naprosto žádný problém pochopit celé C++ v tom co umí, protože je logické a má vnitřní konzistenci na rozdíl od většiny jiných jazyků.

Miloslav Ponkrác

[:::]

Protože static neznamená a nikdy neznamenal, že nějaký identifikátor je ukryt v modulu – příští norma C++ vás třeba může nemile překvapit. Znovu: klíčové slovo static v C++ (na tozdíl od C) nebyl, není a nikdy nebude určeno pro ukrývání identifikátorů. A touto logikou půjdou i příští normy C++.

Tvurci C++ standardu by s tebou asi nesouhlasili. Termin "internal linkage" je celkem vystizny.

N3797.pdf:

A name is said to have linkage when it might denote the same object, reference, function, type, template, namespace or value as a name introduced by a declaration in another scope:
— When a name has external linkage, the entity it denotes can be referred to by names from scopes of other translation units or from other scopes of the same translation unit.
— When a name has internal linkage, the entity it denotes can be referred to by names from other scopes in the same translation unit.
— When a name has no linkage, the entity it denotes cannot be referred to by names from other scopes.

A name having namespace scope (3.3.6) has internal linkage if it is the name of
— a variable, function or function template that is explicitly declared static; or,

----------

Není naprosto žádný problém pochopit celé C++

S tim se da souhlasit

[Miloslav Ponkrác]

Přiznám se, že vytržený kus z kontextu příliš nechápu.

Nicméně já nepsal o normě, ale o vnitřní logice. A možnosti změn v příštích normách, které sleduje tuto logiku.

Klidně můžete něco citovat z normy C++ třeba z roku 2050, bude to zajímavější.

[Sten]

Ten vytržený kus říká, že když je to static prvního případu (having namespace scope), tak to má internal linkage, což znamená, že se na to dá jménem odkazovat jen z té translation unit (*.cpp plus všechny includy), kde to bylo definované.

[little.owl]

Stále je to jeden a ten samý význam.

Nema. Jena vec je storage class specifier a druha linkage specifier; v obou pripadech jde o rozdilne veci.

Není naprosto žádný problém pochopit celé C++ v tom co umí, protože je logické a má vnitřní konzistenci na rozdíl od většiny jiných jazyků.

Co si mam tvrdsiho zobnout nez otevru C++ standard, abych mel stejne optimisticky pocit?

[Miloslav Ponkrác]

„Co si mam tvrdsiho zobnout nez otevru C++ standard, abych mel stejne optimisticky pocit?“

C++ je vnitřně logický jazyk. Stačí pochopit logiku, na které je vystaven. Tím je jednoduše naučitelný, ale pouze způsobem pochopení vnitřní logiky. Ne paměti a nadrcení se ho.

Je to asi jako rozdíl mezi češtinou, angličtinou.

Angličtina je považována za lehký jazyk. Ve skutečnosti je to pekelně těžký jazyk, protože v něm jen minimálně existují nějaká pravidla. Ve skutečnosti je angličtina jen horou frází a idiomů a pro naučení se perfektní angličtiny potřebujete jen paměť, memorovat a neustále v tom žít. Logika, cit a další je téměř neupotřebitelné.

Čeština je přesný opak. Stejně jako řada jiných jazyků. Mají svá pravidla a logiku, a bez nich se česky nenaučíte.

Kdysi jsem šokoval lidi, že mi maďarština připadá jednodušší, než angličtina (a to jí zcela neovládám). Jenže zase – ta maďarština má logiku, pravidla. Trochu odlišná, ale má.

Když se zpět vrátím do programovacích jazyků, existuje mnoho nekonzistentních jazyků, kde nejde předpokládat nic a logika neplatí. Jako je třeba PHP. Daleko víc je nekonzistentních knihoven.

Na C++ se musí pochopením jejich logiky, pak se z C++ stane jasný a snadno naučitelný jazyk. Memorování nemá smysl.

Miloslav Ponkrác

[Miloslav Ponkrác]

V případě proměnných znamená slovo static – ať je to umístěno kdekoli, uvnitř modulu, funkce, třídy, kdekoli jinde – znamená, že jde vnitřně de facto o globální proměnnou (tedy neztrácející hodnotu) umístěnou na pevné adrese.

Static vždy – ať už v případě funkcí či proměnných – znamená, že identifikátor je svázán (proto jsem použil výraz namespace v uvozokách) s místem, kde je definován.

Navíc tu opravdu nikdo neovládá C++, jen suše něco cituje.

Našli se tu jen 3 významu slova static.

Já vám klidně přidám další.

Například static int a = 3 ponouká kompilátor k definici konstanty (zhruba rovnající se #define a 3), pokud nepřistoupíte v modulu k její adrese. Což se v tém normě také dočtete.

A to jsme stále nevyčerpali možnosti použití static.

Jenže celé je to stále o stejné logice, kterou jsem popsal:

– Static proměnné jsou vnitřní implementací globální proměnné, jejichž přístupnost je v jazyce C++ navenek uměle omezena.

– Static znamená svázání identifikátoru, ve kterém je static definováno. Když je static definováno ve třídě, jde o svázání s třídou (identifikátor je globální proměnná/funkce s „namespacem“ třídy). Když je static definováno uvnitř funkce, je přístupné jen z funkce. Když je mimo třídy a funkce, pak je svázáno s modulem.

Tyto dvě věty jsou vnitřní logikou veškerého významu static v C++. 1. bod říká, jako je vnitřně (z hlediska linkeru a výsledného programu), 2. bod říká, jak to bere syntaxe jazyka.

Tečka.

Miloslav Ponkrác

[little.owl]

Stale michate dve veci - jedna vec je storage class, ktery upravuje lifetime objektu, druha vec je linkage, ktera upravuje visibility, a to ma celou radu praktickych dopadu, ty co rikate jsou nektere z nich.

Standard C/C++ je trochu pravnicina, dokument musi byt konzistentni a jasny, jazyk zpetne kompatibilni a nesmi byt prilis velky prostor pro alternativni interpretace.

IMHO, vas pristup k pojeti jazyka se mi zda byti chaoticky.

[Sten]

static int a = 3 rozhodně není konstanta a kompilátor ji tak nemůže použít. Muselo by to být static const int a = 3. Jenže kompilátor to jako konstantu může použít, i pokud tam ten static vůbec není, ten se v tomto případě používá jen pro členské proměnné nebo pro specifikaci internal linkage.

[little.owl]

V ramci optimalizace by to asi mozne bylo, pokud se prokaze, ze pamet, kde se promenna nachazi, neni modifikovana; nicmene to jde brutalne nad ramec C++ standardu a ze static to nelze dovodit.

[Luboš Luňák]

static void funkce() // Globální funkce s viditelností omezenou na jednu kompilační jednotku (soubor)
{
	static int hodnota = 1; // Globální proměnná s viditelností omezenou na funkci
}

class Class
{
	static void funkce() // Globální funkce s viditelností omezenou na třídu (mimo je potřeba explicitní kvalifikace)
	{}
};

[kralyk z abclinuxu]

U static member funkcí nemá static s viditelností nic společného, akorát se tím určuje, že to je v podstatě globální funkce, která leží v namespace té třídy. Viditelnost určuje public/private/protected.

[Luboš Luňák]

Viditelnost určuje static. To, co určují public/protected/private je přístup, viditelnost je pořád stejná.

[little.owl]

Predbehl jste me. Ano, pristupova prava, nemaji s visibilitou, jak s ni pracuje C++, nic spolecneho; je to posledni vec, ktere se posuzuje/aplikuje behem kompilace.

[kralyk z abclinuxu]

O jakou viditelnost tedy jde? Statická metoda třídy se v tomhle chová jinak než statická proměnná funkce, protože je 'viditelná' i z venku třídy (bez ohledu na přístup), zatímco statická proměnná funkce ne.

A viditelnost statických metod je zase jiná věc - to je viditelnost z hlediska linkeru (který statické metody nevidí).

[Luboš Luňák]

Já nevím, jak přesně viditelnost definuje standard jazyka, ale intuitivně se dá např. říct, že objekt je viditelný, pokud se na něj dá odkázat jménem. Např. na statickou proměnnou 'a' ve funkci 'f' se dá odkázat jako 'a' jen ve 'f' a odjinud není vůbec vidět. Podobně je to se statickou proměnnou 'b' ve třídě 'C', jako 'b' se na ni dá odkázat jen z 'C'. V tomhle případě akorát jde explicitní kvalifikací 'C::b' odkázat i zvenku. Pokud by se podobným způsobem šlo odkazovat dovnitř funkcí, fungovalo by i 'f::a', akorát to nikdo neuznal za užitečné (i když překladače se takhle myslím někdy odkazují v chybových hláškách). A do třetice na statickou proměnnou 'd' na úrovni souboru (kompilační jednotky) se jde odkázat jen z toho souboru. Ve všech třech případech jde o "normální" globální proměnnou.

Přístup funguje úplně bez ohledu na viditelnost. Objekt může být viditelný ale nepřístupný (odkázání na private z odvozené třídy), naopak např. "globální" statická proměnná by byla přístupná, ale není viditelná, takže v prvním případě bude chyba o nedostatečném přístupu, v druhém se objekt vůbec nenajde.

Viditelnost z hlediska linkeru je ještě další samostatná věc a z hlediska teorie jazyka C++ by to asi šlo brát jako implementační detail a překladače se v tom klidně mohou lišit.

Samozřejmě by se v tom člověk mohl rýpat a hledat drobné rozdíly (které jsou a jsou u spousty věcí nejen v C++), ale static prostě znamená 'globální proměnná/funkce s omezenou viditelností' a když to tak člověk pochopí (místo těch chaotických vysvětlení o tom, jak je to pokaždé úplně jinak), dost to tak dává smysl. Trochu jako třeba časy v angličtině :) (které jsou ve skutečnosti velmi konzistentní a logické, jen co je člověk dostane správně vysvětlené).

[little.owl]

Pojem "visibilita" identifikatoru specifikuje cast programu ve kterem muze byt referencovan (scope); z hlavy - C definuje file scope, function scope, block scope, function prototype scope a C++ prinasi class scope.

které jsou ve skutečnosti velmi konzistentní a logické, jen co je člověk dostane správně vysvětlené

Muhehe.

[kralyk z abclinuxu]

Podobně je to se statickou proměnnou 'b' ve třídě 'C', jako 'b' se na ni dá odkázat jen z 'C'. V tomhle případě akorát jde explicitní kvalifikací 'C::b' odkázat i zvenku.

To, že ta funkce/proměnná je ve tříde C viditelná jako b je dáno pouze tím, že v rámci scope/namespace člověk nemusí uvádět plné jméno. Jinak ale 'skutečné' jméno té funkce/proměnné je třeba ::foo::bar::C::b, kde foo a bar jsou třeba namespaces (mohly by to být ale i třídy). To, že z různých míst se můžu na tu funkci odkazovat například jménem b nebo C::b nebo bar::C::b je dáno pravidly, jakými se lokalizuje identifikátor, s viditelností to nemá vůbec nic společného.

[Luboš Doležel (Doli)]

Ano, já ten jazyk mám opravdu rád a těší mě, že neusnuli na vavřínech a dále ho rozšiřují (for(each) a lambdy jsou spása). Ale už ztrácím schopnost s jistotou říct, jestli nějaký kód projde kompilátorem.

[----]

FTFY: if (!cpp.contains(f) && is_easy_to_add(f)) { ... }

[potato]

C++ se vyvíjí stejným směrem už dlouho. A to i nebereme-li v úvahu tendenci psát standard, jako když pejsek a kočička vařili dort, tedy zamícháním všeho, co někomu přijde dobré.

Jde hlavně o trend cílené dotahovat jeden směr OOP do jednoho extrému: na každý problém se de facto vytvoří domain-specific jazyk, s použitím tříd, šablon, zvráceního přetížení operátorů, a když dojde na věc, i preprocesoru, prostě všeho, co je k disposici. Výsledkem je pak framework, který pěkně modeluje daný problém. Cena je ovšem vysoká: neprogramuje se v C++, ale v jednotlivých frameworcích; kdo daný framework dobře nezná, pro toho je velmi obtížné zjistit, co kód dělá, a především co doopravdy dělá, když se vystkytne nějaký problém.

[unsigned long long]

Vite, proc vznikaji frameworky a domain-specific jazyky? Prave proto, ze umoznuji problem vyjadrit tak, jak nad nim clovek premysli a jak ho modeluje. Kod neni zaplevelen tunami opakujicich se implementacnich detailu, ktere ho zneprehlednuji, jsou plne bugu a cini ho neudrzovatelnym.

[:::]

No, u C++11 jsem si říkal, že ten jazyk není až tak moc složitej, když si někdo stěžoval. Právě nám ale vyrostla konkurence Perlu. Tohle je docela síla.

Co je na tom spatnyho?

A co je spatnyho na Perlu??