In article <3fdd2009@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Using a smart pointer sounds more like making system-dependant calls
> in wrong places.

Well, if you only target one operating system for one reason or another, you
are usually not concerned about portability at all.  Or, like a task I am
currently dealing with, you don't get pointers back but ids that you even
want to reference in multiple places (OpenGL display lists).  Yet they
belong only to one particular object of a class (the OpenGL context that was
active when they were created).  So, when giving an object encapsulating a
display list to the user (of the OpenGL context object), you have to make
sure when you get them back that they belong to your object at all.

On the other hand, in many cases (like when using OpenGL) you need a rather
low-level interface at a fairly high application level.  The alternative
would be a total abstraction in many cases (i.e. if you want to support
another API like Direct3D), which ends up being a lot of very careful coding
to even only deal with a tiny subset of functionality.

>   I would try to abstract whatever resources you are allocating from the OS
> behind a class.

When dealing with an operating system C interface, sometimes there has to be
a compromise between good abstraction and feasibility.  For example,
supplying Get and Set methods for every possible OpenGL flag and state
variable would quickly result in several thousand member function template
based Get/Set methods - the OpenGL 1.5 API contains over 450 functions
offering access to about 1500 different flags and states!  Not even to
mention the optional feature extensions in OpenGL.  So, unless somebody
wants to implement this and update it for every new OpenGL version, you end
up using less abstraction.  While not in this particular case (you need ids
as outlined above), in many other cases a smart pointer is a really good
alternative to going all the way to a full abstraction layer.  In particular
if you only need certain system functions once.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message