|
I've found a site that explains a lot of rules and restrictions regarding non-static member initialization, but it didn't seem to contain any info on the initialization order : Non-static data members - cppreference.com[^]
IMHO, given all the implications with special cases and dependencies, I don't think it's worth the hassle using this feature, unless you have a very good reason to use it. Especially if you can't rely on the compiler to catch potentially incorrect usage!
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)
|
|
|
|
|
I am trying to create ListCtrl where it display data and when I select a row (Single row at a time not multiple) in the ListCtrl , it takes me to another dialog where i can edit this selected data which will reflect in the ListCtrl.
Please suggest me some way to tackle this.
Thank you.
P.s. I am new to MFC VC++.
|
|
|
|
|
|
Thank you for the quick reply. 
I know how to navigate from dialog to dialog ,this is where I am getting confused - "How do I select a row in the List control?"
Thanks again
|
|
|
|
|
|
|
Have you looked at the NM_CLICK notification code?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
с++ compiler
Hello colleagues.
There is one task, and I think how to implement it more correctly and faster.
In general terms, transfer many different binary data to 1 server.
There is an iocp asynchronous server that receives data from clients.
Then this processed data is converted and added to the queue packets.
There can be many such packets per second (300 - 1000).
Asynchronous processing parses this queue, and the data in each packet in the queue
should be given over TCP / IP to another server. I do not want to create an additional stream for the client per packet from queue parsing. Is there any quick fix?
packets of
queue :
1 ->to 127.0.0.1 3615
2 ->to 127.0.0.1 3615
3 ->to 127.0.0.1 3615
4 ->to 127.0.0.1 3615
5 ->to 127.0.0.1 3615
6 ->to 127.0.0.1 3615
7 ->to 127.0.0.1 3615
8 ->to 127.0.0.1 3615
9 ->to 127.0.0.1 3615
..
..
Thank you.
|
|
|
|
|
I wanted to clarify.
When the packet went to the server, we expect a response from it.
Once the correct answer is received, the packet is removed from the queue.
The faster the queue is empty, the faster the other server will receive the packets.
|
|
|
|
|
I'm confused:
1. TCP/IP already takes care of packet delivery; it makes sure it arrives, and if it doesn't, it gets resent. Why implement another queue on top of that? That just creates more traffic, and you made a point you want to avoid that.
2. You said something about asynchronous processing, but if you implement a queue as you said, it enforces synchronization! So what do you want? Synchronized or not?
That said, I have no experience in programming this kind of stuff, I only know the theory. But maybe there's something to the many things people say about theory and practice http://wiki.c2.com/?QuotesOnTheoryVsPractice[^] 
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)
|
|
|
|
|
I implemented a small C++ app that reads the memory of a video game. My aim is to create a small cheat for the single-player game. I am reading the memory of a video game from another process. There is a linked list that I am trying to read in the game's memory. I am following a pointer chain to follow the linked list. These pointers point to next element in the linked list. Each time I read the pointer's address, it is something different.
Why are the virtual addresses of the pointers always different when I read them?
|
|
|
|
|
Rakanoth wrote: Why are the virtual addresses of the pointers always different when I read them?
To stop you hacking their game.
|
|
|
|
|
Why? I am not cheating in online games.
|
|
|
|
|
Quote: My aim is to create a small cheat for the single-player game.
Still cheating.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I was expecting a technical explanation. Would you please give me some technical explanation about how it changes?
|
|
|
|
|
Why would you expect them to remain the same in a game that is running?
I have no idea what game you are trying to cheat, but you are reading the memory of a different process, so it will get run, stopped, loaded, unloaded, cached, paged to disk, and generally have a hard life - all at the whim of the operating system. Add in that the game itself will probably be moving stuff around as it runs to suit itself, and the chances of you finding exactly what you want without the source code to work form is very unlikely. And that is assuming that you have identified the actual linked list, rather than some stack based object that temporarily looked like an element that might be on a linked list, if the code actually used one.
So why would you expect everything to stay in the same place for your convenience? 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
If you have to ask this, then I doubt that the address you're reading is what you think it is. Not to mention what it points to. Every process uses it's own mapping from it's address space to the underlying physical addresses, and the system functions take care that each address used within a process is mapped accordingly: to some location within the momry space that is associated to this, and only this, process!
Consequently, a process can never access memory from another process, unless the two processes are set up specifically for that purpose: the only way I know to read memory from another process is setting up shared memory. And I doubt that your game allows this.
Take this with a grain of salt and a big AFAIK - I'm anything but a specialist on this topic
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)
|
|
|
|
|
I'm new to MFC VC++ and trying to create a dialog base simple MFC application that display the data contains in MySQL database. Please guide me through this.
Thank you.
|
|
|
|
|
You can find here[^] a project sample of how to connect to MySQL database through ODBC ... in fact, to any kind of dababase through ODBC.
|
|
|
|
|
Thank you.
Could you please suggest me a good book for MFC vc++.
|
|
|
|
|
|
Thanks for the help!
I'am having trouble understanding why it does this
BOOL CMyApp::InitInstance(){
..........
..........
CWinApp::InitInsatnce();
..........
..........
}
Could you please explain why do we need to call two InitInstance() and what is the main reason?
|
|
|
|
|
When you derive from a class and override one of its methods, it's common, and sometimes required, to call the base class implementation.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Thanks for the reply.
If you don't mind, could you please elaborate the "sometime required, to call the base class implementation" part with some example.
|
|
|
|
|
CMyApp is derived from CWinApp, so the line
CWinApp::InitInsatnce();
simply call the InitInstance method from parent CWinApp, which is the base implementation of CMyApp::InitInstance().
"sometime required" sometime is necesarry to call this base implementation, sometime not
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
