ABI Compatibility of identifiers that are not exposed

Discussion regarding the development of CEGUI itself - as opposed to questions about CEGUI usage that should be in the help forums.

Moderators: CEGUI MVP, CEGUI Team

YaronCT
CEGUI Team
Posts: 448
Joined: Fri Jun 19, 2015 12:18
Location: Kiryat-Bialik, Israel

ABI Compatibility of identifiers that are not exposed

Postby YaronCT » Mon Jul 20, 2015 12:24

Hi,

Is it allowed to change, for example, the prototype of a method in "OpenGL3ShaderManager", which is not defined with "OPENGL_GUIRENDERER_API" or something similar that indicates that it should be exposed? That is, if I want to maintain ABI compatibility.

User avatar
Ident
CEGUI Team
Posts: 1893
Joined: Sat Oct 31, 2009 13:57
Location: Austria

Re: ABI Compatibility of identifiers that are not exposed

Postby Ident » Sat Jul 25, 2015 12:32

According to : https://techbase.kde.org/Policies/Binar ... s_With_C++
This is legal, because it fits the following description: "export a class that was not previously exported." listed under "DO's"

Feel free to expose any classes that should be exposed and were not!
CrazyEddie: "I don't like GUIs"

YaronCT
CEGUI Team
Posts: 448
Joined: Fri Jun 19, 2015 12:18
Location: Kiryat-Bialik, Israel

Re: ABI Compatibility of identifiers that are not exposed

Postby YaronCT » Sat Jul 25, 2015 12:41

Ok, but my question was not whether it's legal to expose the class, but whether it's legal to change the prototype of a method of the class (leaving the class unexposed). So, If try to read between your words, it's legal. I was just wondering because in MSVC u must use __declspec(dllexport) do expose a symbol, but e.g. in GCC I think every symbol is automatically exposed, unless it's defined explicitly to have static linkage, or declared/defined with something like "__attribute__ ((visibility ("hidden")))" (which we do not seem to use in CEGUI code. Perhaps we should?). So perhaps e.g. with GCC some1 would still use a method of the class even though it's not explicitly "exposed", and therefore changing its prototype would break ABI compatibility.

User avatar
Ident
CEGUI Team
Posts: 1893
Joined: Sat Oct 31, 2009 13:57
Location: Austria

Re: ABI Compatibility of identifiers that are not exposed

Postby Ident » Sat Jul 25, 2015 12:43

Sorry, clearly I misunderstood your question. By "prototype" do you mean "superclass"? I am not sure what "prototype" means in this context.


Edit: Okay I just looked it up and I guess you mean "function prototype". Let me re-read.
CrazyEddie: "I don't like GUIs"

YaronCT
CEGUI Team
Posts: 448
Joined: Fri Jun 19, 2015 12:18
Location: Kiryat-Bialik, Israel

Re: ABI Compatibility of identifiers that are not exposed

Postby YaronCT » Sat Jul 25, 2015 12:48

No, by changing the prototype of a method of a class, I mean e.g. change its parameters. So, say, in the definition of the class "OpenGL3ShaderManager", change:

Code: Select all

void initialiseShaders();

to:

Code: Select all

void initialiseShaders(bool foo);

And then, if a GCC user used the old prototype, ABI compatibility would be broken. (And he can do that, despite the fact that the class isn't defined with "OPENGL_GUIRENDERER_API".)

User avatar
Ident
CEGUI Team
Posts: 1893
Joined: Sat Oct 31, 2009 13:57
Location: Austria

Re: ABI Compatibility of identifiers that are not exposed

Postby Ident » Sat Jul 25, 2015 12:55

Thats a good question. First of all the obvious thing: If the method initialiseShaders is private or protected and non-static it doesnt matter, it can be removed, changed, whatever. If it is public however, then I believe it can't be removed for the reason you gave, also we typically go by this:
https://techbase.kde.org/Policies/Binar ... s_With_C++

Which states that existing functions of any type cant be removed. What we would typically do is to retain the old function ,mark it as deprecated and call the newly added initialiseShaders(bool foo) from the old function to not have any boilerplate code left. I would like to hear Martin's input on this though as well, just to be sure.
CrazyEddie: "I don't like GUIs"

YaronCT
CEGUI Team
Posts: 448
Joined: Fri Jun 19, 2015 12:18
Location: Kiryat-Bialik, Israel

Re: ABI Compatibility of identifiers that are not exposed

Postby YaronCT » Sat Jul 25, 2015 13:03

Are u sure about "protected"? A used might have inherited the class and used the protected method from there! I think it applies only to private members.

User avatar
Ident
CEGUI Team
Posts: 1893
Joined: Sat Oct 31, 2009 13:57
Location: Austria

Re: ABI Compatibility of identifiers that are not exposed

Postby Ident » Sat Jul 25, 2015 13:06

True, it actually only says "private" in the link and your reasoning completely makes sense. I am really not an expert on ABI compatibility as you may have noticed ;)
CrazyEddie: "I don't like GUIs"

User avatar
Kulik
CEGUI Team
Posts: 1382
Joined: Mon Jul 26, 2010 18:47
Location: Czech Republic
Contact:

Re: ABI Compatibility of identifiers that are not exposed

Postby Kulik » Mon Jul 27, 2015 08:35

We only maintain ABI compat for visible symbols, so yes, this is perfectly legal.

YaronCT
CEGUI Team
Posts: 448
Joined: Fri Jun 19, 2015 12:18
Location: Kiryat-Bialik, Israel

Re: ABI Compatibility of identifiers that are not exposed

Postby YaronCT » Tue Jul 28, 2015 08:47

Kulik,

but in GCC, symbols **are** visible by default, unless the "-fvisibility=hidden" compilation flag or "#pragma GCC visibility push(hidden)" is put in the code. That means, users might already use some symbols that we didn't intend to make visible. Don't u think we should use one of these options to prevent the visibility of the symbols we don't want visible?

YaronCT
CEGUI Team
Posts: 448
Joined: Fri Jun 19, 2015 12:18
Location: Kiryat-Bialik, Israel

Re: ABI Compatibility of identifiers that are not exposed

Postby YaronCT » Tue Jul 28, 2015 08:50



Return to “CEGUI Library Development Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest