What's wrong with Monitor::Enter()

Suppose we have the following variable we'd like to set as a state and we'd like to make it thread safe (at most one thread is allowed to access the variable):

bool workQueued;

Now if we write something like this, it's not gonna work:

Monitor::Enter(__box(workQueued));
try
{
workQueued = true;
}
__finally
{
Monitor::Exit(__box(workQueued));
}

Why it will not work? The problem is, after workQueued is boxed, the value is not store anywhere. So the second thread reaches here will execute Enter statement with another object value.

To make it work as desired, we need to create a object whose only purpose is to act like a lock:

Object* lock;

Then, we feed this object to Enter and Exit method:

Monitor::Enter(lock);
try
{
workQueued = true;
}
__finally
{
Monitor::Exit(lock);
}

LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification

What the heck?! If you've spent more than ten minutes just trying to find where to set EDITANDCONTINUE property in VC++ project property page, you are not alone. It can be set through: (Under Project Property Pages) Configuration Properties -> C/C++ -> General -> Debug Information Format.

OK. Now I've set it NOT to be /ZI and disabled incremental link, why the darn VS still complain the same warning. Remember that no matter how bizarre a problem seems to be, computer always works as expected. Why don't you check the project properties of other projects that this project depends on?

Visual Studio got stuck when opening sln file

Sometimes VS may get stuck when we double-click a .sln file. We can see the file name on which it got stuck. But even if we try to rename that file or replace with another one with the same name, it may still not work. In this case, try to delete the corresponding .suo file.

Problem caused by dll loading mistake

It is very common that we have two versions of dll: somedll.dll(for Release build) and somedll_d.dll(for Debug build). Because of the dll dependancy complications, if these two versions were load at the same time, it may not cause build errors. However, something wrong can happen during the run time.

For example, if there is a global variable in the source file whose output is somedll.dll/somedll_d.dll, that global variable may be initialized twice (once during the load time of somedll.dll and once during the load time of somedll_d.dll). The client code then will get confused on which of the two references to use. But the fact is, it should be only one instance of that global variable existing.

Time-saving Tips

1. Sometimes we may have weird link errors. Some of the errors will be gone if we try to delete the debug/release folder (clean) and rebuild the project.

2. If an environment involves several executables and dlls working together, their build version should match exactly. Otherwise, some bizarre behaviors may happen.

Mixed DLL Loading Problem

When using managed code inside unmanaged dll entry point, it may cause dll loading problem. For more information, follow the link below.

http://msdn2.microsoft.com/en-us/library/aa290048(vs.71).aspx

Be Careful of Naming

Sometimes bad naming may cause compile errors.

I named a managed enum "Event" (__value enum Event) inside a managed class "SopExt" (__gc class SopExt). In this class, I had a private field whose type is the managed enum "Event" and a pair of getter/setter of it. Later, I found that the compiler sometimes had trouble to recognize the expression like this: "sopExt->Event". The compiler sometimes also didn't recognize the type "SopExt::Event".

Obviously, neither expression is wrong. But apperently, the name of the managed enum "Event" is not a good name. Just by changing "Event" to "StreamEvent" (without even changing the name of getter/setter), the compiler error is gone. The reason that caused the compiler error is not clear. It might be that the name "Event" is too general so it confused the compiler? Anyway, good naming is a very important element in programming.