Re: Adding pointers to GC with destructers

2015-04-20 Thread Ali Çehreli via Digitalmars-d-learn

On 04/20/2015 02:48 PM, Freddy wrote:

On Monday, 20 April 2015 at 02:56:35 UTC, Ali Çehreli wrote:

Not automatically. Check out addRange and addRoot:

  http://dlang.org/phobos/core_memory.html

Ali

The destructor doesn't seem to be running


Sorry, I misunderstood you. You can use a RAII object as ketmar said:

import std.stdio;
import std.c.stdlib;

struct Test{
void* ptr;

~this(){
writeln(free: ,this);
free(ptr);
}
}

void main(){
auto ptr=cast(Test*)malloc(4);
writeln(create: ,ptr);

auto test = Test(ptr);  // -- The dtor of this object will free
}

Ali



Re: Reuse object memory?

2015-04-20 Thread Ali Çehreli via Digitalmars-d-learn

On 04/20/2015 02:44 PM, Namespace wrote:

 Thank you. Do you mean this is worth a PR, to add this
 functionality to Phobos?

I am not familiar with such a need so I don't have a strong opinion.

However, if an object needs to be emplaced on top of an existing one, I 
can imagine that the original object was emplaced on some piece of 
memory anyway. In that case, the problem becomes emplacing an object on 
a piece of memory, which is already supported by std.conv.emplace.


Your idea seems to be for the case where the original object is created 
by some third party code, and that they want us to replace it with 
another object. If they are aware of the wholesale change in the object, 
fine. :)


Ali



Re: Reuse object memory?

2015-04-20 Thread Namespace via Digitalmars-d-learn
Thank you. Do you mean this is worth a PR, to add this 
functionality to Phobos?
My current code looks like this: 
http://dpaste.dzfl.pl/19b78a600b6c


Re: User defined properties signatures

2015-04-20 Thread dvic via Digitalmars-d-learn

On Monday, 20 April 2015 at 20:22:40 UTC, Jonathan M Davis wrote:
On Monday, April 20, 2015 19:42:30 dvic via Digitalmars-d-learn 
wrote:
Thanks for your answer Jonathan. But does the return type part 
of

a method
signature? I don't know what theory is claiming about that, but
for me they
are 2 different methods. So contextually, the best fit should
prevail.


The return type is not considered in overloading. And it would 
complicate
things considerably if it were. Some basic cases are pretty 
obvious, like


int foo();
string foo();
int a = foo()

But what about something like

int foo();
float foo();
auto a = foo() + foo();

or

int foo();
string foo();
void bar(int);
void bar(string);
bar(foo());

It's far simpler for the language to not consider return types 
in
overloading and to simply use it for the type of the resulting 
expression.
Then it's generally straightforward for it to determine what 
the type of

complex expressions are. But if the return type is considered in
overloading, then it gets _way_ more complicated, especially 
when the

expressions get at all complicated.

At best, the compiler would be able to work in the simple cases 
and error
out in the complex ones, but it wouldn't take much before it 
would have to

give up and give an error due to ambiguity.

There may be languages out there which take the the return type 
into account

when overloading, but I've never seen one.

- Jonathan M Davis



Thanks Johnathan for the detailed explanation !


Re: Adding pointers to GC with destructers

2015-04-20 Thread Freddy via Digitalmars-d-learn

On Monday, 20 April 2015 at 02:56:35 UTC, Ali Çehreli wrote:

Not automatically. Check out addRange and addRoot:

  http://dlang.org/phobos/core_memory.html

Ali

The destructor doesn't seem to be running

import std.stdio;
import std.c.stdlib;
import core.memory;
struct Test{
~this(){
writeln(free: ,this);
free(this);
}
}

void main(){
auto ptr=cast(Test*)malloc(4);
writeln(create: ,ptr);
GC.addRange(ptr,0,typeid(Test));
ptr=null;
GC.collect();
}

$ rdmd test
create: 1EEC730


Re: Reuse object memory?

2015-04-20 Thread Ali Çehreli via Digitalmars-d-learn

On 04/20/2015 12:05 PM, Namespace wrote:

 I'm sorry if I annoy you

Not at all! :) Sorry for not responding earlier.

, but I would really like to know how you would
 reuse already instantiated storage of an existing object.

 Example code:
 
 final class Foo {
  uint id;

  @nogc
  this(uint id) {
  this.id = id;
  }
 }

 Foo f = new Foo(42);
 

Something like the following works. I chose to set the old object to 
null but it is not necessary:


final class Foo {
uint id;

@nogc
this(uint id) {
this.id = id;
}
}

C reuse(C, T...)(ref C old, T ctorParams)
{
import std.conv;
import std.typetuple;

enum objectSize = __traits(classInstanceSize, C);

void* oldPlace = cast(void*)old;
C newObject = emplace!C(oldPlace[0..objectSize], ctorParams);

old = null;

return newObject;
}

void main()
{
Foo f = new Foo(42);

auto f2 = f.reuse(43);

assert(f is null);
assert(f2.id == 43);
}

Ali



Re: Duplicate another function's parameters in a template function

2015-04-20 Thread Tofu Ninja via Digitalmars-d-learn

On Monday, 20 April 2015 at 23:20:07 UTC, Justin Whear wrote:

See std.functional.forward:
http://dlang.org/phobos/std_functional.html#.forward


Sweet beans, thanks


Re: Reuse object memory?

2015-04-20 Thread Namespace via Digitalmars-d-learn

On Monday, 20 April 2015 at 21:58:59 UTC, Ali Çehreli wrote:

On 04/20/2015 02:44 PM, Namespace wrote:

 Thank you. Do you mean this is worth a PR, to add this
 functionality to Phobos?

I am not familiar with such a need so I don't have a strong 
opinion.


However, if an object needs to be emplaced on top of an 
existing one, I can imagine that the original object was 
emplaced on some piece of memory anyway. In that case, the 
problem becomes emplacing an object on a piece of memory, 
which is already supported by std.conv.emplace.


Your idea seems to be for the case where the original object is 
created by some third party code, and that they want us to 
replace it with another object. If they are aware of the 
wholesale change in the object, fine. :)


Ali


I have currently an array of objects which may be reloaded (it's 
a tilemap). If the array is reused, I can do that with:


arr.length = 0;
arr.assumeSafeAppend();

But then I thought: why not reuse the memory of the objects?
In C++ you can do that very elegant, but in D I have to produce 
garbage since the old object stays alive until the GC collects it 
and I have to allocate new GC memory.


Re: Adding pointers to GC with destructers

2015-04-20 Thread Freddy via Digitalmars-d-learn

On Monday, 20 April 2015 at 22:24:53 UTC, Ali Çehreli wrote:

On 04/20/2015 02:48 PM, Freddy wrote:

On Monday, 20 April 2015 at 02:56:35 UTC, Ali Çehreli wrote:

