Awareness to env variable

Did not observe this issue so far, I was using an environment variable and the pointer to environment variable's value got modified in locally. And the next time when we call getenv to that same environment variable, It should give unmodified value. But it did not happen.

Eg.
export ENV_TEST_TIME=20:20

char* getTime (void)
{
char *pTime = getenv("ENV_TEST_TIME");
printf("\nEnv Time %s",pTime);
pTime[2]='\0';
return pTime;
}

int main(void)
{
printf("\nCall getTime %s",getTime());
printf("\nCall getTime %s",getTime());
return 0;
}
------------------------- output --------------
Env Time 20:20
Call getTime 20

Env Time 20
Call getTime 20

From the output, 'Env Time' value should be same for the both time of getTime function call but it differs. Hence, the getenv internally maps env variable to value and maintenance modified value until the application completes. So do not use env value directly to object manipulations.

Wet and Dry LAB

Today I spoke to my cousin who was in his lab, While I was talking to him about his work, I came across Wet and Dry LAB terminology...

Basically the Wet and Dry LAB, which are the biological testing space.

Dry LAB: The lab which is for analyzing biological DNA, RNA, PROTEIN, etc through the computer simulations or models with thier mathematical or computational .

Wet LAB: The lab which is for applying direct analyze result into physical biological realm. In this lab chemicals, drugs are used to explore on biological realm. Mostly the dry lab result's real evaluation is taken place in this lab.

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

Why the bottom of flame is wider than its edge?

The candle can be wax or oil. As we know the candle is light source , we will do a small analysis on that. Lets consider the wax candle in our cases. The candle is lighted by heat of the match or other candle flame. Prior to candle being ignited, The wick is saturated with fuel in its solid form and the wax first melts into fuel form then it vaporize a small amount and mix with oxygen to form flame. The heat of the flame melts the top of the solid wax, the liquefied fuel moves upwards through the wick via capillary action.

Here, The vaporized wax has higher atom movements, as well the vaporization starts from bottom to top, the atoms are higher in bottom of the flame than its edge.

Test Vaporization:
Ignite two candles, then blow out one candle, after the blowing out, immediately we can see the the white gas flow in the air, just bring the another candle near to that gas air, that candle ignited very fast, since that gas is nothing but the vaporized wax.

Doxygen & GraphViz

As most of the developers know and use doxygen for the documentaion purpose. if we can add the graphviz to doxygen we can get Class collaborative diagrams as well in a neat.

Graphviz is for represent information in a graphical Notaion. Which understand 'dot' language.
http://www.graphviz.org/

The minimum requirement of Doxygen version is 1.5.x. http://www.stack.nl/~dimitri/doxygen/download.html#latestsrc

Follow the below steps
1) doxygen -g "filename" -> generates a file, which contains the list of supported tags to enable or disable.

2) Enable following basic tags from the generated file.

a. EXTRACT_ALL = YES

b. INPUT = ‘input source directory path to be document”

c. FILE_PATTERNS = *.h\ *.C

3) Doxygen uses the "dot" tool to generate the following graphs

• if GRAPHICAL_HIERARCHY is set to YES, a graphical representation of the class hierarchy will be drawn, along with the textual one. Currently this feature is supported for HTML only.
  Warning: When you have a very large class hierarchy where many classes derive from a common base class, the resulting image may become too big to handle for some browsers.
• if CLASS_GRAPH is set to YES, a graph will be generated for each documented class showing the direct and indirect inheritance relations. This disables the generation of the built-in class inheritance diagrams.
• if INCLUDE_GRAPH is set to YES, an include dependency graph is generated for each documented file that includes at least one other file. This feature is currently supported for HTML and RTF only.
• if COLLABORARION_GRAPH is set to YES, a graph is drawn for each documented class and struct that shows:
• the inheritance relations with base classes.
• the usage relations with other structs and classes (e.g. class A has a member variable m_a of type class B, then A has an arrow to B with m_a as label).
• if CALL_GRAPH is set to YES, a graphical call graph is drawn for each function showing the functions that the function directly or indirectly calls.
• if CALLER_GRAPH is set to YES, a graphical caller graph is drawn for each function showing the functions that the function is directly or indirectly called by.

Vtbl leaks and generic pointer typecast:

