Portál AbcLinuxu, 27. dubna 2024 03:05
Céčko ... spíše jako koníček, protože bych s ním asi moc nevydělal.Zajímavé. Kolik je cca představa o "vydělávat moc"? Viz třeba tohle (byť přes 2 roky staré).
27.4.2019 10:58
xkucf03 | skóre: 49
| blog: xkucf03
Ten výzkum je trochu podivný. Např. dělení na C a C/C++, protože céčko je víceméně podmnožina C++. A u té Javy mi taky dělení na EE a SE nedává moc smysl. Máš i juniorní EE pozice, kde ale boucháš jen nějaká REST rozhraní podle šablony, takže to zvládne i čerstvý absolvent. Naopak i v SE se dají řešit i složité úlohy vyžadující zkušenost. Spíš by to tedy měly být juniorní a seniorní pozice, ale ten přechod je plynulý, takže to nejde moc rozdělit (serióznější průzkumy se ptají mj. na počet let praxe s danou technologií + obor).
Např. dělení na C a C/C++, protože céčko je víceméně podmnožina C++Ehm, programoval jste v těch jazycích někdy?
Ano. A píši „víceméně“ – přestože tam jsou nějaké1 rozdíly, tak většina C kódu je zároveň validní C++ kód. Sice se dá říct, že některé věci z C bys jako C++ programátor nemusel umět, ale z hlediska toho průzkumu mi přijde relevantnější spíš to, že abys mohl psát v C++, musíš (až na nějaké detaily) umět i C.
Kromě toho ten průzkum nerozlišuje kategorie „C“ a „C++“, ale „C“ a „C/C++“.
[1] viz např. Where is C not a subset of C++?
WTF? Přijde mi, že tvůj komentář vůbec nesouvisí s tím, na co reaguješ.
Pro jednoduchost predpokladejme, ze C je ostra podmnozina C++ (protoze C++ z C vychazi).
Hodně zjednodušeně ano, ale ostrá podmnožina to není (ne každý C kód je i platným C++ kódem).
Obracene to ale neplati, C++ neni ostrou podmnozinou C (protoze pridava celou radu vlastnosti), takze nelze dat rovnost mezi C a C++.
To jsem nikdy netvrdil. Píši tam:
céčko je víceméně podmnožina C++
Což znamená, že striktně vzato to podmnožina není, ale z praktického hlediska lze říct, že většinou to platí. A hlavně z pohledu toho průzkumu píši:
Sice se dá říct, že některé věci z C bys jako C++ programátor nemusel umět, ale z hlediska toho průzkumu mi přijde relevantnější spíš to, že abys mohl psát v C++, musíš (až na nějaké detaily) umět i C.
S čímž, zdá se, souhlasíš:
Naopak, pokud mas programatory v C++, tak se da predpokladat, ze zvladaji i C.
A zpět k mému prvnímu komentáři: ten průzkum tvrdí, že C programátoři jsou ohodnoceni výrazně lépe, než C/C++ programátoři, což mi nedává moc smysl vzhledem k tomu, že C/C++ programátor musí být zároveň i C programátorem.
Když se podívám např. na Stack Overflow’s annual Developer Survey 2019 (což je průzkum na výrazně větším vzorku respondentů a zjevně s propracovanější metodikou), tak podle něj jsou C++ programátoři platově ohodnoceni lépe než C programátoři (kategorii C/C++ tam nemají), ale rozdíl mezi nimi není moc velký – 55:52 ve prospěch C++. Zatímco ten průzkum ITTalents.cz uvádí poměr 60:50 ve prospěch C. Ano, trh v ČR by mohl být trochu specifický, ale spíš to na mě působí spíš jako nějaký shluk víceméně náhodných čísel než nějaký seriózní průzkum.
Pro jednoduchost predpokladejmeProsim te, muzes mi vysvetlit, co jsi nepochopil na obratu pro jednoduchost predpokladejme?
Obracene to ale neplati, C++ neni ostrou podmnozinou C (protoze pridava celou radu vlastnosti), takze nelze dat rovnost mezi C a C++.To bylo konstantovani faktu, ze ktereho plyne smysluplnost rozlisovani mezi C a C/C++, nad cimz ses tu pozastavoval.
A zpět k mému prvnímu komentáři:
Např. dělení na C a C/C++, protože céčko je víceméně podmnožina C++.Sorry, ale z toho komentare jsem opravdu nepochopil, ze mluvis, o vysledcich a ne jen rozdeleni do kategorii. Jinak ty hodnoty pro C a C/C++ ti mohou vyjit prirozene jine. Protoze s C se dneska da setkat v jinych oblastech nez v C/C++. Pokud nekdo dela v C vetsinou je to systemove programovani. Pokud nekdo dela C++, tak to u rady firem pokryva i vyvoj bezneho aplikacniho software.
O to mi právě šlo – vážně je trh v ČR tak jiný nebo ten průzkum neodpovídá realitě? V USA totiž podle toho průzkumu StackOverflow jsou C a C++ programátoři placeni stejně a celosvětově jsou podle něj lépe placeni C++ programátoři.
A zpět k mému prvnímu komentáři: ten průzkum tvrdí, že C programátoři jsou ohodnoceni výrazně lépe, než C/C++ programátoři, což mi nedává moc smysl vzhledem k tomu, že C/C++ programátor musí být zároveň i C programátorem.Teoreticky ano, prakticky ne. Styl programování v C je o hodně jiný, zejména v porovnání s moderním C++. Např. standardní knihovna C je mnohem menší než C++, nemá např. ani max funkci, natožpak třeba datové struktury. V C si musíš mnoho věcí řešit sám a jinak než v C++. Zkus si přepsat relpipes do C a uvidíš
Zkus si přepsat relpipes do C a uvidíš
To bych asi nedal (resp. přestalo by mě to bavit), nebo minimálně ne bez dalších knihoven/frameworků (zatímco v tom C++ si vystačím s tím, co je ve standardní knihovně).
Dá se tedy asi říct, že psát v čistém C je pracnější než v čistém C++. Na druhou stranu: pokud tě v práci platí od hodiny, tak ti to může být celkem jedno – uděláš méně práce, napíšeš méně funkční software, ale to je věc té firmy – není přece důvod, proč bys za svůj čas měl dostat méně zaplaceno, ne?1
Pokud to tedy nejsou náhodná čísla nebo chyba měření, tak to asi bude tím, jak už tu někdo psal, že na těch projektech v C se asi vyžadují i nějaké jiné znalosti (HW a nízkoúrovňové programování) než u těch C++ projektů. Možná je tam příplatek i za ten „opruz s C“. Na druhou stranu jsem potkal lidi, kteří si v C libují a naopak nesnáší C++, tak nevím – jako Javista to nedokážu úplně posoudit 
ale přijde mi, že ty věci, které jsou v C++ navíc oproti C, mi víc práce šetří než přidělávají, takže když už, tak z těchto dvou možností beru raději to C++ (nebo C/C++).
[1] leda že bys řekl, že programovat v C++ je oproti C natolik zábavné, že to lidi budou rádi dělat i za výrazně méně peněz :-)
Tu odměnu určuje nastavení trhu.
Vždyť ano. Tak pokud si budu vybírat mezi dvěma pracemi, tak si vyberu buď tu zábavnější, klidnější, méně náročnou1 nebo si za tu horší nechám aspoň líp zaplatit, ne?
[1] těch kritérií bude samozřejmě víc včetně toho, jak daleko to mám od domu, jak vypadají kolegové, jaký v tom vidím smysl, osobní rozvoj atd.
Na druhou stranu jsem potkal lidi, kteří si v C libují a naopak nesnáší C++ ... ale přijde mi, že ty věci, které jsou v C++ navíc oproti C, mi víc práce šetří než přidělávají,Jazyk C je pro spoustu lidi a situaci zajimavy tim, ze se jedna o jednoduchy, snadno citelny a tudiz relativne predvidatelny programovaci jazyk. Tedy vhodny pro systemove programovani, kde je zadouci, aby mel programator predstavu, jak kod a data bude mapovan na hardware. (I kdyz dnes je to spis iluze.) Naproti tomu C++ je neuveritelne komplexni jazyk jez zvladne pobrat jen par programatoru. Tim, ze spoustu veci usnadnuje, dochazi k tomu, ze se jazyk vzdaluje od toho, aby programator alespon tusil, jak co bude mapovano na hardware, takze pro systemove programovani to neni uplne vhodna volba. Na druhou stranu, pri vysokourovnovem programovani C++ nechava spoustu technickych detailu na programatorovi, takze i v tomto smeru to neni pro radu lidi dobra volba. (I kdyz musim dodat, ze novejsi verze to hodne dohnaly.) Jeste je tu jeden duvod, proc programatori nemaji radi C++. Dlouha leta byl problem sehnat prekladace, ktere by podporovaly standard v plne siri, takze se vyvojari museli drzet nejake arbitrarne zvolene podmnoziny jazyka. Dnes se ji drzi pro zmenu take urcite podmnoziny jazyka, protoze o nekterych starsich castech jazyka se prohlasuje, ze jsou proste fuj.
Dnes se ji drzi pro zmenu take urcite podmnoziny jazyka, protoze o nekterych starsich castech jazyka se prohlasuje, ze jsou proste fuj.Njn, ale tak ono když tyto některé starší části jsou např.
27.4.2019 15:05
auto_ptr nebo podobně, tak se úplně nelze divit, že jsou prohlášeny za fuj...
tak se úplně nelze divit, že jsou prohlášeny za fuj...To by se dalo jeste pochopit, ale co treba new a delete? To je pro spoustu lidi taky fuj...
delete je z hlediska moderního C++ spíše antipattern. IMO jsou pro to celkem dobré důvody. Samozřejmě vyjma těch situací, kdy není jiná dobrá možnost.
Tak ano, delete je z hlediska moderního C++ spíše antipattern.A to je presne to, o cem mluvim. Nektere casti C++ vcetne relativne zakladnich veci jsou prohlaseny za fuj a neni radno se jich dotykat, a ze toho je. IMHO je toto solidni dukaz toho, ze C++ je FUBAR by design, i kdyz verze c++11, c++17 se to snazi docela soldine zamaskovat.
calloc() místo malloc(). malloc() byl "fuj" a jeho použití bylo potřeba zdůvodnit, myslimže na to byl i lint v buildu. Resp. ono to není ani tak, že by malloc() nebo delete byly z podstaty fuj, ale je to spíš dohoda nad rozsahem jejich použití.
Jinak celkem souhlsaim, že C++ víceméně FUBAR by design, akorát si nemyslim, že zrovna ten new/delete by byl ten problém. To spíš jiné abstrakce násilně naroubované na původní jazyk, jako např. zprasené move semantics a systém druhů hodnot z toho pošlý... to když čtu, připadám si, že taky pojdu. Taky by mě zajímalo, jestli různé pokročilejší SFINAE-based triky jako třeba enable_if apod. jsou výsledkem nějaké zralé úvahy a promyšleného návrhu, nebo toho, že někdo jedno dne řekl "Helemese, to je zajímavé, že to takhle funguje, to bychom mohli využít". Podezírám je, že spíš to druhé.
BTW: Proč se tak málo rozšířilo D? Působí celkem dojmem jako „C++ udělané dobře“. Nebo se někde ve větší míře používá?
3.5.2019 14:10
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
BTW: Proč se tak málo rozšířilo D? Působí celkem dojmem jako „C++ udělané dobře“. Nebo se někde ve větší míře používá?IMO dva hlavní problémy D jsou (1) absence zaměření a (2) je lepší jen o trochu. Ten problém (1) je vidět např. na tom použití GC+runtime. To nedává obecně smysl pro jazyk, který by měl být náhradou C++, protože tenký runtime + absence GC magie je často vůbec důvod, proč něco dělat v C++ (byť to tak nutně být nemusí). Kdyby D nabízelo nějakou skutečně dobrou možnost, jak mít volitený GC, tak by to mohlo fungovat, ale tohle je hodně těžké a D se to nepodařilo. Pro porovnání Rust na tohle rezignoval (GC byl odstraněn před verzí 1.0) a IMO to bylo dobré rozhodnutí. D mělo ambice být Rustem, Gočkem i Pythonem najednou a to je pak šance na fail hrozně vysoká (a možná to vůbec není splnitelný cíl). Co se týče (2), D IMO nemá žádné moc výrazné fíčury, které by ho vyzdvihly nad C++. UFCS? Unicode strings? CTFE? Všechno je to hezké a je to vylepšení oproti C++, ale nestačí to. A některé velké problémy C++ to vůbec neřeší. Když nebudu používat GC v D, jaké mám možnosti memory managementu? V podstatě jsem na tom stejně jako v C++, resp. dnes vlastně i hůř - ty C++ move semantics jsou asi furt lepší než to, co je v D.
Zrovna před chvílí mi ve čtečce přistála zprávička, že nové GCC obsahuje kompilátor D :-)
Unicode strings
Už jen tohle je v C++ dost velké utrpení. std::string je ve skutečnosti posloupnost bajtů, ale historicky se tenhle typ běžně používá pro textové řetězce (i ve většině učebnic), pak je tu std::wstring a několik dalších variant… Různé knihovny používají pro řetězce různé typy, takže to mezi nimi musíš konvertovat. Přitom ale nástroje pro konverzi buď chybí nebo jsou nedokonalé nebo se nepohodlně používají. Takový wstringconvert<codecvtutf8<wchar_t>> je pro jistotu deprecated, ale náhrada za něj ve standardní knihovně zatím chybí. Práce s textovými řetězci je podle mého základní věc a do standardní knihovny jednoznačně patří. Další věc jsou vstupní/výstupní proudy, tam je podobný problém s bajty vs. znaky. Když to srovnám s Javou, tak oproti ní v tomhle C++ působí naprosto retardovaně a jako by bylo dílem někoho, kdo netuší, co dělá (chápu, že hodně z toho je dané historicky a snahou o zpětnou kompatibilitu, ale výsledek je takovýhle).
Naopak jiné věci jsem si na C++ celkem oblíbil, něco je tam lepší než v Javě (byť za cenu vyšší komplexity jazyka) a něco je prostě jinak, ale dá se s tím celkem žít (správa paměti). Ale ty řetězce a proudy mě budou štvát asi pořád. A pak je taky problém, když se sejde dědičnost, šablony, snaha o ABI kompatibilitu a správa paměti… to se pak musí různě hackovat přes vzor D-Pointer a člověk musí víc bojovat s technickými detaily, místo aby se soustředil na byznys logiku a od těch detailů mohl díky jazyku abstrahovat.
), tak tohle by asi váhy na stranu D nepřevážilo - sice bych si usnadnil práci se stringy, ale zas bych se musel babrat s GC, přišel bych o moving, je to marginální jazyk, tj. malý ekosystém, má taky svoje nevýhody... Prostě ta změna není natolik fundamentální, aby to s tím pohlo.
Kdyby Rust neměl borrow checker (a možná nějaké další věci), dopadlo by to s ním IMO úplně stejně, přestože má velmi slušnou podporu utf-8. (A kdo ví, možná to s ním dopadne stejně i s borrow checkerem )
Btw. Java má s Unicode taky problém, AFAIK má nativní podporu jen pro UCS-2.
Prostě ta změna není natolik fundamentální, aby to s tím pohlo.
Pokud jsi vyrostl na C++, tak to docela chápu, ale když někdo k C++ takový vztah nemá, tak to IMHO tak jednoznačné není.
malý ekosystém
D by mělo být s C/C++ dost kompatibilní, kombinovatelné. Ostatní jazyky na to dost kašlou (není to zrovna lehký úkol) nebo jsou propojitelné maximálně s C a to ještě většinou jen nějak nepřímo. Mimochodem, GraalVM je v tomhle celkem revoluční a unikátní.
Btw. Java má s Unicode taky problém, AFAIK má nativní podporu jen pro UCS-2.
Interní reprezentace v paměti1 je jedna věc, ale to tě nemusí moc zajímat – z pohledu programátora je daleko důležitější, jaké API máš k dispozici. A v tomhle Java oproti C++ jasně vede. Máš tam oddělené bajtové a znakové proudy. Znakový si z bajtového vyrobíš jednoduše tak, že jednu třídu (resp. instanci) obalíš jinou třídou. A jako parametr uvedeš požadované kódování (nebo neuvedeš a pak se používá místní kódování platformy). Totéž platí pro převod mezi Stringem a polem bajtů – opět si zadáš kódování jako parametr nebo necháš výchozí a jednoduše si to převedeš.
Na nějaké okrajové problémy s Unicodem můžeš narazit i v té Javě, ale to asi v každém jazyce. Každopádně se to vůbec nedá srovnávat se situací v C++.
[1] BTW: od Javy 9 už neplatí ani to UTF-16, ale od toho můžeš abstrahovat, je to implementační detail toho jazyka/platformy
Pokud jsi vyrostl na C++, tak to docela chápu, ale když někdo k C++ takový vztah nemá, tak to IMHO tak jednoznačné není.Já vyrostl na Pascalu
D by mělo být s C/C++ dost kompatibilní, kombinovatelné.Jistě, ale stále musí být nějaký důvod, proč to vůbec dělat. Jestli chceš používat D kvůli stringům, ale zároveň jsi ochoten používat C++ ekosystém, tak to máš IMHO opravdu rozumnější zůstat u C++ a použít na stringy knihovnu...
Mimochodem, GraalVM je v tomhle celkem revoluční a unikátní.To se teprve uvidí... Já jsem k téhle interoperabilitě na úrovni kódu skeptický. Využivání API a datových struktur jednoho jazyka z jazyka jiného (třeba o dost) typicky znamená psát neidiomatickým stylem, řešit věci nestandardně / neintuitivně.
Interní reprezentace v paměti1 je jedna věc, ale to tě nemusí moc zajímat – z pohledu programátora je daleko důležitější, jaké API máš k dispozici. A v tomhle Java oproti C++ jasně vede.C++ je z hlediska podpory Unicode opravdu opravdu špatné, to asi nemusíme řešit. V Javě vidím ten problém v tom API, afaik to API stále používá datový typ
char a další atavismy. Můžu si případně někde přečíst, v čem se liší nové verze Javy? Mně by jako správné řešení připadalo úplně přestat používat datový typ char (je v podstatě úplně k ničemu, resp. leda jako 16-bit integer pro nějaké specielní účely) a např. vůbec neposkytovat ty funkce typu length vracející zavádějící číslo (počet UTF-16 jednotek). To ale asi nejde úplně udělat, protože zpětná kompatibilita. (Btw. stejný problém má Qt.)
Jestli chceš používat D kvůli stringům
Ono nejde jen o ty stringy, ale o spoustu různých otravných drobností. Třeba z tohoto taky nemám radost:
void execp(const std::vector<std::string>& args) {
const char** a = new const char*[args.size() + 1];
for (size_t i = 0; i < args.size(); i++) a[i] = args[i].c_str();
a[args.size()] = nullptr;
execvp(a[0], (char*const*) a);
delete[] a;
throw cli::RelpipeCLIException(L"Unable to do execvp().", cli::CLI::EXIT_CODE_UNEXPECTED_ERROR);
}
asi bych to měl nějak přepsat, ale strávil jsem teď nějakou dobu hledáním doporučených řešení a nic hezkého jsem nenašel. Zatím mi to funguje takhle.
ale zároveň jsi ochoten používat C++ ekosystém
Tam jde spíš o nějaké zajímavé knihovny, kterých je v C a C++ spousta, než o to, že by si do kódu člověk dobrovolně cpal věci z C++ (jazyk, standardní knihovna).
tak to máš IMHO opravdu rozumnější zůstat u C++ a použít na stringy knihovnu...
Přejít jinam se v zásadě nechystám – to C++ jsem si vybral kvůli rozšířenosti a zralosti (jediná závislost je pak GCC případně by to mělo chodit i v jiném kompilátoru) a pořád je to o dost lepší než C. A pro ty Relační roury jsem si C++ vybral i navzdory tomu, že jako jazyk mi přijde horší než Rust nebo D.
Ale kdybych v tom měl psát něco velkého (informační systém atd. – i když ten bych asi psal spíš v Javě), tak by to chtělo vychytat buď knihovny (Qt možná dost z toho řeší, případně Boost) nebo by možná převážily výhody toho D nebo Rustu (i když tam je otázka, jak snadno by šlo napojovat knihovny z C/C++ a jaké by byly potřeba).
U malého jednoduchého programu bych si rád vystačil se standardní knihovnou. Což tedy v tom C++ jde, i když si u toho občas zanadávám :-) Jediné, co mi vyloženě nešlo, bylo zjišťování šířky znaku (při tisku na terminál – obrázkové písmo, některé emoji, rozbije výstup)… myslím, že jsem tu o tom už psal – a tohle asi v rámci standardní knihovny nemá řešení.
To se teprve uvidí... Já jsem k téhle interoperabilitě na úrovni kódu skeptický. Využivání API a datových struktur jednoho jazyka z jazyka jiného (třeba o dost) typicky znamená psát neidiomatickým stylem, řešit věci nestandardně / neintuitivně.
Já z toho mám trochu rozporuplné pocity, ale asi z jiného důvodu. Za svůj život už jsem viděl tolik rozbitých, děravých a spadlých programů, že mě to táhne spíš k tomu, abych rozdělil systém na více menších komponent, samostatných procesů a trochu víc to izoloval (třeba i pod jiné uživatelské účty nebo bezpečnostní kontexty), než aby to běželo všechno v jednom. Na druhou stranu je fascinující, že jde napsat program, kde část funkcí je v Pythonu, část v Javě a jiná třeba v Ruby a je to v podstatě jako kdybys volal metody na objektu ve svém jazyce. Kdybych to neviděl naživo, tak bych asi nechtěl věřit, že něco takového může existovat :-)
Můžu si případně někde přečíst, v čem se liší nové verze Javy?JEP 254, baeldung.com, dzone.com
a např. vůbec neposkytovat ty funkce typu length vracející zavádějící číslo
Jde o to ujasnit si terminologii a aby se ta čísla správně interpretovala. Dneska text už bohužel není jen text a trochu se to zvrhlo, ale co se dá dělat. Délka může být: a) počet bajtů b) počet znaků (jako jakýchsi atomických jednotek písma), c) počet políček, které to zabírá při vytištění. Nejsem moc nadšený z toho, že c) vůbec existuje resp. že může být různé od b). Asi1 je to nutné kvůli nějakým východním písmům, ale nabourává to spoustu věcí. Nějaké barevné obrázky jsou pak kapitola sama pro sebe, to podle mého do textu vůbec nepatří. Nicméně ať už na to má člověk názor jakýkoli, tyhle věci nepocházejí od autorů programovacích jazyků – ti se s novinkami musí nějak poprat a skloubit to se zpětnou kompatibilitou.
[1] i když: fakt by nemohlo platit, že jeden znak zabírá jedno políčko? Vždyť takové m a i jsou taky různě široké, ale jsme je schopní dát pod sebe se stejnou šířkou.
asi bych to měl nějak přepsat, ale strávil jsem teď nějakou dobu hledáním doporučených řešení a nic hezkého jsem nenašel. Zatím mi to funguje takhle.Mohl bys použít nějakou transformaci vectoru, např. jako je uvedená v tom Example tady (mam na mysli hlavně to druhé volání
transform()).
Jediné, co mi vyloženě nešlo, bylo zjišťování šířky znaku (při tisku na terminál – obrázkové písmo, některé emoji, rozbije výstup)… myslím, že jsem tu o tom už psal – a tohle asi v rámci standardní knihovny nemá řešení.Huh? To by neměl být problém. Emulátory termiálu to interně běžně řeší, včetně třeba Konsole (i když tam to mají zmršené právě kvůli UTF-16 v Qt). Vygoogluj si
wcwidth() a nějakej kód určitě najdeš...
Mimochodem, problém jsou nejen fullwidth znaky a emotikony, ale taky znaky s nulovou šířkou (diakritika atd.).
Jde o to ujasnit si terminologii a aby se ta čísla správně interpretovala. Dneska text už bohužel není jen text a trochu se to zvrhlo, ale co se dá dělat. Délka může být: a) počet bajtů b) počet znaků (jako jakýchsi atomických jednotek písma), c) počet políček, které to zabírá při vytištění.Fór je v tom, že String length v Javě, JS a Qt není ani jedno z toho. Nejblíže to má asi tomu počtu bajtů (je to polovina počtu bajtů, pokud nejsou použity ty Compact Strings), ale v zásadě je to víceméně náhodné číslo pocházející z implementačního detailu, které může a nemusí odpovídat počtu znaků. A není to vina emotikon, bylo to takhle už před nimi. Jinak v kontextu Unicode stringů je délka stringu dobře definovaná: Počet Unicode code points.
Jediné, co mi vyloženě nešlo, bylo zjišťování šířky znaku (při tisku na terminál – obrázkové písmo, některé emoji, rozbije výstup)… myslím, že jsem tu o tom už psal – a tohle asi v rámci standardní knihovny nemá řešení.Huh? To by neměl být problém. Emulátory termiálu to interně běžně řeší, včetně třeba Konsole (i když tam to mají zmršené právě kvůli UTF-16 v Qt). Vygoogluj si wcwidth() a nějakej kód určitě najdeš...
Díky, to wcwidth() pomohlo (aspoň v Konsoli to teď vypadá zarovnané správně, i když v Kate nebo Firefoxu to není ono – nicméně je to výstup určený pro terminál).
Když jsme se o tom bavili minule, tak to vypadalo, že bude potřeba nějaká knihovna, což se mi nechtělo do toho zatahovat. Ale i to wcwidth() ze standardní knihovny dost pomohlo (nicméně třeba ten soubor, který jsi tehdy posílal, to rozbíjí pořád).
aby mel programator predstavu, jak kod a data bude mapovan na hardware. (I kdyz dnes je to spis iluze.)V případě jednočipů to až taková iluze není a C je tam nenahraditelné. Například pokud máš jen 0.5 KB paměti a potřebuješ precizně generovat signál pomocí hardwarové PWM a ještě ten signál v reálném čase interpolovat ze vstupních dat, tak je každých pár instrukcí znát, neboť výpočty musí být synchronizovány s během PWM a s generovanými přerušeními. Na to nic lepšího než C prostě není. Ta kombinace předvídatelnosti a srozumitelnosti je opravdu unikátní a nenahraditelná.
V případě jednočipů to až taková iluze není a C je tam nenahraditelnéTomu rozumim. Narazel jsem spis na toto.
27.4.2019 19:24
xxx | skóre: 42
| blog: Na Kafíčko
kde sice delas nejaky pojebany trivalni veci, ale vzhledem k tomu jak je to obaleny zmrdikecama (si precti neco od treba od Stopky tady), tak se za to plati vic.Toto je priserna poza. Kdyz clovek dela na systemove urovni v C, tak vetsina neprijemnosti plyne z toho, ze programuje proti hardware, do ktere ho neni poradne videt a malokdo ho chape jako celek; a dokumentace, kdyz vubec je, obsahuje chyby. Kdyz clovek dela na enterprise urovni v Jave, tak vetsina neprijemnosti plyne z toho, ze programuje proti systemu, do ktere ho neni poradne videt a malokdo ho chape jako celek; a dokumentace, kdyz vubec je, obsahuje chyby. Je jen na tobe, ktere zlo si vyberes. Ale vybirej opatrne, aby sis nevybral jeste vetsi zlo...
27.4.2019 19:46
xxx | skóre: 42
| blog: Na Kafíčko
25.4.2019 01:49
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
25.4.2019 06:52
xsubway | skóre: 13
| blog: litera_scripta_manet
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.