I have a project with so many static variables accessed from one class to another class. I access these static variables by threads.
For example, I access one variable in one thread to change the value and another thread to access it. Both threads are running concurrently. But sometime abruptly the static variable value got changed and it holds a very big value which results in some problem.
I know that I use more static variables and I do mistake in programming but can anyone tell me avoid this kind of problem and why the variable is suddenly holding huge values.
It sounds like you read the variable halfway through being changed. So, the variable is not a trivial type (ie, BOOL).
Look at CCriticalSection, it's probably what you need. There's a million and one way to do this though. You could wrap the variable in a class including the CCriticalSection, and write get / set routines that use the critsect.
It really depends on the fine details.
If you have loads of static variables, it makes me suspect your initial design though. May be worth a second look. Does PlaceA need to know details of PlaceB?
In the process of moving to Sweden for love (awwww).
If you're in Scandinavia and want an MVP on the payroll (or happy with a remote worker), give me a job! http://cv.imcsoft.co.uk/[^]
If the variables are not volatile, you're already in trouble. The ideal way would be to synchronize access to the variable using thread synchronization techniques (a critical section would do, as all your threads belong to the same process).
I see you have a lot of things to read up.
It is a crappy thing, but it's life -^Carlo Pallini
I am trying some Interop in my application. This is the first time I have had to pass arguments with function calls. I am experiencing some odd results.
// C# Function Call
RenderEngine.LoadNewMesh("BasicMesh", "Pyramid3", 1);
// Managed C++ Wrapper Functionvoid RenderEngine::LoadNewMesh(String^ meshType, String^ meshName, int nSubsets)
char* cMeshType = (char*)(void*)Marshal::StringToHGlobalAnsi(meshType);
char* cMeshName = (char*)(void*)Marshal::StringToHGlobalAnsi(meshName);
m_engineRoot->LoadMesh.LoadNewMesh(cMeshType, cMeshName, nSubsets);
// Native C++ Functionvoid MeshLoader::LoadNewMesh(char* meshType, char* meshName, UINT nSubsets)
m_meshType = meshType;
m_meshName = meshName;
m_nSubsets = 0;
m_nTotalSubsets = nSubsets;
m_pMesh = new BasicMesh();
// This message box will display Pyramid3
MessageBox(0, meshName, 0, 0);
// This code will not trigger the message boxif (meshName == "Pyramid3")
MessageBox(0, (char*)"meshName is Pyramid3", 0, 0);
// This code will trigger and m_meshName is set directly as Pyramid3// if it is not set directly here the call to GetMeshByName later on returns NULLif (strcmp(meshName,"Pyramid3") == 0)
m_meshName = "Pyramid3";
// Object is referenced by name here
// Will return NULL if char* is not set directly
right, because you've assigned meshName to m_meshName, and i assume m_meshName is a string object of some kind, one with an overloaded "==" operator which knows how to compare a C-style (char*) string to its contents. (CString or std::string?)
the problem with the first remains: you cannot compare a pointer to a static string. that's not how C-style strings work. and that's why strcmp exists.
1/ m_meshName is a pointer to character. Underneath, it's an integer holding an address in RAM.
2/ The compiler has seen two constant strings in your code, but only bothers to store one copy of the string "Pyramid3" in it's data segment.
So, the strcmp works as intended, and makes m_meshName point to the constant string in your code.
The 3rd comparison works by luck, as m_meshName is still pointing to that string. This is because your compiler is being efficient, it is not because your code is correct.
I am having a common code snippet to be compiled in VC6 and in Embedded vc++(CE). Right now i am working with vc6 part.
void* CNewClass::GetProcAddress1(HMODULE hModule, LPCTSTR lpFuncName)
USES_CONVERSION;//for ATL, to use A2W declare this first #ifdef _WINCE //for wince
LPCWSTR lpUnicodeFuncName = A2W( lpFuncName );
#else // for vc6
LPCSTR lpAsciiFuncName = (LPCSTR)W2A( lpFuncName );
return (GetProcAddress(hModule, lpAsciiFuncName));
Problem: This function (GetProcAddress) returns 0/fails in release mode. It works fine in debug mode.
General Info: The function GetProcAddress resolves to GetProcAddressA or GetProcAddressW based on the build(ascii or unicode) in EVC++ whereas in vc6, it is GetProcAddress only (simlar to GetProcAddressA with LPCSTR as second parameter).