|
Now that is pretty interesting.
The following code
#include <iostream>
using namespace std;
class Foo
{
int a = b;
int b = 5;
public:
void show(){ cout << "a " << a << ", b " << b << endl;}
};
class Boo
{
int a;
int b;
public:
Boo(): a(b), b(5){}
void show(){ cout << "a " << a << ", b " << b << endl;}
};
class Goo
{
int a;
int b=5;
public:
Goo():a(b){}
void show(){ cout << "a " << a << ", b " << b << endl;}
};
int main()
{
Foo f;
f.show();
Boo b;
b.show();
Goo g;
g.show();
}
compiled with
g++ -Wall
issues NO warning and produces the following output on my Linux box
a 0, b 5
a 0, b 5
a 32766, b 5
The lesson I learnt (while waiting for more clever people to add insight) is "Timeo Danaos and C++ Default Initializers for class members".
|
|
|
|
|
I've tried online GDB because I don't trust VS to be 100% standards comform, and it does the same. (not sure how to set warning level though; but it's gcc, so I wouldn't expect a different result than you). Then I looked up order of initialization, and although there are pretty detailed descriptions on the order of initializations of the stuff mentioned in a constructor, I haven't found a hint on when a static initialization is taking place!
Btw.: interesting choice of names! You forgot Loo, though
P.S.:
While online GDB also does not offer a warning, it does generate a different result when run:
a 0, b 5
a 32764, b 5
a 0, b 5
I'm not sure what to make of this
P.P.S.: link to onlinegdb:
https://www.onlinegdb.com/online_c++_compiler[^]
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)
modified 13-Sep-19 4:24am.
|
|
|
|
|
Ok, I'll add some more mystery. Here's my take:
#include <iostream>
using namespace std;
class Loo
{
public:
static int x;
static int y;
static int z;
int a;
int b = ++y;
int c;
Loo() : a(++x), c(b+(++z)) {}
Loo(int i) : a(++b), b(++i), c(++b) {}
void show(){ cout << "a " << a << ", b " << b << ", c " << c << endl;}
static void show_(){ cout << "x " << x << ", y " << y << ", z " << z << endl;}
};
int Loo::x = 0;
int Loo::y = 0;
int Loo::z = 0;
int main()
{
Loo::show_();
Loo l;
l.show();
Loo::show_();
Loo l5(5);
l5.show();
Loo::show_();
return 0;
} And the output I get is:
x 0, y 0, z 0
a 1, b 1, c 2
x 1, y 1, z 1
a 1, b 7, c 7
x 1, y 1, z 1 The first two lines are unspectactular: they show what can be expected from the code.
The third line is also unsurprising. Importantly, it shows that the member initialization of b was invoked by the default constructor (y=1).
The fourth line however is very odd: It starts with a=1. How? Let's take apart the commonly known rules on initilization order: the initializer list gets processed left to right for all virtual base classes, than all base classes, then all members. We only have members, so initialization order is a, then b, then c.
Next, according to this site Non-static data members - cppreference.com[^] the non-static member initialization of b gets skipped, because b is on the initalizer list. This means, b is not initialized at all by the time a is getting initialized! Note that y remains unchanged, proving that the member initializer is not invoked! Therefore the value assigned to a is undefined. As it seems, in this case b assumes a value of 0, incremented to 1, and then assigned to a.
Next, b gets initialized. It's value is based on i, which is 5, so the value of b should be 6. The output shows 7 - but let's look further: we still have to initialize c, which again is based b, incrementing it. Therefore b is now 7, and c too.
Ok, all is well, except that the value of a is undefined, even though b appears to be initialized in two places! Only that one initialization is skipped because of the other that is happening too late
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'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?
|
|
|
|
|