abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 17:00 | Nová verze

Simon Long představil na blogu Raspberry Pi novou verzi 2018-11-13 linuxové distribuce Raspbian určené především pro jednodeskové miniaturní počítače Raspberry Pi. Přehled novinek v poznámkách k vydání. Společně s Raspbianem byl aktualizován také instalační nástroj NOOBS (New Out Of the Box Software). Simon Long z novinek zdůrazňuje multimediální přehrávač VLC s hardwarovou akcelerací nebo vývojové prostředí pro Python Thonny ve verzi 3. Ke stažení jsou nově také lite a full obrazy Raspbianu. Raspbian Full opět obsahuje software Mathematica.

Ladislav Hagara | Komentářů: 0
včera 02:00 | Nová verze

Krátce po vydání Debianu 9.6 oznámil Tomáš Matějíček vydání verze 9.6 dnes již na Debianu založené živé linuxové distribuce Slax. Vedle vylepšení z Debianu je opraveno několik malých chyb. Opraveno bylo bootování pomocí PXE. Novinkou je skript s názvem pxe pro spuštění vlastního PXE serveru.

Ladislav Hagara | Komentářů: 1
včera 01:00 | Nová verze

Byla vydána beta verze Red Hat Enterprise Linuxu 8. Přehled novinek v příspěvku na blogu a v poznámkách k vydání.

Ladislav Hagara | Komentářů: 4
15.11. 13:44 | IT novinky

Nadace Raspberry Pi na svém blogu představila (YouTube) jednodeskový počítač Raspberry Pi 3 Model A+. Toto menší Raspberry Pi 3 lze koupit za 25 dolarů.

Ladislav Hagara | Komentářů: 0
15.11. 06:00 | Pozvánky

Dnes a zítra probíhá v Praze konference Internet a Technologie 18 pořádaná sdružením CZ.NIC. Sledovat ji lze online.

Ladislav Hagara | Komentářů: 1
15.11. 01:11 | Komunita

V září proběhl v Madridu Open Source CubeSat Workshop 2018. Videozáznamy přednášek byly zveřejněny na YouTube.

Ladislav Hagara | Komentářů: 1
15.11. 00:55 | Zajímavý software

Společnost Amazon představila Amazon Corretto. Jedná se o fork a distribuci OpenJDK (Open Java Development Kit) s dlouhodobou podporou od Amazonu. Ke stažení je preview verze 8. V plánu je také verze 11. Zdrojové kódy jsou k dispozici na GitHubu. Jedná se o reakci na oznámení společnosti Oracle, že bezplatné aktualizace její Javy nebude možné po lednu 2019 používat komerčně. Název Coretto vychází z Caffè corretto, tj. espressa s alkoholem.

Ladislav Hagara | Komentářů: 9
14.11. 12:44 | Nová verze

Po roce vývoje od vydání verze 5.2.0 byla vydána verze 5.3.0 svobodného integrovaného vývojového prostředí KDevelop (Wikipedie). Novinkou je analyzátor Clazy. Vylepšena byla podpora programovacích jazyků C++, PHP a Python. Ke stažení a k vyzkoušení je i binární balíček s KDevelopem 5.3.0 ve formátu AppImage.

Ladislav Hagara | Komentářů: 0
14.11. 05:55 | Komunita

Ubuntu 19.04 bude mít kódové jméno Disco Dingo. Dle oznámení v diskusním listu ubuntu-devel-announce je ve vývojové verzi Disco Dinga výchozím Pythonem 3 verze 3.7. Perl byl aktualizován na verzi 5.28. OpenSSL 1.0 bude nahrazeno OpenSSL 1.1.1 LTS. Nové instalace Dinga budou mít sloučený /usr. Stane se tak 7 let po sloučení /usr ve Fedoře nebo Arch Linuxu.

Ladislav Hagara | Komentářů: 9
14.11. 02:22 | IT novinky

V pondělí a úterý proběhl v San Franciscu Chrome Dev Summit 2018. Přehled dění v příspěvcích na Chromium Blogu. Videozáznamy přednášek na YouTube. Představen byl například web pro webové vývojáře web.dev nebo rozšíření webového prohlížeče Chrome s názvem VisBug (YouTube) určené pro webdesignery. Slíbená je podpora Firefoxu.

