www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.string and ranges

reply dsimcha <dsimcha yahoo.com> writes:
Is std.string by any chance going to see any ripple effects from ranges?  I
want to write some patches to make it work with CTFE, which would be useful
for some compile time mixin generation, but I don't want to waste time working
on a module that Andrei is going to completely revamp anyway.
Feb 07 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
dsimcha wrote:
 Is std.string by any chance going to see any ripple effects from ranges?  I
 want to write some patches to make it work with CTFE, which would be useful
 for some compile time mixin generation, but I don't want to waste time working
 on a module that Andrei is going to completely revamp anyway.

Yes, std.string must be revamped too. You may want to hold onto your work for a little while more. Andrei
Feb 07 2009
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Andrei Alexandrescu wrote:
 dsimcha wrote:
 Is std.string by any chance going to see any ripple effects from 
 ranges?  I
 want to write some patches to make it work with CTFE, which would be 
 useful
 for some compile time mixin generation, but I don't want to waste time 
 working
 on a module that Andrei is going to completely revamp anyway.

Yes, std.string must be revamped too. You may want to hold onto your work for a little while more.

Then I suppose the next question should be: will a char[] be a range of char, or a range of dchar? (Let's keep wchar out of it) On the one hand, char is the logical option since that's what the array actually contains. Also, this better allows for mutability (since encoding dchars can lead to not having enough space to store replacements in the current position). On the other hand, dchars would probably be more useful in many situations. Maybe an adapter could be written, taking a char[] (or any range of chars/wchars) and acting as a range of dchars? Perhaps also similar adapters to convert to chars and wchars?
Feb 08 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Frits van Bommel wrote:
 Andrei Alexandrescu wrote:
 dsimcha wrote:
 Is std.string by any chance going to see any ripple effects from 
 ranges?  I
 want to write some patches to make it work with CTFE, which would be 
 useful
 for some compile time mixin generation, but I don't want to waste 
 time working
 on a module that Andrei is going to completely revamp anyway.

Yes, std.string must be revamped too. You may want to hold onto your work for a little while more.

Then I suppose the next question should be: will a char[] be a range of char, or a range of dchar? (Let's keep wchar out of it)

Glad you asked. Given type C[] in { char[], wchar[], dchar[] }, here are the ranges that can be used to iterate them: a) byCharacter: a bidirectional range with immutable elements. The element type is always dchar, and the range goes over the full characters in the string. If C == dchar, the range has random access. b) byCharacterWritable: a more expensive bidirectional range that still has element type dchar but holds a reference to the original string such that it can go back and change it. (This is tricky because writing back a dchar into the string may change its length.) The language needs the alias this feature and solid proxy objects to be able to implement this. If C == dchar, the range has random access and fast writes. c) byNaturalWidth: a random-access range that iterates the raw elements.
 On the one hand, char is the logical option since that's what the array 
 actually contains. Also, this better allows for mutability (since 
 encoding dchars can lead to not having enough space to store 
 replacements in the current position).
 
 On the other hand, dchars would probably be more useful in many situations.
 
 Maybe an adapter could be written, taking a char[] (or any range of 
 chars/wchars) and acting as a range of dchars?
 Perhaps also similar adapters to convert to chars and wchars?

Quite so. The important things are (1) only bidirectional, not random, access is affordable when reading one dchar at a time from char[] or wchar[]; (b) proxy objects are important in assuring proper mutability. Andrei
Feb 08 2009