Not automatically. Check out addRange and addRoot:

 http://dlang.org/phobos/core_memory.html

Ali

The destructor doesn't seem to be running


Sorry, I misunderstood you. You can use a RAII object as ketmar 
said:


import std.stdio;
import std.c.stdlib;

struct Test{
void* ptr;

~this(){
writeln(free: ,this);
free(ptr);
}
}

void main(){
auto ptr=cast(Test*)malloc(4);
writeln(create: ,ptr);

auto test = Test(ptr);  // -- The dtor of this object will 
free

}

Ali
I believe your original understanding was right.I want to have 
HiddenType* be garbage collected and finalized(freed,destructed) 
when no more references to it are found(stack or heap). I could 
use reference counting but it seems inefficient for a program 
rarely collecting and constantly coping.


Re: Duplicate another function's parameters in a template function

2015-04-20 Thread Justin Whear via Digitalmars-d-learn
On Mon, 20 Apr 2015 22:50:52 +, Tofu Ninja wrote:

 I am trying to write a template function that can take another function
 as an alias template argument and duplicate its parameters for it self.
 
 I tried..
 
 auto pass(alias f, T...)(T t)
 {
  // other stuff... return f(t);
 }
 
 but that does not work if there is a ref parameter.
 
 Thanks

See std.functional.forward:
http://dlang.org/phobos/std_functional.html#.forward


Duplicate another function's parameters in a template function

2015-04-20 Thread Tofu Ninja via Digitalmars-d-learn
I am trying to write a template function that can take another 
function as an alias template argument and duplicate its 
parameters for it self.


For example, something like this...

void foo(ref int x){x = 7;}

auto pass(alias f)(/* ??? */)
{
// other stuff...
return f( /* ??? */ );
}

void main()
{
int y = 0;
pass!foo(y);
assert(y==7);
}


I tried..

auto pass(alias f, T...)(T t)
{
// other stuff...
return f(t);
}

but that does not work if there is a ref parameter.

Thanks


Re: Valgrind

2015-04-20 Thread Vladimir Panteleev via Digitalmars-d-learn

On Monday, 20 April 2015 at 13:29:58 UTC, John Colvin wrote:

On Monday, 20 April 2015 at 13:28:57 UTC, John Colvin wrote:
On Monday, 20 April 2015 at 13:16:23 UTC, Robert M. Münch 
wrote:
Hi, I just found quite old posts about Valgrind and D. Can 
someone give me a short update, what the state of support for 
D is and if there is anythings special to take into account. 
Thanks a lot.


The only special thing to take in to account is that valgrind 
will choke on DMD generated floating point code, so really you 
have to use GDC or LDC if you want to use valgrind.


Correction: The only special thing I know of.


AFAIK, this has been fixed a long time ago.


Re: Reading whitespace separated strings from stdin?

2015-04-20 Thread weaselcat via Digitalmars-d-learn

On Tuesday, 21 April 2015 at 01:31:58 UTC, TheGag96 wrote:
Hi guys! I had this homework assignment for data structures 
that has a pretty easy solution in C++. Reading input like 
this...


1 2 3 # $
4 3 * ! #
20 3 / # $ #
62 # $
2 3 8 * + #
4 48 4 2 + / #
SUM # $
1 2 3 4 5 #
R #
@

...where @ denotes the end of input is fairly simple in C++:

string token = ;
while (token != @) {
  //handle input
}

Note that having newlines doesn't matter at all; every token is 
just assumed to be separated by whitespace. However in D, I 
looked around could not find a solution better than this:


foreach (line; stdin.byLine) {
  foreach (token; line.split) {
//handle input
  }
}

Is there any way to do this without two loops/creating an 
array? readf( %d, token); wasn't cutting it either.


Thanks.


import std.stdio;
import std.array;
void main(){
auto tokens = stdin.readln('@').split;
writeln(tokens);
}

[1, 2, 3, #, $, 4, 3, *, !, #, 20, 3, 
/, #, $, #, 62, #, $, 2, 3, 8, *, +, #, 
4, 48, 4, 2, +, /, #, SUM, #, $, 1, 2, 
3, 4, 5, #, R, #, @]


Reading whitespace separated strings from stdin?

2015-04-20 Thread TheGag96 via Digitalmars-d-learn
Hi guys! I had this homework assignment for data structures that 
has a pretty easy solution in C++. Reading input like this...


1 2 3 # $
4 3 * ! #
20 3 / # $ #
62 # $
2 3 8 * + #
4 48 4 2 + / #
SUM # $
1 2 3 4 5 #
R #
@

...where @ denotes the end of input is fairly simple in C++:

string token = ;
while (token != @) {
  //handle input
}

Note that having newlines doesn't matter at all; every token is 
just assumed to be separated by whitespace. However in D, I 
looked around could not find a solution better than this:


foreach (line; stdin.byLine) {
  foreach (token; line.split) {
//handle input
  }
}

Is there any way to do this without two loops/creating an array? 
readf( %d, token); wasn't cutting it either.


Thanks.


Re: Valgrind

2015-04-20 Thread Nick B via Digitalmars-d-learn

On Monday, 20 April 2015 at 17:25:55 UTC, John Colvin wrote:

On Monday, 20 April 2015 at 16:58:18 UTC, Robert M. Münch wrote:

On 2015-04-20 13:29:57 +, John Colvin said:






Were the causes ever analyzed? I'm a bit wondering why it 
happens on floating point stuff...


valgrind doesn't have full support for x87 code, which dmd 
emits all over the place.


There is company is Germany, which does Valgrind consultancy,

http://www.open-works.net/contact.html

which could fix this issue, if you are prepared to throw some 
money their way.


Nick


Re: Reading whitespace separated strings from stdin?

2015-04-20 Thread Adam D. Ruppe via Digitalmars-d-learn

I think this should work:

import std.stdio;

void main() {
string token;
while(readf(%s , token))
writeln(token);
}


Have you tried that? What is wrong with it if you have?


Re: Reading whitespace separated strings from stdin?

2015-04-20 Thread TheGag96 via Digitalmars-d-learn

On Tuesday, 21 April 2015 at 01:46:53 UTC, Adam D. Ruppe wrote:

I think this should work:

import std.stdio;

void main() {
string token;
while(readf(%s , token))
writeln(token);
}


Have you tried that? What is wrong with it if you have?


It'll just leave some trailing whitespace, which I don't want. 
And somehow doing token = token.stip STILL leaves that whitespace 
somehow...


Re: Reading whitespace separated strings from stdin?

2015-04-20 Thread Adam D. Ruppe via Digitalmars-d-learn

On Tuesday, 21 April 2015 at 02:04:24 UTC, TheGag96 wrote:

It'll just leave some trailing whitespace, which I don't want.


oh it also keeps the newlines attached. Blargh.

Well, forget the D functions, just use the C functions:

import core.stdc.stdio;

void main() {
char[16] token;
while(scanf(%15s, token) != EOF)
printf(**%s**\n, token.ptr);
}



You could convert to a string if needed with import std.conv; 
to!string(token.ptr), but if you can avoid that, you should, this 
loop has no allocations which is a nice thing.


Re: Valgrind

2015-04-20 Thread Martin Nowak via Digitalmars-d-learn

On Monday, 20 April 2015 at 13:28:57 UTC, John Colvin wrote:
The only special thing to take in to account is that valgrind 
will choke on DMD generated floating point code


I actually fixed this problem a while ago.
https://github.com/D-Programming-Language/dmd/pull/4368

An actual problem with valgrind is the GC, because most of it's 
operations appear to valgrind as memory corruptions.
You can GC.disable() collections, use gcstub.d, or help Vladimir 
with his valgrind/GC support to make things work.


http://dlang.org/phobos/core_memory.html#.GC.disable
https://github.com/D-Programming-Language/druntime/blob/master/src/gcstub/gc.d
https://github.com/CyberShadow/druntime/commits/valgrind


Re: Valgrind

2015-04-20 Thread Brad Roberts via Digitalmars-d-learn
Valgrind has a mechanism for teaching it how to ignore certain patterns. 
 A long time ago I setup suppressions for the gc, but the code has 
changed out from under that version so the work would need to be redone.


On 4/20/2015 7:23 PM, Martin Nowak via Digitalmars-d-learn wrote:

On Monday, 20 April 2015 at 13:28:57 UTC, John Colvin wrote:

The only special thing to take in to account is that valgrind will
choke on DMD generated floating point code


I actually fixed this problem a while ago.
https://github.com/D-Programming-Language/dmd/pull/4368

An actual problem with valgrind is the GC, because most of it's
operations appear to valgrind as memory corruptions.
You can GC.disable() collections, use gcstub.d, or help Vladimir with
his valgrind/GC support to make things work.

http://dlang.org/phobos/core_memory.html#.GC.disable
https://github.com/D-Programming-Language/druntime/blob/master/src/gcstub/gc.d

https://github.com/CyberShadow/druntime/commits/valgrind


Re: Adding pointers to GC with destructers

2015-04-20 Thread Martin Nowak via Digitalmars-d-learn

On Sunday, 19 April 2015 at 23:38:49 UTC, Freddy wrote:

C libraries have a pattern of

HiddenType* getObj();
void freeObj(HiddenType*);

Is there any way I can make the GC search for a HiddenType* 
and run freeObj when the pointer is not found.


You can't turn an arbitrary pointer into a garbage collected 
object.

What you can do, is putting the pointer into a GCed object.

class Wrapper {
  this(HiddenType* p) { _p = p; } }
  ~this() { freeObj(_p); }
  alias _p this;
}

