root/OpenSceneGraph-TrainingMaterials/trunk/Presentations/C++AndMemoryManagement/CppAndOpenSceneGraph.p3d @ 10044

<?xml version="1.0" encoding="UTF-8"?>
<!-- key 1222139 -->
<!--
    Document   : DevelopmentInOpenSceneGraph.xml
    Created on : 20th May 2004
    Author     : Robert Osfield
    Description: Lecture at AVR III 2004.
-->

<presentation character_size="0.02"> 
<name>Siggraph Menu</name>
<textcolor>YELLOW</textcolor>


 
<path>${DATA_DIR}</path>
<path>${DATA_DIR}/OpenSceneGraph-Data</path>
<path>${DATA_DIR}/Images</path>
<path>${DATA_DIR}/Models</path>
<path>${DATA_DIR}/Earth</path>

<title-settings character_size="0.04"></title-settings>
<text-settings character_size="0.03"></text-settings>

<template_slide name="front">
  <background>Images/default_blue.jpg</background>
  <title></title>
  <base>
     <click_to_event>Home</click_to_event>        
     <bullet character_size="0.02" position="0.5 0.02 0.05">Home</bullet>
     <click_to_event>Next</click_to_event>        
     <bullet character_size="0.02" position="0.9 0.02 0.05">Next</bullet>
  </base>
</template_slide>

<template_slide name="middle">
  <background>Images/default_blue.jpg</background>
  <title></title>
  <base>
     <click_to_event>Previous</click_to_event>        
     <bullet character_size="0.02" position="0.1 0.02 0.05">Previous</bullet>
     <click_to_event>Home</click_to_event>        
     <bullet character_size="0.02" position="0.5 0.02 0.05">Home</bullet>
     <click_to_event>Next</click_to_event>        
     <bullet character_size="0.02" position="0.9 0.02 0.05">Next</bullet>
  </base>
</template_slide>

<template_slide name="end">
  <background>Images/default_blue.jpg</background>
  <title></title>
  <base>
     <click_to_event>Previous</click_to_event>        
     <bullet character_size="0.02" position="0.1 0.02 0.05">Previous</bullet>
     <click_to_event>Home</click_to_event>        
     <bullet character_size="0.02" position="0.5 0.02 0.05">Home</bullet>
  </base>
</template_slide>


<slide inherit="front">
<background>Images/default_blue.jpg</background>
<title> </title>
<layer>
<paragraph position="0.5 0.5 0" alignment="CENTER_CENTER" character_size="0.07">
C++ and OpenSceneGraph</paragraph>
<image fade="0 0.99 1 0.99" position="0.5 0.90 0" scale="0.55">Images/logops.rgb</image>
</layer>
</slide>

<page inherit="middle" title="Standard C++">
C++ is very powerful

C++ can be optimised to very fast code

Faster than standard C once inline methods and templates kick in

Multiple Programming Paradigms:

   - Functional
   - Object Orientated
   - Generic Programming

C++ can be very very complicated :-|

C++ offers you a lot of rope to hang yourself with ;-z

It takes experience and care to write robust C++..
</page>

<page inherit="middle" title="OpenSceneGraph aims for 'Good Practices'">
One of my goals when writing the OpenSceneGraph was to provide an example of how to write and manage a C++ project.

For others to learn from, cut short all the many frustrating hours of learning the hard way

Takes inspiration from Design Patterns, Effective C++ etc.

Make the project easier to contribute to.

Make it easier to manage

Make it more robust
</page>

<page inherit="middle" title="Inheritance">
Single Inheritance:

   class A {};
   class B : public A {} ;
   

Multiple inheritance:

   class C {};
   class D : public A, public C {};

Conflicting inheritance:

   class E : public B, public D {};
   
What's the problem here??
   
</page>

<page inherit="middle" title="Inheritance cont.">
Conflicting inheritance:

   class A {}
   class B : public A {};
   class C : public A {};
   class E : public B, public C {};
   
E has A appear twice in its inheritance tree, compiler doesn't know which one to use.

The solution is "Virtual Inheritance":

   class A {};
   class B : public virtual A {};
   class C : public virtual A {};
   class E : public A, public B {};
   
Go find where Virtual inheritance is used, and work out why!
</page>

<page inherit="end" title="Containers">
For many years everybody implemented their own containers

They didn't integrate with each other.

They weren't all efficient.

They weren't all robust.

But they all wasted time!
</page>

<page inherit="end" title="std::containers">
The Standard Template Library is a watershed in C++.

Finally robust, efficient and highly interoperable containers were available to all

But still people waste time "Not invented here syndrome"

OpenSceneGraph adopts Standard C++, container and all.

    - Saves coding, debugging and maintainence time
    - Reuse exising skill base
    - Cuts down on need to documention
</page>

<page inherit="end" title="Templates">
Positives:

    - Templates are very powerful
    - Templates can compile down to efficient code

Negatives:

    - Templates can be very hard to understand.
    - Templates can be very hard to decider at compile time.
    - Templates can be slow to compile.
    - Complex templates can restrict portability.
    
So use sparingly:

   - When you need type safety on a generic type
   - When you need inline call efficency
   - When you can avoid recreating code many times
   - When the code remains readable
</page> 

<page inherit="middle" title="Design Patterns">
OpenSceneGraph use Design Patterns :

    - To produce clear designs
    - To uses designs that are familiar
    - That are already documented
    - And with standard terminology
    
    - Promotes collaboration!

Design Patterns used include:

    - Composite -> osg::Group
    - Visitor -> osg::NodeVisitor
    - Chain of Responsibility -> Plugins
    - Singlon -> osgDB::Registry
    - Observer -> see end of talk ;-)

</page>

<page inherit="end" title="Memory management">
Standard C++ has constructors and destructors, but...

No compiler or automatically runtime support for ensuring that no dangling pointers or leak memory occurs.

Partial solution:

    - Reference counting
    - Automatic deletion when reference count goes to zero.
    
More complete solution:

    - Smart pointers automatically increment and decrement.
    - Smart pointers are robust in the presence of exceptions.
    - Smart pointers make handling of scope easy
</page>

<page inherit="end" title="ref_ptr">
Templated smart pointer to the rescue!!

Simple scope example:

{
   // construct an Node, and automatically
   // increment it's reference count by one.
   osg::ref_ptr(osg::Node) node = new osg::Node;

   // do stuff (that doesn't increment it ref count)

}; // ref_ptr goes out of scope and its destructor
   // automatically decrements ref count and if it goes to
   // zero then its deleted.

</page>

<page inherit="end" title="ref_ptr() cont.">
More complex scope example:

osg::ref_ptr(osg::Group) group = new osg::Group;
   
{
   // construct an Node, and automatically
   // increment it's reference count to one.
   osg::ref_ptr(osg::Node) node = new osg::Node;

   // note we have convert to C pointer using .get()
   // addChild increments ref count to two
   group->addChild(node.get()) 

}; // ref_ptr goes out of scope and its destructor
   // automatically decrements ref count down to 1
   // so it doesn't get deleted, group still keeps
   // its copy.
</page>

<page inherit="end" title="ref_ptr cont.">
Problems... circular references...

If two objects both has ref_ptr to each other then they never can be deleted!

Exercise 2d_observer_ptr explores this issue.
</page>

<page inherit="end" title="observer_ptr">
Solution to circular references - osg::observer_ptr

osg::observer_ptr doesn't increment the reference count, but does automatically get reset to 0 when the object its
observing get deleted.

Now onto the Exercises/02_memory!
</page>
</presentation>