Date: Wed, 26 Feb 2014 20:05:45 +0100 From: =?UTF-8?B?xYF1a2FzeiBXw7NqY2lr?= <lukasz.wojcik@zoho.com> To: ghostmansd@gmail.com, hackers@freebsd.org Subject: Re: GSoC proposal: Quirinus C library (qc) Message-ID: <530E3B09.2060602@zoho.com> In-Reply-To: <CAMqzjevCoS2qA7jmpPmOXpfzrsD1LzNMJbC8sw-Op-KB-UMhXQ@mail.gmail.com> References: <CAMqzjevCoS2qA7jmpPmOXpfzrsD1LzNMJbC8sw-Op-KB-UMhXQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
W dniu 2014-02-25 09:24, Dmitry Selyutin pisze: > 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! > Hi Dmitry, I'd like to say I personally like the idea of having glibc counterpart in FreeBSD (and possibly other OSes). It's not quite sure though whether you're looking for help with development or review ? Perhaps with something else ? Sincerely, -ŁW
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?530E3B09.2060602>