auto obj = new Wrapper(getObj());

Since 2.067.0 we also finalize heap allocated structs, so the 
wrapper can also be a struct.


Re: Formatted output ranges

2015-04-20 Thread Dennis Ritchie via Digitalmars-d-learn

On Monday, 20 April 2015 at 17:16:21 UTC, Ivan Kazmenko wrote:

writeln(wrap(a, 30, ;; , ;; ));

Works with dmd 2.066.1 and 2.067.0.


Thanks.


Re: User defined properties signatures

2015-04-20 Thread Jonathan M Davis via Digitalmars-d-learn
On Monday, April 20, 2015 19:42:30 dvic via Digitalmars-d-learn wrote:
 Thanks for your answer Jonathan. But does the return type part of
 a method
 signature? I don't know what theory is claiming about that, but
 for me they
 are 2 different methods. So contextually, the best fit should
 prevail.

The return type is not considered in overloading. And it would complicate
things considerably if it were. Some basic cases are pretty obvious, like

int foo();
string foo();
int a = foo()

But what about something like

int foo();
float foo();
auto a = foo() + foo();

or

int foo();
string foo();
void bar(int);
void bar(string);
bar(foo());

It's far simpler for the language to not consider return types in
overloading and to simply use it for the type of the resulting expression.
Then it's generally straightforward for it to determine what the type of
complex expressions are. But if the return type is considered in
overloading, then it gets _way_ more complicated, especially when the
expressions get at all complicated.

At best, the compiler would be able to work in the simple cases and error
out in the complex ones, but it wouldn't take much before it would have to
give up and give an error due to ambiguity.

There may be languages out there which take the the return type into account
when overloading, but I've never seen one.

- Jonathan M Davis



Valgrind

2015-04-20 Thread Robert M. Münch via Digitalmars-d-learn
Hi, I just found quite old posts about Valgrind and D. Can someone give 
me a short update, what the state of support for D is and if there is 
anythings special to take into account. Thanks a lot.


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



Re: Valgrind

2015-04-20 Thread John Colvin via Digitalmars-d-learn

On Monday, 20 April 2015 at 13:28:57 UTC, John Colvin wrote:

On Monday, 20 April 2015 at 13:16:23 UTC, Robert M. Münch wrote:
Hi, I just found quite old posts about Valgrind and D. Can 
someone give me a short update, what the state of support for 
D is and if there is anythings special to take into account. 
Thanks a lot.


The only special thing to take in to account is that valgrind 
will choke on DMD generated floating point code, so really you 
have to use GDC or LDC if you want to use valgrind.


Correction: The only special thing I know of.


Re: Valgrind

2015-04-20 Thread John Colvin via Digitalmars-d-learn

On Monday, 20 April 2015 at 13:16:23 UTC, Robert M. Münch wrote:
Hi, I just found quite old posts about Valgrind and D. Can 
someone give me a short update, what the state of support for D 
is and if there is anythings special to take into account. 
Thanks a lot.


The only special thing to take in to account is that valgrind 
will choke on DMD generated floating point code, so really you 
have to use GDC or LDC if you want to use valgrind.


Re: build vibe-d-0.7.23 error on win7 x86?

2015-04-20 Thread Etienne via Digitalmars-d-learn

On Monday, 20 April 2015 at 07:58:40 UTC, mzf wrote:

win 7 x86,3GB ram:

1. dmd 2.066 vibe-d-0.7.23, it's ok.

2. dmd 2.067 vibe-d-0.7.23,
   show error msg out of memory

why?


http://forum.dlang.org/thread/mghqlf$10l2$1...@digitalmars.com#post-ybrtcxrcmrrsoaaksdbj:40forum.dlang.org


Re: SysTime.toISOExtString with timezone offset

2015-04-20 Thread Steven Schveighoffer via Digitalmars-d-learn

On 4/20/15 4:47 AM, Jonathan M Davis via Digitalmars-d-learn wrote:


Perhaps, LocalTime should be changed so that it prints the time zone out
(and just make it so that the lack of time zone is read in as local time
rather than treating it that way in both directions), but that's not how it
works currently.


