Jump to content
  • Advertisement
Sign in to follow this  
CodyShort

C++ Classes Question

This topic is 2606 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've been coding on and off for about three years and I am making my first leap into graphics and games. I ran into a little problem with classes when I want to create an instance of a different class.
So for example I have class A and class B.


class A
{
}

class B
{
A instance;
}



How would I go about calling a constructor with parameters for instance? I hope you guys can understand what I am asking!
Thanks.
cb

Share this post


Link to post
Share on other sites
Advertisement

class B
{
public:
B() : instance(... parameters...)
{
}

private:
A instance;
};



And you can add more initialization separated with commas:

class B
{
public:
B() : instance(... parameters...), anotherMember(15.0f)
{
}

private:
A instance;
float anotherMember;
};


And of course, it can be done in the CPP as you would normally do.
header file:

class B
{
public:
B();

private:
A instance;
float anotherMember;
};

cpp file:

B::B() :
instance(...),
anotherMember(15.0f)
{
....
}

Share this post


Link to post
Share on other sites
I recommend using pointers to classes that are members, unless there is a restriction on doing such a thing (from a higher-up, from an API you're using that requires taking this class and accesses its members directly, etc).
Why? If you have a class C that derives from your class A and adds members, what then? The compiler has to perform some black-box magic, or make your code operate differently than you may expect by assuming no derived class is used. Neither is good, and may mean modifying dozens of sparse lines of code when it becomes an issue later on.

Share this post


Link to post
Share on other sites

I recommend using pointers to classes that are members, unless there is a restriction on doing such a thing (from a higher-up, from an API you're using that requires taking this class and accesses its members directly, etc).
Why? If you have a class C that derives from your class A and adds members, what then? The compiler has to perform some black-box magic, or make your code operate differently than you may expect by assuming no derived class is used. Neither is good, and may mean modifying dozens of sparse lines of code when it becomes an issue later on.

Use pointers where it is appropriate to use pointers. Not just because something is a "class."

Share this post


Link to post
Share on other sites

I recommend using pointers to classes that are members, unless there is a restriction on doing such a thing (from a higher-up, from an API you're using that requires taking this class and accesses its members directly, etc).

Actually, I think the usual advice would be the opposite of that: don't use pointers for members unless you have a compelling reason to do otherwise (in which case you'll most likely want to use a smart pointer of some kind).

Why? If you have a class C that derives from your class A and adds members, what then? The compiler has to perform some black-box magic, or make your code operate differently than you may expect by assuming no derived class is used. Neither is good, and may mean modifying dozens of sparse lines of code when it becomes an issue later on.[/quote]
I'm having some trouble following your example. Why would having a class C that derives from A be a problem? (Apologies if I'm overlooking the obvious.)

Share this post


Link to post
Share on other sites

Why? If you have a class C that derives from your class A and adds members, what then? The compiler has to perform some black-box magic, or make your code operate differently than you may expect by assuming no derived class is used. Neither is good, and may mean modifying dozens of sparse lines of code when it becomes an issue later on.

I'm having some trouble following your example. Why would having a class C that derives from A be a problem? (Apologies if I'm overlooking the obvious.)
[/quote]

I assume he's trying to talk about slicing.

Share this post


Link to post
Share on other sites
I tend to agree with @[color=#2B3730]nfries88. When a project gets very big, compile time becomes a big issue. By using pointers, you can use forward declaration. We should do that as much as possible, unless you do not have other choices to not use pointers.

Share this post


Link to post
Share on other sites

[quote name='jyk' timestamp='1303957270' post='4803806']
Why? If you have a class C that derives from your class A and adds members, what then? The compiler has to perform some black-box magic, or make your code operate differently than you may expect by assuming no derived class is used. Neither is good, and may mean modifying dozens of sparse lines of code when it becomes an issue later on.

I'm having some trouble following your example. Why would having a class C that derives from A be a problem? (Apologies if I'm overlooking the obvious.)
[/quote]

I assume he's trying to talk about slicing.
[/quote]

I'm not too familiar with compiler stuff, but I do have a sense of how they have to work. But thanks for teaching me the proper term.
As for using a pointer only when it makes sense to use a pointer, there's no reason to do it this way in C++. The encapsulation provided by a class allows you to take care of most of the occasions when it would need to be active. You won't need to store a persistent reference to something gotten from a member function very often, so things like smart pointers shouldn't be necessary.

Share this post


