2008年9月21日星期日

configurate dns in solaris

su
vim /etc/nsswitch.conf

change:
hosts file
as
hosts file dns

[by Allen Liu]

2008年7月27日星期日

shell下emacs开启alt

kbdcontrol us.emacs ;use emacs keymap

shell下emacs开启alt

kbdcontrol us.emacs ;use emacs keymap

2008年7月24日星期四

Q: What is a test scenario?

A: The terms "test scenario" and "test case" are often used synonymously. Test scenarios are test cases or test scripts, and the sequence in which they are to be executed. Test scenarios are test cases that ensure that all business process flows are tested from end to end. Test scenarios are independent tests, or a series of tests that follow each other, where each of them dependent upon the output of the previous one. Test scenarios are prepared by reviewing functional requirements, and preparing logical groups of functions that can be further broken into test procedures. Test scenarios are designed to represent both typical and unusual situations that may occur in the application. Test engineers define unit test requirements and unit test scenarios. Test engineers also execute unit test scenarios. It is the test team that, with assistance of developers and clients, develops test scenarios for integration and system testing. Test scenarios are executed through the use of test procedures or scripts. Test procedures or scripts define a series of steps necessary to perform one or more test scenarios. Test procedures or scripts may cover multiple test scenarios.

[Ref]
http://www.robdavispe.com/free2/software-qa-testing-test-tester-2240.html

How complier invoke a member function

There are three steps complier to find function you call
1. Search function name match
2. Get the most approach one
3. Check right of function

class C
{
public:
void F(){}
};

class D : public C
{
void F(){}
};

...
D d;
d.F(); //wrong! why?

First, the complier find a function named F(). (D::F())
Second, check the param list
Third, check the right

Scenario 2:
class C
{
public:
void F(){}
};

class D : public C
{
int f;
};

...
D d;
d.F(); //wrong! why?
First, the compiler find name as f (D::f)
so why should we use m_f as member var name.

2008年7月21日星期一

virtual inherit [Ref:wikipedia]

class Animal
{
public:
virtual void eat();
};

class Mammal : public Animal
{
public:
virtual Color getHairColor();
};

class WingedAnimal : public Animal
{
public:
virtual void flap();
};

// A bat is a winged mammal
class Bat : public Mammal, public WingedAnimal {};
...
Bat bat;

But how does bat eat()? As declared above, a call to bat.eat() is ambiguous. One would have to call either bat.WingedAnimal::Animal::eat() or bat.Mammal::Animal::eat(). The problem is that semantics of conventional multiple inheritance do not model reality. In a sense, an Animal is only an Animal once; a Bat is a Mammal and a WingedAnimal, but the Animalness of a Bat's Mammalness is the same Animalness as that of its WingedAnimalness.

This situation is sometimes referred to as diamond inheritance and is a problem that virtual inheritance works, in part, to solve.


Solution

We can redeclare our classes as follows:

// Two classes virtually inheriting Animal:
class Mammal : public virtual Animal
{
public:
virtual Color getHairColor();
};

class WingedAnimal : public virtual Animal
{
public:
virtual void flap();
};

// A bat is still a winged mammal
class Bat : public Mammal, public WingedAnimal {};

Now the Animal portion of Bat::WingedAnimal is the same Animal as the one used by Bat::Mammal, which is to say that a Bat has only one Animal in its representation and so a call to Bat::eat() is unambiguous.

This is implemented by providing Mammal and WingedAnimal with a vtable pointer since, e.g., the memory offset between the beginning of a Mammal and of its Animal part is unknown until runtime. Thus Bat becomes (vtable*,Mammal,vtable*,WingedAnimal,Bat,Animal). Two vtable pointers per object, so the object size increased by two pointers, but now there is only one Animal and no ambiguity. There are two vtables pointers: one per inheritance hierarchy that virtually inherits Animal: One for Mammal and one for WingedAnimal. All objects of type Bat will have the same vtable *'s, but each Bat object will contain its own unique Animal object. If another class inherits Mammal, such as Squirrel, then the vtable* in the Mammal object in a Squirrel will be different from the vtable* in the Mammal object in a Bat, although they can still be essentially the same in the special case that the squirrel part of the object has the same size as the Bat part, because then the distance from the Mammal to the Animal part is the same. The vtables are not really the same, but all essential information in them (the distance) is.

overidde operator with const modify

A:int operator [](int i) const;
B:inst operator [](int i);

//invoke B
X x;
x[1] = 1;

//invoke A
const X x;
int a = x[1];