Yeah, I think so. Otherwise you have the case where a time printed in 
one local timezone is interpreted differently in a program running in 
another time zone.


I'll also note that one can always do:

t.toISOExtString()[0..$-6];

If you know you don't want the time zone there.

-Steve


Re: Templates: Array slices not recognized

2015-04-20 Thread via Digitalmars-d-learn

On Monday, 20 April 2015 at 09:07:54 UTC, Chris wrote:

On Saturday, 18 April 2015 at 17:59:19 UTC, ketmar wrote:

On Sat, 18 Apr 2015 17:50:56 +, Chris wrote:

Doh! You're right! My bad. However, this makes the function 
less

generic, but it doesn't matter here.


maybe `auto ref` can help here?


Yes, auto ref does the trick. I prefer it to passing the slice 
by value, because I can extend the function to cater for more 
types. My implementation (which is different from the one 
posted above) works also with strings, for example. Anyway, it 
gave me a performance boost of ~2.7 times as compared to the 
workarounds I had. This was well worth it!


Strings are slices, too. `string` is equivalent to 
`immutable(char)[]`.


Re: Templates: Array slices not recognized

2015-04-20 Thread Chris via Digitalmars-d-learn

On Saturday, 18 April 2015 at 17:59:19 UTC, ketmar wrote:

On Sat, 18 Apr 2015 17:50:56 +, Chris wrote:

Doh! You're right! My bad. However, this makes the function 
less

generic, but it doesn't matter here.


maybe `auto ref` can help here?


Yes, auto ref does the trick. I prefer it to passing the slice by 
value, because I can extend the function to cater for more types. 
My implementation (which is different from the one posted above) 
works also with strings, for example. Anyway, it gave me a 
performance boost of ~2.7 times as compared to the workarounds I 
had. This was well worth it!


Re: Templates: Array slices not recognized

2015-04-20 Thread ketmar via Digitalmars-d-learn
On Mon, 20 Apr 2015 10:14:25 +, Chris wrote:

 string a = bla;
 string b = blub;
 
 auto res = doSomething(a, b);
 
 If I didn't use auto ref or ref, string would get copied, wouldn't
 it?

no, it wont -- not unless you'll append something to it. slicing arrays 
(and string is array too) will never copy anything.

signature.asc
Description: PGP signature


Re: Templates: Array slices not recognized

2015-04-20 Thread Chris via Digitalmars-d-learn

On Monday, 20 April 2015 at 09:58:06 UTC, Marc Schütz wrote:

On Monday, 20 April 2015 at 09:07:54 UTC, Chris wrote:

On Saturday, 18 April 2015 at 17:59:19 UTC, ketmar wrote:

On Sat, 18 Apr 2015 17:50:56 +, Chris wrote:

Doh! You're right! My bad. However, this makes the function 
less

generic, but it doesn't matter here.


maybe `auto ref` can help here?


Yes, auto ref does the trick. I prefer it to passing the slice 
by value, because I can extend the function to cater for more 
types. My implementation (which is different from the one 
posted above) works also with strings, for example. Anyway, it 
gave me a performance boost of ~2.7 times as compared to the 
workarounds I had. This was well worth it!


Strings are slices, too. `string` is equivalent to 
`immutable(char)[]`.


