A quick Ogre C++ API reading translation tip if you are a noob

http://www.ogre3d.org/docs/api/1.9/

So if you were wanting to understand reading a C++ api and understanding how to invoke say class method calls say from class pointer objects or class objects, I'll provide a little reading translation help here.

Firstly in C++ if you weren't already familiarized relative other Object oriented programming languages you'd notice the '->' being featured for method calls.   Obviously you learn after the first or second crash day of C++ that this '->' call is like the '.' call for invoking a call to class method or in particular a class pointer object.  Thus if having instantiated a class pointer object say

Ogre::TerrainGroup* mTerrainGroup;

Where Ogre::TerrainGroup* is a pointer object to Ogre::TerrainGroup

Anytime a pointer object is instantiated class pointer object invocations are done with '->' as opposed to '.'
Otherwise if it were possible to declare and instantiate

Ogre::TerrainGroup mTerrainGroup;

where mTerrainGroup were a Ogre::TerrainGroup object we'd use a '.' after such object in referencing its method/function call.

Often times when referencing say the Ogre API for methods of a given class object, we can see the method call given in a given addressing format...

thus

void Ogre::Terrain::getPoint	(	long	x,
		long	y,
		Vector3 *	outpos
	)		const

the first token 'void' is the return type of the function call here.

the second and third token bridged by '::' references the Ogre addressing namespace alongside the class object type which is a 'Terrain' object.  Often times when you are declaring a new Ogre object, you'd typically have some referencing like 'Ogre::ogre_object_name    yourobjnamehere;'

Sometimes you'll see return types other than 'void' as indicated above returned where you can store such return object and neither having to supply some output object (in the above case it is a 'Ogre::Vector3*'  object that is required so that the method can provide a given point output to this object).

The fourth token 'getPoint' is the method name of the 'Ogre::Terrain' object...
according to ordering principles, you'd likely find method names are always delimited to the right by the '(' parentheses token.

Returning back to the example above, also if I have a given Ogre::Terrain object instantiated or a object pointer then I can reference method calls to such object by using the '.' or '->' followed by the method name

thus an object

Ogre::Terrain cterrain;
Ogre::Vector3 outputvec;

would have a method call to getPoint() as

cterrain.getPoint(0,0,&outputvec);

or

Ogre::Terrain* cterrain;
Ogre::Vector3 outputvec;
as

cterrain->getPoint(0,0,&outputvec);

Another common feature found are overloaded constructors for a given object, read through these since there may be many different ways to instantiate a given Ogre object using any variation of Ogre objects or whatever necessary to instantiate the given object.  Basically if you weren't familiar with overloading, overloading say could be as simple as allowing you to do addition on two number objects say even if they were floats or doubles, Ogre::Real and so forth so that you hadn't need worry about having a specific object type to instantiate or invoke the class object or method, or in other words less work tracking and type cast converting an object from one type to another in order to instantiate a given object type (through object constructor overloading).  Another example, An Ogre::Vector has 6 different instantiation constructors, or there are six different ways to declare and instance an Ogre::Vector (outside of pointers and anything else).

Also read through required supplied parameters/objects required to get an object up and running or invoking a given object method.

I always recommend a thorough reading of any API concerning a given Object type since outside of code recipes since this can give you a more thorough working knowledge on implementing structures or using fully the tools that such object provides so that you hadn't need do added legwork either re inventing structures by added work or anything else.