test driven development

Notes:

the wikipedia page as usual has good links....here is my notes on them

http://homepage.mac.com/hey.you/lessons.html : has some good advice on test driven development
http://www.agiledata.org/essays/tdd.html : not bad has some good comparisons and clear up on confusions

etc.
http://www.agileadvice.com/archives/2005/05/the_qualities_o.html : good one.
http://blog.james-carr.org/?p=44 : types of unit tests that you want to guard against
http://www.agileadvice.com/archives/2005/05/the_qualities_o.html : qualities of a good unit test
http://msdn.microsoft.com/msdnmag/issues/06/01/UnitTesting/default.aspx how to write unit tests
http://weblogs.asp.net/rosherove/archive/2007/10/08/the-various-meanings-of-tdd.aspx interesting to read...kind of philosphical...

Scrum Notes

Wikipedia has a good article.

http://www.softdevarticles.com/modules/weblinks/viewcat.php?cid=46 this page a no of articles the good ones are :

Adaptive project management using scrum -- I think this is a general primer on scrum. interesting to go thru the slide deck link in the end of the article.

Agile development lessons learned from the first scrum --feels like a standard primer only....dont think i read it

its not just stand up...patterns for the daily scrum meeting ---good one...worth reading

inventing and reinventing scrum in five companies ---feels more like jeff's blah....dont think it is worth it

when to think about shortening your sprint ..a toolset ---good list of things for which you might want to cut down your sprint length

Distributed Scrum: agile project management with outsourced development teams --- good to read...since the title is so relevant to us and indicates how they managed their inter continental development teams with language and time constraints.

looking at other links from the wikipedia page:
the two google video presentations from ken schwaber and jeff sutherland are good to go through....jeff hsa numbers and ken has good stories and nice talk.

the original paper of the japanese ( the new newproduct development way) is also a good read.

item 46 and item 47 ...dont really understand them

i need to work on them be clear and then sort them out

Factor parameter independent code out of templates

Commonality and variablity analysis….interesting word for a simple thing that we do

In non template code repliation is explicit, you can see that there's duplication between two functions or two classes. In template code replication is imlicit there;s only one copy of the template source code ..but replication happens when the template is instantiated multiple times.

Non type parameters and type parameters both can cause bloat.

There are a lot of factors involved in determining performance improvement like size of binary, locaity improvement, cimpiler optimizations, program's working set size.

The best way to find the effect is to just try it out on representative data sets and the platforms concerned.

Things to remember:
Templates generate multiple classes and multiple functions, so any template code not dependent on a template parameter causes bloat.

Bloat due to non type template parameters can often be eliminated by replacing tempalte parameters with function parameters ro class data members.

Bloat due to type aparameters can be reduced by sharing implementations for instantiation types with identical binary representations.

use member function templates t o accept all compatible types

real pointers support implicit conversions very well.  (eg. derived->base, non const -> const)

iterators into stl containers are almost always smart pointers

class top

class middle : public top

class bottom : public middle

now in templates to ge tmiddle to convert to top we need

template <typename t?

class smartptr {

public:

explicit smartptr(t* realptr);

};

smartptr<top> pt1 = smarptr<middle>(new middle); to get this to compile we will need the corresponding constructor in the smartptr definition, since compilers dont assume any relation between smartpttr<top> and smartptr<middle> classes.

 

easiest way to get around is ( but bad)

template typename<t>

class smartptr{

public:

template <typename u>

smartptr(const smartptr<U> & other);,....

}

but this allows converting top object to middle object also.

such functions are called generalized copy constructors. its not declared explicit sive type conversions among built in pointer types.

so what we do is simply use member initialization list to initialize parameters with true ptrs of the other object . then it can compile only if each naked ptr can be converted to the type to which we are trying to convert the object.

 

there are more things here that i dont really understand ...

c+= states that if a copy constructor is needed and you dont declare one it will be generated for you ( so if you only have a generalized template than it wont be used by the compiler )

