Re: [Scidb-users] Some questions about Scidb

Hello Bogdan,

thanks for your interest for Scidb. About your questions:

> 1)      It seems that your MSTL overlaps at least partially with the STL. Is
> there a reason why you chose to implement things from zero? I understand
> Scidb uses some very specialized data structures and algorithms.

There are some reasons:

a) Speed. One example: stl::string is a fine thing, but it has to work in every 
application under any conditions. So a string assignment either has to copy 
the whole string content, or to manage reference count, and the latter is in 
general not more efficient than string copy, under general conditions reference 
counting is a bit complex. Scidb has his own conditions. A string always 
belongs to a database, so the life time of the string is coupled with the life 
time of the associated database. So mstl::string does not need to copy 
strings, or to use reference counting, it is only copying the pointer of the 
string, this is super-fast. Such a method in crashing under general 
conditions, but not under the conditions of Scidb.

b) Speed. The mstl classes are implemented with special optimization 
strategies, based on very special type traits. STL does not provide this (and 
cannot provide such special application dependent things).

c) Library size. One example: sorting inside STL will be performed with 
std::sort, and the use of std::sort is producing many instances of the same 
sort algorithm for different class types. This is a big drawback of STL. In 
MSTL I'm using wrappers to qsort in stdlib.h. This is reducing the library 
size significantly.

d) Implementation details. One example: stl::map in general is using a red-
black-tree, but Scidb's map is using a sorted vector (binary search). In 
general the approach of Scidb has a bad performance (slow insert), but not 
under the special conditions of Scidb, here the sorted vector is better. (And 
if I really need fast inserts, then I use the rbtree class of MSTL.)

e) The MSTL classes are using the special exception handling of Scidb, which 
provides a backtrace. This is not possible with the use of STL, here the 
backtrace cannot be provided. (This would require that every function/method 
has to catch the STL exception.)

f) MSTL contains some special basic classes, not available in STL (and I don't 
like to use the boost library for similar reasons).

g) Scidb is using many specialized classes: specialized (file) stream classes, 
specialized bit sets, and more. The STL has too few classes which are of 
interest (for use in Scidb).

h) The implementation of a specialized STL is not a big thing, compared to the 
overall development time of Scidb this is insignificant.

> 2)      Is it possible to decouple database functionality from the GUI, and
> use it as a library? Eg., to use custom GUIs or scripts (it would be easy
> with CQL). Would the library have any chance of being portable? What kind of
> work would it require to make it portable?

It is decoupled, the GUI interface is separated.The Android app "CBH to PGN" 
is using the Scidb library. But the GUI interface is designed only for the Tk 
library, I don't have a toolkit independent framework.

Scidb is designed to be portable to Windows and Mac OS X. But as long as Scidb 
has not reached the alpha state (stable state) the porting will not be finished 
(but is mostly already implemented). Of course porting is a big task, it 
requires to test the whole application on the ported platform.

> 3)      Will Scidb include some any command line utilities for manipulating
> databases? Eg copying games from one database to another, converting between
> formats, this kind of stuff.

Scidb already has the command line utilities cbh2si4 (converting CBH to si4), 
and cdb2sci (converting any supported database format to sci). More 
applications are not yet demanded.

Cheers,
Gregor