A PHP Error was encountered

Severity: Warning

Message: file_put_contents(): Only 0 of 42 bytes written, possibly out of free disk space

Filename: libraries/article.php

Line Number: 212

A PHP Error was encountered

Severity: Warning

Message: mkdir(): File exists

Filename: libraries/menu.php

Line Number: 500

A PHP Error was encountered

Severity: Warning

Message: file_put_contents(/var/www/html/contents/menus/h_blogs/b_purenode/views/why c and not c_0): failed to open stream: No such file or directory

Filename: libraries/menu.php

Line Number: 505

iadix blockchain platform - blogs Why C and not C++ en

Iadix HTML 5.0 multichain technology
Blockchain, economic solutions and online business
A blockchain to link them all

Blogs Purenode article en



Why C and not C++

author:BitAdmin (Registered)
Join date:15/01/16 22:18

At this time where everything goes OO, one can wonder why C is used in the core programming of the nodes instead of using an OO language like c++.


The first motivation for this choice is cross compiler binary compatibility, the system must be able to load and execute binary code regardless of the compiler used to compile it, and c++ is not a good choice for this for mainly two base reason, the calling convention used to compile class methods is not standard across compilers, and neither the decoration used for exported method name.


With C, all compiler for x86 recognize at least two function calling convention, "stdcall" and "cdecl", and for x64 two standard exist, one from microsoft and the one of gcc, but gcc can be forced to use the microsoft calling convention. These calling convention tell how parameters are passed across function call, and is vital to the modular approach used in the node. C++ doesn't define how the "this" pointer should be passed to method call on the binary/assembly level, so it would make binaries compiled with different compilers imcompatible with each others, which is not the case with C.


Exported functions name decoration is also important to consider, as for a module to call a function of another module, it need to know the name of the function as it's exported by the linker, the framework already require module to declare the function decoration scheme used with C, to make the match transparently between different name decoration used by different compilers, it recognize the gcc stdcall and cdcel and the visual studio style, there can be an underscore added, and the @ to tell the stack size with std call (_function@N), but functions can be imported and referenced from their base name transparently. But the scheme used to decorated c++ class's methods is more complex, has more attribute and is less standard.


Another reason why c++ can be bothering for cross compiler binary compatibility is the use of virtual method, of which pointer will be stored in a table of method pointer, the vtable, and the way the vtable is handled at binary level can be different between compiler, which would preclude sharing a pointer to a class instance with virtual method between different modules compiled with different compilers, because the vtable would not be stored the same.


Now the design is still made entierely around the component concept, the memory system and dynamic data tree make it very easy to deal with complex data hierarchy and references, and the systeme of cross compiler binary module in cunjunction with this dynamic data tree can make the framework very suitable for OO design. In the principle it's closer to how binary module work on RISCOS, each module define a set of function that use a specific register to hold a pointer to its instance data, which make the systeme very OO like albeit being made in ARM assembler, the binary module systeme in cunjunction to the dynamic data tree push the concept even further, because complex structured data can be passed across binary modules without depending on the particular memory agencement of the compiler or cpu. So it completly remove the whole burden of memory allocation, string manipulation and manipulation of hierarchized data structure from the C runtime.


Also C++ will mostly work with boost or the stdc++ library, which is also compiled differently on different platforms, and would most likely break binary compatibility. If two modules compiled with differents compilers on different hosts would share data structures used in calls to the framework, it would probably break in thousands manners.


For all these reason, i prefered to leave the object oriented design partern based on binary modules, rather than on c++ class. A binary module is essentially a static class, you could just add a class {} around the code and have a c++ static class with its methods being the function exported by the modules, and the static data members being the global variable in the data section of the module.


The only restriction of the binary module is that it doesn't support non initialized data section, so all global variables need to be initialized to non zero values, if you need large area of non initialized memory, use a memory allocation function. The binary module can be loaded 'in place', it can be included in a binary assembly file, and relocated 'in place' , as well as it's symbol imported and exported 'in place', without needing any memory allocation, so references to local addresses in the program must point to data included in the binary, which is not the case for non initialized data section, which are not stored in the binary but allocated when the dynamic loader load the binary module.