Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

C String Libraries

Name: Anonymous 2010-02-20 10:48

What are your experiences from using C string libraries (bstring and friends)? I'm starting a project that I'm going to write in ANSI C and that is quite heavy on string processing, and having support for actual strings (as opposed to null-terminated arrays) would be a real time saver. And no, I'm not going to use glib or any other `let's make C something else entirely' solution.

Name: Anonymous 2010-02-20 10:54

I fucking hate when people say, "C string libraries" so kindly shut up.

Name: Anonymous 2010-02-20 11:09

I'm starting a project that I'm going to write in ANSI C
I lol'd
quite heavy on string processing
I lol'd again
and having support for actual strings (as opposed to null-terminated arrays) would be a real time saver
If you really want to save time, you'd do it in a higher level language.

Name: Anonymous 2010-02-20 11:20

>>1
Write it in Common Lisp, OP. It has support for actual strings (as opposed to null-terminated arrays; lolC) and you'll get some Ediware to help you.

Name: Anonymous 2010-02-20 11:30

>>3,4
I considered other languages (mainly Lisp and Python, because I know them), but one of the main requirements of this particular piece of software is to compile out of the box without any additional asshattery on basically any platform in existence to a small binary. C is the only language I know and am willing to use that satisfies this property.

Name: Anonymous 2010-02-20 12:01

And no, I'm not going to use glib or any other `let's make C something else entirely' solution.

Try with libdacav. It gives you a simple implementation of linked lists, hash tables, heaps and buffered strings (which is what you need)

Name: Anonymous 2010-02-20 12:20

>>6
Results 1 - 7 of about 5 for libdacav. (0.29 seconds)

Name: Anonymous 2010-02-20 12:49

>>7
Your Google is outdated. Mine took only 0.24 seconds.

Name: Anonymous 2010-02-20 13:34

>>7
>>8
You are both horribly inferior to the glorious 0.08 seconds Google machine

Name: Anonymous 2010-02-20 13:35

>>5
Ever heard of the ECL (Embeddable Common Lisp, CL to C) and Gambit-C (Scheme to C) implementations. You could compile your code to C and just use that, unless you want C programmers to edit/work on that code afterwards, which would mean you would either have to write it in C, or use something like thinlisp.

Personally I always found string handling in C somewhat tedious, but it's not too hard. Write yourself a structure which can hold: 1) string length 2)string encoding (optional if you will only work with one encoding) 3)character buffer, and then write operations on that, usually extending on standard libc ones. You'll end up with a fairly safe way to handle strings, but it won't make you less of a human compiler, unless you add yourself enough functionality for string manipulation (formatting, reading patterns, regexps, maybe some lex/yacc,...). If I were you I'd prefer writing this in any high-level language which has decent string handling capabilities (Common Lisp, C#, Java, Perl, ...).

Name: Anonymous 2010-02-20 13:36

Oh, come on guys, not so difficult. Here you are:
http://simgidacav.altervista.org/?page=libdacav

Name: Anonymous 2010-02-20 13:39

>>11

What is One manga dumper?

One manga is a funny script that allows to download all jpegs composing a manga on onemanga.com. Actually I'm not a huge manga fan. The story is something like "Once upon a time a guy asked me how to download a manga from there, and I wrote a script for this." ...quite simple, isn't it?

You can just download the script by clicking [url="http://simgidacav.altervista.org/download.php?file=scripts/onemangadump"] here[/url].

http://simgidacav.altervista.org/?page=onemanga

Name: Anonymous 2010-02-20 13:41

NxOS

NxOS is a small operating system for Lego Mindstorms on which I worked during my thesis time. I'm not going to talk about it in this page. The point is that NxOS's scheduler works as a simple application supporting a context change mechanism, which emulates a multithreading environment.

Ever since I was working on it, me and my collegues found the lack of this feature pretty annoying. In this very moment (Jan 25, 2k10) I'm working on it as a project for a university exam, so that I'm killing two birds with one stone.

http://simgidacav.altervista.org/?page=armheap

Pretty cool stuff I'd say.

Name: Anonymous 2010-02-20 13:47

>>10
Ever heard of the ECL (Embeddable Common Lisp, CL to C) and Gambit-C (Scheme to C) implementations.
Quite obviously, yes, I have.

unless you want C programmers to edit/work on that code afterwards
I thought the fact that I want to write it in C kind of implied this.

Personally I always found string handling in C somewhat tedious, but it's not too hard. Write yourself a ... lex/yacc,...).
Yes, I know how to implement a proper string handling library in C, but I don't believe there's need to actually do that, because n+1 programmers have already done it before me. I was asking about your experience on them.

If I were you I'd prefer writing this in any high-level language which has decent string handling capabilities (Common Lisp, C#, Java, Perl, ...).
If I were me, I would also prefer to write it in almost anything else, but this time, I'M ABSOLUTELY FUCKING POSITIVELY SURE THAT C IS THE ONLY LANGUAGE THAT FITS THE REQUIREMENTS (except maybe C++, but I've got some standards, too.)

