|
MsmVc wrote: How can i use debugger?Plz help me
For the sake of God, please buy a beginners book on programming.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
i have 3 projects included in my work space.when i release build them one of the projects cause link error 1257 code generation failed.No error comes in debug build.how can i remove the error in release build.
|
|
|
|
|
|
thanx it helped a little bit but dont tell how to overcome the problem.so the problem persists.
|
|
|
|
|
explain how far the problem is solved.
ali kanju wrote: helped a little bit
that statment is a little vague.
|
|
|
|
|
i mean it tells that it may be a linker problem...bt dont exactly tells how to overcome the problem..i have visual studio 2005 in use..
|
|
|
|
|
hi all,
people may feel that the question what i ask is very basic but guess what i didnt found the right answer for this
thats the reason i am posting here so please help me...
1. when we allocate 50bytes of memory via malloc or new
and while using free or delete[] on this variable how does it knows to delete all those 50 blocks.....
2.
<br />
int i = 10;<br />
int &a = i;<br />
a = 30;<br />
how does compiler knows that it need to change the value of i to 30.
please help me.......
|
|
|
|
|
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.
2. a is a reference to the variable i.
Even though references were introduced in C++, internally it is still implemented as a pointer.
So int &a = i; means pointer a that holds the address of variable i.
a = 30; means put the value 30 into the address where a is pointing to.
Since i is the variable assigned to that address, its value becomes 30.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
«_Superman_» wrote: So int &a = i; means pointer a that holds the address of variable i
I doubt. I think reference is not a pointer, it is the object. See here[^].
|
|
|
|
|
Reference is not a pointer as far as the compiler is concerned.
After the compiler processes it, it is very similar to how a pointer is.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
N a v a n e e t h wrote: I think reference is not a pointer, it is the object
C++ references are implemented as a pointer - trust me 
The only real differences between references and pointers are the syntax (. rather than ->) and the fact that it's very difficult to get a null reference - the language does it's best to ensure that.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Stuart Dootson wrote: C++ references are implemented as a pointer - trust me
Are you saying it is implemented as pointers behind the scenes? I have checked GCC's documentation and other pages. But couldn't find how they implemented it.
AFAIK, C++ standard doesn't tell anything about how a compiler should implement references. A pointer has a memory address and it's own space on the stack whereas a reference share the same address of the original variable. Also the statements in FAQ[^] and whatever you said is not matching (see the Important note specially). Or am I missing something here?
|
|
|
|
|
N a v a n e e t h wrote: Are you saying it is implemented as pointers behind the scenes
Yep - consider this C++ code - two equivalent functions, one using a pointer, the other a reference.
void Add1(int* pInt, int x)
{
*pInt += x;
}
void Add2(int& rInt, int x)
{
rInt += x;
}
I compiled this with cl -FAcs -c -O2 and got this assembly language (irrelevant bits snipped):
PUBLIC ?Add1@@YAXPAHH@Z ; Add1
_TEXT SEGMENT
_pInt$ = 8 ; size = 4
_x$ = 12 ; size = 4
?Add1@@YAXPAHH@Z PROC ; Add1, COMDAT
; 3 : *pInt += x;
00000 8b 44 24 04 mov eax, DWORD PTR _pInt$[esp-4]
00004 8b 4c 24 08 mov ecx, DWORD PTR _x$[esp-4]
00008 01 08 add DWORD PTR [eax], ecx
; 4 : }
0000a c3 ret 0
?Add1@@YAXPAHH@Z ENDP ; Add1
_TEXT ENDS
PUBLIC ?Add2@@YAXAAHH@Z ; Add2
_TEXT SEGMENT
_rInt$ = 8 ; size = 4
_x$ = 12 ; size = 4
?Add2@@YAXAAHH@Z PROC ; Add2, COMDAT
; 8 : rInt += x;
00000 8b 44 24 04 mov eax, DWORD PTR _rInt$[esp-4]
00004 8b 4c 24 08 mov ecx, DWORD PTR _x$[esp-4]
00008 01 08 add DWORD PTR [eax], ecx
; 9 : }
0000a c3 ret 0
?Add2@@YAXAAHH@Z ENDP ; Add2
_TEXT ENDS
END
Exactly the same code for each.
The Wikipedia page on C++ references[^] says it quite nicely - ...the typical implementation...effectively compiles references into pointers which are implicitly dereferenced at each use. Basically, references are (from most C++ programmers PoV) pretty much just syntactic sugar[^] for pointers.
PS - here's the gcc assembly language for that C++ code - again, the two functions are implemented exactly the same.
.globl __Z4Add1Pii
.def __Z4Add1Pii; .scl 2; .type 32; .endef
__Z4Add1Pii:
LFB2:
pushl %ebp
LCFI0:
movl %esp, %ebp
LCFI1:
movl 8(%ebp), %edx
movl 12(%ebp), %eax
addl %eax, (%edx)
popl %ebp
ret
LFE2:
.align 2
.p2align 4,,15
.globl __Z4Add2Rii
.def __Z4Add2Rii; .scl 2; .type 32; .endef
__Z4Add2Rii:
LFB3:
pushl %ebp
LCFI2:
movl %esp, %ebp
LCFI3:
movl 8(%ebp), %edx
movl 12(%ebp), %eax
addl %eax, (%edx)
popl %ebp
ret
LFE3:
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
WOW! That's food for thought. Thanks. Let me investigate further on this.
|
|
|
|
|
Hi Stuart and Navaneeth,
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.
Best Wishes,
-David Delaune
|
|
|
|
|
hawk23reddy wrote: how does compiler knows that it need to change the value of i to 30.
Quoting C++ FAQ Lite[^]
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[4];
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.
Hope this explanation will answer your question.
|
|
|
|
|
Well I am doing image processing application wherein I need to decompress any image format(preferably .JPEG or .TIFF) into raw or .bmp...That is I want to extract the compressed image using C++.
Can any one please assist me on this...
|
|
|
|
|
You can use GDI+ to do this.
Use the Image class to load the .JPEG file.
Image img(L"image.jpg", ...
Call the Save method to convert it to .bmp
CLSID encoderClsid;
GetEncoderClsid(L"image/bmp", &encoderClsid);
img.Save(L"image.bmp, &encoderClsid, ...
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
|
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?
Thanks.
|
|
|
|
|
You shouldn't have to worry about that. Use one of the StrRetTo* functions in shlwapi.
--Mike--
|
|
|
|
|
uOffset is declared as UINT (unsigned int). So it is not a string.
The only string in the union is pOleStr and it is declared as LPWSTR (pointer to unicode string).
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.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
|
«_Superman_» wrote: 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.
«_Superman_» wrote: 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.
|
|
|
|
|
In that case, the string is a unicode string.
«_Superman_»
I love work. It gives me something to do between weekends.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
