From: rod <ro...@mu...> - 2006-07-27 23:00:15
|
On Friday 28 July 2006 07:03, William S Fulton wrote: > rod wrote: > > I'll try to get at least > > the same testcases running as exist for one of the other language > > modules, perhaps the C# module ? > > That's ambitious, as it is currently running at 100% :) Ah, I was (wrongly) thinking that the only completed testsuite cases were those for which a corresponding *_runme.cs existed. Is there a set of core testsuite cases listed somewhere ? If not, I'll concentrate on those which seem simplest. > You have to replicate the make targets from another language module in > Examples/Makefile.in. In there you'll see some variables surrounded by > two @ characters. These get filled in from variables 'exported' by > AC_SUBST in configure.in, eg > > configure.in: > AC_SUBST(CSHARPCFLAGS) > > Makefile.in: > CSHARPCFLAGS = @CSHARPCFLAGS@ > > This way variables for the Makefile can be set at configure time. Both > the test-suite and individual language examples rely heavily on > Examples/Makefile.in. Thanks, I'll take another look at this. > > I have tried to keep consistent with the SWIG style guidelines, but > > have made a few departures: > > > > Formatting: > > - More white space is used. so the code is a little more 'spread out'. > > - A group of variables have their identifiers lined up. > > - Braces for 'if' and loop blocks are lined up. > > Code gets copied and pasted a lot between various modules so please > follow the same style otherwise a dogs dinner will ensue, eg curly brace > positioning, tab size, 2 space indenting etc. Extra vertical space ssems > okay. My particular preference is not for the style that is used in > SWIG, but I'm not so arrogant to impose my own style on the code I > maintain. Keeping the variable names the same as other modules will also > help a lot, eg Node *n, String *tm if you aren't already doing that. Ok, I'll re-format the code to follow SWIG style. > > > Structural: > > - The declaration of the main GNAT and ADA classes has been extracted > > out of the implementation (.cxx) file and placed in their own header > > file. > > Please keep the same as the other modules and keep the class methods > inline. Again I don't personally like the current approach and find it a > bit weird, but consistency is more important than personal preference. > Your other option is to change all the modules to follow the same > pattern. Header files aren't actually needed as each module is self > contained. Maybe you are deriving one Ada module from another? Initially, I had thought there might perhaps be enough in common between the two modules to warrant deriving each from a common base class, though this is doubtful now. The other reason was to reduce the size of the .cxx files, to help make a them a little more manageable. I would volunteer to modify the other language modules to this pattern, if that is an option and will not upset the other language developers. I don't think it would take too long, and should not break the code in any way. Still, as a newcomer, I don't wish to stir things up too much. I can re-merge the .h file, if that is preferred. > > > - Several support classes exist and have been placed in separate > > directories (ada, ada_common, gnat) within the Source/Modules directory. > > Why a separate directory? Every other target language has managed to > contain itself to one file, even very similar languages like the LISP > family of languages. Perhaps you need to explain why your structure > needs to be so different to others. Can't you put the support code into > a common gnat file in the Modules directory? I guess I've adopted an 'Ada-ish' style for the c++ code, in which each class has it's own header and implementation file. As you suggest, there is no pressing need for this setup; the files can be merged into a single support file, or even into the module file itself. My only concern is that this will make for huge files. > > > And, finally, the 'gnat' module requires knowledge of the protected > > and private members of a c++ class being wrapped. To enable this, the > > 'gnat' module overrides several of Lang class functions, which are not > > normally overridden (cDeclaration, accessDeclaration). cDeclaration, > > however, uses functions which are private to 'Lang', and so these private > > functions needed to be available to the 'gnat' module. To make the needed > > private Lang functions available, I added the following to swigmod.h: > > > > extern "C" > > { > > Node* Lang_CurrentClass (); > > String* Lang_ClassName (); > > int Lang_AddExtern (); > > int Lang_ForceExtern (); > > Node* Lang_first_nontemplate (Node* n); > > } > > > > These functions are defined in 'lang.cxx' and simply provide access to > > the appropriate Lang class function. I chose the extern "C" approach, > > rather than changing the access modes from private to protected, to > > minimise any impact on other language modules. > > > > > > I don't see how changing methods from private to protected will impact > other modules. > I'd rather see a traditional C++ approach than a C hack > and provide protected accessors to the private members. Yes, this was my preferred approach. The only reason I chose the extern "C" method (ok, hack ;-) was a wish not to modify any part of the Lang class, as I thought this might be frowned upon. > Out of interest, why do you need knowledge about private and protected > members that you are wrapping? SWIG doesn't allow access to these for > what I thought was fairly obvious and good reasons except where needed: > ie, director protected virtual methods. The record layout of the Ada class needs to match the C++ class record layout exactly, so knowledge of any protected or private class member variables is required. regards. |