From: rod <ro...@mu...> - 2006-07-23 20:01:37
|
Hello, I've been working on an Ada language support for SWIG and was hoping the code might be considered for inclusion into the SWIG cvs. There are two language modules under development. The 'ada' module follows the usual SWIG approach, using wrappers, and is intended to provide fully portable Ada bindings. This module is the more complete of the two, at the moment. The 'gnat' module generates Ada bindings in which an Ada class object is the binary equivalent of the corresponding C++ class object. The 'gnat' module bindings are much cleaner but will be usable only with the GCC or GNAT Ada compilers. Both modules are still far from complete, but are more or less working for the standard 'class', 'enum', 'functptr', 'reference', 'simple', 'template' and 'variables' examples. The 'ada' module also works with several of the testsuite cases (aggregate.i, bools.i, char_strings.i, constover.i, deafult_args.i, default_constructor.i, enum_thorough.i & director_default.i), as well as the ODE rigid body dynamics and CrystalSpace graphics libraries. The 'gnat' module also has a custom example (animals.i) which demonstrates binding to a multiply inherited C++ class, mapping Ada05 interface types to C++ pure abstract base classes. I've added 'ada' and 'gnat' module sections to the configuration files for the make system, the examples and the testsuite, but am unfamiliar with these and so they likely incorrect, as they stand. I plan to start on the SWIG Manual chapters, for each module, over the next few days and hope to have a cvs patch ready sometime early next month, assuming the modules qualify for inclusion. Also, the code for each module (especially 'gnat') is fairly rough, being little more than protoypes, and under heavy development, which will likely continue for several months. Placing the code into the SWIG cvs would allow others from the Ada community to try out or test the modules, and perhaps even encourage a few to join the project. When the documentation is complete, would these modules then qualify for cvs inclusion ? regards, Rod. |
From: William S F. <ws...@fu...> - 2006-07-24 21:08:41
|
rod wrote: > Hello, > > I've been working on an Ada language support for SWIG and was hoping the > code might be considered for inclusion into the SWIG cvs. > > There are two language modules under development. > > The 'ada' module follows the usual SWIG approach, using wrappers, and is > intended to provide fully portable Ada bindings. This module is the more > complete of the two, at the moment. > > The 'gnat' module generates Ada bindings in which an Ada class object is > the binary equivalent of the corresponding C++ class object. The 'gnat' > module bindings are much cleaner but will be usable only with the GCC or GNAT > Ada compilers. > > Both modules are still far from complete, but are more or less working for > the standard 'class', 'enum', 'functptr', 'reference', 'simple', 'template' > and 'variables' examples. > > The 'ada' module also works with several of the testsuite cases > (aggregate.i, bools.i, char_strings.i, constover.i, deafult_args.i, > default_constructor.i, enum_thorough.i & director_default.i), as well as the > ODE rigid body dynamics and CrystalSpace graphics libraries. > > The 'gnat' module also has a custom example (animals.i) which demonstrates > binding to a multiply inherited C++ class, mapping Ada05 interface types to > C++ pure abstract base classes. > > > I've added 'ada' and 'gnat' module sections to the configuration files for > the make system, the examples and the testsuite, but am unfamiliar with these > and so they likely incorrect, as they stand. > > > I plan to start on the SWIG Manual chapters, for each module, over the next > few days and hope to have a cvs patch ready sometime early next month, > assuming the modules qualify for inclusion. > > > Also, the code for each module (especially 'gnat') is fairly rough, being > little more than protoypes, and under heavy development, which will likely > continue for several months. Placing the code into the SWIG cvs would allow > others from the Ada community to try out or test the modules, and perhaps > even encourage a few to join the project. > > > When the documentation is complete, would these modules then qualify for > cvs inclusion ? > Hi Rod Ada would be a welcome addition to SWIG as it is certainly a widely known language, but how widely it is used nowadays I'm not sure. Anyway, it looks like you are doing all the right things to get the module ready for inclusion into SWIG. The latest prerequisites are here: http://swig.cvs.sourceforge.net/*checkout*/swig/SWIG/Doc/Manual/Extending.html#Extending_prerequisites So really you need to get a few more test-suite testcases to pass. We've a few language modules that got committed then no more development happened to them, so I would rather avoid that happening again. If you are sure you are going to commit to maintaining the module with the aim of getting all the test-suite to pass, then I'll get you cvs access when you have your patch ready. I can help get the autoconf and the Makefiles set up, but it isn't much more than a copy paste job from the other languages. Even if your modules are quite rough, that's okay, but please try and format everything keeping to the same style as the other language modules. William |
From: rod <ro...@mu...> - 2006-07-26 19:13:08
|
On Tuesday 25 July 2006 07:03, William S Fulton wrote: > > So really you need to get a few more test-suite testcases to pass. Ah, ok then, I have some more work to do :-). I'll try to get at least the same testcases running as exist for one of the other language modules, perhaps the C# module ? > We've a few language modules that got committed then no more development > happened to them, so I would rather avoid that happening again. If you > are sure you are going to commit to maintaining the module with the aim > of getting all the test-suite to pass, then I'll get you cvs access when > you have your patch ready. I plan to continue developing both modules. Several Ada projects I am involved in would greatly benefit from SWIG generated C++/Ada library bindings. Also, since starting, I have become somewhat interested in the process of generating automatic bindings. There has also been considerable interest in the SWIG Ada modules expressed on the comp.lang.ada newsgroup and several tentative offers to help. Perhaps more significantly, the developers of the GCC/GNAT Ada compiler have kindly offered and provided technical assistance for the 'gnat' module. So I hope I can offer a reasonably solid commitment to the ongoing completion of the modules. > > I can help get the autoconf and the Makefiles set up, but it isn't much > more than a copy paste job from the other languages. Thank you, that is quite a relief. I have made sections for the Ada modules in the makefiles (using other languages as a template), but I expect I missed something in the translation. Building the modules is not a problem (ie 'make' and 'make install' work ok), but the other area's (Examples & testsuite) seem not to work as expected. > Even if your modules are quite rough, that's okay, but please try and format > everything keeping to the same style as the other language modules. 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. 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. - Several support classes exist and have been placed in separate directories (ada, ada_common, gnat) within the Source/Modules directory. 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. If any of these deviations are unacceptable, I will try to address them. regards. |
From: William S F. <ws...@fu...> - 2006-07-27 21:09:11
|
rod wrote: > On Tuesday 25 July 2006 07:03, William S Fulton wrote: >> So really you need to get a few more test-suite testcases to pass. > > Ah, ok then, I have some more work to do :-). 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% :) >> We've a few language modules that got committed then no more development >> happened to them, so I would rather avoid that happening again. If you >> are sure you are going to commit to maintaining the module with the aim >> of getting all the test-suite to pass, then I'll get you cvs access when >> you have your patch ready. > > I plan to continue developing both modules. Several Ada projects I am > involved in would greatly benefit from SWIG generated C++/Ada library > bindings. Also, since starting, I have become somewhat interested in the > process of generating automatic bindings. > > There has also been considerable interest in the SWIG Ada modules expressed > on the comp.lang.ada newsgroup and several tentative offers to help. Perhaps > more significantly, the developers of the GCC/GNAT Ada compiler have kindly > offered and provided technical assistance for the 'gnat' module. > > So I hope I can offer a reasonably solid commitment to the ongoing > completion of the modules. > > Sounds excellent. >> I can help get the autoconf and the Makefiles set up, but it isn't much >> more than a copy paste job from the other languages. > > Thank you, that is quite a relief. I have made sections for the Ada modules > in the makefiles (using other languages as a template), but I expect I missed > something in the translation. Building the modules is not a problem > (ie 'make' and 'make install' work ok), but the other area's (Examples & > testsuite) seem not to work as expected. > > 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. > >> Even if your modules are quite rough, that's okay, but please try and format >> everything keeping to the same style as the other language modules. > > 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. > > 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? > - 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? > 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. > > > If any of these deviations are unacceptable, I will try to address them. > 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. 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. William |
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. |
From: William S F. <ws...@fu...> - 2006-07-31 20:27:02
|
rod wrote: > 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. > There are two parts to the test cases, 1) Making them compile and 2) Providing runtime tests. Just making the wrappers compile is a very good indication that the language module is in a fairly healthy state. For the strongly typed languages it indicates the module is in an excellent state due to the type checking provided by the target language compiler. Also, if one language is passing all the tests, it is also a good indication that the other languages will be okay as many of the tests are corner cases for the core. A lot of the logic is common and you are encouraged to copy and paste your code from other language modules to make this more likely. Runtime tests are more important for interpreted languages but are the ultimate test. Once the simple and class examples are running correctly, a lot of the work has been done and I'd concentrate on writing the typemaps to get the whole test-suite compiling 100%. Then, just start writing runtime tests, with blatant copying and converting of runtime tests from other languages, plus add in any new runtime tests for anything that is particularly important for you. > >> 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. > Cool, it will help everyone long term. > >>> 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. > Only once you have shown that your own language module works well, then you'll find everyone will be happier if you start touching other files outside of your core module. Don't forget though that needless formatting changes mess up the diff history. > >>> - 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. > Everyone works differently, but I find one or two big files with self contained code are easier to find your way around than many little files when moving around the code; * is your friend if you use vim (or CTRL-K in Eclipse, or CTRL-F3 in visual studio). > >>> 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. > Changes to the core are welcome, so long as everything else still works and is absolutely necessary. Any basic changes like changing private to protected should be okay, but anything more will mean you must run the test-suite for all languages (well at least the 6-8 large ones) ensuring there are no regressions. > >> 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. > Interesting thanks. William |
From: rod <ro...@mu...> - 2006-08-02 21:53:44
|
On Tuesday 01 August 2006 06:21, William S Fulton wrote: > > There are two parts to the test cases, 1) Making them compile and 2) > Providing runtime tests. Just making the wrappers compile is a very good > indication that the language module is in a fairly healthy state. For > the strongly typed languages it indicates the module is in an excellent > state due to the type checking provided by the target language compiler. > Also, if one language is passing all the tests, it is also a good > indication that the other languages will be okay as many of the tests > are corner cases for the core. A lot of the logic is common and you are > encouraged to copy and paste your code from other language modules to > make this more likely. Runtime tests are more important for interpreted > languages but are the ultimate test. Once the simple and class examples > are running correctly, a lot of the work has been done and I'd > concentrate on writing the typemaps to get the whole test-suite > compiling 100%. Then, just start writing runtime tests, with blatant > copying and converting of runtime tests from other languages, plus add > in any new runtime tests for anything that is particularly important for > you. Testcases are now the main priority for both modules. I'll spend a few weeks with these, and let you know how I get on. > >>> 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? > > > > 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. > > Only once you have shown that your own language module works well, then > you'll find everyone will be happier if you start touching other files > outside of your core module. Don't forget though that needless > formatting changes mess up the diff history. Fair enough ... also probably more work than I had at first thought. I'll re-inline each modules class functions into their respective headers. > > 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. > > Everyone works differently, but I find one or two big files with self > contained code are easier to find your way around than many little files > when moving around the code; * is your friend if you use vim (or CTRL-K > in Eclipse, or CTRL-F3 in visual studio). I've only been using text editors. I guess I should look into a decent C++ IDE to make life a little easier. > >> 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. > > Changes to the core are welcome, so long as everything else still works > and is absolutely necessary. Any basic changes like changing private to > protected should be okay, but anything more will mean you must run the > test-suite for all languages (well at least the 6-8 large ones) ensuring > there are no regressions. Ah, great. I'll get rid of the hack and change the access to protected for the needed functions. |
From: William S F. <ws...@fu...> - 2006-08-03 08:39:33
|
rod <rodkay <at> mullum.com.au> writes: > > > 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. > > > > Everyone works differently, but I find one or two big files with self > > contained code are easier to find your way around than many little files > > when moving around the code; * is your friend if you use vim (or CTRL-K > > in Eclipse, or CTRL-F3 in visual studio). > > I've only been using text editors. I guess I should look into a decent C++ > IDE to make life a little easier. > This shortcut is just to search for exact word matches at the cursor within the same file. Any decent text editor will offer this, so an IDE is not absolutely necessary. Eclipse CDT strikes me as being really good at navigating around the code, perhaps better than visual studio and SourceNavigator. I still tend to fire up vim though for any serious editing sessions :) William |