Re: typeof(string.front) should be char
On Friday, March 02, 2012 20:41:35 Ali Çehreli wrote: On 03/02/2012 06:30 PM, Piotr Szturmaj wrote: Hello, For this code: auto c = testc; auto w = testw; auto d = testd; pragma(msg, typeof(c.front)); pragma(msg, typeof(w.front)); pragma(msg, typeof(d.front)); compiler prints: dchar dchar immutable(dchar) IMO it should print this: immutable(char) immutable(wchar) immutable(dchar) Is it a bug? No, that's by design. When used as InputRange ranges, slices of any character type are exposed as ranges of dchar. Indeed. Strings are always treated as ranges of dchar, because it generally makes no sense to operate on individual chars or wchars. A char is a UTF-8 code unit. A wchar is a UTF-16 code unit. And a dchar is a UTF-32 code unit. The _only_ one of those which is guranteed to be a code point is dchar, since in UTF-32, all code points are a single code unit. If you were to operate on individual chars or wchars, you'd be operating on pieces of characters rather than whole characters, which wreaks havoc with unicode. Now, technically speaking, a code point isn't necessarily a full character, since you can also combine code points (e.g. adding a subscript to a letter), and a full character is what's called a grapheme, and unfortunately, at the moment, Phobos doesn't have a way to operate on graphemes, but operating on code points is _far_ more correct than operating on code units. It's also more efficient. Unfortunately, in order to code completely efficiently with unicode, you have understand quite a bit about it, which most programmers don't, but by operating on ranges of code points, Phobos manages to be correct in the majority of cases. So, yes. It's very much on purpose that all strings are treated as ranges of dchar. - Jonathan M Davis
Sending Tid in a struct
Hi,
I'm trying to send structs using std.concurrency. the struct contains
a Tid (the id of the sender) so that the receiver can send an answer.
say:
struct Foo
{
Tid tid;
string str;
}
// ...
Foo f = {
tid: thisTid,
str: hello!
};
std.concurrency.send(someThread, f);
// /usr/include/d/dmd/phobos/std/concurrency.d(465): Error: static
assert Aliases to mutable thread-local data not allowed.
// hello.d(15):instantiated from here: send!(Foo)
However, I can send a Tid if I pass it directly as a parameter of the
send function instead of passing it within a struct.
Is this a bug ? It looks like so to me but I guess I could have missed
something.
thanks in advance,
Nicolas
Re: Evaluating __FILE__ and __LINE__ of caller?
Le samedi 03 mars 2012 à 02:39 +0100, Adam D. Ruppe a écrit :
On Saturday, 3 March 2012 at 01:36:51 UTC, H. S. Teoh wrote:
int opIndex(int x) {
Make that
(int x, string file = __FILE__, int line = __LINE__)
and use file/line in there. The exception consturctors
do this, so you can
throw new Exception(msg, file, line);
and get it passed on.
I think __LINE__ is size_t not int
Re: Dumb question about git
On 2012-03-02 20:30, David Nadlinger wrote: On Friday, 2 March 2012 at 18:10:56 UTC, Jonathan M Davis wrote: Both should work, and the man page is going to be for git-rebase. Pretty much all of the git commands can be used with or without a -. On my system, the dashed commands are not directly accessible, and the man page exclusively uses the non-dashed version except for the page title, where it has to as man page names can't (or at least usually don't), contain spaces. Neither on Mac OS X. As far as I know, the dash commands are considered merely an implementation detail now and shouldn't be used directly, but I don't have an official source on hand. David -- /Jacob Carlborg
Re: typeof(string.front) should be char
On 2012-03-03 03:30, Piotr Szturmaj wrote: Hello, For this code: auto c = testc; auto w = testw; auto d = testd; pragma(msg, typeof(c.front)); pragma(msg, typeof(w.front)); pragma(msg, typeof(d.front)); compiler prints: dchar dchar immutable(dchar) I thought all these would be either dchar or immutable(dchar). Why are they of different types? IMO it should print this: immutable(char) immutable(wchar) immutable(dchar) Is it a bug? -- /Jacob Carlborg
Re: typeof(string.front) should be char
Jonathan M Davis wrote:
On Friday, March 02, 2012 20:41:35 Ali Çehreli wrote:
On 03/02/2012 06:30 PM, Piotr Szturmaj wrote:
Hello,
For this code:
auto c = testc;
auto w = testw;
auto d = testd;
pragma(msg, typeof(c.front));
pragma(msg, typeof(w.front));
pragma(msg, typeof(d.front));
compiler prints:
dchar
dchar
immutable(dchar)
IMO it should print this:
immutable(char)
immutable(wchar)
immutable(dchar)
Is it a bug?
No, that's by design. When used as InputRange ranges, slices of any
character type are exposed as ranges of dchar.
Indeed.
Strings are always treated as ranges of dchar, because it generally makes no
sense to operate on individual chars or wchars. A char is a UTF-8 code unit. A
wchar is a UTF-16 code unit. And a dchar is a UTF-32 code unit. The _only_ one
of those which is guranteed to be a code point is dchar, since in UTF-32, all
code points are a single code unit. If you were to operate on individual chars
or wchars, you'd be operating on pieces of characters rather than whole
characters, which wreaks havoc with unicode.
Now, technically speaking, a code point isn't necessarily a full character,
since you can also combine code points (e.g. adding a subscript to a letter),
and a full character is what's called a grapheme, and unfortunately, at the
moment, Phobos doesn't have a way to operate on graphemes, but operating on
code points is _far_ more correct than operating on code units. It's also more
efficient.
Unfortunately, in order to code completely efficiently with unicode, you have
understand quite a bit about it, which most programmers don't, but by
operating on ranges of code points, Phobos manages to be correct in the
majority of cases.
I know about Unicode, code units/points and their encoding.
So, yes. It's very much on purpose that all strings are treated as ranges of
dchar.
Foreach gives opportunity to handle any string by char, wchar or dchar,
the default dchar is appropriate here, but why for ranges?
I was afraid it is on purpose, because it has some bad consequences. It
breaks genericity when dealing with ranges. Consider a custom range of char:
struct CharRange
{
@property bool empty();
@property char front();
void popFront();
}
typeof(CharRange.front) and ElementType!CharRange both return _char_
while for string they return _dchar_. This discrepancy pushes the range
writer to handle special string cases. I'm currently trying to write
ByDchar range:
template ByDchar(R)
if (isInputRange!R isSomeChar!(ElementType!R))
{
alias ElementType!R E;
static if (is(E == dchar))
alias R ByDchar;
else static if (is(E == char))
{
struct ByDchar
{
...
}
}
else static if (is(E == wchar))
{
...
}
}
The problem with that range is when it takes a string type, it aliases
this type with itself, because ElementType!R yields dchar. This is why
I'm talking about bad consequences, I just want to iterate string by
_char_, not _dchar_.
Re: typeof(string.front) should be char
On 03/03/2012 04:36 AM, Jacob Carlborg wrote: On 2012-03-03 03:30, Piotr Szturmaj wrote: Hello, For this code: auto c = testc; auto w = testw; auto d = testd; pragma(msg, typeof(c.front)); pragma(msg, typeof(w.front)); pragma(msg, typeof(d.front)); compiler prints: dchar dchar immutable(dchar) I thought all these would be either dchar or immutable(dchar). Why are they of different types? In the case of char and wchar slices, the elements are decoded as the iteration happens. In other words, the returned values are not actual elements of the ranges. IMO it should print this: immutable(char) immutable(wchar) immutable(dchar) Is it a bug? Ali
Build error about LockingTextWriter
Dear, i do not understand what is wrong in my code and produce this: - $ ldc2 ../../lib/libdscience-ldc.a -I=../.. fasta.d /usr/include/d/std/range.d(295): Error: static assert Cannot put a Sequence into a LockingTextWriter instantiatied in /usr/include/d/std/format.d(1512): put!(LockingTextWriter,Sequence) instantiatied in /usr/include/d/std/format.d(1869): formatRange!(LockingTextWriter,Sequence,char) instantiatied in /usr/include/d/std/format.d(2232): formatValue!(LockingTextWriter,Sequence,char) ... (1 instantiations, -v to show) ... instantiatied in /usr/include/d/std/stdio.d(684): formattedWrite!(LockingTextWriter,char,Sequence) instantiatied in /usr/include/d/std/stdio.d(1563): write!(Sequence,char) instantiatied in fasta.d(12): writeln!(Sequence) - sequence file can be show here: https://gitorious.org/dscience/dscience/blobs/master/dscience/molecules/sequence.d thanks
Re: typeof(string.front) should be char
On 03/03/2012 05:57 AM, Piotr Szturmaj wrote:
Consider a custom range of
char:
struct CharRange
{
@property bool empty();
@property char front();
void popFront();
}
typeof(CharRange.front) and ElementType!CharRange both return _char_
Yes, and I would expect both to the same type.
while for string they return _dchar_. This discrepancy pushes the range
writer to handle special string cases.
Yes, Phobos faces the same issues.
I'm currently trying to write
ByDchar range:
template ByDchar(R)
if (isInputRange!R isSomeChar!(ElementType!R))
{
alias ElementType!R E;
static if (is(E == dchar))
alias R ByDchar;
else static if (is(E == char))
{
struct ByDchar
{
...
}
}
else static if (is(E == wchar))
{
...
}
}
The problem with that range is when it takes a string type, it aliases
this type with itself, because ElementType!R yields dchar. This is why
I'm talking about bad consequences, I just want to iterate string by
_char_, not _dchar_.
In case you don't know already, there are std.traits.isNarrowString,
std.range.ForEachType, etc. which may be useful.
Ali
Re: Evaluating __FILE__ and __LINE__ of caller?
On 3/3/12, bioinfornatics bioinfornat...@fedoraproject.org wrote: I think __LINE__ is size_t not int I'd love to see a 2_147_483_648 line source file! :D
Delegator
hi,
In ruby we can delegate some method. by example:
Ruby
class MineArray
include Forwardable
def_delegators: @array, :[], :[]=, :each_with_index, :length
def initialize( array )
@array = array
end
end
-
this code delegate opIndexAssign opIndex, length ... attribute to his
member.
This save time, bug and line. You do not to have to write a code as:
void opIndexAssign( size_t index, T item){
array[index] = item;
}
thanks
Re: Delegator
Le samedi 03 mars 2012 à 17:42 +0100, bioinfornatics a écrit :
hi,
In ruby we can delegate some method. by example:
Ruby
class MineArray
include Forwardable
def_delegators: @array, :[], :[]=, :each_with_index, :length
def initialize( array )
@array = array
end
end
-
this code delegate opIndexAssign opIndex, length ... attribute to his
member.
This save time, bug and line. You do not to have to write a code as:
void opIndexAssign( size_t index, T item){
array[index] = item;
}
thanks
I miss the question ^^
can w do same in D ?
thanks
Re: Build error about LockingTextWriter
Le samedi 03 mars 2012 à 07:38 -0800, Ali Çehreli a écrit : On 03/03/2012 06:11 AM, bioinfornatics wrote: Dear, i do not understand what is wrong in my code and produce this: - $ ldc2 ../../lib/libdscience-ldc.a -I=../.. fasta.d /usr/include/d/std/range.d(295): Error: static assert Cannot put a Sequence into a LockingTextWriter instantiatied in /usr/include/d/std/format.d(1512): put!(LockingTextWriter,Sequence) instantiatied in /usr/include/d/std/format.d(1869): formatRange!(LockingTextWriter,Sequence,char) instantiatied in /usr/include/d/std/format.d(2232): formatValue!(LockingTextWriter,Sequence,char) ... (1 instantiations, -v to show) ... instantiatied in /usr/include/d/std/stdio.d(684): formattedWrite!(LockingTextWriter,char,Sequence) instantiatied in /usr/include/d/std/stdio.d(1563): write!(Sequence,char) instantiatied in fasta.d(12): writeln!(Sequence) - sequence file can be show here: https://gitorious.org/dscience/dscience/blobs/master/dscience/molecules/sequence.d thanks Just by reading the code, LockingTextWriter can put only the dchar type. This is from std.stdio: /// Range primitive implementations. void put(A)(A writeme) if (is(ElementType!A : const(dchar))) // ... void put(C)(C c) if (is(C : const(dchar))) I haven't tried it myself, but changing the return type of Sequence.front() to dchar would work. Ali thanks ali i have try but no same error
Re: typeof(string.front) should be char
On 03/03/2012 09:40 AM, Jonathan M Davis wrote: ... but operating on code points is _far_ more correct than operating on code units. It's also more efficient. [snip.] No, it is less efficient.
Re: Sending Tid in a struct
On 03/03/2012 12:09 PM, Nicolas Silva wrote:
Hi,
I'm trying to send structs using std.concurrency. the struct contains
a Tid (the id of the sender) so that the receiver can send an answer.
say:
struct Foo
{
Tid tid;
string str;
}
// ...
Foo f = {
tid: thisTid,
str: hello!
};
std.concurrency.send(someThread, f);
// /usr/include/d/dmd/phobos/std/concurrency.d(465): Error: static
assert Aliases to mutable thread-local data not allowed.
// hello.d(15):instantiated from here: send!(Foo)
However, I can send a Tid if I pass it directly as a parameter of the
send function instead of passing it within a struct.
Is this a bug ? It looks like so to me but I guess I could have missed
something.
thanks in advance,
Nicolas
Yes, this seems to be a bug.
Workaround:
struct Foo{
string s;
Tid id;
}
void foo(){
Foo foo;
receive((Tuple!(string,s,Tid,id) bar){foo=Foo(bar.s,bar.id);});
}
void main(){
auto id = spawn(foo);
id.send(string,id);
...
}
cluster computing
Any suggestions for using std.parallelism (like MPI for C/C++) for server clusters? Alternatively, how might I use MPI with D?
Re: typeof(string.front) should be char
On 2012-03-03 15:10, Ali Çehreli wrote: On 03/03/2012 04:36 AM, Jacob Carlborg wrote: On 2012-03-03 03:30, Piotr Szturmaj wrote: Hello, For this code: auto c = testc; auto w = testw; auto d = testd; pragma(msg, typeof(c.front)); pragma(msg, typeof(w.front)); pragma(msg, typeof(d.front)); compiler prints: dchar dchar immutable(dchar) I thought all these would be either dchar or immutable(dchar). Why are they of different types? In the case of char and wchar slices, the elements are decoded as the iteration happens. In other words, the returned values are not actual elements of the ranges. Ah, I see, thanks. -- /Jacob Carlborg
Re: Delegator
On 2012-03-03 17:50, bioinfornatics wrote:
Le samedi 03 mars 2012 à 17:42 +0100, bioinfornatics a écrit :
hi,
In ruby we can delegate some method. by example:
Ruby
class MineArray
include Forwardable
def_delegators: @array, :[], :[]=, :each_with_index, :length
def initialize( array )
@array = array
end
end
-
this code delegate opIndexAssign opIndex, length ... attribute to his
member.
This save time, bug and line. You do not to have to write a code as:
void opIndexAssign( size_t index, T item){
array[index] = item;
}
thanks
I miss the question ^^
can w do same in D ?
thanks
I would say yes, but not with the same pretty syntax. Something like this:
class MineArray
{
mixin delegates!(array, opIndexAssign, opIndex);
}
Just implement delegates to generate the given functions and forward
them to array.
--
/Jacob Carlborg
Re: Delegator
Le samedi 03 mars 2012 à 19:18 +0100, Jacob Carlborg a écrit :
On 2012-03-03 17:50, bioinfornatics wrote:
Le samedi 03 mars 2012 à 17:42 +0100, bioinfornatics a écrit :
hi,
In ruby we can delegate some method. by example:
Ruby
class MineArray
include Forwardable
def_delegators: @array, :[], :[]=, :each_with_index, :length
def initialize( array )
@array = array
end
end
-
this code delegate opIndexAssign opIndex, length ... attribute to his
member.
This save time, bug and line. You do not to have to write a code as:
void opIndexAssign( size_t index, T item){
array[index] = item;
}
thanks
I miss the question ^^
can w do same in D ?
thanks
I would say yes, but not with the same pretty syntax. Something like this:
class MineArray
{
mixin delegates!(array, opIndexAssign, opIndex);
}
Just implement delegates to generate the given functions and forward
them to array.
they are a way to create a decorator as @delgator for able to this
pretty ?
Re: Delegator
On Saturday, 3 March 2012 at 16:50:45 UTC, bioinfornatics wrote:
can w do same in D ?
alias this does that, although it does for all unknown
methods, not specific ones:
struct A {
int[] data;
alias data this;
}
A a;
a[0] = 10; // this works like a.data[0] = 10;
alias this also lets you pass the struct
when the member is expected:
void somethingWithArray(int[] arr) {}
A a;
somethingWithArray(a); // works, passes a.data automatically
Re: Delegator
Le samedi 03 mars 2012 à 19:45 +0100, Adam D. Ruppe a écrit :
On Saturday, 3 March 2012 at 16:50:45 UTC, bioinfornatics wrote:
can w do same in D ?
alias this does that, although it does for all unknown
methods, not specific ones:
struct A {
int[] data;
alias data this;
}
A a;
a[0] = 10; // this works like a.data[0] = 10;
alias this also lets you pass the struct
when the member is expected:
void somethingWithArray(int[] arr) {}
A a;
somethingWithArray(a); // works, passes a.data automatically
But when you have already a ctor ( class ) can you alias this ?
Re: Delegator
Le samedi 03 mars 2012 à 19:18 +0100, Jacob Carlborg a écrit :
On 2012-03-03 17:50, bioinfornatics wrote:
Le samedi 03 mars 2012 à 17:42 +0100, bioinfornatics a écrit :
hi,
In ruby we can delegate some method. by example:
Ruby
class MineArray
include Forwardable
def_delegators: @array, :[], :[]=, :each_with_index, :length
def initialize( array )
@array = array
end
end
-
this code delegate opIndexAssign opIndex, length ... attribute to his
member.
This save time, bug and line. You do not to have to write a code as:
void opIndexAssign( size_t index, T item){
array[index] = item;
}
thanks
I miss the question ^^
can w do same in D ?
thanks
I would say yes, but not with the same pretty syntax. Something like this:
class MineArray
{
mixin delegates!(array, opIndexAssign, opIndex);
}
Just implement delegates to generate the given functions and forward
them to array.
I found this way verys interestiong. Could you put plsease a shorter
implementation of delegates?
Re: Evaluating __FILE__ and __LINE__ of caller?
On Saturday, March 03, 2012 13:21:05 bioinfornatics wrote:
Le samedi 03 mars 2012 à 02:39 +0100, Adam D. Ruppe a écrit :
On Saturday, 3 March 2012 at 01:36:51 UTC, H. S. Teoh wrote:
int opIndex(int x) {
Make that
(int x, string file = __FILE__, int line = __LINE__)
and use file/line in there. The exception consturctors
do this, so you can
throw new Exception(msg, file, line);
and get it passed on.
I think __LINE__ is size_t not int
Yes, it's size_t.
- Jonathan M Davis
Re: typeof(string.front) should be char
On Saturday, March 03, 2012 18:38:44 Timon Gehr wrote: On 03/03/2012 09:40 AM, Jonathan M Davis wrote: ... but operating on code points is _far_ more correct than operating on code units. It's also more efficient. [snip.] No, it is less efficient. Operating on code points is more efficient than operating on graphemes is what I meant. I can see that I wasn't clear enough on that. It's more correct than operating on code units and less correct than operating on graphemes,while it's less efficient than operating on code units and more efficient than operating on graphemes. - Jonathan M Davis
Re: typeof(string.front) should be char
On Saturday, March 03, 2012 14:57:59 Piotr Szturmaj wrote: This discrepancy pushes the range writer to handle special string cases. Yes it does. And there's _no_ way around that if you want to handle unicode both correctly and efficiently. To handle it correctly, you must operate on code points (or even better, graphemes), but to handle them efficiently, you must take the encoding into account. Phobos has gone with the default of correctness while giving you the tools to special case stuff for efficiency. Phobos itself uses static if all over the place to special case pieces of functions on string type. Stuff like isNarrowString and ElementEncodingType exist specifically for that. The problem with that range is when it takes a string type, it aliases this type with itself, because ElementType!R yields dchar. This is why I'm talking about bad consequences, I just want to iterate string by _char_, not _dchar_. If you want to iterate by char, then use foreach or use a wrapper range (or cast to ubyte[] and operate on that). Phobos specificically does not to do that, because it breaks unicode. It doesn't stop you from iterating by char or wchar if you really want to, but it operates or ranges of dchar by default, because it's more correct. - Jonathan M Davis
Re: typeof(string.front) should be char
On 03/03/2012 08:46 PM, Jonathan M Davis wrote: On Saturday, March 03, 2012 18:38:44 Timon Gehr wrote: On 03/03/2012 09:40 AM, Jonathan M Davis wrote: ... but operating on code points is _far_ more correct than operating on code units. It's also more efficient. [snip.] No, it is less efficient. Operating on code points is more efficient than operating on graphemes is what I meant. I can see that I wasn't clear enough on that. Makes sense. It's more correct than operating on code units and less correct than operating on graphemes,while it's less efficient than operating on code units and more efficient than operating on graphemes. - Jonathan M Davis When the code actually only cares about some characters that have 7-bit ASCII values, most of the time there are no correctness issues when operating on code units directly.
Problem when building LDC
When I try to build LDC on Debian Squeeze I get the following error when running cmake: CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE): REQUIRED_VARS (missing: VERSION_VAR) Does anyone here know what VERSION_VAR is and what should I set it to? The LDC website doesn't say anything about it.
Re: Evaluating __FILE__ and __LINE__ of caller?
On Sat, Mar 03, 2012 at 03:52:55PM +0100, Andrej Mitrovic wrote: On 3/3/12, bioinfornatics bioinfornat...@fedoraproject.org wrote: I think __LINE__ is size_t not int I'd love to see a 2_147_483_648 line source file! :D It *could* happen if the source file was auto-generated... and the autogenerator was broken. :P Of course, with D's templates, CTFE, and compile-time introspection capabilities, I can't imagine when autogeneration would actually be required, but we're talking about hypotheticals here. T -- Debian GNU/Linux: Cray on your desktop.
Re: Build error about LockingTextWriter
On 03/03/2012 09:00 AM, bioinfornatics wrote: Le samedi 03 mars 2012 à 07:38 -0800, Ali Çehreli a écrit : On 03/03/2012 06:11 AM, bioinfornatics wrote: Dear, i do not understand what is wrong in my code and produce this: - $ ldc2 ../../lib/libdscience-ldc.a -I=../.. fasta.d /usr/include/d/std/range.d(295): Error: static assert Cannot put a Sequence into a LockingTextWriter instantiatied in /usr/include/d/std/format.d(1512): put!(LockingTextWriter,Sequence) instantiatied in /usr/include/d/std/format.d(1869): formatRange!(LockingTextWriter,Sequence,char) instantiatied in /usr/include/d/std/format.d(2232): formatValue!(LockingTextWriter,Sequence,char) ... (1 instantiations, -v to show) ... instantiatied in /usr/include/d/std/stdio.d(684): formattedWrite!(LockingTextWriter,char,Sequence) instantiatied in /usr/include/d/std/stdio.d(1563): write!(Sequence,char) instantiatied in fasta.d(12): writeln!(Sequence) - sequence file can be show here: https://gitorious.org/dscience/dscience/blobs/master/dscience/molecules/sequence.d thanks Just by reading the code, LockingTextWriter can put only the dchar type. This is from std.stdio: /// Range primitive implementations. void put(A)(A writeme) if (is(ElementType!A : const(dchar))) // ... void put(C)(C c) if (is(C : const(dchar))) I haven't tried it myself, but changing the return type of Sequence.front() to dchar would work. I was wrong anyway. I think is(C : const(dchar)) means if C can implicitly be convertible to dchar. That is the case for char and wchar, so that can't be the reason. Ali thanks ali i have try but no same error Sorry, no more ideas here. :( Ali
Re: typeof(string.front) should be char
On Sat, Mar 03, 2012 at 12:42:53PM -0800, Jonathan M Davis wrote: [...] The current solution encourages correct usage (or at least usage which is closer to correct, since it still isn't at the grapheme level) without disallowing more optimized code. [...] Speaking of graphemes, is anyone interested in implementing Unicode normalization for D? I looked at the specs briefly, and it seems to be something that is straightforward to implement, albeit somewhat tedious. It would be nice if D string types are normalized (needs slight change to string concatenation). Or at least, if there's a guaranteed normalized string type for those who care about it. T -- You have to expect the unexpected. -- RL
Re: typeof(string.front) should be char
On Sat, Mar 03, 2012 at 11:53:41AM -0800, Jonathan M Davis wrote:
[...]
If you want to iterate by char, then use foreach or use a wrapper
range (or cast to ubyte[] and operate on that).
Or use:
string str = ...;
for (size_t i=0; i str.length; i++) {
/* do something with str[i] */
}
Phobos specificically does not to do that, because it breaks unicode.
It doesn't stop you from iterating by char or wchar if you really want
to, but it operates or ranges of dchar by default, because it's more
correct.
[...]
I think this is the correct approach. Always err on the side of correct
and/or safe, but give the programmer the option of getting under the
hood if he wants otherwise.
T
--
A linguistics professor was lecturing to his class one day.
In English, he said, A double negative forms a positive. In some
languages, though, such as Russian, a double negative is still a
negative. However, there is no language wherein a double positive can
form a negative.
A voice from the back of the room piped up, Yeah, yeah.
Re: typeof(string.front) should be char
On 03/03/2012 01:42 PM, H. S. Teoh wrote: On Sat, Mar 03, 2012 at 12:42:53PM -0800, Jonathan M Davis wrote: [...] The current solution encourages correct usage (or at least usage which is closer to correct, since it still isn't at the grapheme level) without disallowing more optimized code. [...] Speaking of graphemes, is anyone interested in implementing Unicode normalization for D? I looked at the specs briefly, and it seems to be something that is straightforward to implement, albeit somewhat tedious. It would be nice if D string types are normalized (needs slight change to string concatenation). Or at least, if there's a guaranteed normalized string type for those who care about it. T Denis Spir was working on solving that problem but unfortunately we haven't heard from him for almost a year now. I think this is his site: http://spir.wikidot.com Ali
Re: Evaluating __FILE__ and __LINE__ of caller?
On 3/3/12, H. S. Teoh hst...@quickfur.ath.cx wrote: Of course, with D's templates, CTFE, and compile-time introspection capabilities, I can't imagine when autogeneration would actually be required, but we're talking about hypotheticals here. It can be if you need an OOP D binding to a C/C++ library. E.g. QtD uses an autogenerator, GtkD as well.
Re: Delegator
Le samedi 03 mars 2012 à 19:18 +0100, Jacob Carlborg a écrit :
On 2012-03-03 17:50, bioinfornatics wrote:
Le samedi 03 mars 2012 à 17:42 +0100, bioinfornatics a écrit :
hi,
In ruby we can delegate some method. by example:
Ruby
class MineArray
include Forwardable
def_delegators: @array, :[], :[]=, :each_with_index, :length
def initialize( array )
@array = array
end
end
-
this code delegate opIndexAssign opIndex, length ... attribute to his
member.
This save time, bug and line. You do not to have to write a code as:
void opIndexAssign( size_t index, T item){
array[index] = item;
}
thanks
I miss the question ^^
can w do same in D ?
thanks
I would say yes, but not with the same pretty syntax. Something like this:
class MineArray
{
mixin delegates!(array, opIndexAssign, opIndex);
}
Just implement delegates to generate the given functions and forward
them to array.
I have try to do a mixin template but i fail
-- D Code
import std.string;
import std.stdio;
import std.range;
mixin template arrayDelegator( alias instance, methods... ){
string result;
static if( methods.length 0 ){
static if( opIndexAssign ){
result ~=
void opIndexAssign( size_t index, ~
ElementEncodingType!(typeof(instance)) ~ item ){
array[index] = item;
}
;
}
static else if( opIndex ){
result ~=
~ ElementEncodingType!(typeof(instance)) ~ opIndex( size_t index
){
return instance[index];
}
;
}
static else if( length ){
result ~=
@property size_t length(){
return instance.length;
}
;
}
static else
throw new Exception( Unknown methods: ~ method );
static if( methods.length 2 )
arrayDelegator!( instance, methods[1 .. $ ] );
}
mixin(result);
}
class Container{
size_t[] array;
mixin arrayDelegator!(array, opIndexAssign, opIndex, length);
this( size_t[] a ){
array = a:
}
}
void main( string[] args ){
Container c = new Container( [0u, 1u, 2u, 3u] );
writeln( c[2] );
c[2] = 4u;
writeln( c[2] );
}
-
$ ldc2 delegator.d
delegator.d(9): no identifier for declarator result
delegator.d(9): semicolon expected, not '~='
delegator.d(9): Declaration expected, not '~='
delegator.d(15): Declaration expected, not 'else'
delegator.d(22): Declaration expected, not 'else'
delegator.d(29): Declaration expected, not 'else'
delegator.d(32): no identifier for declarator
arrayDelegator!(instance,methods[1 .. __dollar])
delegator.d(33): unrecognized declaration
How to avoid code duplication in static if branches?
import std.stdio;
void check() { writeln(check); }
struct Foo { bool isTrue = true; }
struct Bar { }
void test(T)(T t)
{
static if (is(T == Foo))
{
if (t.isTrue)
check();
}
else
{
check();
}
}
void main()
{
Foo foo;
Bar bar;
test(foo);
test(bar);
}
I want to avoid writing check() twice. I only have to statically
check a field of a member if it's of a certain type (Foo).
One solution would be to use a boolean:
void test(T)(T t)
{
bool isTrue = true;
static if (is(T == Foo))
isTrue = t.isTrue;
if (isTrue)
check();
}
But that kind of defeats the purpose of static if (avoiding runtime
overhead). Does anyone have a trick up their sleeve for these types of
situations? :)
Re: typeof(string.front) should be char
On Saturday, March 03, 2012 13:46:16 Ali Çehreli wrote: On 03/03/2012 01:42 PM, H. S. Teoh wrote: On Sat, Mar 03, 2012 at 12:42:53PM -0800, Jonathan M Davis wrote: [...] The current solution encourages correct usage (or at least usage which is closer to correct, since it still isn't at the grapheme level) without disallowing more optimized code. [...] Speaking of graphemes, is anyone interested in implementing Unicode normalization for D? I looked at the specs briefly, and it seems to be something that is straightforward to implement, albeit somewhat tedious. It would be nice if D string types are normalized (needs slight change to string concatenation). Or at least, if there's a guaranteed normalized string type for those who care about it. T Denis Spir was working on solving that problem but unfortunately we haven't heard from him for almost a year now. I think this is his site: http://spir.wikidot.com Ali
[SUCCESS] delegator
dear, I have a little code who is able to delegate to an array see below code: https://gist.github.com/1969776 It should realy great to have same into std.array and into std.range (for reach different range )
Re: typeof(string.front) should be char
On Saturday, March 03, 2012 13:46:16 Ali Çehreli wrote: On 03/03/2012 01:42 PM, H. S. Teoh wrote: On Sat, Mar 03, 2012 at 12:42:53PM -0800, Jonathan M Davis wrote: [...] The current solution encourages correct usage (or at least usage which is closer to correct, since it still isn't at the grapheme level) without disallowing more optimized code. [...] Speaking of graphemes, is anyone interested in implementing Unicode normalization for D? I looked at the specs briefly, and it seems to be something that is straightforward to implement, albeit somewhat tedious. It would be nice if D string types are normalized (needs slight change to string concatenation). Or at least, if there's a guaranteed normalized string type for those who care about it. T Denis Spir was working on solving that problem but unfortunately we haven't heard from him for almost a year now. I think this is his site: http://spir.wikidot.com There's some stuff in the new std.regex which was done to enhance unicode support which is currently completely internal to it which may end up being the basis for more, but Dmitry hasn't yet worked on creating a version of that for more general consumption AFAIK. I'm not quite sure what he did though, since I'm not familier with std.regex. - Jonathan M Davis
Re: How to avoid code duplication in static if branches?
04.03.2012 3:42, Andrej Mitrovic пишет:
[...code...]
I want to avoid writing check() twice. I only have to statically
check a field of a member if it's of a certain type (Foo).
One solution would be to use a boolean:
void test(T)(T t)
{
bool isTrue = true;
static if (is(T == Foo))
isTrue = t.isTrue;
if (isTrue)
check();
}
But that kind of defeats the purpose of static if (avoiding runtime
overhead). Does anyone have a trick up their sleeve for these types of
situations? :)
Alias maybe?
void test(T)( T t ) {
enum TRUE = true;
static if( is(T == Foo) ) {
alias t.isTrue isTrue;
} else {
alias TRUE isTrue;
}
if( isTrue ) {
check();
}
}
This will still insert a redundant check for one of instantiations, but
compiler should be able to deal with 'if(true)' checks.
Re: Evaluating __FILE__ and __LINE__ of caller?
Ok, well a quick search shows socket.d:132 needs fixing. Also there's two versioned out enforces in object_.d which use int line = __LINE__. Interestingly, earlier versions of Phobos used int a lot (I guess in pre-64bit compatible D days). I'm also seeing int used in Derelict, pspemu, plot2kill and dwt2.
Re: Evaluating __FILE__ and __LINE__ of caller?
On Sunday, March 04, 2012 03:38:03 Andrej Mitrovic wrote: Ok, well a quick search shows socket.d:132 needs fixing. Also there's two versioned out enforces in object_.d which use int line = __LINE__. Interestingly, earlier versions of Phobos used int a lot (I guess in pre-64bit compatible D days). I'm also seeing int used in Derelict, pspemu, plot2kill and dwt2. It's a common error to use int where size_t should be used. Using int when dealing with __LINE__ is just one case of that. It didn't start actually causing compilation errors until we go 64-bit dmd though. - Jonathan M Davis
Re: How to avoid code duplication in static if branches?
Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message
news:mailman.364.1330825349.24984.digitalmars-d-le...@puremagic.com...
import std.stdio;
void check() { writeln(check); }
struct Foo { bool isTrue = true; }
struct Bar { }
void test(T)(T t)
{
static if (is(T == Foo))
{
if (t.isTrue)
check();
}
else
{
check();
}
}
void main()
{
Foo foo;
Bar bar;
test(foo);
test(bar);
}
I want to avoid writing check() twice. I only have to statically
check a field of a member if it's of a certain type (Foo).
One solution would be to use a boolean:
void test(T)(T t)
{
bool isTrue = true;
static if (is(T == Foo))
isTrue = t.isTrue;
if (isTrue)
check();
}
But that kind of defeats the purpose of static if (avoiding runtime
overhead). Does anyone have a trick up their sleeve for these types of
situations? :)
Have you checked the generated code? When the static if check fails, it
should be reduced to:
void test(T)(T t)
{
bool isTrue = true;
if (isTrue)
check();
}
And the compiler should be able to tell that isTrue is always true.
Otherwise,
void test(T)(T t)
{
enum doCheck = is(T == Foo);
bool isTrue = true;
static if (is(T == Foo))
auto isTrue = t.isTrue;
if (!doCheck || isTrue)
check();
}
The compiler takes care of it because doCheck is known at compile time.
Re: How to avoid code duplication in static if branches?
You're right it should be able do that dead-code elimination thing.
Slipped my mind. :)
On 3/4/12, Daniel Murphy yebbl...@nospamgmail.com wrote:
Andrej Mitrovic andrej.mitrov...@gmail.com wrote in message
news:mailman.364.1330825349.24984.digitalmars-d-le...@puremagic.com...
import std.stdio;
void check() { writeln(check); }
struct Foo { bool isTrue = true; }
struct Bar { }
void test(T)(T t)
{
static if (is(T == Foo))
{
if (t.isTrue)
check();
}
else
{
check();
}
}
void main()
{
Foo foo;
Bar bar;
test(foo);
test(bar);
}
I want to avoid writing check() twice. I only have to statically
check a field of a member if it's of a certain type (Foo).
One solution would be to use a boolean:
void test(T)(T t)
{
bool isTrue = true;
static if (is(T == Foo))
isTrue = t.isTrue;
if (isTrue)
check();
}
But that kind of defeats the purpose of static if (avoiding runtime
overhead). Does anyone have a trick up their sleeve for these types of
situations? :)
Have you checked the generated code? When the static if check fails, it
should be reduced to:
void test(T)(T t)
{
bool isTrue = true;
if (isTrue)
check();
}
And the compiler should be able to tell that isTrue is always true.
Otherwise,
void test(T)(T t)
{
enum doCheck = is(T == Foo);
bool isTrue = true;
static if (is(T == Foo))
auto isTrue = t.isTrue;
if (!doCheck || isTrue)
check();
}
The compiler takes care of it because doCheck is known at compile time.
Re: How to avoid code duplication in static if branches?
Andrej Mitrovic wrote:
...snip...
I want to avoid writing check() twice. I only have to statically
check a field of a member if it's of a certain type (Foo).
One solution would be to use a boolean:
void test(T)(T t)
{
bool isTrue = true;
static if (is(T == Foo))
isTrue = t.isTrue;
if (isTrue)
check();
}
But that kind of defeats the purpose of static if (avoiding runtime
overhead). Does anyone have a trick up their sleeve for these types of
situations? :)
There's always this:
void test(T)(T t)
{
static if (is (T == Foo))
if (!t.isTrue)
return;
check();
}
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
