Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Python Debugger
dmoore:
--- Quote from: oBFusCATed on July 27, 2012, 04:56:00 pm ---
--- Quote from: dmoore on July 27, 2012, 04:45:31 pm ---Re the Debugger (for obfuscated): Still stuck implementing watches. I get a crash every time I try to expand any watch that isn't the first watch item. This could be just something stupid on my part, but I suspect I may not be using cb::shared_ptr correctly. (my watch is derived from cbWatch, and there are lots of cb::shared_ptr<cbWatch> instances passed around that point to instances of my derived class)
--- End quote ---
I have to check it, but I have no time at the moment, unfortunately.
But cb::shared_ptr<Base> supports managing Derived objects, but you have to have a virtual destructor.
--- End quote ---
Fixed. Stupid mistake on my part. (Missing braces around an if statement block -- too much python!). Code appears to work fine even without a destructor.
BTW, why in some places do you use cb::shared_ptr<OBJECT> and in others OBJECT::Pointer? I like the latter a lot more and would prefer to see it everywhere that you currently have cb::shared_ptr. Also, is it necessary to defined DerivedClass::Pointer (e.g. PyWatch::Pointer). Code seems to run fine even if it is not defined explicitly, since it gets derived from the base (cbWatch::Pointer).
oBFusCATed:
dmoore: What are these places?
Probably one reason is that cb::shared_ptr<Object> compiles and works even if Object is forward declared.
Object::Pointer works only if you have the full declaration of Object and Object::Pointer can't be forward declared.
dmoore:
--- Quote from: oBFusCATed on July 30, 2012, 08:13:01 pm ---dmoore: What are these places?
--- End quote ---
virtual methods in cbDebuggerPlugin
--- Quote ---Probably one reason is that cb::shared_ptr<Object> compiles and works even if Object is forward declared.
Object::Pointer works only if you have the full declaration of Object and Object::Pointer can't be forward declared.
--- End quote ---
So you save yourself a #include in cbplugin.h, but then any debugger plugin will need that #include to implement their derived classes. Not sure I see the real advantage in doing it this way. (Why bother defining cbWatch::Pointer at all if it isn't going to be used consistently in the public facing part of the API?)
oBFusCATed:
I think these have been added as work-arounds for the impossibility to forward declare them.
The thing is that if you can forward declare something you should do it.
This saves compilation time and minimizes the include statements in headers.
C::B is pretty bad in this regard by the way...
dmoore:
--- Quote from: oBFusCATed on July 30, 2012, 10:40:11 pm ---I think these have been added as work-arounds for the impossibility to forward declare them.
The thing is that if you can forward declare something you should do it.
This saves compilation time and minimizes the include statements in headers.
C::B is pretty bad in this regard by the way...
--- End quote ---
The C::B way has been to adopt very similar coding standards to wxWidgets with all its legacy issues. I understand that there is some compile time efficiency gain to structuring your code like this, but IMHO it does not aid readability/manageability of code.
Anyway, I think there must be a better way of doing this than having two different but equivalent definitions for the pointer floating around. For me, any of these would be better:
a) use cb::shared_ptr everywhere
b) declare simple typedefs instead of defining the pointers as static class members (typedef cb::shared_ptr<cbWatch> cbWatchPtr)
c) do it more like the old C::B/wx way: pass around regular pointers.
If you don't like (c) then shouldn't we have an overall plan for moving away from old-style pointers in C::B? Having a patchwork of old and new style code is a mess.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version