Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Re: [HELP] Brushing up my C++?

Thread Tools

Re: [HELP] Brushing up my C++?

Ivan Vecerina
Posts: n/a
"ark" <(E-Mail Removed)> wrote in message
news:WlF1b.78959$(E-Mail Removed) t...
> 1. Exception handling:
> What is better: throwing various ints or unique empty classes like class
> StupidMe2003{} if I don't care for more error details?
> How does it measure up against C stuff like
> int error = blah...;
> if(error==0) {error = blah1...;};
> if(error==0) {error = blah2...;};
> ........................
> return error;
> ?

Cases can be constructed where either return codes or exceptions
provide better performance. The the key thing is to keep exceptions
for exceptional situations (e.g. <1/1000 frequency). In these
cases, replacing the overhead of error checks with C++ exceptions
can actually increase performance.
Throwing named classes may make the code more maintainable,
and allows to use inheritance to group exceptions. Throwing only
ints, if you have few very different types of exceptions (handled
by different recovery code), might not be any faster.
(though my gut feeling is, it will in many cases).

> Can (I hold my breath) the compiler trivialize stack unwinding if my
> automatic classes are somehow known to not consume resources (other than
> stack)?

While several compilers allow the use of exceptions in C++ code to be
'free' in non-exceptional cases, there is always an overhead when an
exception is actually thrown.
The cost of stack unwinding increases with the number of destructors
that need to be called for stack-based objects.

> Is it worth replacing automatic classes with a monstrous super-struct of
> them (when I know it) and lug along a pointer to it -- in lieu of

> classes -- so that all destruction can take place in a catch?

I don't think so.

Watch that the performance of EH is very implementation-specific.
You need to veryfy trade-offs and sweet spots on each platform.
But the general guideline is: use exceptions for exceptional failures.

> 2. Is there any way to force lazy construction? Assuming all needed
> constructors exist, consider
> X x; //(1)
> if (something) x = 1; //(2)
> else x = "foo"; //(3)
> I guess, a straightforward compiler would call a default constructor for
> line (1) if for nothing else then for potential side-effects of the
> constructor. Then lines 2 and 3 would call X::~X and build the x again

> a corresponding copy-constructor, right? Is there any way to say: Look, x

> not used until after line (3), so line (2) should just call X::X(int), and
> likewise line (3)? E.g., if the default constructor is inline (or

> visible to the compiler), it might be feasible (?) but changes semantics

In some cases, performance may benefig from using:
X x = (something) ? 1 : "foo";
It is a good practice to declare objects when/where they can be initialized.

The cost of a default constructor depends on how that constructor is
defined (as well as the constructor if all members and base classes).
In many cases, it can be zero.

> 3. Are smart pointers penalty-free yet?

It depends how smart the pointer class is, obviously. On some platforms,
std::auto_ptr actually is penalty free.

> 4. New/delete: if I want to use different memory allocators in different
> parts of the project (such as in my super-duper library and the rest of

> app, which is not necessarily mine), what do I do with uniqueness of

> Will namespace help? EC++?

There are a few possible approaches:
- overload new/delete on a class-by-class basis
- implement your custom memory pool as a kind of container, to/from
which elements can be added/removed with explicit calls.
- don't worry about calling destructors, just release the whole memory
pool when done (that the way GC is intended to work in C++).

> 5. If I want to hide my classes from public headers, what is better:

> classes or a C wrapper?

Two approaches that can (advantageously) replace "handles" used in C:
- use the pimpl idom (a.k.a. Cheshire Cat, Envelope/Letter, etc...).
- use pointers to an interface class (a publicly exposed abstract
base class that only containes (pure) virtual functions).

Optimizing C++ compilers are pretty good IMO nowadays. But you need
to be aware that, unless all optimizations are turned on, the C++
counterparts of good old C techniques tend to be more expensive
(e.g. inline functions vs. macros: the former typically aren't inlined
when compiling in debug mode -- but debugging macros isn't any better
anyway... ).
It is also important to understand the cost of each C++ feature you
want to use (spend some time inspecting generated code) if performance
is critical.
But overall, in my opinion, some C++ techniques allow you to get
better performance than C in less time (e.g. std::sort vs. qsort,
using specialized C++ containers instead of arrays, some uses
of template tricks, etc).

I hope this helps,

Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Myspace profile brushing up. Jos HTML 0 10-19-2006 09:56 AM
Need advice about brushing up on my C++ Kevin Carne C++ 5 12-23-2005 07:56 PM
Re: [HELP] Brushing up my C++? Peter van Merkerk C++ 0 08-25-2003 02:34 PM