things to remember:

use member function templates to generate functions that accept al lcompatible types

if you declare member templates for generalized copy construction or generalized assignemnt you will still need to declare normal copy constructor and copy assignment operator also.

know how to access names in templatized base classes

when compilers encounter the definition of derived class they dont know what class it inherits from, so they wont find functions defined in the base class, since it doesnt know which base template it is inheriting from ( c++ does this base may actually be translates to a total template specialization that doesnt define the particular function in question)

so basically in templates inheritance stops working.
three ways around this :

prefix calls to base class functions with this-> ( why does it work ?...as in how does it work underneath?)
use a using declaration e,g,
template
class logginmsgsender:public msgsender {
public:
using msgsender::sendclear ;
void sendclearmsg(msginfo& info)
{
sendClear(info);
}
};

or you can exactly specify the function being called in the base class as in
msgsendder::sendclear(info)

its least desirable because if senclear is virtual than the effect of virtual is lost

note that all of these solutions basically promise the compiler that the definition of the function will be available, and so when it sees a call to senclearmsg and if it found that the expected function is not available, then it will still give you a compiler error.

so basically the availablity of a function call or something else is checked only when its usage is encountered.....so if i declare a class that doesnt define sendclear function but neither uses sendclearmsg function than it will compile and execute without error ? is that right ?

things to remember:
in derived class templates refer to names in base class templates via a this->prefix via using declarations or via an explicit base class qualification.

understand the two mieanings of typename

names in a template that are dependent on template parameters are called dependent names.

when a dependent name is nested inside a class it is a nested dependent name.

nested dependent type name i.e. a nested dependent name that refers to a type

non dependent names --opposite of this

if the parser encounters a nested dependent name in a template it assumes that the name is not a type unless you tell it otherwise. by default nested dependent typenames are not types.
so u say: typename c::const_iterator iter(container.begin());
the simple general rule is that anytime you refer to a nested dependent typename in a template you must immediately precede it by the word typename

exception to above rule is that typename must not precede nested dependent type names in a list of base classes or as a base class identifier in am ember initialization list.

typedef typename std::iterator_traits::value_type value_type
value_type temp(*iter)

enforcement of the typename rule varies from compiler to compiler.

things to remember:
when declaring template parameters class and typename are interchangeable.
use typenames to idnetify nested dependent type names except in base class lists or as a base class identifier in a member initialization list

understand implicit interfaces and compile time polymorphism

oops revolves around explicit interfaces and runtime polymorphism

in template programming implicit interface and compile time polymorphism move to the fore.

basically the point is that the interface that a template class must support is defined by the operations and function calls that has been made on the object instantiated from it.

so if their is a template class and two different fns are involed on two different instantiations then do both types need definition of that kind of object ?a1.f00() , a2.foo1() ---- does this mean a1.foo1() also has to be defined ?? ..not sure if this quesiton makes sense

things to remember:
both classes and templates support interfaces and polymorphism
for classes interfaces are explicit and centered on function signatures, polymorphism occurs at runtime through virtual functions
for template parameters interfaces are implicit and based on valid expressions polymorphism occurs during compilation through template instantiation, and function overloading resolution.

use multiple inheritance judiciously

in mi it comes becomes possible to inherit the same name ( function,typedef etc) from more than one base class....potential ambiguity
class borrowableitem{
public:
void checkout();
};
class electronicgadget{
private :
bool checkout() const;
}
class mp3player: public borrowable, public electronicgadget { }
mp3player mp3

mp3.checkout() is ambigous because to find hte appropriate function to call c++ doesnt worry about its access level.

deadly diamond
whenever you have diamond think whether their should be only one copy of the base class or it should be one per path.
if you only want one copy of the base class then make the derived classes have a virtual inheritance. e.g.
class file {}
class inputfile : virtual public file {...}
class outputfile: virtual public file {...}
class iofile: public inputfile, public outputfile {,,}
what structure of outputfile was just normal inheritance ?
what if outputfile has virtual private inheritance ?

