|
Hmmm....I'm in a pickle, then.
Maybe you've tried this sort of thing, then. Basically I'm writing an object to a file as a header then appending various other files to create a large file. Basically, minus error checking:
fOut.Open(strFileOut,
File::modeCreate|CFile::modeWrite|CFile::shareDenyNone, &Error);
//the header
CArchive ar(&fOut, CArchive::store);
m_objInstrument.Serialize(ar);
//then i append the files
for(int i = 0; i < arFileNames.GetSize(); i++)
{
strFileName = arFileNames.GetAt(0);
arFileNames.RemoveAt(0);
fIn.Open(strFileName, CFile::modeRead, &Error))
dwLength = fIn.GetLength();
BYTE * pBuf = (BYTE *)malloc(dwLength);
fIn.Read(pBuf, dwLength);
fOut.Write(pBuf, dwLength);
fIn.Close();
free pBuf;
}
fOut.Close()
So you're saying this is a bad idea? Wait..I just noticed the CArchive::Write method...Interesting. I'm going to give this a try, but in the meantime if you have any suggestions, please feel free to let me know.
Marcus Spitzmiller
"Ha ha, Stupid bloropope.." - Homer
|
|
|
|
|
Here is something you could try:
CMemFile file;
CArchive ar(&file, CArchive::store);
pYourObject->Serialize(ar);
ar.Close();
DWORD dwSizeOfYourObject = file.GetLength();
file.Close();
I haven't tried it, so may be this would give you a size that is a multiple of nGrowBytes (parameter of the constructor of CMemFile, 1024 by default). 
Hope this helps,
David Defoort
|
|
|
|
|
Thanks, David - I'll give that a go, and get back to you.
Marcus Spitzmiller
"Ha ha, Stupid bloropope.." - Homer
|
|
|
|
|
what does this mean?
Run-Time Check Failure #2 - Stack around the variable 'Alt' was corrupted.
also what is a stack overflow really and how are they caused and prevented?
Thanks.
Steve
Not all who wander are lost...
|
|
|
|
|
I do not know the answer to your first question.
stack overflow is when you run out of stack space in your process. They can be caused in a number of ways, but the reasons including calling a recursive function that recurses until there is no more stack space, a bad message loop is created and an endless number of function calls are created until there is no more stack space. Your stack pointer gets corrupted.
Why they are really bad is that each time you call a function, it creates a stack frame at the current stack pointer (SP). All of the stack variables that are created in your function are allocated on the stack as well as the parameters that are passed into the function. If you run out of stack space, then you lose the ability to make function calls and allocate stack varaibles.
|
|
|
|
|
Basically it is a new feature in VC7.
Let us say that Alt is a 10 byte character array. (char Alt [10]). If you write to the 11th byte, you will get this error.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
Wow
That's indeed a cool feature.
Its amazing it wasnt there in VC 6.0.
We dont usually think of corrupted stacks.
Nish
Yeah that's me down below 
|
|
|
|
|
There are 3 new debugging options that are nice. (But slow)
/RTCc - Checks for loss of precision. (i.e. char a = 10000)
/RTCs - Initialize local variables to non-zero. Detect over-runs and under-runs of arrays on the stack. Stack pointer verification (i.e. calling a __stdcall routine using __cdecl which has totally different stack requirements.)
/RTCu - Reports when a variable has been used prior to initialization. This is a run-time check and not compile time.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
C:\Windows\Desktop\Project3\Partition.cpp(178) : error C2440: 'type cast' : cannot convert from 'int (__thiscall Partition::*)(void)' to 'int'
Conversion is a valid standard conversion, which can be performed implicitly or by use of static_cast, C-style cast or function-style cast
int MemoryManager:: searchList(int pID)
{
LinkedList<partition>* current;
LinkedList<partition> first = Li.info();
current = &first;
Partition tempPartition = current->info();
while((current != NULL) && (((int)tempPartition.getProcessID) == (int)pID))
{
current = current->next();
}
return 0;
}
<\pre>
could anyone tell me how do i fix this thank you.
|
|
|
|
|
What's all this Partition stuff?
STL or something???
And which line is 178 here???
Nish
One Nish is trouble enough.
Imagine 16 of me, dancing wild...
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
|
|
|
|
|
int MemoryManager:: searchList(int pID){ LinkedList* current; LinkedList first = Li.info(); current = &first; Partition tempPartition = current->info(); while((current != NULL) && (((int)tempPartition.getProcessID) == (int)pID)) { current = current->next(); } return 0;}
<\pre>
the Partition class is a class that i defined myself.
|
|
|
|
|
Is this where you get the casting error :-
(((int)tempPartition.getProcessID)
If so what is getProcessID?
If it is a function that returns an int write it as getProcessID(). Because when you write it as getProcessID without the '(' and the ')' you are passing a pointer to the function
Nish
One Nish is trouble enough.
Imagine 16 of me, dancing wild...
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
|
|
|
|
|
Hi,
I have a question about multithread.
Let say there is an array called DBObject[100], and my thread function need access to this array. All threads are required to get a "permit" from the main function, so that this thread can have permission to access the particular data item in array.
Permission will be granted IF DBObject[i]= "free"
Let say:
Thread A: 1. Ask for permission to change DBObject[10] -> "X"
2. If permission receive ---- (DBObject[10]= "free"),
then change DBObject[10] -> "X"
3. Else, wait until DBObject[10]="free"
Thread B: 1. Ask for permission to change DBOject[10] -> "Y"
2. If permission receive ---- (DBObject[10]= "free"),
then change DBObject[10] -> "Y"
3. Else, wait until DBObject[10]="free"
(basically, they are using the same thread function.....)
My question is: Is it possible that both thread A and B can read the DBObject[10]="free" at the same time and therefore, think that they have permission to access DBObject[10] and change the DBOject[10] value at the same time. (if it's happened, then i don't know what will happen......)
p.s.: (the point (1), (2) and (3) are stored in a normal function (not thread), and those thread function just calls this function with some parameters);P
Please help!!!!!!!!!
|
|
|
|
|
You need to use thread synchronization objects.
I suggest a critical section here
Nish
One Nish is trouble enough.
Imagine 16 of me, dancing wild...
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
|
|
|
|
|
Critical section objects can be used only by the threads of a single process!
soptest
|
|
|
|
|
soptest wrote:
Critical section objects can be used only by the threads of a single process!
Critical sections are used when you dont need cross-process suncronization. Only one thread will be allowed access to it.
MSDN snip follows...
[snip]
An object of class CCriticalSection represents a “critical section” — a synchronization object that allows one thread at a time to access a resource or section of code. Critical sections are useful when only one thread at a time can be allowed to modify data or some other controlled resource. For example, adding nodes to a linked list is a process that should only be allowed by one thread at a time. By using a CCriticalSection object to control the linked list, only one thread at a time can gain access to the list.
[/snip]
Regards,
Nish
One Nish is trouble enough.
Imagine 16 of me, dancing wild...
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
|
|
|
|
|
|
oops.
Nish
One Nish is trouble enough.
Imagine 16 of me, dancing wild...
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
|
|
|
|
|
Nish [BusterBoy] wrote:
You need to use thread synchronization objects.
I suggest a critical section here
What is it? Do you have any example?
Thanks!!!!
|
|
|
|
|
ChiYung wrote:
What is it? Do you have any example?
You can use the CCriticalSection class.
It has only two member functions you'll need to use.
Create a CCriticalSection object for your app.
Now call m_critsectionobject.Lock() to gain access to the section. Put this as the first line of the array accessing function. Now when other threads call this function, the Lock() will block till the first thread calls Unkock()
Eg:-
void function(...)
{
m_critsectionobject.Lock();
//do your stuff here
m_critsectionobject.Unlock();
}
Now you can safely call function() from multiple threads without fear of two threads accessing the array at the same time.
Nish
One Nish is trouble enough.
Imagine 16 of me, dancing wild...
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
|
|
|
|
|
So, in this case, I can do it in this way: (example.....just algorithm....correct me if i am wrong)
This function will be called inside the thread function:
bool function (int x, CString InputString)
{
//can have others stuff here
m_critsectionobject.Lock();
If DBObject[x]= "free"
return true; //lock granted and thread can change DBObject[x] = InputString
Else, return false; //lock not grant and thread need to wait until DBObject[x]="free"
m_critsectionobject.Unlock();
//can have others stuff here
}
Question: If Thread A and B are trying to access the above "Critical section" code, the program will "automatically" create a "QUEUE", so that thread A and B can "line-up" to access this section??
Anyway..........THANK YOU VERY MUCH!!!!!!!!!!!!!!!!!!!!!!!!!!!
You are my angel!!!!!!!!!!!!!!!
|
|
|
|
|
ChiYung wrote:
Question: If Thread A and B are trying to access the above "Critical section" code, the program will "automatically" create a "QUEUE", so that thread A and B can "line-up" to access this section??
Yes. A and B will NOT access the function in parallel. B will wait till A has called Unlock().
Nish
One Nish is trouble enough.
Imagine 16 of me, dancing wild...
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
|
|
|
|
|
You are so smart
You gave me a big hands!!!!
Thanks!!!!!!
 ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
I have a 3rd party Win32 DLL (a PGP wrapper) that I need to call from VC++. All I have is the DLL and a VB .BAS file that outlines the functions declarations as VB would call them.
I'm new to working with Win32 DLLs without an accompanying SDK kit. Can I set up the _stdcall(s) (using the VB code as a guide) or will need a .def or .h file from the DLL?
TIA
|
|
|
|
|
You'll need a header file for the function prototypes, huh? Otherwise it won't compile
Nish
One Nish is trouble enough.
Imagine 16 of me, dancing wild...
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
:jig::jig::jig::jig:
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
