Date
1 - 2 of 2
[ocs-dev] OCS v0.5.5 posted
|
Jeremy Selan <jeremy...@...>
The use of tr1 shared_ptr is only a stub. When we get multi-platform
stuff sorted out that section will definitely be replaced with platform / compiler specific #ifdefs. Any shared_ptr that provides a dynamic_cast will suffice. (tr1 does work on osx already though :) ) First a justification of shared_ptrs in general... We've spend a long time thinking about object ownership and object lifetimes, and the choice to expose a smart pointer was not arrived at lightly. I do not see a graceful alternative. If people are interested we should probably discuss this further to bring everyone on board. (Or to prove me wrong!) The quick summary is that in the context of multi-threaded apps, where there exists a 'global' config people can get/set, you need to have some form of reference counting to assure that configs aren't destroyed while still in use. I would have ended up just re inventing a shared_ptr / intrusive_ptr, so it seemed expedient to just use a real one. It will also allow for a more simper python use model, as objects can now be created on either side of the fence (C++ or python) and passed back and forth without concern for object lifetime. (Keeping a reference to the python object will keep the C++ object alive, which is very desirable). This will particularly be useful in python UIs that make use of the mutable API. (To create and edit configs 'live') One related thing of note - all exposed objects which use shared-ptrs have private constructors; the only way to create them is with static factory functions. Example: ColorSpaceRcPtr ColorSpace::Create() . This is done so that the shared pointer is always created with a custom object deallocator. Our hope is this will work solve the windows dll memory management issue. (And we hope to verify this soon). OCS::ImageDesc The init functions could definitely be constructors. My concerns is that it would then rely on type signatures to maintain uniqueness, and this has hosed me in the past. (Particularly where default values / int / bools are involved). You can accidentally create a change which is binary compatible, but not source compatible. I really like having super explicit names such as initRGBA, initSingleBuffer, initMultiBuffer. This will also let us add new convenience constructors should they be desired without worrying about compatibility. (Consider 'initRGB', which would have the same type signature as initRGBA. But I agree the current init functions aren't ideal. Does anyone have ideas? Soon enough we will have a live share of the GIT repo, and which point everyone can start contributing... ;) -- Jeremy On Fri, Jun 4, 2010 at 4:09 AM, Bruno Nicoletti <bruno.j....@...> wrote: Hi Jeremy, |
|
|
|
Bruno Nicoletti <bruno.j....@...>
Hi Jeremy,
toggle quoted message
Show quoted text
thanks for the reply. I'm a firm believer in smart pointers, choosing what to expose can be problematic in an API like this when there is no firm standard. #ifndefs is the way around it. As for the ctors, derive thin classes from the base one, which have nothing but ctors in them. class PackedImageDesc : public ImageDesc { public : PackedImageDesc(....); }; class PlanarImageDesc : public ImageDesc { public : PlanarImageDesc(....); }; All you functions should take const references to ImageDesc, and it will all work happily. That should do it. On 4 June 2010 16:41, Jeremy Selan <jeremy...@...> wrote:
The use of tr1 shared_ptr is only a stub. When we get multi-platform --
Bruno Nicoletti |
|
|