La Mulţi Ani, România!
Happy Birthday, Romania!
Joyeux Anniversaire, Roumanie!
Alles Gute zum Geburtstag, Rumänien!

Because my country has some image issues I dedicated a special page about the real Romania here!

In case you don’t know:

Chatting with a virus
Few weeks ago I was chatting with a virus. A friend of mine just got a Yahoo Messenger virus and unsealed it to me.

After that I emailed to my friend and his computer is safe now.

Mission Impossible in Eclipse

This year I was involved in a Java project using Eclipse IDE. Once day I tried to export few files in a .jar and I got impossible situation to close the export dialog: all the buttons where disabled and when I tried to close the window using Alt+F4 or X button I got next message error.

The only solution to escape this message box was to kill the Eclipse process. Fortunately, the issue didn’t reproduce second time.

Idle 41 years

This summer, my Pidgin chat application shown over 41 years of Idle status for one of my high school colleagues. He is 30 years old. The issue was fixed when he turned back to his computer.

An original way to say “Happy Birthday, Austria”

26 October is the National Day of Austria. On this occasion, Google Translate wished Happy Birthday Austria in an original way.

The translation from Deutsche to Romanian of “Happy Birthday Austria! See you soon!” is “Happy Birthday USA! See you soon!“. Today, 14.11.2011, the issue still exists. So Enjoy!

Pidgin relapses
Today, 15.12.2011, according to Pidgin 2.7.11 one of my office colleagues was out of office over 41 years.

Out of Memory – Yahoo mail
Few days ago I was visiting few private insurances companies. One of the most friendly company’s employee staid close to me with her laptop. In the moment she tried to send me a PDF file by email using a Yahoo email I was delighted with an amazing message error:

The using browser was IE 8 in Windows 7. It’s amazing how she got out of memory at line 1. I don’t thing Yahoo writes all the code in one line (even if the don’t use CR + LN).

From the moment I have launched the first release until now I made up to 12GB pictures (3200+ pictures of 10 MB) and honestly I never found time in order to organize the pictures. Always I said that I will complete my application and finally I found time to implement export by date time folders and so on.

Simple Pictures Unifier 1.1 allows merging and exporting pictures in one folder or in date time folders. The application comes with a better user friendly experience and few internal improvements.
The Start Export button launched a new wizard dialog that allows the selection of the preferred export method.

If the user chooses the default export to date time folders the Export wizard window shows a list with detected time folders.

Selecting Finish button the pictures merging is realized and the files are copied to the destination folders. If the user wants to abort the export process it can just press Stop button or close the application with now damages.

Feel free to add comments, suggestions or bugs reports. Any constructive feedback is sincerely appreciated.

Overview
A process starts with a fixed stack space. The top of a stack is pointed to by the ESP register (Extended Stack Pointer) and this is a decrementing pointer. Every function calls results in a stack created for the function inside this Process Stack. Every thread function has its own stack. The stack is a downward growing array. When a function starts, the default stack reservation size is 1 MB.
This is contrasting with the heap’s size whether theoretically increases to a limit of 4 GB on 32bits OS. See more information here.

Every thread under Windows gets its own block of contiguous memory, and while function calls are made, the stack pointer is increasing and decreasing. In contrast, a different thread within the same process might get a different block of contiguous memory – its own stack. When a context switch occurs, the current thread’s ESP (along with the IP and other registers) are saved in the thread’s context structure, and restored when the thread is activated the next time.
To specify a different default stack reservation size for all threads and fibers, use the STACKSIZE statement in the module definition (.def) file. To change the initially committed stack space, use the dwStackSize parameter of the CreateThread, CreateRemoteThread, or CreateFiber function.
Most stack problems occur in overflows of existing stacks, as their sizes are fixed and they cannot be expanded.

_chkstk() increases the stack when needed by committing some of the pages previously reserved for the stack. If there is no more physical memory available for committed pages, _chkstk fails. When you enter a function (VC++ with the stack checking enabled), it will call the _chkstk located in CHKSTK.ASM. This function does a stack page probing and causes the necessary pages of memory to be allocated using the guard page scheme, if possible. In this function, it is stated that when it encounters _XCPT_GUARD_PAGE_VIOLATION, the OS will attempt to allocate another guarded page and if it encounters _XCPT_UNABLE_TO_GROW_STACK then it’s a stack overflow error. When _XCPT_UNABLE_TO_GROW_STACK is encountered, the stack is not yet set up properly, that is why, that it will not call the catch because calling it will use invalid stack variables which will again cause another exception.

