"Proper" way to avoid function name conflicts?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

"Proper" way to avoid function name conflicts?

Eduard Braun
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/038293f7984fa8bfd89a0451d3d77fce3f62610c


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: First-time user experience

John Billingsley
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/038293f7984fa8bfd89a0451d3d77fce3f62610c
>
>
> ------------------------------------------------------------------------------
>
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: First-time user experience

doctormo
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: First-time user experience

John Billingsley
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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: First-time user experience

doctormo
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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: "Proper" way to avoid function name conflicts?

Marc Jeanmougin
In reply to this post by Eduard Braun
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)

--
Mc


On 11/17/2017 11:35 AM, 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/038293f7984fa8bfd89a0451d3d77fce3f62610c
>
>
>
> ------------------------------------------------------------------------------
>
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: "Proper" way to avoid function name conflicts?

Eduard Braun
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-include-in-a-namespace-block

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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: "Proper" way to avoid function name conflicts?

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-include-in-a-namespace-block
>
>
> 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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: "Proper" way to avoid function name conflicts?

Eduard Braun
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-namespace).


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-include-in-a-namespace-block
>>
>>
>> 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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: "Proper" way to avoid function name conflicts?

mathog
In reply to this post by Eduard Braun
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: "Proper" way to avoid function name conflicts?

Eduard Braun
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
> [hidden email]
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel