From skaller at maxtal.com.au Fri Jul 9 21:36:57 1999 From: skaller at maxtal.com.au (John Skaller) Date: Sat, 10 Jul 1999 05:36:57 +1000 Subject: [C++-SIG] Restarting In-Reply-To: <14120.33524.187016.316996@zork.actel.com> References: <199904291447.JAA29865@tartarus.cs.uchicago.edu> <14120.924.420287.392618@zork.actel.com> <199904291447.JAA29865@tartarus.cs.uchicago.edu> Message-ID: <3.0.6.32.19990710053657.0096eaf0@mail.triode.net.au> At 09:04 29/04/99 -0700, Geoffrey Furnish wrote: >I think the Python C++ bindings should live in namespace Py. Something more like org::python::Py would provide better identification perhaps? >I think we should keep avoid use of partial specialization since MS >won't have it until at least VC++ 7.0. >I think we should avoid having any part of the C++ binding /depend/ on >member templates, because Sun 5.0 doesn't have them. >I think we should provide some conveniences as optional facilities >that are implemented with member templates. I really don't see why you need this complication. A C++ binding to python doesn't need any templates at all. Two things ared required: 1) a new python type whose 'methods' map onto a single C++ virtual base representing a PyObject. (It won't quite work right, because python checks the C vtable for 'isSequence' etc). 2) C++ types representing python types (This work has already been done and posted here). Templates, member templates, and other fancy features are not required: python has dynamic genericity, templates are not useful here. ------------------------------------------------------- John Skaller email: skaller at maxtal.com.au http://www.maxtal.com.au/~skaller phone: 61-2-96600850 snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia From furnish at actel.com Sat Jul 10 07:17:28 1999 From: furnish at actel.com (Geoffrey Furnish) Date: Fri, 9 Jul 1999 22:17:28 -0700 (PDT) Subject: [C++-SIG] Restarting In-Reply-To: <3.0.6.32.19990710053657.0096eaf0@mail.triode.net.au> References: <199904291447.JAA29865@tartarus.cs.uchicago.edu> <14120.924.420287.392618@zork.actel.com> <3.0.6.32.19990710053657.0096eaf0@mail.triode.net.au> Message-ID: <14214.55144.37002.851331@zork.actel.com> John Skaller writes: > At 09:04 29/04/99 -0700, Geoffrey Furnish wrote: > > >I think the Python C++ bindings should live in namespace Py. > > Something more like > > org::python::Py > > would provide better identification perhaps? Why is this desirable? This doesn't follow any widespread convention that I am familiar with. For example, the STL and other parts of the C++ standard library are in std::, not org::ISO::std::. Is this a trend that is showing up in modern post-standardization C++ culture? Can you point to examples of other similar packages following this convention? > >I think we should keep avoid use of partial specialization since MS > >won't have it until at least VC++ 7.0. > >I think we should avoid having any part of the C++ binding /depend/ on > >member templates, because Sun 5.0 doesn't have them. > >I think we should provide some conveniences as optional facilities > >that are implemented with member templates. > > I really don't see why you need this complication. > A C++ binding to python doesn't need any templates at all. I thinik this depends a lot on what you're goals are. There are things I want, that are best accomplished with templates. > Two things ared required: > > 1) a new python type whose 'methods' map > onto a single C++ virtual base representing a PyObject. > (It won't quite work right, because python checks the > C vtable for 'isSequence' etc). Could you sketch this idea out a little more fully please? > 2) C++ types representing python types > (This work has already been done and posted here). Paul's work covers a lot of the API. But I don't think your options 1) and 2) represent the sum toto of what one might like to accomplish in a Python binding to C++. > Templates, member templates, and other fancy features > are not required: python has dynamic genericity, > templates are not useful here. I'm going to beg to differ here. Maybe everything you, and perhaps some other people, want, can be done without templates. Some things I want, defintely are most robustly implemented with templates. I fundamentally don't understand the "keep language feature XXX out of the interface!" argument. There are all kinds of things in the Python language proper that I don't use, but I've never advocated that they be thrown away. People use what they want to use, and don't use what doesn't suit their personal purpose. That's no argument that things should be thrown out that others might very well find extremely beneficial. Here is an example of something I consider to be extraordinarily useful, which can basically only be implemented with member templates: PyObject *MyExtensionFunc( PyObject *self, PyArgTuple *args ) { int x; float y; SomeOtherUserDefinedType z; args->ParseTuple( x, y, z ); // Do work given now initialized values for x, y and z. } This sort of an interface to parsing tuples is desirable for the same sorts of reasons that C++ iostreams have banished printf-style format strings. Do you want to parse tuples this way? Perhaps not. Do I? Absolutely. Will anyone else? Undoubtedly some. Everyone? Undoubtedly not. Should we all loose a type-safe error free way to parse arg tuples just because you don't want any occurances of the "template" keyword in the Python extension interface? Frankly, that's a really tough argument for me to see. Please feel free to post code that exhibits what you think should be done. I'll be happy to put it up on the www site too, to make it easy for folks to review. I have some work coming along that I'll post soon too. I'm afraid it's been going a little slower than I hoped. My family got hit by a nasty, and prolonged illness this summer, and I've been struggling to keep up with my day job. My evening hacking time has been cut really short the last few weeks, and we're not quite through it yet. Anyway, it's nearing a presentable point, and I'll get it up for others to see AFAP. Cheers to all, -- Geoffrey Furnish Actel Corporation furnish at actel.com Senior Staff Engineer 955 East Arques Ave voice: 408-522-7528 Placement & Routing Sunnyvale, CA 94086-4533 fax: 408-328-2303 "... because only those who write the code truly control the project." -- Jamie Zawinski From skaller at maxtal.com.au Sun Jul 11 18:26:45 1999 From: skaller at maxtal.com.au (John Skaller) Date: Mon, 12 Jul 1999 02:26:45 +1000 Subject: [C++-SIG] Restarting In-Reply-To: <14214.55144.37002.851331@zork.actel.com> References: <3.0.6.32.19990710053657.0096eaf0@mail.triode.net.au> <199904291447.JAA29865@tartarus.cs.uchicago.edu> <14120.924.420287.392618@zork.actel.com> <3.0.6.32.19990710053657.0096eaf0@mail.triode.net.au> Message-ID: <3.0.6.32.19990712022645.0096cd30@mail.triode.net.au> At 22:17 9/07/99 -0700, Geoffrey Furnish wrote: >John Skaller writes: > > Something more like > > > > org::python::Py > > > > would provide better identification perhaps? > >Why is this desirable? Because if _your_ python bindings live in namespace Py, and _my_ python bindings live in namespace Py, we have a clash. "Py" is an absurdly short name for a proprietary namespace. >This doesn't follow any widespread convention >that I am familiar with. Yes it does: the Java convention. In particular, the (reversed) name of the authoritative web site is a useful convention for naming packages. >For example, the STL and other parts of the >C++ standard library are in std::, not org::ISO::std::. The C++ standard library is kind of special! >Is this a >trend that is showing up in modern post-standardization C++ culture? I have no idea. >Can you point to examples of other similar packages following this >convention? No. > > Two things ared required: > > > > 1) a new python type whose 'methods' map > > onto a single C++ virtual base representing a PyObject. > > (It won't quite work right, because python checks the > > C vtable for 'isSequence' etc). > >Could you sketch this idea out a little more fully please? Sure. Create a C python type: cpp_interface in the usual way, with the tables of methods such as 'get_attr', 'repr' etc. include all methods: all sequence methods, all number methods, etc. The type has a single pointer in it: a pointer to cpp_client which is a virtual base. Each C method is like this: PyObject *length(PyObject *obj) { try { cpp_client *p =((cpp_interface*)obj)->length(); return MakeCppInterface(p); } catch "Unimplemented Method" { return 0 } } that is, it delegates to the cpp_client object. MakeCppInterface make the interface object with pointer to the return C++ object. Because of the (silly) way python overloads methods, there will be a conflict between dictionaries and sequences (length and indexing); so it may be that two interfaces are required. The virtual base cpp_client implements ALL methods the same way: by throwing an exception. > > 2) C++ types representing python types > > (This work has already been done and posted here). > >Paul's work covers a lot of the API. But I don't think your options >1) and 2) represent the sum toto of what one might like to accomplish >in a Python binding to C++. Perhaps that is true: the idea is first to discover the minimal interface. It is necessary to 'get at' C++ implemented types from python, and to 'get at' python types from C++. Thus, two interfaces are required, one in each direction. To 'get at' python types from C++, one only needs a single interface: again represented by a virtual base from which wrappers to dictionaries, tuples, etc are derived. This means C++ can get at python thru a type CppPyObjectWrapper, and python can get at C++ thru cpp_client. (the names need to be changed to something sensible :-) > > Templates, member templates, and other fancy features > > are not required: python has dynamic genericity, > > templates are not useful here. > >I'm going to beg to differ here. Maybe everything you, and perhaps >some other people, want, can be done without templates. Some things I >want, defintely are most robustly implemented with templates. I >fundamentally don't understand the "keep language feature XXX out of >the interface!" argument. Templates are useful for static genericity. Python is intrinsically dynamic, there is only one kind of object, PyObject. [] >Do you want to parse tuples this way? Perhaps not. Do I? >Absolutely. Will anyone else? Undoubtedly some. Everyone? >Undoubtedly not. Should we all loose a type-safe error free way to >parse arg tuples just because you don't want any occurances of the >"template" keyword in the Python extension interface? Frankly, that's >a really tough argument for me to see. I don't see any 'templates' above. I've done extensive work with templates. I'm not against templates. But I am suggesting that using them involves a risk; especially member templates. The lookup rules are not solid, and neither are implementations. ------------------------------------------------------- John Skaller email: skaller at maxtal.com.au http://www.maxtal.com.au/~skaller phone: 61-2-96600850 snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia From alex at inconcert.com Wed Jul 14 17:06:41 1999 From: alex at inconcert.com (Alexis Layton) Date: Wed, 14 Jul 1999 11:06:41 -0400 (EDT) Subject: [C++-SIG] Restarting Message-ID: <199907141506.LAA21466@inconcert.com> Speaking as one who has to use the compilers in question, the proposal seems eminently sensible to me. Alexis Layton InConcert Incorporated, Sr. Software Engineer A Xerox New Enterprises Company alex at InConcert.COM Four Cambridge Center +1 617 499-4443 Cambridge, MA 02142-1494 From furnish at actel.com Wed Jul 14 17:29:00 1999 From: furnish at actel.com (Geoffrey Furnish) Date: Wed, 14 Jul 1999 08:29:00 -0700 (PDT) Subject: [C++-SIG] Restarting In-Reply-To: <199907141506.LAA21466@inconcert.com> References: <199907141506.LAA21466@inconcert.com> Message-ID: <14220.44220.816407.781223@zork.actel.com> Alexis Layton writes: > Speaking as one who has to use the compilers in question, the proposal > seems eminently sensible to me. Could you be a little more explicit? You favor exactly what proposal? And you use exactly which compiler(s)? Particularly in the case of borderline contentious discussions, it is very helpful to be totally explicit, and not rely upon assumed understandings. -- Geoffrey Furnish Actel Corporation furnish at actel.com Senior Staff Engineer 955 East Arques Ave voice: 408-522-7528 Placement & Routing Sunnyvale, CA 94086-4533 fax: 408-328-2303 "... because only those who write the code truly control the project." -- Jamie Zawinski From dubois1 at llnl.gov Wed Jul 14 17:59:34 1999 From: dubois1 at llnl.gov (Paul F. Dubois) Date: Wed, 14 Jul 1999 08:59:34 -0700 Subject: [C++-SIG] CXX3.tgz available, compiles with EGCS snapshot Message-ID: <99071409083300.28471@almanac> CXX is a package for extending Python with C++. David Ascher and I are working on making Numerical use ExtensionClass and plan to release a beta of it for community testing. Since we are doing this rather than making a normal release 12, in the meantime I wanted to make available my version of CXX that compiles with EGCS as of the snapshot of June 16. Compile times are slow but not utterly unbearable. So, if lack of a commercial license for a better compiler has prevented you from trying CXX, you can try it now. ftp://ftp-icf.llnl.gov/pub/python/CXX3.tgz CXX is described in my paper that appeared in the Seventh International Python conference proceedings. Documentation is on-line at : http://xfiles.llnl.gov The document is also included in the distribution. From alex at inconcert.com Wed Jul 14 18:22:59 1999 From: alex at inconcert.com (Alexis Layton) Date: Wed, 14 Jul 1999 12:22:59 -0400 (EDT) Subject: [C++-SIG] Restarting Message-ID: <199907141622.MAA19252@inconcert.com> Geoffrey, I was responding to your message of a week ago, in which you stated a laundry list: > I think the Python C++ bindings should live in namespace Py. > I think we should keep avoid use of partial specialization since MS > won't have it until at least VC++ 7.0. > I think we should avoid having any part of the C++ binding /depend/ on > member templates, because Sun 5.0 doesn't have them. > I think we should provide some conveniences as optional facilities > that are implemented with member templates. By making these "inline > member templates", they'll work with MS VC++ 6.0, Code Warior, EDG > variants, egcs. Perhaps this could be controlled via "member template > autodetection" in the configure, resulting in a config.h flag that > would allow CPP based inclusion or exclusion of these facilities, > depending on whether the compiler the user is using at configure time, > is up to the task or not. > For compilers, we use SC5.0 for Sun, and HP's aCC on HP-UX. (As a company we tend to support "native" compilers on commercial OS for our product (InConcert), and that is what we are interested in extending with Python. Alexis Layton InConcert Incorporated, Sr. Software Engineer A Xerox New Enterprises Company alex at InConcert.COM Four Cambridge Center +1 617 499-4443 Cambridge, MA 02142-1494 From furnish at actel.com Wed Jul 14 19:19:06 1999 From: furnish at actel.com (Geoffrey Furnish) Date: Wed, 14 Jul 1999 10:19:06 -0700 (PDT) Subject: [C++-SIG] Restarting In-Reply-To: <199907141622.MAA19252@inconcert.com> References: <199907141622.MAA19252@inconcert.com> Message-ID: <14220.50826.437070.981854@zork.actel.com> Alexis Layton writes: > [...] > For compilers, we use SC5.0 for Sun, and HP's aCC on HP-UX. > (As a company we tend to support "native" compilers on commercial > OS for our product (InConcert), and that is what we are interested > in extending with Python. Great, thanks for clarifying. We use these compilers here too, so I do have access to them. -- Geoffrey Furnish Actel Corporation furnish at actel.com Senior Staff Engineer 955 East Arques Ave voice: 408-522-7528 Placement & Routing Sunnyvale, CA 94086-4533 fax: 408-328-2303 "... because only those who write the code truly control the project." -- Jamie Zawinski From Paul_Miller at avid.com Wed Jul 14 19:29:46 1999 From: Paul_Miller at avid.com (Paul Miller) Date: Wed, 14 Jul 1999 13:29:46 -0400 Subject: [C++-SIG] Restarting References: Message-ID: <378CC90A.4CC7E6C0@avid.com> > > For compilers, we use SC5.0 for Sun, and HP's aCC on HP-UX. > > (As a company we tend to support "native" compilers on commercial > > OS for our product (InConcert), and that is what we are interested > > in extending with Python. > > Great, thanks for clarifying. We use these compilers here too, so I > do have access to them. We're using SGI MIPSPro 7.3, so feel free to throw any C++ construct you want at the problem. But we also have to use MSVC++, so try to avoid using any new C++ stuff. :-) As for making use of C++ features, I'm all for getting it added as a supported Python extension. You shouldn't have any problems with exceptions and basic templates, though. For now, I wrap my C++ objects as reference-counted smart pointers inside Python extension objects, and implement the method dispatch using the "C" technique. This works great, and I know exactly what is going on. -Paul -- Paul T. Miller | Paul_Miller at avid.com Principal Engineer | Opinions expressed here are my own. Avid Technology, Inc. - Graphics and Effects Software Group From poinot at onera.fr Mon Jul 19 16:44:39 1999 From: poinot at onera.fr (Marc POINOT) Date: Mon, 19 Jul 1999 16:44:39 +0200 Subject: [C++-SIG] CXX3.tgz available, compiles with EGCS snapshot References: <99071409083300.28471@almanac> Message-ID: <379339D7.457473F6@onera.fr> "Paul F. Dubois" wrote: > CXX is a package for extending Python with C++. > > David Ascher and I are working on making Numerical use ExtensionClass and plan > to release a beta of it for community testing. Since we are doing this rather > than making a normal release 12, in the meantime I wanted to make available my > version of CXX that compiles with EGCS as of the snapshot of June 16. Compile > times are slow but not utterly unbearable. So, if lack of a commercial license > for a better compiler has prevented you from trying CXX, you can try it now. I tryed it on my DEC cxx compiler, and it's ok with these two tiny modifications: 1- change the LD command in Makefile.pre.in with LDSHARED= cxx -shared -expect_unresolved "*" (but I guess it's one of our local config problem here, as the Makefile.pre.in takes it from the config). 2- change all uses of STD::cout, STD::endl, STD::ostream, etc... with ::cout, ::endl, etc... This means our cxx iostream lib has a global scope. This is (certainly) temporary, but I add a STDIOSTREAM macro that makes more detailled the use of the STD macro. Here's the diff below with original (CXX3) and the DEC (CXX3.dec). The host version/compiler was: OSF1 xxx V4.0 878 alpha DIGITAL C++ V6.1-027 on DIGITAL UNIX V4.0 (Rev. 878) Marcvs [alias Aaaaah, now I'm going to work with this nice C++ toolkit extension !] ----------------------------------------------------------------- 65c65 < STD::cout << "|" << c6 << "|" << STD::endl; --- > STDIOSTREAM::cout << "|" << c6 << "|" << STDIOSTREAM::endl; diff -r CXX3/CXX/Demo/r.h CXX3.dec/CXX/Demo/r.h 6c6 < USING(STD::ostrstream) --- > USING(STDIOSTREAM::ostrstream) 23c23 < std::cout << "r created " << this << std::endl; --- > STDIOSTREAM::cout << "r created " << this << STDIOSTREAM::endl; 28c28 < std::cout << "r destroyed " << this << std::endl; --- > STDIOSTREAM::cout << "r destroyed " << this << STDIOSTREAM::endl; 52c52 < s << "r(" << start << ", " << stop << ", " << step << ")" << STD::ends; --- > s << "r(" << start << ", " << stop << ", " << step << ")" << STDIOSTREAM::ends; diff -r CXX3/CXX/Demo/rtest.cxx CXX3.dec/CXX/Demo/rtest.cxx 7c7 < STD::cout << "r::check failed (1)."; --- > STDIOSTREAM::cout << "r::check failed (1)."; diff -r CXX3/CXX/Include/CXX_Config.h CXX3.dec/CXX/Include/CXX_Config.h 10a11,12 > #define STDIOSTREAM > diff -r CXX3/CXX/Include/CXX_Objects.h CXX3.dec/CXX/Include/CXX_Objects.h 363c363 < STD::ostream& operator<< (STD::ostream& os, const Object& ob); --- > STDIOSTREAM::ostream& operator<< (STDIOSTREAM::ostream& os, const Object& ob); diff -r CXX3/CXX/Src/cxxsupport.cxx CXX3.dec/CXX/Src/cxxsupport.cxx 35c35 < STD::ostream& operator<< (STD::ostream& os, const Object& ob) { --- > STDIOSTREAM::ostream& operator<< (STDIOSTREAM::ostream& os, const Object& ob) { -------------------------------------------------------------------------------- From poinot at onera.fr Wed Jul 21 15:03:11 1999 From: poinot at onera.fr (Marc POINOT) Date: Wed, 21 Jul 1999 15:03:11 +0200 Subject: [C++-SIG] CXX3 extending with C++ classes References: <99071409083300.28471@almanac> <379339D7.457473F6@onera.fr> Message-ID: <3795C50F.5320C8CB@onera.fr> I have some problem with CXX extension. I think I have to learn more about Python extensions in general, but maybe some pythoner can help me faster ... In have succedeed in extending Python with some of our C++ classes (using CXX3). Now, I want to build extended-objects with other extended-objects as args. Here's a piece of the Python part of the code: import example v="x y z" f="file.mai" # First extended class a=example.EpyBlkMesh(45,17,17,v,f) # ok print type(a) # ok m=b[1] print type(m) # Second extended class using first one c=example.EpyGeoGrid(m) # never get here, it failed before c.volume() ------ The point is, when I look at the pointer adress of m, it is different of the one I have for a. My function EpyGeoGrid_new(PyObject *self, PyObject *args) seems to have an args type which cannot be cast to EpyGeoGrid... Any tip? Any doc reference? Marcvs [alias I didn't found such example in r.cxx Demo...] From poinot at onera.fr Wed Jul 21 17:55:49 1999 From: poinot at onera.fr (Marc POINOT) Date: Wed, 21 Jul 1999 17:55:49 +0200 Subject: [C++-SIG] CXX3 adding methods to new types References: <99071409083300.28471@almanac> <379339D7.457473F6@onera.fr> <3795C50F.5320C8CB@onera.fr> Message-ID: <3795ED85.493F541A@onera.fr> Now I can have my extended-types using other extended types. I found the magical ptr() function taht gives me the expected object pointer (is this right ?). And now, something completely different: I cannot succed in adding a new method to my types, the interpreter complains... --- static PyObject* EpyGeoGrid_value (PyObject* self, PyObject* args) { return new_reference_to(Int(2)); } void init_EpyGeoGridtype () { EpyGeoGrid::behaviors().name("EpyGeoGrid"); EpyGeoGrid::behaviors().doc("EpyGeoGrid object: GeoGrid wrapper"); EpyGeoGrid::behaviors().repr(EpyGeoGrid_repr); EpyGeoGrid::methods().add("value", EpyGeoGrid_value); } --- Traceback (innermost last): File "Demo/t.py", line 27, in ? c.value() AttributeError: 'EpyGeoGrid' object has no attribute 'value' --- Marcvs [alias Ok, now my day is done, it's up to you west coast, see you tomorrow...] From dubois1 at llnl.gov Wed Jul 21 18:01:21 1999 From: dubois1 at llnl.gov (Paul F. Dubois) Date: Wed, 21 Jul 1999 09:01:21 -0700 Subject: [C++-SIG] Re: CXX3 extending with C++ classes References: <99071409083300.28471@almanac> <379339D7.457473F6@onera.fr> <3795C50F.5320C8CB@onera.fr> Message-ID: <001c01bed392$468108a0$f4160218@plstn1.sfba.home.com> Something got lost here. What is b? However, perhaps m = a[1] and then you are using m as an argument? I suspect I know the problem. CXX uses a proxy class for the result of a[1] since you don't know at the time of subscripting whether this is a LHS or RHS use. This class has a user-defined conversion to the type of the sequence so when you use it in an expression or as a rhs of an assignment it casts itself, and the cast performs the actual "fetch". Most of the time proxy objects are suitably invisible but the fact is that they have a different type than the one you think they do and that could cause trouble when mixed with C++'s elaborate rules for automatic casts. The solution is to make the cast explicit, eg. m = Object(a[1]) (or whatever class you really think a[1] is). Proxys are discussed in Scott Meyer's books although the version I had to use was somewhat more elaborate. See the code in Sequence for details. Hope this helps, Paul ----- Original Message ----- From: Marc POINOT To: Paul F. Dubois ; Sent: Wednesday, July 21, 1999 6:03 AM Subject: CXX3 extending with C++ classes > > I have some problem with CXX extension. I think I have > to learn more about Python extensions in general, but > maybe some pythoner can help me faster ... > > In have succedeed in extending Python with some > of our C++ classes (using CXX3). > Now, I want to build extended-objects with other > extended-objects as args. Here's a piece of the Python > part of the code: > > import example > > v="x y z" > f="file.mai" > > # First extended class > a=example.EpyBlkMesh(45,17,17,v,f) > > # ok > print type(a) > > # ok > m=b[1] > print type(m) > > # Second extended class using first one > c=example.EpyGeoGrid(m) > > # never get here, it failed before > c.volume() > > ------ > The point is, when I look at the pointer adress of m, > it is different of the one I have for a. > My function EpyGeoGrid_new(PyObject *self, PyObject *args) > seems to have an args type which cannot be cast > to EpyGeoGrid... > > Any tip? > Any doc reference? > > Marcvs [alias I didn't found such example in r.cxx Demo...] > > > > From dubois1 at llnl.gov Wed Jul 21 18:24:39 1999 From: dubois1 at llnl.gov (Paul F. Dubois) Date: Wed, 21 Jul 1999 09:24:39 -0700 Subject: [C++-SIG] CXX3 adding methods to new types, issue 1 References: <99071409083300.28471@almanac> <379339D7.457473F6@onera.fr> <3795C50F.5320C8CB@onera.fr> <3795ED85.493F541A@onera.fr> Message-ID: <001701bed395$880d1860$f4160218@plstn1.sfba.home.com> ----- Original Message ----- From: Marc POINOT To: Paul F. Dubois ; Sent: Wednesday, July 21, 1999 8:55 AM Subject: [C++-SIG] CXX3 adding methods to new types > > Now I can have my extended-types using > other extended types. I found the > magical ptr() function taht gives me > the expected object pointer (is this right ?). > This works because it causes the proxy-cast I talked about. I think. Implicit casts are a nightmare and I wouldn't have used a proxy object if there was any other way. I even talked to Scott Meyers about what I was doing and he said it sounded right to him but that I was off into unexplored territory. From poinot at onera.fr Thu Jul 22 08:44:34 1999 From: poinot at onera.fr (Marc POINOT) Date: Thu, 22 Jul 1999 08:44:34 +0200 Subject: [C++-SIG] Re: CXX3 adding methods to new types References: <99071409083300.28471@almanac> <379339D7.457473F6@onera.fr> <3795C50F.5320C8CB@onera.fr> <3795ED85.493F541A@onera.fr> <002801bed396$19f69c60$f4160218@plstn1.sfba.home.com> Message-ID: <3796BDD2.87751E4D@onera.fr> "Paul F. Dubois" wrote: > Compare with demo file r.cxx; you seem to be doing everything the same. > Say, did you remember to call your object init function from some module's > init function? > > Here's what I've cloned using example.cxx : void initexample() { // experimental initialization stuff init_EpyBlkMeshtype(); init_EpyGeoGridtype(); example = new ExtensionModule("example"); example->add("EpyBlkMesh",EpyBlkMesh_new,"EpyBlkMesh(im,jm,km,var,file)"); example->add("EpyGeoGrid",EpyGeoGrid_new,"EpyGeoGrid(EpyBlkMesh)"); Dict d = example->initialize(); } Marcvs [alias Does it sounds?]