I know. My function returns an array of the same type (size_t[] 
or a string (immutable(char)[] or whatever). With auto ref I can 
pass a string without having to slice it, like so


string a = bla;
string b = blub;

auto res = doSomething(a, b);

If I didn't use auto ref or ref, string would get copied, 
wouldn't it?


auto ref doSomething(R needle, R haystack);

To avoid this, I would have to write a[0..$], b[0..$], which is 
not nice. Right or wrong?


For the record, I put the function inside a struct which again 
boosted the performance. No it is faster by a factor of ~3.17. 
Using the struct is even slightly faster than executing the same 
code directly within the for loop. That surprised me.


Re: Templates: Array slices not recognized

2015-04-20 Thread Chris via Digitalmars-d-learn

On Monday, 20 April 2015 at 10:27:00 UTC, anonymous wrote:

On Monday, 20 April 2015 at 10:14:27 UTC, Chris wrote:

string a = bla;
string b = blub;

auto res = doSomething(a, b);

If I didn't use auto ref or ref, string would get copied, 
wouldn't it?


auto ref doSomething(R needle, R haystack);

To avoid this, I would have to write a[0..$], b[0..$], which 
is not nice. Right or wrong?


Wrong. `a[0..$]` is the same as simply `a`. A `string` is just 
another slice: a pointer and a length.


Ah, I see. So strings don't get copied around and I can remove 
ref, very good.


Re: Input ranges

2015-04-20 Thread via Digitalmars-d-learn

On Sunday, 19 April 2015 at 23:49:08 UTC, anonymous wrote:

On Sunday, 19 April 2015 at 21:42:23 UTC, Ulrich Küttler wrote:
groupBy is a nice example as it laboriously adds reference 
semantics to forward ranges but assumes input ranges to posses 
reference semantics by themselves.


All ranges are input ranges, though. Input ranges are the least 
specialised category. I think it's a mistake to assume/require 
anything only for input ranges that are not forward ranges.


Yes and no. It is reasonable to provide special implementations 
for ranges that are just input ranges. This is what groupBy does. 
The user gets a function that works with all kinds of ranges.




I guess we could require reference semantics for all input 
ranges (including forward ranges and higher-ups). That would be 
a rather clean way out of this mess. But it would be a major 
effort. And I guess it would hurt performance, maybe a lot.


Definitely, general reference semantics would solve a ton of 
difficulty. However, this would not be D anymore.


This seems to be the catch: For optimal performance memory layout 
is important. You cannot hide it behind an interface.





At this point the solution in byLineCopy feels ad hoc.


I think byLineCopy solves a different problem. ByLine already 
has this:

https://github.com/D-Programming-Language/phobos/blob/v2.067.0/std/stdio.d#L1592-L1598


The same indirection in byLineCopy. This is what I was referring 
to:


https://github.com/D-Programming-Language/phobos/blob/v2.067.0/std/stdio.d#L1783-L1789

Whoever did that knew very well what is going on.


build vibe-d-0.7.23 error on win7 x86?

2015-04-20 Thread mzfhhhh via Digitalmars-d-learn

win 7 x86,3GB ram:

1. dmd 2.066 vibe-d-0.7.23, it's ok.

2. dmd 2.067 vibe-d-0.7.23,
   show error msg out of memory

why?


Re: Templates: Array slices not recognized

2015-04-20 Thread anonymous via Digitalmars-d-learn

On Monday, 20 April 2015 at 10:14:27 UTC, Chris wrote:

string a = bla;
string b = blub;

auto res = doSomething(a, b);

If I didn't use auto ref or ref, string would get copied, 
wouldn't it?


auto ref doSomething(R needle, R haystack);

To avoid this, I would have to write a[0..$], b[0..$], which is 
not nice. Right or wrong?


Wrong. `a[0..$]` is the same as simply `a`. A `string` is just 
another slice: a pointer and a length.


SysTime.toISOExtString with timezone offset

2015-04-20 Thread Jack Applegame via Digitalmars-d-learn
I need current system time ISO string with timezone offset. For 
example

2015-04-20T11:00:44.735441+03:00
but Clock.currTime.toISOExtString doesn't write offset:
2015-04-20T11:00:44.735441+03:00

I found workaround, but it looks redundant and needs memory 
allocation:


auto t = Clock.currTime;
t.timezone = new immutable SimpleTimeZone(t.utcOffset);
writeln(t.toISOExtString);

Is there a simple way to get time ISO string with timezone offset?


Re: SysTime.toISOExtString with timezone offset

2015-04-20 Thread Jonathan M Davis via Digitalmars-d-learn
On Monday, April 20, 2015 08:10:40 Jack Applegame via Digitalmars-d-learn wrote:
 I need current system time ISO string with timezone offset. For
 example
 2015-04-20T11:00:44.735441+03:00
 but Clock.currTime.toISOExtString doesn't write offset:
 2015-04-20T11:00:44.735441+03:00

 I found workaround, but it looks redundant and needs memory
 allocation:

 auto t = Clock.currTime;
 t.timezone = new immutable SimpleTimeZone(t.utcOffset);
 writeln(t.toISOExtString);

 Is there a simple way to get time ISO string with timezone offset?

The ISO standard requires that a lack of time zone in the string be treated
as local time, so SysTime, does not print the timezone offset as part of the
string for LocalTime (though the standard requires that the lack of timezone
be treated as local time, not that local time always be printed with no time
zone, so I suppose that the current behavior is not strictly-speaking
necessary). That being the case, you will have to use a different TimeZone
than LocalTime if you want an offset.

Doing toUTC().toISOExtString() will convert it to UTC, and you'll end up
with z for the offset, but obviously, the time will not be the same, since
it'll be adjusted to UTC. However, that's what I'd suggest that folks do in
most cases. And that won't allocate, since UTC is a singelton.

The only other alternative at present (other than adding the offset to the
string yourself) is to do like you're doing and allocate a SimpleTimeZone
(or if you know what your time zone is, use PosixTimeZone or
WindowsTimeZone).

Perhaps, LocalTime should be changed so that it prints the time zone out
(and just make it so that the lack of time zone is read in as local time
rather than treating it that way in both directions), but that's not how it
works currently.

- Jonathan M Davis



Re: Building website from git master, why does it checkout DMD v2.066.1 and die?

2015-04-20 Thread Gary Willoughby via Digitalmars-d-learn
On Sunday, 19 April 2015 at 21:26:11 UTC, Vladimir Panteleev 
wrote:

On Sunday, 19 April 2015 at 16:20:23 UTC, Gary Willoughby wrote:
If i pass the correct information on the command line it gets 
past the library errors but now shows linker errors.


I'm not seeing the compilation errors when building on the 
staging server, so not sure why you're getting them. I would 
suggest to try creating a new directory, cloning dlang.org into 
a subdirectory of that directory, and then running the build - 
posix.mak should fetch and build the remaining components.


And as for the link errors - this is on a Ubuntu (or 
Ubuntu-based) distribution, right? Here's my workaround:


https://issues.dlang.org/show_bug.cgi?id=12572#c5


Great thanks that cured the linking problem but there are still 
more errors during the build. I'm giving up for now as i only 
need the html but it's disappointing that it's so broken.


Re: Templates: Array slices not recognized

2015-04-20 Thread Chris via Digitalmars-d-learn

On Monday, 20 April 2015 at 10:42:54 UTC, Chris wrote:

On Monday, 20 April 2015 at 10:27:00 UTC, anonymous wrote:

On Monday, 20 April 2015 at 10:14:27 UTC, Chris wrote:

string a = bla;
string b = blub;

auto res = doSomething(a, b);

If I didn't use auto ref or ref, string would get copied, 
wouldn't it?


auto ref doSomething(R needle, R haystack);

To avoid this, I would have to write a[0..$], b[0..$], which 
is not nice. Right or wrong?


Wrong. `a[0..$]` is the same as simply `a`. A `string` is just 
another slice: a pointer and a length.


Ah, I see. So strings don't get copied around and I can remove 
ref, very good.


For the record. I mixed up the results there. The code executed 
directly in the for loop is faster than using a struct, it's also 
faster than using a mixin template (around 10 msecs). My 
apologies.


Re: Building website from git master, why does it checkout DMD v2.066.1 and die?

2015-04-20 Thread Jacob Carlborg via Digitalmars-d-learn

On 2015-04-20 12:42, Gary Willoughby wrote:


Great thanks that cured the linking problem but there are still more
errors during the build. I'm giving up for now as i only need the html
but it's disappointing that it's so broken.


Are your clones of DMD, druntime and Phobos up to date and clean?

--
/Jacob Carlborg


Re: CT-String as a Symbol

2015-04-20 Thread John Colvin via Digitalmars-d-learn

On Thursday, 16 April 2015 at 18:12:35 UTC, Nordlöw wrote:
Is there a way to CT-query the arity of all opIndex and opSlice 
overloads?


Ideally you don't want to have to do that. You'd have to consider 
alias this and inheritance.


Re: CT-String as a Symbol

2015-04-20 Thread ketmar via Digitalmars-d-learn
On Mon, 20 Apr 2015 13:31:03 +, Nordlöw wrote:

 On Thursday, 16 April 2015 at 18:12:35 UTC, Nordlöw wrote:
 Is there a way to CT-query the arity of all opIndex and opSlice
 overloads?
 
 Ping.

as long as they aren't templates, you can use any function traits on 'em. 
like `ParameterTypeTuple!(A.opIndex).length` for example.

with templated opXXX i believe that there is no simply way to get 
argument tuple.

signature.asc
Description: PGP signature


Re: Converting Java code to D

2015-04-20 Thread bearophile via Digitalmars-d-learn

John Colvin:


struct LineStyle
{
enum NONE = None;
enum SOLID = Solid;
enum DASH = Dash;
enum DOT = Dot;
enum DASHDOT = Dash Dot;
enum DASHDOTDOT = Dash Dot Dot;

string label;

private this(string label)
{
this.label = label;
}
}


The constructor doesn't look very useful.

Perhaps a named enum is safer.

Bye,
bearophile


Re: Weird link error

2015-04-20 Thread anonymous via Digitalmars-d-learn

On Monday, 20 April 2015 at 17:02:18 UTC, CodeSun wrote:
I have test a snippet of code, and I encountered with a weird 
link error.

The following is the demo:

import std.stdio;
interface Ti {
T get(T)(int num);
T get(T)(string str);
}

class Test : Ti {
T get(T)(int num) {
writeln(ok);
}
T get(T)(string str) {
writeln(str);
}
}
void main() {
Ti tt = new Test;
tt.get!string(test);
tt.get!string(123);
}


When I use dmd to compile this code snippet, the following link 
error was reported:
tt.d:(.text._Dmain+0x3b):‘_D2tt2Ti12__T3getTAyaZ3getMFAyaZAya’ 
undefined reference
tt.d:(.text._Dmain+0x49):‘_D2tt2Ti12__T3getTAyaZ3getMFiZAya’undefined 
reference


And if I modigy the code to
Test tt = new Test;

then this code will work.


Template methods are non-virtual. That is, you can't override 
them.


So does it mean I can't declare function template inside 
interface? If so, why didn't dmd report the error while 
compiling instead of linking?


You can theoretically implement them elsewhere. For example, this 
works:



module test;

interface Ti {
T get(T)(int num);
T get(T)(string str);
}

pragma(mangle, _D4test2Ti12__T3getTAyaZ3getMFiZAya) string 
impl(int)

{
return foo;
}
pragma(mangle, _D4test2Ti12__T3getTAyaZ3getMFAyaZAya) string 
impl(string)

{
return bar;
}

class Test : Ti {}

void main() {
Ti tt = new Test;
tt.get!string(test);
tt.get!string(123);
}


It's really silly, though. I don't know if there's a more 
realistic use case.


And where I can find the D symbol definition, because 
information like ‘_D2tt2Ti12__T3getTAyaZ3getMFAyaZAya’ makes me 
really confused.


That's a mangled name. There's a tool called ddemangle. It comes 
with the D releases. You can pipe the compiler output through it 
to get more readable symbol names (don't forget to redirect 
stderr to stdout). For this one it gives gives you 
immutable(char)[] 
tt.Ti.get!(immutable(char)[]).get(immutable(char)[]).


Re: Converting Java code to D

2015-04-20 Thread Russel Winder via Digitalmars-d-learn
On Mon, 2015-04-20 at 17:28 +, John Colvin via Digitalmars-d-learn wrote:
 […]
 
 True, the constructor doesn't really add anything here.
 
 To be honest, the combination of enumeration and runtime 
 variables in the Java code seems like a rubbish design, but 
 perhaps there's a good reason for it that I'm not aware of.

It's Type Safe Enum from Java and C++:

http://docs.oracle.com/javase/8/docs/technotes/guides/language/enums.ht
ml
http://www.javapractices.com/topic/TopicAction.do?Id=1
http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Type_Safe_Enum

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder




signature.asc
Description: This is a digitally signed message part


Re: Converting Java code to D

2015-04-20 Thread Steven Schveighoffer via Digitalmars-d-learn

On 4/20/15 11:28 AM, Mike James wrote:

Here is a fragment of Java code from an SWT program...

public enum LineStyle {
 NONE(None),
 SOLID(Solid),
 DASH(Dash),
 DOT(Dot),
 DASHDOT(Dash Dot),
 DASHDOTDOT(Dash Dot Dot);

 public final String label;

 private LineStyle(String label) {
 this.label = label;
 }
}

What would be the best ('canonical') way of translating it to D?


enum LineStyle : string {
   NONE = None,
   SOLID = Solid,
   ... // etc
}

Used like this:

funcThatTakesString(LineStyle.NONE);

LineStyle ls = LineStyle.SOLID;

funcThatTakesLineStyle(ls);

I'm not a Java programmer, and my time with Java was before enums. But 
this is how I would do it.


-Steve


Re: Converting Java code to D

2015-04-20 Thread John Colvin via Digitalmars-d-learn

On Monday, 20 April 2015 at 17:24:30 UTC, bearophile wrote:

John Colvin:


struct LineStyle
{
   enum NONE = None;
   enum SOLID = Solid;
   enum DASH = Dash;
   enum DOT = Dot;
   enum DASHDOT = Dash Dot;
   enum DASHDOTDOT = Dash Dot Dot;

   string label;

   private this(string label)
   {
   this.label = label;
   }
}


The constructor doesn't look very useful.

Perhaps a named enum is safer.

Bye,
bearophile


True, the constructor doesn't really add anything here.

To be honest, the combination of enumeration and runtime 
variables in the Java code seems like a rubbish design, but 
perhaps there's a good reason for it that I'm not aware of.


Re: Valgrind

2015-04-20 Thread John Colvin via Digitalmars-d-learn

On Monday, 20 April 2015 at 16:58:18 UTC, Robert M. Münch wrote:

On 2015-04-20 13:29:57 +, John Colvin said:


On Monday, 20 April 2015 at 13:28:57 UTC, John Colvin wrote:
On Monday, 20 April 2015 at 13:16:23 UTC, Robert M. Münch 
wrote:
Hi, I just found quite old posts about Valgrind and D. Can 
someone give me a short update, what the state of support 
for D is and if there is anythings special to take into 
account. Thanks a lot.


The only special thing to take in to account is that valgrind 
will choke on DMD generated floating point code, so really 
you have to use GDC or LDC if you want to use valgrind.


Correction: The only special thing I know of.


Ok, thanks.

Were the causes ever analyzed? I'm a bit wondering why it 
happens on floating point stuff...


valgrind doesn't have full support for x87 code, which dmd emits 
all over the place.


Re: ctags

2015-04-20 Thread Justin Whear via Digitalmars-d-learn
On Mon, 20 Apr 2015 20:14:34 +0200, Robert M. Münch wrote:

 Hi, is there anything for D that supports generating tags files like
 ctags does for C etc. ?

Dscanner: https://github.com/Hackerpilot/Dscanner#ctags-output


Converting Java code to D

2015-04-20 Thread Mike James via Digitalmars-d-learn

Here is a fragment of Java code from an SWT program...

public enum LineStyle {
NONE(None),
SOLID(Solid),
DASH(Dash),
DOT(Dot),
DASHDOT(Dash Dot),
DASHDOTDOT(Dash Dot Dot);

public final String label;

private LineStyle(String label) {
this.label = label;
}
}

What would be the best ('canonical') way of translating it to D?

Regards,

-=mike=-


Re: Converting Java code to D

2015-04-20 Thread Mike James via Digitalmars-d-learn

On Monday, 20 April 2015 at 17:28:27 UTC, John Colvin wrote:

On Monday, 20 April 2015 at 17:24:30 UTC, bearophile wrote:

John Colvin:


struct LineStyle
{
  enum NONE = None;
  enum SOLID = Solid;
  enum DASH = Dash;
  enum DOT = Dot;
  enum DASHDOT = Dash Dot;
  enum DASHDOTDOT = Dash Dot Dot;

  string label;

  private this(string label)
  {
  this.label = label;
  }
}


The constructor doesn't look very useful.

Perhaps a named enum is safer.

Bye,
bearophile


True, the constructor doesn't really add anything here.

To be honest, the combination of enumeration and runtime 
variables in the Java code seems like a rubbish design, but 
perhaps there's a good reason for it that I'm not aware of.


Maybe they extended enum to get over the lack of structs.

Looking at the spec for java enums it appears that you can return
an enumeration or the associated string using the original code.

Regards, -=mike=-


Re: Weird link error

2015-04-20 Thread Baz via Digitalmars-d-learn

On Monday, 20 April 2015 at 17:02:18 UTC, CodeSun wrote:


And where I can find the D symbol definition, because 
information like ‘_D2tt2Ti12__T3getTAyaZ3getMFAyaZAya’ makes me 
really confused.


---
import std.demangle;
auto friendlySymbol = 
demangle(_D2tt2Ti12__T3getTAyaZ3getMFAyaZAya);

---



ctags

2015-04-20 Thread Robert M. Münch via Digitalmars-d-learn
Hi, is there anything for D that supports generating tags files like 
ctags does for C etc. ?


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



Re: Valgrind

2015-04-20 Thread Robert M. Münch via Digitalmars-d-learn

On 2015-04-20 13:29:57 +, John Colvin said:


On Monday, 20 April 2015 at 13:28:57 UTC, John Colvin wrote:

On Monday, 20 April 2015 at 13:16:23 UTC, Robert M. Münch wrote:
Hi, I just found quite old posts about Valgrind and D. Can someone give 
me a short update, what the state of support for D is and if there is 
anythings special to take into account. Thanks a lot.


The only special thing to take in to account is that valgrind will 
choke on DMD generated floating point code, so really you have to use 
GDC or LDC if you want to use valgrind.


Correction: The only special thing I know of.


Ok, thanks.

Were the causes ever analyzed? I'm a bit wondering why it happens on 
floating point stuff...


--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster



Re: Weird link error

2015-04-20 Thread Adam D. Ruppe via Digitalmars-d-learn

On Monday, 20 April 2015 at 17:02:18 UTC, CodeSun wrote:
So does it mean I can't declare function template inside 
interface?


You can, but they are considered final so a body is required to 
use them - they aren't just a pointer to the derived 
implementation.


Re: Formatted output ranges

2015-04-20 Thread Ivan Kazmenko via Digitalmars-d-learn
Yes, it's a lot better but I did not get to concatenate the 
string ;; in each paragraph:


-
import std.conv, std.stdio, std.range, std.string;

void main() {

auto a = iota(10, 1101).text;

a = a[1 .. $ - 1], a ~= '.';

writeln(wrap(a, 30));
}
-
http://ideone.com/jsSbKj


writeln(wrap(a, 30, ;; , ;; ));

Works with dmd 2.066.1 and 2.067.0.


Weird link error

2015-04-20 Thread CodeSun via Digitalmars-d-learn
I have test a snippet of code, and I encountered with a weird 
link error.

The following is the demo:

import std.stdio;
interface Ti {
T get(T)(int num);
T get(T)(string str);
}

class Test : Ti {
T get(T)(int num) {
writeln(ok);
}
T get(T)(string str) {
writeln(str);
}
}
void main() {
Ti tt = new Test;
tt.get!string(test);
tt.get!string(123);
}


When I use dmd to compile this code snippet, the following link 
error was reported:
tt.d:(.text._Dmain+0x3b):‘_D2tt2Ti12__T3getTAyaZ3getMFAyaZAya’ 
undefined reference
tt.d:(.text._Dmain+0x49):‘_D2tt2Ti12__T3getTAyaZ3getMFiZAya’undefined 
reference


And if I modigy the code to
Test tt = new Test;

then this code will work.

So does it mean I can't declare function template inside 
interface? If so, why didn't dmd report the error while compiling 
instead of linking?


And where I can find the D symbol definition, because information 
like ‘_D2tt2Ti12__T3getTAyaZ3getMFAyaZAya’ makes me really 
confused.


Re: Converting Java code to D

2015-04-20 Thread John Colvin via Digitalmars-d-learn

On Monday, 20 April 2015 at 15:28:04 UTC, Mike James wrote:

Here is a fragment of Java code from an SWT program...

public enum LineStyle {
NONE(None),
SOLID(Solid),
DASH(Dash),
DOT(Dot),
DASHDOT(Dash Dot),
DASHDOTDOT(Dash Dot Dot);

public final String label;

private LineStyle(String label) {
this.label = label;
}
}

What would be the best ('canonical') way of translating it to D?

Regards,

-=mike=-


I'm not too hot at Java, but I'm pretty sure this gives you what 
you want. Perhaps immutable instead of enum would be closer 
to what Java does with enum members, but I don't know.


struct LineStyle
{
enum NONE = None;
enum SOLID = Solid;
enum DASH = Dash;
enum DOT = Dot;
enum DASHDOT = Dash Dot;
enum DASHDOTDOT = Dash Dot Dot;

string label;

private this(string label)
{
this.label = label;
}
}


Re: User defined properties signatures

2015-04-20 Thread Jonathan M Davis via Digitalmars-d-learn
On Monday, April 20, 2015 18:35:34 dvic via Digitalmars-d-learn wrote:
 Hi guys,

 It seems it's possible to define different read properties, only
 differing by the return type.

Not possible. Just like pretty much any C-derived language (C++, Java, C#,
etc.) the return type of a function is not considered in function
overloading, and it is illegal to overload a function based on its return
type.

 Why is the compiler not complaining about defining 2 read
 properties and it does
 otherwise when using both of them?

Now, that is weird. I would fully expect something like

struct S
{
@property int foo() { return 7; }
@property string foo() { return foo; }
}

to result in an error, but for some reason, it doesn't (and it doesn't seem
to have anything to do with the fact that it's a property function). I have
no idea why and would be inclined to argue that it's a compiler bug (though
a compiler dev may be able to come up with a good reason for why it's acting
the way it is). However, since it _is_ failing to compile as soon as you use
the function, the only real problem is that if you declare a function
without ever testing it, you risk having a duplicate function without
knowing it.  But still, I really think that the compiler should be giving an
error message even if you don't call it.

