Groups > comp.lang.c > #126205 > unrolled thread

Count string in string with loop increase 2, why is this not faster?

Started by	Bart Smissaert <bart.smissaert@gmail.com>
First post	2018-02-03 00:00 -0800
Last post	2018-02-03 22:03 +0000
Articles	18 on this page of 98 — 10 participants

Back to article view | Back to comp.lang.c

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

#126307

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2018-02-05 22:29 +0000
Message-ID	<87tvuv840h.fsf@bsb.me.uk>
In reply to	#126305

supercat@casperkitty.com writes:
<snip>
> The authors of Unicode seem to have assumed that the same format should be
> used for data processing, rendering, and bulk storage,

What is your evidence for this?  Evidence to contrary includes documents
issued by the Unicode consortium.  For example

  "For processing rather than storage, the Unicode encoding form is
  usually selected for easy interoperability with existing APIs. Where
  there is a choice, the trade-off between decoding complexity (high for
  UTF-8, low for UTF-16, trivial for UTF-32) and memory and cache
  bandwidth (high for UTF-32, low for UTF-8 or UTF-16) should be
  considered."

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#126298

From	Keith Thompson <kst-u@mib.org>
Date	2018-02-05 09:01 -0800
Message-ID	<lnd11j2wxb.fsf@kst-u.example.com>
In reply to	#126287

David Brown <david.brown@hesbynett.no> writes:
[...]
> The whole concept of a "char" being signed or unsigned is more than a
> little odd to me - it is, I think, a historical accident.
[...]

What would be the alternative?  If char is an integer type it has to be
either signed or unsigned (unless you say that operations where it
matters have undefined behavior).

-- 
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]

#126302

From	bartc <bc@freeuk.com>
Date	2018-02-05 18:44 +0000
Message-ID	<WB1eC.982076$g_1.636152@fx35.am4>
In reply to	#126298

On 05/02/2018 17:01, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> The whole concept of a "char" being signed or unsigned is more than a
>> little odd to me - it is, I think, a historical accident.
> [...]
> 
> What would be the alternative?  If char is an integer type it has to be
> either signed or unsigned

Not really. You can simply state that char is an unsigned integer type. 
But in C, an alternate type is needed to take on the role of 
signed/unsigned 8-bit types.

In my language there are:

   int    - signed
   word   - unsigned
   char   - just character, but with same range as a word of same width

Each available with a width of 8, 16, 32 or 64 bits (except I limit char 
to 32).

Similar with C#: usual int types, and separate char type (I think 16 
bits there).

Same with Go, where a char type is a 'rune', an alias for int32. This is 
signed, but the int32 can represent any Unicode character as a positive 
values, so that's not so important.

Same with Rust, with a different kind of type for 'char', defined as 
something that can represent any Unicode value.

Java I think also has a separate char type, which seems to be 16 bits.

So just about every language except C knows how to do it. Not just 
recent ones either: I've had a separate 'char' type since early 80s.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#126324

From	David Brown <david.brown@hesbynett.no>
Date	2018-02-06 10:42 +0100
Message-ID	<p5bt9u$61s$1@dont-email.me>
In reply to	#126298

On 05/02/18 18:01, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> The whole concept of a "char" being signed or unsigned is more than a
>> little odd to me - it is, I think, a historical accident.
> [...]
> 
> What would be the alternative?  If char is an integer type it has to be
> either signed or unsigned (unless you say that operations where it
> matters have undefined behavior).
> 

The alternative would be for it not to be an integer type at all - and
require explicit functions for conversion back and forth with integers.
 That is what other languages do.

In my "perfect language", there would be a "character" type that holds a
single 8-bit value covering ASCII and UTF-8 code points.  This would not
be implicitly convertible to other types, nor would it have any special
aliasing properties.  Types "uint8_t" and "int8_t" would exist, and work
in the same way as other fixed size integer types.  There would be types
"raw8_t", "raw16_t", etc., for accessing underlying data
representations, with special aliasing powers - "memcpy" would work with
"raw8_t * ", for example.

