next up previous contents index
Next: VII.1 CLA classes Up: VII. FeResPost as .NET Previous: VII. FeResPost as .NET   Contents   Index

Subsections


VII.0 Introduction

On Windows OS, FeResPost is distributed at the same time as a ruby extension, a COM component and as a .NET assembly. One describes in this Part several characteristics of FeResPost as a .NET assembly.

In general, the class names, their methods and attributes (properties), the parameters of these methods and attributes are the same as those available in the FeResPost ruby extension. When necessary, modifications have been done in the ruby extension in order to maintain as much as possible the compatibility between the ruby extension and the .NET assembly. Therefore, the user is referred to Parts I, II, III and IV to find information on the use of the different classes and methods. In most cases, the information given there is sufficient to use the .NET assembly.

However, an exact match between the ruby extension and .NET assembly is not possible. One details below the conventions that have been adopted when incompatibility problems were not solved. More generally, one explains here the specific aspects of the use of FeResPost as a .NET assembly.

This Part of the document is organized as follows:

The installation of the .NET assembly is described in section IX.A.3.5.

In section VII.0.1, one describes conventions that have been adopted when translating the ruby extension into a .NET assembly. Information is given each time the ruby methods are modified to be implemented into the .NET assembly. For example, this is done for iterators, operators, ``clone'' method... Also one explains how objects are created with the assembly.


VII.0.1 .NET assembly versus ruby extension

One highlights below some differences between .NET assembly and ruby extension that are related to specific programmatic aspects of the two different systems.


VII.0.1.1 Accessing the .NET assembly

If FeResPost assembly is installed into global assembly cache, no peculiar operation is necessary to access it from IronRuby. If FeResPost is not installed in global assembly cache, a path must be provided to IronRuby to retrieve the library. This is done, for example, with the ``-I'' option.

When compiling a C# program, the library must be referenced at compile-time with the ``-r'' option. For example:

        csc.exe -r:../../../SRC/OUTPUTS/NET/FeResPost.dll ...
This referencing must be done, even if the library is installed in global assembly cache. Note however, that after compiling the C# client program, this program can be moved elsewhere independently of the FeResPost assembly, if this assembly has been installed in Global Assembly Cache.

We assume that was is true for IronRuby, shall be true for other .NET interpreted languages as well. Similarly, what is true for C# compiled programs is applicable for other CLI compiled languages (C++/CLI or VB/CLI).


VII.0.1.2 Accessing FeResPost namespace

All classes of the FeResPost .NET assembly are defined in ``FeResPost'' namespace. To simplify the access to FeResPost classes and methods, it is recommended to give access to the content of the namespace.

In ruby, this is done by including FeResPost Module into the current workspace:

   ...
   include FeResPost
   ...
In C#, one uses using directives:
    ...
    using FeResPost ;
    ...
The same is true for C++.NET language, but with a different syntax:
    ...
    using namespace FeResPost ;
    ...


VII.0.1.3 Creating class instances

The creation of FeResPost objects depends on the language with which .NET assembly is used. In all cases, the ``new'' operator is used. For example to create a ClaDb object in ruby, one writes:

    ...
    db=ClaDb.new
    ...
The same operation is done as follows in C#:
    ...
	ClaDb db;
    db=new ClaDb();
    ...
(Note that the variable db has been declared before being initialized.)


VII.0.1.4 Basic types as arguments and returned values

In FeResPost .NET assembly, the following default types are used for parameters:

The different classes defined in FeResPost assembly are reference managed classes. The examples given in Part VIII should clarify the use of arguments.


VII.0.1.5 Associative containers and Arrays

When methods of ruby extension receive or return Array objects, .NET assembly also returns Arrays of different types of objects. The difference is that .NET Arrays may have several dimensions. For example, the C++/CLI definition of several methods of the ClaLam class reads as follows:

    ...
    array<float,2>^ get_ABBD(...array<float>^ varargs) ;
    array<float,2>^ get_G(...array<float>^ varargs) ;
    array<float>^ get_alfaEh1(...array<float>^ varargs) ;
    ...
The two first methods above return 2D arrays, instead of 1D arrays of 1D arrays, for ruby extension.