Case – Too many or too big variables on stack
As I said on top, the function stack size is 1 MB. If you miss that and you’re trying to define and use internally an array like this:

int arr[4000][200];

When you’ll compile with VC++ compiler in debug mode you will have a big surprise: the application is crashing on _chkstk() in the moment the _chkstk() tries to create new memory page on stack and fails.
The output window shows next message:

First-chance exception at 0x004116e7 in testApp.exe: 0xC00000FD: Stack overflow.
Unhandled exception at 0x004116e7 in testApp.exe: 0xC00000FD: Stack overflow.

This happens because the 1MB limit is overloaded even on a win32 OS: 4000*200*4 = 3.2MB (approx.).
Same story if you define many local variables and their stack usage overloads the 1MB limit.
If you really need this big array then the solution to avoid this crash is using heap.

int **arr = new int*[4000];
for(int i=0; i<4000; ++i) {
	arr[i] = new int[200];
}

// and finaly don't forget to delete
for(int i=0;i<4000; ++i) {
	delete[] arr[i];
}
delete[] arr;

Case – Recursive functions
If you have an infinite recursion then you will gate same stack overflow error and the application crashes in _chkstk.asm. Recursive function is not the subject of this article so I don’t go in deep… Here it is a good example of what happens with recursive functions.
The solution is to avoid using recursive functions as much as possible and try to implement an iterative function.

Case – A stack corruption
I have started looking over _chkstk() function in the moment when I got few bugs with crashes with some similarly details. I had to analyze some .dump files and solve few bugs that contained a call stack with _chkstk() on top.
Most of the .dump files call stack contained a second similarly thing: the call of a thread function (so called ThreadFoo()) that was running in a threads pool.
In that moment I started to research why _chkstk() fails and my first track was to debug the stack overflows. I followed a MSDN debugging tutorial and unfortunately I didn’t find something strange. I checked if the local stack variables are not so big in order to fill the ThreadFoo() function’s stack and it did not.
Then a new study of ThreadFoo() function has followed in order to detect the internal functions calls that can fail in some circumstances. I stopped to some trace function calls and I studied deeply. Those trace functions where defined in an external debug class and each time when a new trace file was added it used an internal buffer (TCHAR szBuff[2048] = _T(“”);).
The writing of this buffer was done using: swprintf(). As we know this function is unsafe and is not recommended to use. As long as the content of these trace lines was dynamically build (in some cases those line may contain even dynamically build SQL queries that failed) then the length of these trace lines could be higher than 2048 bytes and then guess what: a stack corruption appears! UPS! The stack pointer will be corrupted (the classic stack overflow case).

So I have implemented and used the next macros:

#ifdef _UNICODE
#define usprintf(x, ...)	_snwprintf(x, _countof(x) - 1, ##__VA_ARGS__); x[_countof(x)-1] = 0
#else
#define usprintf(x, ...)	_snprintf(x, _countof(x) - 1, ##__VA_ARGS__); x[_countof(x)-1] = 0
#endif

Now, if we’re using the safe macro we will have no issues.

int x = 23;
TCHAR szMsg[2048] = {0};
usprintf(szMsg, L"Error: %d", x);

A safety alternative way to that buffer was the heap using but the heap access is not fast as the stack access so I preferred this approach (in a business application every milliseconds matters for the log system).
After that fixed I met no other stack corruptions in ThreadFoo() and other code areas.

Even if the top of the call stack was _chkstk() this was not the function that failed. The error appeared because of that stack corruption and _chkstk() has just detected.

Conclusion
If your code produces a stack overflow, then you have to rethink your design in right away:

References
Set stack size
Thread Stack Size
_chkstk Routine
Stack (data structure)
Debugging a Stack Overflow – tutorial
Visual C++ apps crashing in _chkstk() under load
Optimization Note (C++) 1: push, pop, call _chkstk
What is Recursion?

A recent Visual C++ team’s comment on twitter.com reminded me a hot topic that exists in C++ programming world: there is a long discussion of using pre versus post increment operators, specially, for iterators. Even me I was witness to a discussion like this. The discussion started from a FAQ written by me on www.codexpert.ro.