- Jonathan M Davis



Re: User defined properties signatures

2015-04-20 Thread Ali Çehreli via Digitalmars-d-learn

On 04/20/2015 11:35 AM, dvic wrote:

 @property string value() { return m_value; } // m_value is a string
 @property int value() { return to!int(m_value); }

Yes, as Jonathan M Davis said, that's weird.

 But when using it in writefln() or assert for example, compiler (dmd)
 complains
 about 2 different property signatures.

 What I'd like to have is this:

 MyObject.value = 12345; // write property always setting a string

 assert(MyObject.value == 12345);  // depending on the context, call
 1st prop
 assert(MyObject.value == 12345);  // depending on the context, call 2nd
 prop

I think that would work if multiple 'alias this' were allowed. (There is 
a pull request that does not pass some tests; that's why it is not 
included in 2.067.)


struct S
{
int int_value() { /* ... */ }
string string_value() { /* ... */ }

alias int_value this;
alias string_value this;

// ...
}

The matching function would be called depending on whether S is used in 
place of an int or a string.


Ali



User defined properties signatures

2015-04-20 Thread dvic via Digitalmars-d-learn

Hi guys,

It seems it's possible to define different read properties, only
differing by the return type.

Ex:

@property string value() { return m_value; } // m_value is a 
string

