Advice in using boost and STL
mrp
all.
DirextX functions do not throw exceptions, they have a COM type error
return values.
Even if I don't use exception does it make STL and Boost good
candidate for my project? I have to decide this early in development
so I am asking your advices. Or do I look for other exception free C++
libraries? Or try to write one myself.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Mathias Gaunard
> I am developing a game in DirectX and I am not using C++ exceptions at
> all.
>
> Even if I don't use exception does it make STL and Boost good
> candidate for my project?
I would say no.
The point of those libraries is to write elegant, exception-safe code.
If you disable exceptions, you have to do inelegant, inefficient and
unsafe error management at every single instruction in your code.
Which isn't what those libraries are designed for at all.
Thiago Adams
> I am developing a game in DirectX and I am not using C++ exceptions at
> all.
>
> DirextX functions do not throw exceptions, they have a COM type error
> return values.
>
> Even if I don't use exception does it make STL and Boost good
> candidate for my project? I have to decide this early in development
> so I am asking your advices. Or do I look for other exception free C++
> libraries? Or try to write one myself.
If you create a list of all exceptions that C++ and STL can thrown you
will realize that almost all of them can be easily avoided. (The only
one that is hard to avoid is bad_alloc)
However to avoid library exceptions is not the main point because
exceptions are necessary to C++.
Imagine you have a class to hold two COM strings.
class Info
{
BSTR bstr1, bstr2;
}
In c++ you can create a class to hold these values in a safe way and
using a natural syntax.
Like:
Info info1;
Info info2 = info1;
This is possible because of the exception mechanism that can be used
to report errors from constructors and operators.
If you try to avoid exceptions or code will be similar of:
Info info1;
errocode = Initialize(into1);
if (errocode) { ... }
Info info2;
errorcode = CopyTo(info1, info2);
if (errocode) { ... }
Besides of this, your class invariant will be more complicated because
you have to take care about the uninitialized state. This is not
necessary in C++ when the constructor ensures the invariant you need.
Now, suppose you need a collection of "Info". This is very easy to do
using STL containers, but your class must have the copy constructor
and the copy construct may fail.
Considering all these points there is no reason to create a C++
library reporting errors using error codes.
My advices about using error codes APIs (generally C APIs) and
exceptions are:
1. Create an exception class that holds the original error code
2. Create classes to represent your resources.
(Actually you can find samples of 1 and 2 at ATL see CAtlException and
CComBSTR)
3. Use RAII always
4. Your team must understand RAII and the exception mechanism.
5. Don't mix exceptions and error codes. Internally convert error
codes to exceptions, and translated them only when necessary to
communicate with the error code API. Try to keep the error
information.
Error handling is not easy in general but following these advices you
can use STL and boost together with DirectX without any problem and
using a clear C++ code.
Felipe Magno de Almeida
> I am developing a game in DirectX and I am not using C++ exceptions at
> all.
>
> DirextX functions do not throw exceptions, they have a COM type error
> return values.
If you're using DirectX then I presume you don't have executable size
contraints. Is that right?
> Even if I don't use exception does it make STL and Boost good
> candidate for my project? I have to decide this early in development
> so I am asking your advices. Or do I look for other exception free C++
> libraries? Or try to write one myself.
Some boost libraries are able to work without exceptions, but they
default to assert on errors
in that case, which maybe ok, but might not be. For robustness,
exceptions are much better suited.
If you don't have any size contraints, you should probably use
exceptions. That might even be
faster than checking error codes all the time.
Regards,
--
Felipe Magno de Almeida
ManicQin
> I am developing a game in DirectX and I am not using C++ exceptions at
> all.
>
> DirextX functions do not throw exceptions, they have a COM type error
> return values.
>
> Even if I don't use exception does it make STL and Boost good
> candidate for my project? I have to decide this early in development
> so I am asking your advices. Or do I look for other exception free C++
> libraries? Or try to write one myself.
{ Edits: quoted clc++m banner removed. Please don't quote the banner or
other extranous text. - mod }
I really dont think Exception handling capabilities should effect your
judgement...
It's quite irrelevant...
If it really bothers you, you can wrap the DirectX calls and add
exceptions but again
It's irrelevant...
Deciding if to use boost and STL should be based on things like:
portability of your code (which both achieve but ... directX doesnt)
or archituctural directions and does DirectX works well with others?
maybe it have its own standard libraries?
Richard Smith
> I am developing a game in DirectX and I am not using C++ exceptions at
> all.
>
> DirextX functions do not throw exceptions, they have a COM type error
> return values.
>
> Even if I don't use exception does it make STL and Boost good
> candidate for my project? I have to decide this early in development
> so I am asking your advices. Or do I look for other exception free C++
> libraries? Or try to write one myself.
I think that the STL and some parts of Boost will still be a good
solution to your problem. By and large, the Standard Library is
"exception neutral" -- meaning that it will propagate your own
exceptions but rarely throw its own. Of course, there are exceptions
(no pun intended) to this rule, but they are surprisingly few. Many
of the components can throw bad_alloc, but this can be overridden by a
new_handler that calls abort if it can't allocate memory. (If this
isn't satisfactory, you'll have a bit of a problem irrespective of
whether you use the STL as there is no other way for a constructor to
signal error.)
--
Richard Smith
Sam
> I am developing a game in DirectX and I am not using C++ exceptions at
> all.
>
> DirextX functions do not throw exceptions, they have a COM type error
> return values.
>
> Even if I don't use exception does it make STL and Boost good
> candidate for my project?
I always consider STL and Boost good candidates for every C++ project.
They are high quality reusable libraries, extensively tested.
> I have to decide this early in development
> so I am asking your advices. Or do I look for other exception free C++
> libraries? Or try to write one myself.
Exceptions are needed in C++ to report errors from constructors.
Note: I don't know much about DirectX programing but if it requires
callback functions you must take care to not let exceptions
propagate outside the callback functions.
--
Please remove "sam_" from email address.
Lance Diduck
> I am developing a game in DirectX and I am not using C++ exceptions at
> all.
>
> DirextX functions do not throw exceptions, they have a COM type error
> return values.
>
> Even if I don't use exception does it make STL and Boost good
> candidate for my project? I have to decide this early in development
> so I am asking your advices. Or do I look for other exception free C++
> libraries? Or try to write one myself.
posters have noted, C++ minus exceptions greatly complicates the
syntax.
And as others have noted, Boost / std C++ libs have very few throws,
and the vast majority denote programmer errors (like bad arguments).
DirectX does not use exceptions, because like most things Microsoft,
it uses COM-style interfaces. Among other things, this allow DirectX
to be used with other MS programming languages, like VB. VB et al
cannot catch a C++ exception, but they can handle a return code.
The rule is -- use exceptions until there is no other way to get more
performance. Turning off exceptions is like removing known performance
stealers like brakes, bumpers and airbags from your car.
Lance
ManicQin
> solution to your problem. By and large, the Standard Library is
> "exception neutral" -- meaning that it will propagate your own
> exceptions but rarely throw its own. Of course, there are exceptions
> (no pun intended) to this rule, but they are surprisingly few. Many
> of the components can throw bad_alloc, but this can be overridden by a
> new_handler that calls abort if it can't allocate memory. (If this
> isn't satisfactory, you'll have a bit of a problem irrespective of
> whether you use the STL as there is no other way for a constructor to
> signal error.)
I'm sorry there's something I'm missing that I will love to catch up.
Since when STL and Boost are "coupled" with exception handling?
Are there any libraries that are specific for "un-safe" programming?
I accept with Richard that they are "exception neutral" why is it so
important?
Richard Smith
> > I think that the STL and some parts of Boost will still be a good
> > solution to your problem. By and large, the Standard Library is
> > "exception neutral" -- meaning that it will propagate your own
> > exceptions but rarely throw its own. Of course, there are exceptions
> > (no pun intended) to this rule, but they are surprisingly few. Many
> > of the components can throw bad_alloc, but this can be overridden by a
> > new_handler that calls abort if it can't allocate memory. (If this
> > isn't satisfactory, you'll have a bit of a problem irrespective of
> > whether you use the STL as there is no other way for a constructor to
> > signal error.)
>
> I'm sorry there's something I'm missing that I will love to catch up.
> Since when STL and Boost are "coupled" with exception handling?
I'm not sure I understand your question. There are a few places in
the Standard Library where exception are caught and not subsequently
rethrow (certain IOStream operations, for example). And there will
very likely be quite a few places where exception are caught and
rethrow. Is this what you mean by exception handling?
But none of this is forcing you to use exceptions, and in most modern
implementations you only pay a small size penalty and (almost) no
speed penalty for the exception handling code. Some compilers even
provide a way of disabling exceptions (and generation of exception
handling code) so you can avoid this overhead. So if the STL is
'"coupled" with exception handling', it's a very loose coupling, and
you can do exception handling without the STL and use the STL without
exceptions.
That said, I agree with all that Thiago Adams said: most of the time,
the best way -- and often the only idiomatic way -- to report errors
in C++ is with exceptions. However, I was trying to answer the OP's
actual question which was "if I don't use exception does it make STL
and Boost good candidate for my project", to which I think the answer
is yes.
> Are there any libraries that are specific for "un-safe" programming?
What an odd question.
Programming C++ without using exceptions isn't necessarily unsafe.
Yes, it requires a slightly different style of programming, but that
doesn't make it inherently unsafe. If you're not familiar with RAII,
it's very easy to write bad, "unsafe" C++ if you *do* use exceptions.
But RAII also helps you free up resources in code with or without
exceptions. Instead of writing C-like code:
int test() {
int ret = -1;
struct foo* f= (struct foo*) malloc( sizeof(struct foo) );
if ( fn1(f) == -1 )
goto cleanup:
if ( fn2(f) != -1 )
ret = 0;
cleanup:
free(foo);
return ret;
}
you can use RAII to write
int test() {
boost::scoped_ptr<foo> f(new foo);
if ( fn1(f.get()) == -1 )
return -1;
return fn2(f.get());
}
This doesn't necessarily have anything to do with exceptions -- the
code is still using error codes rather than exceptions, but RAII has
tidied up the handling of resources.
And most good libraries will do this anyway because it's the best way
to write exception-safe code.
> I accept with Richard that they are "exception neutral" why is it so
> important?
Sorry, why is *what* so important?
--
Richard Smith
Thiruvalluvan M. G
>
> I'm sorry there's something I'm missing that I will love to catch up.
> Since when STL and Boost are "coupled" with exception handling?
> Are there any libraries that are specific for "un-safe" programming?
>
work pretty well without them. But the containers and algorithms of
STL (and some boost libraries) use default constructors, copy
constructors and copy assignment operators on their elements (objects
of your class) quite freely. They are not going to check if these
operations succeeded using the custom error checking you have
designed. They simply assume that return from these operations means
they are successful, which is not true in most real world cases. In
other words, they expect the user types to throw an exception if any
of these common operations fail.
> I accept with Richard that they are "exception neutral" why is it so
> important?
>
It is important in cases where you have types that never fail in
default construction, copy construction and copy assignment operation.
For example, if you dealing with a primitive type such as int, STL is
exception free.
Thiago Adams
with a primitive type such as int, STL is
> exception free.
>
using integers.
If you omit this behaviour your program is logically wrong or it is
prepared only to exit.
co...@mailvault.com
> I am developing a game in DirectX and I am not using C++ exceptions at
> all.
>
> DirextX functions do not throw exceptions, they have a COM type error
> return values.
>
> Even if I don't use exception does it make STL and Boost good
> candidate for my project? I have to decide this early in development
> so I am asking your advices. Or do I look for other exception free C++
> libraries? Or try to write one myself.
>
My approach with Boost is to "chew the meat and spit the bones."
The Intrusive, Multi_Index and Range libraries are examples of
meaty libraries IMO. I'm skeptical of the Serialization library
though -- http://home.seventy7.com/comparison.html
Brian Wood
Ebenezer Enterprises