Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek i s náhledy aplikací v Týden v GNOME a Týden v KDE.
Organizace Apache Software Foundation (ASF) vydala verzi 20 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Desktopové prostředí Cinnamon, vyvíjené primárně pro distribuci Linux Mint, dospělo do verze 6.0. Seznam změn obsahuje především menší opravy a v říjnovém přehledu novinek v Mintu avizovanou experimentální podporu Waylandu.
OpenZFS (Wikipedie), tj. implementace souborového systému ZFS pro Linux a FreeBSD, byl vydán ve verzích 2.2.2 a 2.1.14. Přináší důležitou opravu chyby vedoucí k možnému poškození dat.
V ownCloudu byly nalezeny tři kritické zranitelnosti: CVE-2023-49103, CVE-2023-49104 a CVE-2023-49105 s CVSS 10.0, 8.7 a 9.8. Zranitelnost CVE-2023-49103 je právě využívána útočníky. Nextcloudu se zranitelnosti netýkají.
I letos vychází řada ajťáckých adventních kalendářů. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2023. Pro programátory v Perlu je určen Perl Advent Calendar 2023. Zájemci o UX mohou sledovat Lean UXmas 2023. Pro zájemce o kybernetickou bezpečnost je určen Advent of Cyber 2023…
Byla vydána verze 2.12 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 23.11 Topi. Přehled novinek v Changelogu.
Po 4 měsících vývoje byla vydána nová verze 4.2 multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu a na YouTube.
Byla vydána nová stabilní verze 23.11 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Tapir. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
virtual int read(struktura1 *data)=0;
virtual int write(struktura1 *data)=0;
virtual int read(struktura2 *data)=0;
virtual int write(struktura2 *data)=0;
Tento interface pak je konkrétně implementován pro xml a modbus.
Dále mám třídu readWriteFactory, která má metodu
ReadWrite* ReadWriteFactory::chooseRWType(int type)
{
ReadWrite *ret;
switch(type)
{
case 1:
ret = new ReadWriteModbus();
return ret;
break;
default :
ret = new ReadWriteXML();
return ret;
break;
}
}
tímhle si vytvořím instanci konkrétní třídy pro komunikaci, která splňuje interface a pak v programu neřeším, jakým způsobem data získávám. Instanci třídy si takhle vytvářim všude kde jí potřebuju - v každym widgetu, kterj potřebuje načítat nebo ukládat data. Dál pak používám jen rw->read(&data)
kde data je struktura, kterou chci naplnit daty.
Modbus na rozdíl od xml souborů potřebuje navázat spojení a udržovat někde identifikátor toho spojení. To je řešeno tím, že po spuštění aplikace se zjistí, jaký je nastavený typ spojení, pokud je to modbus, tak se zavolá funkce, která to spojí a identifikátor se uloží do globální proměnné. Pokaždký když pak volám rw->read pro modbus, tak se identifikátor spojení načte z globální proměnné. Vím, že to je navrženo špatně a chci to zlepšit. Dlouho jsem to chtěl předělat, ale dělal sem věci, které byly někde vidět a na tohle se nedostalo.
Teď potřebuju aplikaci rozdělit do knihoven - datalogic a businesslogic budou v čistém C++ jako knihovny a v aplikaci zbude GUI v Qt. Problém je s používáním globálních proměnných.
Už si s tím lámu docela dlouho hlavu, ale moc mi to nejde. Vymyslel jsem, že interface změním na
virtual int read(struktura1 *data,connectionClass identifikator)=0;
virtual int write(struktura1 *data,connectionClass identifikator)=0;
virtual int read(struktura2 *data,connectionClass identifikator)=0;
virtual int write(struktura2 *data,connectionClass identifikator)=0;
Kde třída identifikator bude uchovávat informace o typu připojení a identifikátor spojení, pokud existuje. Mám představu, že vytvořím instanci třídy connectionClass na začátku programu nebo při manuálním spojení a tu pak budu předávat rw->read(&data,id)
.
A teď jedna z věcí, která mi v OOP pořád nejde na rozum - jak mam předávat id? rw->read bude volaná někde úplně z nejnižšího QtWidgetu, kterej nad sebou má další 3 parent widgety - jak tam to id dostanu? Nejjednoduší by bylo udělat id nějakym způsobem globální, ale všude píšou, že to je špatně, že to neni thread safe a další věci.
Je takhle navržená struktura správná? Jak mam správně předávat id?
Doufám, že to je popsaný srozumitelně a nic sem nevynechal. Díky.
Řešení dotazu:
read()
nebo write()
je samozřejmě veskrze špatným řešením. Nejen z důvodu neefektivnosti, ale především z pohledu návrhu.
C++ jsem už bohužel hodně let neviděl, ale nejspíše bych to přepsal takto (záměrně vypuštěna členská funkce write()
):
Struktury:
typedef struct Data {} Data; typedef struct Data2 {} Data2;Třída pro zapouzdření případných kontextových dat:
class Context { private: int sourceType; ModbusConnection* modbusConn; public: Context() : sourceType(0), modbusConn(0) {} int getSourceType(); void setSourceType(int type); ModbusConnection* getModbusConnection(); void setModbusConnection(ModbusConnection* conn); };Připojení k modbus:
class ModbusConnection { public: ~ModbusConnection(); };Rozhraní pro čtení:
class Reader { public: virtual ~Reader() {} virtual int read(Data& data) = 0; virtual int read(Data2& data) = 0; };Třídy implementující čtení:
class ModbusReader : public Reader { private: ModbusConnection* conn; public: ModbusReader(ModbusConnection* connection) : conn(connection) {} int read(Data& data); int read(Data2& data); };
class XMLReader : public Reader { public: int read(Data& data); int read(Data2& data); };Factory třída:
Reader* ReaderFactory::get(Context* context) { Reader *ret = 0; int type = context->getSourceType(); switch(type) { case 1: ret = new ModbusReader(context->getModbusConnection()); break; default : ret = new XMLReader(); } return ret; }A konečně pak to vše nějak zavoláme:
ModbusConnection modbus; Context context; context.setSourceType(1); context.setModbusConnection(&modbus); Reader *reader = ReaderFactory::get(&context); Data data; while (reader->read(data)) { // .... } delete(reader);
class MainClass
{
public: MainClass();
~MainClass();
}
MainClass()
{
odbusConnection modbus;
Context context;
context.setSourceType(1);
context.setModbusConnection(&modbus);
Reader *reader = ReaderFactory::get(&context);
obj = new Class1();
}
~MainClass()
{
delete(reader);
}
Class1()
{
obj = new Class2();
obj = new Class3();
}
Class2()
{
Data data;
reader->read(data);
}
Jediný, co mě napadá, je prostě to předávat v konstruktoru nějak takhle:
class Class1
{
public Class1(Reader *reader);
}
class Class2
{
public Class2(Reader *reader);
}
Class1(Reader *reader)
{
obj = new Class2(reader);
obj = new Class3(reader);
}
Class2(Reader *reader)
{
Data data;
reader->read(data);
}
Ale nevím, jestli to je takhle správně a nelíbí s mi to, protože musím udělat vlastní třídu Class1 a nemůžu použít standardní (jsou to widgety GUI).
Proč máš break za returnem?Možná proto aby uspokojil některé validátory - už jsem je tam kdysi dopisoval, bo mě štvaly warning-y.
break
dopsat (stejně jako třeba zbytečný zápis virtual ~InterfaceAsPureAbstractClass(){/* nothing to do */};
).NOW()- 2 years)
v Zatmění s C++ to nedělá…
Class Trida : public QMainWindow{
Q_OBJECT
public:
QWidget *novyWidget;
public slots:
void readData(Struktura* data);
void //tady budou sloty pro cteni a zapis vsech struktur a dalsi veci - connect, disconnect atd.
private:
ReadWrite *readWrite;
}
Trida::Trida(QWidget *parent) : QMainWindow(parent){
cnt = new Context();
cnt->set....
//tady naplnim obsah cnt z konfiguracniho souboru
//cnt uchovava informace pro vsechny spojeni - ip, port, modbus_identifikator_spojeni,
//umisteni_xml_souboru, jestli je to nekam aktkualne pripojeno a dalsi...
ReadWriteFactory *readWriteFactory = new ReadWriteFactory();
readWrite = readWriteFactory->sellect(cnt);//tohle mi vrati jeden konkretni typ spojeni
readWrite->setContext(cnt);
readWrite->connect(); //pripojim se - pro typy pripojeni, ktere nevyzaduji spojeni to neni potreba,
// ale nicemu to nevadi
novyWidget = new NovyWidget();
connect(novyWidget,SIGNAL(readData(Struktura*)),this,SLOT(readData(Struktura*)));
//pomoci signalu a slotu spojim pozadavaky na data se slotem, kterej je tady
//budu pridavat vic slotu - na cteni, zapis, disconnect, novej connect atd...
}
Trida::~Trida()
{
readWrite->disconnect();
delete ui;
}
void Trida::readData(Struktura* data)
{
readWrite->read(data);
}
Vlastni cteni dat se pak dela vyslanim signalu
Struktura *data;
data = new Struktura;
emit readData(data);
Všem díky moc za pomoc.
ReadWriteFactory *readWriteFactory = new ReadWriteFactory();
To druhý nevim jak, protože v potřebuju za běhu aplikace měnit typy připojení = mazat a vytvářet nový instance ReadWrite...
To mam do main přesunout jen vytváření factory a jako parametr konstruktoru předat instanci factory?Ano.
Nebo tam ma přesunout všechno - i naplnění context a vytvoření instance ReadWriteTo je práce pro tu factory.
To druhý nevim jak, protože v potřebuju za běhu aplikace měnit typy připojení = mazat a vytvářet nový instance ReadWrite...Takže si budeš hrát s factory, kterou dostaneš zvenčí (z main). Ono se mi tam trošku namíchaly dvě myšlenky, kdy první pocházela z doby než jsem si uvědomil, že asi nebudeš chtít pracovat jen nad jedním spojením.
Tiskni
Sdílej: