If you have been using Hibernate for some time you should know that the best way to map a one-to-many relationship is through a bidirectional @OneToMany association where the mappedBy attribute is set. It is well explained in this article:

The best way to map a @OneToMany relationship with JPA and Hibernate

See also the Hibernate ORM User Guide.

Now, in honour of Saint Thomas, we are going to verify ourselves if that's true. Furthermore we will investigate what happens when we add the @OrderColumn annotation.

Sample project

Source code

The sample project is based on Hibernate 5.4.1.Final and Postgres. There are two tables, master and slave, with auto-incrementing primary keys. The slave table has a foreign key on id_master and a column named index which will be used later with @OrderColumn.

CREATE TABLE master
(
    id          serial     NOT NULL,
    description text,
    CONSTRAINT master_pkey PRIMARY KEY (id)
)

CREATE TABLE slave
(
    id          serial     NOT NULL,
    description text,
    id_master   integer,
    index       integer,
    CONSTRAINT slave_pkey PRIMARY KEY (id),
    CONSTRAINT slave_master_fk FOREIGN KEY (id_master)
        REFERENCES master (id)
)

Unidirectional association

First case. We have two entities, Master and Slave. Master has a list of slaves mapped with @OneToMany and @JoinColumn annotations, the mappedBy attribute is not used. Slave has no association towards Master.

@Entity(name = "MasterNoOrderUni")
@Table(name = "master")
public class Master
{
 @Id
 @GeneratedValue(strategy = GenerationType.IDENTITY)
 private int id = 0;
 
 private String description = "";

 @OneToMany(
   cascade = CascadeType.ALL,
   orphanRemoval = true)
 @JoinColumn(name = "id_master")
 private List<Slave> slaves = null;

// ...

 public void addSlave(String description)
 {
  Slave slave = new Slave(this, description);
  slaves.add(slave);
 }

// ...
}

@Entity(name = "SlaveNoOrderUni")
@Table(name = "slave")
public class Slave
{
 @Id
 @GeneratedValue(strategy = GenerationType.IDENTITY)
 private int id = 0;
 
 private String description = "";

// ...
}

Then, this is the code to persist a new Master and three Slave instances. I hope you will not be offended by what you are going to read, JPA providers are hellish tools.

 app.ms.noOrderColumn.unidirectional.Master master = 
  new app.ms.noOrderColumn.unidirectional.Master("Devil");
 master.addSlave("Devil's slave A");
 master.addSlave("Devil's slave B");
 master.addSlave("Devil's slave C");
 
 EntityManager em = emf.createEntityManager();
 em.getTransaction().begin();
 
 em.persist(master);
 
 em.getTransaction().commit();
 em.close();

Revised console output follows.

    insert into master
        (description) 
    values
        ('Devil')

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 13


    insert into slave
        (description) 
    values
        ('Devil''s slave A')

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 37

    insert into slave
        (description) 
    values
        ('Devil''s slave B')

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 38

    insert into slave
        (description) 
    values
        ('Devil''s slave C')

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 39


    update slave set
        id_master=13 
    where
        id=37

    update slave set
        id_master=13 
    where
        id=38

    update slave set
        id_master=13 
    where
        id=39

Clearly the three update statements could have been avoided. The insert statements are executed on the persist instruction, the update statements are executed on the commit instruction. It is all implementation-related.

Bidirectional association

Second case. A @ManyToOne and a @JoinColumn have been added to Slave, so now a bidirectional association is in place.

This is not a bidirectional association in JPA terms (see SR 338: Java Persistence 2.2 - page 44, 2.9 Entity Relationship) but in this context we need to make a distinction, that is: Bidirectional association vs Bidirectional association with mappedBy.

@Entity(name = "MasterNoOrderBi")
@Table(name = "master")
public class Master
{
// ...
 
 @OneToMany(
   cascade = CascadeType.ALL,
   orphanRemoval = true)
 @JoinColumn(name = "id_master")
 private List<Slave> slaves = null;

// ...
}

@Entity(name = "SlaveNoOrderBi")
@Table(name = "slave")
public class Slave
{
// ...
 
 @ManyToOne
 @JoinColumn(name = "id_master")
 private Master master = null;

// ...
}

Here there is only a German difference.

 app.ms.orderColumn.bidirectional.Master master = 
  new app.ms.orderColumn.bidirectional.Master("Teufel");
 master.addSlave("Teufel's slave A");
 master.addSlave("Teufel's slave B");
 master.addSlave("Teufel's slave C");
 
// ...

The output.

    insert into master
        (description) 
    values
        ('Teufel')

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 14


    insert into slave
        (description, id_master) 
    values
        ('Teufel''s slave A', 14)

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 40

    insert into slave
        (description, id_master) 
    values
        ('Teufel''s slave B', 14)

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 41

    insert into slave
        (description, id_master) 
    values
        ('Teufel''s slave C', 14)

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 42


    update slave set
        id_master=14 
    where
        id=40

    update slave set
        id_master=14 
    where
        id=41

    update slave set
        id_master=14 
    where
        id=42

We still have inefficiency. d_master is set immediately with the insert statements but the same identical result could have been obtained in the previous case by setting @JoinColumn with nullable to false.

 @JoinColumn(name = "id_master", nullable = false)

So, effectively, we can consider this case like a unidirectional association.

Bidirectional association with mappedBy

Third case. This time Master has a @OneToMany annotation and the mappedBy attribute is there in all its glory, moreover no @JoinColumn is present because the field that owns the relationship is in Slave.

@Entity(name = "MasterNoOrderBiMappedBy")
@Table(name = "master")
public class Master
{
// ...
 
 @OneToMany(
   mappedBy = "master",
   cascade = CascadeType.ALL,
   orphanRemoval = true)
 private List<Slave> slaves = null;

// ...
}

