Engineering Problem or Greed Problem?

Engineering Problem or Greed Problem?

In the public park, there are many cement benches installed for resting. 

In first picture, in grey color, in good condition, you can see the old installations. There are 21 of them in which one of them got completely damaged into pieces. All of the others showing wear and tear due to years of use. But they still meet the basic requirement: you can sit on them.

In the second picture, in green colour, you can see the new installations. Out of 15, already 5 of them are broken as seen in the picture. 

The bending moment diagram shows the new design supposed to have less BM at centre because of the fixed-fixed support. (Even after considering extra length between supports)

So, what went wrong in new design?

If you observe carefully, there is nut and bolt joint at support. Initially it might have behaved as per design. That is fixed-fixed beam. But because of negative bending moment at both ends, after few cycles, the joint might have lost its design intent. Now it is more like a simply supported beam with a higher BM at centre. So the same cross section might have failed because of change in support behaviour.

You may be thinking 

just increase factor of safety

Or

Just add cement at required proportion

So

Is it an engineering problem or Greed Problem??

Coding Practices: Which is better? #pragma once or #include Guard

In C or C++, we need to ensure that a header file is not included more than once.
Let us say you have a header file named add.h which declares an adding function (We are not discussing the corresponding cpp files for simplicity). Now let us say you have another header file my_math.h which declares further mathematical functions. If you want to use previously mentioned adding function here, you need to include add.h in my_math.h file.When you want to use functions from both header files in, say, main.cpp, you should ensure that you are including only my_math.h. Otherwise you will get multiple declaration error for adding function because it is coming from both add.h and my_math.h as shown below.

add.h: add(int a, int b)
            /   \
          /       \
        /           \
my_math.h    /
      /           / 
    /           /             
     main.cpp   

As the example case is very simple it is easy to avoid the inclusion of add.h in main.cpp. But doing that will be difficult and sometimes impossible in real life programs. The standard solution for this is to use #include guard as shown below

/*add.h*/

#ifndef _ADD_H_

#define _ADD_H_

/*

Your content goes  here

*/ 

#endif    /*   _ADD_H_  */                                      

 The per-processor will ensure that only one copy of the add.h content is passed to compiler.

A new and easy alternate is adding

#pragma once

at the beginning of the code. This looks very neat. But it is not yet standard. So for better portability we should use #include guard.


References:

1. http://en.wikipedia.org 
2. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
3. http://www.codeproject.com/Articles/26222/C-Coding-Practices-Guide
4. http://www.possibility.com/Cpp/CppCodingStandard.html
5. http://stackoverflow.com/questions/1143936/pragma-once-vs-include-guards 

The diamond problem

Today I came across "Diamond Problem". As usual Wikipedia gives the best basic information
http://en.wikipedia.org/wiki/Diamond_problem#The_diamond_problem

 

 

Some text copied here for quick reference.

C++ by default follows each inheritance path separately, so a D object would actually contain two separate A objects, and uses of A's members have to be properly qualified. If the inheritance from A to B and the inheritance from A to C are both marked "virtual" (for example, "class B : virtual public A"), C++ takes special care to only create one A object, and uses of A's members work correctly. If virtual inheritance and nonvirtual inheritance are mixed, there is a single virtual A and a nonvirtual A for each nonvirtual inheritance path to A. C++ requires stating explicitly which parent class the feature to be used is invoked from i.e. "Worker::Human.Age". C++ does not support explicit repeated inheritance since there would be no way to qualify which superclass to use. C++ also allows a single instance of the multiple class to be created via the virtual inheritance mechanism (i.e. "Worker::Human" and "Musician::Human" will reference the same object).

For further understanding read http://www.cprogramming.com/tutorial/virtual_inheritance.html

lso, it looks like declaring one class as virtual won't work see below link
http://stackoverflow.com/questions/13752482/virtual-inheritance-one-class-enough#

QT Learning

It was interesting to read that one of the expansion of QT is cute.

The class diagram of QT will be very useful. Searched in Google and found one. But it is for the version 4.3.
http://web.njit.edu/all_topics/Prog_Lang_Docs/html/qt/classchart.html

Because of enormous size, the class diagrams are not available for new versions (at least I was not able to find). Even if it is available, it will be very difficult to use or make sense out of it. One easy approach I started following is to make simple class diagrams from "Inheritance Hierarchy" (Available in QT documentation) for the QT classes useful for my project. That way I will get understandable and useful small class diagrams avoiding unused classes. These class diagrams can be a part of development documentation and helps to decide best way to inherit QT classes in our project.

Pair programming

I liked it.

http://en.wikipedia.org/wiki/Pair_programming

"Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently. "

I liked the concept but I am not sure it always help. I would prefer programming as small groups with 3 to 5 members. With good version control system and at least one expert in each team it will be very effective. Dividing the tasks for each in a quick group discussion will help to avoid duplication of work and improve knowledge of everyone.

I further read something interesting about pair programming by Joel in
http://www.joelonsoftware.com/articles/FiveWorlds.html



"  Lo and behold, I discovered that very few of the bugs in there would have been discovered with pair programming or test driven development."

Introduction

I would like to share and keep a note of my thoughts on software development. Mostly I will upload the contents of other web sites which are interesting to me. Also I will add my opinion about what I am reading.