Link to post
Share on other sites

As for using a pointer only when it makes sense to use a pointer, there's no reason to do it this way in C++. The encapsulation provided by a class allows you to take care of most of the occasions when it would need to be active. You won't need to store a persistent reference to something gotten from a member function very often, so things like smart pointers shouldn't be necessary.

I'm not sure if we're all talking about the same thing here.

There are definitely plenty of reasons only to use pointers when necessary and appropriate in C++. In any case, this statement:

As for using a pointer only when it makes sense to use a pointer, there's no reason to do it this way in C++.[/quote]
Is a little confusing, because it seems to suggest that it's appropriate - and even desirable - to use a pointer specifically when it doesn't make sense :)

Let's say you have a class that has a member that's a 3-d geometric vector. You could do this:

class MyClass
{
Vector3 position;
};

Or this:

class MyClass
{
// Position is allocated dynamically at some point...
Vector3* position;
};

Now, I imagine you'd agree that the first example would be preferable, and would be the more common way to do it. If so, that should clearly demonstrate that you don't in fact always want to use pointers for members that are of class types, but rather that you only want to use pointers when it makes sense to do so.

The only real question remaining then is, when does it make sense to do so? That will depend on the developer, and on the context, but there will be plenty of cases (arguably) where you would not want to use a pointer. Just as an example, there'd be little point (that I can think of, at least) in storing a member of type std::vector using a pointer.

Naturally there are places where a pointer of some sort would be appropriate (where polymorphism is needed, Pimpl idiom, etc.), but to use a pointer where it's not needed just adds additional complexity for no particular gain.

As for smart pointers, the primary purpose of a smart pointer is to automate lifetime management and clean-up of a dynamically allocated resource. Proper use of smart pointers obviates the need for (non-compiler-generated) destructors in most cases, and simplifies code overall.

Again, based on your post above, I think maybe we're not all talking about the same thing here. Again though, I'd say that in C++ pointers should not be the 'default' choice, but rather should only be used when there's a specific reason to do so.

Share this post


Link to post
Share on other sites

[quote name='nfries88' timestamp='1304141118' post='4804656']
As for using a pointer only when it makes sense to use a pointer, there's no reason to do it this way in C++. The encapsulation provided by a class allows you to take care of most of the occasions when it would need to be active. You won't need to store a persistent reference to something gotten from a member function very often, so things like smart pointers shouldn't be necessary.

I'm not sure if we're all talking about the same thing here.

There are definitely plenty of reasons only to use pointers when necessary and appropriate in C++. In any case, this statement:

As for using a pointer only when it makes sense to use a pointer, there's no reason to do it this way in C++.[/quote]
Is a little confusing, because it seems to suggest that it's appropriate - and even desirable - to use a pointer specifically when it doesn't make sense :)

Let's say you have a class that has a member that's a 3-d geometric vector. You could do this:

class MyClass
{
Vector3 position;
};

Or this:

class MyClass
{
// Position is allocated dynamically at some point...
Vector3* position;
};

Now, I imagine you'd agree that the first example would be preferable, and would be the more common way to do it. If so, that should clearly demonstrate that you don't in fact always want to use pointers for members that are of class types, but rather that you only want to use pointers when it makes sense to do so.

The only real question remaining then is, when does it make sense to do so? That will depend on the developer, and on the context, but there will be plenty of cases (arguably) where you would not want to use a pointer. Just as an example, there'd be little point (that I can think of, at least) in storing a member of type std::vector using a pointer.

Naturally there are places where a pointer of some sort would be appropriate (where polymorphism is needed, Pimpl idiom, etc.), but to use a pointer where it's not needed just adds additional complexity for no particular gain.

As for smart pointers, the primary purpose of a smart pointer is to automate lifetime management and clean-up of a dynamically allocated resource. Proper use of smart pointers obviates the need for (non-compiler-generated) destructors in most cases, and simplifies code overall.

Again, based on your post above, I think maybe we're not all talking about the same thing here. Again though, I'd say that in C++ pointers should not be the 'default' choice, but rather should only be used when there's a specific reason to do so.
[/quote]
While I see your point (it is simpler to let the compiler allocate that memory for you behind the scenes), with common encapsulation techniques there isn't much point in doing it one way or the other besides the desire of the programmer.

So I guess the ultimate answer, based on responses from people clearly more knowledgeable than myself on the subject and also from some of my own experiences, is to do what you think is right for the situation.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!