C / C++ / MFC

14-Jun-07 5:53

Do people ever do this:

{
   int i, j, k, l, m, n, o;
   for (i = 0; i < 1000; i++)
   {
      //insert implementation here
   }
}

This would be a way to clear i->o off the stack as soon as you don't need them anymore, right? My main reason for using this would be, if I had many variables, and I didn't want to accidentally redefine any variables throughout the entirety of the function. Then again, I could also split it up into multiple functions.

Michael Dunn14-Jun-07 6:27

Michael Dunn

14-Jun-07 6:27

I only do that in cases where I use a scarce resource like a device context. When you have just ints, those use a relatively insignificant amount of stack space. If you're running into naming errors, fixing the code is preferable to sticking scopes in.

--Mike--
Visual C++ MVP Cool | :cool:

LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ

Dunder-Mifflin, this is Pam.

Nemanja Trifunovic14-Jun-07 6:28

Nemanja Trifunovic

14-Jun-07 6:28

Michael Dunn wrote:
I only do that in cases where I use a scarce resource

Heck, you were typing faster Smile | :)

Programming Blog
utf8-cpp

Cyrilix14-Jun-07 6:43

14-Jun-07 6:43

Well, the problem I'm dealing with is that before I make a function call to say, AddWorkToWorkQueue(), I have to initialize a bunch of pointer variables just to set up this call (which this call will use). AddWorkToWorkQueue, however, is a very dynamic process, and I expect to be able to call it anywhere as much as I want.

Because of this, I do not want to explicitly make this repetitive call in my code -- instead, I define a macro for it, which contains several lines of code. The thing with a macro, is that once you define it, you define it. The variable names you define in a macro do not change, so if you use this macro multiple times, you will get variable redefinitions.

I also want to make this macro easy to use, which means that I don't want the user to be forced to keep track of how many times he has used this macro and pass in an additional number as a token parameter to be concatenated at the end of every variable name (see ## - token pasting preprocessor).

The solution I therefore use, is to enclose my macro with {}, allowing me to initialize all the variables I want without any redefinition.

Note: I did mention in the beginning that I was initializing a bunch of pointer variables. We all know what happens when you go out of scope on pointer variables that have not been deleted -- you get a memory leak. No worries -- I also delete the pointers asynchronously by keeping track of them in an STL container.

jbarton14-Jun-07 8:53

jbarton

14-Jun-07 8:53

You said that you are using an STL container to keep track of pointers. Since you are using C++, you really should consider changing from using macros to instead use inline routines. Except for certain special diagnostic or logging routines (where you want to access preprocessor macros such as __FILE__ or __LINE__), there normally isn't any need to use macros in C++ for blocks of code.

In this case, it sounds like you should just make a small inline routine which declares and initializes the variables needed to call your other routine. This small routine can then be used as many times as you want, as the scope of the variables are within the routine. By making it inline, there should be no additional overhead beyond what you would get from a macro. You also won't need to pass in a number as a token parameter, as you won't get variable redefinitions if you use an inline routine instead of a macro.

As far as keep tracking of pointers to delete, I would suggest that you instead use an appropriate smart pointer, using the lightest weight smart pointer that you can. For many simple cases, an std::auto_ptr is sufficient or even a boost::scoped_ptr will work. For more complicated cases, a reference counting smart pointer such as boost::shared_ptr might be needed. Without knowing how you are using the pointers, I couldn't tell which would be a better choice.

Cyrilix14-Jun-07 9:38

14-Jun-07 9:38

Well, the reason why I use a pointer instead of a smart pointer that exits once it goes out of scope is because I need to make sure that my pointers exist until I actually use them, which may be a while after I initialize them. As such, if I were to use a local variable (which I could very well do) and they were to go out of scope before I use them, then by the time I actually use them (my pointers encapsulate function pointers), I would be getting serious errors. To me, the concept of a smart pointer is the same as the concept of a local variable (in this case). They both do graceful shutdown when they go out of scope, which is exactly what I don't want.

I'm not sure about using inline functions as I've never used them before, but I will look into it. I thought it was more of a performance optimization than a functional technique (as in -- it works the same way as any other function except that for functions that get called really often, it will increase performance).

jbarton14-Jun-07 9:57

jbarton

14-Jun-07 9:57

The main point I was trying to get across was that you should avoid using macros in C++ except in a very small number of special cases. Using macros is generally the C method of doing things, not the C++ method.

Whether you make the routine that replaces the macro into an inline routine or just a callable routine is not important. I only suggested an inline routine since it produces almost exactly the same result as a macro - no additional function call being made in the generated code. You would get the same benefits with a normal routine instead of an inline routine except the generated code would probably include a call to this normal routine. Note: some compilers may choose to inline a small normal routine without you adding the inline keyword. Also, some routines marked as inline might still result in a function call - the compiler doesn't have to inline a routine when you tell it to inline. This generally doesn't happen, but there are a few cases where it is needed (such as if you get a pointer to the inline routine and then call it through the pointer).