@Entity(name = "SlaveNoOrderBiMappedBy")
@Table(name = "slave")
public class Slave
{
// ...
 
 @ManyToOne
 @JoinColumn(name = "id_master")
 private Master master = null;

// ...
}

Here there is only a Spanish difference.

 app.ms.orderColumn.bidirectional.mappedBy.Master master = 
  new app.ms.orderColumn.bidirectional.mappedBy.Master("Diablo");
 master.addSlave("Diablo's slave A");
 master.addSlave("Diablo's slave B");
 master.addSlave("Diablo's slave C");
 
// ...

And the result is shorter than before.

    insert into master
        (description) 
    values
        ('Diablo')

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 15

    insert into slave
        (description, id_master) 
    values
        ('Diablo''s slave A', 15)

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 43

    insert into slave
        (description, id_master) 
    values
        ('Diablo''s slave B', 15)

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 44

    insert into slave
        (description, id_master) 
    values
        ('Diablo''s slave C', 15)

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 45

The three update statements previously seen have disappeared, this is what we would have expected from the start. It is confirmed, the bidirectional association with mappedBy is the best way to map a @OneToMany relationship (with Hibernate, for now).

@OrderColumn

But what happens when @OrderColumn is used to maintain order between the slaves?

Several past Hibernate versions were having problems with @OrderColumn (or the deprecated @IndexColumn) when it was combined with @OneToMany and mappedBy (e.g., see here, here and here).

Now we have to put the finger in this wound also, adding @OrderColumn to the previous mappings.

// ...
// Unidirectional

 @OneToMany(
   cascade = CascadeType.ALL,
   orphanRemoval = true)
 @JoinColumn(name = "id_master")
 @OrderColumn(name = "index", nullable = false)
 private List<Slave> slaves = null;

// ...
// Bidirectional with mappedBy

 @OneToMany(
   mappedBy = "master",
   cascade = CascadeType.ALL,
   orphanRemoval = true)
 @OrderColumn(name = "index", nullable = false)
 private List<Slave> slaves = null;

// ...

Output for the unidirectional association.

/* 
    Unidirectional
*/

    insert into master
        (description) 
    values
        ('Devil')

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 16


    insert into slave
        (description) 
    values
        ('Devil''s slave A', 16)

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 46

    insert into slave
        (description, id_master) 
    values
        ('Devil''s slave B', 16)

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 47

    insert into slave
        (description, id_master) 
    values
        ('Devil''s slave C', 16)

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 48


    update slave set
        id_master=16,
        index=0 
    where
        id=46

    update slave set
        id_master=16,
        index=1 
    where
        id=47

    update slave set
        id_master=16,
        index=2 
    where
        id=47

Output for the bidirectional association with mappedBy.

/*
    Bidirectional with mappedBy
*/

    insert into master
        (description) 
    values
        (Diablo)

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 18


    insert into slave
        (description, id_master) 
    values
        ('Diablo''s slave A', 18)

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 52

    insert into slave
        (description, id_master) 
    values
        ('Diablo''s slave B', 18)

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 53

    insert into slave
        (description, id_master) 
    values
        ('Diablo''s slave C', 18)

-- DEBUG o.h.id.IdentifierGeneratorHelper - Natively generated identity: 54


    update slave set
        index=0 
    where
        id=52

    update slave set
        index=1 
    where
        id=53

    update slave set
        index=2 
    where
        id=54

It is a step back. When @OrderColumn enters the scene even a bidirectional association with mappedBy becomes plagued by those ugly update statements. Does it means that the two types of association are now equivalent? Not really. Let's consider another situation.

 // ...

 app.ms.orderColumn.unidirectional.Master master = 
  em.find(app.ms.orderColumn.unidirectional.Master.class, 16);
 master.removeSlave("Devil's slave B");

 // ...

 app.ms.orderColumn.bidirectional.mappedBy.Master master = 
  em.find(app.ms.orderColumn.bidirectional.mappedBy.Master.class, 18);
 master.removeSlave("Diablo's slave B");

 // ...

We are putting an end to the sufferings of slaves B.

/* 
    Unidirectional, remove B
*/

    update slave set
        id_master=null,
        index=null 
    where
        id_master=16 
        and id=48

    update slave set
        id_master=null,
        index=null 
    where
        id_master=16 
        and id=47

    update slave set
        id_master=16,
        index=1 
    where
        id=48

    delete from slave 
    where
        id=47

The first two updates are useless. Hibernate is setting the id_master and index columns to null for all those elements that it has effectively to update or delete. It is applying a sort of punishment.

/*
    Bidirectional with mappedBy, remove B
*/

    update slave set
        index=0 
    where
        id=52

    update slave set
        index=1 
    where
        id=54

    delete from slave 
    where
        id=53

The first update is useless. Hibernate is updating the index column for all the remaining elements.

At first sight it could be said that the bidirectional association with mappedBy is still the best because there are less update statements, but what would have happened removing slave C instead of B?

/* 
    Unidirectional, remove C
*/

    update slave set
        id_master=null,
        index=null 
    where
        id_master=16 
        and id=48

    delete from slave 
    where
        id=48

/*
    Bidirectional with mappedBy, remove C
*/

    update slave set
        index=0 
    where
        id=52

    update slave set
        index=1 
    where
        id=53

    delete from slave 
    where
        id=54

Conclusion

The best way to map a @OneToMany relationship with Hibernate is through a bidirectional association (with mappedBy), but this is true if @OrderColumn is not being used. When @OrderColumn is specified then the number of elements involved and the operations performed must be considered. Other JPA providers (precisely EclipseLink and OpenJPA) are doing better in some of the cases analyzed here, so let's keep an eye on Hibernate 6 or 666.

