www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Best way to make Until! into string

reply Jonathan M Davis <jmdavisProg gmail.com> writes:
Okay. If you call until like so

str.until('\"')

you get a Until!(pred,string,char). I want to turn that into a string. 
array() doesn't seem to do the trick right now. It used to work, but now it 
gives me

main.d(47): Error: template std.array.array(Range) if (isForwardRange!
(Range)) does not match any function template declaration
main.d(47): Error: template std.array.array(Range) if (isForwardRange!
(Range)) cannot deduce template function from argument types !()(Until!
(pred,string,char))

to!string just converts it into a string with the Until! stuff being 
included in the string rather than giving me the actual result, so that 
doesn't work.

So, what is the correct and preferred way to convert the result of Until! to 
as string when you were searching on a string in the first place? The 
std.algorithm functions are definitely nice, but they have tendancy to 
return hard-to-use types.

- Jonathan M Davis
Jun 21 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
Jonathan M Davis wrote:

 Okay. If you call until like so
 
 str.until('\"')
 
 you get a Until!(pred,string,char). I want to turn that into a string.
 array() doesn't seem to do the trick right now. It used to work, but now
 it gives me
 
 main.d(47): Error: template std.array.array(Range) if (isForwardRange!
 (Range)) does not match any function template declaration
 main.d(47): Error: template std.array.array(Range) if (isForwardRange!
 (Range)) cannot deduce template function from argument types !()(Until!
 (pred,string,char))
 
 to!string just converts it into a string with the Until! stuff being
 included in the string rather than giving me the actual result, so that
 doesn't work.
 
 So, what is the correct and preferred way to convert the result of Until!
 to as string when you were searching on a string in the first place? The
 std.algorithm functions are definitely nice, but they have tendancy to
 return hard-to-use types.
 
 - Jonathan M Davis
I should say that array() used to work if you used to!string on the result, but in either case, it won't compile for me now with DMD 2.047 (it did with DMD 2.046) if I feed the result of until() to array(). Maybe it's a bug, or maybe I've just been doing the conversion in the wrong way in the first place, but I don't know how to do it now. - Jonathan M Davis
Jun 21 2010
parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Tue, Jun 22, 2010 at 08:38, Jonathan M Davis <jmdavisProg gmail.com>wrote:

 Jonathan M Davis wrote:

 Okay. If you call until like so

 str.until('\"')

 you get a Until!(pred,string,char). I want to turn that into a string.
 array() doesn't seem to do the trick right now. It used to work, but now
 it gives me

 main.d(47): Error: template std.array.array(Range) if (isForwardRange!
 (Range)) does not match any function template declaration
 main.d(47): Error: template std.array.array(Range) if (isForwardRange!
 (Range)) cannot deduce template function from argument types !()(Until!
 (pred,string,char))
I should say that array() used to work if you used to!string on the
result, but in either case, it won't compile for me now with DMD 2.047 (it did with DMD 2.046) if I feed the result of until() to array(). Maybe it's a bug, or maybe I've just been doing the conversion in the wrong way in the first place, but I don't know how to do it now.
I got this error also while installing 2.047. I think the new definition of a forward range asks for a .save() member. And I guess some ranges where not converted. std.range.repeat is one, like cycle. It seems like Until is another. Maybe for repeat/cycle that was a conscious decision? I'll file a bug anyway. http://d.puremagic.com/issues/show_bug.cgi?id=4362 http://d.puremagic.com/issues/show_bug.cgi?id=4363 Philippe
Jun 22 2010
parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Philippe Sigaud wrote:

 I got this error also while installing 2.047. I think the new definition
 of a forward range asks for a .save() member. And I guess some ranges
 where not converted. std.range.repeat is one, like cycle. It seems like
 Until is another.
 
 Maybe for repeat/cycle that was a conscious decision? I'll file a bug
 anyway.
 
 http://d.puremagic.com/issues/show_bug.cgi?id=4362
 http://d.puremagic.com/issues/show_bug.cgi?id=4363
 
 Philippe
I guess that would be one downside for things like forward range not being interfaces. I guess that that means that when you intend a particular range struct or class to be a particular type of range or ranges that you should probably include unittests to verify that they are. Well, as Andrei said in TDPL, too many unittests is almost enough. In any case, it was hard enough figuring out how to make the result of until() useable in the first place. It's good to know that my solution of using array() is almost certainly still supposed to work. It may be something that I'll have to patch in my local phobos if I want my current program to be of much use... Thanks for the help. - Jonathan M Davis
Jun 22 2010
prev sibling parent reply div0 <div0 users.sourceforge.net> writes:
On 22/06/2010 07:29, Jonathan M Davis wrote:
 Okay. If you call until like so

 str.until('\"')

 you get a Until!(pred,string,char). I want to turn that into a string.
 array() doesn't seem to do the trick right now. It used to work, but now it
 gives me

 main.d(47): Error: template std.array.array(Range) if (isForwardRange!
 (Range)) does not match any function template declaration
 main.d(47): Error: template std.array.array(Range) if (isForwardRange!
 (Range)) cannot deduce template function from argument types !()(Until!
 (pred,string,char))

 to!string just converts it into a string with the Until! stuff being
 included in the string rather than giving me the actual result, so that
 doesn't work.

 So, what is the correct and preferred way to convert the result of Until! to
 as string when you were searching on a string in the first place? The
 std.algorithm functions are definitely nice, but they have tendancy to
 return hard-to-use types.

 - Jonathan M Davis
