Difference between revisions of "Subclassing Application Class"

From MorphOS Library

(Next subchapter.)
(Crosslinking++;)
 
(31 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
''Grzegorz Kraszewski''
 
''Grzegorz Kraszewski''
 +
----
 +
<small>This article in other languages: [[Klasy pochodne od klasy "Application"|Polish]]</small>
  
  
−
==Introduction==
+
Every MUI application is (or at least should be) an [[Event Driven Programming, Notifications|event driven]] one. This means the application provides a set of actions, which may be triggered with user activity (like using the mouse and keyboard). The straightforward way of implementing this set of actions is to implement it as a set of methods added to some MUI object. For simple programs, the best candidate for adding such methods is the master ''Application'' object. More complex programs (for example ones using a multi-document interface) may add actions to other classes, for example the ''Window'' class.
−
Every MUI application is (or at least should be) an event driven one. It means the application provides a set of actions, which may be triggered with user activity (like using mouse and keyboard). The straightforward way of implementing this set of actions is to implement it as a set of metods added to some MUI object. For simple programs, the best candidate for adding such methods is the master ''Application'' object. More complex programs (for example ones using multi-document interface) may add actions to other classes, for example ''Window'' one.
 
  
 
Why methods? Implementing actions as methods has many advantages:
 
Why methods? Implementing actions as methods has many advantages:
−
* Methods may be used directly as notification actions. It saves a programmer from using hook tricks or cluttering the main loop with teens of ''ReturnID'' values.
+
* Methods may be used directly as [[Event Driven Programming, Notifications#Notifications in MUI|notification]] actions. It saves a programmer from using hook tricks or cluttering the main loop with lots of ''ReturnID'' values.
 
* Methods may be coupled directly with scripting language interface (formerly known as ARexx interface) commands.
 
* Methods may be coupled directly with scripting language interface (formerly known as ARexx interface) commands.
−
* Methods used in notifications are executed immediately in response of user actions. No delay is introduced by the main loop (especially if it is not empty).
+
* Methods used in notifications are executed immediately in response to user actions. No delay is introduced by the main loop (especially if it is not empty).
−
* A notification triggering attribute value may be passed directly to method, as its parameter.  
+
* A notification triggering attribute value may be [[Event Driven Programming, Notifications#Reusing Triggering Value|passed directly]] to a method as its parameter.  
−
* Using methods improves code modularity.
+
* Using methods improves code modularity and object encapsulation. Functionality meant to be handled in the scope of an object is handled in its method, without the code spreading across the project.
  
−
 
+
In a well designed MUI program, all program actions and functionality are implemented as methods and the program internal state is stored as a set of attributes and internal application instance data fields. An example of such a program is discussed throughly in the [[MUI Subclassing Tutorial: SciMark2 Port]] article.
−
==The Application==
 
−
Many programming tutorials tend to bore readers with some useless examples. In this one a "real world" application will be ported to MorphOS and "MUI-fied". The application is [http://math.nist.gov/scimark2/index.html SciMark 2]. SciMark is yet another CPU/memory benchmark. It performs some typical scientific calculations like Fast Fourier Transform, matrix LU decomposition, sparse matrix multiplication and so on. The benchmark measures mainly CPU speed at floating point calculations, cache efficiency and memory speed. Being written in Java initially, it has been rewritten in C (and in fact in many other languages). The C source is available on the [http://math.nist.gov/scimark2/download_c.html project homepage].
 
−
 
 
−
The source uses only pure ANSI C standard, so it is easily compilable on MorphOS using provided ''Makefile''. One has just replace ''$CC = cc'' line to ''$CC = gcc'', to match the name of the MorphOS compiler. As a result, a typical shell-based application is obtained. Here are example results for a Pegasos 2 machine with G4 processor:
 
−
 
 
−
 
 
−
[[File: scimark_cli_noopt.png|center]]
 
−
 
 
−
 
 
−
Not very impressive in fact. This is because no optimizaton flags are passed to the compiler in the makefile. They can be added by inserting a line ''$CFLAGS = -O3'' below the ''$CC = gcc'' one. Let's also link with ''libnix'' (a statically linked unix environment emulation, see [[Installation_of_Software_Development_Kit_and_its_basic_usage#Standard_C_and_C.2B.2B_Libraries|Standard C and C++ Libraries]]) by adding ''-noixemul'' to ''CFLAGS'' and ''LDFLAGS''. After rebuilding the program and running it again the results are significantly improved (the program has been compiled with GCC 4.4.4 from the official SDK).
 
−
 
 
−
 
 
−
[[File: scimark_cli_opt.png|center]]
 
−
 
 
−
 
 
−
This shows how important is optimization of the code, especially computationally intensive one. Optimized code is '''more than 4 times faster'''!
 
−
 
 
−
 
 
−
==Code Inspection==
 
−
The original source code is well modularized. Five files: ''FFT.c'', ''LU.c'', ''MonteCarlo.c'', ''SOR.c'' and ''SparseCompRow.c'' implement the five of single benchmarks. Files ''array.c'' and ''Random.c'' contain auxiliary functions used in benchmarks. File ''Stopwatch.c'' implements time measurement. An important file ''kernel.c'' gathers all the above and provides five functions performing complete benchmarks with timing. Finally ''scimark2.c'' contains the ''main()'' function and implements the shell interface.
 

Latest revision as of 13:49, 27 January 2011

Grzegorz Kraszewski

This article in other languages: Polish


Every MUI application is (or at least should be) an event driven one. This means the application provides a set of actions, which may be triggered with user activity (like using the mouse and keyboard). The straightforward way of implementing this set of actions is to implement it as a set of methods added to some MUI object. For simple programs, the best candidate for adding such methods is the master Application object. More complex programs (for example ones using a multi-document interface) may add actions to other classes, for example the Window class.

Why methods? Implementing actions as methods has many advantages:

  • Methods may be used directly as notification actions. It saves a programmer from using hook tricks or cluttering the main loop with lots of ReturnID values.
  • Methods may be coupled directly with scripting language interface (formerly known as ARexx interface) commands.
  • Methods used in notifications are executed immediately in response to user actions. No delay is introduced by the main loop (especially if it is not empty).
  • A notification triggering attribute value may be passed directly to a method as its parameter.
  • Using methods improves code modularity and object encapsulation. Functionality meant to be handled in the scope of an object is handled in its method, without the code spreading across the project.

In a well designed MUI program, all program actions and functionality are implemented as methods and the program internal state is stored as a set of attributes and internal application instance data fields. An example of such a program is discussed throughly in the MUI Subclassing Tutorial: SciMark2 Port article.

Retrieved from "https://library.morph.zone/index.php?title=Subclassing_Application_Class&oldid=1221"