As everybody knows, a "VTable" (short for "virtual table") is a data
Structure used to lookup methods when they are called dynamically. In
C++, it is generated by the compiler. If there is a problem in
Vtable, it's a bit tricky to know the reasons.

I had the following problem with Vtable :-

In mutiple hierarchical implementation, create an object from derived class and typecast into genric pointer then upcast that genric pointer into one of parent class object pointer. And then invoke a late binding method, the Vtable internally will call a different 'method name'. Let discuss this problem in details. The sample code
is shown in below.

///////////////////////////////////////vtbltest.h///////////////////////////

#ifndef VTBL_TEST_H
#define VTBL_TEST_H

#include

using namespace std;

class A
{
public:
virtual ~A();
virtual void fun () = 0;
virtual void act () = 0;
virtual void show () = 0;
};

class B
{
public:
virtual ~B();
virtual void draw () = 0;
};

class C : public B, public A
{
public:
virtual ~C();
virtual void fun();
virtual void act();
virtual void show();
virtual void draw();
};

#endif

////////////////////////////////////////////////////////vtbltest.C//////////

#include "vtbltest.h"

A::~A()
{ cout<<"\nA::~A";}
B::~B()
{ cout<<"\nB::~B";} C::~C() {cout<<"\nC::~C";} void C::fun() { cout<<"\nC::fun";}
void C::act()
{ cout<<"\nC::act";}
void C::show()
{ cout<<"\nC::show";}
void C::draw()
{ cout<<"\nC::draw";}

int main ()
{
class C *pC = new C ();
//assign to generic pointer
void *pVoid = (void*) pC;
//assign generic pointer to the class A pointer.
//Note: Class A is Base class of Class C
class A *pA = reinterpret_cast(pVoid);
//invoke a show method.
pA->show();
delete pA;
return 0 ;
}

The abstract class 'A' and 'B' are inherited by the concrete class
'C'. Create an instance of C, typecast it to generic pointer, then
re-typecast the generic pointer to either base class 'A' or 'B' and
then invoke a method 'show'.

The expected output is:
C::show
C::~C
A::~A
B::~B

But the actual output is:
C::act
C::~C
A::~A
B::~B

We end up with a big mess. Let us understand this misbehavior by knowing what is happening with the virtual table. We will debug with gdb ...

[amaran@buildsrv c++]$ gdb ./a.out
...
...
...
(gdb) b main
Breakpoint 1 at 0x8048bc6: file vtbltest.C, line 41.
(gdb) r
Starting program: /home1/amaran/learning/c++/a.out
Breakpoint 1, main () at vtbltest.C:41
41 class C *pC = new C ();
(gdb) n
42 void *pVoid = (void*) pC;
(gdb) n
43 class A *pA = (class A*)pVoid;
(gdb) n
45 pA->show();
(gdb) p pC
$1 = (C *) 0x804b008
(gdb) p pVoid
$2 = (void *) 0x804b008
(gdb) p pA
$3 = (A *) 0x804b008
(gdb) p *pC
$4 = {<\B> = {_vptr.B = 0x804a148},
<\A> = {_vptr.A = 0x804a168}, }
(gdb) p *pVoid
Attempt to dereference a generic pointer.
(gdb) p *pA
$5 = {_vptr.A = 0x804a148}
(gdb)

Look at the gdb trace at $4 and $5. It shows the virtual table pointer values. The pointer pC shows that the virtual table address of 'class B' is "_vptr.B = 0x804a148" and 'Class A' is "_vptr.A = 0x804a168". After typecasting of generic pointer and re-typecasting the pVoid to class A pointer, the class A pointer's virtual table address is "_vptr.A =0x804a148". Now compare pC's virtual table address with that of pA's. They do do not match (pC->"_vptr.A = 0x804a168" not equal to
pA->"_vptr.A =0x804a148").


What are the possible errors with the code?

1) Cast from Generic pointer to Class A pointer
2) Even if do above step, why vtable address is wrongly assigned
(possible vtable implementation leak)
3) Inheritance methodologies


Solutions:

1) Avoid cast to generic pointer in case of multiple inheritance.
2) if its indeed for existing desgin, first upcast object into base class pointer then type cast into genric pointer.

What might be happening the implementation of vtable:

When we do down cast to base class, the first virtual table pointer is assigned to that base class's vtable pointer. That is pC->vptrB address is assigned to pA->vptrA. The above code will work, if we upcast into class B not class A.