Thread: [pygccxml-development] bug detecting read_only variables
Brought to you by:
mbaas,
roman_yakovenko
From: Allen B. <al...@vr...> - 2007-03-10 21:55:03
|
I think I may have just found a corner case for the auto-detection of which exposed class variables should be read_only. I am wrapping a class that has a static member variable of a type that does not have an op=. I think the idea the class designers had is that this would keep someone from assigning to these variables after they are created. Unfortunately py++ does not detect this case right now and tries to expose this variable using def_readwrite instead of def_read. I think this could be fixed by adding some logic to variable_wrapper.variable_t.__find_out_is_read_only to check for this case. -Allen |
From: Roman Y. <rom...@gm...> - 2007-03-11 07:00:51
|
On 3/10/07, Allen Bierbaum <al...@vr...> wrote: > I think I may have just found a corner case for the auto-detection of > which exposed class variables should be read_only. I am wrapping a > class that has a static member variable of a type that does not have an > op=. I think the idea the class designers had is that this would keep > someone from assigning to these variables after they are created. > > Unfortunately py++ does not detect this case right now and tries to > expose this variable using def_readwrite instead of def_read. I think > this could be fixed by adding some logic to > variable_wrapper.variable_t.__find_out_is_read_only to check for this case. Thank you, I will take a look on this issue -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
From: Roman Y. <rom...@gm...> - 2007-03-12 18:29:47
|
On 3/10/07, Allen Bierbaum <al...@vr...> wrote: > I think I may have just found a corner case for the auto-detection of > which exposed class variables should be read_only. I am wrapping a > class that has a static member variable of a type that does not have an > op=. I think the idea the class designers had is that this would keep > someone from assigning to these variables after they are created. > > Unfortunately py++ does not detect this case right now and tries to > expose this variable using def_readwrite instead of def_read. I think > this could be fixed by adding some logic to > variable_wrapper.variable_t.__find_out_is_read_only to check for this case. Allen I took a look on your problem and I think I need your help to resolve it. Here is a full code for __find_out_is_read_only method: def __find_out_is_read_only(self): type_ = declarations.remove_alias( self.type ) if isinstance( type_, declarations.const_t ): return True if declarations.is_pointer( type_ ): type_ = declarations.remove_pointer( type_ ) if declarations.is_reference( type_ ): type_ = declarations.remove_reference( type_ ) if isinstance( type_, declarations.const_t ): return True if self.apply_smart_ptr_wa: return False #all smart pointers has assign operator if isinstance( type_, declarations.declarated_t ) \ and isinstance( type_.declaration, declarations.class_t ) \ and not declarations.has_public_assign( type_.declaration ): return True return False As you can see the last condition checks exactly what you propose. So may be you are using old version( I guess the answer is no ) or you have some interesting use case. In this case I'd like to ask you to create minimal example, which reproduces the problem. As a temporal work-around you can set "is_read_only" variable property to "True" -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |