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.