Date: Wed, 26 Feb 2014 21:02:00 +0100 From: =?ISO-8859-1?Q?Fernando_Apestegu=EDa?= <fernando.apesteguia@gmail.com> To: =?UTF-8?B?xYF1a2FzeiBXw7NqY2lr?= <lukasz.wojcik@zoho.com> Cc: hackers@freebsd.org, ghostmansd@gmail.com Subject: Re: GSoC proposal: Quirinus C library (qc) Message-ID: <CAGwOe2ZVXqyJL7uKHHyS6-NwiQa7d5tDjQ-kOSLaZmeJj8v7nA@mail.gmail.com> In-Reply-To: <530E3B09.2060602@zoho.com> References: <CAMqzjevCoS2qA7jmpPmOXpfzrsD1LzNMJbC8sw-Op-KB-UMhXQ@mail.gmail.com> <530E3B09.2060602@zoho.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 26, 2014 at 8:05 PM, =A3ukasz W=F3jcik <lukasz.wojcik@zoho.com>= wrote: > 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 mainl= y >> by Gnome developers (though it is a standalone library) and LGPL-ed, whi= ch >> is not as liberal as Boost's license. We also have APR, which seems to b= e >> 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 t= he >> 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 memo= ry >> 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 generat= ed >> from errno values as well as from Windows API errors. >> Almost all functions from qc library except for the three common functio= ns >> (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_uc= s >> types for characters, where qc_byte has exactly 8-bit width and qc_ucs h= as >> 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, da= y >> 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 withou= t >> 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, ge= t >> known BSD world better and provide a good cross-platform library which m= ay >> 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 writ= e >> 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 somethi= ng > else ? > I suppose you mean _glib_ instead of glibc (our glibc counterpart is our libc in base). The project sounds nice although a lot of features (like the error treatment, multithreading support...) are already present in glib (and they are very well tested). Cheers. > > Sincerely, > -=A3W > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGwOe2ZVXqyJL7uKHHyS6-NwiQa7d5tDjQ-kOSLaZmeJj8v7nA>