The usage of smart pointers may or may not be appropriate in your case. It just tends to make the cleanup code a lot easier. As long as you can arrange to have the scope of the variable end when you no longer need the resource, then you don't need to do any explicit calls to delete the object. Sometimes it just takes a little reorganization to take advantage of smart pointers. Without seeing your code, I can't tell whether you could use smart pointers by just rearranging things a bit.

You said that you were placing the pointers into an STL collection for future cleanup. You could place a boost::shared_ptr into the collection, which would simplify the eventual cleanup. Instead of needing to loop through the collection and manually deleting each pointer, you can just clear the collection. The boost::shared_ptr would then take care of cleanup automatically.

Cyrilix14-Jun-07 10:38

14-Jun-07 10:38

Modified: The following is my defined macro (without the line breaks for readability) -- given that I'm passing in types and function pointers, the syntax can get quite hairy. Do you think using an inline function would actually work in this case?

#define PROCESS(type, function, args)
{													
	CallbackWrapperSpecific<MainWindow, void (MainWindow::*)(##type&), ##type>* cbwSpecific =	
		new CallbackWrapperSpecific<MainWindow, void (MainWindow::*)(##type&), ##type>
                (this, &MainWindow::##function, ##args);
	CallbackWrapperGeneric<##type>* cbwGeneric = cbwSpecific;
	CallbackWrapperDestroy* cbwDest = cbwSpecific;
	CoreWorkUnit* cWorkUnit = new CoreWorkUnit(Function_##function, cbwDest);
	m_localWorkMap.insert(map<int, CoreWorkUnit*>::value_type(m_threadPool->Process(cbwGeneric), cWorkUnit));
}

As for the boost library, I will try what you've suggested.

Thanks.

Re: Forced scoping as a programming technique? [modified]

jbarton15-Jun-07 3:20

jbarton

15-Jun-07 3:20

I didn't read your reply until this morning, so I am just replying now.

Looking at your PROCESS macro, it seems like most of it could easily be changed to be a member template function of class MainWindow (although I am making some assumptions about what the various symbols are).

The assumptions that I am making are:
- CallbackWrapperSpecific is a templated class derived from CallbackWrapperGeneric.
- The args passes to PROCESS is a specific variable with the type matching the first argument passed to PROCESS.
- The PROCESS macro is being used inside a member of MainWindow. I assume this because the "this" pointer is being passed to the constructor of CallbackWrapperSpecific.
- The m_localWorkMap is a member of MainWindow which is used to hold thread ids which map to CoreWorkUnit * objects (part of your cleanup mechanism).
- The m_threadPool is a member of MainWindow which is used to create a thread to process the request, with its Process member returning the thread id.

Given these assumptions, the only problem line that I see in the entire macro is:
CoreWorkUnit* cWorkUnit = new CoreWorkUnit(Function_##function, cbwDest);

This line is constructing a Function_ name from a combination of a constant string and the name of the member routine in MainWindow. This appears to be the only line which can't directly be converted into using a member template function. If you could explain what this is for, perhaps I could suggest another way to do this.

The rest of the code looks straight forward and should be easy to change - the following is close to what would be used (if my assumptions were correct):

<br />
   template <typename type><br />
   void Process( void (MainWindow::*memberFn)(type&), type args )<br />
   {<br />
      CallbackWrapperSpecific< MainWindow, void (MainWindow::*)(type&), type >* cbwSpecific =<br />
         new CallbackWrapperSpecific< MainWindow,void(MainWindow::*)(type&), type>( this, memberFn, args );<br />
<br />
      CallbackWrapperGeneric<type>* cbwGeneric = cbwSpecific;<br />
      CallbackWrapperDestroy* cbwDest = cbwSpecific;<br />
      CoreWorkUnit* cWorkUnit = new CoreWorkUnit(/*Function_##function,*/ cbwDest);<br />
      m_localWorkMap.insert(map<int, CoreWorkUnit*>::value_type(m_threadPool->Process(cbwGeneric), cWorkUnit));<br />
   }<br />

Note that I commented out the first argument to the CoreWorkUnit constructor as I didn't know what to put here.

The calling sequence is slightly different, as you pass the type as a template parameter, and the address of the MainWindow routine as the first argument - the call would look something like:

<br />
   Process<int>( &MainWindow::DoSomething, 1 );<br />

Cyrilix15-Jun-07 3:45

15-Jun-07 3:45

I am surprised that you were able to deduce so much from just seeing this code snippet -- your assumptions are almost 100% on the spot. The m_localWorkMap actually holds work IDs and the call to Process from m_threadPool returns the work ID so I can insert it into m_localWorkMap. In my ThreadPool class (not shown), I have a work ID being mapped to a WorkUnit. In my local (caller) class, CoreWorkUnit maps work IDs to resources that I need to free (namely cbwDest, as you can see above, which is the basest class of CallbackWrapperGeneric and CallbackWrapperSpecific) and the function name. Say I pass in MyFunction as my "function name", when the CoreWorkUnit constructor executes, it will set an enum value for CoreWorkUnit (Function_MyFunction). This is used when I get my data later on (I have to know which work ID corresponds to which work function that I actually called). I can easily fill this in by just passing the enum value directly (but one of my goals is to make PROCESS simple and as parameterless as possible to use, so I'll take that into account.

The below seems to work...

template<class T>
inline void MainWindow::Process(void (MainWindow::*funcPtr)(T&), T args)
{
	CallbackWrapperSpecific<MainWindow, void (MainWindow::*)(T&), T>* cbwSpecific =
		new CallbackWrapperSpecific<MainWindow, void (MainWindow::*)(T&), T>(this, funcPtr, args);
	CallbackWrapperGeneric<T>* cbwGeneric = cbwSpecific;
	CallbackWrapperDestroy* cbwDest = cbwSpecific;
	CoreWorkUnit* cWorkUnit = new CoreWorkUnit(Function_DoWork, cbwDest);
	m_localWorkMap.insert(map<int, CoreWorkUnit*>::value_type(m_threadPool->Process(cbwGeneric), cWorkUnit));
}

...with the following prototype...

template <class T> void Process(void (MainWindow::*funcPtr)(T&), T args);

To be honest, I didn't think a class member template function was possible without the class being a template class, so now I have dispelled another myth. Smile | :)

-- modified at 10:10 Friday 15th June, 2007

Nemanja Trifunovic14-Jun-07 6:27

Nemanja Trifunovic

14-Jun-07 6:27

That makes sense in some situations when you want a resource to be held as short as possible. Ie:

{
mutex lock(some_lock);
...
}

But as you said it is often better to have it as a separate function.

Programming Blog
utf8-cpp

Re: setting executable icon

bob1697214-Jun-07 8:12

bob16972

14-Jun-07 8:12

Cyrilix wrote:
Do people ever do this:

Yes.

As others have stated, to ensure a resource is in scope only as long as it's needed like a device context. I've also used it to ensure my assertions on scoping within a function were clear and somewhat enforced if some delicate resource balancing act were being performed.

setting executable icon

R Thompson14-Jun-07 5:44

R Thompson

14-Jun-07 5:44

I'm trying to set my icon for a exe file in visual studio 2003. I think this should be a common thing to do, but google has given me no info for the keywords I've been trying. Can anyone point me in the right direction on how to do this?

R Thompson14-Jun-07 6:11

R Thompson

14-Jun-07 6:11

figured it out.

For those who were also wondering. What you got to do is go into the resource folder on the solution tab. make an icon with the same name as your executable (or click on said icon if its already there, which it was for me)

Then the weirdness happens. Click on the icon; then You need to right click on the main page where the icon is and select some of the other resolutions, then change your icon to suite that.

Something this common shouldn't be impossible to figure out. fyi this was mfc.

Re: setting executable icon

Michael Dunn14-Jun-07 6:28

Michael Dunn

14-Jun-07 6:28

Explorer looks at the icon resources in the EXE and uses the icon with the smallest ID.

--Mike--
Visual C++ MVP Cool | :cool:

LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ

Dunder-Mifflin, this is Pam.

Re: setting executable icon

Hamid_RT14-Jun-07 19:44

Hamid_RT

14-Jun-07 19:44

Do you want to change icon of your program

WhiteSky

Save Screenshot

CDRAIN14-Jun-07 4:54

CDRAIN

14-Jun-07 4:54

Hi, I'm developing a Visual C++ App.
I need to save my app's screenshot and save it as an image (to analize it in future).
Can somebody help me to do this on a Button's click event?

Thanks a lot

David Crow14-Jun-07 5:40

David Crow

14-Jun-07 5:40

CDRAIN wrote:
I need to save my app's screenshot...

To where?

"A good athlete is the result of a good and worthy opponent." - David Crow

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

Naveen14-Jun-07 14:30

Naveen

14-Jun-07 14:30

You can save your app's screen as a bmp file. there are many samples in code project desribing this. Have a search. How ever i will explain the steps.

Get the device context of your window.
Create a memory dc and a bitmap.
bitblt the content of the screen to the memory dc
now get the pixel data and other informarion from this bimap object and write to a file.

nave

[OpenedFileFinder]

Re: Save Screenshot [modified]

Hamid_RT14-Jun-07 19:41

Hamid_RT

14-Jun-07 19:41

Do you have any handle of this screenshot (hbitmap)?

WhiteSky

CDRAIN15-Jun-07 0:46

CDRAIN

15-Jun-07 0:46

I need to save the screenshot in a file .bmp or jpg (better) and the post it via email.
I don't have implement nothing code yet, have you sample code?

How I've just said I need to post it in email message (compiled with the TO: address), is there an API function (like the HTML "mailto:mymail@my.com" or some simple command) to open the user's email App with this message ready to me sent?

Thanks.

-- modified at 6:53 Friday 15th June, 2007