Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #97957 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2016-12-03 23:58 +0100 |
| Last post | 2016-12-10 11:08 -0800 |
| Articles | 11 on this page of 111 — 24 participants |
Back to article view | Back to comp.lang.c
Counted strings jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-03 23:58 +0100
Re: Counted strings supercat@casperkitty.com - 2016-12-03 15:40 -0800
Counted stringsl Thiago Adams <thiago.adams@gmail.com> - 2016-12-03 15:40 -0800
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-04 00:20 +0000
Re: Counted strings Richard Damon <Richard@Damon-Family.org> - 2016-12-03 21:26 -0500
Re: Counted strings jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-04 18:11 +0100
Re: Counted strings Mark Storkamp <mstorkamp@yahoo.com> - 2016-12-04 19:25 -0600
Re: Counted strings Keith Thompson <kst-u@mib.org> - 2016-12-03 18:57 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-04 16:33 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-04 07:52 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-04 17:10 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-04 10:14 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-04 20:20 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-04 16:49 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-05 10:40 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 05:51 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-05 16:10 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 07:38 -0800
Re: Counted strings Melzzzzz <mel@zzzzz.com> - 2016-12-05 16:56 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 08:04 -0800
Re: Counted strings Melzzzzz <mel@zzzzz.com> - 2016-12-05 17:16 +0100
Re: Counted strings Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 16:12 -0500
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 13:24 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-06 10:53 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 03:52 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-06 13:32 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 04:48 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-06 13:42 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 05:16 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-06 14:39 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 05:24 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 05:41 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 05:47 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-06 14:48 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 05:54 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 06:21 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 06:24 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-06 18:06 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 10:19 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-06 19:45 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 11:10 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 12:58 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 14:08 -0800
Re: Counted strings Keith Thompson <kst-u@mib.org> - 2016-12-06 11:25 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 05:28 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-06 16:21 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 07:29 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 07:39 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 08:32 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 08:32 -0800
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-05 16:28 +0000
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 08:34 -0800
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-05 18:27 +0000
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 10:36 -0800
Re: Counted strings Ian Collins <ian-news@hotmail.com> - 2016-12-06 08:19 +1300
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 11:22 -0800
Re: Counted strings Ian Collins <ian-news@hotmail.com> - 2016-12-06 08:26 +1300
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-05 19:36 +0000
Re: Counted strings Ian Collins <ian-news@hotmail.com> - 2016-12-06 08:41 +1300
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 11:48 -0800
Re: Counted strings Thiago Adams <thiago.adams@gmail.com> - 2016-12-05 11:59 -0800
Re: Counted strings jameskuyper@verizon.net - 2016-12-05 12:12 -0800
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 12:18 -0800
Re: Counted strings jameskuyper@verizon.net - 2016-12-05 13:17 -0800
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 13:29 -0800
Re: Counted strings jameskuyper@verizon.net - 2016-12-05 15:37 -0800
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 15:43 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-06 13:40 +0100
Re: Counted strings "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-06 12:00 -0500
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 10:09 -0800
Re: Counted strings Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 13:33 -0500
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-06 21:24 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 12:56 -0800
Re: Counted strings Keith Thompson <kst-u@mib.org> - 2016-12-05 12:22 -0800
Re: Counted strings supercat@casperkitty.com - 2016-12-05 08:36 -0800
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-05 17:31 +0000
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-05 22:07 +0100
Re: Counted strings Ian Collins <ian-news@hotmail.com> - 2016-12-06 10:14 +1300
Re: Counted strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-05 22:11 +0000
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-06 02:13 +0000
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-05 21:57 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 13:01 -0800
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-05 21:22 +0000
Re: Counted strings Ian Collins <ian-news@hotmail.com> - 2016-12-06 10:25 +1300
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-05 21:36 +0000
Re: Counted strings jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-05 22:33 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 17:03 -0500
Re: Counted strings supercat@casperkitty.com - 2016-12-04 08:57 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-04 20:19 +0100
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-04 20:24 +0100
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-04 20:37 +0100
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-04 21:04 +0100
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-04 21:22 +0100
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-04 22:37 +0000
Re: Counted strings David Thompson <dave.thompson2@verizon.net> - 2016-12-10 22:42 -0500
Re: Counted strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-10 23:17 -0800
Re: Counted strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 11:48 +0000
Re: Counted strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-11 04:40 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-11 10:56 +0100
Re: Counted strings Robert Wessel <robertwessel2@yahoo.com> - 2016-12-05 15:47 -0600
Re: Counted strings Gareth Owen <gwowen@gmail.com> - 2016-12-05 22:01 +0000
Re: Counted strings Robert Wessel <robertwessel2@yahoo.com> - 2016-12-05 22:28 -0600
Re: Counted strings "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-05 20:18 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-06 11:05 +0100
Re: Counted strings luser droog <luser.droog@gmail.com> - 2016-12-04 13:13 -0800
Re: Counted strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-05 09:30 -0800
Re: Counted strings Keith Thompson <kst-u@mib.org> - 2016-12-05 09:41 -0800
Re: Counted strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-06 11:19 -0800
Re: Counted strings Keith Thompson <kst-u@mib.org> - 2016-12-06 11:44 -0800
Re: Counted strings Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 10:29 -0800
Re: Counted strings supercat@casperkitty.com - 2016-12-10 11:08 -0800
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-12-05 22:01 +0000 |
| Message-ID | <87y3zuc9xu.fsf@gmail.com> |
| In reply to | #98094 |
Robert Wessel <robertwessel2@yahoo.com> writes: > Penelope in Ulysses? (Joyce). She's Molly in Joyce, Penelope in the original.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-05 22:28 -0600 |
| Message-ID | <mffc4c15s1vqvdutjq9gdp8iigpd6cpt5e@4ax.com> |
| In reply to | #98096 |
On Mon, 05 Dec 2016 22:01:17 +0000, Gareth Owen <gwowen@gmail.com> wrote: >Robert Wessel <robertwessel2@yahoo.com> writes: > >> Penelope in Ulysses? (Joyce). > >She's Molly in Joyce, Penelope in the original. The chapter containing Molly's stream-of-consciousness is called Penelope.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid@invalid.invalid> |
|---|---|
| Date | 2016-12-05 20:18 -0800 |
| Message-ID | <o25e4e$61k$1@dont-email.me> |
| In reply to | #98094 |
On 12/5/2016 1:47 PM, Robert Wessel wrote:
> On Sun, 4 Dec 2016 20:19:09 +0100, Robert Spanjaard
> <spamtrap@arumes.com> wrote:
>
>> On 04-12-16 16:33, David Brown wrote:
>>>> What are your ideas about counted strings?
>>>>
>>>> How could it be done?
>>>
>>> I would be inclined to simplify to only two possible choices - an 7-bit
>>> length that covers most small strings, and a 31-bit length that covers
>>> any string (data that is more than 2GB is size is not a "string").
>>>
>>> You could use the LSB of the first byte of the string to determine if
>>> the rest of the byte gives the 7-bit length, or if the rest of the first
>>> 4 bytes gives the 31-bit length. Distinguishing between the two is just
>>> a bit test, and decoding the length is a simple shift instruction
>>> (especially if you have a little-endian platform with 32-bit unsigned
>>> ints and misaligned load support).
>>>
>>> I think there is little to be gained by supporting 16-bit length fields.
>>
>> That depends on what type of data you're going to count. For normal text
>> (books, papers, etc), 16 bit seems to be a sensible length. I never
>> encountered a single paragraph longer than 65535 characters,
>
>
> Penelope in Ulysses? (Joyce).
>
Check this crap out:
____________________________________
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#define HEADER_SIZE 8
#define HEADER_STR "DEADBEEF"
#define CONCAT(mp_a, mp_b)mp_a##mp_b
#define STRING_DEFINE_VAR(mp_name, mp_ustr) \
char CONCAT(mp_name, _STRING_base)[] = HEADER_STR "\0" mp_ustr; \
char* mp_name = CONCAT(mp_name, _STRING_base) + (HEADER_SIZE + 1)
char*
header_raw_get(
char* buf
){
char* hbuf = buf - (HEADER_SIZE + 1);
return hbuf;
}
int main()
{
// do pascal string hack thing...
STRING_DEFINE_VAR(mstr, "Hello");
char* rstr = header_raw_get(mstr);
printf("mstr:%s\n", mstr);
printf("rstr:%s\n", rstr);
return 0;
}
____________________________________
We store 8 chars in the header.
;^)
[toc] | [prev] | [next] | [standalone]
| From | Robert Spanjaard <spamtrap@arumes.com> |
|---|---|
| Date | 2016-12-06 11:05 +0100 |
| Message-ID | <o262gk$1e6g$1@gioia.aioe.org> |
| In reply to | #98094 |
On 05-12-16 22:47, Robert Wessel wrote: >> That depends on what type of data you're going to count. For normal text >> (books, papers, etc), 16 bit seems to be a sensible length. I never >> encountered a single paragraph longer than 65535 characters, > > Penelope in Ulysses? (Joyce). I don't know what the original printed version looks like, but on Project Gutenburg it's still divided into seven paragraphs of 4474, 11192, 11837, 16151, 17767, 18025 and 21383 characters. -- Robert Spanjaard
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-12-04 13:13 -0800 |
| Message-ID | <0087d2e5-1b6b-4862-9d4f-751bc986deb7@googlegroups.com> |
| In reply to | #97957 |
On Saturday, December 3, 2016 at 4:58:20 PM UTC-6, jacobnavia wrote: > What are your ideas about counted strings? > > How could it be done? In my two interpreters, strings are always associated with a count. But while I could explain their structures at length, none of it would really be applicable to the situation here where we want a "data layout" or "format" rather than a /structure/. Most appealing to me from an aesthetic sense are the examples of the utf-8 encoding and the MIDI encoding of variable-length integers. The utf-8 encoding, briefly, has an initial /unary/ count of the number of bytes. Looking at the top bits of the first byte of a utf-8 encoded character, if it's 0, value fits in the same byte, 7-bits if it's 10, value fits in 2 bytes, 12-bits if it's 110, value fits in 3 bytes, 17 bits if it's 1110, value fits in 4 bytes, 22 bits An earlier draft extends the system to a max of 6 bytes where the value has 32 bits. But in order to have the ability to easily take a roughly chosen pointer into the middle of the string and then find the beginning of the character you're pointing at/into, utf-8 also puts these unary tags on all the following bytes, which seems inefficient for this count- prefix application where we're not trying take these roughly-chosen pointers are we? If we drop the tags on the following bytes, the 5 bytes gives 36 bits of value already. The other interesting scheme is used in MIDI files (one of my first language implementations was a midi-file assembler). For integers, the top bit of each byte was used as an "end-value" sentinel and the value was the concatenation of the 7-bit payloads, so if top bit is 1, val is 7-bit 2's-compl else if top bit of 2nd byte is 1, val is 14-bit else if top bit of 3rd byte is 1, val is 21-bit else if top bit of 4th byte is 1, val is 28-bit So, a 5th byte in this scheme gives us 35 bits of value.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-05 09:30 -0800 |
| Message-ID | <97ca2dbf-f636-423d-93f8-61204901a182@googlegroups.com> |
| In reply to | #97957 |
On Saturday, December 3, 2016 at 10:58:20 PM UTC, jacobnavia wrote: > > What are your ideas about counted strings? > > How could it be done? > It's a very standard data compression problem. You need to gather statistics, but also consider ease of implementation and obviousness. I think 8 clear bits need to be the empty string. If the high bit of the first byte is unset, it's asciiz (backwards compatibility). That then gives us 7 bits to play with for encodings. We can store UTF8 / ascii, 8 bit, 16 bit, 32 bit, 64 bit counts, and we've still 4 bits left. So nul/non-nul terminated. Now it's three bits.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-05 09:41 -0800 |
| Message-ID | <lnr35m46k2.fsf@kst-u.example.com> |
| In reply to | #98026 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, December 3, 2016 at 10:58:20 PM UTC, jacobnavia wrote:
>> What are your ideas about counted strings?
>>
>> How could it be done?
>>
> It's a very standard data compression problem.
>
> You need to gather statistics, but also consider ease of implementation
> and obviousness.
> I think 8 clear bits need to be the empty string. If the high bit of
> the first byte is unset, it's asciiz (backwards compatibility).
> That then gives us 7 bits to play with for encodings. We can store
> UTF8 / ascii, 8 bit, 16 bit, 32 bit, 64 bit counts, and we've still
> 4 bits left. So nul/non-nul terminated. Now it's three bits.
So for strings of length 127 or less, you still have to scan for
the terminating '\0' to determine the length. That could be a
performance problem (and no improvement over standard C strings)
if you have a lot of relatively short strings.
In addition to improving the speed of length calculations, another
advantage of counted strings is that they allow the possibility of
having null bytes within a string. Your scheme loses that.
I suppose there might be some contexts where your scheme would make
sense.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-06 11:19 -0800 |
| Message-ID | <ae62a155-9f37-4e0a-bfbe-c5655b333fb6@googlegroups.com> |
| In reply to | #98028 |
On Monday, December 5, 2016 at 5:41:17 PM UTC, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > On Saturday, December 3, 2016 at 10:58:20 PM UTC, jacobnavia wrote: > >> What are your ideas about counted strings? > >> > >> How could it be done? > >> > > It's a very standard data compression problem. > > > > You need to gather statistics, but also consider ease of implementation > > and obviousness. > > I think 8 clear bits need to be the empty string. If the high bit of > > the first byte is unset, it's asciiz (backwards compatibility). > > That then gives us 7 bits to play with for encodings. We can store > > UTF8 / ascii, 8 bit, 16 bit, 32 bit, 64 bit counts, and we've still > > 4 bits left. So nul/non-nul terminated. Now it's three bits. > > So for strings of length 127 or less, you still have to scan for > the terminating '\0' to determine the length. That could be a > performance problem (and no improvement over standard C strings) > if you have a lot of relatively short strings. > No, because the representation is slightly redundant. "Fred" can be 'F' 'r' 'e' 'd' '\0' or 0x80, 0x04, 'F' 'r' 'e' 'd' > > > In addition to improving the speed of length calculations, another > advantage of counted strings is that they allow the possibility of > having null bytes within a string. Your scheme loses that. > Again, no. Obviously it can't be both asciiz and have embedded nul bytes, but we can store 0x80 0x0D, 'F' 'r' 'e' 'd' 0 'i' 's' 0 'd' 'e' 'a' 'd' 0 > > I suppose there might be some contexts where your scheme would make > sense. > Anywhere you want a reasonably efficient and intuitive encoding for counted strings, and backwards compatibility with asciiz strings. But no claims to be the last word, I'm sure some people can do better.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-06 11:44 -0800 |
| Message-ID | <lntwag3kry.fsf@kst-u.example.com> |
| In reply to | #98198 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, December 5, 2016 at 5:41:17 PM UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> > On Saturday, December 3, 2016 at 10:58:20 PM UTC, jacobnavia wrote:
>> >> What are your ideas about counted strings?
>> >>
>> >> How could it be done?
>> >>
>> > It's a very standard data compression problem.
>> >
>> > You need to gather statistics, but also consider ease of implementation
>> > and obviousness.
>> > I think 8 clear bits need to be the empty string. If the high bit of
>> > the first byte is unset, it's asciiz (backwards compatibility).
>> > That then gives us 7 bits to play with for encodings. We can store
>> > UTF8 / ascii, 8 bit, 16 bit, 32 bit, 64 bit counts, and we've still
>> > 4 bits left. So nul/non-nul terminated. Now it's three bits.
>>
>> So for strings of length 127 or less, you still have to scan for
>> the terminating '\0' to determine the length. That could be a
>> performance problem (and no improvement over standard C strings)
>> if you have a lot of relatively short strings.
>>
> No, because the representation is slightly redundant.
> "Fred" can be 'F' 'r' 'e' 'd' '\0'
> or
> 0x80, 0x04, 'F' 'r' 'e' 'd'
So you *might* have to scan for the terminating '\0', depending on which
of two representations was chosen.
And what if I happen to want a string whose first character is 0x80?
Is this:
0x80, 0x04, 'F' 'r' 'e' 'd' '\0'
a 4-character string starting with 'F' (with a redundant null byte past
the end), or a 6-character string starting with 0x80? Redundancy is ok.
Ambiguity, not so much.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-10 10:29 -0800 |
| Message-ID | <kfn1sxfk58i.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #97957 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Instead of prefixing a string with its count, we could do a variable
> length encoding, like in utf8.
>
> Strings of length 0 to 254 would be prefixed by a byte containing the
> length. If the value of that byte is 255 (0xff, all ones) it means
> that the length is encoded in the next two bytes. [...]
>
> What are your ideas about counted strings?
IMO any scheme that is not interoperable with regular C strings
is a non-starter. Here "regular C strings" may be taken to mean
ASCII and UTF-8. With that in mind I suggest an idea along
the following lines:
first byte is meaning
------------- -------
0 to 127: start of regular zero-terminated string
128 to 187: start of string of length n-127
(length is between 1 and 60 characters)
188: next two bytes encode length
189: next four bytes encode length
190: reserved
191: reserved
192 to 255: start of UTF-8 multibyte character in a
regular zero-terminated string
An empty string is always indicated with an initial byte of
zero. In all other cases strings may be zero-terminated or
they may have a length prefix. (I think it's a good idea
to zero-terminate even those strings that have a length
prefix, but that can be a separate discussion.)
The key point is that any string that is valid UTF-8 may be used
as is. Length prefixes are available for cases that need them.
An empty string is the only exception to that, which seems like a
good choice since checking for an empty string by seeing if the
first character is null is so deeply entrenched for most C
developers.
So that's my suggested outline. Comments?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-10 11:08 -0800 |
| Message-ID | <ef9a9b0a-9746-40c3-b261-91af4cd72a10@googlegroups.com> |
| In reply to | #98725 |
On Saturday, December 10, 2016 at 12:29:24 PM UTC-6, Tim Rentsch wrote: > IMO any scheme that is not interoperable with regular C strings > is a non-starter. Here "regular C strings" may be taken to mean > ASCII and UTF-8. With that in mind I suggest an idea along > the following lines: It would be useful for a newString type to be designed in such a way that given a pointer to a newString one could easily get a pointer that could be passed to a function that would use a C string in read-only fashion, and that when given a pointer to a C string of known length could create an object whose address could be given to code that would use a newString in read-only fashion. If those two operations can be performed efficiently, that would achieve 99% of the usefulness that could be achieved by making the pointers directly compatible, while yielding a much cleaner design than would be possible if pure pointer compatibility were required.
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.c
csiph-web