[C++-SIG] CXX at Sourceforge

Marc Poinot poinot at onera.fr
Tue Mar 7 12:05:00 CET 2000


"Paul F. Dubois" wrote:
> 
> There are no ends of ideas and styles being put forward. Rather than just
> talking about the way each of you sees it, I would like to focus things by
> looking at what is there now and seeing if we understand exactly its
> strengths and weaknesses. Opinions about whether something will or won't
> compile or bloat or act badly should be backed up by actual data, not just
> speculation. Maybe that way we can keep down the noise level.
> 
The actual change of version for our CXX extension to CXX 4.2 has 
raised *no problem* (2 hours with GNU emacs). 
This almost was a syntactic translation, and
This new version is very nice, as we avoid now the C layer for argument
translation and initialization. Thanks to all developpers of CXX.

I hope you will not see this as noise, here's the list of things I
had to do to change our code, for about 35 classes of extensions.
Short and simplified examples (actual data?) are coming from our 
CGNS (Computational Fluid Dynamics data representation) extension class.
--------------------------------------------------------------
[1] Change the way to initialize the module
a- For Extension MODULE: Now change it to have a derived 
   class from ExtensionModule<T>, change init methods, etc...
   In other words make it as a class.

   class CGNS_module : public ExtensionModule<CGNS_module>
   {
    public:
     CGNS_module();
    private:
     Py::Object new_ExtCGNS(const Tuple &t) ;
   };

b- Use class-based method for initialization of the Extension CLASS
   but also for repr, getattr...
   * Make init_type() as static, otherwise you cannot reach it without
     an object instance.
  class ExtCGNS: public PythonExtension<ExtCGNS> 
  {
    public:
     ExtCGNS(STD::string wname);
    ~ExtCGNS();
     static void init(); // should be static
     ...

c- Move creation of new objects (new MyClass) into Extension MODULE
   See above new_ExtCGNS method.

[2] Remove all C stuff in the objects
a- change args with Tuple, remove tuple translation. We had the
   following macro, and the following use of the macro

#define  E_PYTHON_TO_CXX(aaa,eee,ttt) \
  Object * o##eee = new Object( aaa ); \
  ttt * eee ; eee = static_cast< ttt *>( o##eee ->ptr());

int
ExtCGNS_setattr(PyObject* self, char *name, PyObject *op)
{
  E_PYTHON_TO_CXX(self,x,ExtCGNS);
  
    if(STD::string(name)=="init") 
    {
      Array w(op);
      x->writeRefState(w);
    }
  return 0;
}

-----------------------------------
The code is now:

int ExtCGNS::setattr(const char *name, const Py::Object &o)
{
  if(STD::string(name)=="init") 
  {
    Array w(o);
    writeRefState(w);
  }
  return 0;
}

Great ! :) :)

b- returns with Py::Object
c- setattr/getattr/repr... now class methods
   * Why can't we have strings for setattr/getattr parameters?
   So that the code can be:

int ExtCGNS::setattr(const STD::string name, const Py::Object &o)
{
  if(name=="init") 
  {
    Array w(o);
    writeRefState(w);
  }
  return 0;
}

[3] Build
a- Add *simple* makefile (see end of this file)
b- compiler complains (warning) about CXX_Extensions.h, Line = 107 and 108
   * remove  ExtensionModuleBase:: qualifiers which are not necessary.
c- Use an extern "C" for init declaration of module.
   This is specific, as I put the init function into a C++ compiled file.


Sample makefile (SGI) for building a librarie with CXX

# ----------------------------------------------------
#
INCS=-I./Include -I/usr/local/include/python1.5
#
CCC=CC -64 -LANG:std
#
# use CC ar to instanciate templates (pre-linker)
AR=CC -ar -o
#
all:
	$(CCC) $(INCS) -c Src/cxx_extensions.cxx
	$(CCC) $(INCS) -c Src/cxxextensions.c
	$(CCC) $(INCS) -c Src/cxxsupport.cxx
	$(AR) libCXX.a *.o

clean:
	rm -f libCXX.a *.o
# ----------------------------------------------------


Marcvs [alias Long life CXX extensions...]




More information about the Cplusplus-sig mailing list