I am not going give a longer list of features or discuss details - it is
off-topic, it is totally hypothetical (not nearly at the stage of
"vapourware"!), inconsistent, incomplete, and the details vary
drastically every time I think how a "perfect" language would be.

But one thing for sure is that character data and arithmetic data would
not be mixed implicitly.  If a language has a concept of a "char" or
"character" where it even makes sense to ask about its signedness, it's
got that bit of design wrong.  IMHO, of course :-)

[toc] | [prev] | [next] | [standalone]

#126325

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2018-02-06 11:17 +0000
Message-ID	<87h8qumkog.fsf@bsb.me.uk>
In reply to	#126324

David Brown <david.brown@hesbynett.no> writes:
<snip>
> The alternative would be for it not to be an integer type at all - and
> require explicit functions for conversion back and forth with integers.
>  That is what other languages do.
>
> In my "perfect language", there would be a "character" type that holds a
> single 8-bit value covering ASCII and UTF-8 code points.

This looks a but messed up.  The bytes that make up a multi-byte
encoding like UTF-8 have no meaning at all except as numbers (well, bit
patters as much numbers but it the same thing for most languages).  Of
all the operations you decide to permit on this 8-bit character type,
only the conversions to and from integers are useful for individual
UTF-8 bytes, and they are needed every time for every use of the byte!

A character type should represent characters, with some set of relevant
operations depending on the design, and UTF-8 sequences should be
represented as byte sequences with numeric values.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#126328

From	Richard Damon <Richard@Damon-Family.org>
Date	2018-02-06 08:40 -0500
Message-ID	<SfieC.13262$9z2.11550@fx43.iad>
In reply to	#126325

On 2/6/18 6:17 AM, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> <snip>
>> The alternative would be for it not to be an integer type at all - and
>> require explicit functions for conversion back and forth with integers.
>>   That is what other languages do.
>>
>> In my "perfect language", there would be a "character" type that holds a
>> single 8-bit value covering ASCII and UTF-8 code points.
> 
> This looks a but messed up.  The bytes that make up a multi-byte
> encoding like UTF-8 have no meaning at all except as numbers (well, bit
> patters as much numbers but it the same thing for most languages).  Of
> all the operations you decide to permit on this 8-bit character type,
> only the conversions to and from integers are useful for individual
> UTF-8 bytes, and they are needed every time for every use of the byte!
> 
> A character type should represent characters, with some set of relevant
> operations depending on the design, and UTF-8 sequences should be
> represented as byte sequences with numeric values.
> 
> <snip>
> 

WHile individual code points may not be that useful, most of the program 
is probably dealing with them as strings, with pointers and indexes into 
arrays of them. For most code we don't need 'arithmetic' on the code 
point, just basic movement and comparisons.

There will need to be some low level functions that takes these strings 
and perform some basic operations to get real characters (full 21+ bit 
values)) out of them, and those routines will need the conversion, but 
making it explicit wouldn't make that code that ugly.

Of course, when C was being invented, characters were only 8 bits (at 
most) long for almost all cases, and it was coming out of a language 
where everything was an int (pointers weren't a unique type, just 
operators on int values) so characters acting as int was natural.

Yes, making characters a non-arithmatic type might make sense, but would 
be a major breaking change. Some coding/quality standards like MISRA 
basically define that the char type should only be used for real 
characters (and thus not much need for arithmetic), and when being used 
for tiny numbers, you need to explicitly use signed char and unsigned 
char (which generally should NOT be used for real text).

[toc] | [prev] | [next] | [standalone]

#126331

From	bartc <bc@freeuk.com>
Date	2018-02-06 14:08 +0000
Message-ID	<qFieC.982085$g_1.313207@fx35.am4>
In reply to	#126328

On 06/02/2018 13:40, Richard Damon wrote:
> On 2/6/18 6:17 AM, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> <snip>
>>> The alternative would be for it not to be an integer type at all - and
>>> require explicit functions for conversion back and forth with integers.
>>>   That is what other languages do.
>>>
>>> In my "perfect language", there would be a "character" type that holds a
>>> single 8-bit value covering ASCII and UTF-8 code points.
>>
>> This looks a but messed up.  The bytes that make up a multi-byte
>> encoding like UTF-8 have no meaning at all except as numbers (well, bit
>> patters as much numbers but it the same thing for most languages).  Of
>> all the operations you decide to permit on this 8-bit character type,
>> only the conversions to and from integers are useful for individual
>> UTF-8 bytes, and they are needed every time for every use of the byte!
>>
>> A character type should represent characters, with some set of relevant
>> operations depending on the design, and UTF-8 sequences should be
>> represented as byte sequences with numeric values.
>>
>> <snip>
>>
> 
> WHile individual code points may not be that useful, most of the program 
> is probably dealing with them as strings, with pointers and indexes into 
> arrays of them. For most code we don't need 'arithmetic' on the code 
> point, just basic movement and comparisons.

The following operations can make sense:

   char + int  (and possibly vice versa)
   char - int
   ++char
   --char
   char - char
   char < char etc

But the following probably don't:

   char + char
   char * char or int
   char / char or int
   -char
   char << char or int

While ops involving logical bitops are possibilities. Anyway any 
operations are possible by casting char to and from int. Having a 
distinct char type is just an opportunity for detecting more errors in a 
program.

However not only has C chosen to conflate char types and byte types, but 
it allows char types to be negative! And in a bad way when there are 
only 8 bits and some pre-Unicode characters had values from 128 to 255.

(A signed character type is not so bad when the range is wide enough 
that no actual character values need to be negative.)

-- 
bart

[toc] | [prev] | [next] | [standalone]

#126334

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2018-02-06 14:42 +0000
Message-ID	<87po5ikwmg.fsf@bsb.me.uk>
In reply to	#126328

Richard Damon <Richard@Damon-Family.org> writes:

> On 2/6/18 6:17 AM, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> <snip>
>>> The alternative would be for it not to be an integer type at all - and
>>> require explicit functions for conversion back and forth with integers.
>>>   That is what other languages do.
>>>
>>> In my "perfect language", there would be a "character" type that holds a
>>> single 8-bit value covering ASCII and UTF-8 code points.
>>
>> This looks a but messed up.  The bytes that make up a multi-byte
>> encoding like UTF-8 have no meaning at all except as numbers (well, bit
>> patters as much numbers but it the same thing for most languages).  Of
>> all the operations you decide to permit on this 8-bit character type,
>> only the conversions to and from integers are useful for individual
>> UTF-8 bytes, and they are needed every time for every use of the byte!
>>
>> A character type should represent characters, with some set of relevant
>> operations depending on the design, and UTF-8 sequences should be
>> represented as byte sequences with numeric values.
>>
>> <snip>
>>
>
> WHile individual code points may not be that useful, most of the
> program is probably dealing with them as strings, with pointers and
> indexes into arrays of them. For most code we don't need 'arithmetic'
> on the code point, just basic movement and comparisons.

Just to be clear (I wasn't) by "byte sequences with numeric values" I
meant byte sequences where the bytes can be treated simply as numbers.

> There will need to be some low level functions that takes these
> strings and perform some basic operations to get real characters (full
> 21+ bit values)) out of them, and those routines will need the
> conversion, but making it explicit wouldn't make that code that ugly.

Sure.  I'm not sure how what you are saying relates to what I'm saying.
I think you agreeing that an 8-bit object, on which you can't do
arithmetic, but that holds only part of a UTF-8 encoding is not very
useful.  Agreement being so rare on Usenet am not 100% sure!

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#126342

From	Keith Thompson <kst-u@mib.org>
Date	2018-02-06 12:35 -0800
Message-ID	<lnh8qt26wl.fsf@kst-u.example.com>
In reply to	#126324

David Brown <david.brown@hesbynett.no> writes:
> On 05/02/18 18:01, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> The whole concept of a "char" being signed or unsigned is more than a
>>> little odd to me - it is, I think, a historical accident.
>> [...]
>> 
>> What would be the alternative?  If char is an integer type it has to be
>> either signed or unsigned (unless you say that operations where it
>> matters have undefined behavior).
>
> The alternative would be for it not to be an integer type at all - and
> require explicit functions for conversion back and forth with integers.
>  That is what other languages do.

