Vývojáři OpenMW (Wikipedie) oznámili vydání verze 0.50.0 této svobodné implementace enginu pro hru The Elder Scrolls III: Morrowind. Přehled novinek i s náhledy obrazovek v oznámení o vydání.
Komunita kolem Linux Containers po roce vývoje představila (YouTube) neměnný operační systém IncusOS speciálně navržený pro běh Incusu, tj. komunitního forku nástroje pro správu kontejnerů LXD. IncusOS poskytuje atomické aktualizace prostřednictvím mechanismu A/B aktualizací s využitím samostatných oddílů a vynucuje zabezpečení bootování pomocí UEFI Secure Bootu a modulu TPM 2.0. Postaven je na Debianu 13.
Mozilla začne od ledna poskytovat komerční podporu Firefoxu pro firmy. Jedná se o podporu nad rámec stávající podpory, která je k dispozici pro všechny zdarma.
V Bolzanu probíhá konference SFSCON (South Tyrol Free Software Conference). Jean-Baptiste Kempf, zakladatel a prezident VideoLAN a klíčový vývojář VLC media playeru, byl na ní oceněn cenou European SFS Award 2025 udělovanou Free Software Foundation Europe (FSFE) a Linux User Group Bolzano‑Bozen (LUGBZ).
Open-source minimalistický trackball Ploopy Nano byl po modelech modelech Classic a Thumb Trackball také aktualizován. Nová verze Nano 2 používá optický senzor PAW3222 a k původně beztlačítkovému designu přidává jedno tlačítko, které ve výchozí konfiguraci firmwaru QMK přepíná režim posouvání koulí. Sestavený trackball nyní vyjde na 60 kanadských dolarů (bez dopravy a DPH).
Github publikoval Octoverse 2025 (YouTube), tj. každoroční přehled o stavu open source a veřejných softwarových projektů na GitHubu. Každou sekundu se připojil více než jeden nový vývojář. Nejpoužívanějším programovacím jazykem se stal TypeScript.
Kit je nový maskot webového prohlížeče Firefox.
Mastodon (Wikipedie) - sociální síť, která není na prodej - byl vydán ve verzi 4.5. Přehled novinek s náhledy v oznámení na blogu.
Německo zvažuje, že zaplatí místním telekomunikačním operátorům včetně Deutsche Telekom, aby nahradili zařízení od čínské firmy Huawei. Náklady na výměnu by mohly přesáhnout dvě miliardy eur (bezmála 49 miliard Kč). Jeden scénář počítá s tím, že vláda na tento záměr použije prostředky určené na obranu či infrastrukturu.
Po dvaceti letech skončil leader japonské SUMO (SUpport.MOzilla.org) komunity Marsf. Důvodem bylo nasazení sumobota, který nedodržuje nastavené postupy a hrubě zasahuje do překladů i archivů. Marsf zároveň zakázal použití svých příspěvků a dat k učení sumobota a AI a požádal o vyřazení svých dat ze všech učebních dat.
class Hrac
{
private:
QString * jmeno;
QColor * barva;
int * znak;
int * body;
public:
Hrac();
Hrac(const Hrac &other);
~Hrac();
void nastavVlastnosti(QString jmeno, QColor barva, int znak, int body);
int * zjistiZnak();
int * zjistiBody();
QColor * zjistiBarvu();
QString * zjistiJmeno();
TypHrace * zjistiTyp();
bool checkForVictory();
friend QDataStream &operator<<(QDataStream &out, Hrac &hrac);
void serialize(QDataStream& ost);
static Hrac unserialize(QDataStream& istr);
};
Řešení dotazu:
serialize a unserialize, definice třídy se zdá v pořádku
QDataStream& operator <<(QDataStream &out, Hrac &hrac) nemusí být friend, protože použije (měl by použít ) veřejnou metodu serialize
unserialize by mělo vracet Hrac*, jinak se tam bude volat (zbytečně) copy konstruktor. Lepší by ale bylo vytvořit deserializační konstruktor explicit Hrac(QDataStream &str)
Btw. proč jsou tam ty dva inty (znak a body) dynamicky alokované?
QDataStream &operator<<(QDataStream &out, Hrac &hrac)
{
return(out << hrac.jmeno->length()<< " " << hrac.jmeno->toAscii() << " " << hrac.barva << " " << hrac.znak << " " << hrac.body);
}
void Hrac::serialize(QDataStream &ost)
{
ost << this;
}
Hrac Hrac::unserialize(QDataStream &istr)
{
Hrac tmp;
int delkajmena;
QString jmeno;
QColor barva;
int znak;
int body;
istr >> delkajmena;
//istr.readBytes() //?
tmp.nastavVlastnosti(jmeno,barva,znak,body);
return tmp;
}
Tu deserializaci udělám pomocí toho kontruktoru, takové řešení mě nenapadlo, díky.
Dynamickou alokaci tam používám pro všechny objekty uvnitř tříd, neměl by v tom být žádný rozdíl ne?
Kdyby vás zajímal ještě nějaký kus kódu, tak to celé mám na SVN pod
http://code.google.com/p/pisqorky/source/browse/trunk#trunk/src .
Dynamickou alokaci tam používám pro všechny objekty uvnitř tříd, neměl by v tom být žádný rozdíl ne?I kdyby to byla pravda, tak proč se v takovym případě namáhat?
void Hrac::serialize(QDataStream &str)
{
str << *this->jmeno << *this->barva << *this->znak << *this->body;
}
void Hrac::unserialize(QDataStream &str)
{
str >> *this->jmeno >> *this->barva >> *this->znak >> *this->body;
}
resp. s konstruktorem:
Hrac::Hrac(QDataStream &str)
: jmeno(new QString())
, barva (new QColor())
, znak (new int(0))
, body (new int(0))
{
this->unserialize(str);
}
a pokud budou potřeba, tak přidat operátory
QDataStream& operator <<(QDataStream &str, Hrac &hrac)
{
hrac.serialize(str);
return str;
}
QDataStream& operator >>(QDataStream &str, Hrac &hrac)
{
hrac.unserialize(str);
return str;
}
Tiskni
Sdílej: