Do inline functions improve performance?
Why should I use inline functions instead of plain old #definemacros?
Is there any difference between List x; and List x();?
Can one constructor of a class call another constructor of the same class to initialize the this object?
Which constructor gets called when I create an array of Fredobjects?
Vector or explicit assignment or ugly placement new
What is the "Named Constructor Idiom"?
Call ctor by explicit named function
How do I prevent the "static initialization order fiasco"?
In short, suppose you have two static objects x and y which exist in separate source files, say x.cpp and y.cpp. Suppose further that the initialization for the y object (typically the y object's constructor) calls some method on the x object.
Using x().xxxx instead of x.xxxx since replace the global Fred object, x, with a global function, x(), that returns the Fred object by reference. Since static local objects are constructed the first time control flows over their declaration , the new Fred() statement will only happen once: the first time x() is called. Every subsequent call will return the same Fred object (the one pointed to by ans).
This is called the Construct On First Use Idiom because it does just that: the global Fred object is constructed on its first use.
#include "Fred.h"
Fred& x()
{
static Fred* ans = new Fred();
return *ans;
}
By changing the declaration from static Fred* ans = new Fred(); to static Fred ans;, we still correctly handle the initialization situation but we no longer handle the deinitialization situation. For example, if there are 3 static objects, say a, b and c, that use ans during their destructors, the only way to avoid a static deinitialization disaster is if ans is destructed after all three.
Does return-by-value mean extra copies and extra overhead?
Return by value optimization can make Foo x=rbv() does not make aditional copy. But Foo x; x = rbv() does not work
What is the "Named Parameter Idiom"?
See:
http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.18
In the chain of calling, every procedure returns a reference (*this) and no extra
copy is needed and we have F.A().B().C()..... If inline is used, it will be better...
Why am I getting an error after declaring a Foo object via
Foo x(Bar())?
Because that doesn't create a Foo object - it declares a non-member function that returns a Foo object.
Follow-up: if your Foo::Foo(Bar const&) constructor is not explicit, and if Foo's copy constructor is accessible, you can use this syntax instead: Foo x = Bar();.
OK, OK already; I won't explicitly call the destructor of a local; but how do I handle the above situation?
Simply wrap the extent of the lifetime of the local in an artificial block {...}:
What is "placement new" and why would I use it?
void someCode()
{
char memory[sizeof(Fred)];
void* p = memory;
Fred* f = new(p) Fred();
...
f->~Fred(); // Explicitly call the destructor for the placed object
}
We also have operator new....
Why should I worry about "self assignment"?
What operators can/cannot be overloaded?
Most can be overloaded. The only C operators that can't be are . and ?: (and sizeof, which is technically an operator). C++ adds a few of its own operators, most of which can be overloaded except :: and .*.
How
can I overload the prefix and postfix forms of operators ++ and --?Via a dummy parameter.
Number& operator++ (); // prefix ++
Number operator++ (int); // postfix ++
Note the different return types: the prefix version returns by reference, the postfix version by value.
Do friends violate encapsulation?
, try thinking of a friend function as part of the class's public interface. A friend function in the class declaration doesn't violate encapsulation any more than a public member function violates encapsulation: both have exactly the same authority with respect to accessing the class's non-public parts. It enhances encapsulation!
What are some advantages/disadvantages of using friend functions?
The major disadvantage of friend functions is that they require an extra line of code when you want dynamic binding. To get the effect of a virtual friend, the friend function should call a hidden (usually protected) virtual member function. This is called the Virtual Friend Function Idiom. For example:
Why does my program go into an infinite loop when someone enters an invalid input character?
http://www.parashift.com/c++-faq-lite/input-output.html#faq-15.2
while (i != -1) {
std::cin >> i; // BAD FORM — See comments below
std::cout << "You entered " <<>> i) { // GOOD FORM
if (i == -1) break;
std::cout << "You entered " <<>>
How can I provide printing for my class Fred?
We use a non-member function (a friend in this case) since the Fred object is the right-hand operand of the
<<> rather than std::cout <<>), we could have used a member function named operator<<. friend std::ostream& operator<< (std::ostream& o, Fred const& fred); friend std::istream& operator>> (std::istream& i, Fred& fred);
Use operator overloading to provide a friend right-shift operator, operator>>. This is similar to the output operator, except the parameter doesn't have a const: "Fred&" rather than "Fred const&".
Why can't I open a file in a different directory such as "..\test.dat"?
Because "\t" is a tab character.
You should use forward slashes in your filenames, even on operating systems that use backslashes (DOS, Windows, OS/2, etc.).
Why should I use new instead of trustworthy old malloc()?
Constructors/destructors, type safety, overridability.
Constructors/destructors: unlike malloc(sizeof(Fred)), new Fred() calls Fred's constructor. Similarly, delete p calls *p's destructor.
Type safety: malloc() returns a void* which isn't type safe. new Fred() returns a pointer of the right type (a Fred*).
Overridability: new is an operator that can be overridden by a class, while malloc() is not overridable on a per-class basis.
How do I allocate multidimensional arrays using new?
On one extreme, if you know all the dimensions at compile-time, you can allocate multidimensional arrays statically (as in C): Fred matrix[nrows][ncols];
How can I force objects of my class to always be created via new rather than as locals or global/static objects?
Use the Named Constructor Idiom.
As usual with the Named Constructor Idiom, the constructors are all private or protected, and there are one or more public staticcreate() methods (the so-called "named constructors"), one per constructor. In this case the create() methods allocate the objects vianew. Since the constructors themselves are not public, there is no other way to create objects of the class.
What are the two kinds of garbage collectors for C++?
In general, there seem to be two flavors of garbage collectors for C++:
Conservative garbage collectors. These know little or nothing about the layout of the stack or of C++ objects, and simply look for bit patterns that appear to be pointers. In practice they seem to work with both C and C++ code, particularly when the average object size is small. Here are some examples, in alphabetical order:
Boehm-Demers-Weiser collector
Geodesic Systems collector
Hybrid garbage collectors. These usually scan the stack conservatively, but require the programmer to supply layout information for heap objects. This requires more work on the programmer's part, but may result in improved performance. Here are some examples, in alphabetical order:
Attardi and Flagella's CMM
Bartlett's mostly copying collector
Since garbage collectors for C++ are normally conservative, they can sometimes leak if a bit pattern "looks like" it might be a pointer to an otherwise unused block. Also they sometimes get confused when pointers to a block actually point outside the block's extent (which is illegal, but some programmers simply must push the envelope; sigh) and (rarely) when a pointer is hidden by a compiler optimization. In practice these problems are not usually serious, however providing the collector with hints about the layout of the objects can sometimes ameliorate these issues.
How can I handle a destructor that fails?
Write a message to a log-file. Or call Aunt Tilda. But do not throw an exception!
Here's why (buckle your seat-belts):
The C++ rule is that you must never throw an exception from a destructor that is being called during the "stack unwinding" process of another exception. For example, if someone says throw Foo(), the stack will be unwound so all the stack frames between thethrow Foo() and the } catch (Foo e) { will get popped. This is called stack unwinding.
During stack unwinding, all the local objects in all those stack frames are destructed. If one of those destructors throws an exception (say it throws a Bar object), the C++ runtime system is in a no-win situation: should it ignore the Bar and end up in the } catch (Foo e) {where it was originally headed? Should it ignore the Foo and look for a } catch (Bar e) { handler? There is no good answer — either choice loses information.
So the C++ language guarantees that it will call terminate() at this point, and terminate() kills the process. Bang you're dead.
The easy way to prevent this is never throw an exception from a destructor. But if you really want to be clever, you can say never throw an exception from a destructor while processing another exception. But in this second case, you're in a difficult situation: the destructor itself needs code to handle both throwing an exception and doing "something else", and the caller has no guarantees as to what might happen when the destructor detects an error (it might throw an exception, it might do "something else"). So the whole solution is harder to write. So the easy thing to do is always do "something else". That is, never throw an exception from a destructor.
Of course the word never should be "in quotes" since there is always some situation somewhere where the rule won't hold. But certainly at least 99% of the time this is a good rule of thumb.
What's the difference between "Fred const* p", "Fred* const p" and "Fred const* const p"?
You have to read pointer declarations right-to-left.
Fred const* p means "p points to a constant Fred": the Fred object can't be changed via p.
Fred* const p means "p is a const pointer to a Fred": you can't change the pointer p, but you can change the Fred object via p.
Fred const* const p means "p is a constant pointer to a constant Fred": you can't change the pointer p itself, nor can you change the Fred object via p.
Does "Fred& const x" make any sense? Updated!
[Recently changed const X& to X const& (in 4/10). Click here to go to the next FAQ in the "chain" of recent changes.]
No, it is nonsense.
To find out what the above declaration means, you have to read it right-to-left. Thus "Fred& const x" means "x is a const reference to aFred". But that is redundant, since references are always const. You can't reseat a reference. Never. With or without the const.
In other words, "Fred& const x" is functionally equivalent to "Fred& x"
What is a "const member function"?
A const member function is indicated by a const suffix just after the member function's parameter list.
subscript operators often come in pairs.
class Fred { ... };
class MyFredList {
public:
Fred const& operator[] (unsigned index) const; ← subscript operators often come in pairs
Fred& operator[] (unsigned index); ← subscript operators often come in pairs
...
Does "Fred const* p" mean that *p can't change?
"Fred const* p" means that the Fred can't be changed via pointer p, but there might be other ways to get at the object without going through a const (such as an aliased non-const pointer such as a Fred*). For example, if you have two pointers "Fred const* p" and "Fred* q" that point to the same Fred object (aliasing), pointer q can be used to change the Fred object but pointer p cannot.
};
Why am I getting an error converting a Foo** → Foo const**?
C++ allows the (safe) conversion Foo* → Foo const*, but gives an error if you try to implicitly convert Foo** → Foo const**.
The rationale for why that error is a good thing is given below. But first, here is the most common solution: simply change Foo const**to Foo const* const*:
The reason the conversion from Foo** → Foo const** is dangerous is that it would let you silently and accidentally modify a const Fooobject without a cast:
A member (either data member or member function) declared in a private section of a class can only be accessed by member functions and friends of that class
A member (either data member or member function) declared in a protected section of a class can only be accessed by member functions and friends of that class, and by member functions and friends of derived classes
A member (either data member or member function) declared in a public section of a class can be accessed by anyone
Why can't my derived class access private things from my base class?
Converting Derived* → Base* works OK; why doesn't Derived** → Base** work?
C++ allows the conversion Derived* → Base*, since a Derived object is a kind of a Base object. However trying to convert Derived** → Base** is flagged as an error. Although this error may not be obvious, it is nonetheless a good thing. For example, if you could convert Car** → Vehicle**, and if you could similarly convert NuclearSubmarine** → Vehicle**, you could assign those two pointers and end up making a Car* point at a NuclearSubmarine:
Is an array of Derived a kind-of array of Base?
the sizeof a base class is different with the size of derived class. So it might be evil if you change an array of derived to the array of base!
What is an ABC?
At the programming language level, an ABC is a class that has one or more pure virtual member functions. You cannot make an object (instance) of an ABC.
How do you define a copy constructor or assignment operator for a class that contains a pointer to a (abstract) base class?
If the class "owns" the object pointed to by the (abstract) base class pointer, use the Virtual Constructor Idiom in the (abstract) base class. As usual with this idiom, we declare a pure virtual clone() method in the base class:
When my base class's constructor calls a virtual function on its this object, why doesn't my derived class's override of that virtual function get invoked?
Base::Base()
Base::virt() // ← NotDerived::virt()
Derived::Derived()
Derived::virt()
Base::virt() // ← Not
Derived::Derived()
Derived::virt()
The explanation for this behavior comes from combining two facts:
- When you create a Derived object, it first calls Base's constructor. That's why it prints
Base::Base() beforeDerived::Derived() . - While executing
Base::Base() , the this object is not yet of type Derived; its type is still merely Base. That's why the call to virtualfunctionvirt() withinBase::Base() binds toBase::virt() even though an override exists in Derived.'Okay, but is there a way to simulate that behavior as if dynamic binding worked on the this object within my base class's constructor?
Dynamic Binding During Initialization idiomWhat's the meaning of,
Warning: Derived::f(char) hides Base::f(double) ?Here's how you get out of the mess: Derived must have a using declaration of the hidden member function. For example,class Base {
public:
void f(double x);
};
class Derived : public Base {
public:
using Base::f; ← This un-hidesBase::f(double x)
void f(char c);
};How can I set up my class so it won't be inherited from?
The (easy) technical approach is to make the class's constructors private and to use the Named Constructor Idiom to create the objects. No one can create objects of a derived class since the base class's constructor will be inaccessible. The "named constructors" themselves could return by pointer if you want your objects allocated by new or they could return by value if you want the objects created on the stack.A slightly trickier technical approach is to exploit virtual inheritance. Since the most derived class's ctor needs to directly call the virtual base class's ctor, the following guarantees that no concrete class can inherit from class Fred:class Fred;
class FredBase {
private:
friend class Fred;
FredBase() { }
};
class Fred : private virtual FredBase {
public:
...
};Class Fred can access FredBase's ctor, since Fred is a friend of FredBase, but no class derived from Fred can access FredBase's ctor, and therefore no one can create a concrete class derived from Fred.
How are "private inheritance" and "composition" similar?
has a....
What are the access rules with private and protected inheritance?
Take these classes as examples:
class B { /*...*/ };
class D_priv : private B { /*...*/ };
class D_prot : protected B { /*...*/ };
class D_publ : public B { /*...*/ };
class UserClass { B b; /*...*/ };
class D_priv : private B { /*...*/ };
class D_prot : protected B { /*...*/ };
class D_publ : public B { /*...*/ };
class UserClass { B b; /*...*/ };
None of the derived classes can access anything that is private in B. In D_priv, the public andprotected parts of B are private. In D_prot, the public and protected parts of B are protected. InD_publ, the public parts of B are public and the protected parts of B are protected (D_publ is-a-kind-of-a B). class UserClass can access only the public parts of B, which "seals off" UserClass from B.
To make a public member of B public in D_priv or D_prot, state the name of the member with a
class D_prot : protected B {
public:
using B::f; // Note: Notusing B::f(int,float)
};
public:
using B::f; // Note: Not
};
virtual inheritance
Under diamond structure for inheritance, it will remove the ambiguity so that all of
the derived classes will have the unique base class by using virtual inheritance ( Class B: public virtual A { }}
What does it mean to "delegate to a sister class" via virtual inheritance?
cross delegation!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
sizeof(char)=1
How can I tell if an integer is a power of two without looping?
inline bool isPowerOf2(int i)
{
return i > 0 && (i & (i - 1)) == 0;
}
{
return i > 0 && (i & (i - 1)) == 0;
}
Are there any lint-like guidelines for C++?
- A class Fred's assignment operator should return
Assignment operators should make sure that self assignment does nothing, otherwise you may have a disaster. In some cases, this may require you to add an explicit test to your assignment operators.
Why would I use a const variable / const identifier as opposed to#define ?
Every #define macro effectively creates a new keyword in every source file and every scope until that symbol is #undef d.
Why is cos(x) != cos(y) even though x == y ? (Or sine or tangent or log or just about any other floating point computation)
floating point calculations and comparisons are often performed by special hardware that often contain special registers, and those registers often have more bits than a double. That means that intermediate floating point computations often have more bits than sizeof(double) , and when a floating point value is written to RAM, it often gets truncated, often losing some bits of precision.sizeof(double) , and when a floating point value is written to RAM, it often gets truncated, often losing some bits of precision.
That means that intermediate floating point computations often have more bits than
extern "C" {
void f(int i, char c, float x);
int g(char* s, char const* s2);
double sqrtOfSumOfSquares(double a, double b);
}
void f(int i, char c, float x);
int g(char* s, char const* s2);
double sqrtOfSumOfSquares(double a, double b);
}
function pointer V.S.
functionoid
, functionoids were implemented using virtual functions and function pointer is just C-type function pointer. It can be even more powerful for functioniods if the operator () is overloaded. (functor)
Template specialization
template
class D : public B {
public:
void g()
{
B::Xyz x;
B::Pqr y; ← bad (even though some compilers erroneously (temporarily?) accept it)
}
};
class D : public B
public:
void g()
{
B
B
}
};
Because of this potential specialization, the compiler cannot assume that
template
class D : public B {
public:
void g()
{
typename B::Xyz x;
typename B::Pqr y; ← good
}
};
class D : public B
public:
void g()
{
typename B
typename B
}
};
How can I find a Fred object in an STL container of
inline std::string stringify(double x)
{
std::ostringstream o;
if (!(o <<>> x))
throw BadConversion("convertToDouble(\"" + s + "\")");
return x;
}
{
std::ostringstream o;
if (!(o <<>> x))
throw BadConversion("convertToDouble(\"" + s + "\")");
return x;
}
How can I create two classes that both know about each other?
Use a forward declaration
Why can't I put a forward-declared class in a std::vector<> ?
Because the std::vector<> template needs to know the sizeof() its contained elements, plus thestd::vector<> probably accesses members of the contained elements (such as the copy constructor, the destructor, etc.)
