Class constructor parameter question...

[Dersucher]

I feel like I should prolly know this.... And at one time I did...

But whats the difference between the various ways i've seen of passing parameters? e.g.

Weather::Weather(Ogre::SceneManager *sm)
Weather::Weather(Ogre::SceneManager* sm)
Weather::Weather(Ogre::SceneManager &sm)
Weather::Weather(Ogre::SceneManager& sm)

??

I apologize if this is an extreemly noobish question.. But for the life of me, i can't remember..

*curses VB.net*

[CaseyB]

Weather::Weather(Ogre::SceneManager *sm)
Weather::Weather(Ogre::SceneManager* sm)

These two are the same

Weather::Weather(Ogre::SceneManager &sm)
Weather::Weather(Ogre::SceneManager& sm)

and these two are the same.

They both hold the address in memory of the object that they are referencing. The difference is that an object that is "new"ed to get a pointer is created on the heap and will not go out of scope, an object that is just defined and you make a reference to is created on the local stack, so it can go out of scope. For example if you do something like this:

Code: Select all

Weather* getWeather()
{
    return new Weather();
}

then the Weather object will be created on the heap and will be valid when the pointer is used by the calling function. If you were to do this:

Code: Select all

Weather& getWeather()
{
    Weather myWeather;
    return myWeather;
}

Then myWeather will be created on the local stack and will go out of scope when the method returns and the reference passed to the calling function will be invalid.

[Dersucher]

Ahhh.. Yes... Horrid memories are returning.. Heap stack, local stack..

Thank you for your reply.

So using Ogre::SceneManager* sm or Ogre::SceneManager *sm either one has no difference?

[CaseyB]

So using Ogre::SceneManager* sm or Ogre::SceneManager *sm either one has no difference?

Nope, it's just a matter of preference.

[Dersucher]

Cool.. Many thanks..

One last question, then I will answer you these questions three.

Given what was previously stated, when you "New" something, does the same hold true?

Weather *wxSystem;
wxSystem = new Weather(mSceneMgr);

vs.

Weather* wxSystem;
wxSystem = new Weather(mSceneMgr);

[xavier]

Yes, the difference is only preference, as stated. Where the * shows up (what it's "attached" to) makes no difference to the compiler.

My personal preference has become the "Type* pVariable" style -- since the type of the identifier is a "Type*" it's easier to scan code and see what "pVariable" actually is. Much easier in class declarations where large spaces are employed between the identifier type and its name...for instance,

Code: Select all

class MyClass
{
private:
     int                    m_iVar;
     MyType*                m_pType;
     MyOtherType*           m_pOtherType;
     int                    m_iVar2;
};

I find much more readable than

Code: Select all

class MyClass
{
private:
     int                   m_iVar;
     MyType                *m_pType;
     MyOtherType           *m_pOtherType;
     int                   m_iVar2;
};

[Kojack]

Whitespace has virtually no meaning to C++. Apart from things like nested template parameters.
All the following are identical:

Code: Select all

Weather *wxSystem;

Weather* wxSystem;

Weather*wxSystem;

Weather * wxSystem;

Weather             *            wxSystem;

Weather 
      *
wxSystem;

I prefer the * with a space on the left, because it more closely matches the way c++ actually works. The * binds to the right when defining variables, so I put it closer to the thing on the right.

Code: Select all

int* a, b;

That looks like you have 2 int pointers, when really the * only applies to "a".

Code: Select all

int *a, b;

That shows how the * groups with variables better.

But the compiler doesn't care, and I don't like mixing pointers and non pointers in one line anyway. So it all comes down to personal preference.

[betajaen]

I prefer using the system where Weather* mxSystem indicates this class creates it, and Weather *mxSystem this class just uses it.

No different at all to the compiler, but it's very handy to it look very quickly.

[haffax]

betajaen, nifty trick to squeeze extra info in the source, but a bit non-standard, never heard of that one before, and the difference were lost on me.

I too like Type* var better than Type *var. While the latter is syntactically more to how C++ works (though this is a C legacy really), the former expresses the semantics better. var is of type Type*, instead of "if you dereference var, then the type is Type". True to, but weird..

[Protagonist]

I've seen the way betajaen places the * a fair bit I think.
I naturally fell into the habit of using Type *var in my parameter lists, and Type* var when declaring data members etc.
Makes sense to me.

[betajaen]

I've gotten in to the habit now of declaring arguments in classes as:

Code: Select all

class foo {
    void setDensity(float density, Body*);
};

I feel if I write "Body* body" I'm repeating myself, and Body* is just as semantic enough as Body* body. The float density is required because "float" isn't a description of what the argument is. But if the second argument wasn't there though, it would be.

When NxOgre 0.9 is released you'll see this weird system all over the place

[Protagonist]

Are you doing some funky things with what is meant to happen to your objects in their future or do you mean destination? .

Fair point though. I tend to repeat myself doing things like Hud *hud out of habit.

EDIT: Oops, misread density as destiny, haha. Oh dear, sorry.

[lXciD]

I'm a Type* var guy too. I like to keep things as consistent as possible. The reason why I choose that is because I was taught that way from start...

[Ajare]

But what about if you want to declare more than one pointer on the same line?

Code: Select all

int *x, *y, *z;

looks cleaner than

Code: Select all

int* x, *y, *z;

[haffax]

Happens so rarely, that it is not worth worrying about.