Ladislav Hagara | Komentářů: 0
Jak nejčastěji otevíráte dokumenty na počítači?
 (90%)
 (4%)
 (6%)
Celkem 105 hlasů
 Komentářů: 9, poslední 15.11. 22:46
Rozcestník

Dotaz: Rozšiřitelnost rozhraní a kompatibilita ABI v C++

xkucf03 avatar 10.9. 21:33 xkucf03 | skóre: 46 | blog: xkucf03
Rozšiřitelnost rozhraní a kompatibilita ABI v C++
Přečteno: 1582×
Máme rozhraní, které bude implementovat někdo cizí a my ho budeme volat (tzn. SPI). V tomto rozhraní je metoda, které předáváme nějaká data. Protože těch parametrů je víc, předáváme je ve formě objektu/struktury. V budoucnu můžou přibýt nová doplňková data, které implementátor rozhraní může ale nemusí využít (číst je). V dalších verzích mu tam dáme prostě něco navíc, co by se mu mohlo hodit. Přirozenou cestou by bylo přidat do této třídy/struktury nové členy či get metody. Tuhle třídu stejně nikdo nedědí (instance vytváříme vždy my a předáváme je tomu SPI), takže nehrozí kolize jmen.

Jak byste tohle řešili v C++?

Příklad SPI rozhraní:
class Hadler {
public:
	virtual void start(string_t name, std::vector<AttributeMetadata> attributes) = 0;
};
Třída, která by se měla postupně rozšiřovat:
class AttributeMetadata {
public:
	string_t attributeName;
	TypeId typeId;
	string_t typeName; // tohle např. přidáme až v další verzi
};
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net

Odpovědi

11.9. 08:16 Ivan
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
Hmm a co proste predat hash-mapu kde klicem bude string a hodnou neco jako Qvariant, std::variant, boost::variant ?
11.9. 09:36 MadCatX | skóre: 19 | blog: dev_urandom
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
Tohle je asi nejbezpečnější z hlediska skutečně flexibilního rozšiřování počtu parametrů. Bacha na to, že předávat přes boundary objekty STL knihovny je dost o držku - lepší by bylo použít nějakou vlastní implementaci hashmapy nebo tu STLkovou aspoň uzavřít do tebou kontrolovaného wrapperu.

C++ je z hlediska kompatibility API a ABI příšerně nešikovné, pokud bys třeba chtěl distribuovat knihovnu sestavenou kompilátorem A jako binárku a linkovat se vůči ní něčím zkopilovaným kompilátorem B, je situace ještě veselejší. Rozepsal bych se více ale mám dneska fakt narvaný den, snad večer, máš-li zájem...
11.9. 12:21 Franta
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
Jenže to je takové nešikovné, nesystematické pouzivat někde třídy/metody a jinde hashmapy, navíc tam pak nefunguje typová kontrola.

Nejradši bych mel něco jako v Javě final třídy, které si můžu rozsirovat, jak chci a je to bezpečné.

Ještě jsem uvažoval oddělit objekt nesoucí data a objekt/rozhraní zajišťující přístup k těmto datům. To první by byla nějaká ta hashmapa. A to druhé nějaká fasáda/pohled. Při čtení bych pak řekl: na tahle data chci koukat tímto pohledem... A ten by mi tahal patřičné hodnoty z mapy a zpristupnoval je objektově. V Javě bych tohle dal, ale v C++ se obavám, ze bych zase narazil na něco, co nebude kompatibilní (odkud vzít ten pohled?, jak říct, ze na tato data lze koukat těmito pohledy a jejich předky, kteří nabízejí podmnožinu funkci?). Navíc tím člověk vymýšlí vlastní objektový systém...

Praktické příklady a zkušenosti uvítám.
11.9. 13:57 karel
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
Jenže v javě ten objekt předáváš přes referenci. Tak jak to máš definované, ho předáváš hodnotou, takže přidáním dalších attributů si změníš jeho velikost a nebude ti teda sedět reprezentace toho objektu v paměti mezi novější a starší verzí. Oddělit data od rozhraní se dělá přes NVI, tím si "schováš" atributy do source souboru, takže zkompilovaná velikost objektu je vždycky stejná.

