|
thanks for fast reply
but
for _T("Message Box Title -- Hello World")
error C3861: '_T': identifier not found
for L"Message Box Title -- Hello World"
same error C2664
|
|
|
|
|
sorry friends
L is ok.
It works.Thank you.
But _T macro can not find it says.
How can i tell compiler to see this macro.I opened only empty win. application.
Thanks again.
Edit/Delete Message
|
|
|
|
|
|
thanks friends
TEXT() is working; also for _T macro #include <tchar.h> is solve the problem.
|
|
|
|
|
sawerr wrote: But _T macro can not find it says.
What does this mean? _T() macro is defined in tchar.h; But again finally expands to L""
|
|
|
|
|
what type of project u r using?
|
|
|
|
|
hi all,
i am having doubt in Socket Programming, What is the need of select(...) Api in Socket. Please give me a neat explation of what the select(...) Api do in Socket and where we can apply this Api.
Also i want the Difference between Blocking and NonBlocking Sockets.
please help me out.
Uday kiran
|
|
|
|
|
uday kiran janaswamy wrote: need of select(...) Api in Socket.
If an application is using several sockets then the select() function may be used to find out which ones are active.
uday kiran janaswamy wrote: Also i want the Difference between Blocking and NonBlocking Sockets.
See here. You will get a lot of information relating to blocking and non-blocking sockets.
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
|
|
|
|
|
hi all,
i want the difference of heap and stack in memory related area.
also when you populate the CDialog i am having doubt.
CDialog d; ---> First
d.DoModel();
CDialog *d = new CDialog; ---->Second
d->DoModel();
both First and Second will populate the Dialog but can i know what is the difference of the First and Second Memory Concept.
please let me know.
Uday kiran
|
|
|
|
|
uday kiran janaswamy wrote: difference of heap and stack in memory related area
It's a difference of access memory (the hardware of the memory). The stack is much faster than the heap, but smaller and more expensive. primitives are place in the stack, but objects on the heap.
uday kiran janaswamy wrote:
CDialog d; ---> First
d.DoModel();
Object is created on the stack. No chances for memory leak but the amount of memory on the stack is small and the store can get exhausted.
uday kiran janaswamy wrote: CDialog *d = new CDialog; ---->Second
d->DoModel();
Object is created on heap.
While allocating memory on the heap you are responsible for deallocating memory. Each byte of memory that's being assigned/used should be returned back to the heap after it's task is done or else there is a problem that is known as Memory Leak.
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
_AnShUmAn_ wrote: It's a difference of access memory (the hardware of the memory). The stack is much faster than the heap, but smaller and more expensive. primitives are place in the stack, but objects on the heap.
Really? I always thought memory was memory!
Using the stack is generally faster than the heap, since you don't have the overhead of managing a pool of memory. Individual allocations of stack memory cannot be freed, since it's done on a 'frame' basis, and everything in the current frame is cleaned up (albeit sequentially).
In the snippet
CDialog d;
the object itself is stack-based, and will automatically have it's destructor called when the function returns (as the object will go out of scope).
In the snippet
CDialog* d = new CDialog;
the variable is stack-based, but the object itself is on the heap. When the function completes, the variable that refers to the object goes out of scope, but the object still exists, as you say. It will not have a destructor called automatically.
There is, AFAICR, nothing which forces primitives to live on the stack, and force objects to be allocated on the heap. Usually the developer decides, particularly in the situation of developing for Windows, where UI objects need to exist beyond the lifetime of a function.
Steve S
Developer for hire
|
|
|
|
|
hi steve,
i understand the concept of stack and heap i am very thankfull to you to give a nice example.
Uday kiran
|
|
|
|
|
Steve S wrote: I always thought memory was memory!
In a computer there is only one variable storage area, the main computer RAM. But, for the purpose of organization and performance, it is divided into several areas.
When you C/C++ program is started, memory is requested to the operating system to create the heap and the stack.
Both these memory areas use what we could call the heap (not the stack). They are accessed by dereferencing pointers, like in the code below:
struct S {
int x;
int y;
int z;
};
int main(void) {
S* var_s;
var_s=new S;
if (!var_s) return __LINE__;
var_s->y=20;
}
In this code, the structure S will have a total of 12 bytes (in Win32), because each integer takes 4 bytes. The new will return some relatively unpredictable address in memory, which is not that important. The only important value to check for is zero, which means the requested memory is not available (that's why the "if" statement is there).
When your program starts, another area of memory is allocated, the stack. This memory is just like any other, but it is considered must more volatile, and besides it is also used where to go to when functions terminate. The stack is considered to be memory like "remember this for a moment while I do something else, and then I will get back to this".
1) The address of the variable var_s is always known by using the stack pointer, which is a physical register of the processor.
2) The stack is very dense. Everything is packed together, and only the memory area after the stack pointer is free. Everything else from the start of the stack up to the stack pointer is densely occupied.
3) All the relative addresses of things stored in the stack are predictable. For example, while inside main, the return address could also be known, independently from where your program came from, by reading memory addresses 5000 to 5003 (4 bytes before the address of var_s). In reality, when main begins there is more stuff added to the stack which makes the var_s ocuppy addresses further from the main return address, but still it is possible to check all variables and function return addresses by navigating through the stack.
4) Although everything is accessible in the stack, by navigating in it, new things can be memorized only after previously memorized things. The stack can contain no holes, and that is the main diference to the heap. So, only the most recent things can be forgotten go release memory for new things. This means that you cannot forget the address o contents 5000 and used for storing other things, unless you forget about var_s first.
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
You aren't telling me anything I didn't already know (I've programmed in 6502, Z80, MC68000 and 80x86 assembly language).
My point was that stack memory isn't physically faster per se than the heap, since it's all stored in the same stuff (although cache hits on the stack region are more likely to succeed).
Sure, a stack allocation is much faster, since you don't have to worry about maintaining coherence or multiple threads running parallel allocation/deallocation, and deallocation is likewise easier. That's why stack-based variables are/were referred to in Kernighan and Ritchie as 'auto' or 'automatic' variables. Space is automatically allocated and deallocated on request.
You do make the point, of course, that the stack isn't limitless, and a couple of questions I've seen posted on CP were resolved by changing to use dynamic rather than automatically allocated variables. However, I felt that the comment on speed was likely to confuse the OP, and lead them away from the facts...
Steve S
Developer for hire
|
|
|
|
|
Thanks for the information Steve. I got to know a few more things through this thread.
Thanks once again....
Somethings seem HARD to do, until we know how to do them.
_AnShUmAn_
|
|
|
|
|
hi everyone,
I am doing the unicode version of the project. The function of DragQueryFile(API) work well,but in the version of unicode, it is different from the version fo ansi, when I use this windows API, first it should return the count of file I have dragged, and I can get the path of each file, but it is not this, in the uncode vesion the value it return is likely the length of the file path, and when I get the path, I doesn't return the path in whole, It return the first character of the path.
for example, in ansi the value returned is 1(the count of file),"c:\test\li.txt"(file path) and in unicode the value returned the length of the path("c:\test\li.txt") and "c"(the path first character).
I am confusing about it long time. Is there anyone who has some thought about it, can tell me .
thanks advance.
lijie.
|
|
|
|
|
You're seeing just "c" because you're treating the string as if it were an MBCS string. The first two bytes are 63 00 (the UTF-16 encoding of 'c').
|
|
|
|
|
First thanks a lot,
but why ,why return the only first character, in the ansi version it can return the path of the file. And I have write a project in the unicode vesion use the function DragQueryFile it can return the path, and the count of the files which is dragged cann't return in the unicode vesion .
|
|
|
|
|
i am developing a user interface using windows forms in a vc++.net
environment. i have a database(ms-sql) which contains the necessary data for
displaying in a my datagrid.
how to create the setup in order to have the database in it. i wish to my application be installed to other machines wich don't have ms sql server and i would want the datagrid to display the data items after instalation
thanx in advance
|
|
|
|
|
Do you want to make setup for your program?
|
|
|
|
|
yes.
i need a setup in order to make my application available to eny workstation but without beeing necesary to instal sql server to those machines
|
|
|
|
|
|
I have class CMySock derived from CAsyncSocket and that class has a member as
CMySock *pSock;
CMySock's object is created and kept in listen mode.When a connection reqest comes and CMySock's OnAccept() is called. There I want to connect to another system with pSock. and my code for that is
if(!(m_pSrcClientSocket->m_pDestClientSocket)->Create())<br />
{<br />
MessageBox("Falied to create a socket");<br />
}<br />
else<br />
{<br />
if(!(m_pSrcClientSocket->m_pDestClientSocket)->Connect(rs.GetAt(0),port))<br />
{
<br />
int err = GetLastError();<br />
MessageBox("Failed to connect to Connect");<br />
}<br />
else<br />
{<br />
}<br />
}
if the pointer is of CSocket instead of CMySock its connecting well.
I want to user CMySock only.
How to overcome this problem. Please help.
Thank you
KIRAN PINJARLA
|
|
|
|
|
Hi,
why would you connect to another system at function OnAccept()?
CMySock::OnAccept()
{
CMyClientSock *NewClientSock = new CMyClientSock();
Accept( NewClientSock, NULL, NULL );
//--> now the NewClientSock object is connected to the new incoming connection, you don't need construct / connect any object.
}
HTH
Frank
|
|
|
|
|
i write once class called IOCP, derive two class called downIOCP(serve terminal), and upIOCP(serve up-station) another.
so, when data from terminal to downIOCP and it shoud be transfer to up-server station , the downIOCP PostQueuedCompletionStatus() to upIOCP to let it WSASend() data to up-station.
are there some problem such as accessing buffer mutexly ?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
