I was browing old posts and came across this discussion. The standards state that It is unspecified whether or not a reference requires storage which gives compiler venders alot of room for implementation. However I believe you are both correct depending on how the compiler performs optimization and has implemented references. I make this assertion because the ISO standards explicitly allow both scenarios.
Essentially it is not correct to say that references are always pointers. It is equally incorrect to say that references always refer directly to the object. It really comes down to language semantics.
Underneath it all, a reference i to object x is typically the machine address of the object x. But when the programmer says i++, the compiler generates code that increments x. In particular, the address bits that the compiler uses to find x are not changed.
Even though a reference is often implemented using an address in the underlying assembly language, please do not think of a reference as a funny looking pointer to an object. A reference is the object. It is not a pointer to the object, nor a copy of the object. It is the object.
1. The OS keeps track of all allocated blocks on the heap. So it knows about the total size, number of objects etc. This information is used to free the heap.
I doubt about it, according to my knowledge whenever application allocates memory using malloc or new, compiler will keep track of total amount of memory allocated in 4 bytes (32 bits on 32-bit OS) just ahead of starting address of allocated block.
For example, int *a = new int;
Suppose starting address of a is 100, then 4 bytes ahead of address location 100 say 96-100 will contain value 4*sizeof(int).
So when free or delete is invoked, it just look into memory space and release accordingly.
When uType is STRRET_OFFSET, MSDN doesn't say whether the string uOffset is pointing to is an ANSI or Unicode string. Is it always ANSI or always Unicode? Is it ANSI on Win9x systems and Unicode on WinNT systems?
uOffset is declared as UINT (unsigned int). So it is not a string.
uOffset is an offset to a string. I was wondering whether the string it's "pointing" to was ANSI or Unicode.
ANSI or UNICODE is not dependent on the OS.
It depends on whether the macro UNICODE or _UNICODE is declared or not.
For example, LPTSTR (TCHAR*) becomes LPSTR (CHAR*) if UNICODE is not declared and LPWSTR (WCHAR*) if UNICODE is declared.
I know about the TCHAR stuff. The reason I mentioned the OS was because I was thinking since Win9x used ANSI internally (mostly, I think) and WinNT used Unicode (but supported programs compiled for ANSI for compatibilty), the string inside the PIDL where uOffset is "pointing" would be that type.
I am trying to run an application on a machine that does not have Visual Studio 2008 installed.
I am getting an error message "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem."
It's only a one dialog application. Nothing fancy. The controls used are combo boxes, edit control, static text control and list control.
I have installed the distributable libraries on this machine. I have compiled my code under release mode. Update the machine with all patches from Microsoft update as well.
I used the setup and deployment wizard too to see if that would solve my problem.
I have installed the distributable libraries on this machine.
How did you do that exactly ?
TO be able to run such an application on a machine were Visual Studio is not installed, you need to install the Visual C++ 2008 Redistributable package[^] on the target machine. This takes care of installing the required libraries (C run-time and MFC libraries). You can't do the same as with VC6: simply copying manually some files won't work.
you need to install the Visual C++ 2008 Redistributable package[^] on the target machine.
Yes, I read about that when I searched for this error before posting this message.
Not sure what else to do, even reinstalled the operating system, got all the current updates. and installed the redistributable and yes I did compile it in the release instead of debug. Are there any options that need to be changed when I do a release compile.
I even tried a new project created by the wizard same result in the realease mode.
Do I have to change any other options when in release mode?
Ozer is right in that GetBuffer() is the problem. But you don't need to call that since you don't need write access to the CString's buffer. Pass *this to atof() and the compiler will insert a call to the LPCSTR converter for you.
Yes, but you can't tell the radio button is selected by looking at it (it loses the black circle indicating selection). You can access that information in code, but how does the user know what was previously selected?
Normally, its visual state (black circle) shouldn't be changed, too, except for dimming, of course. Normally means, at first, your radio button is in windows' standard RADIOBUTTON class (or its MFC counterpart, CButton).
It's possible that it may be an owner draw button or sub-classed one or even a complete custom control. if so, the problem may be with its drawing routine.
Sometimes, OS itself shows some strange behavior due to a sw./hw. problem (may be graphic card driver). I recommend to try it on another machine.
Although I think that this is standard behavior, (latest) windows version differences should also be considered (e.g. Windows7, Vista).
Last Visit: 31-Dec-99 18:00 Last Update: 26-Jul-16 0:19