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

Discussion in 'C++' started by Ivan Vecerina, Aug 23, 2003.

  1. "ark" <> wrote in message
    > 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,
    Ivan Vecerina, Aug 23, 2003
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?dHJlbGxvdzQyMg==?=

    HELP! HELP! HELP! Opening Web Application Project Error

    =?Utf-8?B?dHJlbGxvdzQyMg==?=, Feb 20, 2004, in forum: ASP .Net
    Feb 20, 2004
  2. Harvey
    Jul 16, 2004
  3. Peter van Merkerk

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

    Peter van Merkerk, Aug 25, 2003, in forum: C++
    Peter van Merkerk
    Aug 25, 2003
  4. Jos
  5. Kevin Carne
    Kevin Carne
    Dec 23, 2005

Share This Page