Sorry to resurrect this thread, I've been very absent from D, and am just
now going through all these old posts.
On Wed, 27 Jun 2012 17:41:14 -0400, Timon Gehr wrote:
On 06/27/2012 11:11 PM, Steven Schveighoffer wrote:
No, druntime, and include minimal utf support. We do the same thing wi
My point (and the reason I somehow hijacked this thread) is that
such functionality would be useful for random access over narrow
strings. Currently random access is missing.
Also this approach fits nicely if random access is needed to
Unicode characters, not just code points.
I don't see mu
On Thursday, 28 June 2012 at 14:34:03 UTC, Andrei Alexandrescu
wrote:
Well of course I've exaggerated a bit. My point is that
mentioning "200 ns!!!" sounds to the uninformed ear as good as
"2000 ns" or "20 ns", i.e. "an amount of time so short by human
scale, it must mean fast". You need to com
On 6/28/12 8:57 AM, Roman D. Boiko wrote:
On Thursday, 28 June 2012 at 12:29:14 UTC, Andrei Alexandrescu wrote:
On 6/28/12 5:58 AM, Roman D. Boiko wrote:
Pedantically speaking, sheer timings say nothing without the
appropriate baselines.
Andrei
I used results of benchmarks for two such algori
Timon Gehr , dans le message (digitalmars.D:170884), a écrit :
>> An I would say I am also entitle to say strings are not normal
>> ranges, since they define length, but have isLength as true,
>
> hasLength as false.
Of course, my mistake.
> They define length, but it is not part of the range int
Timings should not be very different from random access in any
UTF-32 string implementation, because of design of these
algorithms:
* only operations on 64-bit aligned words are performed
(addition, multiplication, bitwise and shift operations)
* there is no branching except at the very top
On 06/28/2012 11:28 AM, Christophe Travert wrote:
Jonathan M Davis , dans le message (digitalmars.D:170872), a écrit :
On Thursday, June 28, 2012 08:05:19 Christophe Travert wrote:
"Jonathan M Davis" , dans le message (digitalmars.D:170852), a écrit :
completely consistent with regards to how
On Thursday, 28 June 2012 at 12:29:14 UTC, Andrei Alexandrescu
wrote:
On 6/28/12 5:58 AM, Roman D. Boiko wrote:
Pedantically speaking, sheer timings say nothing without the
appropriate baselines.
Andrei
I used results of benchmarks for two such algorithms, which I
like most, taken from here
On 6/28/12 5:28 AM, Christophe Travert wrote:
As a more general comment, I think having a consistent langage is a very
important goal to achieve when designing a langage. It makes everything
simpler, from langage design to user through compiler and library
development. It may not be too late for
On 6/28/12 5:58 AM, Roman D. Boiko wrote:
Pedantically speaking, it is possible to index a string with about
50-51% memory overhead to get random access in 0(1) time.
Best-performing algorithms can do random access in about 35-50
nanoseconds per operation for strings up to tens of megabytes. For
On Thursday, 28 June 2012 at 09:58:02 UTC, Roman D. Boiko wrote:
Pedantically speaking, it is possible to index a string with
about 50-51% memory overhead to get random access in 0(1) time.
Best-performing algorithms can do random access in about 35-50
nanoseconds per operation for strings up t
"David Nadlinger" , dans le message (digitalmars.D:170875), a écrit :
> On Thursday, 28 June 2012 at 09:49:19 UTC, Jonathan M Davis wrote:
>>> char[] is not treated as an array by the library, and is not
>>> treated as a RandomAccessRange. That is a second
>>> inconsistency, and it would be avoid
On Thursday, 28 June 2012 at 10:02:59 UTC, Roman D. Boiko wrote:
On Thursday, 28 June 2012 at 09:58:02 UTC, Roman D. Boiko wrote:
Pedantically speaking, it is possible to index a string with
about 50-51% memory overhead to get random access in 0(1)
time. Best-performing algorithms can do random
On Thursday, 28 June 2012 at 09:58:02 UTC, Roman D. Boiko wrote:
Pedantically speaking, it is possible to index a string with
about 50-51% memory overhead to get random access in 0(1) time.
Best-performing algorithms can do random access in about 35-50
nanoseconds per operation for strings up t
On Thursday, 28 June 2012 at 05:10:43 UTC, Jonathan M Davis wrote:
On Thursday, June 28, 2012 08:59:32 Gor Gyolchanyan wrote:
Currently strings below dstring are only applicable in
ForwardRange
and below, but not RandomAccessRange as they should be.
Except that they shouldn't be, because you
On Thursday, 28 June 2012 at 09:49:19 UTC, Jonathan M Davis wrote:
char[] is not treated as an array by the library, and is not
treated as a RandomAccessRange. That is a second
inconsistency, and it would be avoided is string were a struct.
So, it looked to me like you were saying that making
On Thursday, June 28, 2012 09:28:52 Christophe Travert wrote:
> I never said strings should support length and slicing. I even said
> they should not. foreach is inconsistent with the way strings are
> treated in phobos, but opIndex, opSlice and length, are inconsistent to.
> string[0] and string.f
Jonathan M Davis , dans le message (digitalmars.D:170872), a écrit :
> On Thursday, June 28, 2012 08:05:19 Christophe Travert wrote:
>> "Jonathan M Davis" , dans le message (digitalmars.D:170852), a écrit :
>> > completely consistent with regards to how it treats strings. The _only_
>> > inconsinte
On Thursday, June 28, 2012 08:05:19 Christophe Travert wrote:
> "Jonathan M Davis" , dans le message (digitalmars.D:170852), a écrit :
> > completely consistent with regards to how it treats strings. The _only_
> > inconsintencies are between the language and the library - namely how
> > foreach it
"Jonathan M Davis" , dans le message (digitalmars.D:170852), a écrit :
> completely consistent with regards to how it treats strings. The _only_
> inconsintencies are between the language and the library - namely how foreach
> iterates on code units by default and the fact that while the language
On Thursday, June 28, 2012 08:59:32 Gor Gyolchanyan wrote:
> On Thu, Jun 28, 2012 at 12:22 AM, Steven Schveighoffer
>
> wrote:
> > On Wed, 27 Jun 2012 15:20:26 -0400, Timon Gehr wrote:
> >> There is no reason for anyone to be confused about this endlessly. It
> >> is simple to understand. Furthe
On Thu, Jun 28, 2012 at 12:22 AM, Steven Schveighoffer
wrote:
> On Wed, 27 Jun 2012 15:20:26 -0400, Timon Gehr wrote:
>
>> There is no reason for anyone to be confused about this endlessly. It
>> is simple to understand. Furthermore, think about the implications of a
>> library-defined string typ
On Wednesday, June 27, 2012 23:41:14 Timon Gehr wrote:
> On 06/27/2012 11:11 PM, Steven Schveighoffer wrote:
> > When most string functions take strings, why would you want to use
> > immutable(char)[] everywhere?
>
> Because the proposed 'string' interface is inconvenient to use and
> useless. It
On 06/27/2012 11:11 PM, Steven Schveighoffer wrote:
On Wed, 27 Jun 2012 16:55:49 -0400, Timon Gehr wrote:
On 06/27/2012 10:22 PM, Steven Schveighoffer wrote:
On Wed, 27 Jun 2012 15:20:26 -0400, Timon Gehr
wrote:
There is no reason for anyone to be confused about this endlessly. It
is simpl
On Wednesday, June 27, 2012 17:11:56 Steven Schveighoffer wrote:
> On Wed, 27 Jun 2012 16:55:49 -0400, Timon Gehr wrote:
> > On 06/27/2012 10:22 PM, Steven Schveighoffer wrote:
> >> On Wed, 27 Jun 2012 15:20:26 -0400, Timon Gehr
> >>
> >> wrote:
> >>> There is no reason for anyone to be confused
On Wed, 27 Jun 2012 16:55:49 -0400, Timon Gehr wrote:
On 06/27/2012 10:22 PM, Steven Schveighoffer wrote:
On Wed, 27 Jun 2012 15:20:26 -0400, Timon Gehr
wrote:
There is no reason for anyone to be confused about this endlessly. It
is simple to understand. Furthermore, think about the impli
On Wednesday, June 27, 2012 22:54:28 Gor Gyolchanyan wrote:
> On Wed, Jun 27, 2012 at 10:42 PM, Jonathan M Davis
wrote:
> > On Wednesday, June 27, 2012 22:29:25 Gor Gyolchanyan wrote:
> >> Agreed. Having struct strings (with slices and everything) will set
> >> the record straight.
> >
> > Excep
On 06/27/2012 10:22 PM, Steven Schveighoffer wrote:
On Wed, 27 Jun 2012 15:20:26 -0400, Timon Gehr wrote:
There is no reason for anyone to be confused about this endlessly. It
is simple to understand. Furthermore, think about the implications of a
library-defined string type: it just introduce
On Wed, 27 Jun 2012 15:20:26 -0400, Timon Gehr wrote:
There is no reason for anyone to be confused about this endlessly. It
is simple to understand. Furthermore, think about the implications of a
library-defined string type: it just introduces the problem of what the
type of built-in string lit
On 06/27/2012 08:54 PM, Gor Gyolchanyan wrote:
On Wed, Jun 27, 2012 at 10:42 PM, Jonathan M Davis wrote:
On Wednesday, June 27, 2012 22:29:25 Gor Gyolchanyan wrote:
Agreed. Having struct strings (with slices and everything) will set
the record straight.
Except that they couldn't have slicing
On 06/27/2012 08:09 PM, Steven Schveighoffer wrote:
On Wed, 27 Jun 2012 13:30:48 -0400, Jonathan M Davis
wrote:
I don't see why having the literal be a string would make anything
confusing.
The fact that a string is considered a range of dchar rather than char
could
be, but I don't see why ha
On Wed, Jun 27, 2012 at 10:42 PM, Jonathan M Davis wrote:
> On Wednesday, June 27, 2012 22:29:25 Gor Gyolchanyan wrote:
>> Agreed. Having struct strings (with slices and everything) will set
>> the record straight.
>
> Except that they couldn't have slicing, because it would be very inefficient.
>
On Wednesday, June 27, 2012 22:29:25 Gor Gyolchanyan wrote:
> Agreed. Having struct strings (with slices and everything) will set
> the record straight.
Except that they couldn't have slicing, because it would be very inefficient.
You'd have to get at the actual array of code units to slice anyth
On Wed, Jun 27, 2012 at 10:09 PM, Steven Schveighoffer
wrote:
> On Wed, 27 Jun 2012 13:30:48 -0400, Jonathan M Davis
> wrote:
>
>
>> I don't see why having the literal be a string would make anything
>> confusing.
>> The fact that a string is considered a range of dchar rather than char
>> could
On Wed, 27 Jun 2012 13:30:48 -0400, Jonathan M Davis
wrote:
I don't see why having the literal be a string would make anything
confusing.
The fact that a string is considered a range of dchar rather than char
could
be, but I don't see why having a string literal be a dstring instead of a
On Wednesday, June 27, 2012 19:54:12 Gor Gyolchanyan wrote:
> On Wed, Jun 27, 2012 at 7:49 PM, Jonathan M Davis
wrote:
> > On Wednesday, June 27, 2012 19:47:41 Gor Gyolchanyan wrote:
> > > On Wed, Jun 27, 2012 at 7:41 PM, Jonathan M Davis
> >
> > wrote:
> > > > On Wednesday, June 27, 2012 17:58:4
On 06/27/2012 05:54 PM, Gor Gyolchanyan wrote:
On Wed, Jun 27, 2012 at 7:49 PM, Jonathan M Davis mailto:jmdavisp...@gmx.com>> wrote:
_All_ strings are considered to be ranges of dchar. That's why
string and
wstring are not random access ranges and hasLength is false for them.
-
On Wed, Jun 27, 2012 at 7:49 PM, Jonathan M Davis wrote:
> On Wednesday, June 27, 2012 19:47:41 Gor Gyolchanyan wrote:
> > On Wed, Jun 27, 2012 at 7:41 PM, Jonathan M Davis
> wrote:
> > > On Wednesday, June 27, 2012 17:58:46 Gor Gyolchanyan wrote:
> > > > I tested it out and the string literal wit
On Wednesday, June 27, 2012 19:47:41 Gor Gyolchanyan wrote:
> On Wed, Jun 27, 2012 at 7:41 PM, Jonathan M Davis
wrote:
> > On Wednesday, June 27, 2012 17:58:46 Gor Gyolchanyan wrote:
> > > I tested it out and the string literal without qualifiers counts as a
> > > dstring.
> >
> > That depends en
On Wed, Jun 27, 2012 at 7:41 PM, Jonathan M Davis wrote:
> On Wednesday, June 27, 2012 17:58:46 Gor Gyolchanyan wrote:
> > I tested it out and the string literal without qualifiers counts as a
> > dstring.
>
> That depends entirely on what you assign it to.
> writeln(typeof("hello").stringof) prin
On Wednesday, June 27, 2012 17:58:46 Gor Gyolchanyan wrote:
> I tested it out and the string literal without qualifiers counts as a
> dstring.
That depends entirely on what you assign it to.
writeln(typeof("hello").stringof) prints string, not dstring. So, the literal
by itself is a string by de
On Wed, Jun 27, 2012 at 5:38 PM, Timon Gehr wrote:
> On 06/27/2012 03:25 PM, Gor Gyolchanyan wrote:
>
>> Are there functions, which wrap arbitrary range types into standard
>> range interfaces?
>> I looked at the docs, but couldn't find anything.
>> Use case:
>>
>> RandomAccessRange!dchar s = ???
On 06/27/2012 03:25 PM, Gor Gyolchanyan wrote:
Are there functions, which wrap arbitrary range types into standard
range interfaces?
I looked at the docs, but couldn't find anything.
Use case:
RandomAccessRange!dchar s = ???("Hello, world!");
--
Bye,
Gor Gyolchanyan.
A narrow string is not a
Are there functions, which wrap arbitrary range types into standard range
interfaces?
I looked at the docs, but couldn't find anything.
Use case:
RandomAccessRange!dchar s = ???("Hello, world!");
--
Bye,
Gor Gyolchanyan.
44 matches
Mail list logo
