| [793] | 1 | \documentclass[twoside,12pt]{article} | 
|---|
|  | 2 | %  Package standard : Utilisation de caracteres accentues, mode francais et graphique | 
|---|
|  | 3 | \usepackage[latin1]{inputenc} | 
|---|
|  | 4 | \usepackage[T1]{fontenc} | 
|---|
|  | 5 | \usepackage{babel} | 
|---|
|  | 6 | \usepackage{graphicx} | 
|---|
|  | 7 |  | 
|---|
|  | 8 | %  Extension de symboles mathematiques | 
|---|
|  | 9 | \usepackage{amssymb} | 
|---|
|  | 10 |  | 
|---|
| [1015] | 11 | % package a mettre pour faire du pdf | 
|---|
|  | 12 | \usepackage{palatino} | 
|---|
|  | 13 |  | 
|---|
| [793] | 14 | %  Definition de taille de page | 
|---|
|  | 15 | \setlength{\textwidth}{16cm} | 
|---|
|  | 16 | \setlength{\textheight}{21.5cm} | 
|---|
|  | 17 | \setlength{\topmargin}{0.5cm} | 
|---|
|  | 18 | \setlength{\oddsidemargin}{0.cm} | 
|---|
|  | 19 | \setlength{\evensidemargin}{0.cm} | 
|---|
|  | 20 | \setlength{\unitlength}{1mm} | 
|---|
|  | 21 |  | 
|---|
|  | 22 | \newcommand{\bul}{$\bullet \ $} | 
|---|
|  | 23 |  | 
|---|
|  | 24 | \begin{document} | 
|---|
|  | 25 |  | 
|---|
|  | 26 | \begin{titlepage} | 
|---|
|  | 27 | \vspace{1cm} | 
|---|
| [1015] | 28 | \vspace{1cm} | 
|---|
|  | 29 | \makebox[34mm][c]{\includegraphics[width=3cm]{hfi_icon_vsmall.eps}} | 
|---|
|  | 30 | \raisebox{12mm}{\rule{80 mm}{0.5 mm}\makebox[50 mm]{\bf Planck HFI L2}} | 
|---|
| [793] | 31 | \vspace{2cm} | 
|---|
| [1015] | 32 | \vspace{2cm} | 
|---|
| [793] | 33 | \begin{center} | 
|---|
|  | 34 | \par \renewcommand{\baselinestretch}{2.0} \small | 
|---|
|  | 35 | {\LARGE \bf | 
|---|
|  | 36 | Planck HFI L2 \\ | 
|---|
|  | 37 | Software Development Guidelines | 
|---|
|  | 38 | } | 
|---|
|  | 39 | \par \renewcommand{\baselinestretch}{1.0} \normalsize | 
|---|
|  | 40 | \vspace{5 cm} | 
|---|
|  | 41 | \begin{tabular}{ll} | 
|---|
|  | 42 | {R. Ansari} & {\tt ansari@lal.in2p3.fr} \\ | 
|---|
|  | 43 | {É. Aubourg} & {\tt aubourg@hep.saclay.cea.fr} \\ | 
|---|
|  | 44 | % {É. Lesquoy} & {\tt lesquoy@hep.saclay.cea.fr} \\ | 
|---|
| [1015] | 45 | {C. Magneville} & {\tt cmv@hep.saclay.cea.fr} \\ | 
|---|
| [793] | 46 | \end{tabular} | 
|---|
|  | 47 |  | 
|---|
|  | 48 | \end{center} | 
|---|
|  | 49 | \vfill | 
|---|
|  | 50 | \hfill | 
|---|
|  | 51 | % \includegraphics[width=4cm]{Fig/hfi_icon_vsmall.eps} | 
|---|
|  | 52 | \framebox[\textwidth]{\hspace{0.5cm} \bf Planck HFI Level 2 | 
|---|
|  | 53 | \hspace{1cm} \today } | 
|---|
|  | 54 | \end{titlepage} | 
|---|
|  | 55 |  | 
|---|
|  | 56 | \tableofcontents | 
|---|
|  | 57 |  | 
|---|
|  | 58 | \newpage | 
|---|
|  | 59 |  | 
|---|
|  | 60 | \section{Introduction} | 
|---|
|  | 61 | We intend to gather gradually in this document the guidelines | 
|---|
| [1015] | 62 | for the development of Planck HFI Level 2 data processing software. | 
|---|
| [793] | 63 | We assume throughout this document that C++ is the baseline option | 
|---|
|  | 64 | as the programming language for the development of Planck HFI | 
|---|
| [1015] | 65 | Level 2 processing software, we review here briefly some of | 
|---|
|  | 66 | the properties of the C++ and Java language and interoperability | 
|---|
|  | 67 | with other language, mainly C and Fortran. | 
|---|
| [793] | 68 |  | 
|---|
|  | 69 |  | 
|---|
| [1015] | 70 | \section{C++} | 
|---|
|  | 71 | {\bf C++ \ } is an object-oriented programming language which | 
|---|
|  | 72 | has been developed by extending the {\bf C \ } language. | 
|---|
|  | 73 | Some of the additional possibilities incorporated in C++ are: | 
|---|
|  | 74 | \begin{itemize} | 
|---|
|  | 75 | \item Introduction of object and classes | 
|---|
|  | 76 | \item function overloading | 
|---|
|  | 77 | \item Operator overloading | 
|---|
|  | 78 | \item function and operator inlining | 
|---|
|  | 79 | \item virtual functions (polymorphism) | 
|---|
|  | 80 | \item public, protected and private members | 
|---|
|  | 81 | \item dynamic memory management operators | 
|---|
|  | 82 | \item Exception handling | 
|---|
|  | 83 | \item generic (template) function and classes | 
|---|
|  | 84 | \end{itemize} | 
|---|
|  | 85 |  | 
|---|
|  | 86 | We discuss here the some of the problems and solutions arising when | 
|---|
|  | 87 | integrating software modules written in other languages into C++ programs. | 
|---|
|  | 88 |  | 
|---|
|  | 89 | \subsection{Calling C code from C++} | 
|---|
| [793] | 90 | C++ extends the possibilities offered by the C language. | 
|---|
|  | 91 | All of the C language data types and function call syntax are thus | 
|---|
|  | 92 | supported by C++. Among other features, C++ offers the function | 
|---|
|  | 93 | overloading possibility. This means that functions with different | 
|---|
|  | 94 | argument list can have the same name. | 
|---|
|  | 95 | \begin{verbatim} | 
|---|
|  | 96 | int fo(int a); | 
|---|
|  | 97 | int fo(int a, int b); | 
|---|
|  | 98 | int fo(double a, double b); | 
|---|
|  | 99 | \end{verbatim} | 
|---|
| [1015] | 100 | Using {\bf C \ }, one would have written: | 
|---|
| [793] | 101 | \begin{verbatim} | 
|---|
|  | 102 | int foi(int a); | 
|---|
|  | 103 | int foii(int a, int b); | 
|---|
|  | 104 | int fodd(double a, double b); | 
|---|
|  | 105 | \end{verbatim} | 
|---|
|  | 106 | C++ compilers use internally a name containing the encoding of the | 
|---|
|  | 107 | argument list. In order to instruct the compiler to use simple | 
|---|
| [1015] | 108 | names, {\bf C \ } functions should be declared as \\ | 
|---|
| [793] | 109 | {\tt extern "C" }. This is usually included in the header | 
|---|
|  | 110 | file (.h). In the example above, the header file (.h) file | 
|---|
|  | 111 | would be in the form: | 
|---|
|  | 112 | \begin{verbatim} | 
|---|
|  | 113 | #ifdef __cplusplus | 
|---|
|  | 114 | extern "C" { | 
|---|
|  | 115 | #endif | 
|---|
|  | 116 | int foi(int a); | 
|---|
|  | 117 | int foii(int a, int b); | 
|---|
|  | 118 | int fodd(double a, double b); | 
|---|
|  | 119 | #ifdef __cplusplus | 
|---|
|  | 120 | } | 
|---|
|  | 121 | #endif | 
|---|
|  | 122 | \end{verbatim} | 
|---|
|  | 123 |  | 
|---|
| [1015] | 124 | \subsection{Calling Fortran code from C++} | 
|---|
| [793] | 125 | Fortran is a simple language and uses only basic data types. | 
|---|
|  | 126 | Although the exact mapping between Fortran and C/C++ basic data types | 
|---|
|  | 127 | may vary depending on the OS and hardware architecture, it is close | 
|---|
|  | 128 | to the one shown in the table below: | 
|---|
|  | 129 | \begin{center} | 
|---|
|  | 130 | \begin{tabular}{lll} | 
|---|
|  | 131 | INTEGER     &  int    & usually 4 bytes \\ | 
|---|
|  | 132 | REAL*4      &  float  & usually 4 bytes \\ | 
|---|
|  | 133 | REAL*8      &  double & usually 8 bytes \\ | 
|---|
|  | 134 | COMPLEX     &  complex<float> & \\ | 
|---|
|  | 135 | COMPLEX*16  &  complex<double> & \\ | 
|---|
|  | 136 | \end{tabular} | 
|---|
|  | 137 | \end{center} | 
|---|
|  | 138 | In fortran, all arguments are passed by address and | 
|---|
|  | 139 | fortran compilers (on Unix systems) add an underscore "\_" | 
|---|
|  | 140 | to all symbol names. It is thus rather easy to call | 
|---|
|  | 141 | Fortran subroutines or functions from C or C++. | 
|---|
|  | 142 | This is illustrated in the following example: | 
|---|
|  | 143 | \begin{verbatim} | 
|---|
|  | 144 | C   Fortran-Code | 
|---|
|  | 145 | SUBROUTINE FSUB(A,N,B,M) | 
|---|
|  | 146 | REAL A(*),B(*) | 
|---|
|  | 147 | INTEGER N,M | 
|---|
|  | 148 | RETURN | 
|---|
|  | 149 | END | 
|---|
|  | 150 | \end{verbatim} | 
|---|
|  | 151 | The corresponding C (or C++) declaration is: \\[3mm] | 
|---|
|  | 152 | {\tt void fsub\_(float *a, int *n, float *b, int *m); } \\[3mm] | 
|---|
|  | 153 | {\tt FSUB} can be called from C code, as is shown below : | 
|---|
|  | 154 | \begin{verbatim} | 
|---|
|  | 155 | float aa[10]; | 
|---|
|  | 156 | int na=10; | 
|---|
|  | 157 | float bb[10]; | 
|---|
|  | 158 | int mb=10; | 
|---|
|  | 159 | fsub_(aa, &na, bb, &mb); | 
|---|
|  | 160 | \end{verbatim} | 
|---|
|  | 161 |  | 
|---|
| [1015] | 162 | The case of character string arguments in Fortran subroutines | 
|---|
| [793] | 163 | needs a bit more attention, and the string length needs to be passed | 
|---|
|  | 164 | as an additional integer type argument. | 
|---|
| [1015] | 165 | As with {\bf C \ } functions, Fortran functions or subroutines | 
|---|
|  | 166 | have to be declared {\tt extern "C"} to be used within {\bf C++ \ } | 
|---|
|  | 167 | programs. {\bf C/C++ \ } driver routines can easily be written for | 
|---|
|  | 168 | extensively used Fortran modules, simplifying calling sequences. | 
|---|
| [793] | 169 |  | 
|---|
| [1015] | 170 | It should also be noted that the Fortran support libraries have to be | 
|---|
| [793] | 171 | included for the link with the C++ driver. | 
|---|
| [1015] | 172 | It is also possible to translate the whole Fortran source code | 
|---|
|  | 173 | into {\bf C \ } code using {\bf f2c \ } program. The call syntax | 
|---|
| [793] | 174 | will be exactly the same as with a Fortran compiler, and | 
|---|
|  | 175 | {\tt libf2c.a} should be used when linking the program. | 
|---|
|  | 176 |  | 
|---|
| [1015] | 177 | It is very difficult to use C++ classes directly from Fortran. | 
|---|
|  | 178 | However, high level functionalities based on a C++ library can | 
|---|
|  | 179 | be wrapped in a Fortran style function which can be | 
|---|
|  | 180 | called from Fortran. One looses of course many of the | 
|---|
| [793] | 181 | possibilities offered by underlying C++ library. | 
|---|
|  | 182 |  | 
|---|
|  | 183 | We illustrate below the wrapping of a simple C++ class: | 
|---|
|  | 184 | \begin{verbatim} | 
|---|
|  | 185 | // An example class performing some computation | 
|---|
|  | 186 | class Example { | 
|---|
|  | 187 | Example(); | 
|---|
|  | 188 | ~Example(); | 
|---|
|  | 189 | void compute(int sz, float *x); | 
|---|
|  | 190 | int getSize(); | 
|---|
|  | 191 | float getResult(int k); | 
|---|
|  | 192 | }; | 
|---|
|  | 193 | \end{verbatim} | 
|---|
|  | 194 |  | 
|---|
|  | 195 | The wrapper would then look like: | 
|---|
|  | 196 | \begin{verbatim} | 
|---|
|  | 197 | extern "C" { | 
|---|
|  | 198 | void foradapt_(float *a, int *n, float *b, int *m); | 
|---|
|  | 199 | } | 
|---|
|  | 200 |  | 
|---|
|  | 201 | foradapt_(float *a, int *m, float *b, int *n) | 
|---|
|  | 202 | { | 
|---|
|  | 203 | // a is the input array, m it's size | 
|---|
|  | 204 | // b is the output array, n the returned size | 
|---|
|  | 205 | // b has to dimensioned big enough in the calling program | 
|---|
|  | 206 |  | 
|---|
|  | 207 | Example ex; | 
|---|
|  | 208 | ex.compute(*n, a); | 
|---|
|  | 209 | *m = ex.getSize(); | 
|---|
|  | 210 | for(int i=0; i<ex.getSize(); i++) | 
|---|
|  | 211 | b[i] = ex.getResult(i); | 
|---|
|  | 212 | } | 
|---|
|  | 213 | \end{verbatim} | 
|---|
|  | 214 |  | 
|---|
|  | 215 | One can then call {\tt FORADPAT} from fortran : | 
|---|
|  | 216 | \begin{verbatim} | 
|---|
|  | 217 | REAL  A(1000) | 
|---|
|  | 218 | REAL  B(1000) | 
|---|
|  | 219 | INTEGER N,M | 
|---|
|  | 220 | M = 1000 | 
|---|
|  | 221 | N = 1000 | 
|---|
|  | 222 | CALL FORADPAT(A, M, B, N) | 
|---|
|  | 223 | \end{verbatim} | 
|---|
|  | 224 |  | 
|---|
|  | 225 |  | 
|---|
|  | 226 | \subsection{Fortran-90 and C++} | 
|---|
|  | 227 | Fortran-90 (F90) is a much more complex language than Fortran 77 | 
|---|
|  | 228 | (F77). Compared to F77, it introduces many new constructions, including: | 
|---|
|  | 229 | \begin{itemize} | 
|---|
|  | 230 | \item[-] pointers | 
|---|
|  | 231 | \item[-] local and global variables | 
|---|
|  | 232 | \item[-] in, out, in-out argument type for function and subroutines | 
|---|
|  | 233 | \item[-] compound data types, similar to structures in C | 
|---|
|  | 234 | \item[-] multidimensional arrays | 
|---|
|  | 235 | \item[-] function and operator overloading. | 
|---|
|  | 236 | \end{itemize} | 
|---|
|  | 237 | It is thus more difficult to use full featured F90 modules from | 
|---|
|  | 238 | {\bf C} or {\bf C++}. One would have to map all these different | 
|---|
|  | 239 | data structures with their attributes between the two languages, | 
|---|
|  | 240 | in a OS/compiler independent way. | 
|---|
|  | 241 | It should however be possible to encapsulate F90 modules into simple F77 | 
|---|
|  | 242 | like subroutines that could be called from C/C++. | 
|---|
|  | 243 |  | 
|---|
|  | 244 |  | 
|---|
| [1015] | 245 | \section{Java} | 
|---|
|  | 246 | Java \footnote{Information on the Java platform and language | 
|---|
|  | 247 | can be found at {\bf http://java.sun.com} } | 
|---|
|  | 248 | is a rather recent object-oriented programming language. It is | 
|---|
|  | 249 | based on the concept of a virtual machine, and a very extended | 
|---|
|  | 250 | standard library. | 
|---|
|  | 251 |  | 
|---|
|  | 252 | Java compilers produce "byte-codes" that are interpreted in a virtual | 
|---|
|  | 253 | machine (JVM). Thus, pure Java programs are platform-independent and | 
|---|
|  | 254 | portable. The very extended libraries that are available for the | 
|---|
|  | 255 | language make it a very good choice for user interfaces, network | 
|---|
|  | 256 | programming, distributed objects, database access. Numeric | 
|---|
|  | 257 | computation libraries start to appear but are still in early stages | 
|---|
|  | 258 | of development. | 
|---|
|  | 259 |  | 
|---|
|  | 260 | The Java language is strongly typed, with dynamic typing information. | 
|---|
|  | 261 | It is dynamic in essence as class bytecodes can be loaded into the | 
|---|
|  | 262 | JVM on request. | 
|---|
|  | 263 | It uses a garbage collector for memory management. Memory leaks and | 
|---|
|  | 264 | memory access errors cannot exist. All this makes debugging easier | 
|---|
|  | 265 | than with C++. | 
|---|
|  | 266 |  | 
|---|
|  | 267 | The overhead of interpreting the bytecodes in the virtual machine is | 
|---|
|  | 268 | alleviated by the development of "JIT" (Just In Time) compilers, that | 
|---|
|  | 269 | do a dynamic compilation. Java programs are typically 3 times slower | 
|---|
|  | 270 | than their equivalent in C++, but the exact figure might vary between | 
|---|
|  | 271 | 1 and 5 depending on the type of program. | 
|---|
|  | 272 |  | 
|---|
|  | 273 | Two features convenient for numeric library development and usage | 
|---|
|  | 274 | present in C++ are missing in Java: templates and operator overloading. | 
|---|
|  | 275 | Typically, a single code cannot be specialised for | 
|---|
|  | 276 | floats and doubles automatically, and one must write, if A, B and C | 
|---|
|  | 277 | are matrices, {\tt C = A.mult(B) instead of C = A*B} . | 
|---|
|  | 278 |  | 
|---|
|  | 279 | \subsection{Calling C/C++ code from Java } | 
|---|
|  | 280 |  | 
|---|
|  | 281 | A Java library (JNI, Java Native Interface) allows to call C/C++ code | 
|---|
|  | 282 | from Java programs. Of course, portability is then lost. | 
|---|
|  | 283 | Methods in Java objects can be declared {\tt native}. A tool then | 
|---|
|  | 284 | produces C/C++ headers for coding these methods in C/C++. This code | 
|---|
|  | 285 | can call existing C/C++/Fortran code, and even map the Java object to | 
|---|
|  | 286 | a C++ object. | 
|---|
|  | 287 |  | 
|---|
|  | 288 | Because the layout of objects in memory is not fixed in the JVM | 
|---|
|  | 289 | specifications, all accesses to methods and member variables are done | 
|---|
|  | 290 | through interface pointers. Accessing arrays can imply a copy of the | 
|---|
|  | 291 | array on input, and a copy back on return if the array was modified. | 
|---|
|  | 292 |  | 
|---|
|  | 293 | Since Java memory management is garbage-collector-based, C/C++ | 
|---|
|  | 294 | programs that want to hold references to Java objects, or create Java | 
|---|
|  | 295 | objects, must interact with the garbage collector explicitly. | 
|---|
|  | 296 |  | 
|---|
|  | 297 | JNI allows also C/C++ programs to instantiate a JVM and Java objects, | 
|---|
|  | 298 | and access them. | 
|---|
|  | 299 |  | 
|---|
|  | 300 | \subsection{Java and CORBA} | 
|---|
|  | 301 |  | 
|---|
|  | 302 | Another solution to call C++ objects from Java, or vice-versa, is to | 
|---|
|  | 303 | use CORBA. CORBA is a standard distributed objects framework, and | 
|---|
|  | 304 | Java 2 comes with a CORBA-2 compliant ORB (Object Request Broker), | 
|---|
|  | 305 | JavaIDL. | 
|---|
|  | 306 |  | 
|---|
|  | 307 | Objects distributed through CORBA must have their interface defined | 
|---|
|  | 308 | in a specific language, IDL. Tools then creates stubs for any | 
|---|
|  | 309 | language, as well as implementation skeletons. | 
|---|
|  | 310 |  | 
|---|
|  | 311 | An object can then physically exist on a machine, implemented in C++, | 
|---|
|  | 312 | and be manipulated remotely through Java stubs, as if it were a local | 
|---|
|  | 313 | Java object. CORBA offers thus language-independent distributed | 
|---|
|  | 314 | objects. | 
|---|
|  | 315 |  | 
|---|
|  | 316 | It adds overhead compared to JNI, because of the presence of a | 
|---|
|  | 317 | network layer, but offers more functionality. In particular, the C++ | 
|---|
|  | 318 | objects are platform-dependent, but the Java code that uses them, | 
|---|
|  | 319 | being pure Java code, remains portable. | 
|---|
|  | 320 |  | 
|---|
|  | 321 |  | 
|---|
| [793] | 322 | \newpage | 
|---|
|  | 323 | \appendix | 
|---|
|  | 324 |  | 
|---|
| [1015] | 325 | \section{C++ standard and compilers} | 
|---|
| [793] | 326 | \vspace{5 mm} | 
|---|
|  | 327 |  | 
|---|
|  | 328 | {\bf C++} can be considered now as a mature language. | 
|---|
|  | 329 | The current standard for C++ and C are defined by | 
|---|
|  | 330 | \footnote{Available from {\bf http://www.ansi.org/ } }: | 
|---|
|  | 331 | \begin{itemize} | 
|---|
| [1015] | 332 | \item[] {\bf ISO/IEC 14882-1998(E) \ } Programming languages -- C++ | 
|---|
|  | 333 | \item[] {\bf ANSI/ISO 9899-1990 \ } for Programming Languages C | 
|---|
| [793] | 334 | \end{itemize} | 
|---|
|  | 335 |  | 
|---|
| [1015] | 336 | Powerful compilers are available on most platforms, including: | 
|---|
| [793] | 337 |  | 
|---|
|  | 338 | \begin{itemize} | 
|---|
|  | 339 | \item[-] the GNU multiplatform g++ \footnote{http://gcc.gnu.org/}, | 
|---|
|  | 340 | \item[-] KAI KCC \footnote{http://www.kai.com/C\_plus\_plus/} which is a | 
|---|
|  | 341 | nice multiplatform optimising C++ compiler. | 
|---|
|  | 342 | \item[-] Digital (Compaq) cxx \footnote{http://www.unix.digital.com/cplus/} | 
|---|
|  | 343 | \item[-] IBM VisualAge C++ \footnote{http://www-4.ibm.com/software/ad/vacpp/} | 
|---|
|  | 344 | \item[-] HP aCC \footnote{http://www.hp.com/esy/lang/cpp/} | 
|---|
|  | 345 | \item[-] Silicon Graphics SGI-CC on IRIX \footnote{http://www.sgi.com/developers/devtools/languages/c++.html} | 
|---|
|  | 346 | \item[-] Cray C++ compiler on Unicos \footnote{http://www.sgi.com/software/unicos/cplusoverview.html} | 
|---|
|  | 347 | \end{itemize} | 
|---|
|  | 348 |  | 
|---|
|  | 349 |  | 
|---|
|  | 350 | \end{document} | 
|---|