|
Sweet. Thanks.
..so, let's pretend for a minute that I'm not a layman(which I am). What are the gory details?
|
|
|
|
|
No gory details....sometimes developers here speak over new developers heads. It's kinda like they want to break everything down to the Greek language (kinda like a preacher in a pulpit)(Sometimes it's easier in english than when you break it down to something else). Which is nice, but sometimes you have to tell it in easier terms and then when that person understands explain why (in Greek  )
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
scottwalk wrote:
What is the purpose of IN, OUT?
Basically it indicates when the variables will contain valid information. IN indicates that the variable has valid information when calling the function; OUT indicates that the variable will have valid information after the called function returns.
See "pass by reference" and "pass by value" for related information.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Excellent. Even though I'm a beginner, I can still speak g(r)eek now and then.
|
|
|
|
|
Is it possible to use special character \t with TextOut?
CString s=_T("");
s.Format("This a\ttab");
pDC->TextOut(0, 0, s);
It would print block square for \t instead of tab.
|
|
|
|
|
Try DrawText() with DT_EXPANDTABS flag set, or TabbedTextOut() with TabPositions = 0 and TabStopPositions = NULL.
onwards and upwards...
|
|
|
|
|
Hi guys, this is probably a very *niche* question, and I don't suppose I'll get many answers, but here's hoping ... 
My program has two components, let's call them ...
program.exe
and
library.dll
-
library.dll is statically linked to program.exe throughout program.exe's entire lifetime.
Suppose a function in program.exe calls a function in library.dll, which allocates some memory using the "new" operator. I've recently discovered that releasing this allocated memory from a function in program.exe causes a crash. You have to release the dynamic memory from the same *module* it was allocated in. Therefore, if I allocated memory using a statement in library.dll, I have to release it using another statement in library.dll, not in program.exe.
It took me long enough to figure that out without any documentation, and that's fine, but my problem is as follows:
Suppose I have a structure of two nested classes.
class A;
class B
{
A a; // contains an instance of A
};
Class A is defined in library.dll, class B in program.exe
Class B is instanced in the global scope in program.exe.
Now, suppose I call a function in class B (program.exe) that then calls a function in class A (library.dll) to allocate some dynamic memory. Class A has a destructor that should theoretically release the memory once the lifetime of the instance "a" expires. When the program closes, this is usually done inside the exit() function when all destructors are executed, when the program is closing.
But here comes my problem: Before the program closes, C++ throws an exception as the "delete" operator on the dynamic memory is executing. This happens, as I see it (and hopefully I'm wrong), because C++ somehow treats the "delete" statement that is defined inside library.dll as a code of program.exe because it's calling it from the global destructor.
Having a destructor of class A in library.dll for the dynamic memory causes a crash. However, when I define a destructor of class B in program.exe that calls a function in class A to delete the memory, the program ends fine without any crashes.
I hope I have made the matter clear, confusing though it may be. Does anyone have the slightest idea what may be going wrong? I'd be very grateful, thanks.
|
|
|
|
|
We have projects that have memory allocated and freed, newed and deleted all over the place. I think that perhaps your DLL and EXE are somehow mismatched. One is Debug, other is Release, or if MFC, one is statically linked to MFC and other is using MFC as a DLL. You can check that and possibly your problem will go away.
Other option, to avoid the delayed delete calls, is to declare a POINTER to your Class B at global scope, and create (new) it within the context of your program's regular execution (InitInstance in MFC), and delete it before your program is really exiting (wihtin ExitInstance). Then you might be okay that way too.
|
|
|
|
|
The funny thing is, my prog is a console app. The compile types are all "Single-Threaded with Debug". No fancy MFC, or even the windows libraries, or anything
|
|
|
|
|
I am with you on this.
The guideline that I go by.
objects that are instantiated inside a dynamically loaded library must be deleted inside the same library. If the object is deleted inside the program itself, the results are unpredictable. It may work fine, or it may cause a memory leak or even a program crash. If your program redefines new or delete, a program crash is almost guaranteed.
Thank You
Bo Hunter
|
|
|
|
|
So what's the verdict? This is a really interesting thread and I'd like to know if any conclusions were reached.
Based on Peter's description, the memory is getting allocated in the program. Peter, you said that class A was embedded in class B right? And you said that class B was instantiated in the main application right? So essentially, the library contains the class declaration for A but the main application project contains the actual code that runs and instantiated objects, deletes objects, displays data to the console, and so on and so forth. Is that right? I do this all the time with no problems. The class in the library needs to be exported so that the program can compile and link properly. Obviously you've done that else it wouldn't have compiled and linked. But I have never instantiated something in a DLL and then passed the destruction responsibility to another DLL or .exe. That would seem like a strange implementation to me; anyway.
I don't know what you mean by the "Delete" statement defined in library.dll. The delete statement is basic C++ syntax. It's not defined in the DLL. I don't know what you mean by saying that. It sounds like your library.dll is simply declaring the class. That has no bearing on where and how the class can be created or destroyed. Any project (dll or the main project) should be able to link to the class declaration in your library, instantiate it's own version of the object and subsequently delete it. Is there any special code in the destructor of Class A?
It'd be nice to see some code snips of class B and A so we have some idea of the complexity of the classes, especially what specifically, is being done in the destructor of each class. Oh and some snips of code where you instantiate and delete the object would be nice to see as well.
|
|
|
|
|
Does anyone know of a good free command line tool for replacing all instances of one string in file with another?
Joel Holdsworth
"Outlook not so good"
That magic 8-ball knows everything! I'll ask about Exchange Server next
|
|
|
|
|
You could always wrap up CString::Replace() in a little program.
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
|
|
|
|
|
Why not just write one in about 20 lines of code?
EX (error checking omitted for brevity):
<br />
int main(int argc, char *argv[])<br />
{<br />
if (argc != 4)<br />
{
printf("Missing Parameters");<br />
exit(1);<br />
}<br />
<br />
FILE *fp = fopen(argv[1],"rb");<br />
if (fp)<br />
{<br />
CString cFileData;<br />
char caBuf[4096];<br />
int iSize = fread(caBuf,1,sizeof(caBuf)-1,fp);<br />
while (iSize > 0)<br />
{<br />
caBuf[iSize] = 0;<br />
cFileData += caBuf;<br />
iSize = fread(caBuf,1,sizeof(caBuf)-1,fp);<br />
}<br />
<br />
fclose(fp);<br />
<br />
cFileData.Replace(argv[2],argv[3]);<br />
<br />
fp = fopen(argv[1],"wb");<br />
if (fp)<br />
{<br />
fwrite((LPCSTR)cFileData,1,cFileData.GetLength(),fp);<br />
fclose(fp);<br />
}<br />
}<br />
<br />
return 0;<br />
}<br />
onwards and upwards...
|
|
|
|
|
Here's one with 10 lines of code:
if (argc < 4) return (1);
CFile file(argv[1], CFile::modeRead);<br />
CString Buffer;<br />
file.Read(Buffer.GetBuffer(file.GetLength()), file.GetLength());<br />
Buffer.ReleaseBuffer(file.GetLength());<br />
file.Close();<br />
Buffer.Replace(argv[2],argv[3]);<br />
file.Open(argv[1], CFile::modeCreate|CFile::modeWrite);<br />
file.Write((LPCTSTR)Buffer, Buffer.GetLength());<br />
file.Close();<br />
Top ten member of C++ Expert Exchange.
http://www.experts-exchange.com/Programming/Programming_Languages/Cplusplus/
|
|
|
|
|
I guess I did straight C for too long....can't get out of fopen/fread mode...:->
onwards and upwards...
|
|
|
|
|
Cool thanks, I think I'll use that. Although I may de-MFCify it to make the app more lightweight.
Joel Holdsworth
"Outlook not so good"
That magic 8-ball knows everything! I'll ask about Exchange Server next
|
|
|
|
|
I don't know what the problem may be, but have you hovered over the IDS_SOMESTRINGID to see what its value is? Also make sure you don't have a resource defined with the same id.
My articles
www.stillwaterexpress.com
BlackDice
|
|
|
|
|
I have a worker thread and need to start and stop a timer.
As I understand there are two ways to do this, using CWnd class and handling OnTimer()or SetTimer(hWnd, ....) API call, but both rely on having a UI to receive WM_TIMER messages. Is this correct? 
If yes what is the best way to implement a timer in a worker thread, that does not interact with the UI at all?
|
|
|
|
|
no_reg_name wrote:
sing CWnd class and handling OnTimer()or SetTimer(hWnd, ....) API call, but both rely on having a UI to receive WM_TIMER messages. Is this correct?
Very Much Correct ,No problem using timer in UI
no_reg_name wrote:
what is the best way to implement a timer in a worker thread, that does not interact with the UI at all?
You have to use Sleep api to simulate the Timer in worker thread.
"I Think this Will Help"
<h5
alok="" gupta="" <br=""> visit me at http://www.thisisalok.tk
|
|
|
|
|
Look at CreateWaitableTimer and use WaitForSingleObject or else WaitForMultipleObjects, if you have another event or such to signal your thread to exit or to perform some other work.
Instead of using Sleep() os LeepEx() which will lock up your thread until the sleep has timed out.
|
|
|
|
|
There are two ways to use the SetTimer API. The first is as you said where you specify an HWND that will recieve the WM_TIMER message. The second is to use the CALLBACK function that you specify in the fourth parameter of the SetTimer() function. See SetTimer[^] and TimerProc[^] in MSDN for more info.
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" mYkel - 21 Jun '04
Within you lies the power for good - Use it!
|
|
|
|
|
I guess you can type faster than me.... Beat me by two seconds...
onwards and upwards...
|
|
|
|
|
basementman wrote:
I guess you can type faster than me
Yeah, my two fingers do move pretty fast
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
"Obviously ??? You're definitely a superstar!!!" mYkel - 21 Jun '04
Within you lies the power for good - Use it!
|
|
|
|
|
You do not have to have a window to create a timer. You can create a timer if you supply NULL for the hWnd and supply a callback proc.
onwards and upwards...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