STL has a similar class hierarchy in basic_ios, basic_istream , basic_ostream and they are all templates

the reponsiblity for initializing a virtual base class is born my the most derived class....that means a derived class has to be aware of a virtual base, independent of how far down it is

try not to use virtual inheritance. if you must try not to put data members in there.

inheritance is necessary if virtual functions are to be redefined

things to remember:
multiple inheritance is more complex than single inheritance., it can lead to new ambiguity issues and to the need for virtual inheritance.
virtual inheritance imposes costs in size speed and complexity of initialization and assignment. its most practical when virtual base classes have no data.
multiple inheritance does have legitimate uses. one scenario involves combining publid inheritance from an interface class with private inheritance from a class that helps the implementation.

Use private inheritance judiciously

compilers dont convert a derived class object into a base class object automatically if you privately inherit

private inheritance means you want to exploit some features available in base class, and not that their is any conceptual relationship between them

use composition whenever you can, use private inheritance when you must..genrally when protected or virtual functions are in picture and in edge cases space concerns ....I dont understand this point ?

having a composition object inside yourself, you can prevent derived classes from redefining your inherited virtual functions.

now edge case: think class with no data ( no non static data , no virtual functions, no virtual bases)such an empty class would have size more than 1 due to c++ technical issues...generally compiler inserts a char, depending on alignment etc you might see different size increase.
c++ decrees that free standing objects must have non zero size.
class holdsint { int x ; empty e } has size more than int

Empty base optimization class holdsint:private empty { int x } has size int....its generally viable under single inheritance only.

rules governing c++ object layout generally mean that the ebo cant be applied to derived classes that have more than one base

generally empty classes have typedefs enums static data non virts etc.....stl has a no of empty classes....e.g. unary_function and binary_function

private inheritance is most likely to be a legitimate design strategy when you are dealing with two classes not related by is a where one either needs a ccess to the protexted members of another or need to redefine one or more of its virtual functions.

things to remember:
private inheritance means is implemented in terms of . its usually inferior to composition but it makes sense when a derived class needs access to protected base class members or needs to redefine inherited virtual functions

uinlike composition privaet inheritance can enable the empty base optimization . this can be important for library developers who strive to minimize object sizes.

model has a or is implemented in terms of through composition

composition is also known as layering, containment, aggregation and embedding

their are two kinds of objects....objects in the real world and implementation artifacts ( buffers, mutexes, search trees)

things to remember:
composition has meanings completely different from that of public inheritance
in the application domain, composition means has a , in the implementation domain it means is implemented in terms of .

Never redefine a function's inherited default parameter value

Virtual functions are dynamically bound whereas default parameter values are statically bound

I wonder why compilers cannot check for this case themselves ?

How will this interact with the case where you don't know the number of arguments beforehand ..not sure even If that is an issue ?

You can use the nvi idiom, , public non  virtual specifies the default argument and then each private virtual can have its argument. Then it is clear and no redefinition happens in derived  Not sure what the author means here ?

Things to remember:
Never redefine an inherited parameter value, because default parameter values are statically bound, while virtual functions --the only functions you should be redefining -- are dynamically bound

Never define an inherited non virtual function

If mf is non virtual and Base and derived have their own version of this function then

D x;
B* pb = &x
D* pd = &x;
Pb->mf() & pd->mf() will call different functions.

References exhibit the same baffling behavior as pointers above. I don't really understand this ??

Things to remember:
Never redefine an inherited non virtual function

consider alternatives to virtual functions

the template method pattern via the non virtual interface idiom
 write a public function that does the before work ( taking a lock, checking conditions) , calls a virtual fn to do the work and than does after work ( logging etc). generally that virtual fn is private ? why?
general design is clients call private virtual functions through public non virtual member functions- is known as the non virtual interface idiom.

