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

[xkucf03]

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
};

Odpovědi

[Ivan]

Hmm a co proste predat hash-mapu kde klicem bude string a hodnou neco jako Qvariant, std::variant, boost::variant ?

[MadCatX]

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...

[Franta]

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.

[karel]

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.

[Ivan]

V KDE to maji pekne definovane: https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B

[Franta]

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ší?

[luky]

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]

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.

[luky]

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.

[Radek Isa]

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){
...
}


[Radek Isa]

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){
...
}


[MadCatX]

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]

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?

[MadCatX]

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]

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 :-)

[Ivan]

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.

[Jindřich Makovička]

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]

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í RelationalReader a RelationalReaderStringHadler -- tam asi zůstanu u těch virtuálních metod.

[lacod]

Co skusit pouzit RTTI a dynamic_cast .

[StenF]

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]

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.