Pokud chceš udělat takto dynamické rozhraní, dali by se na to použít třeba "eclipse adaptéry". V kombinaci s NVI může ta tvoje vnitřní Impl struktura dědit ze všech interfaců. Metoda getAdapter potom bude šablona, která bude explicitně specializovaná jenom v source souboru. Tím vlastně budeš řídit, na které rozhraní se dokáže ta tvoje třída "přeměnit".

Jenom je to celé zbytečně složité, a pokud k tomu nemáš nějaký pádný důvod, tak bych se tomu asi snažil vyhnout.
11.9. 08:20 Ivan
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
V KDE to maji pekne definovane: https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
11.9. 12:38 Franta
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
Dík, na KDE jsem koukal, ale primo řešení tohoto problémů jsem tam nenašel.

Přijde mi, ze rozhraní se v C++ moc rozšiřovat nedají, nebo by člověk musel každou chvíli zvyšovat major verzi, aby tím řekl: nemusí to být kompatibilní, prekompilujte si to a otestujte.

Ma cenu vůbec usilovat o ABI kompatibilitu? Nebo říct, ze ABI kompatibilita je jen při zvýšení patch verze, zatímco při zvýšení minor verze být nemusí. A při zvýšení major verze to může být nekompatibilní i na úrovni zdrojaku/API?

Pak ale zase bude problém dostat do distribucí upgrade byť jen minor verze, protože by mohl rozbít ostatní balíčky. Leda dát verzi do názvu balíku a umožnit instalaci více verzí...

Pak jsem ještě četl o nějakém triku se jmennymi prostory... tam je šance, ze by se ABI napojovala na správnou starší verzi a při kompilaci se to napojilo na nejnovější?
11.9. 12:45 luky
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
Na jazyce nezavisle reseni je pouzit verzovani symbolu - v jedne knihovne muze byt nekolik rozdilnych verzi jednoho rozhrani. Pouzite rozhrani se voli pri kompilaci uzivatele rozhrani. Popsano to je v dokumentaci ld/gcc.
xkucf03 avatar 12.9. 19:09 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++

Ještě doplním kontext. Mám rozhraní:

class RelationalReader {
public:
    virtual ~RelationalReader() = default;
    virtual void addHandler(handlers::RelationalReaderStringHadler* handler) = 0;
    virtual void addHandler(handlers::RelationalReaderValueHadler* handler) = 0;
    virtual void process() = 0;
};

Jeho instance si uživatel vytváří přes tovární metodu:

class Factory {
public:
    static RelationalReader* create(std::istream &input);
};

Když chce zpracovat vstupní proud dat, napíše si vlastní Handlery, zavolá jednou nebo víckrát addHandler() a potom process() (v rámci této metody se pak provolávají všechny zaregistrované Handlery).

class RelationalReaderBaseHadler {
public:
    virtual ~RelationalReaderBaseHadler() = default;
    virtual void startRelation(string_t name, std::vector<AttributeMetadata> attributes) = 0;
    virtual void endOfPipe() = 0;
};

Rozšiřovat by se časem mohlo to AttributeMetadata a taky by mohly přibýt další druhy Handlerů (což znamená přidat nové druhy addHandler() a rozšířit tak rozhraní Readeru).

Napadlo mne, že bych pak mohl přidat novou třídu RelationalReader2 a novou tovární metodu, která by její instance vracela. A tato nová třída RelationalReader2 by mohla podporovat nové verze Handlerů a ty nové verze Metadat.

To by mělo fungovat, ne? Akorát mi trochu vadí, že i kvůli drobnému rozšíření Metadat je potřeba přidat několik dalších tříd resp. verzí rozhraní. Asi by to mohla být pořád jedna implementační třída, která by podporovala rozhraní všech verzí. Je tohle správná cesta? Nebo vás napadá nějaké jednodušší elegantnější řešení?