@property int value() { return to!int(m_value); }

But when using it in writefln() or assert for example, compiler 
(dmd) complains

about 2 different property signatures.

What I'd like to have is this:

MyObject.value = 12345; // write property always setting a 
string


assert(MyObject.value == 12345);  // depending on the context, 
call 1st prop
assert(MyObject.value == 12345);  // depending on the context, 
call 2nd prop


Why is the compiler not complaining about defining 2 read 
properties and it does

otherwise when using both of them?

Any clue?

Thanks a lot.



Re: Reuse object memory?

2015-04-20 Thread Namespace via Digitalmars-d-learn

On Sunday, 19 April 2015 at 21:17:18 UTC, Ali Çehreli wrote:

On 04/19/2015 09:04 AM, Namespace wrote:

 Is it somehow possible to reuse the memory of an object?

Yes, when you cast a class variable to void*, you get the 
address of the object.


 @nogc
 T emplace(T, Args...)(ref T obj, auto ref Args args) nothrow
if (is(T ==
 class)) {

There is already std.conv.emplace:

import std.conv;
import core.memory;

class Foo
{
int i;

this(int i)
{
this.i = i;
}
}

void main()
{
void* buffer = GC.calloc(1234);

enum FooSize = __traits(classInstanceSize, Foo);

/* These two object are constructed on a void[] slice: */
auto f = emplace!Foo(buffer[0..FooSize], 42);
auto f2 = emplace!Foo(buffer[0..FooSize], 43);

/* f3 is constructed on top of an existing object: */
auto f2_addr = cast(void*)f2;
auto f3 = emplace!Foo(f2_addr[0..FooSize], 44);

/* At this point, all three reference the same object: */
assert(f.i == f2.i);
assert(f.i == f3.i);
}

Ali


I'm sorry if I annoy you, but I would really like to know how you 
would reuse already instantiated storage of an existing object.


Example code:

final class Foo {
uint id;

@nogc
this(uint id) {
this.id = id;
}
}

Foo f = new Foo(42);



Re: User defined properties signatures

2015-04-20 Thread dvic via Digitalmars-d-learn

On Monday, 20 April 2015 at 18:50:31 UTC, Jonathan M Davis wrote:
On Monday, April 20, 2015 18:35:34 dvic via Digitalmars-d-learn 
wrote:

Hi guys,

It seems it's possible to define different read properties, 
only

differing by the return type.


Not possible. Just like pretty much any C-derived language 
(C++, Java, C#,
etc.) the return type of a function is not considered in 
function
overloading, and it is illegal to overload a function based on 
its return

type.


Why is the compiler not complaining about defining 2 read
properties and it does
otherwise when using both of them?


Now, that is weird. I would fully expect something like

struct S
{
@property int foo() { return 7; }
@property string foo() { return foo; }
}

to result in an error, but for some reason, it doesn't (and it 
doesn't seem
to have anything to do with the fact that it's a property 
function). I have
no idea why and would be inclined to argue that it's a compiler 
bug (though
a compiler dev may be able to come up with a good reason for 
why it's acting
the way it is). However, since it _is_ failing to compile as 
soon as you use
the function, the only real problem is that if you declare a 
function
without ever testing it, you risk having a duplicate function 
without
knowing it.  But still, I really think that the compiler should 
be giving an

error message even if you don't call it.

- Jonathan M Davis



Thanks for your answer Jonathan. But does the return type part of 
a method
signature? I don't know what theory is claiming about that, but 
for me they
are 2 different methods. So contextually, the best fit should 
prevail.


Re: User defined properties signatures

2015-04-20 Thread Steven Schveighoffer via Digitalmars-d-learn

On 4/20/15 2:50 PM, Jonathan M Davis via Digitalmars-d-learn wrote:

On Monday, April 20, 2015 18:35:34 dvic via Digitalmars-d-learn wrote:



Why is the compiler not complaining about defining 2 read
properties and it does
otherwise when using both of them?


Now, that is weird. I would fully expect something like

struct S
{
 @property int foo() { return 7; }
 @property string foo() { return foo; }
}

to result in an error, but for some reason, it doesn't (and it doesn't seem
to have anything to do with the fact that it's a property function).


There's an open bugzilla on this: 
https://issues.dlang.org/show_bug.cgi?id=2789


-Steve


Re: ctags

2015-04-20 Thread Gary Willoughby via Digitalmars-d-learn

On Monday, 20 April 2015 at 18:14:34 UTC, Robert M. Münch wrote:
Hi, is there anything for D that supports generating tags files 
like ctags does for C etc. ?


I and some others have merged D support into the following fork 
of exuberant-ctags:


https://github.com/fishman/ctags

This is the most up to date ctags repository I've found so far 
and it's D support constantly being updated.


Re: readText for large files on Windows.

2015-04-20 Thread Kenny via Digitalmars-d-learn

Thanks. The bug is created.
https://issues.dlang.org/show_bug.cgi?id=14469


Re: Iterate over enum

2015-04-20 Thread via Digitalmars-d-learn

On Saturday, 18 April 2015 at 21:11:28 UTC, HaraldZealot wrote:

On Saturday, 18 April 2015 at 20:42:09 UTC, Ali Çehreli wrote:

On 04/18/2015 01:30 PM, HaraldZealot wrote:
Is it possible iterate over enum (preferable in compile time) 
or at

least check that particular value belong to enum?


EnumMembers:

 http://dlang.org/phobos/std_traits.html#EnumMembers

It returns a static tuple, meaning that a foreach over those 
members will be a compile-time foreach. (No loop at all at 
run-time, the body is unrolled for every member.)


Ali


Many thanks


If you want a dynamic version use

[EnumMembers!T]

or without enumerator aliases (enumerator value duplicate)

import std.traits: EnumMembers;
import std.algorithm: sort, uniq;
return [EnumMembers!T].sort().uniq;

I've turned this into enumMembers at

https://github.com/nordlow/justd/blob/master/traits_ex.d#L396

This prevents the foreach loop from being inlined. I've had 
problems with compilation performance with nested 
foreach-iterating over EnumMembers!T with 100s of elements.