RogueFlash, various implementations of a simplistic flashcard software to explore a range of technologies.

(2023) RogueFlashVueQs

Single-page / Electron application.

Source code

(2021) RogueFlashVue

Single-page application.

Source code

(2021) RogueFlashNg

Single-page application.

Source code

(2019) RogueFlashSPJO

RESTful(ish) service.

Source code

(2018) RogueFlashJspSP

Web application. Port of RogueFlashJspHB to Spring, same db.

Source code

(2017) RogueFlashNetCoreMvc

Web application. Port of RogueFlashJspHB to ASP.NET Core, same db.

Source code

(2017) RogueFlashJspEL

Web application. Port of RogueFlashJspHB to GlassFish.

Source code

(2017) RogueFlashJspHB

Web application.

Source code

In this tutorial we will see how to call a C++ library from a Mono for Android app. Out of sheer curiosity and in the face of pragmatism, instead of resorting to P/Invoke we will make use of Cxxi, a framework that is still in development and aims to improve the interoperability between C++ and Mono.

Native library

The native library that we are going to use is Boost.Geometry and, as in the past, we will limit ourselves only to boolean operations on polygons. This choice leads to difficulties due to the heavy use of templates in the library so, in order to export the features that we need, we will use the following class (which is inspired by KBool):

//
// Wrapper.h
//

#if defined(_MSC_VER)
    #define EXPORT __declspec(dllexport)
#else
    #define EXPORT
#endif

namespace ClippingLibrary
{


class EXPORT Wrapper
{
public:
    Wrapper();
    ~Wrapper();
    
    void AddInnerRing();
    void AddOuterRing();
    void AddPoint(double x, double y);

    void ExecuteDifference();
    void ExecuteIntersection();
    void ExecuteUnion();
    void ExecuteXor();
    
    bool GetInnerRing();
    bool GetOuterRing();
    bool GetPoint(double& x, double& y);

    void InitializeClip();
    void InitializeSubject();
    
private:
    class Implementation;
    Implementation* _pImpl;
};


}

In doing so the real and proper implementation of the library is completely hidden and Cxxi will have to deal only with class members that at the most expect two parameters of type double.

Moreover, to build the library for Android, it is necessary to modify the file

$BOOST_ROOT\boost\detail\endian.hpp

in this way:

#ifndef BOOST_DETAIL_ENDIAN_HPP
#define BOOST_DETAIL_ENDIAN_HPP

// GNU libc offers the helpful header <endian.h> which defines
// __BYTE_ORDER

#if defined (__GLIBC__) || defined(ANDROID)
# include <endian.h>

For further details about Boost on Android:

https://github.com/MysticTreeGames/Boost-for-Android

Ndk

Ndk (Native Developement Kit) is a set of tools that allow to build C and C++ libraries so that they can be used on Android. In particular, through Ndk we can carry out a cross-compilation. So, for example, a library built on Windows can be executed on an Android device.

First thing, it is necessary to prepare an Ndk project creating a main directory with any name and then a subdirectory that must be called jni. Then, inside the jni subdirectory, we create two new files that are required to configure the project.

The first file is Application.mk:

APP_STL := gnustl_static

APP_ABI := \
    armeabi \
    armeabi-v7a

• APP_STL, specifies the C++ runtime to be used.

  Ndk provides several runtimes with different characteristics and licenses. Given that we have Boost as dependency, C++ exceptions support is required. At the moment, the only runtime that has such capability is Gnu Stl, which is under Gpl v3 license. Also, we use the static version since we want to create only one library.

• APP_ABI, specifies the hardware architecture on which our software will run.

  If omitted the default value is armeabi.

The second file is Android.mk:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := Native
LOCAL_SRC_FILES := Wrapper.cpp

LOCAL_CPPFLAGS += -fexceptions
LOCAL_C_INCLUDES := W:\Boost

include $(BUILD_SHARED_LIBRARY)

• LOCAL_PATH, specifies the path of the current Android.mk file and must be defined at the beginning. The macro $(call my-dir) returns the path to Android.mk itself.
• include $(CLEAR_VARS), resets various global variables and must be used in case the project is composed of several modules.
• LOCAL_MODULE, specifies the module name.
• LOCAL_SRC_FILES, lists the source files to be built. It must not contain header files.

  Note that in this example, Wrapper.h and its implementation Wrapper.cpp must be inside the jni directory.

• LOCAL_CPPFLAGS, lists the flags to be passed to the C++ compiler. fexceptions enables exceptions support, otherwise the following error should appear:

  $BOOST_ROOT/boost/numeric/conversion/converter_policies.hpp:162: error: exception handling disabled, use -fexceptions to enable

• LOCAL_C_INCLUDES, lists the paths where headers of dependencies like Boost can be found.
• include $(BUILD_SHARED_LIBRARY), specifies that the output must be a shared library.

At this point, the PATH system variable must include the path to the Ndk installation directory. We can open a shell or command prompt and go to the main directory of our Ndk project and, finally, launch the following command:

ndk-build

At the end of the build process, inside the main directory of the project there should be a subdirectory named libs, and this should be its content:

libs
+---armeabi
|       libNative.so
|
\---armeabi-v7a
        libNative.so

For every architecture specified in the Application.mk file there is a subdirectory with its version of the library. Note that the name of the file is libNative.so, where Native is the name of the module specified in the Android.mk file and lib is a prefix added for convention.

For further details it is advisable to refer to the documentation provided with the Ndk, expecially the html files OVERVIEW, CPLUSPLUS-SUPPORT, APPLICATION-MK and ANDROID-MK.

Gcc-Xml

Gcc-Xml is a tool that parses C++ code and generates an xml file containing a description of the parsed code. Then, the xml file can be used by other tools that need access to the structure of the C++ code, avoiding to tackle directly the complex parsing phase.