non virtual function is like the virtual function wrapper.
note that derived classes redefine private virtual functions ? it says that is ok...but i am not convinced?
what if some library class has virtual and then we inherit and accidently override that function.
what if you just declare a virtual function without virtual in a derived class without he qualifier ??


the strategy pattern via function patterns
pass a function pointer with the defined type that is stored. and then call that function.

note that using the function pointer to calculate the health means that you need to weaken the encapsulation and provide either public accessors or make it a friend function.

strategy pattern via tr1::function pointer
why  health calculator shud be a function and not something that just acts like a function.

you can use the tr1::bind function to bind an argument to a function.

the classic strategy pattern

standard pattern.
to calculate health of a object , have a separate hierarchy of calculation functions, and keep an object of these calculation functions inside the object.

summary:
use the non virtual interface idiom. a form of the template method design pattern that wraps public non virtual member functions around less accessible virtual functions.

replace virtual functions with function pointer data members, a stripped down manifestation of the strategy design pattern

replace virtual functions with tr1::function data members thus allowing use of any callable entity with a signature compatible with what you need. this too is a form of the strategy design pattern

replace virtual functions in one hierarchy with virtual functions in another hierarchy. this is the conventional implementation of the strategy design pattern

things to remember:
alternative to virtual functions include the nvi idiom and various forms of the strategy desing pattern the nvi idiom is itself an example of the template design pattern

a disadvantage of moving functionality from a member function to a function outside the class is that the non member function lacks access to the class's non public members

tr1::function objects act like generalized function pointers, such object support all callable entities compatible with a given target signature

differnentiate between inheritance of interface and inheritance of implementation

the difference between these two is same as the difference between function declaration and function definition.

member function interfaces are always inherited.public inheritance means that trivially
the purpose of declaring a pure virtual function is to havea a dervied class inherit a function interface only.

you can provide a definition for a pure function also, but not a ver useful thing in general.

the purpose of declaring  simple virtual functions is to have derived classes inherit a function interface as well as a default implementation.

to avoid the chance of forgetting to define a proper version when a new class comes in, then you can define a function in the interface that is pure virtual and have it call a portected virtual function to do the actual thing.

that way every new class has to define the virtual function and it gets you
a non virtual member function specifies and invariant over specialization

pure virtual - interface only
simple virtual --interface and  default implementation
non virtual -- interface and a mandatory implementation

things to remember:
inheritance of interface is different from inheritance of implementation. under public inheritance derived calsses always inherit base class interfaces.
pure virtual functions specift inheritance of interface only
simple virtual functions specify inheritance of interface plus inheritance of a default implementation.
non virtual functions specift inheritance of interface plus inheritance of a mandatory implementation

avoid hiding inherited names

scope a derived class is nested inside its base class's scope

only names matter for determining what gets hidden
so if u define a fn in base and same name is defined in derived than that name will hide all the names in base.

if you want to carry over all names from base , use using base::name
is this behavior same for virtual functions also ? does their signature have to be exactly same ? check on this ?

if u want to enable only a few variants from the overload, than just have a forwarding function.
how do you do this if you want to bring in a variable definition in scope ?

things to remember:
names in derived classes hide names in base classes. under public inheritance this is never desirable.
to make hidden names visible again, eploy using declarations or forwarding functions



--
Regards,
Umesh Kumar

http://worthyarticles.blogspot.com/
http://learnbooks.blogspot.com/
http://cplusplusnotes.blogspot.com/

make sure public inheritance models is a relationship

a derived class is a specialized version of base class so it should follow all constraints and provide all functionalities of the base class.

so pre conditions of dervied shud be subset of pre conditions of base
post conditions shud be superset of post conditions

differentiate between penguins cant fly and penguins can fly, but it is actually an error to make them fly.

things to remember:
public inheritance means is a . everything that applies to base classes must also apply to derived classes, because every derived class object is a base class objects

