Monthly Archives: July 2013

Shell scripting (cross platform)

According to

There is a paragraph, stating:

Perl, Python, Ruby all are really slow compared to statically typed languages. I use Scala for all scripting purposes – it is just as terse as Perl / Python / Ruby but has better collection libraries and runs much, much faster. I’d use Lua if I only needed a thin layer of scripting on top of C/C++. I would use Scala if I only needed a thin layer of C/C++ on the bottom.

IF a new shell is to be designed with scripting functionality, Lua might be a good candidate to be the scripting part and the C++ core to be a shell script engine. 


Traditional bash is very powerful, but it is really poor-documented. Thus, writing the bash scripting is extremely difficult if new-comer is  involved-in, or if someone stop writing script language for a period of time. For example, I’ve wrote shell script in Linux for two years or so, and I’ve stop writing it one year, meanwhile transforming the platform from mac OSX. When I use the bash script again, the old code is not applicable, for the native code (regular expression using [[ a =~ b ]] syntax), and the difference is merely the “” operator at the regex pattern side. Besides, I use osx and windows at the same time, creating the need to cross-platform scripting. 


Therefore, there might be a thought to write a cross-platform shell-engine to take advantage of threading, while scripting language helps to tell what binary to execute.


Preprocessor macro for three OS

MAC:   __APPLE__ (two under-slash)

Linux: __linux__ (Still two slash)

Windows: __WIN32__ / __WIN64__

MINGW: __MINGW32__ (not verified yet)




Beside following the guide from bitbucket, there is another step to perform to avoid “unable to login issue”=>

Please refer!topic/bitbucket-users/R2GqjuchNc0

A double side linked list with auto deletion functionality

The pure list data structure is simple. A lot of elements are linked by pointers, and accessment of all elements are traditionally handled by the list holder. Adding a element to the list should be done by the list holder, that is fine. But what if list element deletion automation is required?


The example of the requirement of the auto list deletion is shown from the figure above. There are two nodes, and those nodes can be connected by an edge. Since there might be more than one edge connecting from/to a node, the list is required. When the edge is going to be deleted, traditional way is to delete the edge, and then delete corresponding list entries/re-connect the lists of two nodes, giving the condition traditional list mechanism is applied.

To avoid multiple deletion, the edge should be seen as a pointer instead of a real object. Storing the pointer to the list is also possible, but the automation of edge is sacrificed. The reason is that for generic list data structure, the list order manipulation is handled by the list container itself. Therefore, the list element and the list should be re-designed to fit auto deletion scenario. 

Thank to the class and the inheritance of C++, customized list design is dramatically simplified. If no inheritance is applied, the edges need to be stored inside accessible container (such as another list) within reachable objects/space, and this act might be difficult in some scenario. Therefore, the newly defined list data structure can be inherited by the edge class itself (when the edge contains it’s own class), and no much overhead is caused.

Second, the list element should update the lists of two sides automatically. When the edge is to be removed, it will also be deleted. By the linked list mechanism, the previous and the next element is known. Therefore, the list entry deletion and list re-linking can be done at the destructor of the new list element class/data-structure.

Combining class inheritance and class destruction function, list element auto deletion can now be simplified to the deletion of the element itself, and other operations are done by C++ interior functionality. 

The example will be shown in the new example file, of the QT graphic view.



Finally complete multiple node connection and node deletion

Finally, I can add multiple edges to one node. And, I can now remove any node from a graph while corresponding edges are removed.

The key lies in

  • class inheritance
  • linked list data structure – double sided
  • Pure virtual list
  • Class destructor.

The code will be published several days later.

Design concept and conclusion

Too much design leads to nothing. Design is based on the need. More design dedication involved comes to the strength of the design,

A huge design comes from countless small designs.

Design period is shortened only if changes are made. True correctness won’t be achieved by one design, but by multiple renovation. The correctness of a design decides the greatness of a design.

For software, there is no absolute way. Success of software comes with no definite rule, but just methods that increases the chance of success. No successful method can be replicated to another application without any modification, with possible chance of success to the second application.

Some conclusion for software design.

Graphic view: line linking

For the graphic view, the interconnecting line between two items can now follows the object.


Next target is to multi-link the items.

Maya's Programming & Electronics Blog

An attempt at a proper programming & electronics blog