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