.
Portál AbcLinuxu, 30. dubna 2025 12:39
Tak jsem zkoukl Stroustrupovu přednášku o budoucnosti C++ inzerovanou ve zprávičce. V prvé řadě to byla ukázka, jak nemožně může být americký vědec oblečený, to už je mnohem lepší Stallman se starým diskem na hlavě.
Přednáška celkem dobrá, bohužel zvuk převážně na levém kanálu. Nové fíčury v C++ přinášejí takové "novinky" jako například možnost inicializovat kontejner literálem. Bohužel kvůli tomu přidali asi padesátou možnost, jak něco inicializovat. Zkrátka vždycky když Bjarne hovořil o něčem, co úžasně zpřehlední kód, problesklo mi hlavou, jak elegantně je to vyřešeno v Pythonu/Ruby.
C++ umí generovat výborný nativní kód z dost vysokoúrovňového popisu (šablony...), to je jeho killer feature. Nicméně má to dost daleko k tomu, aby programátor psal, co chce opravdu udělat, místo toho musí psát kód, jehož sideefect je to, co chce opravdu udělat. Přidáváním nových vlastností s nutným zachováním zpětné kompatibility ale situaci příliš neprospívá.
Demokratický postup tvorby standardu mě taky neohromil, nesnáším Design by Commettee, ale jinak se to udělat asi nedá.
C++ je obrovský, nepřehledný jazyk plný temných koutů a chyb v kompilátorech. A bude větší a míň přehledný. Ale na velkou množinu problémů je to to nejlepší, co máme.
Tiskni
Sdílej:
16.8.2007 09:22
msk | skóre: 27
| blog: msk
16.8.2007 09:40
kyknos | skóre: 18
| blog: Quid novi?
| Ranša Rosa
(Ranša Rosa? To je v Mexiku? 
)
riadenie toku kodu indentom ( co za blba toto vymyslelo! )
Za takové věci by měly být přísné tresty. To mi připomíná, že bych si měl konečně zjistit, kdo má na svědomí syntaxi makefilu… :-)
Jak kdy. Vím, že puristé by mne vytahali za uši, ale věci jako
if (R < 0) { perror("blabla"); exit(1); }
(to je jen příklad) mi připadá přehlednější napsat do jednoho řádku.
Jsem ochoten se skřípěním zubů akceptovat, když jazyk přikládá zvláštní význam značce konce řádku (Bourne shell, assemblery), ale jazyk, který nepřežije záměnu neprázdné posloupnosti mezer a tabulátorů jinou neprázdnou posloupností mezer a tabulátorů, považuji za zvrácený.
To je argument proti Pythonu?Jak kdy. Vím, že puristé by mne vytahali za uši, ale věci jako
if (R < 0) { perror("blabla"); exit(1); }(to je jen příklad) mi připadá přehlednější napsat do jednoho řádku.
if True : print("koncim"); sys.exit()
V něm jde napsat taky.
ale jazyk, který nepřežije záměnu neprázdné posloupnosti mezer a tabulátorů jinou neprázdnou posloupností mezer a tabulátorů, považuji za zvrácený.Popravdě, mě osobně se tato vlastnost Pythonu taky moc nelíbí (zlatý Haskell, tam si člověk aspoň vybere). Bílé znaky do syntaxe nepatří ... (ano, já mám
:set list, ale co ostatní?)
17.8.2007 10:13
kyknos | skóre: 18
| blog: Quid novi?
| Ranša Rosa
16.8.2007 11:09
Rezza | skóre: 25
| blog: rezza
| Brno
16.8.2007 11:26
andree | skóre: 39
| blog: andreeeeelog
16.8.2007 12:29
Rezza | skóre: 25
| blog: rezza
| Brno
16.8.2007 12:08
elviin | skóre: 29
| blog: elviin
| Plzeň-Praha
Ano ano, proc si na handle napsat nejakou tridu, ve ktere jednou pro vzdy naimplementuju zpusob uvolnovani a dal se o nic nestarat? Proc na zobecneni takove tridy pouzit sablony, pripadne makra?
Mnohem lepsi je se stale dokolecka kopirovat jeden a ten samy kus kodu s finally, znovu a znovu psat kontroly zdali uz byl handle v try {} inicializovan a muzu ho uvolnit, neustale premyslet nad tim, kde mi muze vybublat vyjimka a kde bude treba pridat finally s uvolnenim...
16.8.2007 15:30
alblaho | skóre: 17
| blog: alblog
Opravdu je napsání deklarace třídy, definice třídy, napsání kódu konstruktoru a destruktoru kratší, než jednoduché použití finally?Jestli je pro vas neprekonatelny problem abstrahovat opakujici se kod a udelat to tak, abyste pro vygenerovani tridy zadaval jen typ handlu, funkci pro uvolneni a nazev, tak vam neni pomoci. Pokud handle pouzijete v celem programu pouze jednou, tak to vyjde (± pismeno) nastejno. Jakekoliv dalsi pouziti je cista ztrata pro finally.
Dokonce strojový kód v případě finally je kratší a rychlejší, protože kompilátor si ušetří budování seznamu lokální objektů k destrukci! Ale ve strojovém kódu je automatické volání destruktorů a finally naprosto to samé! Je to totéž! Jak tedy jedno může být bezpečnější, než druhé?Jestli se vam program vlece kvuli "stack unwind" a hodlate to resit pomoci finally, tak vam neni pomoci. Rozdil je prave v tom, ze seznamy objektu k destrukci za vas vytvari kompilator, v pripade finally toto musite dalat sam. Ze se ma volat nejaka funkce na uklizeni je receno uz pri definici promenne, nemuze se vam stat, ze byste na uvolneni zapomnel, vubec to neresite - proto je to bezpecnejsi.
A az zas budete do c++ tlacit finally kvuli handlum, tak se hlavne v kontrastu k tomu nezapomente zminit, ze se vybor do standardu chysta prosadit spoustu naprosto zbytecnych veci...
handle_type some_handle = ::CreateHandleFromOsAPI(bla bla);
try
{
...
}
finally
{
if (some_handle != null_handle)
::CloseHandleOsApi();
}
Pokud je to jednorázové, rozhodně to není to samé co napsat definici třídy (pro jistotu připomínám, že handlů není jeden druh, aby to šlo odepsat jednou třídou).
Kde jsem napsal, že se mi program vleče kvůli "stack unwind"?
Poslední odstaven no comment. Zřejmě Vám Vaše žena nedala a Vy holt si nemáte kde vybít zlost.
handle_type some_handle = ::CreateHandleFromOsAPI(bla bla); try { ... } finally { if (some_handle != null_handle) ::CloseHandleOsApi(); }pro jistotu připomínám, že handlů není jeden druh, aby to šlo odepsat jednou třídouRika vam neco termin "template specialization" ?
Důležité je všimnout si toho "special operator" V Lispu není special operator nic, co jím být nemusí. Je jich tam jen pětadvacet, a nad nimi je vystavěno všechno. Jinými slovy, to, co Vy tady považujete za nové zbytečné klíčové slovo, je jinde považováno za užitečné primitivum pro flow of control.
16.8.2007 21:46
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
DEFINE_RRELEASE_CLASS(scoped_handle, handle_type, ::CloseHandleApi()); ... scoped_handle some_handle = ::CreateHandleFromOsAPI(bla bla); ...
Kde jsem napsal, že se mi program vleče kvůli "stack unwind"?To jsem si dovolil vydedukovat z vasi odpovedi. Protoze jestli se vam program nevlece kvuli "stack unwind", tak naprosto nechapu proc resite na kolik instrukci vam vyjde finally a na kolik destruktory.
No tak s handlama si nabehl pan Ponkrac, ja si je nevymyslel.
Ano, dovedu si predstavit pripady, kdy vam to muze usetrit par radku kodu. Jenze finally neresi podstatu problemu, je to jen berlicka, ktera se neda k nicemu dalsimu pouzit. Doufejme, ze v novem stadardu bude vyresena ta postata (napr. pridanim lambda funkci) a pak uz bude podobna debata zbytecna.
- novy kompilator
Nove vlastnosti prekvapive vyzaduji implementaci v prekladacich. Nastesti pripominky jejich vyvojaru jsou brany vazne, prave z toho duvodu, ze nikdo nechce, aby se opakovalo fiasko s exportovnanim sablon. Krom toho, pro gcc uz existuje iplementace napr. konceptu, "variadic templates", ...
- finally
V C++ se pouzivaji jine techniky, coz je ostatne duvod, proc se nikdo ani nepokusil to navrhnout a proc to nikomu neschazi.
- nebudou C99 int
Na to jste prisel jak?
16.8.2007 12:23
elviin | skóre: 29
| blog: elviin
| Plzeň-Praha
Vzdyt preci mam pravo se zasmat a jen jsem rad, ze nejsem sam, komu nektere vase prispevky pripadaji nepodlozene a chybne.
16.8.2007 13:59
Daniel Kvasnička ml. | skóre: 52
| blog: The Joys and Sorrows of Being an IT Freak
| Ostrava
16.8.2007 18:34
pavlix | skóre: 54
| blog: pavlix
To IMHO není až takový problém, pokud to člověk potřebuje. A pokud to nepotřebuje, není problém to zkompilovat staticky. Koneckonců to trošku hapruje s testovatelností, takže se jistě najdou i tací, co to nebudou chtít umožnit, aby se nemohli uživatelé střílet do nohy.
Ale vzhledem k tomu, že typické interpretované jazyky obvykle obsahují nějakou formu include,To mě vždycky udivovalo, jak jsou v tomhle různé implementace JavaScriptu jednotné a o include jej nikdo nerozšíří a nerozšíří…
include umí vzít skript „zvenku“, eval umí pracovat jen s tím, co už má. Takže mu skript musíte dopravit jinou cestou, pokud něco takového umožňuje prostředí, ve kterém je interpret spuštěn. XMLHttpRequest ve webových prohlížečích je poměrně mladá záležitost, a chybějící include v JS pro Windows Scripting Host vypadá jako špatný vtip (přestavte si, jak by se asi pracovalo s unixovým shellem bez source).
sveho casu jsem si hral s knihovnou rhino... a to byste se divil co dokaze ecmascript, kdyz ma ty spravne bindingy....Rhino už je součástí sunovské Javy 6, tam už je těch objektů pro binding docela dost
Což mi připomíná, že Java už vlastně tu možnost include má, protože načtení bajtkódu třídy z pole bajtů umí odpradávna, a v 6 už jsou i veřejné třídy pro volání kompilátoru (pokud je k dispozici, samozřejmě).
Takže to můžeme uzavřít, že interpretované jazyky zpravidla include mají, zatímco kompilované ne, přičemž pro jazyky s názvem vyhovujícím vzoru "Java*" platí výrok obráceně
s WSH jsem nemel dikybohu tu cest... ale pokud tam jdou instanciovat jakekoliv activex objekty (z cehoz mam docela strach) tak by nemel byt problem takvou funkcionalitu dopsat...ActiveX tam fungují, takže by to šlo. Dokonce jsou pro WSH myslím nějaké objekty pro čtení souborů už přímo v systému. Ale pořád je jaksi nešikovné v prostředí, které má být určeno pro tvorbu systémových skriptů, programovat
include na 5 řádek
s WSH jsem nemel dikybohu tu cest...
Já bohužel ano. Konkrétně, když jsem ke své značné nelibosti zjistil, že Explorer (neplést s Internet Explorerem) ve Windows 98SE schovává některé přípony (např. shs) i v případě, že se mu v konfiguraci zaškrtne "zobrazovat přípony všech typů". Velmi praktické…
Urcite se problem da resit i jinak, ale ja to mel za 2 hodky hotove a hodne me to bavilo programovat a ulehcilo pocitani... no pocitani to ulehcilo asi vsem v rocniku
Co? Eval umí vyhodnotit řetězec, který se dá za běhu v tom skriptu napsat, dá se načíst z čehokoliv...Ano, přesně tak. Jenže problém je v tom „z čehokoliv“ – JS jako takový nemá žádnou možnost získat takový řetězec odněkud „zvenku“. K tomu musí poskytnout nějaké objekty běhové prostředí, ve kterém ten JavaScript běží (třeba webový browser). Před
XMLHttpRequestem to znamenalo mít ve stránce skrytý iframe, do něj JavaScript asynchronně načíst (a to ještě tak, aby jej browser neinterpretoval, ale nechal na pokoji), zkontrolovat, že se načetl opravdu JS a ne chybová stránka a pak jej spustit. Ve WSH to znamená načíst textový soubor, v cyklu ho projít po řádcích a načíst do řetězce a pak opět předat do eval. Fakt jednoduchost sama 
Je to zhruba na stejné úrovni, jako z Cčkového programu zavolat kompilátor a výsledný program spustit – to pak C má taky include
Což má samozřejmě omezení, ale funguje to. A jestli se nepletu, tak to takhle nějak funguje i v perlovském Inline::C a rubáckém RubyInline.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.