The reason of preferring pre increment operators is simple. For each post-increment operator a temporary object is needed.
Visual C++ STL implementation looks similarly with next code:

_Myt_iter operator++(int)
{   // postincrement
  _Myt_iter _Tmp = *this;
  ++*this;
  return (_Tmp);
}

But for pre-increment operator implementation this temporary object is not needed anymore.

_Myt_iter& operator++()
{   // preincrement
  ++(*(_Mybase_iter *)this);
  return (*this);
}

In the discussion that I mentioned above, somebody came with a dummy application and tried to prove that things have changed because of new compilers optimizations (the code exists in the attached file, too). This sample is too simple and far away to the real code. Normally the real code has more code line codes that eat CPU time even if you’re compiling with /O2 settings (is obviously).
Base on that VC++ team’s tweet related to viva64.com’s research I decided to create my own benchmark base on single and multicore architectures. For those that don’t know Viva64 is a company specialized on Static Code Analysis.
Starting from their project I extended the tested for other STL containers: std::vector, std::list, std::map, and std::unordered_map (VC++ 2010 hash table implementation).
For parallel core tests I used Microsoft’s new technology called Parallel Pattern Library.

1. How the tests were made
1.1. Code stuff
In order to get execution time I used same timer as Viva64 team (with few changes). Each container instance was populated with 100000 elements of same random data. An effective computing function was repeated 10 times. Into this function some template functions are called for 300 times. The single core computing function contains loops like this:

for (size_t i = 0; i != Count; ++i)
{
   x += FooPre(arr);
}

// where FooPre looks like
template <class T>
size_t FooPre(const T &arr)
{
  size_t sum = 0;

  for (auto it = arr.begin(); it != arr.end(); ++it)
    sum += *it;

  return sum;
}

For the parallel core computing the first simple for loop has changed in:

parallel_for (size_t(0), Count,
[&cnt,&arr] (size_t i) {
	cnt.local() += FooPre(arr);
});

Where cnt is an instance of combinable class and the sum of partial computed elements is obtained by calling combine() method:

cnt.combine(plus<size_t>());

As you can see, the parallel_for function uses one of the new C++ standard features: a lambda function. This lambda function and the combinable class implements the so called parallel aggregation pattern and helps you to avoid the multithreaded common share resource issues. The code is executed on independent tasks. The reason that this approach is fast is that there is very little need for synchronization operations. Calculating the per-task local results uses no shared variables, and therefore requires no locks. The combine operation is a separate sequential step and also does not require locks.

1.2. Effective results
The tests were running on a Intel core i3 machine (4 cores) running Windows 7 on 32bits OS. I tested debug and release mode for single and multi cores computation. The test application was build in VC++ 2010 one of the first C++11 compliant.
The OX axis represents the execution repeated times, and the OY axis means time in seconds.

1.2.1. Single core computation
Debug

Release

1.2.2. Multi cores computation
As you know, multi core programming is the future. For C++ programmers Microsoft propose a very interesting library called Parallel Pattern Library.
The overall goal is to decompose the problem into independent tasks that do not share data, while providing a sufficient number of tasks to occupy the number of cores available.

This is how it looks my task manager when the demo application runs in parallel mode.

Isn’t it nice comparing to a single core use?

Debug

Release

1.2.3. Speedup
Speedup is an efficiency performance metric for a parallel algorithm comparing to a serial algorithm.

Debug

Release

Conclusions:
The biggest differences appear in the debugging area where the pre-increment is “the champion”.
According to these results I have to agree with Viva64 team. Even if the results are so close in release version I keep my opinion that using pre increment operator is preferred instead of post increment operators. We all know how long it takes the debug period and how important is every second that we win in long debugging days.

If you still have doubts in using pre-increment operator or you need a flexible way of switching this operators in your code you can easily implement some macros like these:

#define VECTOR_ITERATOR(type, var_iter)  std::vector<type>::iterator var_iter;
#define VECTOR_FOR(vect, var_iter)	for (var_iter = vect.begin(); var_iter != vect.end(); ++var_iter)

  int x1 = 230;
  std::string s1;
  itoa(x1, s1, 10);

// error C2664: ‘itoa’ : cannot convert parameter 2 from ‘std::string’ to ‘char *’

