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í
×
dnes 13:22 | Nová verze

Alan Griffiths z Canonicalu oznámil vydání verze 1.0.0 display serveru Mir (GitHub, Wikipedie). Mir byl představen v březnu 2013 jako náhrada X serveru a alternativa k Waylandu. Dnes Mir běží nad Waylandem a cílen je na internet věcí (IoT).

Ladislav Hagara | Komentářů: 0
včera 22:00 | Nasazení Linuxu
Stabilní aktualizace Chrome OS 69 (resp. Chromium OS), konkrétně 69.0.3497.95, přináší mj. podporu linuxových aplikací. Implementována je pomocí virtualizace, a proto je tato funkce také omezena na zařízení s dostatkem paměti a podporou hardwarové akcelerace, tudíž nejsou podporovány chromebooky s 32bitovými architekturami ARM, či Intel Bay Trail (tzn. bez Intel VT-x).
Fluttershy, yay! | Komentářů: 3
včera 21:32 | Zajímavý projekt
Došlo k uvolnění linuxové distribuce CLIP OS, vyvíjené francouzským úřadem pro kybernetickou bezpečnost ANSSI, jako open source. Vznikla za účelem nasazení v úřadech, kde je potřeba omezit přístup k důvěrným datům. Je založená na Gentoo.
Fluttershy, yay! | Komentářů: 0
včera 16:00 | Komerce

Zjistěte více o bezpečné a flexibilní architektuře v cloudu! IBM Cloud poskytuje bezpečné úložiště pro Vaše obchodní data s možností škálovatelnosti a flexibilitou ukládání dat. Zároveň nabízí prostředky pro jejich analýzu, vizualizaci, reporting a podporu rozhodování.

… více »
Fluttershy, yay! | Komentářů: 12
včera 12:22 | Nová verze

V dubnu letošního roku Mozilla představila webový prohlížeč pro rozšířenou a virtuální realitu Firefox Reality (GitHub). V úterý oznámila vydání verze 1.0. Ukázka na YouTube. Firefox Reality je k dispozici pro Viveport, Oculus a Daydream.

Ladislav Hagara | Komentářů: 2
včera 12:00 | Komunita

V srpnu loňského roku společnost Oracle oznámila, že Java EE (Enterprise Edition) bude uvolněna jako open source. O měsíc později bylo rozhodnuto, že tato open source Java EE bude přejmenována a předána Eclipse Foundation. Nové jméno bylo oznámeno v únoru letošního roku. Z Java EE se stala Jakarta EE. Eclipse Foundation včera oznámila dosažení dalšího milníku. Zdrojové kódy aplikačního serveru GlassFish jsou již k dispozici v git repozitářích Eclipse Foundation (GitHub).

Ladislav Hagara | Komentářů: 0
19.9. 23:55 | Komunita

LTS (Long Term Support) podpora Ubuntu 12.04 LTS (Precise Pangolin) skončila po 5 letech od jeho vydání, tj. v dubnu 2017. V březnu 2017 ale Canonical představil placenou ESM (Extended Security Maintenance) podporu, díky které je Ubuntu 12.04 podporováno do dubna 2020. Dnes Canonical potvrdil ESM podporu také pro Ubuntu 14.04 LTS (Trusty Tahr), jehož LTS podpora skončí v dubnu 2019.

Ladislav Hagara | Komentářů: 0
19.9. 15:00 | Nová verze

Byla vydána verze 3.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí HTML, CSS a JavaScriptu Electron (YouTube, GitHub). Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.

Ladislav Hagara | Komentářů: 0
19.9. 14:44 | Nová verze

Po půl roce vývoje od vydání verze 6.0.0 byla vydána verze 7.0.0 překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, clang-tools-extra a LLD.

Ladislav Hagara | Komentářů: 0
19.9. 13:44 | Nová verze

Byla vydána verze 3.0.0 knihovny pro vykreslování grafů v programovacím jazyce Python Matplotlib (Wikipedie, GitHub). Přehled novinek a galerie grafů na stránkách projektu. Zrušena byla podpora Pythonu 2.

Ladislav Hagara | Komentářů: 0
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (13%)
 (14%)
 (20%)
 (23%)
 (25%)
 (4%)
 (1%)
Celkem 382 hlasů
 Komentářů: 33, poslední 16.9. 11:55
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: 697×
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

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.