Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Diskuse byla administrátory uzamčena.
Nechápu, proč se vývojáři některých distribucích (ehm většiny) drží zuby nechty zastaralého softwaru, přestože nová verze přináší opravy chyb a pak je backportují jak opice.
Upgrade toolchainu bývá jeden z nejrizikovějších. Kromě obvyklých problémů, které jsou u jakéhokoli balíku, v tomto případě musíte počítat i s tím, že nezanedbatelné procento balíčků v distribuci s novou verzí najednou z různých důvodů nepůjde přeložit. U gcc nejčastěji bývá důvodem větší přísnost na syntaxi, kdy konstrukce, které dříve prošly s warningem, najednou způsobí tvrdou chybu. No a podle očekávání jsou to nejčastěji právě ty balíčky, které nejsou zrovna nejaktivněji maintainované.
pokud dodržuji standard jazyka
Standard, který většina programátorů nikdy neviděla, protože oficiálně ho ani nemohou získat jinak než že si ho koupí za ne zrovna zanedbatelnou částku (nebo si pokoutně stáhnout odněkud draft). A to nemluvím o jeho rozsahu.
No já se nechcu hádat, ale jak může nové gcc rozbít nějaký programČekej reakce lidí, kterým se to děje dnes a denně. Například u NetworkManageru běžně selhává kompilace na Gentoo kvůli warningům proměněným v errory. Dokonce mám pocit, že to ani není upstream verzí GCC ale nějakými úpravami výchozí konfigurace, ale to je čirá spekulace.
Snad pokud dodržuji standard jazykaTeoretik idealista? Zrovna ty warningy eskalované na errory jsou jeden příklad za všechny. Úpravy bývají triviální, ale pokud jde o celou distribuci, je toho dost.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz!CONFIG_SYSCTL (což je hodně neobvyklé) nevznikl dead code, ale už jsem přehlédl, že se tam pak objeví nepoužitý label.
$ cc -v 2>&1 |tail -n1
gcc version 4.9.0-pre9999 20130917 (experimental) commit 6b99cb5e6af1b911414c1b34d3a163b4b52a1ad7 (Gentoo 4.9.0_pre9999)
Mám tím překompilovány všechny programy (některé starším buildem pochopitelně).
Gentoo konkrétně umožnuje používat víc verzí GCC zároveň a přepínat mezi němi pomocí programu gcc-config (Ví někdo, proč to není modul do eselect?), takže i když se něco rozbije, máte po ruce záložní řešení.
některé starším buildem pochopitelně?
gcc version 4.9.0-pre9999A tušíš, proč je 4.8 na Gentoo stále hardmasked?
Ale na testovacím stroji mít bleeding edge překladače a knihovny mi už nějaký ten čas ušetřilo.
Proč je právě teď oficiální 4.8 hardmasked opravdu netuším, proces odmaskovávání neznám.Jedním z kroků je navrhnout ho v bugzille.
protože je ještě dost věcí v bugzile které se s GCC-4.8 nepřeloží,
a další sranda je to že gcc-4.8 je dost oproti předchozím rozdílné viz http://gcc.gnu.org/gcc-4.8/porting_to.html
Ví někdo, proč to není modul do eselect?Existuje (či existoval?) eselect compiler, ale sám používám gcc-config, protože je to úplně jedno.
Až od 4.9.Na gcc 4.8.1 -fdiagnostics-color=auto funguje. Funguje i detekce $GCC_COLORS, která danou volbu zapíná automaticky, je-li nastavena (http://gcc.gnu.org/onlinedocs/gcc/Language-Independent-Options.html).
Tento evidentně zvrácený kód bude pod GCC zkompilován s pouhým varováním, kdežto pod Clangem dostanete chybu. (Nevylučuji, že Clang nějak přinutíte to akceptovat.)GCC umí být maximálně tolerantní, tedy dokáže zkompilovat snad vše, co zkompilovat jde. Tvrdé chyby hlásí snad jen když není zbytí. Nedá se říct, že by to bylo špatně, je to jedna z možností jak kompilaci řešit. Na druhou stranu libovolné warningy můžeš v tvrdé chyby proměnit vyladěním -Werror nebo můžeš zkusit -pedantic-errors.
Apple je na vývoji Clangu/LLVM silně zainteresován a důvodem je už výše zmiňovaný přechod GCC na GNU GPLv3. Apple na GCC silně závisí (závisel) a od tohoto přechodu zůstal zaseknutý na posledních verzích, co vyšly pod starou licencí.Otázkou je, co tím Apple získal a co by ztratil použitím kompilátoru pod GPLv3. Popřípadě co by je stála analýza rizik a jejich zalepení (například patchováním GCC, pokud by to bylo nutné) a zda tu analýzu provedli.
Proto Apple logicky podporuje projekt pod jemu příjemnější (volnější) licencí.Já chápu, že GPLv3 není zrovna pohodlná, ale konkrétně u kompilátoru si nejsem vědom toho, že by představovala až takový problém. Jestli třeba v Apple někdo nezdržoval GPLv3 GCC za jiným účelem (například odůvodněním LLVM). Ale rád se nechám poučit o jiných teoriích ;).
GCC umí být maximálně tolerantní, tedy dokáže zkompilovat snad vše, co zkompilovat jde. Tvrdé chyby hlásí snad jen když není zbytí. Nedá se říct, že by to bylo špatně, je to jedna z možností jak kompilaci řešit. Na druhou stranu libovolné warningy můžeš v tvrdé chyby proměnit vyladěním -Werror nebo můžeš zkusit -pedantic-errors.Gcc dokaze zkompilovat i to co by se zkompilovat nemelo. V Ccku umoznuje definovat funkci uvnitr funkce, takze pokud na zacatku kodu zapomenete na jednu slozenou zavorku, tak gcc ohlasi chybu az na samem konci souboru. Proto je v uzitecne davat stredniky i tam kde syntakticky byt nemusi. Na druhou stranu ma GCC i neco striktenejsi semantickou kontrolu u sablon nez ma MSVC. MSVC dokaze preparsovat sablonu i kdyz nezna definice typu v ni pouzitych. Gcc provadi (asi jenom castecnou) semantickou kontrolu sablon i kdyz je zrovna nepouzijete (instantiate).
return bez hodnoty u funkce deklarované s návratovou hodnotou, zatímco brání definici šablon, které obsahují neznámé typy. (Existují ale i výjimky, třeba extern template GCC kvůli komplexnosti takové implementace nikdy neimplementovalo a po vypuštění extern template z C++11 to už ani neplánuje.)
Otázkou je, co tím Apple získal a co by ztratil použitím kompilátoru pod GPLv3. Popřípadě co by je stála analýza rizik a jejich zalepení (například patchováním GCC, pokud by to bylo nutné) a zda tu analýzu provedli.Apple používá Objective-C a Objective-C++. Pro ladění těchto jazyků (a třeba nedávno zavedený automatický reference counting) se interně lépe strukturované LLVM hodilo. Stejně jako pro JIT kompilace, třeba implementace OpenGL v MacOS X se JIT kompiluje podle hardware, na kterém se spustí.
Já chápu, že GPLv3 není zrovna pohodlná, ale konkrétně u kompilátoru si nejsem vědom toho, že by představovala až takový problém. Jestli třeba v Apple někdo nezdržoval GPLv3 GCC za jiným účelem (například odůvodněním LLVM). Ale rád se nechám poučit o jiných teoriích ;).Pro JIT kompilace může GPLv3 představovat problém.
Pro JIT kompilace může GPLv3 představovat problém.Zajímavé.
.
Větší problém (který zatím moc neřeší ani jedna strana) podle mě je, že některé knihovní třídy mají poměrně bohatou hierarchii (a to i STL, některé implementace k tomu přidávají ještě své úrovně abstrakce) a uživatel nedostane chybu na úrovni svého kódu, ale na všech úrovních po cestě. Sebesprávnější programátor má potom smůlu, protože se kvůli jednomu překlepu topí v hláškách cizího kódu.
Třeba už to ale nějaké cool IDE vyřešilo a pro svoji ignoranci o tom nevím - představoval bych si takové hlášky rozklikávací s náhledy kódu při najetí myší nad danou třídu, což s clang[++]em/LLVM určitě nebude problém.
S pouzitim Clangu pro parsovani kodu v IDE si uz pohravali v QtCreatoru (ja na to i branch v gitu) - problem je, ze je to radove pomalejsi nez "naivni" implementace, kterou vetsina IDEcek pouziva, takze na obarveni klicoveho slova nebo doplneni nazvu metody za tecku/operator-> se musi cekat, coz urcite zadneho programatora nepotesi Z toho duvodu se to zatim jeste nikde moc neujalo.
Vim jak otravny treba je defaultni c++ obarvovani ve vimu, kde po otevreni levy zavorky tam zacnou cervene svitit ruzny pravy zavorky, protoze "nepasujou" a sviti dokud nedokoncis psani.To mi víceméně vyhovuje. Aspoň se to nesnažím kompilovat, dokud to neopravím.
Uz vidim jak zacnu psat novy radek kodu a v tu chvili me vsechen nasledujici kod zacne cervene blikat dokud nedopisu radek a neukoncim strednikemBlikání je špatné obecně :). Ale bylo by zajímavé to zkusit neblikající a ne přespříliš výrazné.
Ja mám starú šunku notebook a zase až tak pomalé to dopĺňanie vo vime nie je (~0.5s, dopĺňanie sa spúšťa na pozadí). Backend musí byť ale celkom slušne nastavený, zapnuté cachovanie ... Samozrejme hovorím o dopĺňaní v komplexných projektoch používajúcich Qt 5 (malá konzolová aplikácia používajúca max tak fstream bude samozrejme rádovo rýchlejšia).
A pak že je Java pomalá Tam jsou v IDE (např. Netbeans) tyhle věci běžné a nápověda se zobrazí hned.
int funkce()
{
return;
}
Tento evidentně zvrácený kód
Huh? A co je na něm zvráceného?
Já osobně jsem totiž s GDB krajně nespokojený. Pro takovéto obyčejné použití celkem postačí, po letech používání ale začnete narážet na podivné chování (GDB pošle samo sobě SIGSTOP), pády GDB (laděný program často „sejme“ i debugger) a další podivnosti (GDB mi při auto-completion nabídne funkci pro breakpoint, pak ale řekne, že je nedefinovaná).Čoveče, jak to používáš? S tím jsem se nikdy v životě ještě nesetkal. A jinak debuggovat jde i gdb, pro ty případy kdy samo sobě pošle SIGSTOP (to by se asi dít nemělo).
GDB bohužel nebylo nikdy navrženo tak, aby sloužilo jako API pro jiné programy (stav je v globálních proměnných apod.), takže to ani jinak nejde.To je omyl. Jen je k tomu potřeba nepoužívat TUI. To bylo skutečně navrženo jako UI, ne jako API (i když to tak na první pohled nemusí vypadat).
Huh? A co je na něm zvráceného?Nedefinovaná návratová hodnota. Zakázali to sice tuším až v C99, ale autora takového kódu bych za to nakopal.
Čoveče, jak to používáš? S tím jsem se nikdy v životě ještě nesetkal.Při vývoji Darlingu klidně několikrát za den. Těžko říct, to přesně to způsobuje, ale nemůžu se LLDB dočkat.
To je omyl. Jen je k tomu potřeba nepoužívat TUI.I tak je to oproti klasickému API bída.
Nedefinovaná návratová hodnota. Zakázali to sice tuším až v C99, ale autora takového kódu bych za to nakopal.Tož nám co pamatujeme ještě BASIC (GOSUB, RETURN) a kované procedury (subroutine, proto SUB, jinak žádné call, ale postaru ještě pěkně GOTO) to až tak zvrácené/nepřirozené nepřijde. Ostatně jestli hned za callem nic z akumulátoru nevyzvedáváš, tak je i docela nesmysl do něj něco cpát, konvence, nekonvence. A furt platí že Céčko je programovací jazyk a ne nějaký strojový syntaktický popis programu. Jazyk se většinou píše na klávesnici, na tu obrazovku neskáče ten kód sám od sebe. Mně osobně by jako prasení nepřišlo i kdyby tam žádný return nebyl, protože funkce je většinou deklarovaná někde mimo hlavní funkce a také je jasně ohraničená složenými závorkami. Pro nás co píšeme ještě stále programy v textovém editoru to furt jeden ENTER a min. šest ušetřených písmenek. Je kravina pokračovat někde v prostoru mimo program, takže já bych od kompilátoru očekával (leda by to bylo nejednoznačné), že za „}“ ten leave a ret automaticky doplní a nebude otravovat jinak to není kompilátor ale otravný krám. A v C99 si můžou psát co chtějí.
Při vývoji Darlingu klidně několikrát za den. Těžko říct, to přesně to způsobuje,Samozřejmě asi máš dost starostí s vývojem Darlingu, takže to po tobě nikdo nemůže chtít, ale GDB je stále ve aktivním vývoji. Takže pokud ti to fakt někde blbne a je to nějaká trivialita je dobré stáhnout si zdrojáky gdb a můžeš se pokusit to místo které vrací kraviny najít. Někdy je to lepší než se nad tím rozčilovat a doufat v nějakou alternativu. Jinak i když GDB nemá tolik možností jako jiné debuggery, mi přišel ze všech nejlogičtější (jako by půlku práce udělal za mě).
I tak je to oproti klasickému API bída.Tak jestli chceš, GDB má i paketový protokol. Pointa je, že chceš-li implementovat API do GDB začínat se má tady, ne tady. To User Manual je všeříkající.
paketový protokol.No ale úplně nejlepší by bylo asi nevymýšlet nějaké kraviny a naučit se používat libgdb.
Ostatně jestli hned za callem nic z akumulátoru nevyzvedáváš, tak je i docela nesmysl do něj něco cpát, konvence, nekonvence. A furt platí že Céčko je programovací jazyk a ne nějaký strojový syntaktický popis programu. Jazyk se většinou píše na klávesnici, na tu obrazovku neskáče ten kód sám od sebe. Mně osobně by jako prasení nepřišlo i kdyby tam žádný return nebyl, protože funkce je většinou deklarovaná někde mimo hlavní funkce a také je jasně ohraničená složenými závorkami.Co je to za pseudofilosofické sračky? Když chci funkci bez návratové hodnoty, tak přece nebudu do hlavičky psát, že návratová hodnota je typu
int, ne? Jaký je problém na té tvé klávesnici z doby BASICu místo int napsat v hlavičce void?
Problém je, že mi ten int unikl. Pak už to samozřejmě dává smysl.Tím je vyřešeno.
void nebo nic, pak mi přijde return zbytečný.Vzhledem k tomu, že nic je ekvivalent
int, tak bych viděl warning jako velmi relevantní (i když je to natolik bad style, že pak dávám přednost warningu v každém případě).
Vzhledem k tomu, že nic je ekvivalent intJak jsem říkal. Staré dobré procedury. To se prostě zavolalo, vrátilo a takové kraviny jako návratové typy nebo hodnoty se vůbec neřešili. S ničím jiným než úspěchem se ani nepočítalo a když nastane chyba, nech si to vyřeší systém sám. Ono tou deklarací funkce bez zapsání typu na integer se automaticky počítá s funkcemi, ne s procedurami. Do šrotu s krámem jakýmsi (to je jako kdyby mě někdo chtěl vychovávat co mám psát).
Jak jsem říkal. Staré dobré procedury. To se prostě zavolalo, vrátilo a takové kraviny jako návratové typy nebo hodnoty se vůbec neřešili.Stačí před funkci napsat
void. Výstup lze řešit prostřednictvím ukazatelových parametrů.
S ničím jiným než úspěchem se ani nepočítalo a když nastane chyba, nech si to vyřeší systém sám.Vždy můžeš použít například funkci
abort(). Remcáš nad věcmi, které vůbec nejsou zásadního významu.
Výstup lze řešit prostřednictvím ukazatelových parametrů.Proč tak složitě? Výstup stačí uložit do předem dané globální proměnné :)
int, ne void.
Trebas chces aby to vracelo int ... trebas kvuli rozsahu ... ale je ti jedno, co tam bude/nebude.
Tohle jsem nepochopil. Šlo by to trochu rozvést?
nejak definovanej rozsah (= nejaky mnoztvi Bytu)Rozsah a množství bajtů jsou sice na sobě do jisté míry závislé, ale dát mezi to rovnítko je pitomost.
a ja si vysledky (trebas) ukladam do pole intu. U nekterych je mi vysledek putna, ale nechci kvuli tomu vyrabet nejakou odbocku - to muze bejt drahy. A jednoduse pak vim, ze vysledek po zavolani tech 150ti funci bude nejak velkej kus dat v pameti, se kterym trebas neco dalsiho provedu.Můžeš popsat mechanismus ukládání a vyzvedávání těch hodnot, odpovídající konstrukce v C a souvislost s návratovou hodnotou typu
int? Mám takové podezření, že vaříš z vody.
To, co píšete, moc smysl nedává - když voláte konkrétní funkci, tak prostě musíte (už při kompilaci) vědět, co je zač a co (jaký typ) vrací. Ne že vám vrátí "nějaký počet bytů".
Ale aspoň mne to navedlo na skutečný use case. Řekněme, že jde o callback nebo mám v poli pointery na funkce, z nichž některé vracejí užitečnou hodnotu a od některých žádnou informaci neočekávám. Pak je potřeba, aby měly všechny stejný typ návratové hodnoty. Ale i v tom případě bych to neřešil a prostě tam napsal "return 0". Ta jedna instrukce xor až tak závratný vliv na výkon mít nebude.
Ale i v tom případě bych to neřešil a prostě tam napsal "return 0".+1 Nicméně to asi nebude platit pro pole funkcí, ale spíše pro pole struktur, ve kterých budou kromě funkcí i informace, ze kterých zjistím, zda mě návratová hodnota zajímá. Pak je ale otázkou, jeslti skutečně nebudu chtít vracet data ve formě „nějakého počtu bajtů“, ale na to se spíše hodí funkci předávat odkaz na buffer nějaké velikosti nebo dle vhodnosti použít některou z mnoha jiných technik.
return je prasárna a překladač netuší, jak převést void na int, tudíž hodí error. Teoreticky by mohl hodit warning a buď interpretovat void jako magickou konstantu (nulu), nebo by mohl return bez argumentu interpretovat jako návrat bez inicializace návratové hodnoty. Ale je to zbytečnost, když je stejně zřejmé, že je to špatně.
Pokud bys chtěl něco zakódovat/konvertovat do návratového int, tak to buď musí být z datového typu, které překladač dokáže konvertovat automaticky, nebo musíš to konverzi provést explicitně.
Definovat vse muze byt drahe. Pracoval jsem s API, kde byla obdoba errno a navratova hodnota mela smysl jen kdyz nebyla "errno" definovana. V tom pripade je naprosto zbytecne z funkce neco vracet. Kdyz takovych pripadu mate v kodu stovky, tak to je na 8bitovem kontroleru uz poznat.Huh? A co je na něm zvráceného?Nedefinovaná návratová hodnota. Zakázali to sice tuším až v C99, ale autora takového kódu bych za to nakopal.
Interrupty do toho cpu přes signály a další hrůzy
To je poněkud špatný návrh API. Nebyl by přece problém to navrhnout tak, aby se nevracela hodnota zbytečně a funkčnost zůstala zachovaná.Jo, ale za cenu prodlouzeni a zpomaleni kodu. Casto se totiz muze vyplatit z nedefinovane hodnoty vypocitat jinou nedefinovanou nez prodlouzit nejdelsi cestu programem pridanim dalsich podminek. To, ze neco pocitate zbytecne, je jedno, protoze stejne musite mit tolik casu, kolik ho je potreba v nejhorsim pripade.
Ono taky errno je velký problém pro vícevláknové aplikace. Ať už jde o pthread na Linuxu nebo interrupty na 8bitu.To už je trochu jiné téma.
Styl, kdy funkce vrátí kód chyby a data předá na pointery v parametrech mi přijde asi nejlepší. V poslední době jsem však přišel na chuť vyjímkám, ty dokáží ještě víc zjednodušit život.Tady se bavíme o tom, že tom chce optimalizovat do poslední instrukce ;).
void cidla_ok(void) {
int hodnota, rtn, i;
for (i = 0; i < pocet_cidel; i++) {
hodnota = cti_z_i2c(cidla[i].i2c_adresa);
hodnota = skaluj(hodnota, cidla[i].typ_cidla);
rtn += hodnota_ok(hodnota, cidla[i].typ_hodnoty);
}
if (errno || rtn) {
reboot();
}
}
Tohle nemá šanci obecně fungovat. Na jedné straně totiž potřebujete, aby v případě, že k chybě nedojde, zachovala se hodnota errno (jinak vám úspěch druhého volání zamaskuje chybu prvního), ale pak nemáte nijak zaručeno, že pokud všechny uspějí, na konci bude errno nula. Mimochodem, standardní C knihovna vám v případě úspěchu negarantuje vůbec nic, takže nikdy nestačí kontrolovat errno, ale vždy musíte nejdřív zkontrolovat návratovou hodnotu.
A efektivitou bych se neoháněl už vůbec, když pokaždé zbytečně projdete celý cyklus, i když bude výsledek jasný třeba hned po první iteraci.
libc se v projektu nepouzivala, proto jsem v komentarich psal "errno" a obdoba errno a ne errnoTohle nemá šanci obecně fungovat. Na jedné straně totiž potřebujete, aby v případě, že k chybě nedojde, zachovala se hodnota
errno(jinak vám úspěch druhého volání zamaskuje chybu prvního), ale pak nemáte nijak zaručeno, že pokud všechny uspějí, na konci budeerrnonula. Mimochodem, standardní C knihovna vám v případě úspěchu negarantuje vůbec nic, takže nikdy nestačí kontrolovaterrno, ale vždy musíte nejdřív zkontrolovat návratovou hodnotu.
Projit cely cyklus zbytecne me vubec nevadi, protoze na spracovani cyklu mam vyhrazeny dany cas. Je proto lepsi obcas delat zbytecne veci a snizit maximalni mozny cas behu. Prumerny cas je mi ukradeny.A efektivitou bych se neoháněl už vůbec, když pokaždé zbytečně projdete celý cyklus, i když bude výsledek jasný třeba hned po první iteraci.
Prectete si znovu cely thread
A vy si přečtěte příspěvek, na který odpovídáte.
libc se v projektu nepouzivala, proto jsem v komentarich psal "errno" a obdoba errno a ne errno
To je úplně jedno. To, co jsem napsal, je problém pro jakoukoli implementaci. Buď v případě úspěchu errno vynulujete nebo ho necháte - ale vaše ukázka nebude fungovat správně ani v jednom případě. Samozřejmě ještě může být chování nedefinované (jako ve standardní C knihovně), ale pak jste na tom ještě hůř.
chce zjistit zda v sérii akcí nastala nějaká chyba
Jenže to právě nezjistí, pokud před tou sérií nenastaví errno na nulu. A to neudělal.
Možná vypadám jako hnidopich, ale při své práci se setkávám s důsledky podobných "samozřejmých" předpokladů (které se tu a tam ukážou neoprávněnými) příliš často na to, abych to mohl ignorovat.
void a (2) v tom, že se v něm return nevolá vůbec, natož podmínečně.
Čoveče, jak to používáš? S tím jsem se nikdy v životě ještě nesetkal. A jinak debuggovat jde i gdb, pro ty případy kdy samo sobě pošle SIGSTOP (to by se asi dít nemělo).Mě už se taky GDB podařilo nejednou shodit, takže se té nespokojenosti ani moc nedivím. Ale není třeba čekat na LLDB, docela slušný je i idb (intelácký debugger, je součástí Intel Composer, pro nekomerční účely zdarma). Nevýhodou je, že jeho UI je postavené nad Eclipse a je tedy šíleně pomalé.
Mě už se taky GDB podařilo nejednou shodit, takže se té nespokojenosti ani moc nedivím.Ono je asi dobré, pokud nějaký bug vyběhne nečekaně si uložit stav a pak se k němu vracet. Mně se teda zatím podařilo ho jenom zacyklit, musím to zaklepat, mně drží jako skála.
Ale není třeba čekat na LLDB, docela slušný je i idbPochopil jsem to tak, že nevyhovující je spíš způsob ovládání jak debuger samotný, že?
Ono je asi dobré, pokud nějaký bug vyběhne nečekaně si uložit stav a pak se k němu vracet. Mně se teda zatím podařilo ho jenom zacyklit, musím to zaklepat, mně drží jako skála.Pises "jen" v Ccku anebo i v C++? U projektu (se sablonama), ktery ma velke mnozstvi symbolu staci zmacknout 2x po sobe TAB ve spatnem kontextu a GDB jde do kopru. Z nejakoho duvodu se snazi zkombinovat vsechny symboly a dela to tak dlouho dokud ho nezabije OOM. O kterej bug presne je jedne to nemuzu rict - bugu na "TAB completition" v gdb existuje nekolik.
V první řadě je nutné podotknout, že označení GCC je lehce matoucí. GCC totiž označuje jak sadu kompilátorů (GNU Compiler Collection) pro různé jazyky (C++, Java, Fortran, ...)Jak je to s kompilátorem pro Javu v GCC? Vždycky jsem to kompiloval, ale nikdy jsem si nevšiml, že by to bylo nějak využilo. Je to vůbec k něčemu dobré?
No, člověk z toho má jakousi nativní binárku bez bloatwaru v podobě JREVždyť to je pomalu na erekci. Ještě jsem teda ale žádné třídy překládané do binárek v nasazení neviděl, ale budu to muset zkontrolovat. Cokoliv lepší než Java.
na OS X se ale LLVM-GCC od roku 2008 běžně používápoužívalo, teď už se v podstatě používá jen clang
(default už to nějakou dobu je, a v dnes vydaném Xcode 5 už bylo llvm-gcc dokonce odstraněno takže clang ("Apple LLVM compiler 5.0") je už jedinou Applem dodávanou možností).
vim ~/.emacs Jako že je tahle debata na mě moc vysoká liga (nebo spíš to není hra mého srdce) tak tahle hláška mě dohnala k slzám. Sorry za offtopic, nemůžu si pomoct.
))
Tento evidentně zvrácený kód...
pitomost
Tiskni
Sdílej:
