www.digitalmars.com         C & C++   DMDScript  

D - Phobos returned strings

reply Vathix <vathix dprogramming.com> writes:
Most of the functions in phobos that return strings automatically new 
the string returned. While it makes most things easier, it makes it 
harder to use phobos to build a string in your own buffer.
For example, say I want to read a file but I also want to put 
parentheses around its data. So I use "(" ~ std.file.read("foo.txt") ~ 
")". How many cycles did I just waste? If I could specify a destination 
buffer, I could get the file size, add 2, and avoid copying the file 
data twice. Here's the code:

uint size = getSize("foo.txt");
char[] str = new char[size + 2];
str[0] = '(';
str[str.length - 1] = ');
std.file.read("foo.txt", str[1 .. str.length - 1]);

Exactly what I am proposing:
Functions that return string data have an overloaded extra parameter for 
the destination buffer. (I know this isn't possible in all cases, but it 
is in most.) It would be up to the caller to supply a large enough 
buffer, and the filled portion slice would be returned. The convention 
has been to put the destination parameter first, as in memcpy(dest, src) 
but I don't think it should be in this case, because it's just an 
optional extra parameter. A good working example of this is in std.base64.

If votes are for this, I'm willing to go through phobos and implement it 
wherever I can, and give the origional authors full credit.


A bit off topic, what does everyone think of adding
alias char[] string;
to std.string? There are no name conflicts and I think it will appeal to 
more users (I think it looks nicer). The lowercase s indicates that it's 
a primitive value type (value that holds a reference to the string data) 
as opposed to a class object reference. This isn't a big deal, just 
thought I'd mention it. I've already noticed people doing it, hope it 
doesn't turn into the C bool thing ;)


-- 
Christopher E. Miller
Apr 06 2004
next sibling parent "Ben Hinkle" <bhinkle4 juno.com> writes:
 Exactly what I am proposing:
 Functions that return string data have an overloaded extra parameter for
 the destination buffer. (I know this isn't possible in all cases, but it
 is in most.) It would be up to the caller to supply a large enough
 buffer, and the filled portion slice would be returned. The convention
 has been to put the destination parameter first, as in memcpy(dest, src)
 but I don't think it should be in this case, because it's just an
 optional extra parameter. A good working example of this is in std.base64.

 If votes are for this, I'm willing to go through phobos and implement it
 wherever I can, and give the origional authors full credit.

I agree this is generally needed. My updates to std.stream include the overloaded function void readLine(inout char[] result) as well as the existing char[] readLine() The speedup from doing this was somewhere around 10% I think. There are probably other functions in there that should also get an overloaded input buffer. Note when implementing something that takes a buffer don't set the length to 0 unless you absolutely have to becuase setting the legnth to 0 throws away the data pointer (see my earlier posts about reserving array space and length 0) -Ben
Apr 06 2004
prev sibling parent C <dont respond.com> writes:
 A bit off topic, what does everyone think of adding
 alias char[] string;
 to std.string?

I usually do this myself, but only because at some point I might want to= = change char [] , to wchar [] or dchar [] , so I'd say leave it up to the= = user. Or maybe do a version for unicode , change string to d/w char = instead.
 How many cycles did I just waste? If I could specify a destination =

 buffer, I could get the file size, add 2, and avoid copying the file =

 data twice.

How much faster would this be ? I know MSVC has an optimiazation where MyClass x =3D Function(); doesn't actually copy the MyClass, just uses the local address of the = variable for its creation. If we get a choice I would vote to optimize = the return by values before offering a pass by refernce addition to all = functions in std. Just my 2 pents, C On Tue, 06 Apr 2004 09:42:20 -0400, Vathix <vathix dprogramming.com> wro= te:
 Most of the functions in phobos that return strings automatically new =

 the string returned. While it makes most things easier, it makes it =

 harder to use phobos to build a string in your own buffer.
 For example, say I want to read a file but I also want to put =

 parentheses around its data. So I use "(" ~ std.file.read("foo.txt") ~=

 ")". How many cycles did I just waste? If I could specify a destinatio=

 buffer, I could get the file size, add 2, and avoid copying the file =

 data twice. Here's the code:

 uint size =3D getSize("foo.txt");
 char[] str =3D new char[size + 2];
 str[0] =3D '(';
 str[str.length - 1] =3D ');
 std.file.read("foo.txt", str[1 .. str.length - 1]);

 Exactly what I am proposing:
 Functions that return string data have an overloaded extra parameter f=

 the destination buffer. (I know this isn't possible in all cases, but =

 is in most.) It would be up to the caller to supply a large enough =

 buffer, and the filled portion slice would be returned. The convention=

 has been to put the destination parameter first, as in memcpy(dest, sr=

 but I don't think it should be in this case, because it's just an =

 optional extra parameter. A good working example of this is in =

 std.base64.

 If votes are for this, I'm willing to go through phobos and implement =

 wherever I can, and give the origional authors full credit.


 A bit off topic, what does everyone think of adding
 alias char[] string;
 to std.string? There are no name conflicts and I think it will appeal =

 more users (I think it looks nicer). The lowercase s indicates that it=

 a primitive value type (value that holds a reference to the string dat=

 as opposed to a class object reference. This isn't a big deal, just =

 thought I'd mention it. I've already noticed people doing it, hope it =

 doesn't turn into the C bool thing ;)

-- = D Newsgroup.
Apr 06 2004