Similarly, when a FeResPost method of ruby extension receives or returns a Hash object, the corresponding method of .NET assembly deal with a Dictionary. For examples, the methods of CLA classes devoted to management of units are declared as follows:

    ...
    System::Collections::Generic::Dictionary<System::String^,
            System::String^>^ getUnits(void) ;
    void setUnits(System::Collections::Generic::Dictionary<
            System::String^,System::String^>^ Units) ;
    void changeUnits(System::Collections::Generic::Dictionary<
             System::String^,System::String^>^ Units) ;
    ...


VII.0.1.6 Iterators

.NET provides a standard interface that allows the writing of iterators on collections of different types. In FeResPost, all the iterators are based on two classes:

As for the COM component, two classes devoted to iterations have been added because it does not seem possible to create a class that proposes several enumerators.

The ``Iterator'' class is common to all the iterators of all the FeResPost classes. But an Iterator object behaves differently depending on the class that produces it and/or the method of the class that is used to produce it.

Let us illustrate it by an example... Consider the ``each_ply'' iterator defined in ClaLam class of FeResPost ruby extension. With the ruby extension, the iteration on the plies of a laminate may be performed as follows:

   ...
   lam.each_ply do |plyDescr|
      ...
   end
   ...
With FeResPost .NET assembly and IronRuby, an Iterator must first be produced before iterating on the elements of the corresponding collection. This can be done as follows:
   ...
   plyIt = lam.iter_ply
   plyIt.each do |plyDescr|
      ...
   end
   ...
This examples illustrates the conventions that have been used when programming the FeResPost .NET assembly to transpose the iterators proposed in the ruby extension:
  1. As in the FeResPost ruby extension, each iterator method name starts with ``each_'', correspondingly, the .NET assembly methods returning an Iterator object have a name that starts with ``iter_''. The correspondence between ruby extension methods and .NET assembly methods is obvious: ``each_ply'' becomes ``iter_ply'', ``each_material'' becomes ``iter_material'',...
  2. When the .NET iteration method has no argument, it is a property ``getter'' that is used instead of a method. Otherwise, a method with argument is defined.
  3. In IronRuby using the .NET assembly, the iteration on the Iterator object is done using ``each'' iteration method.
Note that to the IronRuby lines given as example above, one prefers the shorter notation:
   ...
   lam.iter_ply.each do |plyDescr|
      ...
   end
   ...


VII.0.1.7 Operators

Operators are defined in the different classes to which they apply (Group, Result, ResKeyList...). Note that C++/CLI allows to define in managed classes static operators the first operand of which is an object that is not an instantiation of the class. This allows, for example, to define dyadic operators the first operand of which is a float, and the second operand of which a Result object.

In ruby extension, the definition of such operators is prohibited because it involves the modification of ruby standard classes. Instead, these operators are defined as singleton methods in ``Post'' Module (``opAdd'', ``opMul''...). (See also section VII.0.1.10.)


VII.0.1.8 Singleton methods

Ruby ``singleton'' methods of FeResPost classes are defined as static functions of FeResPost managed classes.


VII.0.1.9 ``Clone'' and ``ToString'' methods

Most FeResPost managed classes implement the ``ICloneable'' interface and define a ``Clone'' method that corresponds to ruby ``clone'' method in FeResPost ruby extension. ``Post'' static class does not derive from ICloneable, as this class can not be instantiated. Also, the classes deriving from ``DataBase'' (``NastranDb'' and ``SamcefDb'' classes) do not implement the ``Clone'' method.

The ``to_s'' method of ruby extension are replaced by ``ToString'' method in .NET assembly.


VII.0.1.10 ``Post'' static class

FeResPost does not define Modules. The ruby extension ``Post'' Module is replaced a static ``Post'' class in .NET assembly. More precisely, ``Post'' class defines only static methods and no constructor/destructor.

All the methods defined in ``Post'' module of ruby extension are defined in ``Post'' static class, except the four methods corresponding to dyadic operators.


VII.0.1.11 Complex arguments

complex arguments are input as 1D Arrays of two float or double values.


next up previous contents index
Next: VII.1 CLA classes Up: VII. FeResPost as .NET Previous: VII. FeResPost as .NET   Contents   Index
FeResPost 2017-05-28