Is there any speed gains using pointers instead of references? I am used to java way of doing things and I am wondering if referencing wastes more resources.
Nope, internally they are the same. The different is you cannot reassign references, i.e. they are a bit more limited but generally easier to use because they point to existing allocated memory.
Unfortunately you cannot get exact Java style syntax in C/C++. References in C++ are close, but not exactly the same. You cannot use the ‘new’ operator to allocate an object for a reference (unless you do so on the same line as the declaration, but ignore that for now). References in C++ have to point to something. They cannot be uninitialized - so they are safer, you’re never gonna get a null or uninitialized reference. Pointers can be assigned later, so they are more flexible, you can create the object whenever you want. So you have more control over memory usage and you can pass parameters to its constructor. But the downside is you have to check for and handle uninitialized or null pointers and crashes. They both get compiled to the same code though, so performance is the same, its just compile time checking which differs.
The code you want is:
Particle *p; // this needs to be a pointer, because you want to call 'new' and create it passing parameters to its constructor.
ofxVec2f loc = ofxVec2f(0,0);
ofxVec2f vel = ofxVec2f(0,0);
ofxVec2f acc = ofxVec2f(0,0);
float r = 10;
p = new Particle(loc, vel, acc);
// no matching function call to "Particle::Particle(ofxVec2f&,....)
Particle(ofxVec2f &l, ofxVec2f &v, ofxVec2f &c); // define these as references, not pointers
ofxVec2f loc; // define these as objects, not pointers
Particle::Particle(ofxVec2f& _loc, ofxVec2f& _vel, ofxVec2f& _acc) // reference, not pointer
loc = _loc; // the objects are copied over
vel = _vel;
acc = _acc;
In the constructor, _loc is the object, not the address, so the whole object will be copied over to loc when we do loc=_loc. which is good, because the object being passed in is a local variable and will be destroyed once the testApp::setup() function finishes. if Particle::loc was pointing to it, it would be garbage after the function ends.
The reason we have ofxVec2f& _loc in the Particle::Particle header and not just ofxVec2f _loc, is to pass the object by reference so only its address is passed, BUT _loc still refers to the object not the address. This is quicker because we dont have to do two copies (once from the temp local variable in testApp::setup() into the temp function parameter stack, and once again from the temp function parameter stack into Particle::loc)
I just read what I wrote, and it sounds quite confusing… so I hope I havent just confused you even more there are so many ways of doing this…
In this case, I would actually advise against pointers altogether (for simplicity sake, not that theres anything wrong with using pointers). You can give Particle an init(ofxVec2f &l, ofxVec2f &v, ofxVec2f &c) function, and call that instead of new Particle(). It is safe, will run equally fast (actually, will run an incy wincy fraction of a nanosecond faster because calling particle.doSomething() is an incy wincy fraction of a nanosecond faster than particle->doSomething()). So you don’t need any pointers or references at all. The only thing you should pay attention to, is pass objects by reference in function parameters. So instead of defining a function as :
init(ofxVec2f l, ofxVec2f v, ofxVec2f c); // this will copy the whole object onto the stack - slow!
init(ofxVec2f &l, ofxVec2f &v, ofxVec2f &c); // this will pass the objects address, but inside the function l, v, c will appear as objects, not pointers. Like Java.