Skip to main content
updated links now that unique_ptr and shared_ptr are part of the standard library
Source Link

In this case, storing a vector of Animal would not work for you, as your animals have different sizes, and you wouldn't be able to store the derived objects in the spaces intended to hold the base class. (And even if they're the same size, you won't get the intended polymorphic effect, as base class methods will be executed - the virtualness of a method doesn't come into play unless you access it through a pointer or reference.)

If you want to avoid the annoyance of managing the memory yourself, you could consider storing a smart pointer such as a shared_ptr (note thatunique_ptr or auto_ptr doesn't work with STL containers, according to Max Lybbert)shared_ptr, or some variant thereof. That way you can still use your polymorphic class, but it's a little less work for you.

There's no real hard and fast rules about when to use objects and pointers, although it's worth noting that in some cases, like yours, objects just aren't going to work for you. I tend to use objects whenever nothing precludes it though, although you do have to be concerned about expensive copy operations as you note (although sometimes they can be ameliorated by passing containers by reference).

In this case, storing a vector of Animal would not work for you, as your animals have different sizes, and you wouldn't be able to store the derived objects in the spaces intended to hold the base class. (And even if they're the same size, you won't get the intended polymorphic effect, as base class methods will be executed - the virtualness of a method doesn't come into play unless you access it through a pointer or reference.)

If you want to avoid the annoyance of managing the memory yourself, you could consider storing a smart pointer such as a shared_ptr (note that auto_ptr doesn't work with STL containers, according to Max Lybbert), or some variant thereof. That way you can still use your polymorphic class, but it's a little less work for you.

There's no real hard and fast rules about when to use objects and pointers, although it's worth noting that in some cases, like yours, objects just aren't going to work for you. I tend to use objects whenever nothing precludes it though, although you do have to be concerned about expensive copy operations as you note (although sometimes they can be ameliorated by passing containers by reference).

In this case, storing a vector of Animal would not work for you, as your animals have different sizes, and you wouldn't be able to store the derived objects in the spaces intended to hold the base class. (And even if they're the same size, you won't get the intended polymorphic effect, as base class methods will be executed - the virtualness of a method doesn't come into play unless you access it through a pointer or reference.)

If you want to avoid the annoyance of managing the memory yourself, you could consider storing a smart pointer such as a unique_ptr or shared_ptr, or some variant thereof. That way you can still use your polymorphic class, but it's a little less work for you.

There's no real hard and fast rules about when to use objects and pointers, although it's worth noting that in some cases, like yours, objects just aren't going to work for you. I tend to use objects whenever nothing precludes it though, although you do have to be concerned about expensive copy operations as you note (although sometimes they can be ameliorated by passing containers by reference).

improved content
Source Link
Blair Conrad
  • 243.6k
  • 25
  • 137
  • 114

In this case, storing a vector of Animal would not work for you, as your animals have different sizes, and you wouldn't be able to store the derived objects in the spaces intended to hold the base class. (And even if they're the same size, you won't get the intended polymorphic effect, as base class methods will be executed - the virtualness of a method doesn't come into play unless you access it through a pointer or reference.)

If you want to avoid the annoyance of managing the memory yourself, you could consider storing ana smart pointer such as a shared_ptr (note that auto_ptr doesn't work with STL containers, shared_ptraccording to Max Lybbert), or some variant thereof. That way you can still use your polymorphic class, but it's a little less work for you.

There's no real hard and fast rules about when to use objects and pointers, although it's worth noting that in some cases, like yours, objects just aren't going to work for you. I tend to use objects whenever nothing precludes it though, although you do have to be concerned about expensive copy operations as you note (although sometimes they can be ameliorated by passing containers by reference).

In this case, storing a vector of Animal would not work for you, as your animals have different sizes, and you wouldn't be able to store the derived objects in the spaces intended to hold the base class. (And even if they're the same size, you won't get the intended polymorphic effect, as base class methods will be executed - the virtualness of a method doesn't come into play unless you access it through a pointer or reference.)

If you want to avoid the annoyance of managing the memory yourself, you could consider storing an auto_ptr, shared_ptr, or some variant thereof. That way you can still use your polymorphic class, but it's a little less work for you.

There's no real hard and fast rules about when to use objects and pointers, although it's worth noting that in some cases, like yours, objects just aren't going to work for you. I tend to use objects whenever nothing precludes it though, although you do have to be concerned about expensive copy operations as you note (although sometimes they can be ameliorated by passing containers by reference).

In this case, storing a vector of Animal would not work for you, as your animals have different sizes, and you wouldn't be able to store the derived objects in the spaces intended to hold the base class. (And even if they're the same size, you won't get the intended polymorphic effect, as base class methods will be executed - the virtualness of a method doesn't come into play unless you access it through a pointer or reference.)

If you want to avoid the annoyance of managing the memory yourself, you could consider storing a smart pointer such as a shared_ptr (note that auto_ptr doesn't work with STL containers, according to Max Lybbert), or some variant thereof. That way you can still use your polymorphic class, but it's a little less work for you.

There's no real hard and fast rules about when to use objects and pointers, although it's worth noting that in some cases, like yours, objects just aren't going to work for you. I tend to use objects whenever nothing precludes it though, although you do have to be concerned about expensive copy operations as you note (although sometimes they can be ameliorated by passing containers by reference).

Source Link
Blair Conrad
  • 243.6k
  • 25
  • 137
  • 114

In this case, storing a vector of Animal would not work for you, as your animals have different sizes, and you wouldn't be able to store the derived objects in the spaces intended to hold the base class. (And even if they're the same size, you won't get the intended polymorphic effect, as base class methods will be executed - the virtualness of a method doesn't come into play unless you access it through a pointer or reference.)

If you want to avoid the annoyance of managing the memory yourself, you could consider storing an auto_ptr, shared_ptr, or some variant thereof. That way you can still use your polymorphic class, but it's a little less work for you.

There's no real hard and fast rules about when to use objects and pointers, although it's worth noting that in some cases, like yours, objects just aren't going to work for you. I tend to use objects whenever nothing precludes it though, although you do have to be concerned about expensive copy operations as you note (although sometimes they can be ameliorated by passing containers by reference).