C / C++ / MFC

try/catch Variable Scope Question

4-Aug-04 6:35

Does anyone know of a good article that could help me with the following problems? I have a fairly large Visual Studio .Net solution. It is an MFC application with a number of DLLs in addition to the main project that contains the main app's gui.

For some reason, the minimum rebuild feature doesn't work too well. I need to learn more about compile time dependencies and how to avoid recompiling everything every time I change some code and perform a build or a batch build.

If I perform a clean and a build or a rebuild all, then assuming the results are a clean compilation with no errors, shouldn't I be able to run in debug mode immediately? For some reason, if I do a rebuild all of my entire MFC app and all DLLs, and then press F5 to debug, visual studio complains that the DLLs are all out of date and makes me build again. Now once I do a rebuild, followed by a build or batch build, all is okay and subsequent builds seem to be pretty smart and only build the necessary pieces based on what files changed. I don't understand this. If I do a rebuild all, that should be it. Everything should be up to date and performing a subsequent build should result in the output window showing me that all is up to date and none of the projects should recompile.

Any ideas or suggestions on how to solve this issue?

Regards,
Shawn

Steve Thresher4-Aug-04 6:03

Steve Thresher

4-Aug-04 6:03

Is the following legal C++ code?

try
{
    char s[10]="Error";
    <br>
    if (some condition)
        throw s;
}
catch (const char *s2)
{
    OutputDebugString(s2);
};

From what I've read I would expect the catch block to receive a pointer to stack memory thats no longer reserved for the variable s. Am I correct?

Systems AXIS Ltd - Software for Business ...

Nitron4-Aug-04 7:36

Nitron

4-Aug-04 7:36

Steve Thresher wrote:
Is the following legal C++ code?

It appears that throw throws a copy of the data, thus preserving the scope. It is the same concept as constructing an exception in your code and throwing it.

~Nitron.

ññòòïðïðB A start

palbano4-Aug-04 7:49

palbano

4-Aug-04 7:49

Nitron wrote:
It appears that throw throws a copy of the data

Well it of course copies the char* variable but the caught variable contains the same memory address as the thrown variable. So the memory is not copied. Don't know if that is what you meant. Confused | :confused:

"No matter where you go, there your are." - Buckaroo Banzai

-pete

Steve Thresher4-Aug-04 10:07

Steve Thresher

4-Aug-04 10:07

If you're dealing with objects a copy is made when the object is thrown (using the copy constructor or a shallow copy if a copy constructor is not avaiable) and then the original is destroyed at the end of the try block. When it comes to strings the compiler only knows the address of the string so no copy can be made.

Systems AXIS Ltd - Software for Business ...

palbano4-Aug-04 7:43

palbano

4-Aug-04 7:43

That is not my understanding. The stack will not begin to unwind until after the exception handler returns.

"No matter where you go, there your are." - Buckaroo Banzai

-pete

Tim Smith4-Aug-04 15:26

Tim Smith

4-Aug-04 15:26

If it works, it works due to something that is implementation specific.

In general, I would beat people who made code that depended on that.

Tim Smith

I'm going to patent thought. I have yet to see any prior art.

Ryan Binns4-Aug-04 18:46

Ryan Binns

4-Aug-04 18:46

It will probably work, but shouldn't really be used. Instead, you could throw an integer index into an array of strings stored elsewhere, or allocate memory for the string and throw it, then free it in the catch() block.

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

Newbie: Can I do this?

cgriffin4-Aug-04 5:52

cgriffin

4-Aug-04 5:52

I want to program a DLL that would have three entry points. Initialize, DoDialog and Terminate. The Initialize would have a parameter that is a callback into the calling application. DoDialog would have a parameter that would be a Handle to a block of data. When called DoDialog would bring up a dialog and return when the dialog is finished. The data would be modified by the dialog. Terminate would just release things that were allocated in Initialize. So is this possible? Should I do this in MFC, .NET, something else? I also have a fair amount of non-UI C++ code that need to be ported for this dialog as well.

palbano4-Aug-04 7:16

palbano

4-Aug-04 7:16

cgriffin wrote:
Can I do this?

I have no way of knowing that.

palbano wrote:
Can it be done?

Sure Big Grin | :-D

"No matter where you go, there your are." - Buckaroo Banzai

-pete

digwizfox4-Aug-04 7:31

4-Aug-04 7:31

Sounds reasonable. You can program a DLL to do many things for you as long as you define a good interface. DLLs can contain classes and/or global functions that can be exported so that an application project can link to it. I like to think of DLLs kind of like how I think of classes. You figure out what you want it to do; what kind of logic/common code you want in it and design a good user interface so that other projects can link to the functions and/or classes.

We have a main app project that links to MFC extension DLLs. Use the wizard to create your ext DLLs and it is very simple. In some cases our MFC extension DLLs export class definitions (such as common dialogues). Then the main app can use #include "TheDialogueHeader.h" and then instantiate the dialogue like any other MFC class and implement a modal or modeless dialogue.

We also have DLLs that export a thread function that the application can link to and call by passing the function pointer to AfxBeginThread. Then you have a DLL with a main function that is a thread that will execute along with all of the threads in the Main App project. So your Initialize() func could be a thread or just a function that can be called and will return when finished. If it is a thread, then use the terminate function to implement the signaling logic that will cause the thread(s) in the DLL to terminate for a clean exit.

There are lots of ways to do it but what you are describing seems like a reasonable thing to do. The possibilities are endless and there are many different ways of organizing the code within your DLL. Just like a class, you can have global functions in the DLL or classes that are not exported (private to the rest of the world) that are called by the exported functions/classes (public to the world); and so on and so on.

Have fun!
Shawn

cgriffin4-Aug-04 7:45

cgriffin

4-Aug-04 7:45

Thanks for your reply. I was afraid to add too much to the first post so I left out some details. What I am doing is porting code from a Macintosh project. No threading is necessary. The other thing I should mention is that I need to be able to define the dialog after compile time. I have an application that allows the user to design a custom specialized dialog. My application then generates the resources and combines that with the dialog code for the final plugin (Mac version). It seems like it would be too much trouble to write a resource table into the dll. So I was thinking that I could have an external file in my own format, read that and then create the dialog programmatically. Which platform would be best to do that in? If it's .NET is C# required for using .NET? If so then I probably can't go that way as I have to integrate my control/model code from C++.

digwizfox4-Aug-04 8:46

4-Aug-04 8:46

Sounds challenging. I've never needed to design a dialogue at run time. I'm not experienced with managed C++ code or C#.

First of all .Net could be used for many things (you don't need to know C# to use VS .NET). You can use .Net to program an application using all unmanaged C++ code if you'd like. Visual Studio .Net has many options and capabilities that are well beyond what I've ever done.

But when I mentioned earlier that a dialogue can be designed in an MFC extension DLL, the .rc file will exist within the DLL and the .Net wizard will take care of that. So I'm only familiar with the process of creating dialogues in the .dll and allowing the .rc file to exist as part of the dll project. Of course that means that the dialogue exists at compile time which isn't what you want, so I can't help you with that particular detail. Perhaps someone with that kind of experience can chime in with some suggestions.

Shawn

cgriffin4-Aug-04 10:10

cgriffin

4-Aug-04 10:10

Thanks for the help. BTW what is managed/unmanaged C++?

digwizfox4-Aug-04 10:24