Ross <rli### [at] everestkcnet> wrote:
> What do you
> think about, i forget the proper name, exception statements on functions.
> for instance saying "this function can throw exceptions of this type". like
> "int foo() throws bla" or whatever. I started using it, then commented them
> out. I wasn't sure if you have a heirarchy of exception classes if you would
> have it throw the derived-from class, or the derived class. did that make
> sense?

  If I remember correctly, the exception mechanism of C++ has been
standardized to be quite safe.
  If I'm not mistaken, you can safely throw a local temporary instance
of a class and catch-blocks catching a reference of that type (or a base
type of that class) will correctly get a reference to an existing instance,
and the instance will be destroyed at the end of that catch block.

  That is, suppose you have a "class Exception" and a
"class InvalidArgument: public Exception". You can then do
something like this:

void foo()
{
    ...
    throw(InvalidArgument());
}

and somewhere else:

try
{
    foo();
}
catch(Exception& e)
{
    ...
}

  If foo() throws an exception of type InvalidArgument, it will be
caught in the catch block above (which takes a reference of type
Exception). The reference will point to a valid instance and this
instance will be properly destroyed at the end of the catch block
(unless rethrown, of course).

  (One great thing about C++ exceptions is that the compilers can
implement them so that they do not affect the speed of the code if
exceptions are not thrown (at the cost of a bit bigger binaries, though).)

  If you are using exceptions for error handling in your program, it may
indeed be a good idea to tell for most functions if they do or do not
throw exceptions.
  Telling that a certain function does not throw exceptions is a bit like
the same kind of assertion as telling that a member function does not
modify the state of the object (with 'const'). This is not only quite
documentary, but it can also be useful sometimes.
  (The same applies, of course, to telling that a function can throw
only certain types of exceptions.)

> yeah, I wasn't quite sure what to do. it *felt* like overkill, but I didn't
> know the best way to go about it. Instead of dropping namespaces altogether,
> I did what I did. suggestions?

  Namespaces are usually useful when you are creating a library for others
to use, specially if the library will contain a numerous amount of public
names (type names, function names, etc).

  Consider the Boost set of libraries (http://www.boost.org/). All the
Boost libraries are inside a 'boost' namespace (except their implementation
of the standard libraries, which are inside the 'std' namespace, of course).
Also each individual library is located in its own sub-namespace. For
example, the lambda library (http://www.boost.org/libs/lambda/doc/) is
inside the 'lambda' namespace inside the 'boost' namespace (ie. if you
don't use 'using', you would need to use the 'boost::lambda::' prefix for
each name).
  These libraries contain quite a numerous set of things inside them,
but they seldom contain just one type.

  Anyways, my point is that usually when you are creating a big library
(which is designed to be reusable and not too specific to a certain
application), using a namespace may be a good idea.
  Using a namespace for one class inside your program may be overkill.
After all, the name of the class works almost as a namespace all by itself.

> premature optimization is the root of all evil. i'm guilty here. just trying
> to avoid branches.

  Concentrate on optimizing your algorithms and data containers (for speed
and memory usage). It's usually not necessary to optimize the code. :)

  I would say that in this case the memory optimizations take priority.
After all, the speed bottleneck in this application is disk reading and
writing, which is very slow compared to handling the data and thus the
speed of your code is not extremely relevant. The amount of memory your
data containers waste is something more important (even though in this
case it may not be very urgent either, considering how much memory there
is in current computers; as long as you keep only one image at a time
in memory there shouldn't be any problem).

  By the way, one hint regarding to disk reading and writing speed,
since you want your application to be fast:
  For several reasons the C++ streams are quite slow. Using C streams
instead can increase your application's reading and writing speed even
by a factor of two.
  (The best way of doing this is, of course, to make an abstract
reading/writing type inside which it's easy to change which type of
file reading/writing functions are used.)

> I saw you mention, i think it was you anyway, in another thread that df3's
> support 8, 16, and 24(or was it 32?) bit "voxels". Is this a new thing?

  IIRC it's a new feature of POV-Ray 3.6. See the documentation for details.

> Also, is the df3 format a pov-team "invention", or what?

  AFAIK, yes.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message