Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »#ifndef XDBOBJECT_H #define XDBOBJECT_H template< class T> inline T &XObject(void *ptr) { return **(T **) ((char *) ptr + sizeof(void *)); } template< class T> inline const T &XObject(const void *ptr) { return **(T **) ((const char *) ptr + sizeof(void *)); } #endif // XDBOBJECT_H
Tiskni
Sdílej:
Lol...
#endif XDBOBJECT_H
Některé starší kompilátory (a nejspíš MSVC stále) tohle berou jako legitimní, zatímco třeba novější GCC řve, že se mu to vůbec nelíbí.
private
a nespoleha se na defaultni viditelnost tak se to da celkem snadno resit pomoci:
#define private public #include "x.h"
#define class structv implicitnim pripade, fuj:)
class
misto typename
, tak zmena na struct
nebude fungovat.
A i kdyz dusledne pouziva typename
, tak treba v tomhle pripade se class
nevyhne:
template<template<typename T> class U> struct X { };
A ano, jazyk by měl programátory kontrolovatTo ano (kontrolovat ve smyslu pomahat).
a rozumně omezovat. Patří to do popisu práce programovacích jazyků.To ani nahodou - jeste jsem nevidel problem z realneho sveta programovani (kde je neomezene casove okno), ktery by sel resit pri zachovani omezovani jazykem (tedy bez ruznych hacku).
V čem jazyk programátorovi pomáhá, když nedokáže vynutit ani private?Prave tim nevynucovanim
On Vám někdo brání psát programy bez jediného slova private?Mne ne, ale dost casto se pouziti techto ficur jazyka uci uplne spatne a s vysledky se myslim setkavate i Vy. Tvurci jazyku se temi ficurami chlubi, povazuji tyhle "zbytecnosti" za must-have atd. Zacinajici programatori tedy nabudou dojmu, ze pouziti techto ficur je neco spravneho, ba dokonce bezpodminecneho a narvou to pak vsude -> fail. Btw co se praseni tyce, uz jsme videl nekolik ekvivalentnich programu nebo dokonce primo prepisu z jednodussich jazyku (napr. Python) do tech slozitejsich (napr. C++) a mira praseni byla v obou stejna - troufam si tedy tvrdit, ze na praseni tyto omezujici vlastnosti jazyka nemaji vliv (nebo opravdu margialni).
Pak je to ovšem chyba učitelů a chyba programátorů, že něco špatně používají.Nesouhlasim, protoze pokud je nekde neco navic, tak je to z meho pohledu zbytecne.
Zkuste špatně používat kyanid draselný, nebo methyalkohol či se koupat v kyselině sírové a uvidíte, že příroda a realita je plná featur, které příroda dokáže velmi drsně vynucovat. A hacky moc nepomáhají.Toto neni vynucovani, ale presne to co pozaduji. Tedy aby me jazyk neomezoval (priroda mi dovoli nevhodne pouzivat vami uvedene latky).
Možná byste se měl dívat na kódy mistrů a lidí, kteří umí programovat. A to pokud možno i v cílovém jazyku, do kterého přepisují.Vetsinou mi to neni doprano - asi sedim v realnem svete a ne v izolovane soustave mezi dvema borci, kteri si tresou spolecne rukou jaky krasny jazyk si sami pro sebe vytvorili.
Podívejte, já Vám tento příspěvek přeložím do angličtiny nebo francouzštiny, případně němčiny – ale všechny tři překlady nebudou za mnoho stát. Říká to něco o tom, jak kvalitní vyjadřovací schopnost má angličtina, němčina nebo francouzština? Ani náhodou.Domnivam se, ze u programovaciho jazyka vubec nezalezi na jeho vyjadrovacich schopnostech at uz jsou jakekoliv, ale na jeho realne pouzitelnosti (tuto vsak zrejme definuji jinak nez Vy).
Jazyk Vás neomezuje. Jazyk Vám dovolí nepoužívat klíčové slovo private. Nechápu, na co si stěžujete?Jazyk umi zbytecnost -> programator ji zbytecne pouziva -> ja z toho mam problem, ktery musim resit -> jsem omezovan jazykem (protoze ten problem musim resit v tom jazyku, kde to je nejake hnusne hackovani)
I já sedám v reálném světě. A věřte, že v reálném světě jsou mistři (vedle dalších lidí). Existují mistrovští houslisté, mistrovští programátoři, atd. pro všechny obory.Prirovnanim z realneho non-IT sveta bych se v pripade IT vyhnul. V tomto pripade je mylne proto, ze kod tu s nami je nezmeneny mnoho let a meni se pouze pozadavky (kde pozadavek neni subjektivniho charakteru), kdezto na dobre zahraneho Bacha nebo na dobre repovanou skladbu se pozadavky opravdu nemeni! Podstatnych rozdilu by se samozrejme naslo vice...
Jako vata je tento odstavec dobrý. Jinak v něm nevidím jediný argument k tématu.Tedy znovu - jazyk s malym poctem omezeni je realne mnohem pouzitelnejsi nez jazyk s vetsim poctem omezeni.
Škoda, že na kernelu neprogramuje pavlix a dumblog, protože ti jsou tak chytří, že jako programátoři by si ohlídali, že chyba by ani nevznikla, natož aby tam byla několik let.Za pavlixe mluvit nemuzu, ale osobne jsem uz do kernelu hrabnul a hodlam v tom pokracovat (zatim to neni ve vanilce, ale delam na tom). Takze se teste, bude v nem mnohem vice chyb, ktere se budou hledat radu let.
Obvykle se delší programy déle ladí, debugují a testují, než píší.Což podtrhnuje můj výše uvedený názor, že je dobré mit k testování a ladění co nejlepší prostředky a nemuset kvůli tomu vymýšlet nějaké speciální hacky. Popravdě řečeno mám pocit, že mé komentáře čteš pozpátku nebo vzůru nohama, jinak bys z nich těžko mohl odvodit téměř přesný opak toho, co se v nich píše.
Možná se budete divit, ale třeba v Linux kernelu se našly chyby, které tam byly řadu let. Těžko můžete podceňovat programátory kernelu, že programují špatně. Škoda, že na kernelu neprogramuje pavlix a dumblog, protože ti jsou tak chytří, že jako programátoři by si ohlídali, že chyba by ani nevznikla, natož aby tam byla několik let.Zajímavé větné konstrukce. V oblasti sítí jsem několik takových chyb hlásil a další čekají, až budu mít čas je pořádně ověřit. Důkazů, že (někteří) programátoři kernelu (někdy) programují špatně a výsledky jejich práce se dostanou do upstreamu, je v tom síťovém kódu víc než dost. A nejedná se zdaleka jen o nějaká přehlédnutí, jsou to i zásadní návrhové chyby. Ale to je na dlouhé povídání a s aplikačním programováním, kde se běžně používají cizí knihovny, to nemá nic moc společného.
Pokud je třeba přistupovat k privátním atributům v C++, jedná se o špatný návrh interface či API a někdo to nenavrhl dobře.Ano. Ale co dělat, když už se dostanu před takový kód?
struct ShadowAStruct { void** virtual_function_table; ...je 100x vetsi prasarna nez vypnuti private (napr. pomoci #define). Pri zmenach v ty knihone bych musel presne synchronizovat i tuhle strukturu. A pravdepodobnost ze nekde pribude promenna a cely se to posune je mnohem vetsi nez pravdepodobnost nejaky zasadni zmeny kvuli ktery se zmeni funkce toho private atributu. Navic kdyz to prelozim jinym prekladacem tak se to muze cely rozsipat...
1) Nejčistější je nemít private tam, kde k tomu chcete přistupovat zvenčí.Jak tohle pomuze nekomu kdo se dostane ke kodu kde uz private je? Treba autor blogu.
2) Pokud k tomu chcete přistupovat zvenčí, a je tam private, pak existuje jakž takž čisté klíčové slovo friend, kterým udělíte práva na přístup k private jen tam, kde je to třeba.jo a kdyby bylo mozne deklarovat friend i mimo tridu tak by to dost resilo.
3) Jestli si myslíte, že jakýkoli hackovací kód se nemusí znovu zkontrolovat při změnách knihovny, tedy i ten, který popisuje autor v článku, pak nemám slov.uz zase si domejslis neco co ostatni nerekli...
4) Jakýkoli hackovací kód přeložený jiným překladačem může fungovat jinak, i ten co napsal autor článku.Jak me muze prosta zmena private na public zpusobit ze to nekde bude fungovat a jinde ne? Prosil bych o konkretni priklad.
5) Vypnutí private pomocí #define nevypíná globálně private. Už jen proto, že private je výchozí stav pro class. Tedy private jsou i věci, které nemají klíčové slovo private.to sam zminuju uz v prvnim prispevku...
jo a kdyby bylo mozne deklarovat friend i mimo tridu tak by to dost resilo.Tedka jak chteji zrychlit vydavani novych specifikaci C++, tak se mozna dozijeme toho, ze tam budou nastroje na omezovani a zaroven nastroje na ruseni techto omezeni (a tyto budou mit zase nejaka omezeni...)
Potřeboval jsem se dostat k private věcem a úpravou .h bych porušil licenci.Heh, to bych z toho nevyčetl. Přibližně jsem pochopil co to dělá, ale ušel mi smysl :)