Program    Unit    Converter

  1. Introduction

    Implementation project Unit Converter belongs to a series of micro-projects in preparation of more elaborated modules for device calibration and numeric simulation of network systems ( cf. C, C++ implementation projects, in German ). Those "proto-projects" shall help identify and resolve common problems. Results - either in terms of programing modules or process definitions or intermediary tools - shall be re-used.

    Most physical parameters can be measured according to different units - e.g. Celsius, Fahrenheit, Kelvin express temperature values. The Unit Converter shall translate values from one unit into others. Here use cases:

    • convert Celsius values into Fahrenheit and Kelvin within range [-10, +10] ( Celsius ) using an incrementation step of 1
    • convert Fahrenheit values into Celsius and Kelvin with range [-30, +30] ( Fahrenheit ) calculated for 13 values

    I chose the topic as an homage to Dennis Ritchie and Brian Kernighan, who wrote the first versions of the ANSI C specification Programming in C. In chapter 1, they discuss various snippets implementing a Converter Celsius-Fahrenheit. Other books introducing to C or C++ - e.g. OOP C++, Erlenkötter - came back to the same example. Its treatment is elementary. And yet, it networks many issues about data representation, access, output, transformation.

    I read the teachers' solutions. I programmed similar tasks in alternative languages e.g. C, Perl, FORTRAN, Basic. The current purpose is to explore genuine C++ perspectives.

    My strategy was to get down to business as soon as possible: C++ code is available, as I write these lines. Not quick and dirty - as may have been the case, if I wanted to deliver one single conversion table - say for the temperature. Some requirements ( see Tab. AUR ) are more difficult to satisfy.

    Besides, prototyping helped assess coding principles that provide additional safeguards - assuming that even Object Orientation, can not guarantee code that is easy to understand and maintain. To retrace all epistemic implications of this effort would go far beyond my scope. Chapters below will only tackle specific aspects.

    • Coding principles:

      For now, I do not intend to write a text explicitly targeting C++. In Perl Projects, I expressed views - see Perl Programming Principles. Chapters I to III should apply to C++ - mutatis mutandis - ( Procedural and object oriented languages manipulate data differently ). Chapter IV about Pattern Matching has no relevance to C++.

    • Iterative character of the process:

      • Starting point is the existing prototype - a command line program, which addressed initial requirements.
      • As implementation and documentation progress, new requirements may emerge or existing ones may need adjustments. They will be implemented, if they represent an evolutionary step.
      • Revolutionary requirements are those which blow the existing framework. If any, they shall be kept in a protocol - as precious seeds for alternative projects.
      • When the documentation is completed, the source code will be released.

  2. Implementation Process

    1. User's Requirements

      No Content
      1

      Keywords General purpose
      Entered by A. Khelil
      Date 05 Feb 2016
      Description A program shall be written that enables a user for physical parameters to select a unit, determine a value ( or a set of values ) and request the corresponding values for other units available.

      2

      Keywords Use Cases
      Entered by A. Khelil
      Date 05 Feb 2016
      Description

      The program will at least be able to treat following cases:

      Parameter Units
      TemperatureCelsius, Fahrenheit, Kelvin
      TimeYear, Day, Week, Hour, Second

      Examples:
      • The user selects any unit ( e.g. Celsius ) and its value to get associated values in other units ( e.g. Fahrenheit, Kelvin ).

      3

      Keywords Operation
      Entered by A. Khelil
      Date 05 Feb 2016
      Description The user will trigger actions by means of a Graphical User Interface ( GUI ).

      4

      Keywords Future Extensions
      Entered by A. Khelil
      Date 05 Feb 2016
      Description It shall be possible to add physical parameters and units at minimum implementation expense.

      Tab. User Requirements ( UR ) ( Stand 05 Feb 2016 )

      Remarks to tables "User's Requirements" ( US )

      • Requirements are data bases:
        The tables above are a way to convey information. But, they are not operational in the real world, where the number of items grows to hundreds and more. Requirements must be entered into a tool, that enables selective data viewing and manipulation according to attribute values ( ideally a relational data base ).

      • Requirements have a "date" attribute:
        Initial requirements were formulated before and during prototyping. Their identification date is ( almost arbitrarily ) set to 05 Feb 2016, ( after initial prototyping ).

      • About User Requirements
        UR express the software contractor's view. In many real world projects, the contractor's list is small, incomplete, vague. Items may even be inconsistent or impossible to realize, because the contractor might not be aware of technical details.

    2. Answers to the User's Requirements

      No Content
      1

      Keywords Operation
      Entered by A. Khelil
      Date 05 Feb 2016
      Answer to 3
      Description Implementing a GUI requires additional techniques - e.g. for exchanging signals between elements. For this reason, a preliminary version will be written as a command line program.
      Statusscheduled
      2

      Keywords Data Model
      Entered by A. Khelil
      Date 05 Feb 2016
      Answer to -
      Description The way how users impact calculations ( by tipping commands on the console, by clicking a mouse ) should not interfere with the underlying data model.
      Statusimplemented
      3
      Keywords Data Model
      Entered by A. Khelil
      Date 05 Feb 2016
      Answer to 2, 4
      Description

      Each physical parameter and associated units shall be encapsulated within a dedicated class, where the conversion formulas are coded:

      Temperature class converter_temperature:
      Method double convert_C_2_F( double Celsius ) for example will convert a Celsius value into its corresponding Fahrenheit value.
      Time class converter_time:
      Method double convert_d_2_h( double Day ) for example will convert a day value into its corresponding hour value.

      Statusimplemented
      4

      Keywords General Purpose
      Entered by A. Khelil
      Date 05 Feb 2016
      Answer to 1
      Description Class cl_calculator will manage all registered converter and invoke them according to the user's input - whether from console or mouse.
      Statusimplemented
      5

      Keywords Console input/output
      Entered by A. Khelil
      Date 05 Feb 2016
      Answer to -
      Description Console input and output shall be programmed consistently through all classes.
      Statusimplemented
      6

      Keywords Console output
      Entered by A. Khelil
      Date 05 Feb 2016
      Answer to -
      Description The ( console ) program shall support different verbosity levels:
      quiet minimum output
      moderate moderate output to trace back crucial steps
      verbose extended output to trace back most steps
      debug maximum output also includes specific steps
      Statusdebug level implemented
      7

      Keywords File input
      Entered by A. Khelil
      Date 12 Feb 2016
      Answer to -
      Description Another pre-version of the software shall read the entire input from a file.
      Statusscheduled
      Tab. Answers to User Requirements ( AUR ) ( Stand 06 Feb 2016 )

      Remarks to table Answers to the User's Requirements ( AUR )
      • The AUR enable readers (commissioners) to grasp the rationale behind solutions that are actually implemented resp. delivered.

      • In some projects, the UR are so mature, that the AUR can straight be written on a one-to-one basis ( homomorphy between UR and AUR ), see as examples the projects commissioned by Giesecke & Devrient from 2001 till 2007: { project OP2.01' (Sunflower), project GP2.1 (Jaguar), project JavaCard2.2 (Jaguar2, Tiger), project GP2.1.1, GP2.2, project ETSI. } According to my experience, projects as thoroughly specified as for chip cards are rather an exception.

      • The AUR shall at least address every single point mentioned by the commissioner.
        As a rule, the AUR will have to address technical aspects, originally ignored. The most efficient way to process is to network available informations. Ideally, the AUR could link all technical documents - and possibly others, if data access is secured. In this micro-project, the AUR will be updated, if necessary, as long as documentation and coding progress.

  3. Data Model

    1. General Structure

      In order to ensure maximum flexibility and legibility, program Unit Converter is articulated over 3 levels - the deeper the layer, the higher its number.

      1. Layer 1 is encapsulated in class cl_calculator that directly interacts with the user. His input amounts to following questions: Which physical parameter? Which reference unit? Which set of values to convert?
      2. The calculator shall process conversions irrespective of the actual physical parameter treated. Therefore, a generic converter class, converter_generic, shall declare all generic ( and abstract ) conversion methods ( layer 2 ).
      3. For each physical parameter an independent class shall be implemented, which defines all abstract methods of its parent class ( the generic converter ).


      Fig. 3 Software layer structure

      Below, I document the layers - beginning with class converter_generic that articulates the whole design.

      Note: Given the fact that this micro-project is a first shot, I will proceed the code documentation manually. In a later step, I will generate most documentation with Doxygen - apart from a short description of the general idea ( meta-level ).

    2. The Generic Converter

      The generic converter describes general behaviors common to all physical converters. It is a basic abstract class.

      1. Non member data

        Together with the class definition, but outside of it, following data are declared ( defined ):

        - Name Type Description
        1 enum_converter enum List of the converter ( class ) id-s available. The enumeration ranking defines ( implicitly ) the converter ( class ) id. ( Note: It is appropriate to instantiate only one converter object of each class.)
        The total number of registered converter classes ( objects ) is stored in nALLOWED_CONVERTER_NAMES
        2 ALLOWED_CONVERTER_NAMES const QString[]

        List of the converter ( class/object ) names.
        The name sequence is homologous to the id sequence.

        Tab. Non member data associated with class converter_generic

        Non member data associated with class converter_generic enable the overall administration of the converter set. They must be extended, each time a new physical converter is implemented.

      2. Member data

        A converter_generic declares following member data and methods:

        - Name Type Description
        1 n_Conv static int Total number of converter objects generated so far.
        ( There shall be only one converter object dedicated to a given physical entity )
        2 id_Conv ( protected ) int Converter Identification number
        expresses the order of the converter object in the generation sequence, see also init_generic_id(void).
        3 name_converter ( protected ) QString Converter Name
        By default ( automatic initialization ), it derives from the identification number. However, the constructor accepts a parameter converter name and ( public ) member functions enable reading and overriding its value.
        4 n_units ( protected ) int Number of units registered
        Note: At generic level, its value is set to zero
        5 names_unit ( protected ) QString* Array bearing all unit names
        Note: At the generic level, the array address is set to zero ( Null pointer ).
        6 vals_unit ( protected ) double* Array bearing all unit values
        The state of a converter is characterized by the values in this array.
        All values associated to different units constantly refer to the same physical state.
        7 id_ref_unit ( protected ) int uid of the reference unit
        the one of which values determine the converter state ( corresponding values associated to the alternative units will be printed ).
        By default, the program selects the first unit listed as reference. The user may pick another one by invoking ( public ) member method set_UID_Ref.
        Tab. Member Data of class converter_generic

        Remarks:

        • A line of conversion table consists in values vals_unit[i], i=0,n_units-1. The printing order ensures that the reference unit always appears first. Therefore a printed line writes following: vals_unit[j], j=( i+id_ref_unit ) mod n_units, i=0,n_units-1

        • By the same token, a table headline prints following: names_unit[j], j=( i+id_ref_unit ) mod n_units, i=0,n_units-1

      3. Member methods

        - Section Name Description
        1 public converter_generic(void)

        1. invokes init( ).
        2 public converter_generic( QString name )

        1. invokes init( ).
        2. invokes setName_Converter( name ) ( overwrites converter name )
        3 public virtual ~converter_generic( )

        1. delete[] names_unit
        2. delete[] vals_unit
        Since only a physical converter can be instantiated, both pointers point to existing addresses.

        4 private void init(void)

        1. n_Conv++
        2. invokes init_generic_id( )
        3. invokes init_generic_name( )
        4. invokes init_generic_units( )
        5 private void init_generic_id(void)

        initializes converter id ( not bound to change after generation )

        1. id_Conv=converter_generic::n_Conv
        6 private void init_generic_name(void)

        initializes converter name by default ( derived from id ).

        1. name_converter="Generic_Converter_id_{id_Conv}"

        The converter name can be overwritten by public member method void setName_Converter( QString name ).

        7 private void init_generic_units(void)

        initializes ( pointer ) values associated with units: A generic converter has no units yet.

        1. n_units=0
        2. names_unit=NULL
        3. vals_unit=NULL
        4. id_ref_unit=0
        8 public void
        setName_Converter( QString name )

        overrides converter name

        1. name_converter=name
        9 public QString getName_Converter(void)

        reads converter name

        1. return name_converter;
        10 public int get_nUnit(void)

        reads number of associated units.
        A physical converter ( derived from class converter_generic ) shall always have at least 2 units.

        1. return n_units;
        11 public void set_UID_Ref( int uid )

        sets id of the reference unit

        1. id_ref_unit=uid;
          if uid is not a legal id, nothing changes and no warning is sent.

        12 public int get_UID_Ref(void)

        reads id of the reference unit

        13 public void set_UID_Ref_FromConsole(void)

        sets id of the reference unit. The user enter his selection onto the console.

        1. prt_units( )
        2. Read id from console
        14 public double getVal_UID( int uid )

        reads current ( state ) value of unit with id=uid

        1. return glb_UCT::ARBITRARY_VALUE;
          if there is no unit at all - see global_UnitConversionTable for details about namespace glb_UCT.

        2. return vals_unit[uid];
          if uid is a legal unit id.

        3. return vals_unit[id_ref_unit];
          if uid is outside range, returns value of the reference unit.

        15 public double getVal_UID_Ref(void)

        reads current state value of the reference unit.

        1. return getVal_UID( id_ref_unit );

        16 public QString getName_UID( int uid )

        reads name of unit with id=uid

        1. return glb_UCT::UNKNOWN_NAME;
          if there is no unit at all - see global_UnitConversionTable for details about namespace glb_UCT.

        2. return names_unit[uid];
          if uid is a legal unit id.

        3. return names_unit[id_ref_unit];
          if uid is outside range, returns name of the reference unit.

        17 public QString getName_UID_Ref(void)

        reads name of reference unit.

        1. return getName_UID( id_ref_unit );

        18 public void prt_Units(void)

        prints list of registered unit ids and names onto the console.

        19 public

        virtual void generateArray_names_unit(void)
        =0

        generates the array containing the names of the registered units ( ordered according to their id ).

        20 public

        virtual void generateArray_vals_unit(void)
        =0

        generates the array containing the values of the registered units ( ordered according to their id ).

        21 public

        virtual void
        setVal_UID( double val, int uid )
        =0

        overwrites state of unit uid with value val

        22 public

        void
        setVal_UID_Ref( double val )

        overwrites state of reference unit with value val

        23 private QString getName_ConvTabCol( int col )

        reads title of column col in conversion table i.e. name of unit associated with this column

        1. int uid= ( col + id_ref_unit ) % n_units;
        2. return names_unit[uid];

        As stated in remarks to Tab. member data of converter_generic, the first column always associates with the reference unit.

        24 private double getVal_ConvTabCol( int col )

        reads value associated with column col of the current conversion line in table

        1. int uid= ( col + id_ref_unit ) % n_units;
        2. return vals_unit[uid];
        25 public void wri_HeadLine_ConvTab(void)

        prints the conversation table headline e.g. the unit names associated to each table column ( invokes QString getName_ConvTabCol( int col ) in a loop ).

        26 public

        void wri_ValLine_ConvTab_4_UID_Ref(void)

        prints a conversation table line e.g. corresponding values for each unit ( invokes double getVal_ConvTabCol( int col ) in a loop ).

        Tab. Member Methods in class converter_generic

        Remarks:

        • The initial implementation version is a console application: output and input originate from the console.

        • Depending on the level value - set or read by void set_output_level( int ), int get_output_level(void) in namespace glb_UCT -, the amount of output differs. If level is set to glb_UCT::OUTPUT_DEBUG, even constructors, destructors and initialization steps are protocoled.

        • Console output methods are green highlighted . Virtual methods are red highlighted ( to be implemented by derived physical converters ).

    3. Physical Converter

      According to AUR no. 3, each physical converter shall be coded in an separate class ( derived from class converter_generic ). At least 2 classes shall be implemented: converter_temperature, converter_time. As an example, the first one is documented below.

      1. Non member data

        - Name Type Description
        1 enum_unit_temperature enum

        List of the unit id-s available:

        enum {
        unit_celsius,
        unit_fahrenheit,
        unit_kelvin,
        nUNIT_TEMPERATURE
        }
        1. The enumeration ranking defines ( implicitly ) the unit id.
        2. The total number of registered units for converter_temperature is nUNIT_TEMPERATURE.
        Tab. Non member data in class converter_temperature

        Non member data listed in the table above enable the overall administration of associated units. They must be implemented accordingly by any physical converter: Each unit must be registered.

        Additional parameters, specific to a given physical converter, can also be defined. As an example const MAX_CELSIUS was defined that might provide an upper limit to the calculation range ( not activated though ).

      2. Member data

        All member data have been declared at the generic level.

      3. Member methods

        - Section Name Description
        1 public converter_temperature(void);

        1. converter_generic( );
        2. init( );
        2 public converter_temperature(
        QString Name );

        1. converter_generic( Name );
        2. init( );
        3 public ~converter_temperature( );

        4 private void init(void);

        1. n_units=nUNIT_TEMPERATURE;
        2. generateArray_names_unit( );
        3. generateArray_vals_unit( );

        5 public void generateArray_names_unit(
        void )

        Creates and populates array for unit names:

        1. names_unit = new QString[nUNIT_TEMPERATURE];
        2. names_unit[unit_celsius] = "celsius ( C )";
        3. names_unit[unit_fahrenheit] =
          "fahrenheit ( F )";
        4. names_unit[unit_kelvin] = "kelvin ( K )";
        6 public void generateArray_vals_unit(
        void )

        Creates and populates array for unit values. The Celsius value is set to an arbitrary value ( and the other units accordingly ).

        1. vals_unit = new double[nUNIT_TEMPERATURE];
        2. setValue_C( glb_UCT::ARBITRARY_VALUE );
        7 public void setVal_UID( double val,
        int uid )

        Updates array vals_unit, depending on the uid value ( switch operator )

        1. setValue_C( val );
        2. setValue_F( val );
        3. setValue_K( val );
        8 public void setValue_C( double val )

        Sets the Celsius value - and updates other units accordingly.

        1. vals_unit[unit_celsius] = val;
        2. vals_unit[unit_fahrenheit] = convert_C_2_F( val );
        3. vals_unit[unit_kelvin] = convert_C_2_K( val );
        9 public void setValue_F( double val )

        Sets the Fahrenheit value - and updates other units accordingly.

        1. vals_unit[unit_celsius] = convert_F_2_C( val );
        2. vals_unit[unit_fahrenheit] = val
        3. vals_unit[unit_kelvin] = convert_C_2_K( vals_unit[unit_celsius] );
        10 public void setValue_K( double val )

        Sets the Kelvin value - and updates other units accordingly.

        1. vals_unit[unit_celsius] = convert_K_2_C( val );.
        2. vals_unit[unit_fahrenheit] = convert_C_2_F( vals_unit[unit_celsius] );
        3. vals_unit[unit_kelvin] = val;
        11 private void convert_C_2_F(
        double celsius )

        Converts a Celsius value into the corresponding Fahrenheit value.

        1. return ( celsius * 9.0/5.0 ) + 32.0 );
        12 private void convert_C_2_K(
        double celsius )

        Converts a Celsius value into the corresponding Kelvin value.

        1. return ( celsius + 273.15 );
        13 private void convert_F_2_C(
        double fahrenheit )

        Converts a Fahrenheit value into the corresponding Celsius value.

        1. return ( ( fahrenheit - 32 ) * 5.0/9.0 );
        14 private void convert_K_2_C( double kelvin )

        Converts a Kelvin value into the corresponding Celsius value.

        1. return ( kelvin - 273.15 );
        Tab. Member methods in class converter_temperature

        Remarks:

        1. Implemented virtual methods of the parent class are red highlighted .

        2. The setValue methods have been declared public for testing purposes. From the converter point of view, they 'd better be declared private, as the convert methods have been.

  4. Calculation module

    1. Concept

      In order to generate a conversion table of units, a "superstructure" must be implemented that receives its input from the user and invokes ( the actual calculation ) methods from the proper converter ( object of class converter_generic ). I chose to implement a solution based on the concept of calculator ( class cl_calculator ). A calculator operates on 2 levels:

      1. A calculator maintains a list of all converters it needs.
        For that reason, there shall be only one calculator object ( singleton class ). Also there shall be only one converter object instantiated associated to a specific physical converter.

      2. It communicates with the user. Required are at least following data:

        1. The physical parameter ( e.g. temperature )
        2. The reference unit ( e.g. Celsius )
        3. Minimal value ( of the reference unit ) in the conversation table
        4. Maximal value ( of the reference unit ) in the conversation table
        5. One parameter deciding about the amount of results to produce: either the number of calculations or the calculation step.

      The advantage is that, if correctly implemented, the same cl_calculator can be used, no matter how the user communicates: console or GUI or even input data file. ( Off course additional methods must be implemented depending on the case. )

    2. Non member data

      Empty set.

    3. Member data

      - Name Type Description
      1 n_calc static int

      Number of calculator objects instantiated so far.
      There shall be only one calculator object ( singleton ).

      2 TheCalculator static cl_calculator*

      Pointer to the unique calculator object.
      There shall be only one calculator object ( singleton ).

      3 calc_id int

      Identification number of the calculator object ( equal to the instantiation order ).

      4 calc_name QString

      calculator name.
      At instantiation, the automatically attributed name derives from the id. It is possible to change this name "manually" any time later.

      5 ListOfConverters[
      nALLOWED_CONVERTER]      		 static converter_generic*

      List of all converter objects, that the calculator currently maintains.
      There won't be more converter objects than there are associated classes: A specific converter class is only instantiated if required and only once.

      6 id_cur_converter int

      Identification number of the converter object currently in use.

      7 name_cur_converter QString

      Name of the converter object currently in use.
      8 min_ValTab double

      Minimal value ( of the reference unit ) in the conversion table.

      9 max_ValTab double

      Maximal value ( of the reference unit ) in the conversion table.

      10 delta_ValTab double

      Calculation step ( of the reference unit ) in the conversion table.

      11 n_ValTab int

      Number of calculations ( lines ) in the conversion table.

      12 n_iteration int

      A calculator can calculate a new conversion table any number of times ( each time asking for the table parameters anew ). The total number of repetition is kept protocoled in n_iteration.

      Tab. Member Data in class cl_calculator

      Remarks:

      • To maintain name_cur_converter is not necessary, since it can be any time derived from id_cur_converter.

      • The number of lines in conversion table can be determined in 2 manners: either set value of delta_ValTab or value of n_ValTab. The user enters only one value ( depending on the method selected ) and the other one is derived accordingly. It seems more natural to determine a calculation step.

    4. Member methods

      - Section Name Description
      1 private cl_calculator(void)

      Constructor processes following steps:

      1. set_calc_id( );
      2. set_calc_name( );
      3. n_iteration=0;
      It cannot be invoked itself.

      2 public static cl_calculator* getTheCalculator(void)

      Retrieves the calculator object:

      1. Instantiates a calculator object, if no one has been yet and stores the pointer to member TheCalculator.
      2. return TheCalculator;
      3 public static int get_numberOf_cl_calculator(void)

      Retrieves the number of calculator objects ( should always be one )

      1. return n_calc;
      4 public ~cl_calculator( )

      Destructor:

      Also deletes every converter object instantiated so far ( pointed to in ListOfConverters ).

      5 public int get_n_iteration(void)

      Method is in line defined:

      1. return n_iteration;
      6 public void set_calc_id(void)

      Initializes the identification number of the calculator ( never to be changed afterwards ):

      1. calc_id = ++n_calc;
      7 public int get_calc_id(void)

      Retrieves the identification number of the calculator:

      1. return calc_id;
      8 public void set_calc_name(void)

      Associates a name by default to the calculator:

      1. calc_name = "calculator_" + QString::number( get_calc_id( ) );
      9 public QString get_calc_name(void)

      Retrieves the calculator name:

      1. return calc_name;
      10 public void prt_Converters(void)

      Prints the list of all converter names that can be associated to the calculator.
      They are listed in array ALLOWED_CONVERTER_NAMES ( non member data associated with class converter_generic ).

      The display of list shall help the user to see what is available and make his choice.

      11 public void set_id_SelectedConverter(
      const int id )

      Selects current converter:

      1. id_cur_converter = id;

      If the passed id is illegal ( does not correspond to one registered id ), nothing changes. However an error is thrown.

      12 public int get_id_SelectedConverter(void)

      Retrieves current converter:

      1. return id_cur_converter;
      13 public void prt_id_SelectedConverter(void)

      Writes name of the current selected converter onto the console.

      14 public void setNam_SelectedConverter(
      const QString NamCurConv )

      Updates name of the currently selected converter:

      1. name_cur_converter = namCurConv;
      15 public void setNam_SelectedConverter(
      const int idCurConv )

      Updates name of the currently selected converter in the list of converter names:

      1. name_cur_converter = ALLOWED_CONVERTER_NAMES[idCurConv];
      16 public QString getNam_SelectedConverter(void)

      Retrieves name of the the currently selected converter:

      1. return name_cur_converter;
      17 public converter_generic* get_SelectedConverter(void) Retrieves the selected converter object:

      1. int id = get_id_SelectedConverter( );
      2. return ListOfConverters[id];
      18 public void upd_ConverterList(
      const int idCurConv )

      Updates element idCurConv of converter list, ListOfConverters[idCurConv] - which points to converter class bearing id idCurConv.

      1. If id idCurConv connects to a registered converter ( class ), then it is ensured that ListOfConverters[idCurConv] points to a proper converter object.
      2. If idCurConv is illegal, an error message is printed and the currently selected converter is set to the default one - which is converter_temperature.

      19 public void upd_ConverterList(void)

      Updates currently selected converter in list ListOfConverters[].

      1. upd_ConverterList( id_cur_converter );

      20 public void sel_Converter_FromConsole(void)

      Selects converter from console:

      1. prt_Converters( );
      2. The user is prompted to enter the id of converter he wants to activate.
        Note: The question is repeated, till the user enters a legal id value.
      3. upd_ConverterList( );
      4. get_SelectedConverter( )-> set_UID_Ref_FromConsole( );
        The user is prompted to enter the reference unit from console.

      21 public void set_ConversionTab_MinMax_n(
      double min, double max, unsigned int n=1 )

      Following parameters of the conversion table are set:

      1. min_ValTab=min
      2. max_ValTab=max
      3. n_ValTab=n

      Plausibility controls are performed on the passed values. Under circumstances, they will be corrected ( no error message is delivered though ).

      22 public void set_ConversionTab_MinMax_n_FromConsole(void)

      Following parameters of the conversion table are requested from the console:

      1. min_ValTab=min
      2. max_ValTab=max
      3. n_ValTab=n

      The values min, max, n are checked before being adopted ( set_ConversionTab_MinMax_n( min, max, n ); ).

      23 public void set_ConversionTab_MinMax_Delt(
      double min, double max, double delt=1.0 )

      Following parameters of the conversion table are set:

      1. min_ValTab=min
      2. max_ValTab=max
      3. delta_ValTab=delt

      Plausibility controls are performed on the passed values. Under circumstances, they will be corrected ( no error message is delivered though ).

      24 public void set_ConversionTab_MinMax_Delt_FromConsole(void)

      Following parameters of the conversion table are requested from the console:

      1. min_ValTab=min
      2. max_ValTab=max
      3. delta_ValTab=delt

      The values min, max, delt are checked before being adopted ( set_ConversionTab_MinMax_Delt( min, max, delt ); ).

      25 public void prt_Pars_ConversionTab_MinMax(void)

      Prints parameters of conversion table to be currently calculated:

      1. min_ValTab: minimal value of reference unit to convert
      2. max_ValTab: maximal value of reference unit to convert
      3. Delt_ValTab: step between consecutive values
      4. n_ValTab: number of values converted
      26 public void calc_conversion_table(
      const int idCurConv )

      Calculates and prints an conversation table using converter identified with idCurConv.

      Among other steps, following methods are invoked:

      1. prt_Pars_ConversionTab_MinMax();
      2. TheConv->wri_ValLine_ConvTab_4_UID_Ref(val);
      27 public void calc_conversion_table(void)

      Normally the conversion table to calculate is linked with the currently selected converter id_cur_converter,

      1. calc_conversion_table(id_cur_converter);
      28 public void do_iteration(void)

      Collects all steps required to calculate one conversion table - marked as "an iteration".

      1. n_iteration++;
      2. set_ConversionTab_MinMax_Delt_FromConsole();
      3. calc_conversion_table();
      Tab. Member Methods in class cl_calculator

  5. Console Implementation

    1. Code Sample

      Using class cl_calculator the main program is quite simple. It consists basically of 2 steps:

      1. Initialization step: cl_calculator* TheCalc = cl_calculator::getTheCalculator();
      2. Calculation step: TheCalc→do_iteration();. This calculation step may be embedded within an iteration loop, at which end the user is asked whether he wants to continue.

      Below a code sample to validate the implementation:

      void test_calculator(void)
      {
      cl_calculator* TheCalc = cl_calculator::getTheCalculator();
      bool more_It = false;
      std::string answer;
      do {
      std::cin.ignore(100,'\n');
      std::cout << std::endl << "→ Do you want to calculate another conversion table? (y or yes) : ";
      std::getline (std::cin,answer);
      std::cout << std::endl << "answer=[" << answer << "]";
      if (toupper (answer[0]) == 'Y')
      {
      more_It = true;
      TheCalc→do_iteration();
      }
      else
      {
      more_It = false;
      std::cout << std::endl << "→Treatment aborted: "<< TheCalc→get_n_iteration() <<
      " iterations have been performed. bye.";
      }
      } while (more_It);
      delete TheCalc;
      return;
      }

    2. Download

      To download release versions of the console implementation click Download Table.