From: William S F. <ws...@fu...> - 2005-11-12 19:48:27
|
I'd like to bring up a discussion of whether SWIG should generate copy constructors and assignment operator wrappers. I would like to remove heaps of copy constructors from the C++ classes being wrapped as they are not necessary and are a maintenance headache considering the C++ compiler will generate these anyway. gcc -Weffc++ is a great way to monitor whether a custom one should be written btw. The problem is that SWIG does not generate a copy constructor like a C++ compiler does. Normally if a class does not provide the following the compiler will generate code for them (if needed): - Default constructor - Destructor - Copy constructor - Assignment operator - Address of operators (const and non-const) SWIG supplies the first two, but non of the others. Can anybody think of a reason why copy constructors should not be automatically generated? The logic to generate these should be similar to generating a default constructor, ie if not present and not private/protected, then generate one. One other thing to consider is what the copy constructors should be called in the target language, for example in Java a clone() method might be most appropriate. We probably need a virtual method lang::copyConstructorHandler() like lang::constructorHandler() to deal with this. I can't see the point in generating address of operators, but the assignment operators might be useful. This is a little more tricky to generate as an assignment operator cannot be generated if the class has a const member or a member that is a reference. William |
From: Marcelo M. <mm...@ac...> - 2005-11-14 10:48:51
|
Well, as in the default constructor, the only reason would be when there is an explicit private/protected copy constructor, or, when the class is abstract. Beside that, I agree, the copy constructor it should be automatically generated as in the case of the default constructors. Other automatic things that C++ provide but swig doesn't are the operator cast constructors, ie, if you have: struct A { operator double(); }; struct B { B(double); }; in C++ you can do A a(1.0); B b(a); that problem is partially solved with the implicit.i library file, but it doesn't work for all the languages right now. And following the lines of missing things, is the dynamic cast operations, ie, if you have a virtual class, you always can do: A *ad = dynamic_cast<A*>(vptr); I remember we discuss this point some time ago, but never agree in a proper name to the dynamic cast method, which in python it should be a static method that would look like: a = A.dynamic_cast(vptr) But back to the point, we could add a feature "copyconstructor" in the same way we have now the "defaultconstructor", and use it accordingly. Marcelo William S Fulton wrote: > I'd like to bring up a discussion of whether SWIG should generate copy > constructors and assignment operator wrappers. > > I would like to remove heaps of copy constructors from the C++ classes > being wrapped as they are not necessary and are a maintenance headache > considering the C++ compiler will generate these anyway. gcc -Weffc++ > is a great way to monitor whether a custom one should be written btw. > The problem is that SWIG does not generate a copy constructor like a > C++ compiler does. Normally if a class does not provide the following > the compiler will generate code for them (if needed): > > - Default constructor > - Destructor > - Copy constructor > - Assignment operator > - Address of operators (const and non-const) > > SWIG supplies the first two, but non of the others. Can anybody think > of a reason why copy constructors should not be automatically > generated? The logic to generate these should be similar to generating > a default constructor, ie if not present and not private/protected, > then generate one. One other thing to consider is what the copy > constructors should be called in the target language, for example in > Java a clone() method might be most appropriate. We probably need a > virtual method lang::copyConstructorHandler() like > lang::constructorHandler() to deal with this. > > I can't see the point in generating address of operators, but the > assignment operators might be useful. This is a little more tricky to > generate as an assignment operator cannot be generated if the class > has a const member or a member that is a reference. > > William > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: > Tame your development challenges with Apache's Geronimo App Server. > Download > it for free - -and be entered to win a 42" plasma tv or your very own > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel |
From: William S F. <ws...@fu...> - 2005-11-15 20:10:03
|
Marcelo Matus wrote: > Well, as in the default constructor, the only reason would be when there is > an explicit private/protected copy constructor, or, when the class is > abstract. > > Beside that, I agree, the copy constructor it should be automatically > generated as > in the case of the default constructors. > > Other automatic things that C++ provide but swig doesn't are the > operator cast constructors, > ie, if you have: > struct A { > operator double(); > }; > > struct B { > B(double); > }; > > in C++ you can do > > A a(1.0); > B b(a); > What needs doing to add in this functionality? Which languages are working? > that problem is partially solved with the implicit.i library file, but > it doesn't work for all the > languages right now. > > And following the lines of missing things, is the dynamic cast > operations, ie, if you have > a virtual class, you always can do: > > A *ad = dynamic_cast<A*>(vptr); > > I remember we discuss this point some time ago, but never agree in a > proper name to the > dynamic cast method, which in python it should be a static method that > would look like: > > a = A.dynamic_cast(vptr) > > But back to the point, we could add a feature "copyconstructor" in the > same way we have > now the "defaultconstructor", and use it accordingly. > Yes, although I think you mean %makedefault and %nodefault ("nodefault" feature). I'd advocate turning copy constructor generation on by default and then the "copyconstructor" feature can be used to turn it off. Of course they can be globally turned off and selectively turned on as well using the feature. Would the -nodefault commandline option and "nodefault" feature also turn it off? I guess it makes sense if it did, but then we'd need to decide if the "nodefault" or "copyconstructor" feature had precedence. You got any spare cycles and fancy implementing this Marcelo? William > Marcelo > > William S Fulton wrote: > >> I'd like to bring up a discussion of whether SWIG should generate copy >> constructors and assignment operator wrappers. >> >> I would like to remove heaps of copy constructors from the C++ classes >> being wrapped as they are not necessary and are a maintenance headache >> considering the C++ compiler will generate these anyway. gcc -Weffc++ >> is a great way to monitor whether a custom one should be written btw. >> The problem is that SWIG does not generate a copy constructor like a >> C++ compiler does. Normally if a class does not provide the following >> the compiler will generate code for them (if needed): >> >> - Default constructor >> - Destructor >> - Copy constructor >> - Assignment operator >> - Address of operators (const and non-const) >> >> SWIG supplies the first two, but non of the others. Can anybody think >> of a reason why copy constructors should not be automatically >> generated? The logic to generate these should be similar to generating >> a default constructor, ie if not present and not private/protected, >> then generate one. One other thing to consider is what the copy >> constructors should be called in the target language, for example in >> Java a clone() method might be most appropriate. We probably need a >> virtual method lang::copyConstructorHandler() like >> lang::constructorHandler() to deal with this. >> >> I can't see the point in generating address of operators, but the >> assignment operators might be useful. This is a little more tricky to >> generate as an assignment operator cannot be generated if the class >> has a const member or a member that is a reference. >> >> William >> >> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by: >> Tame your development challenges with Apache's Geronimo App Server. >> Download >> it for free - -and be entered to win a 42" plasma tv or your very own >> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php >> _______________________________________________ >> Swig-devel mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-devel > > > |