The development version of Gcc-Xml is still being updated. The source code can be checked out from the git repository according to the instructions on the download page, and it is ready to be used with CMake.

Note that Gcc-Xml requires the presence of a C++ compiler, the PATH system variable must include the path to the compiler, and if you choose to download pre-built binaries you must be sure that they support such compiler.

Once obtained the binaries for Gcc-Xml, we can execute the following command:

gccxml --gccxml-compiler gcc -fxml=Wrapper.xml Wrapper.h

• gccxml-compiler, specifies the compiler to be used.

  We opted for gcc but, for example, on Windows we could have used msvc10.

• fxml, sets the name of the xml file to be generated.
• Wrapper.h, in the end, is the name of the source file to be parsed.

Cxxi

Cxxi is a tool that enables the use of C++ libraries from managed code. In this regard, if you have not yet done so, it could be interesting to read this introduction that also lists some of the features that make Cxxi different from other solutions such as Swig:

CXXI: Bridging the C++ and C# worlds.

Here you can find the master branch:

http://github.com/mono/cxxi

However we are going to use this fork:

https://github.com/kthompson/cxxi

This is because some problems still present in the master have been solved in the fork, in particular with parameters passed by reference as in the GetPoint method seen in our Wrapper class.

The source code comes with a solution file (.sln) that can be opened with Visual Studio 2010 or MonoDevelop. As the result of the build process, we get two files:

• Generator.exe
• Mono.Cxxi.dll

But presently, in release mode, the name of the dll is CPPInterop.dll.

At this point we can feed Generator.exe with the xml file previously created by Gcc-Xml:

generator -abi=ItaniumAbi -ns=CxxiGeneratedNamespace -lib=Native -o=OutputFolder Wrapper.xml

• abi, specifies the abi used by our native library.

  The abi used on Arm seems to be based on the Itanium abi and moreover Ndk uses gcc as compiler so the value of the abi option must be set to ItaniumAbi. If we were trying to use a library built with Visual C++ from a Windows application, we should specify MsvcAbi.

• ns, specifies the namespace that encloses the files created by Generator.exe
• lib, is the name of the native library without the lib prefix.
• o, is the directory where Generator.exe puts the output files.
• Wrapper.xml, in the end, is the name of the xml file generated by Gcc-Xml

The first file obtained in our example is Lib.cs:

using System;
using Mono.Cxxi;
using Mono.Cxxi.Abi;

namespace CxxiGeneratedNamespace {

    public static partial class Libs {
        public static readonly CppLibrary Native = 
            new CppLibrary ("Native", 
                ItaniumAbi.Instance, 
                InlineMethods.NotPresent);
    }
}

The namespace is the same one specified in the previous command, and the name of the library and the choosen abi are passed to the CppLibrary constructor.

The second file is Wrapper.cs (slightly reformatted):

using System;
using Mono.Cxxi;

namespace CxxiGeneratedNamespace.ClippingLibrary {
    public partial class Wrapper : ICppObject {

        private static readonly IWrapper impl = 
            Libs.Native.GetClass<IWrapper,_Wrapper,Wrapper> (
                "Wrapper");
        public CppInstancePtr Native { get; protected set; }

        public static bool operator!=(Wrapper a, Wrapper b)
        { 
            return !(a == b);
        }
        public static bool operator==(Wrapper a, Wrapper b)
        {
            if (object.ReferenceEquals(a, b))
                return true;
            if ((object)a == null || (object)b == null)
                return false;
            return a.Native == b.Native;
        }
        public override bool Equals(object obj)
        {
            return (this == obj as Wrapper);
        }
        public override int GetHashCode() 
        { 
            return this.Native.GetHashCode();
        }

        [MangleAs ("class ClippingLibrary::Wrapper")]
        public partial interface IWrapper :
        ICppClassOverridable<Wrapper>
        {
            [Constructor] CppInstancePtr Wrapper (
                CppInstancePtr @this);
            [Destructor] void Destruct (CppInstancePtr @this);
            void AddInnerRing (CppInstancePtr @this);
            void AddOuterRing (CppInstancePtr @this);
            void AddPoint (CppInstancePtr @this,
                double x, double y);
            void ExecuteDifference (CppInstancePtr @this);
            void ExecuteIntersection (CppInstancePtr @this);
            void ExecuteUnion (CppInstancePtr @this);
            void ExecuteXor (CppInstancePtr @this);
            bool GetInnerRing (CppInstancePtr @this);
            bool GetOuterRing (CppInstancePtr @this);
            bool GetPoint (CppInstancePtr @this, 
                [MangleAs ("double  &")] ref double x, 
                [MangleAs ("double  &")] ref double y);
            void InitializeClip (CppInstancePtr @this);
            void InitializeSubject (CppInstancePtr @this);
        }
        public unsafe struct _Wrapper {
            public IntPtr _pImpl;
        }




        public Wrapper (CppTypeInfo subClass)
        {
            __cxxi_LayoutClass ();
            subClass.AddBase (impl.TypeInfo);
        }

        public Wrapper (CppInstancePtr native)
        {
            __cxxi_LayoutClass ();
            Native = native;
        }