For example, in Pascal "Char" is a distinct type.  In Ada "Character" is
an enumeration type (Ada allows character constants like 'x' as
enumerators).  In both languages, conversions between characters and
integers are possible, but are never implicit, and there is no
arithmetic on characters (though comparisons like ('0' < '1') are
allowed).

I tend to agree that conflating characters, bytes, and narrow integers
was a bad idea, but C is quite thoroughly stuck with that decision.

[...]

-- 
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]

#126349

From	David Brown <david.brown@hesbynett.no>
Date	2018-02-06 23:04 +0100
Message-ID	<p5d8pp$6m3$2@dont-email.me>
In reply to	#126342

On 06/02/18 21:35, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 05/02/18 18:01, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>> [...]
>>>> The whole concept of a "char" being signed or unsigned is more than a
>>>> little odd to me - it is, I think, a historical accident.
>>> [...]
>>>
>>> What would be the alternative?  If char is an integer type it has to be
>>> either signed or unsigned (unless you say that operations where it
>>> matters have undefined behavior).
>>
>> The alternative would be for it not to be an integer type at all - and
>> require explicit functions for conversion back and forth with integers.
>>   That is what other languages do.
> 
> For example, in Pascal "Char" is a distinct type.  In Ada "Character" is
> an enumeration type (Ada allows character constants like 'x' as
> enumerators).  In both languages, conversions between characters and
> integers are possible, but are never implicit, and there is no
> arithmetic on characters (though comparisons like ('0' < '1') are
> allowed).
> 
> I tend to agree that conflating characters, bytes, and narrow integers
> was a bad idea, but C is quite thoroughly stuck with that decision.
> 

Agreed (on all points).

[toc] | [prev] | [next] | [standalone]

#126270

From	Richard Damon <Richard@Damon-Family.org>
Date	2018-02-04 17:35 -0500
Message-ID	<TULdC.8235$9%2.1074@fx36.iad>
In reply to	#126266

On 2/4/18 3:17 PM, Bart Smissaert wrote:
>> int sqlite3_CountStringInStringA(const WCHAR *strSearch, const  WCHAR
> *strFind, int nSearch, int nFind);
> 
> I tried that but get errors in compiling in MSVS 2012:
> 
> Error	1	error C2143: syntax error : missing ')' before '*'	C:\SQLite\311\sqlite3.c	3199	1	SQLite3_StdCall
> 
> Line 3199 is:
> 
> SQLITE_API sqlite3_CountStringInStringA(const WCHAR *strSearch, const WCHAR *strFind, int nSearch, int nFind);
> 
> And I also get:
> 
> Error	7	error C2371: 'WCHAR' : redefinition; different basic types	C:\Program Files (x86)\Windows Kits\8.1\Include\um\winnt.h	394	1	SQLite3_StdCall
> 
> Note that I am compiling sqlite3.c from the latest Windows download.
> 
> 
> RBS
> 

Something is strange here.

sqlite3.c would be the sqlite amalgamation. The latest version of that 
is 3.22 (not 3.11)

