Quick Question... I Hope.

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • That's a confusing way to put it.

      A Virtual function is one that can be overwritten by child classes. You can choose whether or not to have the parent class implement a virtual function at all (though any instance of the class needs to have it defined).

      If you don't really know inheritance, then you won't really get virtual functions.
      -Larrik Jaerico

      www.LarrikJ.com
    • It's C++'s way of facilitating polymorphism (one of the cornerstones of OOP). It only really becomes applicable when talking about inheritance hierarchies. Basically it tells the compiler that the class function that's been declared virtual may be overridden by a derived class (just like any other function). The catch though is if you have a derived object's memory address stored in a base class pointer (or if you have a reference to a derived object stored in a base class reference), and you call the virtual function through the base class pointer/reference, the executable will at runtime will perform a look up and realize that it needs to really call the derived class' version of the virtual function (remember: had the function not been declared virtual and the function was called through the base class reference/pointer, the base class version of that function would've been called).
    • It's hard to have an easy explantion for a complicated concept, isn't it!
      Mr.Mike
      Author, Programmer, Brewer, Patriot
    • Hi,

      This might be part of virtual so I post my question in here
      to keep the post nice and clean.

      Could someone explain the idea/concept of a "Factory"?
      The author made a refreance to it in his book and I
      first thought it was a "made up word", but after taking
      a second look at virtual classes I came across the
      concept of factories here..

      g.oswego.edu/dl/mood/C++AsIDL.html

      This paper talks about 'Factories' but its not clear.
      Could someone provide a better explination?

      Thank you,

      Sabrina.
    • Factories are somewhat related to virtual, I'll give an example that explains how.

      Here's a good detailed explanation (kinda long) on Factories:
      msdn.microsoft.com/library/def…bda/html/factopattern.asp

      The factories thing is more a part of the whole Design Patterns philosophy in programming, which goes beyond just knowing syntax, and enters the area of being able to architect very large software programs that are flexible and easy for a team of separate minds to work with.

      Basically, you want to use a factory when you want to delay instantiation of an object (you know what needs to be created, but you want full control of when and where it gets created). An example would be switching screens. Let's say you have a title screen, and you want to switch to a gameplay screen. And to make things worse, let's say that you can't fit both, the title screen and gameplay screen, in RAM at once. What do you do? Well, you have at least two obvious options.
      • Use enums for each screen and pass that to some screen manager when you want to change screens: For example, when you want to switch from title to gameplay, you tell the game that the next screen is ENUM_GAMEPLAY, then you delete current screen (title) and create the new screen based on the enum that was passed in (gameplay). The downside to this is you have to maintain a list of enums and a big ole switch statement every time you add a new screen type... not so bad, but
      • If you pass in an IScreenFactory object instead of an enum, then you can have the factory create whichever screen it is made to create. In this case, you are passing in an object that is made from "class GameScreenFactory : public IScreenFactory". IScreenFactory has a pure virtual function (IScreen* CreatScreen()) that is defined in 'GameScreenFactory' to return a brand new GameScreen* (or smart pointer, if you're the careful type), which is derived from IScreen. Your code is safer to maintain with this method than the enum method because there are no dependencies on screen enums in multiple places.

      The post was edited 1 time, last by Kain ().

    • Larrik might be right. It is better to not use Design Patterns (such as Factories) at all than to try to force yourself to use it in unnatural ways. :)

      With that said, I'd recommend getting to know Design Patterns as a side project so that you can get a feel for it and decide for yourself what you want to do with that knowledge. There are a lot of people in the industry who understand design patterns and use parts of it, but not all.

      The original book that was the genesis of this mentality is really boring, but here it is:
      Design Patterns
      by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
      amazon.com/exec/obidos/tg/deta…v=glance&s=books&n=507846
      [IMG:http://images.amazon.com/images/P/0201633612.01._PIdp-schmoo2,TopRight,7,-26_SCMZZZZZZZ_.jpg]

      A book that presents the idea in more readable terms is
      Design Patterns Explained : A New Perspective on Object-Oriented Design (2nd Edition) (Software Patterns Series)
      by Alan Shalloway, James Trott
      amazon.com/exec/obidos/tg/deta…v=glance&s=books&n=507846
      [IMG:http://images.amazon.com/images/P/0321247140.01._PE17_SCMZZZZZZZ_.jpg]

      And my favorite book of all on this subject is about what NOT to do in your code using the design patterns philosophy:
      AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis
      by William J. Brown, Raphael C. Malveau, Hays W. "Skip" McCormick (III), Thomas J. Mowbray
      amazon.com/exec/obidos/tg/deta…v=glance&s=books&n=507846
      [IMG:http://images.amazon.com/images/P/0471197130.01._PIdp-schmooS,TopRight,7,-26_PE32_SCMZZZZZZZ_.gif]

      I really like "Anti-Patterns" because I find it easier to remember what NOT to do than remembering what to do. It also presents the topics in amusing ways and gives them funny names like the blob class... which is their name for the big giant class that does everything! hahahahahahahahahaha. Why am I laughing?
    • BTW, Sabrina, my explanation was a lot of info and I think it was too much info. I believe that people learn in layers as opposed to chunks of batch processing (Neo-"I know kung fu").

      So consider that explanation a layer that you'll probably understand when the layers under it are understood. I didn't explain the layers under it at all. I'm not sure where to start. If you gave me some specific questions that you're having, I might be able to start from those. Don't give up, and keep those great questions coming! :)
    • Hi,

      Thanks again Kain, I will check out B&N for your suggested
      book. It sounds like Design Patterns is kinda dull and boring,
      but I think it might be a good topic to look into. It seems
      as though this is a software engineering issue and I am
      surprised that we did not cover it in any of my classes.
      If this is not a big issue like Larrik stated, then I will just
      make a 'mental note' of it.

      Thanks again guys for the education :))

      Sabrina.
    • A mental note should be just fine. I also didn't learn about software engineering until after I graduated.

      It was when I began working that my education really began... from more experienced coworkers who were excellent mentors to me... as well as some books that they pointed out as having influenced them. All that time I spent in school was just learning the foundation and syntax of code. Real world experience gave me a reason to want to put that stuff together in the best possible way.

      ...and I'm still learning :D