For managed code, use SqlConnection’s StateChange event:

        static void Main(string[] args)
        {
            SqlConnection conn = new SqlConnection();

            conn.StateChange += ConnStateChangeEventHandler;

            conn.ConnectionString = "server=yourServerName; uid=yourUserName; pwd=xxxx; database=northwind";

            conn.Open();

            try
            {
                SqlCommand cmd = new SqlCommand();
                cmd.Connection = conn;
                cmd.CommandText = "select * from customer";

                cmd.ExecuteNonQuery();
            }
            catch (SqlException ex)
            {
                Console.WriteLine(ex.Message);
            }

            Console.ReadKey();

        }

        private static void ConnStateChangeEventHandler(Object sender, StateChangeEventArgs args)
        {
            Console.WriteLine("old state: {0}, new state: {1}", args.OriginalState, args.CurrentState);
        }

For ODBC application, use SQLGetConnectAttr to check the SQL_COPT_SS_CONNECTION_DEAD attribute:

UINT connection_state = SQL_CD_FALSE;
 
// check if the connection is broken
SQLGetConnectAttr(hdbc, SQL_COPT_SS_CONNECTION_DEAD, &connection_state, SQL_IS_UINTEGER, NULL);

if (connection_state == SQL_CD_TRUE )
{
    cout << “connection broken” << endl;
}

struct MyBase

{

  __int64 x;

  __int64 y;

  MyBase()

  {

          memset(this, 0, sizeof(MyBase));

  }

};

struct MyDerived: public MyBase

{

  int z;

  MyDerived():MyBase(), z(0)

  {}

};

Then create two objects as below, and then compare these two
objects with memcmp, do you think the c compare will be equal since the
constructor has initialized all the members of the objects to be 0?

MyDerived obj1;

MyDerived obj2;

if (memcmp(&obj1, &obj2, sizeof(MyDerived)) == 0)

{

        cout << "equal" << endl;

}

The answer is no. Since due to data alignment, the size of
MyDerived is 24 bytes, although the constructor has initialized x, y and z to
0, there are still 4 bytes keeps uninitialized, so they may be equal or not.

// a wrapper class which holds memory that’s allocated

// by using new []

template<class T>

class ArrayWrapper

{

public:

    ArrayWrapper(T* pData = NULL)

    {

        m_pData = pData;

    }

    ~ArrayWrapper()

    {

        delete [] m_pData;

    }

private:

    T* m_pData;

};

// code that use this class

{

    ArrayWrapper<WCHAR> buffer;

    buffer = new WCHAR[20];

}

Answer:

The first statement creates a new ArrayWrapper<WCHAR> object buffer which is initialized with NULL. The second statement create a temporary object, which is initialized with the address that is returned by the operator new, then the compiler copy the temporary object to buffer, then it call the destructor of the temporary object, this causes the memory to be freed. When the buffer object is out of scope, the same memory will be freed again and you have a double free issue.

while(*str1)

{

str1++;

};

while(*str2++);

Answer:

Str1 points to the terminating zero of the string. But str2 points to the memory address after the zero.

See the assembly of “while(*str2++);” will reveals how this statement work:

while(*str2++);

01043505 mov eax,dword ptr [str2]

01043508 mov cl,byte ptr [eax]

0104350A mov byte ptr [ebp-0F1h],cl

01043510 mov edx,dword ptr [str2]

01043513 add edx,1

01043516 mov dword ptr [str2],edx

01043519 movsx eax,byte ptr [ebp-0F1h]

01043520 test eax,eax

01043522 je ReverseStr+66h (1043526h)

01043524 jmp ReverseStr+45h (1043505h)

We can see it will fetch the value from the memory address pointed by str2 to eax, then increase str2 by 1 and then test if the eax is zero. The fetch and increase occurs first before the increase, thus cause str2 to point to the address after the terminating zero.

The “while(*str2++);” statement is the same as this code:

char temp;

do

{

        temp = *str3;

        str3++;

}while (temp);

void PrintNumber(int number)

{

        cout << number << endl;

}

int _tmain(int argc, _TCHAR* argv[]) 

