← Back to branch summary

~ubuntu-branches/ubuntu/intrepid/plplot/intrepid

« back to all changes in this revision

Viewing changes to doc/docbook/src/cpluscplus-design.html

  • Committer: Bazaar Package Importer
  • Author(s): Rafael Laboissiere
  • Date: 2006-11-04 10:19:34 UTC
  • mfrom: (2.1.8 edgy)
  • Revision ID: james.westby@ubuntu.com-20061104101934-mlirvdg4gpwi6i5q
Tags: 5.6.1-10
* Orphaning the package
* debian/control: Changed the maintainer to the Debian QA Group

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/docbook/src/cpluscplus-design.html
1
 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 
1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
2
2
<HTML
3
3
><HEAD
4
4
><TITLE
5
5
>Design of the PLplot C++ Interface</TITLE
6
6
><META
7
7
NAME="GENERATOR"
8
 
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
 
8
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
9
9
REL="HOME"
10
10
TITLE="The PLplot Plotting Library"
11
11
HREF="index.html"><LINK
56
56
WIDTH="80%"
57
57
ALIGN="center"
58
58
VALIGN="bottom"
59
 
>Chapter 9. A C++ Interface for PLplot</TD
 
59
>Chapter 10. A C++ Interface for PLplot</TD
60
60
><TD
61
61
WIDTH="10%"
62
62
ALIGN="right"
88
88
>Stream/Object Identity</A
89
89
></H2
90
90
><P
91
 
>A C++ class named <VAR
 
91
>A C++ class named <TT
92
92
CLASS="literal"
93
 
>plstream</VAR
 
93
>plstream</TT
94
94
> has been introduced.  It's central
95
95
purpose is provide a specific, object based encapsulation of the
96
96
concept of a PLplot output stream.  Any output produced using a
97
 
<VAR
 
97
<TT
98
98
CLASS="literal"
99
 
>plstream</VAR
 
99
>plstream</TT
100
100
> object, will go to the PLplot output stream associated with
101
101
that object, regardless of what stream may have been active before.  
102
102
    </P
103
103
><P
104
104
>In order to write a multiple output stream PLplot application, a C++
105
 
program can declare <VAR
 
105
program can declare <TT
106
106
CLASS="literal"
107
 
>plstream</VAR
 
107
>plstream</TT
108
108
> objects, and invoke drawing methods on
109
109
those objects, without regard to ordering considerations or other
110
110
coherency considerations.  Although this has obvious simplification
111
111
benefit even for simple programs, the full benefit is most easily
112
112
appreciated in the context of Tk extended wish applications in which a
113
 
<VAR
 
113
<TT
114
114
CLASS="literal"
115
 
>plstream</VAR
 
115
>plstream</TT
116
116
> can be associated with each plframe.
117
117
    </P
118
118
></DIV
128
128
>The PLplot C API is composed of a set of drawing functions, all
129
129
prefixed with "pl", in an effort to prevent namespace collision.
130
130
However, the prefix "pl" is gratuitous, and in particular is
131
 
unnecessary in a C++ context.  The <VAR
 
131
unnecessary in a C++ context.  The <TT
132
132
CLASS="literal"
133
 
>plstream</VAR
 
133
>plstream</TT
134
134
> class mirrors most
135
135
of the PLplot C API, but does so by dropping the "pl" prefix.  The
136
 
<VAR
 
136
<TT
137
137
CLASS="literal"
138
 
>plstream</VAR
 
138
>plstream</TT
139
139
> class thus serves to collect the PLplot drawing
140
140
functions into a scope in which collisions with other similarly named
141
141
functions is not a concern.  So, where a C programmer might write:
183
183
characters!  You've replaced 'pl' with 'p.', except it could be worse
184
184
for a longer object name."  True.  BUT, in this new scheme, most plots
185
185
will not be generated by invoking methods on a specific stream object,
186
 
but rather by deriving from <VAR
 
186
but rather by deriving from <TT
187
187
CLASS="literal"
188
 
>plstream</VAR
 
188
>plstream</TT
189
189
>, and invoking methods of
190
190
"this" object.  See the section on derivation below.
191
191
    </P
199
199
>Abstraction of Data Layout</A
200
200
></H2
201
201
><P
202
 
>The <VAR
 
202
>The <TT
203
203
CLASS="literal"
204
 
>plstream</VAR
 
204
>plstream</TT
205
205
> class will provide an abstract interface to the
206
206
2-d drawing functions.  Instead of forcing the C++ user to organize
207
207
data in one of a small set of generally braindead data layouts with
208
208
poor memory management properties, potentially forcing the C++ user to
209
209
not use a superior method, or to copy data computed in one layout
210
210
format to another for plotting (with consequent bug production), the
211
 
<VAR
 
211
<TT
212
212
CLASS="literal"
213
 
>plstream</VAR
 
213
>plstream</TT
214
214
> 2-d plotting functions will accept an abstract layout
215
215
specification.  The only thing which is important to the 2-d drawing
216
216
functions is that the data be "indexable".  They should not care about
275
275
></H2
276
276
><P
277
277
>Use of abstraction as in C) above will allow a single method in
278
 
<VAR
 
278
<TT
279
279
CLASS="literal"
280
 
>plstream</VAR
 
280
>plstream</TT
281
281
> to perform the services of multiple functions in the C API.
282
282
In those cases where multiple functions were provided with different
283
283
data layout specifications, but similar functionality, these can all