A C style approach in order to avoid this error means using an intermediary buffer:

    int x1 = 230;
    std::string s1;
    char szBuff[64]={0};
    itoa(x1, szBuff, 10);
    s1 = szBuff;

Same story if we try to convert a std::string to an int:

  std::string s3 = "442";
  int x3 = atoi(s3);

// error C2664: ‘atoi’ : cannot convert parameter 1 from ‘std::string’ to ‘const char *’

In this case we can use c_str() in order to return a constant pointer to char.

int x3 = atoi(s3.c_str());

An elegant way to get rid of such problems is to build two conversion function that use templates and C++ streams.
Base on this idea, I created a Sting2Numeric class that contains two static methods: Type2String() and String2Type().

class String2Numeric
{
   public:

	template <class TypeT>
	static xstring Type2String(TypeT x)
	{
		xostringstream o;
		if (!(o << x))
			throw BadConversion("Type2String(TypeT)");

		return o.str();
	} 

	template <class TypeT>
	static TypeT   String2Type(const xstring& s)
	{
		xistringstream i(s);
		TypeT x;
		if (!(i >> x))
			throw BadConversion("String2Type(TypeT)");

		return x;
	}
};

where BadConvertion is a std::runtime_error‘s derived class.

class BadConversion : public std::runtime_error {
public:
	BadConversion(const std::string& s)
		: std::runtime_error(s)
	{ }
};

Because of ANSI and UNICODE project’s compatibility I defined few macros:

#ifdef _UNICODE
	#define	xstring			std::wstring
	#define	xostringstream	std::wostringstream
	#define	xistringstream	std::wistringstream
#else
	#define	xstring			std::string
	#define	xostringstream	std::ostringstream
	#define	xistringstream	std::istringstream
#end

Because of this compatibility I strongly recommend using a xstring alias instead of std::wstring or std::string.
When you want to convert an int, float, double, or other numerical type to a xstring in a C++ style you can use the Type2String() function. Vice versa, if you want to convert a xstring to these types you can use String2Type().

In order to avoid possible thrown exception I recommend to you using a try catch block whenever you’re using these functions. I prefer using xstring for string/wstring variables definition, too.
Here is a sample of using this class:

double y1 = 0.2312, y2 = 1.0123;
xstring s1 , s2;

try
{
	s1 = String2Numeric::Type2String<double>(y1);
	s2 = String2Numeric::Type2String<int>(x2);

	#ifdef _UNICODE
		xstring s3(L"43.52");
	#else
		xstring s3("43.52");
	#endif

	x2 = String2Numeric::String2Type<int>(s3);
	y2 = String2Numeric::String2Type<double>(s3);
}
catch (BadConversion &eBC)
{
  std::cout << "An exception has been thrown: " << eBC.what() << std::endl;
}

The String2Numeric class can be extended. For instance, if the conversion throw an error then you can add detailed information in the exception message.

Download String2Numeric (79) class.

For our flexible binaries properties changes and in order to avoid manual edit for each rebuild we can create and include a header file (version.h) that contains some constants of product version and file version of our project (.rc files).

We have to include only these constants into this file (version.h):

    #define PRODUCT_VERSION      4.3.2.198
    #define PRODUCT_VERSION_STR  "4.3.2.198"

Then, for each .rc file wherever we have FileVersion and ProductVersion we have to use this constants.
When we will build a new kit, we have to change only these constants and then to start the kit building process. Everything is fine until we add new controls in our projects resource files. Then, because of Visual Studio IDE automation we can get an unlikely surprise: the FileVersion and the ProductVersion properties could be reset to 1.0.0.0.

In order to avoid this issue and edit the version only in a single place I propose the following workaround:

// Neutral resources
#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_NEU)
#ifdef _WIN32
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
#pragma code_page(1252)
#endif //_WIN32

/////////////////////////////////////////////////////////////////////////////
//
// Version
//

#include "..\version.h"

VS_VERSION_INFO VERSIONINFO
 FILEVERSION PRODUCT_VERSION
 PRODUCTVERSION PRODUCT_VERSION
 FILEFLAGSMASK 0x3fL
#ifdef _DEBUG
 FILEFLAGS 0x1L
#else
 FILEFLAGS 0x0L
#endif
 FILEOS 0x4L
 FILETYPE 0x1L
 FILESUBTYPE 0x0L
