From: SourceForge.net <no...@so...> - 2007-11-20 09:14:03
|
Bugs item #1746818, was opened at 2007-07-03 00:00 Message generated for change (Comment added) made by berserker_r You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1746818&group_id=1645 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: csharp Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Berserker (berserker_r) Assigned to: William Fulton (wsfulton) Summary: Directors bug with virtual protected methods Initial Comment: // C++ code %feature("director") Alfa; class Alfa { public: Alfa() { } virtual ~Alfa() { } protected: virtual void test() { } }; %feature("director") Beta; class Beta : public Alfa { public: Beta() { } virtual ~Beta() { } }; // C# code public class Gamma : Beta { public Gamma() { } public void foo() { test(); } } public static class Program { static void Run() { Gamma g = new Gamma(); g.foo(); } } The "foo" call causes an access violation in the C++ code generated by swig, in particular the problem is here: SWIGEXPORT void SWIGSTDCALL CSharp_Alfa_testSwigExplicitAlfa(void *jarg1) { Alfa *arg1 = (Alfa *) 0 ; SwigDirector_Alfa *darg = 0; arg1 = (Alfa *)jarg1; darg = dynamic_cast<SwigDirector_Alfa *>(arg1); (darg)->testSwigPublic(); } arg1 is a SwigDirector_Beta instance (not SwigDirector_Alfa) so the dynamic_cast here returns null and the "testSwigPublic" call causes an access violation. ---------------------------------------------------------------------- >Comment By: Berserker (berserker_r) Date: 2007-11-20 10:13 Message: Logged In: YES user_id=418740 Originator: YES Just an update to my previous workaround for a "generic accessor": //////////////////////////////////////////////////////////////////////////////////// template <typename T, typename F> class SwigAccessor : public T { friend F; }; template <typename T, typename F> inline static SwigAccessor<T, F> * swig_friend_cast(T *p) { return reinterpret_cast<SwigAccessor<T, F> *>(p); } template <typename T, typename F> inline static SwigAccessor<T, F> & swig_friend_cast(T &p) { return reinterpret_cast<SwigAccessor<T, F> &>(p); } class Alfa { protected: void protectedAlfaMethod(); // This is what we need to call }; class SwigWrapperBase { public: virtual ~SwigWrapperBase() { } }; class SwigAlfaWrapper : public SwigWrapperBase { public: SwigAlfaWrapper() : m_impl(new Alfa()) { } virtual ~SwigAlfaWrapper() { delete m_impl; } public: void protectedAlfaMethod() { // Let's call that !!! swig_friend_cast<Alfa, SwigAlfaWrapper>(m_impl)->protectedAlfaMethod(); } private: Alfa *m_impl; }; //////////////////////////////////////////////////////////////////////////////////// Can anyone release a patch?Plz help... ---------------------------------------------------------------------- Comment By: Berserker (berserker_r) Date: 2007-11-09 10:43 Message: Logged In: YES user_id=418740 Originator: YES > Devious, though I doubt this trick has defined behaviour in C++. I don't have an alternative approach to suggest though... It's a well known C++ trick, where is the problem? ---------------------------------------------------------------------- Comment By: Olly Betts (olly) Date: 2007-11-09 10:36 Message: Logged In: YES user_id=14972 Originator: NO Devious, though I doubt this trick has defined behaviour in C++. I don't have an alternative approach to suggest though... ---------------------------------------------------------------------- Comment By: Berserker (berserker_r) Date: 2007-11-09 10:11 Message: Logged In: YES user_id=418740 Originator: YES I found a solution to the problem, but I'm not so expert with the swig API to release a patch, I hope someone can help with that...the idea is to remove the inheritance from the wrapped classes using instead a "proxy helper class" to make the the "C" calls. In this example I'll show how we can access to the protected methods: //// User code //////////////////////////////////////// class Alfa { public: Alfa() { } virtual ~Alfa() { } public: virtual void publicAlfaMethod() { } protected: virtual void protectedAlfaMethod() { } }; class Beta : public Alfa { public: Beta(int value) : m_value(value) { } virtual ~Beta() { } public: virtual void publicBetaMethod() { } protected: virtual void protectedBetaMethod() { } private: int m_value; }; //// Swig code //////////////////////////////////////// class WrapperBase { public: virtual ~WrapperBase() { } }; class AlfaWrapper : public WrapperBase { // This class will help us to access the protected methods class AlfaAccessor : public Alfa { friend class AlfaWrapper; }; public: // The trick is to cast "Alfa" as "AlfaAccessor" so that we can access to every method AlfaWrapper() : m_impl(reinterpret_cast<AlfaAccessor *>(new Alfa())) { } virtual ~AlfaWrapper() { delete reinterpret_cast<Alfa *>(m_impl); } public: void publicAlfaMethod() { /* // The swig implementation will be if(publicAlfaMethodCallback) publicAlfaMethodCallback(); else m_impl->publicAlfaMethod(); */ m_impl->publicAlfaMethod(); } void protectedAlfaMethod() { // Note: this is allowed because we are good friends :) m_impl->protectedAlfaMethod(); } private: AlfaAccessor *m_impl; }; class BetaWrapper : public WrapperBase { class BetaAccessor : public Beta { friend class BetaWrapper; }; public: BetaWrapper(int value) : m_impl(reinterpret_cast<BetaAccessor *>(new Beta(value))) { } virtual ~BetaWrapper() { delete reinterpret_cast<Beta *>(m_impl); } public: void publicAlfaMethod() { m_impl->publicAlfaMethod(); } void protectedAlfaMethod() { m_impl->protectedAlfaMethod(); } void publicBetaMethod() { m_impl->publicBetaMethod(); } void protectedBetaMethod() { m_impl->protectedBetaMethod(); } private: BetaAccessor *m_impl; }; ---------------------------------------------------------------------- Comment By: William Fulton (wsfulton) Date: 2007-11-07 16:49 Message: Logged In: YES user_id=242951 Originator: NO It doesn't necessarily cost money to fix bugs. I don't think you fully understand how free software works. The Linux kernel like all other large free software projects is contributed to by paid employees as well as volunteers. SWIG doesn't have any sponsors and currently we are very short of active developers. With free software you have the freedom to take the hard work that others have put into the software and use it for your own use. You are also free to take the source code to modify for your own needs. Part of the philosophy of free software is that the software can be fixed without being beholden to any company who may or may not fix it at their will. You have a great choice: either pay to get what you want (like proprietary software), fix it yourself or use some workarounds. Also you could have come up with a solution of what the generated code should look like under all situations then it would be a lot easier for one of us to implement. Another choice was to coerce one of the SWIG developers into looking at it sooner rather than later for nothing, not with the somewhat arrogant attitude that you have shown, ie we are beholden to fix this for you. If you'd mentioned which free project this was affecting, why it is important, we might have been a bit more sympathetic. Learning some diplomatic skills might be useful for next time. ---------------------------------------------------------------------- Comment By: soccia79 (soccia79) Date: 2007-11-07 15:32 Message: Logged In: YES user_id=1836240 Originator: NO > Depends on who you commission to do the work, but expect to pay up to the normal commercial rates for hiring consultants who are experts in a particular field. We develop a free project, that's way I'm asking...no company will give us the money for this patch (if we have known in the past that a fix for Swig could costs anything, we would have look for something else...) ---------------------------------------------------------------------- Comment By: William Fulton (wsfulton) Date: 2007-11-07 15:06 Message: Logged In: YES user_id=242951 Originator: NO Depends on who you commission to do the work, but expect to pay up to the normal commercial rates for hiring consultants who are experts in a particular field. ---------------------------------------------------------------------- Comment By: soccia79 (soccia79) Date: 2007-11-06 12:57 Message: Logged In: YES user_id=1836240 Originator: NO > An excellent way of pushing a bug to number 1 priority is to contract the work out to any one of the developers. >I can be emailed directly if you are interested. Can I have an idea of the "costs" for a "contract" like this? ---------------------------------------------------------------------- Comment By: soccia79 (soccia79) Date: 2007-10-26 09:26 Message: Logged In: YES user_id=1836240 Originator: NO > However, there are often workarounds for things like this. > For example, you could try to re-declare a "virtual void test()" in class > Beta (even if it does not exist: the goal is to generate additional > wrappers; by chance, function calls will resolve to the base class). > Try it either directly or with a %extend. Maybe you'll have to declare it > public. The problem is that we cannot modify the sources because is a third part library and we cannot "extend" every derived class because it would be an huge work (a temporary work with a fix). We'll wait with the hope of a fix... ---------------------------------------------------------------------- Comment By: soccia79 (soccia79) Date: 2007-10-26 09:25 Message: Logged In: YES user_id=1836240 Originator: NO > However, there are often workarounds for things like this. > For example, you could try to re-declare a "virtual void test()" in class > Beta (even if it does not exist: the goal is to generate additional > wrappers; by chance, function calls will resolve to the base class). > Try it either directly or with a %extend. Maybe you'll have to declare it > public. The problem is that we cannot modify the sources because is a third part library and we cannot "extend" every derived class because it would be an huge work (a temporary work with a fix). We'll wait with the hope of a fix... ---------------------------------------------------------------------- Comment By: Amaury Forgeot d'Arc (amauryf) Date: 2007-10-26 00:14 Message: Logged In: YES user_id=389140 Originator: NO Furthermore, the problem does not seems easy to fix. Directors are not even implemented consistently among the different swig backends. However, there are often workarounds for things like this. For example, you could try to re-declare a "virtual void test()" in class Beta (even if it does not exist: the goal is to generate additional wrappers; by chance, function calls will resolve to the base class). Try it either directly or with a %extend. Maybe you'll have to declare it public. And tell us the solution when you find it! ---------------------------------------------------------------------- Comment By: Olly Betts (olly) Date: 2007-10-25 18:11 Message: Logged In: YES user_id=14972 Originator: NO I don't understand what you're trying to ask. If you're asking if 4 months is a long time, sadly we have bugs much older than this which are still open. Some are because we need more information and have requested it but the reporter hasn't responded, but that's certainly not true of all of them. If you're asking if this this bug should be fixed "urgently", well in an ideal world all bugs would be fixed quickly. I understand that it may be an "urgent" issue for you, but all the SWIG developers are unpaid volunteers with other priorities. If fixing this is urgent for you, then as William says you're welcome to work on a fix yourself (SWIG's complete source code is available for download) or to find someone willing to contract to fix it for you. Simply asking repeatedly if there's a fix yet isn't going to magically make one appear more quickly I'm afraid. ---------------------------------------------------------------------- Comment By: soccia79 (soccia79) Date: 2007-10-25 13:59 Message: Logged In: YES user_id=1836240 Originator: NO Is it 4 month "urgently"? ---------------------------------------------------------------------- Comment By: William Fulton (wsfulton) Date: 2007-10-25 13:42 Message: Logged In: YES user_id=242951 Originator: NO The SWIG developers are volunteers with no direct funding. There are over a hundred bugs currently reported and this is just one of them. If you really need a particular bug fixed urgently consider debugging and fixing it yourself or ask one of the developers to prioritise. An excellent way of pushing a bug to number 1 priority is to contract the work out to any one of the developers. I can be emailed directly if you are interested. ---------------------------------------------------------------------- Comment By: soccia79 (soccia79) Date: 2007-10-25 12:24 Message: Logged In: YES user_id=1836240 Originator: NO > 4 months and no patches yet...any hope? Quoted ---------------------------------------------------------------------- Comment By: Berserker (berserker_r) Date: 2007-10-23 20:18 Message: Logged In: YES user_id=418740 Originator: YES 4 months and no patches yet...any hope? ---------------------------------------------------------------------- Comment By: soccia79 (soccia79) Date: 2007-10-23 13:28 Message: Logged In: YES user_id=1836240 Originator: NO Plz help! ---------------------------------------------------------------------- Comment By: soccia79 (soccia79) Date: 2007-10-22 13:47 Message: Logged In: YES user_id=1836240 Originator: NO I tried the la svn revision but the problem persists! Always the same cast error as berserker_r reported: SWIGEXPORT void SWIGSTDCALL CSharp_Alfa_testSwigExplicitAlfa(void *jarg1) { Alfa *arg1 = (Alfa *) 0 ; SwigDirector_Alfa *darg = 0; arg1 = (Alfa *)jarg1; darg = dynamic_cast<SwigDirector_Alfa *>(arg1); // crash here because arg1 is a SwigDirector_Beta instance (darg)->testSwigPublic(); } ---------------------------------------------------------------------- Comment By: Olly Betts (olly) Date: 2007-10-19 14:59 Message: Logged In: YES user_id=14972 Originator: NO This sounds like it could be related to bug#1735931 which has been fixed in SVN HEAD: http://sourceforge.net/tracker/index.php?func=detail&aid=1735931&group_id=1645&atid=101645 Can you check the latest SVN HEAD and let us know if this is fixed/still present? ---------------------------------------------------------------------- Comment By: soccia79 (soccia79) Date: 2007-10-19 12:47 Message: Logged In: YES user_id=1836240 Originator: NO Plz fix this bug! ---------------------------------------------------------------------- Comment By: soccia79 (soccia79) Date: 2007-07-26 17:42 Message: Logged In: YES user_id=1836240 Originator: NO News about this bug? ---------------------------------------------------------------------- Comment By: soccia79 (soccia79) Date: 2007-07-04 17:42 Message: Logged In: YES user_id=1836240 Originator: NO Plz fix this bug, I have the same problem!!! (I'm using last SVN) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=101645&aid=1746818&group_id=1645 |