{

        int numbers[] = {1,2,3,4,5};

        vector<int> vi(numbers, numbers+5);

        //vi.begin() and vi.end() return two iterators:

        for_each(vi.begin(),vi.end(),PrintNumber);

}

In .NET, you implement the iterator pattern using the IEnumerable and IEnumerator interfaces and their generic version IEnumerable<T> and IEnumerator<T>. IEnumerable returns an IEnumerator object and the IEnumerator objects implement the actual "iterator" code. You can use tools such as Reflector to check the classes such as List<T>, Dictionary<TKey, TValue> in .NET framework library to see how these classes implement the IEnumerable/ Ienumerable<T> interfaces. .NET language such as C# has more integral support for the iterator pattern, if a class implements the IEnumerale interface, you can use the foreach statement to access each element of the classes.

The yield return statement makes it even easier to implement the iterator pattern. For example, if you use yield return statement in below class, the compiler will generate code for you and the compiler generated code implements the IEnumerable interface and then you can use the class in the foreach statement, you can use reflector to check the compiler generated code to see how the IEnumerable interface is implemented:

public class DaysOfTheWeek

{

    string[] m_Days = { "Sun", "Mon", "Tue", "Wed", "Thr", "Fri", "Sat" };

    public IEnumerable Days()

    {

        for (int i = 0; i < m_Days.Length; i++)

        {

            yield return m_Days[i];

        }

    }

}

DaysOfTheWeek obj = new DaysOfTheWeek();

foreach(string day in obj.Days())

{

        Console.WriteLine(day);

} 

https://msdn.microsoft.com/en-us/library/ms724408(VS.85).aspx

The resolution of the GetTickCount function is limited to the resolution of the system timer, which is typically in the range of 10 milliseconds to 16 milliseconds.

To get higher resolution timing info, two popular options are:

1. The multimedia timeGetTime function, you can use this API to get 1 millisecond resolution timing info:

        TIMECAPS timeCaps = {0};

        //use timeGetDevCaps to get the minimum and maximum

        //resolutions supported by the system

        timeGetDevCaps(&timeCaps, sizeof(timeCaps));

        printf("minimum device resolution is %d millisecond(s)\r\n",timeCaps.wPeriodMin);

        printf("maximum device resolution is %d millisecond(s)\r\n",timeCaps.wPeriodMax);

        //use timeBeginPeriod to adjust the timer resolution

        //you cannot set the resolution smaller than timeCaps.wPeriodMin

        MMRESULT result = timeBeginPeriod(timeCaps.wPeriodMin);

        if(result == TIMERR_NOERROR)

        {

               printf("time resolution set to: %d millisecond(s)\r\n",timeCaps.wPeriodMin);

        }

        DWORD ticks1 = timeGetTime();

        //doing some operation here

        //Sleep(5000);

        DWORD ticks2 = timeGetTime();

        printf("time elapsed: %d\r\n",ticks2 - ticks1);

        //use timeEndPeriod to clear the resolution adjusted by the previous call //timeBeginPeriod

        timeEndPeriod(timeCaps.wPeriodMin);

Internally, when you call timebeginPeriod to adjust the timer resolution, it calls into ntdll!NtSetTimerResolution which goes into kernel to manipulate the timer hardware. This resolution adjustment can affect the OS thread scheduling behavior and it can affect other applications, applications such as Windows Media Player uses these APIs and we don't see bad effect.

2. To get even higher resolution timing info, you can use QueryPerformanceFrequency and QueryPerformanceCounter:

         LARGE_INTEGER frequencyPerSec = {0};

        LARGE_INTEGER start = {0};

        LARGE_INTEGER end = {0};

        if(QueryPerformanceFrequency(&frequencyPerSec))

        {

               QueryPerformanceCounter(&start);

               //do something here

               QueryPerformanceCounter(&end);

              printf("elaplsed time: %I64d second(s)\r\n",

                        (end.QuadPart - start.QuadPart)/frequencyPerSec.QuadPart);

        }

These APIs can get higher resolution but their overhead is higher than timeGetTime also.

Another option is the rdtsc counter but the currently hardware may have problems for this counter. Currently, SQL Server 2008 uses timtGetTime like mechanism and QueryPerformanceFrequency/QueryPerformanceCounter to get timing info, it does not use rdtsc anymore:

