"Proper" way to avoid function name conflicts?
Hi all,
just stumbled across something again I always wanted to ask the devs more familiar with C/C++ than me:
If the same function name is used in two third party C libraries, is there a good way to avoid this name conflict without changing the third party library?
Background is a conflicting function name in libwmf and libuemf that caused some crashes [1] and was fixed by Tav by renaming the function in libuemf [2] which works as we have a copy of that library but obviously will cause issues if we attempt to update the library with upstream code at some point in the future.
Best Regards, Eduard
[1] https://bugs.launchpad.net/inkscape/+bug/1616844 [2] https://gitlab.com/inkscape/inkscape/commit/038293f7984fa8bfd89a0451d3d77fce...
My extravagant wife has bought a Microsoft Surface Studio and I have the task of setting it up.
Installing Inkscape 9.2 went without a hitch. Running it was a different matter!
The screen resolution meant that the icons and text were microscopic. With the aid of a magnifying glass I found the preferences, which at first only showed a list of tool options. On a second try I found the settings to make things 'larger' - but still everything was bunched into a small space.
When I tried to show the response to the hugely expensive pressure sensitive pen, I could only draw fixed-width calligraphic lines on the screen. 'Input devices' only showed the main pointer, and denied that the mouse possessed a scroll wheel. This was after I had ticked the microscopic box for 'use a pressure sensitive device' and restarted the program.
Writing software is great fun, but unless the user is presented with an enjoyable experience it is mere navel-gazing. To me it seems that few of you have demanding graphic-designer wives!
Best wishes
John
On 17-Nov-17 8:35 PM, Eduard Braun wrote:
Hi all,
just stumbled across something again I always wanted to ask the devs more familiar with C/C++ than me:
If the same function name is used in two third party C libraries, is there a good way to avoid this name conflict without changing the third party library?
Background is a conflicting function name in libwmf and libuemf that caused some crashes [1] and was fixed by Tav by renaming the function in libuemf [2] which works as we have a copy of that library but obviously will cause issues if we attempt to update the library with upstream code at some point in the future.
Best Regards, Eduard
[1] https://bugs.launchpad.net/inkscape/+bug/1616844 [2] https://gitlab.com/inkscape/inkscape/commit/038293f7984fa8bfd89a0451d3d77fce...
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Dear John,
Sorry you had such a bad experience.
On Sat, 2017-11-18 at 13:58 +1000, John Billingsley wrote:
Writing software is great fun, but unless the user is presented with an enjoyable experience it is mere navel-gazing. To me it seems that few of you have demanding graphic-designer wives!
Sounds more like a hardware issue than a graphic designing partner issue.
Inkscape is designed to be used on Desktop systems. This is why we've never pushed Inkscape onto tablets or phones. The UI needs serious re- working to get it into shape for such a different presentation.
There are movements to make the interface more flexible going forwards. But it's slow going and so far we're still tweaking things for gtk3.
Best Regards, Martin Owens
I am not crabbing! I am keen to see Inkscape get as much success as possible. But to do that, you need to look at the market, rather than clever gizmos.
My wife lost patience with Corel Draw after their successive versions became so cluttered with 'enhancements' that they were virtually unusable. Corel 8 was very comfortable, but when x7 is installed it has similar microscopic icons to those of Inkscape.
I am sure that a basic subset of the software could be put together with very little effort, offering more than Windows Ink but with 'dive straight in' appeal. Alternatively all but the essential tools could be hidden on first installation, with some tips on how to add them.
Cheers
John
PS I suspect that for the pen to be discovered by the program, the Wacom driver interface might need to be added. If this is the case, maybe a textbox could give that advice, in the same way that Audacity shows how to add LAME for mp3 saving.
On 18-Nov-17 4:35 PM, Martin Owens wrote:
Dear John,
Sorry you had such a bad experience.
On Sat, 2017-11-18 at 13:58 +1000, John Billingsley wrote:
Writing software is great fun, but unless the user is presented with an enjoyable experience it is mere navel-gazing. To me it seems that few of you have demanding graphic-designer wives!
Sounds more like a hardware issue than a graphic designing partner issue.
Inkscape is designed to be used on Desktop systems. This is why we've never pushed Inkscape onto tablets or phones. The UI needs serious re- working to get it into shape for such a different presentation.
There are movements to make the interface more flexible going forwards. But it's slow going and so far we're still tweaking things for gtk3.
Best Regards, Martin Owens
On Sun, 2017-11-19 at 10:17 +1000, John Billingsley wrote:
I am not crabbing! I am keen to see Inkscape get as much success as possible. But to do that, you need to look at the market, rather than clever gizmos.
I did not intend to imply you were inappropriate with your comments. I only wanted to add some project historical clarity to your thoughts. In the hope that they would be more powerful outfitted with up to date information.
My wife lost patience with Corel Draw after their successive versions became so cluttered with 'enhancements' that they were virtually unusable. Corel 8 was very comfortable, but when x7 is installed it has similar microscopic icons to those of Inkscape.
I don't believe the tiny icons are a feature added by Inkscape. Rather a way inkscape doesn't resize for high resolution displays correctly. So on some computers Inkscape will display exactly the same number of pixels for it's icons, but these icons will be large and succulent targets for a mouse pointer.
I am sure that a basic subset of the software could be put together with very little effort, offering more than Windows Ink but with 'dive straight in' appeal. Alternatively all but the essential tools could be hidden on first installation, with some tips on how to add them.
I have that target in mind. I already have a couple of example configurations that strip down the inkscape experience. But these won't be available until 0.94/1.0 since inkscape has historically been unconfigurable and much of the user interface was glued into code. We've unpicked a lot of that this release cycle though to help.
PS I suspect that for the pen to be discovered by the program, the Wacom driver interface might need to be added. If this is the case, maybe a textbox could give that advice, in the same way that Audacity shows how to add LAME for mp3 saving.
Inkscape comes with wacom support, I don't think there's something you have to add. (unless there's something in the windows build that's needed) on linux wacom tablets work out the box.
Best Regards, Martin Owens
You can probably wrap one (or both) of them in a namespace (or class) in a separate .h file containing just the include to one lib and definitions of (used|all) functions in the lib, calling the lib, and include that .h file instead of the library one. (Not very practical, I know)
Am 19.11.2017 um 23:19 schrieb Marc Jeanmougin:
You can probably wrap one (or both) of them in a namespace (or class) in a separate .h file containing just the include to one lib and definitions of (used|all) functions in the lib, calling the lib, and include that .h file instead of the library one. (Not very practical, I know)
Are suggesting something like?
wrapper.h: namespace custom { #include <library1.h> }
I read about that before but it was specifically advised against (because it might cause even more issues while not really solving the problem at hand), e.g. https://stackoverflow.com/questions/6670738/is-it-a-good-idea-to-wrap-an-inc...
The fact that I wasn't able to find any satisfying solution at all (except changing the library source) was the reason to ask here, so if I misunderstood and you had something different in mind please let me know!
Regards and thanks for your answer Eduard
I thought about something more like
wrapperlib1.h: #include <lib1>
namespace Lib1 { void my_conflicting_function_from_lib1(args){ return conflicting_function_from_lib1(args); } }
On 11/20/2017 01:07 AM, Eduard Braun wrote:
Am 19.11.2017 um 23:19 schrieb Marc Jeanmougin:
You can probably wrap one (or both) of them in a namespace (or class) in a separate .h file containing just the include to one lib and definitions of (used|all) functions in the lib, calling the lib, and include that .h file instead of the library one. (Not very practical, I know)
Are suggesting something like?
wrapper.h: namespace custom { #include <library1.h> }
I read about that before but it was specifically advised against (because it might cause even more issues while not really solving the problem at hand), e.g. https://stackoverflow.com/questions/6670738/is-it-a-good-idea-to-wrap-an-inc...
The fact that I wasn't able to find any satisfying solution at all (except changing the library source) was the reason to ask here, so if I misunderstood and you had something different in mind please let me know!
Regards and thanks for your answer Eduard
Hm, but that would put "my_conflicting_function_from_lib1" into namespace "Lib1" while the actual "conflicting_function_from_lib1" still would not be in a different namespace and would conflict with a function of the same name from, say, lib2 --- or am I missing something here?
Even worse: If I understand what I read properly all functions in any 'extern "C"' blocks share the same namespace (if they're linked together), so there can never be any two c functions with the same name? (See e.g. https://stackoverflow.com/questions/28996944/extern-c-linkage-inside-c-names...).
Am 20.11.2017 um 01:16 schrieb Marc Jeanmougin:
I thought about something more like
wrapperlib1.h: #include <lib1>
namespace Lib1 { void my_conflicting_function_from_lib1(args){ return conflicting_function_from_lib1(args); } }
On 11/20/2017 01:07 AM, Eduard Braun wrote:
Am 19.11.2017 um 23:19 schrieb Marc Jeanmougin:
You can probably wrap one (or both) of them in a namespace (or class) in a separate .h file containing just the include to one lib and definitions of (used|all) functions in the lib, calling the lib, and include that .h file instead of the library one. (Not very practical, I know)
Are suggesting something like?
wrapper.h: namespace custom { #include <library1.h> }
I read about that before but it was specifically advised against (because it might cause even more issues while not really solving the problem at hand), e.g. https://stackoverflow.com/questions/6670738/is-it-a-good-idea-to-wrap-an-inc...
The fact that I wasn't able to find any satisfying solution at all (except changing the library source) was the reason to ask here, so if I misunderstood and you had something different in mind please let me know!
Regards and thanks for your answer Eduard
On 17-Nov-2017 02:35, Eduard Braun wrote:
Background is a conflicting function name in libwmf and libuemf that caused some crashes [1] and was fixed by Tav by renaming the function in libuemf [2] which works as we have a copy of that library but obviously will cause issues if we attempt to update the library with upstream code at some point in the future.
What part of the code is using libwmf? Is libemf linked in too? I wrote libuemf because libemf didn't do everything it needed to (at least at the time) to fully enable emf support and then later expanded it to support wmf as well. I vaguely recall that there was some generic import/export mechanism available in Inkscape at the time which could be set to do emf but that the results were so limited that it was hardly worth the bother.
Anyway, since libuemf and (libemf + libwmf) are two separate implementations covering the same specialized data types it is hardly surprising that they have name conflicts. Normally a program would only use one or the other, and _that_ is the proper way to avoid these particular function name conflicts. Perhaps that is not possible here, if the code linking in libemf/libwmf is itself in an outside library which comes prelinked to the other two.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Am 20.11.2017 um 18:39 schrieb mathog:
On 17-Nov-2017 02:35, Eduard Braun wrote:
Background is a conflicting function name in libwmf and libuemf that caused some crashes [1] and was fixed by Tav by renaming the function in libuemf [2] which works as we have a copy of that library but obviously will cause issues if we attempt to update the library with upstream code at some point in the future.
What part of the code is using libwmf? Is libemf linked in too? I wrote libuemf because libemf didn't do everything it needed to (at least at the time) to fully enable emf support and then later expanded it to support wmf as well. I vaguely recall that there was some generic import/export mechanism available in Inkscape at the time which could be set to do emf but that the results were so limited that it was hardly worth the bother.
I think the conflict is caused by the gdk-pixbuf loader provided by libwmf. The file open dialog uses gdk-pixbuf to render file previews. (As I'm on Windows were gdk-pixbuf is compiled with native GDI+ loaders instead of the libwmf backend I fortunately never experienced this problem first hand).
What you write below seems to be the case here...
Anyway, since libuemf and (libemf + libwmf) are two separate implementations covering the same specialized data types it is hardly surprising that they have name conflicts. Normally a program would only use one or the other, and _that_ is the proper way to avoid these particular function name conflicts. Perhaps that is not possible here, if the code linking in libemf/libwmf is itself in an outside library which comes prelinked to the other two.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (5)
-
Eduard Braun -
John Billingsley -
Marc Jeanmougin -
Martin Owens -
mathog