GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
There's no mechanism within C++ to do that. In fact, modern run time systems are designed so that program data spaces are different for each program invocation. For example:
$ cat example.c
printf("&n = %p\n" , &n);
$ for ((i=0;i<4;++i)); do ./example; done
&n = 0x7fff2ddda67c
&n = 0x7ffdece1243c
&n = 0x7ffe42e7d2bc
&n = 0x7fffd2e78b2c
Note that even this simple program gives different addresses for the address of int n on successive runs. This is to make it difficult for any malicious program to interfere with and modify a running program, or to predict where a program will place data.
Also note that in any modern OS (outside of some embeded applications), you are dealing with virtual addresses anyway, so where your process thinks an object is and where the object actually is in physical memory are completely different, so you need to know things like the value page frames and things to work out a physical address of an object in memory.
Outside of some sort of educational value, I can't see any up side to always getting the same address when calling new, so maybe you might want to think about why you want this behavior and come up with a new plan.
The question is stupid, there is no way a dynamic heap manager can guarantee it wont give the memory space away to some other call for memory allocation. To do what you asked it would have to keep the memory "available" anyhow, so for the love of all things coding just declare the thing static in that case (unless you actually want a global).
My C++ is rusty with string objects but it should be something like
static char* str = char;
In C it is simpler
static char str;
Problem solved it now has the same address everytime locally, and effectively does the same thing that any crazy heap manager doing what you asked would have to do.
I am assuming you are going to change the string at times, so you want a variable not a constant.
Main Question: Is it possible to set a tree item image (CTreeCtrl::SetItemImage) without having to build a CImageList ?
I have to build different images corresponding to the items state and I would like to be able to create the image dynamically (lot of TransparentBlt) instead of having to list and build all the images and add them statically to the image list.
i have a default item image and I TransparentBlt state images on it
for example, an item can have the state1 enabled, and will display the appropriate image representing state1.
an another item can have state1 and state4 and will display an image with the state1 and state4
Now, I have to create the imagelist for all combinations of states at compile time and call the SetItemImage with the image list index.
I'd like to be able to simply call something like:
myTree.SetItemImage( hItem, BuildMyItemImage(hItem ) ); // and that would dynamically build an image depending on the states and just use it.
I was wondering if it is possible to connect to an FTPS server using CInternetSession/CFtpConnection and if so how. Or will I need to use a library to achieve this. I've searched around on the internet but can't find a definitive answer.
I can access the server using FileZilla with no problems. I know very little about FTP/FTPS but my guess is that CInternetSession/CFTPConnection do not support SSL(TSL); I've been doing quite a lot of reading but haven't found anything to confirm this however. I think my next step is to try out curl.
I hadn't seen that particular post, but I've seen most of the links listed there. I did try adding ftps:// to the server name, as suggested in that link, but that returns and invalid url error. I was hoping for a simple solution but it looks to be more complicated than I hoped.
It's called the NON client area but sorry I don't use MFC enough to help.
What I can tell you is on the windows API it's the WM_NCPAINT message you need to handle
and you simply draw the image onto the Device Context it provides.
The WM_NCPAINT message is sent to a window when its frame must be painted.
The DC is funny it is the size of the whole frame window with a big hole in the middle you cant draw which is the normal
client area. So you can draw from RECT.bottom up whatever the height of the frame is.