2017-01-20 10 views
7

Tytuł mówi wszystko. Zamierzam dodać argument do funkcji składowej klasy z wartością domyślną. Argument jest nietrywialny. Czy to łamie ABI? Załóżmy, że moja nowa wersja biblioteki ma być M.m.0 i powinna być dostępna jako zamiennik dla wszystkich połączonych aplikacji, które używają M.m-1.x.Czy dodanie argumentów z wartościami domyślnymi do funkcji łamie ABI?

Przykładowy kod:

// These are some classes: base and child : public base 

/* Version 1.2.3 */ 
class foo() { 
public: 
    void do_that_stuff(const std::string a); 
} 

/* Version 1.3.0 */ 
class foo() { 
public: 
    void do_that_stuff(const std::string a, const base& b = base()); 
} 

PS: Zrobiłem mój własny test, i to działa. Po prostu nie można być pewnym:

+4

Nazwa mówi wszystko. Domyślne argumenty to * argumenty * i nie mają nic wspólnego z typem funkcji (w szczególności z parametrami funkcji). –

+1

_ "Czy to łamie ABI w tył?" Przykro mi? –

+1

'do_that_stuff' otrzyma inną zniekształconą nazwę w starych i nowych kompilacjach - myślę, że łamie moją definicję kompatybilności ABI. –

Odpowiedz

10

Większość ABI ABCs koduje typy argumentów funkcji [member] w nazwie symbolu. Domyślne argumenty są zwykle implementowane jako obiekty tymczasowe wyczarowane w punkcie połączenia. Jeśli są to wybory dokonane dla użytej ABI, dodanie domyślnego argumentu zmieni ABI. Niezależnie od tego, czy będzie to konieczne, należy określić konkretny używany ABI.

+0

Z ciekawości, czy znasz ABI, która nie zostałaby złamana przez tę zmianę? – Oliv

+1

@Oliv: Nie jestem tego świadomy. Jednak ABI * może * generować wiele symboli dla funkcji z domyślnymi argumentami. Byłoby to dość podejście do zmiany klasy bez łamania ABI (zakładając, że zmodyfikowana funkcja nie jest "wirtualna"): zamiast tego, jeśli użyjemy domyślnego argumentu, funkcje mogą zostać przeciążone przez wywołanie innego przekazywania wszystkich argumebtów i dodanie defaulted argument. –

Powiązane problemy