Could be wrong, but strings aren't (conceptually) arrays any more. They are bidirectional ranges which is why the array call doesn't work. Though how you actually get a string back I don't know. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Jun 22 2010
parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
div0 wrote:

 On 22/06/2010 07:29, Jonathan M Davis wrote:
 Okay. If you call until like so

 str.until('\"')

 you get a Until!(pred,string,char). I want to turn that into a string.
 array() doesn't seem to do the trick right now. It used to work, but now
 it gives me

 main.d(47): Error: template std.array.array(Range) if (isForwardRange!
 (Range)) does not match any function template declaration
 main.d(47): Error: template std.array.array(Range) if (isForwardRange!
 (Range)) cannot deduce template function from argument types !()(Until!
 (pred,string,char))

 to!string just converts it into a string with the Until! stuff being
 included in the string rather than giving me the actual result, so that
 doesn't work.

 So, what is the correct and preferred way to convert the result of Until!
 to as string when you were searching on a string in the first place? The
 std.algorithm functions are definitely nice, but they have tendancy to
 return hard-to-use types.

 - Jonathan M Davis
Could be wrong, but strings aren't (conceptually) arrays any more.
As I understand it, they're definitely arrays. It's just that they because they're arrays of char (well immutable(char)) but are read as unicode code points, the type of the array isn't necessarily a full character and code that needs to read code points has to treat them as a range of code points rather than an array of char. So, whether you treat them as an array depends a bit on what you're doing with them. As long as you're not actually trying to intrepret them as code points, however, they're the same as any other array.
 
 They are bidirectional ranges which is why the array call doesn't work.
 Though how you actually get a string back I don't know.
 
I wasn't clear enough. I was basically doing this: to!string(array(str.until('\"'))); As I understand it, that forces the Until type into an array of whatever type (probably char[]) and then to!string would convert it to immutable(char)[]. It's the cleanest way that I found (well, actually, the only way I think) to convert the result of until() to string in spite of the fact that it was called with a string in the first place. It's one of the prices of flexibility, I guess. - Jonathan M Davis
Jun 22 2010
parent reply div0 <div0 users.sourceforge.net> writes:
On 22/06/2010 19:26, Jonathan M Davis wrote:
 div0 wrote:

 On 22/06/2010 07:29, Jonathan M Davis wrote:
 Okay. If you call until like so

 str.until('\"')

 you get a Until!(pred,string,char). I want to turn that into a string.
 array() doesn't seem to do the trick right now. It used to work, but now
 it gives me

 main.d(47): Error: template std.array.array(Range) if (isForwardRange!
 (Range)) does not match any function template declaration
 main.d(47): Error: template std.array.array(Range) if (isForwardRange!
 (Range)) cannot deduce template function from argument types !()(Until!
 (pred,string,char))

 to!string just converts it into a string with the Until! stuff being
 included in the string rather than giving me the actual result, so that
 doesn't work.

 So, what is the correct and preferred way to convert the result of Until!
 to as string when you were searching on a string in the first place? The
 std.algorithm functions are definitely nice, but they have tendancy to
 return hard-to-use types.

 - Jonathan M Davis