Minimize compilation dependencies between files

In general a class specifies not just interface but a fair no of implementation details. Like private variables, inline functions etc.

Including standard headers is unlikely to be the problem as you can take advantage of precompiled headers.

You can use the pimpl idiom to get around with hiding the impl from the clients

I don't understand what is the meaning of replace dependencies on definitions with dependencies on declarations. ????
This minimizes compilation dependencies.

Two rules to follow:
Avoid using objects when object references and pointers will do
Depend on class declarations instead of class definitions whenever you can. ---I don't understand the note about moving dependencies to client's files at bottom of page 143 ???

Provide separate header files for declarations and definitions.

Look at iosfwd header file.???

Handle classes are classes that employ the pimpl idiom
They generally forward all their calls to the base class.

Or you can have an interface class exposed to client and actual class that implements the interface. Then you provide a static factory function that gives the actual class ( typically a shared pointer to it).

Obviously both of these approaches have the cost of most fn calls being virtual function calls.

Things to remember:
The general idea behind minimizing compilation dependencies is to depend on declarations instead of definitions. Two approaches based on this idea are handle classes and interface classes.

Library header files should exist in full and declaration only forms,. This applies regardless of whether templates are involved or not

Understand the ins and outs of inlining

Compilers are designed to optimize nicely over stretches of code without function calls.

Inlining can cause code bloat -> lower hit rates,memory crunch -> bad performance
Define function inside a class also makes it inline.
Inline functions should typically be in header files. Since inlining is generally a compile type thing
Compilers choose whether to inline or not
All but the trivial virtual fns are generally not inlined.
Most compilers have a diagnostic level that will result in a warning if compiler cant mark a function inline.
If your program takes the address of a function then the body of the function wud be generated even if compiler can imline it. Even if you don't do it ,sometimes compilers might just do that.

Compilers put hteir own code in constructors and destructors for handling exception, destruction In case of incomplete construction, calling base class constructor for derived classes etc.

If u have a inline function then clients are using it  means it is in there code, so u change implementation of that fn means clients have to recompile.

One pain in coding is that debuggers have trouble with inline functions

Things to remember:
Limit most inlinking to small frequently called functions. This facilititates debugging and binary upgradablity, minimizes potential code bloat, and mizimizes the changes of greater program speed.

Don't declare function templates inline just because they appeat in header files

Strive for exception safe code

When exceptions are thrown, foolowng should happen:

 Leak no resources ---use resource classes to manage all resources. Such classes also make code shorter.
Don't allow data structures to become corrupted---don't be left pointing to a deleted object,

Exception safe functions offer one of the following guarantees:
Basic guarantee --- exception thrown means program will remain in a valid state ( invariants satisfied etc)though exact state maybe unknown

Strong guarantee -- exception thrown means program state is unchanged. Calls to such functions are atomic…so boolean success or failure

NoThrow guarantee-- never throw exceptions. All operations on built in types are no throw.

Exception safe code always offers one of the three guarantees above. If not its not exception safe.

Int doSomething() throw() ---this doesn't mean no exc thrown, but that if a exception is thrown means serious error and call unexpected fun.

Try strongest guarantee but very hard.Strong guarantee is pretty hard because something could have changed state and you don't know what change it called

The general design strategy that you can use to get strong guarantee is copy , change copy  and swap in a non throwing oepration….obviously its costly and maynot give strong guarantee.

Normal : real obj = real obj { ptr to real data} --pimpl idiom

A functions exception safety guarantee is part of its interface….so give it as much weight as to other parts of its interface.

Things to remember:
Exception safe functions leak no resources and allow no data structures to become corrupted, even when exceptions are thjrown. Such functions offer the basic, strong on nothrow guarantees.

The strong guarantee can often be implemented via copy and swap, but the storng guarantee is not practical for all functions.

A function can usually offer a guarantee no stronger than the weakest guarantee of the functions it calls.