This file has no line anything like this (and I wouldn't expect it to)

sqlite is mostly platform agnostic, there is no 'windows' version of it 
(though there are some conditional compiles to handle platform 
differences), so its core files would not have anything this 
specifically windows to deal with special windows strings.

Your statement also has a basic syntax error, in that it doesn't provide 
the return type of the function being declared.

The error sounds like for some reason that windows.h hasn't been include 
at this point, unless the other errors are causing parsing errors.

[toc] | [prev] | [next] | [standalone]

#126272

From	Bart Smissaert <bart.smissaert@gmail.com>
Date	2018-02-04 14:38 -0800
Message-ID	<c23c0e71-c3dd-48f0-96a7-33478ac9be44@googlegroups.com>
In reply to	#126270

> This file has no line anything like this

What line are you referring to?
I am compiling the 3.22.0 Windows amalgation and I have added some code, so maybe that is one of my lines then you are referring to.

RBS

[toc] | [prev] | [next] | [standalone]

#126275

From	Richard Damon <Richard@Damon-Family.org>
Date	2018-02-04 17:57 -0500
Message-ID	<LdMdC.34871$m03.8854@fx38.iad>
In reply to	#126272

On 2/4/18 5:38 PM, Bart Smissaert wrote:
>> This file has no line anything like this
> 
> What line are you referring to?
> I am compiling the 3.22.0 Windows amalgation and I have added some code, so maybe that is one of my lines then you are referring to.
> 
> RBS
> 

Why are you editing the base sqlite file? Normally you extend library 
functionality by wrapping functions and adding code elsewhere.

Directly modifying library code is generally considered the domain for 
people with a degree of expertise which some of your initial question 
makes me think you may not have.

Afterall, what are you going to do when the next version of sqlite comes 
out to fix bugs and add features. If you have changes tangled up in it, 
it becomes a LOT of work to perform the update.

[toc] | [prev] | [next] | [standalone]

#126278

From	Bart Smissaert <bart.smissaert@gmail.com>
Date	2018-02-04 15:22 -0800
Message-ID	<7c58fd38-efa0-4948-b112-9af1b599e76a@googlegroups.com>
In reply to	#126275

> Normally you extend library 
functionality by wrapping functions and adding code elsewhere.

Yes, I understand that and that will be the next thing.
These are just experiments. Not sure yet what the best way is to add
other functionality outside the amalgation.

RBS

[toc] | [prev] | [next] | [standalone]

#126267

From	Bart Smissaert <bart.smissaert@gmail.com>
Date	2018-02-04 12:19 -0800
Message-ID	<1073ecd2-3a13-4995-905a-bcaf4e3807c4@googlegroups.com>
In reply to	#126265

> I also just noticed that your function name ends in A

This A stands for ANSI, I can see that his might be confusing naming.

RBS

[toc] | [prev] | [next] | [standalone]

#126268

From	Richard Damon <Richard@Damon-Family.org>
Date	2018-02-04 16:42 -0500
Message-ID	<K6LdC.4151$YR7.3386@fx34.iad>
In reply to	#126267

On 2/4/18 3:19 PM, Bart Smissaert wrote:
>> I also just noticed that your function name ends in A
> 
> This A stands for ANSI, I can see that his might be confusing naming.
> 
> RBS
> 

A may have been ANSI, not ASCII, but the A version of things like 
MessageBox take 8 ANSI strings, i.e. 8 bit characters, while the W 
version takes Wide strings (16 bit characters)

[toc] | [prev] | [next] | [standalone]

#126240

From	Keith Thompson <kst-u@mib.org>
Date	2018-02-03 13:38 -0800
Message-ID	<lno9l54uug.fsf@kst-u.example.com>
In reply to	#126230

Richard Damon <Richard@Damon-Family.org> writes:
[...]
> I personally would generally convert a string storing UTF-16/UCS-2 data 
> into an array of uint16_t if at all possible, just because it is closer 
> to what is really going on (or maybe wchar if I knew it was the right 
> size). This isn't always possible for data coming from outside source.
>
> If these are coming from VB, then they may have actually started like that.

I'd use char16_t, defined in <uchar.h>, if it's available.  (I think it
was introduced in C11, so it might not be).

-- 
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]

#126241

From	Jorgen Grahn <grahn+nntp@snipabacken.se>
Date	2018-02-03 22:03 +0000
Message-ID	<slrnp7ccd0.eu5.grahn+nntp@frailea.sa.invalid>
In reply to	#126205

On Sat, 2018-02-03, Bart Smissaert wrote:

> Have simple function to count the number of occurrences of strFind
> in strSearch:

I like the terms that the Linux man pages for strstr() and friends
better: "needle" and "haystack".

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [standalone]

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

csiph-web

Count string in string with loop increase 2, why is this not faster?

Contents

#126307

#126298

#126302

#126324

#126325

#126328

#126331

#126334

#126342

#126349

#126270

#126272

#126275

#126278

#126267

#126268

#126240

#126241