Could be wrong, but strings aren't (conceptually) arrays any more.
As I understand it, they're definitely arrays. It's just that they because they're arrays of char (well immutable(char)) but are read as unicode code points, the type of the array isn't necessarily a full character and code that needs to read code points has to treat them as a range of code points rather than an array of char. So, whether you treat them as an array depends a bit on what you're doing with them. As long as you're not actually trying to intrepret them as code points, however, they're the same as any other array.
I think we're talking about the same thing but with slightly different terminology. As far as I understand it, for a string (I'm specifically talking immutable(char)) each byte is not a 'code point' or a character. It may take multiple bytes to encode a 'code point' and it can take multiple code points to encode a character. (Or maybe it's just 2 code points at most, I'm not clear on the details of combining characters) So it's never valid to randomly access the bytes in a utf-8 string. If you take a random byte out of string, you might be getting only one byte out a multi byte encoded 'code point'. (I have the vague recollection that each byte of an encoded 'code point' is itself clearly defined to be an invalid utf 'code point' so you can't accidentally go using one) Which is bad and therefore you should never conceptually treat a string as an array. (To me array implies random access and that's you are going to be doing such). When you have an encoded 'code point' in a utf-8 string you have to start mucking about with bit shifting I believe to decode it. Of course strings are arrays, but I think this is just an implementation detail and might be/probably should be changed in future. Andrei was quite emphatic in one of his posts that strings would from now on be bidirectional ranges. If you decode a string to dstring then you have a list of code points. I'm not clear on whether randomly accessing a dstring is a good idea or bad idea though. If any of that seems wrong please let me know. I'm a bit hazy on the finer points of utf myself and I don't want to carry on making invalid assumptions about it.
 They are bidirectional ranges which is why the array call doesn't work.
 Though how you actually get a string back I don't know.
I wasn't clear enough. I was basically doing this: to!string(array(str.until('\"'))); As I understand it, that forces the Until type into an array of whatever type (probably char[]) and then to!string would convert it to immutable(char)[]. It's the cleanest way that I found (well, actually, the only way I think) to convert the result of until() to string in spite of the fact that it was called with a string in the first place. It's one of the prices of flexibility, I guess. - Jonathan M Davis
Sry, means nothing to me. I'm still using dmd 2.028. :( -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Jun 22 2010
parent reply Jonathan M Davis <jmdavisProg gmail.com> writes:
div0 wrote:


[... snip of UTF-8 stuff ...]

The UTF char stuff is all painfully complicated, and I _think_ that I more 
or less understand it, but I suspect that I don't understand it all that 
well. It would be nice if the there were a page in the docs somewhere that 
really explained it well.



[... snip of until() stuff ...]
 
 Sry, means nothing to me. I'm still using dmd 2.028. :(
 
Oh my, you caveman! ;) I'd have to go look at all of the changelogs to even have a clue of what's been changed since then. Oh well, I guess that it means that you don't have to worry about stuff changing on you each upgrade by sticking to the same version for a while, and I suppose that there could be a specific bug holding you back. But you're going to have to upgrade eventually. Personally, I usually stick to the latest version or possibly one older if I'm slow getting the new one set up, but to each their own, I suppose. - Jonathan M Davis
Jun 22 2010
next sibling parent reply div0 <div0 users.sourceforge.net> writes:
On 22/06/2010 23:05, Jonathan M Davis wrote:
 Oh my, you caveman! ;) I'd have to go look at all of the changelogs to even
 have a clue of what's been changed since then. Oh well, I guess that it
 means that you don't have to worry about stuff changing on you each upgrade
 by sticking to the same version for a while, and I suppose that there could
 be a specific bug holding you back. But you're going to have to upgrade
 eventually. Personally, I usually stick to the latest version or possibly
 one older if I'm slow getting the new one set up, but to each their own, I
 suppose.

 - Jonathan M Davis
Oh it's not through choice; After 2.028 there was a whole string of releases with compiler bugs I couldn't find work arounds for. Then I got bored of trying for a while, and now with 2.047 I've been bitten by the removal of struct initialisers. CTFE isn't a full replacement for them yet. I could probably rewrite my code to get round it, but I can't really be bothered. I don't really want to spend the time to do that then find out there's another bug/feature that borks compilation. Luckily I don't use much of phobos so once the compiler is sorted it shouldn't take long to update all my code. And who knows by that point I might even have something worth releasing! -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Jun 23 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
div0:
 and now with 2.047 I've been 
 bitten by the removal of struct initialisers.
What do you mean? Bye, bearophile
Jun 23 2010
parent div0 <div0 users.sourceforge.net> writes:
On 23/06/2010 23:14, bearophile wrote:
 div0:
 and now with 2.047 I've been
 bitten by the removal of struct initialisers.
What do you mean? Bye, bearophile
curly brace initialisers: struct c4 { float[4] _vals; } c4 dat = { [0,0,0,0] }; Needs to be changed to use a constructor, but CTFE can't assign to the _vals array at the moment in the constructor. It'll get fixed sooner or later, so I'd rather wait than recode every thing to work around it; only to change it all back when CTFE gets better. And also not using an array makes generalising the number of _vals a huge pain. -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Jun 24 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmail.com> writes:
Jonathan M Davis wrote:

 div0 wrote:
 

[... snip of UTF-8 stuff ...]

 
 The UTF char stuff is all painfully complicated, and I _think_ that I more
 or less understand it, but I suspect that I don't understand it all that
 well. It would be nice if the there were a page in the docs somewhere that
 really explained it well.
 
TPDL has a great section on Unicode and strings. I definitely think that I understand the situation better now. Unicode is a pain to deal with, but D deals with it really well over all. I'm certainly more comfortable dealing with unicode in D than in most languages. - Jonathan M Davis
Jun 23 2010