This question refers to common problems discussed in these questions:
Can virtual functions have default parameters?
Virtual functions default parameters
Here is what currently happens in c++ with default parameters to virtual functions:
struct Base
{
virtual void foo(int one = 1, int two = 2)
{ cout << "one: " << one << " two: " << two << endl; }
};
struct Derived : public Base
{
virtual void foo(int one = 3, int two = 4)
{ Base::foo(one, two); cout << " derived!" << endl; }
};
int main()
{
Base* b = new Base();
Base* d = new Derived();
Derived* dp = new Derived();
b->foo();
d->foo();
dp->foo();
return 0;
}
output:
one: 1 two: 2
one: 1 two: 2
derived!
one: 3 two: 4
derived!
This is the behaviour I wish existed in c++ virtual function default parameters:
#include <iostream>
using namespace std;
struct Base
{
virtual void foo () { foo(1, 2); }
virtual void foo (int one) { foo(one, 2); }
virtual void foo(int one, int two)
{ cout << "one: " << one << " two: " << two << endl; }
};
struct Derived : public Base
{
virtual void foo() { foo(3, 4); }
virtual void foo(int one, int two)
{ Base::foo(one, two); cout << " derived!" << endl; }
};
int main()
{
Base* b = new Base();
Base* d = new Derived();
Derived* dp = new Derived();
b->foo();
d->foo();
dp->foo();
return 0;
}
output:
one: 1 two: 2
one: 3 two: 4
derived!
one: 3 two: 4
derived!
So, basically, if I want to override a default parameter in a parent class, I will just create a new foo with that number of arguments. Note that the derived overrides the no-arg condition, but not the one-arg condition.
As a side note, my current project uses a purely virtual base class. I often have pointers of the base class type and of the derived class type. I want a call from either pointer to have the same result.
QUESTIONS:
I have read many questions related to this subject, but they all don't seem to give reasonable solutions. Most of the solutions would result in uglier code all throughout your project.
Some say "Don't use default parameters on virtual functions," but then I would need to put the default in every place I call the function. It seems it would be better to just put a comment that says, "also change base class" and "also change derived class" than to have to change everywhere the function is called.
Some say to only have the default parameters in the base class, but that means that any pointer to a derived object would need to be cast back to a base pointer before the defaults could be used. That makes a lot of code ugly as well.
Are there reasons I should avoid the above design?
At some point in time future maintainers of your code will be baffled, confused, and/or perplexed if you change the default values depending on which static type they call foo on so I'm going to assume that's not your concern.
Given that your concern is someone changing the default in the parent and forgetting to update the child class that's easily solved with the non-virtual interface pattern:
#include <iostream>
using namespace std;
struct Base
{
void foo(int one = 1, int two = 2) { foo_impl(one, two); }
protected:
virtual void foo_impl(int one, int two)
{ cout << "one: " << one << " two: " << two << endl; }
};
struct Derived : public Base
{
protected:
virtual void foo_impl(int one, int two)
{ Base::foo_impl(one, two); cout << " derived!" << endl; }
};
int main()
{
Base* b = new Base();
Base* d = new Derived();
Derived* dp = new Derived();
b->foo();
d->foo();
dp->foo();
return 0;
}
I think the problem in "understanding what's going on" is that default values for function arguments are resolved at compile-time - this means that unless it's VERY obvious and simple, the compiler will not KNOW what class some pointer is pointing at, and won't give the right argument. In other words, the compiler will use the class of the pointer when determining the arguments for your function. There is absolutely no way you can work around this (other than "knowing which class you want to use", but then it's pretty meaningless to use virtual functions).
The solution depends on what you REALLY want to do, but an obvious answer is to NOT use default arguments. The other solution is, like you have, some sort of indirect function call, where the "no arguments" function is different from the one and two argument functions.
But it's perhaps also a good idea to wonder if your design is right in the first place. Maybe you need to find a different solution somewhere...
First of all, you are not using default parameters in your example. Thus, the problem that usual default parameters have do not apply to your code. In your code, subclasses can override default parameters which will work as expected no matter if a Derived is used through a Base or a Derived pointer. Thus, I do not see a problem with your approach, it seems fine to me.
Related
I was recently asked this question in an interview:
#include <iostream>
class Base
{
public:
void foo() { std::cout << "foo" << std::endl; }
};
class Derived : public Base
{
public:
void bar() { std::cout << "bar" << std::endl; }
};
int main(int argc, const char *argv[])
{
Base *p = new Derived;
// additional code here
return 0;
}
The conditions on the question were that the Base and Derived classes cannot be changed (for example changing the name of the methods, adding additional methods, or changing a method to virtual.
A further restriction was that no type of cast could be used.
The pointer p had to be used.
Other than that, you could write any additional code, including as many classes as necessary to insure that the "bar()" method was called using the object pointed to by p.
Given that no casts were allowed, the only aswer I could come up with was an old-school one:
Derived *d;
memcpy(&d, &p, sizeof p);
d->bar();
Which is even worse than a cast.
The interviewer berated me and told me I didn't have even the most basic knowledge of object hierarchy since I could not see the very obvious, trivial solution to the question.
I apologize if this question is a duplicate; I've seen other questions about accessing a method in a derived class from a base class, but in all cases I saw, the answer involved either a cast or modification to either of the classes.
He may be correct; I've been programming in C++ for over 15 years and I cannot see the solution. It could be I've never encountered it since I would use a cast in this situation: in this case, it would have to be a static_cast since there are no virtual methods (not even the destructor) which would allow the dynamic_vast to compile (it fails with a message: "'Base' is not a polymorphic type"
Simple and easy dumb:
#define Base Derived
just before main. (you can then call bar on it)
I maybe would come up with something like:
void foobar(Base* b){
Derived d;
d.bar();
}
int main(int argc, const char *argv[]){
Base *p = new Derived;
foobar(p);
return 0;
}
And if the interviewer complains that this is too foobar, I would ask him to please ask less foobar questions :P
No, really, I do consider this as a valid answer to a quite academic question. I am using the object pointed by p (to call a foobar function) and I made sure that 'bar()' is called. I dont think such an exercise deserves a more sophisticated solution. Logically, my solution cannot be distinguished from whatever solution the interviewer had in mind.
The pointer p had to be used. Other than that, you could write any additional code, including as many classes as necessary to insure that the "bar()" method was called using the object pointed to by p.
As many classes as necessary, you say?
#include <iostream>
class Base
{
public:
void foo() { std::cout << "foo" << std::endl; }
};
class Derived : public Base
{
public:
void bar() { std::cout << "bar" << std::endl; }
};
int main()
{
class Base
{
public:
void bar() { std::cout << "bar" << std::endl; }
};
class Derived : public Base
{
};
Base *p = new Derived;
p->bar();
}
You could use a union for type-punning:
union {
Base* bp;
Derived* dp;
} my_union = {p};
my_union.dp->bar();
Answer could be: This will not compile.
I am trying to understand inheritance and I need some help building two classes. The fist one is called A, the second one is called B.
A has one private integer value "m_a". It has two constructors, the default one sets m_a to 5. and another one which takes as an argument an integer called m and sets m_a's value to m. As for member functions it will have two. The first one will return m_a. The second one will print "Hello from A!". Let's move on to B. B will have a private string m_s. A default constructor which will set m_s to "asd" or to anything other than an empty string and a constructor which will take as an argument a string and set m_s to it's value. As far as functions go, firstly B will have a function that will return m_s. It will have a function which will have the same name as the print "Hello from A" function in A which will override it and it will printout "Hello from B!" instead (is that polymorphism ?).
Those are the classes needed. I have the following questions (I will post what I have created below)
Firstly, is there any way I can get to the private data fileds from the base class. For example let's say I want to take the m_s variable, add it to another one and print out their sum. Is that possible ? (and how)
Also when I try to create a class with a constructor different from the default one I get errors. I am obviously doing something wrong. The question is what.
I think those are all of my questions for now, so it is time for me to post the source code.
#include <iostream>
#include <string>
using namespace std;
class A
{
private:
int m_a;
public:
A(){m_a = 5;}
A(int m)
{
m_a = m;
}
void pm()
{
cout << "Hello from A!" << endl;
}
int get_a()
{
return m_a;
}
};
class B : A
{
private :
string m_s;
public:
B(){m_s = "asd";}
B(string s)
{
m_s = s;
}
void pm()
{
cout << "Hello from B!" << endl;
}
string get_s()
{
return m_s;
}
};
int main()
{
A a(10);
a.pm();
cout << a.get_a() << endl;
B b("asd");
b.pm();
cout << b.get_s() << endl;
cout << b.get_a() << endl;
return 0;
}
(is that polymorphism ?).
Not the way you have done it. It would be polymorphism if you had a pointer of type A* which pointed to what was actually a B object, and calling pm on that pointer correctly invoked the member function of B. This would only be possible if the pm function in A were declared as virtual, like below.
class A
{
...
virtual void pm(){
...
};
...
int main()
{
A* = new B();
A->pm(); //"Hello from B!"
}
is there any way I can get to the private data fileds from the base class
Not sure what you mean here - your example talks of a private field of the derived class.
Typically good class design means that derived class should not need to access the (private) fields of the base class, if this is needed you should make that field protected.
As to the compile error #ArunKumar got it exactly.
When you say Class B : A You inherit from A, but all the members are inherited as private by default, due to this, base class constructor is private, so you cannot use it.
However when you say Class B : public A it is the other end of the spectrum. All members of the base class retain their accesibility in the derived class (public remains public, etc)
The problem is that you're using private inheritance:
class B : A {
Inheritance through classes are private by default. Add public before A.
class B : public A {
As for your other problem...
I want to take the m_s variable, add it to another one and print out their sum.
This is easy when it comes to std::string. Just create another member function:
void addTom_s(string s) { m_s += s; }
Trying changing class B : A to class B : public A
Lets say we have the following two class definitions.
#include <iostream>
#include <array>
class A
{
public:
virtual void f() = 0;
};
class B : public A
{
public:
virtual void f() { std::cout << i << std::endl; }
int i;
};
Here sizeof(B) == 8, presumably 4 the virtual pointer and 4 for the int.
Now lets say we make an array of B, like so:
std::array<B, 10> x;
Now we get sizeof(x) == 80.
If my understanding is correct, all method calls on elements of x are resolved statically, as we know the type at compile time. Unless we do something like A* p = &x[i] I don't see a need to even store the virtual pointer.
Is there a way to create an object of type B without a virtual pointer if you know it is not going to be used?
i.e. a template type nonvirtual<T> which does not contain a virtual pointer, and cannot be pointed to by a subtype of T?
Is there a way to create an object of type B without a virtual pointer if you know it is not going to be used?
No. Objects are what they are. A virtual object is virtual, always.
After all, you could do this:
A *a = &x[2];
a->f();
That is perfectly legitimate and legal code. And C++ has to allow it. The type B is virtual, and it has a certain size. You can't make a type be a different type based on where it is used.
Answering my own question here, but I've found that the following does the job, by splitting A into it's virtual and non-virtual components:
enum is_virtual
{
VIRTUAL,
STATIC
};
template <is_virtual X>
class A;
template<>
class A<STATIC>
{
};
template<>
class A<VIRTUAL> : public A<STATIC>
{
public:
virtual void f() = 0;
virtual ~A() {}
};
template <is_virtual X>
class B : public A<X>
{
public:
void f() { std::cout << i << std::endl; }
int i;
};
The important thing here is that in B<> don't specify f() as virtual. That way it will be virtual if the class inherits A<VIRTUAL>, but not virtual if it inherits A<STATIC>. Then we can do the following:
int main()
{
std::cout << sizeof(B<STATIC>) << std::endl; // 4
std::cout << sizeof(B<VIRTUAL>) << std::endl; // 8
std::array<B<STATIC>, 10> x1;
std::array<B<VIRTUAL>, 10> x2;
std::cout << sizeof(x1) << std::endl; // 40
std::cout << sizeof(x2) << std::endl; // 80
}
That would be a nice one to have, but I can't think of any way to revoke virtual members or avoid storing the virtual pointer.
You could probably do some nasty hacks by keeping a buffer that's the size of B without the virtual pointer, and play with casts and such. But is all undefined behavior, and platform dependant.
Unfortunately it won't work in any normal sense as the code inside the method calls expects the virtual pointer to be in the class definition.
I suppose you could copy/paste all of A and B's code into a new class but that gets to be a maintenance headache fast.
This is a basic concept question. If I have a class that Derived that inherits from Base, and I instantiate a new Derived object, can I set it's Base object to a specific Base object of my choosing so that all calls base class methods are redirected to this particular base object?
something like this:
class Base
{
protected:
string name;
public:
Base(string n) { name = n}
void doSomething(){cout << name << "\n";}
};
class Derived : public Base
{
public:
Derived(string n) : Base(n) {}
int main()
{
Derived* d = new Derived("original base"); //create a derived
d->doSomething(); // prints "original base"
Base* rB = new Base("replacement base"); // create a new base object
((Base*) d) = rB; // replace the base object of d with a new one (pretend code)
d->doSomething(); // prints "replacement base"
return 0;
}
I'm sure I made all sorts of errors in that simple code, because my skill level is low, but just for the idea.
Is this possible in C++? We can slice the derived information off of an object, so can we separate and replace the components in a chain of inheritance?
Why would I want to do this?
Consider the mixin lilies: (again, forgive syntax errors)
template <class T> class MyMixin : public T
{
public:
MyMixin(T desiredBaseObject)
{
// do something to set the desired base
// object of this class to desiredBaseObject.
}
};
RandomClass1 dog(int i = 0);
RandomClass2 cat(double i = 0.0);
MyMixin< RandomClass1 > mixin1(dog);
MyMixin< RandomClass2 > mixin2(cat);
In this case, if we could set the base object of the mixin to any desired object, we could use constructors with any parameter list in our mixin without the mixin needing to know anything about it. Also, the mixin could be used like a decorator without the need for a common interface amongst decorators.
Thanks for the answers. Since we can slice off the derived part of an object, it seems like the base and derived information lives separately. Could someone comment on this? Could we access some internal table, like the vtables I hear so much about (I don't know anything about this type of stuff, so maybe this is not applicable), and accomplish this?
#BenoƮt
Could you explain why only 1 and 4 work, but 2 and 3 do not?
class Base
{
protected:
std::string name;
public:
Base(std::string n)
{
name = n;
}
virtual void doSomething()
{
cout << name << "\n";
}
};
class Derived : public Base
{
public:
int x;
Derived(std::string n) : Base(n)
{
x = 5;
}
void printX()
{
cout << "x = " << x << "\n";
x++;
}
};
Derived* d1 = new Derived("original 1");
d1->doSomething();
d1->printX();
Base* rb1 = new Base("new 1");
*static_cast<Base*>(d1) = *rb1;
d1->doSomething();
d1->printX();
cout << "\n\n";
Derived d2 = Derived("original 2");
d2.doSomething();
d2.printX();
Base b2 = Base("new 2");
static_cast<Base>(d2) = b2;
d2.doSomething();
d2.printX();
cout << "\n\n";
Derived d3("original 3");
d3.doSomething();
d3.printX();
Base b3("new 3");
static_cast<Base>(d3) = b3;
d3.doSomething();
d3.printX();
cout << "\n\n";
Derived d4("original 4");
d4.doSomething();
d4.printX();
Base b4("new 4");
*static_cast<Base*>(&d4) = *&b4;
d4.doSomething();
d4.printX();
cout << "\n\n";
this will print:
original 1
x = 5
new 1
x = 6
original 2
x = 5
original 2
x = 6
original 3
x = 5
original 3
x = 6
original 4
x = 5
new 4
x = 6
Why does this only work with when using a pointer?
I'm not questioning why you want to do this, but it's perfectly safe do it unless your inheritance breaks the ISA relationship (eg Derived is a restricted subset of Base, eg a Square is not a Rectangle since it is possible to resize only one dimension of a Rectangle but impossible to do so with a Square).
*static_cast<Base*>(d) = *rB;
(works also with references)
or you can write a little function (you will find lots of functions doing this):
template<typename T>
T& assign(T& to, const T& from)
{
return to = from;
}
assign<Base>(*d, *rB);
and anyway, you do this every time you overload/redefine operator=
Derived& operator=(const Derived& other)
{
// prettier than the cast notation
Base::operator=(other);
// do something specific to Derived;
this->name += " (assigned)";
return *this;
}
No. If you need to do this, you should use composition, not inheritance.
(I'm answering the more general question -- in your specific case where you just want to change the string you can just change name from within the derived class)
Inheritance = IS A relation.
Composition = HAS A relation.
You're describing a class that has an object of type A where you can set its instance.
So you need to use composition - Make a class that hold a member of type A
Inheritance is a property of types, not of objects. The type "Derived" inherits from the type "Base". You can make objects of type "Derived" (Derived x;), and you can also make objects of type "Base" (Base y, unless that's forbidden), but each of those objects are complete, fully-fledged objects with no "replaceable parts".
The point of type inheritance is that you may treat an object of type "Derived" as if it was an object of type "Base" (as long as you refer to it by reference or pointer), that is, if you have a function void foo(Base & b);, then you may call foo(x). But foo can only access those parts of x which are inherited from "Base"!
You could combine inheritance & composition:
class A {
string name;
public: A(const char* s) : name(string(s)) {}
virtual void m() { cout << name << endl; }
};
class B : A {
public:
B(const char* s) : A(s), a(0) {}
void m() { if (a) a->m(); else A::m(); }
A* a;
};
int main() {
B b("b");
b.m(); // prints b
b.a = new A("a");
b.m(); // prints a
}
No, you cannot do that.
You have (at least) a couple of options:
Create a new Derived object, parameterised by a mixture of parameters from the two objects you wish to combine.
Create some setter methods in the Base class, that allow you to change its parameters/state later in its lifetime.
No.
Why would you want to do this? If two Deriveds are supposed to have the exact same Base, such that modifications through one Derived show up in the other, you need to have some sort of pointer to Base in each derived, making this composition, not inheritance.
If you want to change the data in the Derived's Base, write a function to do that, a little like a copy assignment operator for Base.
Alternately, you could make a new constructor for Derived that would take a Base and a Derived, and take Base information from the Base and Derived information from the Derived.
Are there any cases where we do down casting of objects?
If we do, why?
I have observed a way of hiding implementation using the below code. Is this the correct way to do? Is there any better way to achieve the same.
class A{
public:
A();
virtual ~A();
//exposed virtual functions
};
class AImpl : public A{
public:
AImpl(A *obj);
virtual ~AImpl();
//exposed virtual functions++
};
class Helper{ //utility class so i am making constructor and assignment operator as private
public:
static bool doWork(A *obj){
AImpl *objImpl = dynamic_cast<AImpl *> (obj);
return doWork(objImpl); // some internal function
}
private:
Helper();
Helper(const Helper& obj);
const Helper& operator=(const Helper& obj);
};
The question still does not makes sense. I agree. I still have not figured out a proper way of hiding the implementation details from the client.
UncleBens
I termed this thing wrongly as Object slicing. Basically, I was referring to this (Object Slicing) as the information related to derived part is missing.
S.Soni
Thanks for giving a wonderful explaination. Now, I can really put forward question.
Consider a clients perspective. The only class which are visible to him is class A and the Helper class (because I have hidden implementation behind AImpl
Client has to write the following code as he is unaware of AImpl class
int main(){
A *a = new A();
Helper.doWork(a);
// ...
}
As you said AImpl * in this case will actually be pointing to the base class object, which is wrong (you have explained it with a great example), so this approach of hiding implementation is not correct.
Any attempt to access a derived class member function will result in a crash (and correctly so).
How should I go about hiding the implementation in this case? This is a design problem now?
**Are there any cases where we do down casting of objects**
The purpose of dynamic_cast is to perform casts on polymorphic types. For
example, given two polymorphic classes Band D, with D derived from B, a
dynamic_cast can always cast a D* pointer into a B* pointer. This is because a base
pointer can always point to a derived object. But a dynamic_cast can cast a B* pointer
into a D* pointer only if the object being pointed to actually is a D object.
**`Is there any better way to achieve the same`**
Perhaps the most important of the new casting operators is dynamic_cast. The
dynamic_cast performs a run-time cast that verifies the validity of a cast.
1) Your class is not polymorphic.A class that declares or inherits a virtual function is called a polymorphic class
2) Syntax of dynamic_cast is dynamic__cast (expr)
1st Edit :
Try like this , it will work
class A
{
public:
A();
virtual ~A();// Notice here i have put virtual
};
class AImpl : public A
{
public:
AImpl(A *obj);
~AImpl();
};
class Helper
{
public:
Helper(){}
static bool doWork(A *obj)
{
AImpl *objImpl = dynamic_cast<AImpl*> (obj);
return true;
}
};
Study this example :
class Base
{
public:
virtual void f() { cout << "Inside Base\n"; }
// ...
};
class Derived: public Base
{
public:
void f() { cout << "Inside Derived\n"; }
};
int main()
{
Base *bp, b_ob;
Derived *dp, d_ob;
dp = dynamic_cast<Derived *> (&d_ob);
if(dp) {
cout << "Cast from Derived * to Derived * OK.\n";
dp->f();
} else
cout << "Error\n";
cout << endl;
bp = dynamic_cast<Base *> (&d_ob);
if(bp) {
cout << "Cast from Derived * to Base * OK.\n";
bp->f();
} else
cout << "Error\n";
cout << endl;
bp = dynamic_cast<Base *> (&b_ob);
if(bp) {
cout << "Cast from Base * to Base * OK.\n";
bp->f();
} else
cout << "Error\n";
cout << endl;
dp = dynamic_cast<Derived *> (&b_ob);
if(dp)
cout << "Error\n";
else
cout << "Cast from Base * to Derived * not OK.\n";
cout << endl;
bp = &d_ob; // bp points to Derived object
dp = dynamic_cast<Derived *> (bp);
if(dp) {
cout << "Casting bp to a Derived * OK\n" <<
"because bp is really pointing\n" <<
"to a Derived object.\n";
dp->f();
} else
cout << "Error\n";
cout << endl;
bp = &b_ob; // bp points to Base object
dp = dynamic_cast<Derived *> (bp);
if(dp)
cout << "Error";
else {
cout << "Now casting bp to a Derived *\n" <<
"is not OK because bp is really \n" <<
"pointing to a Base object.\n";
}
cout << endl;
dp = &d_ob; // dp points to Derived object
bp = dynamic_cast<Base *> (dp);
if(bp) {
cout << "Casting dp to a Base * is OK.\n";
bp->f();
} else
cout << "Error\n";
return 0;
}
From your code and the information that the passed in pointer actually points to an A, and not an AImpl, also the constructor AImpl that accepts an A*, I gather that what you want it:
class Helper{
public:
static bool doWork(A *obj){
AImpl objImpl(obj); //construct an AImpl instance, using available constructor
return doWork(&objImpl); // some internal function
}
};
There is no way to cast a base instance into an instance of a derived class (where would the missing derived part come from??).
Well, if the following holds true (not the only valid reasons, but a common one):
you have a MVC like architecture
you want to hide the implementation details from client code (no-na...)
you need to pass some references from core to client-code (handles of all sorts, etc.)
the only valid implementation of the public interfaces must be in the core of the MVC part
then using this way is quite common.
However, if it is simply not allowed to use any other implementation (because only your library core may implement the interface), then asserting the type would be nice too; this would provide a nice landing in the debugger or crash-dump for any user of the library who messed with it in a way it should not be done. Of course, the documentation should clearly indicate that deriving from A is a bad idea.
Your example code contains at least 4 syntax errors, so it's hard to judge what you're trying to do.
And it logically won't work either. You have a class AImpl that inherits A, then a member function that takes an A and appears to try to dynamic-cast it to an AImpl. But it isn't an AImpl, because it's just an A, as that is how the parameter is declared. If you were to pass an instance of AImpl to that function, it would be sliced down to just an A.
You could make it a reference or pointer to an A, and then it could be an AImpl. Dynamic casts are only ever of use on references or pointers.
Down-casting is used when we have a variable or parameter that has the static type of a base class but we logically know that it is (or might be) of a derived class. It is avoided wherever possible because it means that the compilation process is not able to completely check the type-correctness of the program, i.e. the answer to the question "are you trying to put a square peg into a round hole" cannot be fully answered until runtime.
Update after question was edited
It sounds like you want clients of your library to have access to a limited interface to an object, A, but when they pass it to a function in your library you will have access to the full interface. You could just use friend for this.
class A
{
friend class LibraryThing;
void visibleToLibraryThing();
public:
// ctor, etc.
void visibleToAll();
};
class LibraryThing
{
public:
void foo(A &a)
{
a.visibleToLibraryThing();
}
};
The LibraryThing class can access the private members of A, because it is declared as a friend of A.
The downside is that LibraryThing can access everything in A, so it means that as the author of the library, you won't be able to benefit from encapsulation. Only users of your library will.
You can use PIMPL to hide implementation details, mask dependencies, and speed up builds.
http://www.gotw.ca/gotw/028.htm
http://www.ddj.com/cpp/205918714
http://www.gotw.ca/gotw/024.htm