        public Wrapper ()
        {
            __cxxi_LayoutClass ();
            Native = impl.Wrapper (impl.Alloc (this));
        }
        public void AddInnerRing ()
        {
            impl.AddInnerRing (Native);
        }
        public void AddOuterRing ()
        {
            impl.AddOuterRing (Native);
        }
        public void AddPoint (double x, double y)
        {
            impl.AddPoint (Native, x, y);
        }
        public void ExecuteDifference ()
        {
            impl.ExecuteDifference (Native);
        }
        public void ExecuteIntersection ()
        {
            impl.ExecuteIntersection (Native);
        }
        public void ExecuteUnion ()
        {
            impl.ExecuteUnion (Native);
        }
        public void ExecuteXor ()
        {
            impl.ExecuteXor (Native);
        }
        public bool GetInnerRing ()
        {
            return impl.GetInnerRing (Native);
        }
        public bool GetOuterRing ()
        {
            return impl.GetOuterRing (Native);
        }
        public bool GetPoint (ref double x, ref double y)
        {
            return impl.GetPoint (Native, ref x, ref y);
        }
        public void InitializeClip ()
        {
            impl.InitializeClip (Native);
        }
        public void InitializeSubject ()
        {
            impl.InitializeSubject (Native);
        }


        partial void BeforeDestruct ();
        partial void AfterDestruct ();

        public virtual void Dispose ()
        {
            BeforeDestruct ();
            impl.Destruct (Native);
            Native.Dispose ();
            AfterDestruct ();
        }

        private void __cxxi_LayoutClass ()
        {
            impl.TypeInfo.CompleteType ();
        }

    }
}

Here, again, we can note the namespace to which has been added ClippingLibrary, the namespace of the native library. Furthermore, the class takes the name of the respective native class, Wrapper. If there were more classes, there would be a file for each class.

Mono for Android

Through Mono for Android, C# developers can write apps for Android without the need to learn Java. The trial version has no time limits but only allows to deploy to the Android emulator. The installer downloads all the necessary, Android Sdk and MonoDevelop included.

To test our library we can execute the following steps (the description refers to MonoDevelop but the steps for Visual Studio are similar):