Když už by se verzovaly třídy, je lepší dávat verzi do jejich názvu nebo do jmenného prostoru? Spíš mi přijde, že do prostoru. A dělá se spíš namespace reader1 { nebo namespace reader { namespace v1 {? A přes inline namespace by to mělo být napojené do neverzovaného prostoru, který by ukazoval na poslední verzi?

Některé knihovny mají verzované jen adresáře s hlavičkovými soubory, ale třídy a jmenné prostory už ne, např.

#include <botan-1.10/botan/bcrypt.h>

P.S. Nemáte odkaz na nějakou knihovnu, ve které je podle vás tohle dokonale vyřešené? Nechci vymýšlet kolo, ale na druhou stranu, co jsem zatím našel, byly dost velké projekty se spoustou kódu a poměrně složitým build systémem.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
13.9. 11:57 luky
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
inline namespacy se pouzivaji takto:
namespace my_lib {
#ifdef MY_LIB_V1
inline
#endif
namespace my_lib_v1 { ... }
#ifdef MY_LIB_V2
inline
#endif
namespace my_lib_v2 { ... }
}
A definovanim bud MY_LIB_V1 nebo MY_LIB_V2 se pri prekladu vybere verze.

13.9. 12:19 Radek Isa | skóre: 12
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
A nešlo by prostě udělat havičkový soubor rozhraní.h a využít dědičnost? Class A{ // jejich struktura použitá v rozhraní
protected:
int a;
int b;
}

Class B : public A { //vaše struktura použivá v programu
protected:
int nova_promena;
int nova_promena_2;
}

Třída B bude obsahovat všechny prvky a metody třídy A. Případně by bylo potřeba ještě dodefinovat přetypování ve třídě B na třídu A. A vše by mělo fungovat. Dlouho jsem nepsal nic v C++.
int lib_method(A param){
....
}

int main(){
B prom = new();
int b = lib_method(prom)
}
pokud by jsi něco potřeboval přenést do objektu A, tak by jsi to tam jenom přesunul z oběktu B. Nakonec by jsi musel překompilovat veškeré zdrojové soubory. Vždy když změníš rozhraní musíš knihovnu i program překompilovat. Pokud by jsi nechtěl překompilovaávat programy při změně strukturytrídy A, pak je nutné předávat proměnou pomocí ukazatele. A ke všemu přistupovat pomocí knihovních funkcí. A * lib_new(){
...
}

int lib_method(A * param){
...
}
13.9. 12:20 Radek Isa | skóre: 12
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
A nešlo by prostě udělat havičkový soubor rozhraní.h a využít dědičnost? Class A{ // jejich struktura použitá v rozhraní
protected:
int a;
int b;
}

Class B : public A { //vaše struktura použivá v programu
protected:
int nova_promena;
int nova_promena_2;
}

Třída B bude obsahovat všechny prvky a metody třídy A. Případně by bylo potřeba ještě dodefinovat přetypování ve třídě B na třídu A. A vše by mělo fungovat. Dlouho jsem nepsal nic v C++.
int lib_method(A param){
....
}

int main(){
B prom = new();
int b = lib_method(prom)
}
pokud by jsi něco potřeboval přenést do objektu A, tak by jsi to tam jenom přesunul z oběktu B. Nakonec by jsi musel překompilovat veškeré zdrojové soubory. Vždy když změníš rozhraní musíš knihovnu i program překompilovat. Pokud by jsi nechtěl překompilovaávat programy při změně strukturytrídy A, pak je nutné předávat proměnou pomocí ukazatele. A ke všemu přistupovat pomocí knihovních funkcí. A * lib_new(){
...
}

int lib_method(A * param){
...
}
13.9. 15:53 MadCatX
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
Napadlo mě, že pro tvé potřeby by ti nejspíš stačil koncept d-pointeru. Princip je ten, že ven exportuješ objekt, který bude mít vždy stejnou velikost bez ohledu na to, jaká data bude poskytovat. Data samotná budou obsažená v interní struktuře, na kterou bude exportovaný objekt obsahovat pointer - tím se zaručí ta neměnná velikost. Do exportovaného objektu můžeš přidávat gettery a settery pro všechny atributy. Příklad následuje:
public_api.h
#ifndef PUBLIC_API_H
#define PUBLIC_API_H

#include <string>

#define ATTRIBUTES_API_VERSION 3

class AttributesPrivate;

class Attributes {
public:
	~Attributes();

	int a() const;
	int b() const;
	bool c() const;
	std::string s() const;
	std::string s2() const;

	void setA(int a);
	void setB(int b);
	void setC(bool c);
	void setS(const std::string &s);
	void setS2(const std::string &s2);

	static Attributes make()
	{
		return Attributes(ATTRIBUTES_API_VERSION);
	}

private:
	Attributes(int32_t apiVer);

	int32_t API_VERSION;
	AttributesPrivate *m_d;
};

#endif // PUBLIC_API_H
private_api.h
#ifndef PRIVATE_API_H
#define PRIVATE_API_H

#include "public_api.h"

class AttributesPrivate {
public:
	/* V1 API */
	int a;
	int b;
	bool c;

	/* Added in V2 API */
	std::string s;

	/* Added in V3 API */
	std::string s2;
};

#endif // PRIVATE_API_H
library.cpp
#include "private_api.h"

Attributes::Attributes(int32_t apiVer) :
	API_VERSION(apiVer),
	m_d(new AttributesPrivate{})
{
}

Attributes::~Attributes()
{
	delete m_d;
}

int Attributes::a() const
{
	return m_d->a;
}

int Attributes::b() const
{
	return m_d->b;
}

bool Attributes::c() const
{
	return m_d->c;
}

std::string Attributes::s() const
{
	return m_d->s;
}

std::string Attributes::s2() const
{
	return m_d->s2;
}

void Attributes::setA(int a)
{
	m_d->a = a;
}

void Attributes::setB(int b)
{
	m_d->b = b;
}

void Attributes::setC(bool c)
{
	m_d->c = c;
}

void Attributes::setS(const std::string &s)
{
	m_d->s = s;
}

void Attributes::setS2(const std::string &s2)
{
	m_d->s2 = s2;
}
Privátní konstruktor Attributes a statická factory metoda make implementovaní ve veřejném headeru umožňuje knihovně rozpoznat, vůči jaké verzi API byl zkompilován program, který ji volá a podle toho se zařídit. Pokud tohle chování nevyžaduješ, může být c-tor Attributes klidně veřejný.

Tenhle koncept používají mj. třeba Qtčka.
xkucf03 avatar 15.9. 13:34 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++

Dík. Pimpl idiom znám, ale bral jsem ho spíš jako volbu pro třídy obsahující logiku a ne jen přepravky na data / struktury, takže mě nenapadlo ho použít pro ty AttributeMetadata. Ale asi to takhle udělám.

Jen mi trochu vadí, že private_api.h musí být mezi exportovanými hlavičkovými soubory, protože se na něj odkazuje public_api.h. Není lepší to udělat jako void ukazatel a uvnitř metod pak přetypovávat? Chápu, že na funkci to nebude mít vliv, ale nesedí mi, aby implementační detaily prosakovaly do hlavičkových souborů, které tvoří veřejné rozhraní.

A pak nemám úplně dobrý pocit z té hromady metod, které jen provolávají m_d->.... To se píše vždycky ručně? Nepoužívá se třeba nějaké generování kódu?

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
15.9. 15:45 MadCatX
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++

Dík. Pimpl idiom znám, ale bral jsem ho spíš jako volbu pro třídy obsahující logiku a ne jen přepravky na data / struktury, takže mě nenapadlo ho použít pro ty AttributeMetadata. Ale asi to takhle udělám.

Jen mi trochu vadí, že private_api.h musí být mezi exportovanými hlavičkovými soubory, protože se na něj odkazuje public_api.h. Není lepší to udělat jako void ukazatel a uvnitř metod pak přetypovávat? Chápu, že na funkci to nebude mít vliv, ale nesedí mi, aby implementační detaily prosakovaly do hlavičkových souborů, které tvoří veřejné rozhraní.

private_api.h právě mezi exportovanými headery být nemusí, to class AttributesPrivate; je tzv. forward deklarace která o samotné třídě AttributesPrivate říká jen to, že někde existuje. Zvenku se s proměnnou m_d nedá dělat o nic více než s voidem.

Hierarchie includů vypadá takto: public_api.h -> private_api.h -> library.cpp pro knihovnu a public_api.h -> app.cpp pro aplikaci.

A pak nemám úplně dobrý pocit z té hromady metod, které jen provolávají m_d->.... To se píše vždycky ručně? Nepoužívá se třeba nějaké generování kódu?

Samotné C++ toto neumožňuje (aspoň o tom nevím) ale třeba QtDBus poskytuje na generování tříd obalujících data přenášená přes DBus sadu skriptíků s předpisem definovaným v XML. Napsat si na to něco rudimentárního třeba v Pythonu není problém.
xkucf03 avatar 15.9. 16:34 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
to class AttributesPrivate; je tzv. forward deklarace která o samotné třídě AttributesPrivate říká jen to, že někde existuje
Aha, to mi uniklo. Tak to bude fungovat :-)
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
15.9. 21:05 Ivan
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
Operator "->" se dat pretizit a pak se s tim daji delat blbosti, ve tvem pripade by to asi ale k nicemu nebylo. Mozma ze by to nekto dokazal nejak vypouzit pro generovani kodu.

C++ obcas smeruje k tomu, ze si reknes: "Tyhle dve radky kodu jsou to nejchytrejsi co jsem kdy naprogramoval". Pokud jde ale o verejne rozhrani tak je lesi se tomu vyhnout.

16.9. 16:18 Jindřich Makovička | skóre: 15
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
Pokud nebude mít ten někdo cizí zdrojáky, použil bych asi ABI v čistém C a předávání dat přes nějakou osvědčenou technologii typu Cap'nProto nebo protobuf.
xkucf03 avatar 16.9. 23:08 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++

Zdrojáky mít bude (svobodný software), ale šlo mi o tu zpětnou kompatibilitu, aby šlo upgradovat knihovnu a aplikace nepřestala fungovat.

Ty "osvědčené technologie" mi nevyhovují z několika důvodů -- jednak jsou příliš komplexní (přes 150 000 resp 700 000 řádků kódu) a jednak nenavrhuji rozhraní mezi dvěma programy, kde ten serializační formát dává smysl, ale rozhraní v rámci jednoho programu -- mezi aplikační logikou a knihovnou pro právě serializaci/deserializaci dat (tzn. řešit to tím, že mezi to vložím jinou knihovnu pro serializaci/deserializaci nedává smysl). Navíc se na tom chci naučit zase kus C++ a to, jak se to dělá jinde (KDE / Qt atd.)

Víceméně už jsem to vyřešil tím d-pointerem. Ještě ladím další věci, např. jestli se ty AttributeMetadataPrivate budou kopírovat nebo nebo budou v chytrém ukazateli (v zásadě se kopírovat nemusí, protože měnit je bude jen ten, kdo je vytváří, tzn. neměnný objekt). A pak ta rozhraní RelationalReaderRelationalReaderStringHadler -- tam asi zůstanu u těch virtuálních metod.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
22.9. 04:59 lacod | skóre: 2 | blog: OSS_DMS
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
Co skusit pouzit RTTI a dynamic_cast .
1.10. 09:27 StenF
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++
Pokud nesastavujete vse spolecne a nebo posilate data jinemu prg., tak doporucuju predavat textove zpravy utf8. Bud json nebo jednodussi name=value, ktere zpracujete jednoduse primo v std c++. Text data se dobre ladi, jednoduse muzete vse co jste poslal zapsat do logu nebo si vytvorit testovaci vzorky. Atd. atd.

Pimpl je taky fajn az na dynamickou alokaci kazdeho objektu, coz u nekterych typu projektu nemusi byt zadouci.
xkucf03 avatar 1.10. 19:30 xkucf03 | skóre: 46 | blog: xkucf03
Rozbalit Rozbalit vše Re: Rozšiřitelnost rozhraní a kompatibilita ABI v C++

Už jsem to tu někde psal -- ta knihovna v podstatě řeší serializaci a deserializaci určitého formátu. A při čtení posílá data formou událostí (něco jako SaX parser) aplikaci, která si je zpracuje. Nedává mi tedy smysl vymýšlet nějaký další serializační formát, ve kterém by se předávala data mezi knihovnou a aplikací. Více viz můj další dotaz Qt/C++, signály, sloty a vlánka (v příloze je tam i ukázka obrazovky).

Ten pimpl/d-pointer to řeší docela dobře.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.