Portable Social Networks, The Building Blocks Of A Social Web - by Ben Ward

A great article about the future of social networking where different sites would be able to interact with the help of protocols and standards which exist even today and do it on mobile platforms.

Read full article at Digital Web Magazine

IE Antivirus : A pain in the %^$#

IE antivirus is one of the most annoying malware I've ever come across in my life. It pops up warnings and opens pages in my browser when ever I double click on a folder. I guess it's a kind of explorer hijacker but it's anybody's guess. After two antivirus programmes and countless scans which failed to do anything about this little devil I was getting really mad... Today I was finally able to get rid of it using a program called Malwarebytes' Anti-Malware. One scan and a re-start was enough to do the trick... Removal procedure

Deriving from a C++/C# disposable class (via void Nish(char* szBlog))

There's a nice article by Nish on the mysterious world of using managed and unmanaged objects bound by derivation. He's given a clear and concise explanation on how to derive a C++/CLI class from a C# class which implements IDisposable and avoid the imminent garbage collection pitfalls.
Read more here...

Bit by void* (from jaredpar's WebLog)

Recently I got bit by void* again because of another C++ quirk I didn't think through. I had a class which wrapped a void* which could be one of many different structs. The structs were POD and didn't have any shared functionality hence I didn't bother creating an inheritance hierarchy. Unfortunately I defined the structs like so

class C1 {
struct S1 {
int field1;
float field2;
};
struct S2 {
char field1;
};
~C1() {
delete m_pData;
}
void* m_pData; // Can be S1,S2,etc ...
}

Unfortunately this appeared to work fine for quite some time. Then after a couple of days of bug fixes I ended up with a memory leak which I quickly tracked down to a leaked COM object. Although C1 was at fault I didn't suspect any changes to this class because after all it was working fine for some time and all I did was add a new field to one of the structs. If the structs were being successfully free'd before a new field shouldn't change anything.

The field I added was of type CComPtr which exposed a greater problem in my code. Even though I properly delete the pointer in C1::~C1() I wasn't running the destructor on the pointed at data and instead I was just freeing the memory. Until I added a field which had a non-trivial destructor this wasn't a problem (still a bug though).

Why did this happen? By deleting a void* and expecting a destructor to run what I'm really doing is asking C++ to behave polymorphicly. C++ as a rule won't behave this way unless it is specifically asked to with inheritance and virtual. In the case of void*, it just won't. The fix is to actually implement an inheritance hierarchy which supports polymorphism.

It's just another rule that I need to remember when coding C++.

Deleting void* is dangerous, period.

Unfortunately C++ has too many of these rules and not enough enforcement.

Via jaredpar's WebLog

atoi vs. Custom String to Int Convertion

I had two code reviews of my process and it turned up a plethora of bugs and unoptimized code. One of these was a function which is called very frequently, which contained three atoi calls. atoi is expensive, I know, but I didn't have an idea as to HOW expensive it was. Further, I thought there was no other way to achieve its results, until our team lead Mr. Prabath Fernando pointed out that it was possible to get the corresponding value of a ascii int character by subtracting 48 from it. This could be better understood by looking at an ascii table.

Anyway, I wrote a macro to do the same thing as atoi and did a performance test.

Code:

#include
#include
#include

#define QSaToi(iLen, zString, iOut) {int j = 1; iOut = 0; \
for (int i = iLen - 1; i >= 0; --i) \
{ iOut += ((zString[i] - 48) * j); \
j = j*10;}}

int main(int argc, char** argv)
{
clock_t ct_start = clock();
const char* zTest = "1234567";
int iOut = 0;

for (int i = 0; i < result = " << iOut << std::endl; std::cout << " time = " << ((double)clock() - ct_start)/(CLOCKS_PER_SEC) << " ct_start =" clock();" i =" 0;" iout =" atoi(zTest);" result = " << iOut << std::endl; std::cout << " time = " << ((double)clock() - ct_start)/(CLOCKS_PER_SEC) << ">> iOut;
}

Results:

Result from custom method = 1234567
Time for custom method = 0.063 us
Result from atoi = 1234567
Time for atoi = 0.422 us

Conclusion : Custom atoi macro is ~7 times faster than normal atoi.

NOTE: this was tested only with microsoft visual c++ 2008 compiler so results might differ on unix machines