"Warp" <war### [at] tagpovrayorg> wrote in message
news:41615dea@news.povray.org...

>   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)
> {
>     ...
> }


That matches what I understood from Stroustrup's book. He does a good job of
explaining it.


>   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.


So using the above example that you typed in, if a function throws an
InvalidArgument exception, would you say the function is throwing an
exception of type InvalidArgument or of type Exception?


> > 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.


Yeah, I've looked at boost a little and considered using the filesytem
module just as a learning experience. I was taking the approach, though it
may not be so well implemented in my code, that df3 and tga namespaces would
be reusable libraries. that I may want to expand to a png->df3 conversion as
an excercise in understanding the png file format. however, as you say maybe
the class is sufficient in encapsulating a set of related data and
functions.


>
> > 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've spent some time lurking around comp.lang.C++.moderated (if i have the
name right) and that debate seems endless. Everyone seems to say it's
implementation specific, but that in reality C I/O is faster. In my
application, i'm not even reading an entire file into memory at once. I
didn't want people to say "why the hell is this using X megabytes of
memory!" or have someone try to load a rediculously large tga file and have
it crash. I considered allowing a command line option for suggesting how big
of a buffer to use. Though I noticed that after some buffer size, speed
improvements were nonexistant. I started using Valgrind for performance
checking and memory allocation/deallocation. It's a very cool program.


>
> > 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.
>

Thanks again :)
ross

Post a reply to this message