Date: Tue, 25 Feb 2014 12:24:17 +0400 From: Dmitry Selyutin <ghostman.sd@gmail.com> To: hackers@freebsd.org Subject: GSoC proposal: Quirinus C library (qc) Message-ID: <CAMqzjevCoS2qA7jmpPmOXpfzrsD1LzNMJbC8sw-Op-KB-UMhXQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hello everyone!
My name is Dmitry, I'm 22 years old student from Lomonosov Moscow State
University of Russia. This message is addressed mainly to C connoiseurs,
yet I think other people may find it interesting. It's a GSoC proposal.
It's a pity that for language like C we generally don't have something
universal like Boost, so we have to implement some common functions from
scratch or introduce new dependencies. We have Glib, which is used mainly
by Gnome developers (though it is a standalone library) and LGPL-ed, which
is not as liberal as Boost's license. We also have APR, which seems to be a
bit more comprehensive and convenient, yet it is not so well-known as Glib.
I'm in process of implementing a something like Boost for ANSI C (though I
don't pretend this library to share Boost's comprehensiveness). Several
ideas I find useful are:
1. Strict and universal interface. Each function begins with qc_ prefix,
followed by type if function is type-related. Most of types (except
enum-typedef'ed ones) have three common functions (replace _type_ with the
necessary type name, e.g. _bytes_):
a. Constructor: void * qc_type_construct(void). Allocate object instance
and initialize it to default value.
b. Destructor: void qc_type_destruct(void * pointer). Deallocate memory
allocated for object and its members.
c. Replicator: void * qc_type_replicate(void const * pointer). Replicate
object, copying its data to new allocated object, i.e. clone.
Most of types also have _import_ and _export_ functions, which allow to
fill allocated object with the desired data (e.g. fill bytes array from
null-terminated char string) or export data to another type. Almost all
enum-typedef'ed types also have _import_ and _export_ functions to retrieve
a key value corresponding to string.
2. Common and universal error type, qc_error. Such errors can be generated
from errno values as well as from Windows API errors.
Almost all functions from qc library except for the three common functions
(constructor, destructor, replicator) return qc_error code and set specific
qc_errno variable to this code.
It is now possible to write such constructions:
if (qc_bytes_import_str(bytes_instance, "Hello, world!"))
qc_errormsg(qc_errno, "error check");
Global variable qc_errno is implemented in terms of multithreading
applications, it is unique for every running thread.
3. Clear distinction between byte and Unicode strings (qc_byte and qc_ucs
types for characters, where qc_byte has exactly 8-bit width and qc_ucs has
exactly 32-bit width).
Charsets are just enumeration, e.g. QC_ENCODING_UTF8,
QC_ENCODING_ISO_8859_4, etc., yet it is possible to lookup the desired
encoding using qc_encoding_import. If encoding is known under several
names, they are handled alltogether, i.e. QC_ENCODING_ASCII will be
returned for any of "ASCII", "iso-ir-6", "ANSI_X3.4-1968", "ISO646-US",
etc. Register doesn't matter.
Two new types, qc_bytes and qc_unicode are provided, in order to store
binary and Unicode data. It is possible to store null characters inside
such objects. It is similar to C++ string and C++ vector classes.
4. Universal file system path type. It is possible to achieve
cross-platformness using such path types, i.e. it is possible to make
directories, links, symlinks, remove files, directories, etc. regardless of
platform path API.
5. i18n support must be embedded with qc library. Locales, timezones, day
and months names, etc. must be provided too, in several forms if necessary.
i18n functions work with qc_unicode type, so charset conversion problems
won't exist.
6. Multithreading support if platform permits it. On POSIX we use pthreads,
on Windows we use its API for multithreading. I'm also thinking about green
threads implementation. Thread local storage is already implemented, yet
there is still a lot work to be done with threads, mutexes, etc.
7. Multiprecision arithmetics. I'm using GMP to achieve it, yet I'm
planning to switch to something BSD-like or to implement it from scratch
(that probably would be better, since library doesn't introduce any
dependencies except GMP).
8. Ternary logic almost everywhere. Being fan of Russian Setun computer,
I've started this library as implementation of ternary logic operations.
When I've realized that there is still much to be done in other fields,
I've already concluded that ternary logic is suitable for a wide set of
other operations, e.g. comparison, determining type of strings, endianness,
etc. I think that I'll leave type qc_trit, since I've found it extremely
useful.
9. A lot of other things to be done, such as unified I/O streams which
provide compression/transformation filters, protocols, math library, etc.
Why I'm writing such letter to FreeBSD? I'm pretty sure that FreeBSD highly
needs such library, since we try to use BSD-like license and yet to
implement things that exist in GNU world. The most common example is GNU
readline library, yet I think there is a lot of libraries that we
reimplemented just to let some projects suit BSD philosophy. We can make a
good library, which can be used a lot in different projects, yet it will
field everyone like Boost. The nature of C language itself helps us to keep
this library much more tiny than Boost library; I also think that we can
limit our support with POSIX-(almost-)compatible platforms and Windows.
I've already done a lot of work, but it is hard to make decisions without
advice or discussion, so I've thought about to enter GSoC this year like I
did two years ago when I've reimplemented gnulib-tool for FSF. This project
is much more interesting for me, since I want to upgrade my C skills, get
known BSD world better and provide a good cross-platform library which may
be useful to almost everyone. Since I've already finished my volunteer's
job in Sochi (I've worked as technologist volunteer), I'm really want to
make something new for other people to be useful.
If you are interested in my project, here is repository at GitHub:
https://github.com/ghostmansd/quirinus. I guess I'll later rename it to
https://github.com/ghostmansd/qc, yet it doesn't matters. If you're
interested in my previous GSoC work, you can find it here:
https://github.com/ghostmansd/gnulib-python. If you want to get to know me
better from any side (my philological studies in Lomonosov Moscow
University, GSoC participation, Sochi volunteer job, etc.), you can write
me a email; I'd be very glad.
Thanks for reading such a long letter!
--
With best regards,
Dmitry Selyutin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMqzjevCoS2qA7jmpPmOXpfzrsD1LzNMJbC8sw-Op-KB-UMhXQ>