Python: How useful are lambda functions ?

Lets say you have this function defined:

def square1(x) : return x*x

We can check what square is:

>>> type(square1)
 

And use it like this:

>>>square1 (8)
64

It can be rewritten as an anonymous function or lamda as:

square2 = lamda x: x*x

and again when we check the type we get

>>> type(square2)
 

And it works the same way as the previous function

>>>square2 (8)
64

Now say we define a list:

list = [1,2,3,4,5,6,7,8]

and then we want to get the square of each number. Either of these will work:

>>> map (square1, list)
[1, 4, 9, 16, 25, 36, 49, 64]

and same result with

>>> map (square2, list)
[1, 4, 9, 16, 25, 36, 49, 64]

So far the benefit of leaning lambda functions is small. We have only used them to write a small function on the fly and the function has to be small as lambdas do not support multiple statements.

Perhaps the main motivation for lambdas can be illustrated with the following:

strategy = {
    'square' : lambda x: x*x,
    'double' : lambda x: x*2,
    'half'   : lambda x: x/2,
}
list = [1,2,3,4,5,6,7,8]
while(True):
    try:
        x =  raw_input("What would you like to do with the list ? ")
        map(strategy[x], list)
    except KeyError, e:
        print "The value entered is not valid: " + str(e)

The dict called strategy contains 3 lambda functions and if we had not used lambdas the we would have had to add the following lines:

def square(x) : return x*x
def double(x) : return x*2
def half(x)   : return x/x

If our strategy dict contained a lot more functions, it would start getting tedious to define all of these and then since the definition of the function would be in another part of the code, it would not be as quick and easy to see what 'square' does for example.

Preventing class D from being derived from class B

In some cases there are classes who should not have children.
There are some ways to recognise this:

1) Are there any virtual methods ?
It is unlikely that you should derive from a class which has no virtual methods.  For example if the base class B has method foo which is non virtual, the derived class D cannot override (re-implement) or overload the method foo without hiding the method B::foo.

If you need to hide B::foo in class D, then it implies that class D is not really a B (violation of the D is-a B principle).


2) Is the destructor virtual ?
If a class D is derived from B then you have to assume that someone will quite legally do this:
B* pb = new D;
which implies that they will also want to do:
delete(pb);

Now if B does not have a virtual destructor, the destructor for B will be called and not the destructor for D.  This can lead to memory leakage if D has pointers to other objects on the heap.

Therefore if the destructor is not virtual, you have to assume that you should not be deriving from this class
In the book "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices", it states
      "Make base class destructors public and virtual, or protected and nonvirtual"

If this is done it will help a user to see if it is intended to derive from a bass class

Discussion of std::vector

Note that in stl_vector.h, the destructor is defined as public and non-virtual.

Since the class has no virtual methods, then it is not a good idea to declare the destructor as virtual as this will add a virtual table lookup overhead for all method calls in this class. 
Also as the class is used as a concrete class the destructor has to be public.
Therefore in this case the destructor will be public and non-virtual.

The fact that the destructor is non-virtual and that there are no virtual methods implies that std::vector is not intended to be a base class of a derived class.

This may explain why there is no good documentation for deriving from stl containers, however I may make a few future posts where I do this and examine any pitfalls.

When to use friend functions over member methods

There are several arguments both for and against friend methods. Some of these arguments hold true in all cases and some only hold true depending on the context of programmer and his environment. Here is a summary of how I determine when to use friend functions or member methods.

1) Use member methods when it makes it much easier to see what methods are available
If you work in an organisation and you use an IDE where the member methods of each class are obvious, but the friend functions of the class are not obvious, use member functions. I've seen arguments on the web that say you should use non member friend functions to enforce encapsulation of the class and that crappy IDEs should not affect your decision. However in the commercial world where your company has invested in such and IDE, you can't afford to hide functionality from your colleagues.


2) If first arg cannot be a pointer to 'this', then a friend function will be easier to use 
For example consider operator<<

Say we have a class C which contains an int (e.g. 5) and a char (e.g. 'X') and we want to override operator<< to produce the result :5-X

int main() {
    C obj(5,'X');
    std::cout << "The value representing obj is " << obj << std::endl; // obj should be represented by 5-X

    return 0;
} 

If we define the class C with a the friend function operator<<, it should look like this:

class C { 
    friend std::ostream& operator<< (std::ostream&, const C&);
    public:
        C(int i, char c) : foo(i), bar(c)  {}; 
    private:
        int foo;
        char bar;

};
std::ostream& operator<< (std::ostream& ostr, const C& c) {
    ostr << c.foo << "-" << c.bar;
}

and the output is

The value representing obj is 5-X

Having the friend operator<< defined like this means we have the logical easy to read syntax of

std::cout << "The value representing obj is " << obj << std::endl;

We could have also used this syntax

std::cout << "The value representing obj is "; operator<<(std::cout, obj) << std::endl;

In the above, we are just more explicit in defining the arguments for operator<< Now say instead that we define operator<< as a member method:

class C {
    public:
        C(int i, char c) : foo(i), bar(c)  {};
        std::ostream& operator<< (std::ostream&);
    private:
        int foo;
        char bar;

};
std::ostream& C::operator<< (std::ostream& ostr) {
    ostr << foo << "-" << bar;
}

The only way to call this is

std::cout << "The value representing obj is "; obj.operator<<(std::cout) << std::endl;

Therefore defining operator<< to be a friend function is a much better option to using member methods. Some useful links:

http://www.faqs.org/faqs/alt.comp.lang.learn.c-c++/C++_FAQ_%28part_05_of_11%29/

read chapter [14.5] Should my class declare a member function or a friend function?

Also of interest
http://www.faqs.org/faqs/alt.comp.lang.learn.c-c++/C++_FAQ_(part_05_of_11)/#ixzz0cyteOeXg

When should a non-member function be a friend

Let's be clear, a private variable in a class is no longer really private when you define a get or set methods to read or update the variable.  Having the variable private in this case just means that you are hiding the name of the variable, not it's existence.


If you have to add a new public get/set method in order to get a non friend function to work, it is probably better that this function is a friend, rather than expose the private variable (via the get/set) to all other functions.  

Having a get/set method is OK if it makes sense that all other functions can use these to see the private variable, otherwise best not to expose the internals of the class via get/set.