1. Create a new Solution called TestMonoDroid. Select a Mono for Android project type (actually only available under C#).
2. Add a new project to the solution and name it Cxxi. Select a Mono for Android Library Project type (only available under C#).

   We can't use the previously created Mono.Cxxi.dll, the project must be rebuilt to target Mono for Android.

3. Inside the Cxxi project add the same files found in the Mono.Cxxi project, in the original Mono.Cxxi source code.
4. Under Project Options, Build, General, check Allow 'unsafe' code.
5. Inside the TestMonoDroid project add a reference to the Cxxi project.
6. Add the files Lib.cs and Wrapper.cs, previously obtained with Generator.exe, to TestMonoDroid.
7. Add the libs folder, previously obtained with Ndk, to TestMonoDroid.
8. For every libNative.so file go to Properties, Build, and set Build action to AndroidNativeLibrary.
9. Modify Activity1.cs and add code for testing the library (see below for an example).
10. Build All.
11. From the Run menu, select Upload to Device.
12. Start an emulator and once the upload is done launch the TestMonoDroid app.

    Some problems could arise in this phase, in that case these resources may be of help:

    MonoDroid: Not connecting to Emulator

    MonoDroid: Running out of space on fresh Virtual Device?

    Unsupported configuration: ... armeabi-v7a-emu.so in Mono for Android v4.0

This is an example of how to use the library:

// ...

using CxxiGeneratedNamespace.ClippingLibrary;

// ...

        private static string RunTest()
        {
            var w = new Wrapper();

            w.InitializeSubject();
            w.AddOuterRing();
            w.AddPoint(0, 0);
            w.AddPoint(0, 1000);
            w.AddPoint(1000, 1000);
            w.AddPoint(1000, 0);
            w.AddPoint(0, 0);
            w.AddInnerRing();
            w.AddPoint(100, 100);
            w.AddPoint(900, 100);
            w.AddPoint(900, 200);
            w.AddPoint(100, 200);
            w.AddPoint(100, 100);
            w.AddInnerRing();
            w.AddPoint(100, 700);
            w.AddPoint(900, 700);
            w.AddPoint(900, 900);
            w.AddPoint(100, 900);
            w.AddPoint(100, 700);

            w.InitializeClip();
            w.AddOuterRing();
            w.AddPoint(-20, 400);
            w.AddPoint(-20, 600);
            w.AddPoint(1020, 600);
            w.AddPoint(1020, 400);
            w.AddPoint(-20, 400);
            w.AddInnerRing();
            w.AddPoint(100, 450);
            w.AddPoint(900, 450);
            w.AddPoint(900, 550);
            w.AddPoint(100, 550);
            w.AddPoint(100, 450);

            w.ExecuteDifference();

            return GetOutputString(w);
        }

// ...

Note that rings must be closed and outer rings must be clockwise while inner rings must be anti-clockwise.

Not very choreographic but it runs:

Conclusion

We have seen how to use a native library from a MonoDroid app. A more pragmatic approach would have excluded Cxxi in favour of a more mature solution (and in this specific case we could have avoided a lot of issues by using the C# version of Clipper). However Cxxi is an interesting project that can offer more than what we have seen here, and in the future it could become the standard solution for interoperability between C++ code and Mono so keep an eye on it.

Download

Support files (also contains Wrapper.h and Wrapper.cpp).

Notes

• Android 3.1 (Emulated)
• Android Ndk r7b
• Boost 1.49.0
• Cxxi kthompson-cxxi-1a9c3a8
• GCC_XML cvs revision 1.135
• Mono for Android 4.0.4.264524889 (Evaluation)
• MonoDevelop 3.0.1

Trying to use Cgal in a C++ project with Common Language Runtime support (/clr) you may encounter a few problems.

First ...

If the following message appears when you start your application:

The application failed to initialize properly (0xc000007b).

The problem may be due to Boost.Thread, which is required by Cgal.

According to

http://lists.boost.org/Archives/boost/2009/04/151043.php

modify

$BOOST_ROOT/libs/thread/src/win32/tss_pe.cpp

in this way:

#if (_MSC_VER >= 1400)
//#pragma section(".CRT$XIU",long,read)
#pragma section(".CRT$XCU",long,read)
#pragma section(".CRT$XTU",long,read)
#pragma section(".CRT$XLC",long,read)
        __declspec(allocate(".CRT$XLC")) _TLSCB __xl_ca=on_tls_callback;
        //__declspec(allocate(".CRT$XIU"))_PVFV p_tls_prepare = on_tls_prepare;
        __declspec(allocate(".CRT$XCU"))_PVFV p_process_init = on_process_init;
        __declspec(allocate(".CRT$XTU"))_PVFV p_process_term = on_process_term;
#else

The __declspec lines were added in order to close this ticket (Severity - Cosmetic):

https://svn.boost.org/trac/boost/ticket/2199

Second ...

If the following assertion message appears at runtime:

Wrong rounding: did you forget the -frounding-math option if you use GCC (or -fp-model strict for Intel)?

Define CGAL_DISABLE_ROUNDING_MATH_CHECK and rebuild your project.

However, you should have seen this compiler warning:

warning C4996: '_controlfp_s': Direct floating point control is not supported or reliable from within managed code.

_controlfp_s is used directly by Cgal but, from MSDN:

This function is deprecated when compiling with /clr (Common Language Runtime Compilation) or /clr:pure because the common language runtime only supports the default floating-point precision.

So you should not expect identical results if you run the same project compiled with or without Common Language Runtime support.

Notes

Tested with Visual Studio 2010 using Cgal 3.9 and Boost 1.49.0 beta 1, x86 build, on Windows XP.

A quick overview of the different ways to call unmanaged APIs from managed code, with .Net and also with Mono.

The inspiration for this post came after reading a couple of articles. The first relating to SharpDX:

A new managed .NET/C# Direct3D 11 API generated from DirectX SDK headers

The second:

Techniques of calling unmanaged code from .NET and their speed

that in substance is on the same topic of this post but doesn't provide enough sample code, in particular for the final benchmark.

Native library

In the following examples we will use a function exported from a phantomatic library called Native.dll (Native.so for Mono on Unix/Linux), written in C and compiled with Cdecl calling convention.

//
// Native.h
//

void DoWithIntPointer(int a, int b, int* r);

//
// Native.c
//

#include "Native.h";

void DoWithIntPointer(int a, int b, int* r) {
    *r = a + b;
}

DoWithIntPointer simply calculates the sum of two integer but having parameters passed by value and by reference it will allow us to see some peculiarities.

Explicit P/Invoke

Let's start with a classic P/Invoke example:

//
// TestPInvoke.cs
//

using System.Runtime.InteropServices;

class TestPInvoke {    
    [DllImport(
        "Native.dll", 
        CallingConvention = CallingConvention.Cdecl
    )]
    private static extern void DoWithIntPointer(
        int a, 
        int b, 
        out int r
    );
    
    public static void Main() {
        int result = 0;
        DoWithIntPointer(1, 2, out result);
    }
}

The extern keyword tells the compiler that DoWithIntPointer is defined elsewhere while the DllImport attribute provides directions to trace it.

Implicit P/Invoke - C++/Cli

With C++/Cli we can write wrappers for native libraries with relative ease but it cannot be used with Mono. Here we have the C++/Cli wrapper for our Native library:

//
// NativeCppCliWrapper.cpp
//

#include "Native.h";

namespace NativeCppCliWrapper
{

using namespace System;
using namespace System::Runtime::InteropServices;

public ref class Wrapper {
public:
    static void CallDoWithIntPointer(
        Int32 a, 
        Int32 b, 
        [Out] Int32% r
    ) {
        int tmp;
        DoWithIntPointer(a, b, &tmp);
        r = tmp;
    }
};

}

After compiling, the wrapper can be used as any other assembly:

//
// TestCppCli.cs
//

using NativeCppCliWrapper;

class TestCppCli {
    public static void Main() {
        int result = 0;
        Wrapper.CallDoWithIntPointer(1, 2, out result);
    }
}

If we dig through the IL code generated by C++/Cli we can see that CallDoWithIntPointer invokes:

 IL_0004: call void modopt(
      [mscorlib]System.Runtime.CompilerServices.CallConvCdecl
   )  '<module>'::DoWithIntPointer(int32, int32, int32*)

And DoWithIntPointer is described by the following metadata:

.method assembly static pinvokeimpl("" lasterr cdecl)
 void modopt(
    [mscorlib]System.Runtime.CompilerServices.CallConvCdecl
    ) DoWithIntPointer (
      int32 '',
      int32 '',
      int32* ''
    ) native unmanaged preservesig 
{
 .custom instance void
 [mscorlib]System.Security.SuppressUnmanagedCodeSecurityAttribute::.ctor()
   = ( 01 00 00 00 )
}

Converted in C# (with IlSpy):

[SuppressUnmanagedCodeSecurity]
[DllImport("", 
    CallingConvention = CallingConvention.Cdecl, 
    SetLastError = true
)]
[MethodImpl(MethodImplOptions.Unmanaged)]
internal unsafe static extern void DoWithIntPointer(
    int, 
    int, 
    int*
);

Does this remind us of anything? Yes, it is very similar to the extern declaration that we have seen previously but among the differences we can note an attribute called SuppressUnmanagedCodeSecurity. MSDN tells us that:

This attribute is primarily used to increase performance; however, the performance gains come with significant security risks.

Security risks apart it can be used with explicit P/Invoke, it is not an exclusive of C++/Cli.

In other situations the native code is called in a more sophisticated way, for example if we poke inside IL code of SlimDX we can find things like this:

.method public hidebysig 
 instance valuetype SlimDX.Result Optimize () cil managed 
{
 // Method begins at RVA 0xd0824
 // Code size 25 (0x19)
 .maxstack 3

 IL_0000: ldarg.0
 IL_0001: call instance valuetype 
  IUnknown* SlimDX.ComObject::get_UnknownPointer()
 IL_0006: dup
 IL_0007: ldind.i4
 IL_0008: ldc.i4.s 68
 IL_000a: add
 IL_000b: ldind.i4
 IL_000c: calli System.Int32 modopt(
   System.Runtime.CompilerServices.IsLong
  ) modopt(
   System.Runtime.CompilerServices.CallConvStdcall
  )(System.IntPtr)
 IL_0011: ldnull
 IL_0012: ldnull
 IL_0013: call valuetype SlimDX.Result 
  SlimDX.Result::Record
  <class SlimDX.Direct3D11.Direct3D11Exception>(
   int32, object, object
  )
 IL_0018: ret
}

The calli instruction is used to invoke a native method given the address of the method itself. We will see how to take advantage of calli without C++/Cli in the last example.

Dynamic P/Invoke

In order to employ the previos techniques tha native library must be know at compile time, while it must be located in a certain path at runtime. With dynamic P/Invoke we can obtain a greater degree of flexibility.

In the next example we will benefit by an assembly called CSLoadLibrary but slightly modified, in particular to run on Unix/Linux via Mono (see the download link at the end of this post for the modified version). CSLoadLibrary contains an UnmanagedLibrary class that provides access to native libraries through standard Windows APIs (LoadLibrary, GetProcAddress, FreeLibrary) or Unix/Linux counterparts (dlopen, dlsym, dlclose).

//
// TestDelegate.cs
//

using System.Runtime.InteropServices;
using CSLoadLibrary;

class TestDelegate {
    [UnmanagedFunctionPointer(CallingConvention.Cdecl)]
    delegate void DelegateWithIntPointer(
        int a, 
        int b, 
        out int r
    );
    
    public static void Main() {
        UnmanagedLibrary nativeLib = 
            new UnmanagedLibrary(
                "Native"
            );
        
        DelegateWithIntPointer doWithIntPointer = 
            nativeLib.GetUnmanagedFunction
                <DelegateWithIntPointer>(
                "DoWithIntPointer"
            );

        int result = 0;
        doWithIntPointer(1, 2, out result);
    }
}

In practice, given the name of the native library to load, an UnmanagedLibrary object is instantiated. Then, with GetUnmanagedFunction we obtain a delegate pointing to our native function, DoWithIntPointer. Naturally the signature of the delegate must match the signature of the native function.

Dynamic P/Invoke – Explicit P/Invoke

This time, instead of using CSLoadLibrary, the delegate is created via Reflection, replicating the extern declaration shown in the Explicit P/Invoke example.

//
// TestDynamicS.cs
//

using System;
using System.Reflection;
using System.Reflection.Emit;
using System.Runtime.InteropServices;
using System.Security;

class TestDynamicS {
    delegate void DelegateWithIntPointer(
        int a, 
        int b, 
        out int r
    );
    
    public static void Main() {
        DelegateWithIntPointer doWithIntPointer = 
            GetDynamicSDelegate
                <DelegateWithIntPointer>(
                "Native", 
                "DoWithIntPointer", 
                CallingConvention.Cdecl
            );
            
        int result = 0;
        doWithIntPointer(1, 2, out result);
    }

    private static TDelegate GetDynamicSDelegate
        <TDelegate>(
        string libraryName, 
        string entryPoint, 
        CallingConvention callingConvention
    ) where TDelegate : class 
    {
        Type delegateType = typeof(TDelegate);
        MethodInfo invokeInfo = delegateType.GetMethod("Invoke");
        // Gets the return type for the P/Invoke method.
        Type invokeReturnType = invokeInfo.ReturnType;
        // Gets the parameter types for the P/Invoke method.
        ParameterInfo[] invokeParameters = 
            invokeInfo.GetParameters();
        Type[] invokeParameterTypes = 
            new Type[
                invokeParameters.Length
            ];
        for (int i = 0; i < invokeParameters.Length; i++) {
            invokeParameterTypes[i] = 
                invokeParameters[i].ParameterType;
        }

        // Defines an assembly with a module and a type.
        AssemblyName assemblyName = 
            new AssemblyName(
                "TestAssembly"
            );
        AssemblyBuilder assemblyBuilder = 
            AppDomain.CurrentDomain.DefineDynamicAssembly(
                assemblyName, 
                AssemblyBuilderAccess.Run
            );
        ModuleBuilder moduleBuilder = 
            assemblyBuilder.DefineDynamicModule(
                "TestModule"
            );
        TypeBuilder typeBuilder = 
            moduleBuilder.DefineType(
                "TestDynamicS"
            );
            
        //Defines a P/Invoke method called Invoke.
        MethodBuilder methodBuilder = 
            typeBuilder.DefinePInvokeMethod(
                "Invoke", 
                libraryName + ".dll", 
                entryPoint, 
                MethodAttributes.Public | 
                    MethodAttributes.Static | 
                    MethodAttributes.PinvokeImpl,
                CallingConventions.Standard, 
                invokeReturnType, 
                invokeParameterTypes, 
                callingConvention, 
                CharSet.Ansi
            );
        methodBuilder.SetImplementationFlags(
            methodBuilder.GetMethodImplementationFlags() | 
            MethodImplAttributes.PreserveSig
        );
        
        // Adds SuppressUnmanagedCodeSecurityAttribute to 
        // the method.
        Type attributeType = 
            typeof(
                SuppressUnmanagedCodeSecurityAttribute
            );
        ConstructorInfo attributeConstructorInfo = 
            attributeType.GetConstructor(
                new Type[] {}
            );
        CustomAttributeBuilder attributeBuilder = 
            new CustomAttributeBuilder(
                attributeConstructorInfo, 
                new object[] {}
            );
        methodBuilder.SetCustomAttribute(attributeBuilder);

        // Finishes the type.
        Type newType = typeBuilder.CreateType();
        
        object tmp = 
            (object)Delegate.CreateDelegate(
                delegateType, 
                newType.GetMethod("Invoke")
            );
        return (TDelegate)tmp;
    }
}

Though we are adding the SuppressUnmanagedCodeSecurity attribute, it is not essential.

Dynamic P/Invoke - Emit Calli

The last example is more complicated. Here again, we make use of UnmanagedLibrary to get the native function's address. Then, through Reflection, we create a dynamic method which internally passes the address of the native function to calli, the instruction seen previously.

//
// TestCalli.cs
//

using System;
using System.Reflection;
using System.Reflection.Emit;
using System.Runtime.InteropServices;
using CSLoadLibrary;

class TestCalli {
    [UnmanagedFunctionPointer(CallingConvention.Cdecl)]
    delegate void DelegateWithIntPointer(
        int a, 
        int b, 
        out int r
    );
    
    public static void Main() {        
        UnmanagedLibrary nativeLib = 
            new UnmanagedLibrary(
                "Native"
            );
        IntPtr nativeMethodAddress = 
            nativeLib.GetUnmanagedFunctionAddress(
                "DoWithIntPointer"
            );
        DelegateWithIntPointer doWithIntPointer = 
            GetCalliDelegate
                <DelegateWithIntPointer>(
                nativeMethodAddress
            );
        int result = 0;
        doWithIntPointer(1, 2, out result);
    }
    
    private static TDelegate GetCalliDelegate
        <TDelegate>(
        IntPtr methodAddress
    ) where TDelegate : class
    {
        Type delegateType = typeof(TDelegate);
        MethodInfo invokeInfo = delegateType.GetMethod("Invoke");
        // Gets the return type for the dynamic method and calli.
        // Note: for calli, a type such as System.Int32& must be
        // converted to System.Int32* otherwise the execution 
        // will be slower.
        Type invokeReturnType = invokeInfo.ReturnType;
        Type calliReturnType = 
            GetPointerTypeIfReference(
                invokeInfo.ReturnType
            );
        // Gets the parameter types for the dynamic method 
        // and calli.
        ParameterInfo[] invokeParameters = 
            invokeInfo.GetParameters();
        Type[] invokeParameterTypes = 
            new Type[
                invokeParameters.Length
            ];
        Type[] calliParameterTypes = 
            new Type[
                invokeParameters.Length
            ];
        for (int i = 0; i < invokeParameters.Length; i++) {
            invokeParameterTypes[i] = 
                invokeParameters[i].ParameterType;
            calliParameterTypes[i] = 
                GetPointerTypeIfReference(
                    invokeParameters[i].ParameterType
                );
        }

        // Defines the dynamic method.
        DynamicMethod calliMethod = 
            new DynamicMethod(
                "CalliInvoke", 
                invokeReturnType, 
                invokeParameterTypes, 
                typeof(TestCalli), 
                true
            );
            
        // Gets an ILGenerator.
        ILGenerator generator = calliMethod.GetILGenerator();   
        // Emits instructions for loading the parameters into 
        // the stack.
        for (int i = 0; i < calliParameterTypes.Length; i++) {
            if (i == 0) {
                generator.Emit(OpCodes.Ldarg_0);
            } else if (i == 1) {
                generator.Emit(OpCodes.Ldarg_1);
            } else if (i == 2) {
                generator.Emit(OpCodes.Ldarg_2);
            } else if (i == 3) {
                generator.Emit(OpCodes.Ldarg_3);
            } else {
                generator.Emit(OpCodes.Ldarg, i);
            }
        }
        // Emits instruction for loading the address of the
        //native function into the stack.
        switch (IntPtr.Size) {
            case 4:
                generator.Emit(
                    OpCodes.Ldc_I4, 
                    methodAddress.ToInt32()
                );
                break;
            case 8:
                generator.Emit(
                    OpCodes.Ldc_I8, 
                    methodAddress.ToInt64()
                );
                break;
            default:
                throw new PlatformNotSupportedException();
        }
        // Emits calli opcode.
        generator.EmitCalli(
            OpCodes.Calli, 
            CallingConvention.Cdecl,
            calliReturnType, 
            calliParameterTypes
        );
        // Emits instruction for returning a value.
        generator.Emit(OpCodes.Ret);

        object tmp = 
            (object)calliMethod.CreateDelegate(
                delegateType
            );
        return (TDelegate)tmp;
    }
    
    private static Type GetPointerTypeIfReference(Type type) {
        if (type.IsByRef) {
            return Type.GetType(type.FullName.Replace("&", "*"));
        }
        return type;
    }
}

The method GetPointerTypeIfReference converts the type of a parameter like Int32& to Int32*, otherwise calli executes correctly but results slower.

Benchmark

Hardware: CPU Intel Core i3-2310M 2.1 GHz, RAM 4 GB.
Software: VMware Player 3.1.4. on Windows 7 x64.

[ms] x 100,000,000 iterations

SUC means that the test has been executed with the SuppressUnmanagedCodeSecurity attribute.

Conclusion

The above results seem a bit weird and the only certain thing appears to be that Dynamic P/Invoke is always faster if we resort to calli. Anyway, we have seen different ways to invoke unmanaged code from managed code, each with its own pros and cons, and if necessary we can use them or conduct further tests.

Download

Benchmark source code.

Other resources

About interoperability:

• Interop with Native Libraries
• Invoke Native C++ DLL from .NET Code

About calli:

• Calli is not Verifiable
• C#/.NET: Why is Calli Faster Than a Delegate Call?
• OpenGL Import für Delphi .Net