After reading this thread back in October, I had submitted a bug report to Microsoft about vector resize not taking a const reference. Some research had shown that it had been previously requested to be changed to a const reference, but it had been rejected to be fixed.
As you can see by the first link, this wll be fixed in VC11.
Thanks for reporting this bug. We've fixed it, and the fix will be available in VC11.
Amusingly, when this was originally reported in July 2006 (months before I joined the VC team), this was indeed By Design. C++03 18.104.22.168 [lib.vector.capacity]/6 specified:
I'm not sure if this works with Express, but it does in Pro. Look under the Project menu or Right click on the project name under the Solution Explorer. Choose Rescan Solution. This will cause Intellisence to go over everything. This usually is enough to kick start it if it stops working.
Since they added this to VC 2010, this has managed to fix any problems I've been having. I haven't needed to go back and delete the ncb's like in 2005 or 2008.
First, replace those lock and unlock calls with one of the RAII locking structures provided by boost::threads (see example below, I made a typedef for declaring the mutex and a lock that uses a typedef exposed by boost::mutex)
Next, take a look at std::queue. This will be a much better structure for storing the jobs, instead of the static sized array you've got.
Next, instead of storing as a function pointer, use boost or tr1 function to store the functions to process. They have a little more "weight" to them behind the scenes, but should be a little safer to use.
Using the queue, it will be much easier to test if there is a job availble to run, else you can call sleep() or yield() to let the thread not completely eat the cpu when it has nothing to do.
typedef boost::mutex mutex_t;
typedef mutex_t::scoped_lock lock_t;
std::queue<std::tr1::function<void ()> > Jobs;
active = true;
Thread = boost::thread(&Worker::Work, this);
active = false;
// Ensure there are no remaining jobs in the queue (this is probably overkill)
while(Jobs.empty() == false)
__declspec(dllexport) void Indigo::Worker::Work()
// Checking active will probably need to be atomic
if(Jobs.empty() == false)
// Execute the first job in the queue
// Remove the job from the queue
__declspec(dllexport) void Indigo::Worker::Add(boost::function<void ()> Func)
 Fixed formatting in code and added yield condition.
Mutex_A.lock(); //don't continue until A is finished
Mutex_B.lock(); //don't continue until B is finished
Mutex_C.lock(); //don't continue until C is finished
//TODO: Finish with Update A, B & C resources
Mutex_A.unlock(); //free A for next loop
Mutex_B.unlock(); //free B for next loop
Mutex_C.unlock(); //free C for next loop
My first advice would be to not use .lock / .unlock and use one of the RAII based lock-guards that boost provides
As far as frequent creation and destruction, that can get expensive. If you can, you might look at creating a couple of worker threads that you keep running all of the time. These threads should each have a queue of functions to execute (like a functor). If there is nothing in queue, just have the thread sleep then do another check.
 See this thread for a more detailed example of what I was describing.
do you think they could be causing the problem of the program doing nothing? if so what would I be looking for that indicates CLI? I'm unfamiliar with the language, but taking a quick google it seems similar to C# (with that being the coding language I'm most familiar with its plausible I used similar code in C++ by mistake)
It's basically a modified version of C++ that uses the .Net Common Language Runtime. Check your project files (Right click on the Project and choose Properties). Check under General -> Common Language Runtime Support and see if it says Common Language Runtime Support /clr (see picture below)
If it is there, try changing it to No Common Language Runtime Support.
I'm not using C++/CLI... at least not to my knowledge Intellisence still works and it was to my understanding it didn't work with projects that included / used C++/CLI (I've come across VS 2010 commenting on it in the bottom right corner when looking at certain code examples)
I just tried creating a test C++/CLI project in VC2010 and included <boost/thread.hpp> and got the exact same error you did.
1>------ Build started: Project: CLRTest, Configuration: Debug Win32 ------ 1>Build started 7/19/2011 8:51:27 AM. 1>InitializeBuildStatus: 1> Creating "E:\Programming\CLRTest\_Obj\Win32\Debug\CLRTest\CLRTest.unsuccessfulbuild" because "AlwaysCreate" was specified. 1>ClCompile: 1> stdafx.cpp 1> AssemblyInfo.cpp 1> CLRTest.cpp 1> Generating Code... 1>e:\programming\boost\boost\thread\win32\basic_timed_mutex.hpp(160): warning C4793: 'boost::detail::basic_timed_mutex::unlock' : function compiled as native : 1> Found an intrinsic not supported in managed code 1>e:\programming\boost\boost\thread\win32\thread_primitives.hpp(314): warning C4793: 'boost::detail::win32::interlocked_bit_test_and_set' : function compiled as native : 1> Found an intrinsic not supported in managed code 1> .NETFramework,Version=v4.0.AssemblyAttributes.cpp 1>C:\Users\Rob Yull\AppData\Local\Temp\.NETFramework,Version=v4.0.AssemblyAttributes.cpp : fatal error C1083: Cannot open compiler generated file: 'E:\Programming\CLRTest\_Obj\Win32\Debug\CLRTest\C:\Users\Rob Yull\AppData\Local\Temp\.NETFramework,Version=v4.0.AssemblyAttributes.obj': Invalid argument 1> 1>Build FAILED. 1> 1>Time Elapsed 00:00:04.30 ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
It looks like your IndigoFramework project is C++/CLI.
You are correct about Intellisense and C++/CLI, but I'm guessing only one of the projects may be incorrectly setup this way.
Change those std::endl to '\n' and you see a big difference. You are flushing the buffer after every call using std::endl; Also, to make the code a little closer to the C version, reserve some memory for the string.
Exceptions all boil down to two extremes: "handle the problem immediately and locally, and gosh darnit now I have to remember to wrap every call to this function" or the other extreme, "stop everything, and move on." In the latter case it's perfectly fine to use a return code. Return codes, in the places where you want them, are not actually strenuous.
I find this statement funny. So basically instead of having to wrap a function call in a try/catch block, you want to wrap it in a if/else or switch block? Possible performance issues aside (to be determined by profiling), you are basically just trading one test for another (hopefully, since I frequently see examples where no test is performed).
Exceptions are less scary in memory-safe languages and so their use is less discouraged.
If you are using RAII (as you should be in C++), it can be a very memory and resource safe language. And this applies to whether your are using exceptions or return codes.