Re: Boost process and C

Keith Thompson wrote:
websnarf@xxxxxxxxx writes:
CBFalconer wrote:
websnarf@xxxxxxxxx wrote:
CBFalconer wrote:
... snip ...
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?

I took another 2 minute look, and was immediately struck by the use
of int for sizes, rather than size_t. This limits reliably
available string length to 32767.

Using size_t is also not any more *portable* than using int. Any lack
of portability is merely a reflection of the lack of the intrinsic
non-portability of the language itself. size_t can only reliably
contain values as high as 65535 -- so you are saying this difference in
limits (between 32k and 64k) embodies a significant universe of string
manipulation to warrant a claim against Bstrlib's portability?

Yes.

I can't speak for Chuck, but size_t can reliably contain the size of
any object that the system can create. That's what it's for. If the
maximum value of size_t is 65535, then the system isn't going to be
able to create objects bigger than 65535 bytes.

It's entirely possible to have a conforming implementation in which
int is 16 bits, but size_t is 32 bits. On such a system, using int to
represents sizes needlessly sacrifices the ability to handle objects
bigger than 32767 bytes. For that matter, it's conceivable (but
unlikely) that size_t could be smaller than int.

None of this speaks of the portability complaint CBF was claiming to
make. Its also an extremely marginal complaint that ignores the
tremendous benefit of this design choice, as I've already thoroughly
explained.

[...]
Hundreds of people have downloaded Bstrlib and seriously looked at it
already. I've gotten plenty of feedback over its lifetime which has
lead to its evolution (so its not like it hasn't already had
significant review). You, of all people, are not going find any
serious flaw in it by perusing it for 2 minutes.

"Cursed with non-portabilities" indeed ...

Do you have any figures on the number of people who have looked at it
briefly, rejected it because it's too complex, and not bothered to
mention it to you? [...]

How do you suppose I would obtain such figures? I instead count the
actual feedback, and from that feedback count the number of people who
complained of portability problems (none) hidden assumptions (none) and
interminable API (none -- well even less than none, since people keep
asking me to add things into it.)

I also roughly count the number of people who have included Bstrlib in
their project but for some reason don't tell me about this fact (just
using google). While some of them may be being irresponsible and just
using the library without looking at the source at all -- I highly
doubt that that represents the majority, or that I can find even a
significant percentage of all such people this way.

Its not like a language standard where the audience is obvious
(compiler vendors) and so if you wanted to know if the standard was
rejected, you could just count up the number of people who upgraded
their compiler, but didn't implement the standard, say.

[...] I'm not saying there are a lot of such people (obviously I don't have any such
figures myself),

You can look in the sourceforge project page; the number of downloads
is not a secret.

There have, in fact, been thousands of downloads, but clearly a
significant number of them are probably just people getting the latest
version -- so I'm just estimating. There are a lot of "first day of
release" downloads of my library, indicating I have repeat customers
(about a hundred within the first few days of any new release) who are
very interested in keeping up to date with the latest version. But at
the same time, there are many more conservative people with on going
projects who I can see from their sources are using old versions of the
library.

[...] but I don't think
you can exclude the possibility that it's a common thing.

That's true, but I have received enough feedback to suggest that this
library has survived quite a thorough amount of auditting. Some
bugs have been caught, and the design has been improved because of it.

For the average source file in any environment, you are lucky if you
can get *one* person to review it. Bstrlib has clearly far exceeded
that.

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

.

Relevant Pages

  • Re: Boost process and C
    ... Using size_t is also not any more *portable* than using int. ... of portability is merely a reflection of the lack of the intrinsic ... able to create objects bigger than 65535 bytes. ... "Cursed with non-portabilities" indeed ... ...
    (comp.lang.c)
  • Re: Boost process and C
    ... available string length to 32767. ... Using size_t is also not any more *portable* than using int. ... of portability is merely a reflection of the lack of the intrinsic ... "Cursed with non-portabilities" indeed ... ...
    (comp.lang.c)
  • Re: Basic questions
    ... The compiler is allowed to insert padding bits wherever it likes ... > As 16 is an int, what you wrote is equivalent to ... if the OP uses 'unsigned short' only to store 16-bit numbers (writing ... values, so they're not a panacea for portability, and they might trick ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Moving from C++ to VC++
    ... If you care about ... not some abstract notion of portability. ... probably still sit on 8bit 'int'. ... > size, index, or anything having to do with capacity in a data structure, ...
    (microsoft.public.vc.language)
  • Re: C99 exact width integers usage - informal survey
    ... so you can write perfectly portable code (assuming ANSI ... yes and no on the portability issue. ... types int and unsigned int. ... That's why the exact sized int types are not required in C99 unless ...
    (comp.arch.embedded)