Issues caused by rdtsc:

https://support.microsoft.com/kb/931279/en-us

https://blogs.msdn.com/b/psssql/archive/2008/12/16/how-it-works-sql-server-no-longer-uses-rdtsc-for-timings-in-sql-2008-and-sql-2005-service-pack-3-sp3.aspx

https://blogs.msdn.com/b/psssql/archive/2007/08/19/sql-server-2005-rdtsc-truths-and-myths-discussed.aspx

00ce10a4 8b06            mov     eax,dword ptr [esi]
00ce10a6 8b10            mov     edx,dword ptr [eax]
……
00ce10ab 8bce            mov     ecx,esi
00ce10ad ffd2            call    edx {test![thunk]:Derived::Func1`adjustor{4}' (00ce10c0)}

When virtual function and multiple inheritance are involved, Visual C++ use the adjustor thunk technique to solve the vtable layout issue. Below sample code will make it clear how this technique works:

#include "stdafx.h"

class Interface1
{
public:
 virtual void Func1() = 0;
 virtual void Func2() = 0;
};

class Base1 : public Interface1
{
public:
 virtual void Func1() = 0;
 virtual void Func2() = 0;
};

class Base2 : public Interface1
{
public:
 virtual void Func1() = 0;
 virtual void Func2() = 0;
};

class Derived: public Base1, public Base2
{
public:
 Derived(int p1, int p2):m1(p1),m2(p2){}
 void Func1();
 void Func2();
private:
 int m1;
 int m2;
};

void Derived::Func1()
{
 printf("m1 = %d\r\n",m1);
}

void Derived::Func2()
{
 printf("m2=%d\r\n",m2);
}

int _tmain(int argc, _TCHAR* argv[])
{
 Derived* pObj = new Derived(1,2);

 Base1* pb1 = pObj;

 printf("called via Base1*, pb1 = 0x%x\r\n",pb1);
 pb1->Func1();
 pb1->Func2();

 
 Base2* pb2 = pObj;
 printf("called via Base2*, pb2 = 0x%x\r\n",pb2);
 pb2->Func1();
 pb2->Func2();
}

We can see that Derived inherits both Base1 and Base2; and both Base1 and Base2 inherit Interface1. The object inheritance is show in below:

If you run the code, you can get below results, note that pb1 and pb2 points to different memory address:

called via Base1*, pb1 = 0x561cb0
m1 = 1
m2=2
called via Base2*, pb2 = 0x561cb4
m1 = 1
m2=2

Run the code under windbg, we can see the generated assembly code for function wmain is as follows, and I have highlighted the key points:

0:000> uf test!wmain

1) 49 00ce1040 push    esi
2) 50 00ce1041 push    10h
3) 50 00ce1043 call    test!operator new (00ce11f3) >>>call operator new to allocate memory
4) 50 00ce1048 add     esp,4
5) 50 00ce104b test    eax,eax
6) 50 00ce104d je      test!wmain+0x35 (00ce1075)
7) 50 00ce104f mov     dword ptr [eax+4],offset test!Base2::`vftable' (00cea188) >>>Derived constructor begins
8) 50 00ce1056 mov     dword ptr [eax],offset test!Derived::`vftable' (00cea194)
9) 50 00ce105c mov     dword ptr [eax+4],offset test!Derived::`vftable' (00cea1a0)
10) 50 00ce1063 mov     dword ptr [eax+8],1
11) 50 00ce106a mov     dword ptr [eax+0Ch],2
12) 50 00ce1071 mov     esi,eax   >>>eax and esi contains the this pointer of pObj
13) 50 00ce1073 jmp     test!wmain+0x37 (00ce1077)
14) 50 00ce1075 xor     esi,esi
15) 54 00ce1077 push    esi
16) 54 00ce1078 push    offset test!`string' (00cea144)
17) 54 00ce107d call    test!printf (00ce10e7)
18) 55 00ce1082 mov     eax,dword ptr [esi]
19) 55 00ce1084 mov     edx,dword ptr [eax]
20) 55 00ce1086 add     esp,8
21) 55 00ce1089 mov     ecx,esi
22) 55 00ce108b call    edx   >>>call pb1->Func1()
23) 56 00ce108d mov     eax,dword ptr [esi]
24) 56 00ce108f mov     edx,dword ptr [eax+4]
25) 56 00ce1092 mov     ecx,esi
26) 56 00ce1094 call    edx   >>>call pb1->Func2()
27) 59 00ce1096 add     esi,4
28) 60 00ce1099 push    esi
29) 60 00ce109a push    offset test!`string' (00cea164)
30) 60 00ce109f call    test!printf (00ce10e7)
31) 61 00ce10a4 mov     eax,dword ptr [esi]
32) 61 00ce10a6 mov     edx,dword ptr [eax]
33) 61 00ce10a8 add     esp,8
34) 61 00ce10ab mov     ecx,esi
35) 61 00ce10ad call    edx  >>>call Func1's adjustor thunk
36) 62 00ce10af mov     eax,dword ptr [esi]
37) 62 00ce10b1 mov     edx,dword ptr [eax+4]
38) 62 00ce10b4 mov     ecx,esi
39) 62 00ce10b6 call    edx   >>>call Func2's adjustor thunk
40) 63 00ce10b8 xor     eax,eax
41) 63 00ce10ba pop     esi
42) 63 00ce10bb ret

