Disable anonymous namespace definition for Windows compilers

[mannatera]

Fixes #134

[coveralls]

Coverage remained the same at 100.0% when pulling 9ed7815 on mannatera:master into 7da401a on ranisalt:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 9ed7815 on mannatera:master into 7da401a on ranisalt:master.

[jdforsythe]

Thanks @mannatera this is blocking Windows development right now. I can confirm that installing your branch through npm successfully resolves this issue on Windows 10.

[ranisalt]

Thanks!

Also, do you happen to know how to file this bug report to Microsoft developers?

[jdforsythe]

I'm not a C++ dev but the Visual C++ docs lead me to believe anonymous namespaces should work:

https://msdn.microsoft.com/en-us/library/5cb46ksf.aspx#anonymous%20or%20unnamed%20namespaces

Here's an article about reporting an issue:

https://docs.microsoft.com/en-us/cpp/how-to-report-a-problem-with-the-visual-cpp-toolset

[mannatera]

It might as well be a bug with Nan. When I tested it and added new NAN_METHOD which called a class that was outside the anonymous namespace leaving all other code as is (that means that HashWorker and all related classes were still under anonymous namespace) then I got it all working too, with no problems.

I cannot explain this, but it seemed that initiating class outside the namespace "fixed" the class inside the anonymous namespace also.

My best explanation is that Execute() method of Nan::AsyncWorker was called, but when it finished HandleOKCallback() was not called afterwards - leading to this bug in Windows.