Name: Anonymous 2010-02-20 13:49

>>5
Why could that possibly be a requirement? I submit that you are, in fact, an asshat.

Name: Anonymous 2010-02-20 19:02

Just get used to pointers.
something like

char *cPtr;
for(cPtr = string;*cPtr != '\0';cPtr++)
    processchar(*cPtr);

and you're basically all set.
Point to end of string:
cPtr += strlen(cPtr);

strtok can be quite annoying.

Just play around with it a bit and you'll get used to it.

Name: Anonymous 2010-02-20 19:39

>>16
It's not just annoying! Just read the manpage, and you'll find out it sucks monkey balls:

BUGS
       Be cautious when using these functions.  If you do use them, note that:

       * These functions modify their first argument.

       * These functions cannot be used on constant strings.

       * The identity of the delimiting character is lost.

       * The strtok() function uses a static buffer while parsing, so it's not
         thread safe.  Use strtok_r() if this matters to you.

Name: Anonymous 2010-02-20 19:45

>>17
This is why I step through the strings myself looking for delimiting cahracters.
Also gawk.

Name: Anonymous 2010-02-20 20:11

>>10
Is it possible to compile programs with ECL so that don't end up being 50mb monsters like with sbcl?

Name: Anonymous 2010-02-20 20:22

glib is quite excellent. Just stay the hell away from gobject.

Name: Anonymous 2010-02-20 20:36

>>19
Yes, ECL binaries tend to be rather tiny compared to full memory dumps that real natively compiled lisps produce. There's some shared library with the runtime which is ~1mb and the main executable can be fairly tiny (dozen, hundred kb for small apps).

Name: Anonymous 2010-02-21 0:54

>>17
so rewrite strtok. rolling your own solution is going to be faster and easier than reading and understanding someone elses

Name: Anonymous 2010-02-21 4:23

>>22
so rewrite hax. trolling your own anus is going to be faster and easier than haxing and understanding someone elses anus

fixed

Name: Anonymous 2010-02-21 4:50

>>16
Cute. I've programmed in C since mid-90s, and I'm already quite `used to pointers'. I know how to do string processing in C and I know how it differs from string processing in languages that have, like, an actual string data type.

Name: Anonymous 2010-02-21 5:03

>>24
You can always emulate a real string datatype as long as you're willing to write a lot of functions which operate on your new datatype.

Name: Anonymous 2010-02-21 5:05

>>25
Do you realize that you're posting on a thread whose sole purpose is to seek for an existing library of such functions?

Name: Anonymous 2010-02-21 5:07

Let me ask this: Why write your own string type/use a string library when you have to convert it back every time you use a different library that happens to expect char* as input parameter?

Name: Anonymous 2010-02-21 5:15

>>27
Because your anus was haxed.

______
If you believe in Anus Haxing and are 100% proud of it put this as your signature.

Name: Anonymous 2010-02-21 5:18

>>27
I'm assuming a sane C string library exposes the underlying char * for the times I know I need it, and tells what I can do with it without breaking stuff.

Name: Anonymous 2010-02-21 5:52

>>27
Look how GString from Glib handles it.

Name: Anonymous 2010-02-22 12:47

bstring frustrates me incredibly because it has the stupid BSD binary advertising clause. Instead I'll end up writing my own for my C project (not OP). Dammit.

Name: sage 2010-02-22 16:56

sage

Name: Anonymous 2010-02-24 13:45

>>31
Can I suggest you do develop your own set of library? On the long period this allows you to reuse your own source code without messing with third party.

Don't change these.
Name: Email:
Entire Thread Thread List