This should help with getting started with C++ http://www.cplusplus.com/doc/tutorial/

I just want to note that these pretty old tutorials are not the best for learning modern C++. I think the only way to learn modern C++ is to read a book or two, or experiment a lot and learn from different sources on the internet.

For the graphics library, I recommend SFML. It's a complete package, including networking, written in modern C++. SDL, on the other hand, is a C library and is not a good example of C++ OOP.

What I am looking for is a guide for code styling, project structure and modern C++ usage.

This is one of the disadvantages of C++ in my opinion, there isn't really a standard coding style that's being used by everyone. You could choose for the standard library coding style, but there are a lot of other coding styles out there.

For project structures this is the case too, it's relatively a lot more complicated compared to Java, but you will get used to it. There isn't however a 'best' way to do it. Especially since there are many different IDE's, compilers and operating systems out there that support C++. Using your IDE's project files will be enough for all your own projects. If you want to collaborate however, I recommend learning to use VCS like Git (VCS is never a bad idea, whatever language you choose) and using CMake (just google it if you're interested).

When you've learned the basics of C++, for example using the link posted above, you should learn more about C++11. The creator of C++ still has a lot of good resources, also on C++11, on his site (a bit long but very useful). The design patterns you learned using Java should for a large part be the same with C++. C++ however misses the kind of RTTI Java supports.

For 1) the equivalent of POJO is POD - where you make a struct where all the members are public, and all the members are either primitive types, raw pointers, or other POD types.

If every member has a getter/setter, then they may as well just be public.

Although they can be used equivalently there are differences. If you add a set-method you can include error-handling and polymorphism which can help you maintain correct behavior.

For example:
you have a class Player and a member called health. If you use a set-method you can also implement something like:

void Player::setHealth(int x) {
  if (x < (maxhealth /4) && x > 0) {
    Player::yell("I need a medic!");
  }
  if (x <= 0) {
    Player::setState(DEAD);
  }
  health = x;
}

Of course right now you would probably implement stuff like this in a method like "registerDamage" and this would probably make more sense but if you design a set-method from begin with you are more flexible to changes. You could also check for a negative number and add a line to your log that something went wrong.

Another advantage of using set-methods is that you can easily implement conceptional future changes. For example if you decide later on that max health should be 99 instead of originally planned 9999, you simply have to add a /100 here and it's all set. Otherwise you'd have to go through your code and modify every occurence where the variable was changed from the outside.

There's nothing evil about getters and setters. However, the C++ community is a bit more lax on when to use them. To a typical C++ programmer, there's no reason to make a setter and getter if all they do is modify and return -- public variables are perfectly fine. Sure, there's justifiable reasons why you may want to add that abstraction layer (typically, "you might want to change the behavior later") but it's really not that important.

However, Hodgman is very right when he says that lots of getters and setters are a bad sign. An object in general should either contain a bunch of information for other objects to use or it should do something. If you find your objects typically do both, you might want to take another look at your architecture. This applies to C++ and Java equally.

As for good C++ style, it's a little hard to gauge sometimes. C++ works in several different "levels". There's the embedded stuff, and there's stuff going up all the way to Javaland, and the C++ in different levels tends to look different. Raw pointers for example tend to be everywhere in embedded code, while best practice (rightly) says you should be using them very sparingly in every other domain.

I don't know any good resources for the stuff (though someone mentioned Herb Sutter's blog above -- he's a good resource for C++ stuff in general) but the sorts of things you should be looking for in a mid-level domain are things like:

Smart Pointers

RAII

Templates (more specifically, the standard library containers like vector -- arrays should be used fairly sparingly)

Lambdas (maybe, more specifically "not function pointers")

In general, if you see C++ that looks like C, it's either written at a very low level of abstraction or it's bad.