Google Protocol Buffers Released

Google has released it's protobuf API for data serialization/retrieval under open source license. So far it appears to be pretty good and would help to avoid alot of headaches over data persistence and managing countless numbers of object types. Performance values are yet to be determined...

protobuf home

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