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

Revision 10160, 8.0 kB (checked in by robert, 5 years ago)

Changed paths to be relative paths to test out new relative path support in p3d plugin

Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!-- key 1222139 -->
3<!--
4    Document   : DevelopmentInOpenSceneGraph.xml
5    Created on : 20th May 2004
6    Author     : Robert Osfield
7    Description: Lecture at AVR III 2004.
8-->
9
10<presentation character_size="0.02"> 
11<name>Siggraph Menu</name>
12<textcolor>YELLOW</textcolor>
13
14<path>../../Data</path>
15<path>../../Data/OpenSceneGraph-Data</path>
16<path>../../Data/Images</path>
17<path>../../Data/Models</path>
18<path>../../Data/Earth</path>
19
20<!--
21<path>${DATA_DIR}/OpenSceneGraph-Data</path>
22<path>${DATA_DIR}/Images</path>
23<path>${DATA_DIR}/Models</path>
24<path>${DATA_DIR}/Earth</path>
25-->
26 
27<path>${DATA_DIR}</path>
28<path>${DATA_DIR}/OpenSceneGraph-Data</path>
29<path>${DATA_DIR}/Images</path>
30<path>${DATA_DIR}/Models</path>
31<path>${DATA_DIR}/Earth</path>
32
33<title-settings character_size="0.04"></title-settings>
34<text-settings character_size="0.03"></text-settings>
35
36<template_slide name="front">
37  <background>Images/default_blue.jpg</background>
38  <title></title>
39  <base>
40     <click_to_event>Home</click_to_event>       
41     <bullet character_size="0.02" position="0.5 0.02 0.05">Home</bullet>
42     <click_to_event>Next</click_to_event>       
43     <bullet character_size="0.02" position="0.9 0.02 0.05">Next</bullet>
44  </base>
45</template_slide>
46
47<template_slide name="middle">
48  <background>Images/default_blue.jpg</background>
49  <title></title>
50  <base>
51     <click_to_event>Previous</click_to_event>       
52     <bullet character_size="0.02" position="0.1 0.02 0.05">Previous</bullet>
53     <click_to_event>Home</click_to_event>       
54     <bullet character_size="0.02" position="0.5 0.02 0.05">Home</bullet>
55     <click_to_event>Next</click_to_event>       
56     <bullet character_size="0.02" position="0.9 0.02 0.05">Next</bullet>
57  </base>
58</template_slide>
59
60<template_slide name="end">
61  <background>Images/default_blue.jpg</background>
62  <title></title>
63  <base>
64     <click_to_event>Previous</click_to_event>       
65     <bullet character_size="0.02" position="0.1 0.02 0.05">Previous</bullet>
66     <click_to_event>Home</click_to_event>       
67     <bullet character_size="0.02" position="0.5 0.02 0.05">Home</bullet>
68  </base>
69</template_slide>
70
71
72<slide inherit="front">
73<background>Images/default_blue.jpg</background>
74<title> </title>
75<layer>
76<paragraph position="0.5 0.5 0" alignment="CENTER_CENTER" character_size="0.07">
77C++ and OpenSceneGraph</paragraph>
78<image fade="0 0.99 1 0.99" position="0.5 0.90 0" scale="0.55">Images/logops.rgb</image>
79</layer>
80</slide>
81
82<page inherit="middle" title="Standard C++">
83C++ is very powerful
84
85C++ can be optimised to very fast code
86
87Faster than standard C once inline methods and templates kick in
88
89Multiple Programming Paradigms:
90
91   - Functional
92   - Object Orientated
93   - Generic Programming
94
95C++ can be very very complicated :-|
96
97C++ offers you a lot of rope to hang yourself with ;-z
98
99It takes experience and care to write robust C++..
100</page>
101
102<page inherit="middle" title="OpenSceneGraph aims for 'Good Practices'">
103One of my goals when writing the OpenSceneGraph was to provide an example of how to write and manage a C++ project.
104
105For others to learn from, cut short all the many frustrating hours of learning the hard way
106
107Takes inspiration from Design Patterns, Effective C++ etc.
108
109Make the project easier to contribute to.
110
111Make it easier to manage
112
113Make it more robust
114</page>
115
116<page inherit="middle" title="Inheritance">
117Single Inheritance:
118
119   class A {};
120   class B : public A {} ;
121   
122
123Multiple inheritance:
124
125   class C {};
126   class D : public A, public C {};
127
128Conflicting inheritance:
129
130   class E : public B, public D {};
131   
132What's the problem here??
133   
134</page>
135
136<page inherit="middle" title="Inheritance cont.">
137Conflicting inheritance:
138
139   class A {}
140   class B : public A {};
141   class C : public A {};
142   class E : public B, public C {};
143   
144E has A appear twice in its inheritance tree, compiler doesn't know which one to use.
145
146The solution is "Virtual Inheritance":
147
148   class A {};
149   class B : public virtual A {};
150   class C : public virtual A {};
151   class E : public A, public B {};
152   
153Go find where Virtual inheritance is used, and work out why!
154</page>
155
156<page inherit="end" title="Containers">
157For many years everybody implemented their own containers
158
159They didn't integrate with each other.
160
161They weren't all efficient.
162
163They weren't all robust.
164
165But they all wasted time!
166</page>
167
168<page inherit="end" title="std::containers">
169The Standard Template Library is a watershed in C++.
170
171Finally robust, efficient and highly interoperable containers were available to all
172
173But still people waste time "Not invented here syndrome"
174
175OpenSceneGraph adopts Standard C++, container and all.
176
177    - Saves coding, debugging and maintainence time
178    - Reuse exising skill base
179    - Cuts down on need to documention
180</page>
181
182<page inherit="end" title="Templates">
183Positives:
184
185    - Templates are very powerful
186    - Templates can compile down to efficient code
187
188Negatives:
189
190    - Templates can be very hard to understand.
191    - Templates can be very hard to decider at compile time.
192    - Templates can be slow to compile.
193    - Complex templates can restrict portability.
194   
195So use sparingly:
196
197   - When you need type safety on a generic type
198   - When you need inline call efficency
199   - When you can avoid recreating code many times
200   - When the code remains readable
201</page>
202
203<page inherit="middle" title="Design Patterns">
204OpenSceneGraph use Design Patterns :
205
206    - To produce clear designs
207    - To uses designs that are familiar
208    - That are already documented
209    - And with standard terminology
210   
211    - Promotes collaboration!
212
213Design Patterns used include:
214
215    - Composite -> osg::Group
216    - Visitor -> osg::NodeVisitor
217    - Chain of Responsibility -> Plugins
218    - Singlon -> osgDB::Registry
219    - Observer -> see end of talk ;-)
220
221</page>
222
223<page inherit="end" title="Memory management">
224Standard C++ has constructors and destructors, but...
225
226No compiler or automatically runtime support for ensuring that no dangling pointers or leak memory occurs.
227
228Partial solution:
229
230    - Reference counting
231    - Automatic deletion when reference count goes to zero.
232   
233More complete solution:
234
235    - Smart pointers automatically increment and decrement.
236    - Smart pointers are robust in the presence of exceptions.
237    - Smart pointers make handling of scope easy
238</page>
239
240<page inherit="end" title="ref_ptr">
241Templated smart pointer to the rescue!!
242
243Simple scope example:
244
245{
246   // construct an Node, and automatically
247   // increment it's reference count by one.
248   osg::ref_ptr(osg::Node) node = new osg::Node;
249
250   // do stuff (that doesn't increment it ref count)
251
252}; // ref_ptr goes out of scope and its destructor
253   // automatically decrements ref count and if it goes to
254   // zero then its deleted.
255
256</page>
257
258<page inherit="end" title="ref_ptr() cont.">
259More complex scope example:
260
261osg::ref_ptr(osg::Group) group = new osg::Group;
262   
263{
264   // construct an Node, and automatically
265   // increment it's reference count to one.
266   osg::ref_ptr(osg::Node) node = new osg::Node;
267
268   // note we have convert to C pointer using .get()
269   // addChild increments ref count to two
270   group->addChild(node.get())
271
272}; // ref_ptr goes out of scope and its destructor
273   // automatically decrements ref count down to 1
274   // so it doesn't get deleted, group still keeps
275   // its copy.
276</page>
277
278<page inherit="end" title="ref_ptr cont.">
279Problems... circular references...
280
281If two objects both has ref_ptr to each other then they never can be deleted!
282
283Exercise 2d_observer_ptr explores this issue.
284</page>
285
286<page inherit="end" title="observer_ptr">
287Solution to circular references - osg::observer_ptr
288
289osg::observer_ptr doesn't increment the reference count, but does automatically get reset to 0 when the object its
290observing get deleted.
291
292Now onto the Exercises/02_memory!
293</page>
294</presentation>
Note: See TracBrowser for help on using the browser.