Re: [pygccxml-development] [pygccxml-commit] SF.net SVN: pygccxml: [570] pyplusplus_dev/pyplusplus
Brought to you by:
mbaas,
roman_yakovenko
From: Roman Y. <rom...@gm...> - 2006-09-21 18:10:56
|
On 9/21/06, Matthias Baas <ba...@ir...> wrote: > > Yes of course. First of all I committed new version that should fix the > > problem. > > No, it doesn't (because now the class mem_fun_transformed_wrapper_t is > not instantiated). I am sorry I break it. For my defence I can say that I run function_transformation unit test and it passed. Also if mem_fun_transformed_wrapper_t is not instantiated, than find_out_mem_fun_creator_classes is broken and we should fix it. > Unfortunately, I also have to say that I'm not that happy about the > workaround to force the generation of a wrapper class. This is a step > back from what was already there. The comment you put into the code > ("function transformers require wrapper") is not true. The majority of > classes in the Maya SDK (which do use function transformers) do not > require a wrapper class and I'd like to keep it that way. To quote yourself: > > "The generated code should not be too different from the one, that human > would write. I don't write code like this." Actually I do. When we discussed this feature I explain why I prefer to keep wrappers and ask you explicitly to create generated code in a wrapper. > I know that for some reason you do want to have wrapper classes in all > cases. That's why I would have added an option to control this. Please don't. This is not an option that should exist. Someday we will fix the problem in the whole project. > Actually, we could have reused an option that was already there once: > finalize. But as you reacted somewhat testily on this topic I postponed > the implementation of this functionality until this feature is > implemented (besides that, the function transformers already do add > themselves to a wrapper class if there is one, but they just don't force > the creation of a wrapper class). They should. Can you give me few good reasons to not create wrappers? > > self.curr_code_creator.associated_decl_creators.append(fwrapper) > > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > You had bug in this line. You did not added fwrapper to code creators tree. > > Thus you did not defined its logical place. Thus > > multiple_files_t.associated_decl_creators ignored it. > > All right. I've seen that you moved the associated_decl_creators list to > the class registration_based_t which is a base class for calldef_t. So > far so good. But how is this list used? What are the requirements on the > code creators that may be put into this list? They should belong to module_t code creator > Just to test how it behaves, I added a code creator to the list of a > wrapper function creator to see where it gets written. But I never > noticed a difference, no matter if it was inside > associated_code_creators or not. If the code creator was not hooked into > any other part of the code creator tree, it didn't get written at all > and if it was added to the root, it just got written into the main C++ > file. > So how is this feature used? This feature is still under development and it is possible I have bugs. I jus verified that I did not break the working code. I will try to finish the feature in a day or two -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |