#797 class destructor not recognised

closed-wont-fix
parsing (147)
5
2007-02-28
2007-02-15
speedy
No

***************************

module example;

%inline %{
class game_actor
{
public:
game_actor::game_actor(void);
game_actor::~game_actor();
};

%}

***************************

SWIG 1.3.31 wrongly recognises the destructor as a plain ordinary function,
although it is a valid destructor declaration in C++.

SWIG output:
bug.i(8): Warning(504): Function ~game_actor must have a return type.

Workaround I'm using currently is to rename destructors from "game_actor::~game_actor();"
to simpler but not-.h-to-.cpp-copy-pastable "~game_actor();".

Discussion

  • Olly Betts

    Olly Betts - 2007-02-15

    Logged In: YES
    user_id=14972
    Originator: NO

    Your "workaround" is actually correcting this code to be valid C++ - it's invalid to have the extra "game_actor::" qualifier like this. Some older C++ compilers don't complain about it, but it's an error in recent versions of GCC:

    $ g++ tmp.cc
    tmp.cc:4: error: extra qualification ‘game_actor::’ on member ‘game_actor’
    tmp.cc:5: error: extra qualification ‘game_actor::’ on member ‘game_actor’
    $ g++ --version
    g++ (GCC) 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
    Copyright (C) 2006 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions. There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

    SWIG could handle this better though. We should probably issue a similar error to GCC.

     
  • speedy

    speedy - 2007-02-15

    Logged In: YES
    user_id=1080547
    Originator: YES

    Visual C++ 2003 compiler here - I think you should issue a warning but accept it as a destructor for the time being, to be no-pain compatible with the older compilers.

    Btw. I'm using that notation because I like to be able to copy&paste from .h <-> .cpp directly.

     
  • Gonzalo Garramuno

    Logged In: YES
    user_id=961712
    Originator: NO

    Not entirely a swig bug.

    Definition of functions/destructor as:

    game_actor::game_actor();

    is NOT valid C++ within the class definition (only Microsoft's crappy compiler will accept that as valid).

    Use proper C++ constructs like:

    %inline %{
    class game_actor
    {
    public:
    game_actor(void);
    ~game_actor();
    };

    %}

     
  • speedy

    speedy - 2007-02-28

    Logged In: YES
    user_id=1080547
    Originator: YES

    1. -==>>only<==- Microsoft's crappy compiler ("only" as in used only by few people?)

    2. I'm sure you understand that I'm using that syntax only for practical reasons (whatever the C++ standard requires - there are also many C++ extensions aka. GCCisms in existance, would you ban them?), and you are pushing towards SWIG being more strict then my current compiler?

     
  • David M. Beazley

    • assigned_to: marcelomatus --> beazley
    • status: open --> closed-wont-fix
     
  • David M. Beazley

    Logged In: YES
    user_id=7557
    Originator: NO

    I'm not going to fix this problem. (1) It's not valid C++ code. (2) The SWIG parser is already complicated enough as it is to be adding support for a non-standard feature like this. I will reconsider if the submitter can provide a specific citation to part of the ANSI C++ standard that says that this programming style is proper C++ code.

     
  • Olly Betts

    Olly Betts - 2007-02-28
    • assigned_to: beazley --> marcelomatus
    • status: closed-wont-fix --> open
     
  • Olly Betts

    Olly Betts - 2007-02-28

    Logged In: YES
    user_id=14972
    Originator: NO

    There are a number of instances of valid standard-conforming C++ which SWIG
    can't handle (nested classes are probably the most requested example), so I'm
    not personally likely to spend my limited time fixing handling of invalid C++
    code which can trivially be fixed to be valid C++.

    You seem to feel strongly about this, so I suggest if you want this to be
    resolved in a particular way that you work on a patch which does that and
    submit it for inclusion in SWIG.

    It's probably less effort to just fix your code though...

     
  • Olly Betts

    Olly Betts - 2007-02-28

    Logged In: YES
    user_id=14972
    Originator: NO

    sorry dave, I didn't intend to reopen the bug.

     
  • Olly Betts

    Olly Betts - 2007-02-28
    • status: open --> closed-wont-fix
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks