Re: Boost process and C

CBFalconer wrote:
websnarf@xxxxxxxxx wrote:
Ben Pfaff wrote:
... snip ...
No. I mean that some string operations can be expressed shorter
and with more clarity in Perl than in C. No new string library
will change this.
That's a pretty wishy washy premise on which to base an implied
disapproval of Bstrlib. Let me just guess that you haven't really
seriously taken a look at it.

The last time I took an (admittedly cursory) look at Bstrlib, I
found it cursed with non-portabilities

You perhaps would like to name one?

[...] and unwarrented assumptions,

Such as?

not to mention an interminable API.

It is not necessary to learn or use the entire API to use it
effectively. If it seems large you can blame the current crop of users
who have motivated all the extensions from its original base functions.
In each case I could not make a strong enough case to avoid each
functions' inclusion. You appear to be the only person obsessed with
this non-issue.

[...] This is a criticism very few can make of the standard C string operations.

The C standard says that whether or not "string literals" are writable
is platform specific. It doesn't even specify what wchar_t contains
-- for example, the WATCOM compiler supports the old UCS-2 in its 16
bit compilers, and UTF-32 in its 32 bit compilers (while not
implementing a properly functioning setlocale function). So much for
portability. Bstrlib is *designed* for portability (including semantic
behavior irrespective of platform).

Every C string function which writes makes the one unwarranted
assumption that it cannot make -- i.e., that the size of the buffer
that holds the destination will be large enough for whatever operation
it is doing. fgets() makes the assumption that the input stream is in
text mode, or that it doesn't read a '\0' or that you just don't care
about that case. Nearly every string function *assumes* that the
parameters are non-aliasing (that's worse than just an unwarranted
assumption -- its just degenerate in terms of functionality). It is
*assumed* that you don't make interleaved calls strtok on different
strings. And of course, the format of C strings *assumes* that '\0'
will never be considered part of a string's content -- this assumption
ends up permeating all system string APIs, for any platform that uses C
as its main implementation language.

In terms of API size, Bstrlib is about 80 base C functions (which
includes the stream API functions) and 18 macros (there are 22 "bonus"
functions for doing MIME parsing and other miscellaneous utilities, and
there is a C++ API). The string.h file for one of my compilers has
about 57 extern functions. Then we need to add
(f|s|v|vs|sn|vsn|vf|)printf, (f|)puts, (f|)gets, (s|)scanf, ato(f|i|l),
strto(d|l), which is 19 all by itself. Add in the wide characters and
you'll nearly double that count. Bstrlib is not drammatically more
"interminable" than the standard C library.

And you just can't compare the size of the APIs to judge how easy it is
to use or understand. To know all of the undefined scenarios of the C
library functions, you have to do a function by function examination of
the standard. With Bstrlib, all you have to do is make sure each
parameter is well defined, you don't abuse the write protection, and
don't destroy a value if you use an alias of it later. So the effort
to understand each function is Bstrlib is far lower. The functions in
Bstrlib also tend, on average, to do a lot more per function -- so your
investment in understanding has a higher payoff. And the thing is open
source, so there is never any ambiguity about any Bstrlib function that
you cannot authoritatively figure out on your own.

So I don't know what you last looked at, because you are just plain
wrong.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

.

Relevant Pages

  • Re: Hash functions (was: Maximum String size in Java?)
    ... Bstrlib is *NOT* suspect. ... > your string library has problems with them speaks for itself. ... some kind of corruption of the raw source file. ... occurred to me that the corruption was truly in the source file itself. ...
    (comp.programming)
  • Re: Secure C library
    ... >> string functions don't make much sense once you add bounds-checking ... >> designing an interface just for the purpose of reducing the frequency ... > make buffer size decisions more visible, ... Bstrlib is also very interoperable with char *'s, ...
    (comp.std.c)
  • Re: Handling delimited strings
    ... library written in C and C++, which adds useful string functionality to ... In Bstrlib you can call bgetsor similar functions on top of fgetc. ... A reference, or pointer, to a sub-string in FILENAME ... > The COUNT action would return the number of delimiters in FILENAME at ...
    (comp.programming)
  • Re: Strings in C are less optimal than in (say) Pascal - correct?
    ... > know the length of such a string, the resultant discovery is therefore very ... if prefix is just some offset that we know is in the middle of dest? ... A common complaint with other string libraries which are not char * ... based (and sometimes erroneously cited as a reason to avoid Bstrlib) is ...
    (comp.lang.c)
  • Re: PInvoke Marshalling....
    ... The wParam is a pointer to a API defined structure (containing a Low DWORD ... contents of the string builder. ... "DeviceHandle" and not indicative that it is a windows handle. ... public static extern int SNAPI_SetVersionBuffer(IntPtr DeviceHandle, ...
    (microsoft.public.dotnet.languages.csharp)