If we run the code till line 12 above (object pObj1 is constructed successfully then, and eax register contains the this pointer of pObj1), then display the object of pObj1:

We can see it has two vtable pointers since it inherits two base classes, and both base classes have virtual functions:

0:000> dt test!Derived @eax
   +0x000 __VFN_table : 0x00cea194
   +0x004 __VFN_table : 0x00cea1a0
   +0x008 m1               : 0n1
   +0x00c m2               : 0n2

Let’s check the two vtables:

We can see the first vtable contains function pointers which points to the actual function implementation:
(Derived::`RTTI Complete Object Locator' is for Run Time Type Identification purpose):

0:000> dps 0x00cea194 L3
00cea194  00ce1000 test!Derived::Func1
00cea198  00ce1020 test!Derived::Func2
00cea19c  00cea334 test!Derived::`RTTI Complete Object Locator'

And the other vtable contains function pointers to the adjust thunk function:

0:000> dps 0x00cea1a0 L2
00cea1a0  00ce10c0 test![thunk]:Derived::Func1`adjustor{4}'
00cea1a4  00ce10d0 test![thunk]:Derived::Func2`adjustor{4}'

If we check the adjustor thunk function, we can see it just changes the ecx register, and then jumps to the actual function implementation. We know for the this call calling convention, ecx holds the this pointer, so it just adjusts the this pointer and then does a jump.

0:000> u 00ce10c0
test![thunk]:Derived::Func1`adjustor{4}':
00ce10c0 sub     ecx,4
00ce10c3 jmp     test!Derived::Func1 (00ce1000)

Now let’s see how Derived::Func1 is called via one of its base class pointer pb1, we know esi holds the this pointer of pObj1:
 
18) 55 00ce1082 mov     eax,dword ptr [esi] >>>move vtable pointer (the first vtable pointer in object pObj1) to eax
19) 55 00ce1084 mov     edx,dword ptr [eax] >>>move the first function pointer in the vtable to edx, which is Func1
20) 
21) 55 00ce1089 mov     ecx,esi >>>>move esi to ecx, which adheres to the this call calling convention
22) 55 00ce108b call    edx   >>>call pb1->Func1()

This is a typical virtual function call sequence, since pb1 just points to the start of pObj1 in memory, so there is no need to do any adjust for the this pointer.

However, let’s see how the same function is called via another base class pointer pb2:

27) 59 00ce1096 add     esi,4 >>>>add 4 to esi, so esi (pb2) points to the second vtable pointer in pObj1
28) …
29) …
30) …
31) 61 00ce10a4 mov     eax,dword ptr [esi]  >>>move the second vtable pointer to eax
32) 61 00ce10a6 mov     edx,dword ptr [eax] >>>move the first function in the second vtable to edx
33) ….
34) 61 00ce10ab mov     ecx,esi >>>move esi to ecx
35) 61 00ce10ad call    edx  >>>call Func1's adjustor thunk

We see that when we use pb2 to call Derived::Func1, pb2 actually points to the second vtable pointers (added 4 to esi, which is moved to ecx), since there is only one implementation of Func1, so before we calls into Func1, we need to adjust the ecx pointer (substract 4 from 4), thus we pass the correct this pointer to Func1 so it can address Derived’s member in Func1 correctly, this is exactly what the adjust thunk function is doing (see the assembly we have shown above)

Below chart will make all these more clear:

We know that the pop method pops the top element of the stack, change the stack's internal state but returns nothing; and the top method returns a reference to the top element on the stack, but does not change the stack's internal state. If we want to pop the top element and then remove it from the stack, we need to call both top and pop:

stack<Gadget> gadgets;

gadget = gadgets.top();

gadgets.pop();

One of the reasons is exception safety, suppose we combine functionalities into one function:

template<class T>

class stack

{

public:

T pop();    //let pop to change the stack's internal state and return the top element

};

Then suppose the client write below code:

Gadget gadget;                 //call default constructor of Gadget

gadget = gadgets.pop();  //call operator= of Gadget

or

Gadget gadget = gadgets.pop();  //call copy constructor of Gadget

If operator= or copy constructor throws exception, then we will be in trouble: the stack's internal state has been changed, but we have not get the popped element.

Actually, any mutator function (function that changes an object's internal state) should not directly return an object to avoid the issue discussed here.

 1. When the object is out of scope normally.

 2. During the stack unwind when handling an exception.

For situation 2, if the destructor throws another exceptions when it is handling the first exception, C++ will call terminate to kill your process.

Consider below code:

#include "stdafx.h"

 class MyClass

{

public:

               ~MyClass();

};

 MyClass::~MyClass()

{

               throw 2;

}

 int _tmain(int argc, _TCHAR* argv[])

{

               try

               {

                              MyClass obj1;

                               //intentionally throws a exception here

                              throw 1;

               }

               catch(...)

               {

                              printf("never reachs here\r\n");

               } 

}

When you run the debug build under VS 2010, you get below Debug Error window and you can see Terminate gets called:

debug build call stack in VS 2010 (Parameters removed for clarify):

  msvcr100d.dll!_NMSG_WRITE
  msvcr100d.dll!abort
  msvcr100d.dll!terminate              >>>>terminate gets called
  msvcr100d.dll!__FrameUnwindFilter
  msvcr100d.dll!__FrameUnwindToState
  msvcr100d.dll!@_EH4_CallFilterFunc@8
  ntdll.dll!ExecuteHandler2@20
  ntdll.dll!ExecuteHandler@20
  ntdll.dll!_KiUserExceptionDispatcher@8
  KernelBase.dll!RaiseException
  msvcr100d.dll!_CxxThrowException           >>>> MyClass::~MyClass throws another exception
  test.exe!MyClass::~MyClass
  msvcr100d.dll!_CallSettingFrame
  msvcr100d.dll!__FrameUnwindToState
  msvcr100d.dll!CatchIt
  msvcr100d.dll!FindHandler
  msvcr100d.dll!__InternalCxxFrameHandler
  msvcr100d.dll!__CxxFrameHandler3
  ntdll.dll!ExecuteHandler2@20
  ntdll.dll!ExecuteHandler@20
  ntdll.dll!_KiUserExceptionDispatcher@8
  KernelBase.dll!RaiseException
  msvcr100d.dll!_CxxThrowException                >>>>first exception
  test.exe!wmain
  test.exe!__tmainCRTStartup
  test.exe!wmainCRTStartup
  kernel32.dll!BaseThreadInitThunk
  ntdll.dll!__RtlUserThreadStart
  ntdll.dll!_RtlUserThreadStart

When you run the release build on Windows 7, Windows Error Reporting gets involved:

0:000> kL 50
ChildEBP RetAddr 
0016ede4 003024b7 kernel32!UnhandledExceptionFilter
0016f120 0030747f test!_call_reportfault+0x107
0016f130 003052b2 test!abort+0x28
0016f160 0016f6a0 test!terminate+0x33
WARNING: Frame IP not in any known module. Following frames may be wrong.
0016f164 003081ee 0x16f6a0
0016f16c 00304fe4 test!__FrameUnwindToState+0x86
0016f180 003026be test!_EH4_CallFilterFunc+0x12
0016f1ac 77d565f9 test!_except_handler4+0x8e
0016f1d0 77d565cb ntdll!ExecuteHandler2+0x26
0016f280 77d56457 ntdll!ExecuteHandler+0x24
0016f280 00000000 ntdll!KiUserExceptionDispatcher+0xf

We see this pattern in .NET programming also:

1. The dispose pattern

Any type that wraps native resource needs to have a finalizer method to release the native resource. It is also recommended for this kind of types to implement the dispose pattern so the users can explicitly call the dispose method to release the native resource deterministically. This dispose pattern follows the template method pattern actually:

Sample code:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace DesignPattern

{

    internal class MyNativeResourceWrapper: IDisposable

    {

        //template method, which calls the actual implementation method to

        //do the cleanup, the actual implementation method can be overrided

        //by derived classes.

        public void Dispose()

        {

            Dispose(true);

        }

        //actual implementation method to do the native resource cleanup

        //it is virtual and protected so the derived classes can override

        //if the class is sealed, this class should be private

        protected virtual void Dispose(bool disposing)

        {

            if(disposing)

            {

                //method is called by Dispose(), do the proper cleanup here

                //also call GC.SuppressFinaliz so GC will not call us again

                GC.SuppressFinalize(this);

            }

            else

            {

                //method is called by GC, you should not reference

                //other managed members here

                //since they may be garbage collected already               

            }

        }

        ~MyNativeResourceWrapper()

        {

            Dispose(false);

        }

    }

    class MyDerivedNRW : MyNativeResourceWrapper

    {

        protected override void Dispose(bool disposing)

        {

            //Console.WriteLine("Derived Dispose");

            base.Dispose(disposing);

        }

    }

    class Program

    {

        static void Main(string[] args)

        {

            MyNativeResourceWrapper obj1 = new MyNativeResourceWrapper();

            obj1.Dispose();

            MyNativeResourceWrapper obj2 = new MyDerivedNRW();

            obj2.Dispose();

        }

    }

}

2. The event pattern in .net can be treated as the template method pattern also.

We know event is built on top of delegate, and delegate actually maintains a list of type safe function pointers. When we define an event, what the compiler actually does is to define a private delegate type, an add_XXX method to add object to the delegate and a remove_XXX method to remove object from the delegate. You can use tools such as reflector to check the code generated by the compiler.

Sample code:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace DesignPattern

{

    internal class NewMailEventArgs : EventArgs

    {

        private string m_Subject;

        private readonly string m_From;

        private readonly string m_To;

        public string Subject { get { return m_Subject; } }

        public string From { get { return m_From; } }

        public string To { get { return m_To; } }

        public NewMailEventArgs(string subject, string from, string to)

        {

            m_Subject = subject;

            m_From = from;

            m_To = to;           

        }

    }

    internal class MailMgr

    {

        //1. define an event

        public event EventHandler<NewMailEventArgs> NewMail;

        //2. actual implementation method that raises the event

        // which calls into the actual method that client implements

        protected virtual void OnNewMail(NewMailEventArgs e)

        {

            EventHandler<NewMailEventArgs> temp = NewMail;

            if (temp != null)

            {

                temp(this, e);

            }

        }

        //3. template method to actually call implementation method

        public void SimilateNewMailArrives(string subject)

        {

            NewMailEventArgs e = new NewMailEventArgs("hello","george","nick");

            OnNewMail(e);

        }

    }

    internal class MailClient

    {

        public MailClient(MailMgr mailmgr)

        {

            mailmgr.NewMail += HandleNewMail;

        }

        private void HandleNewMail(object sender, NewMailEventArgs e)

        {

            Console.WriteLine("get new mail with subject: {0}", e.Subject);

        }

        public void UnRegister(MailMgr mailmgr)

        {

            mailmgr.NewMail -= HandleNewMail;

        }

    }

    class Program

    {

        static void Main(string[] args)

        {

            MailMgr mgr = new MailMgr();

            MailClient client = new MailClient(mgr);

            mgr.SimilateNewMailArrives("hello");

            client.UnRegister(mgr);

        }

    }

}