BEGIN
    BLOCK "StringFileInfo"
    BEGIN
        BLOCK "040904e4"
        BEGIN
            VALUE "CompanyName", "TODO: <Company name>"
            VALUE "FileDescription", "TODO: <File description>"
            VALUE "FileVersion", PRODUCT_VERSION_STR
            VALUE "InternalName", "testResources.exe"
            VALUE "LegalCopyright", "TODO: (c) <Company name>.  All rights reserved."
            VALUE "OriginalFilename", "your_project.exe"
            VALUE "ProductName", "TODO: <Product name>"
            VALUE "ProductVersion", PRODUCT_VERSION_STR
        END
    END
    BLOCK "VarFileInfo"
    BEGIN
        VALUE "Translation", 0x409, 1252
    END
END
#endif    // Neutral resources
/////////////////////////////////////////////////////////////////////////////

   "\r\n"
   "#include ""res\\your_project.rc2""\r\n"
   "\0"

That code block looks like this:

3 TEXTINCLUDE
BEGIN
    "\r\n"
    "#include ""res\\your_project.rc2""\r\n"
    "\0"
    "#define _AFX_NO_SPLITTER_RESOURCES\r\n"
    "#define _AFX_NO_OLE_RESOURCES\r\n"
    "#define _AFX_NO_TRACKER_RESOURCES\r\n"
    "#define _AFX_NO_PROPERTY_RESOURCES\r\n"
    "\r\n"
    "#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_ENU)\r\n"
    "LANGUAGE 9, 1\r\n"
    "#pragma code_page(1252)\r\n"
    "#include ""res\\your_project.rc2""  // non-Microsoft Visual C++ edited resources\r\n"
    "#include ""afxres.rc""     // Standard components\r\n"
    "#endif\r\n"
    "\0"
END

Don’t forget to edit .rc2 file name with the right file name of your project.

#include "res\your_project.rc2"

The rest of the section’s lines have to be deleted.

Observations
Once you apply these steps, the product version properties will not possible from the Visual Studio IDE resource editor, anymore (only as edit text file or an external text editor). If we didn’t define something special in our project’s String Table we will see only IDS_ABOUTBOX.

Please, feel free to add comments, suggestions or bugs reports to this application.
Any constructive feedback is sincerely appreciated. Thanks you!

A direct and fast way in order to detect the file size without these operations means the CRT run-time library’s function _tstat64() and stuff.

In the header file or on .cpp file please add next macros definitions:

#define __S_ISTYPE(mode, mask)  (((mode) & _S_IFMT) == (mask))
#define S_ISDIR(mode)    __S_ISTYPE((mode), _S_IFDIR)

Then, write next function:

long long GetFileSizeFast(const TCHAR *szFilePath)
{
	if (!szFilePath || !szFilePath[0] || !PathFileExists(szFilePath))
		return -1;

	long long nSize = -1;
	struct __stat64 buf;
	nSize  = (_tstat64( szFilePath, &buf ) == 0) ? buf.st_size : -1;
	if (S_ISDIR(buf.st_mode)) nSize = -1;

	return nSize;
}

If you’re using WinAPI there is an even faster way in order to get file size.

long long GetFileSizeFastest(const TCHAR* szFilePath)
{
	if (!szFilePath || !szFilePath[0] || !PathFileExists(szFilePath))
		return -1;

	WIN32_FIND_DATA sFileData;
	HANDLE hFind = FindFirstFile(szFilePath, &sFileData);
	if (hFind == INVALID_HANDLE_VALUE)
		return -1;

	FindClose(hFind);

	return  (sFileData.nFileSizeHigh * (MAXDWORD+1LL)) + sFileData.nFileSizeLow;
}

Finally, call these functions wherever you need.

Unfortunately, two weeks ago, watching few slides presentations over slideshare.net I was shocked by a Windows message on my laptop (Windows 7 Ultimate x64 OS): “Your computer is low on memory. Save your files and close these programs: Google Chrome.”
What the hack?!

I closed that window and I investigated Task Manager in order to detect witch process was using my memory.
I was socked again when I saw that one Chrome process was using even 701 MB!

Briliant!

The main Google Chrome process had 13 tabs: 8 tabs contained slideshare.net presentations, one with twitter.com and the rest normal web pages.