Re: Parameterized enum does not work
On Friday, 9 January 2015 at 07:52:50 UTC, Daniel Kozak wrote:
On Friday, 9 January 2015 at 07:50:53 UTC, Daniel Kozak wrote:
On Friday, 9 January 2015 at 06:17:53 UTC, Andre wrote:
Hi,
Should following coding work?
string lpad(ubyte length, long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
enum lpad14(long n) = lpad(14, n);
void main()
{
lpad14(123);
}
There is following error from dmd:
source\app.d(12): Error: template app.lpad14 cannot deduce
function from argumen
t types !()(int), candidates are:
source\app.d(8):app.lpad14(long n)
Kind regards
André
What are you trying to do?
OK I probably see it now :):
import std.stdio;
string lpad(ubyte length, long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
enum lpad14(long n) = lpad(14, n);
void main()
{
writeln(lpad14!(123));
}
However this is only for compile time, if you want runtime
version you need something like this:
import std.stdio;
string lpad(ubyte length)(long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
alias lpad14 = lpad!14;
void main()
{
writeln(lpad14(123));
}
Re: Parameterized enum does not work
Thanks a lot.
Kind regards
André
On Friday, 9 January 2015 at 07:59:51 UTC, Daniel Kozak wrote:
On Friday, 9 January 2015 at 07:52:50 UTC, Daniel Kozak wrote:
On Friday, 9 January 2015 at 07:50:53 UTC, Daniel Kozak wrote:
On Friday, 9 January 2015 at 06:17:53 UTC, Andre wrote:
Hi,
Should following coding work?
string lpad(ubyte length, long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
enum lpad14(long n) = lpad(14, n);
void main()
{
lpad14(123);
}
There is following error from dmd:
source\app.d(12): Error: template app.lpad14 cannot deduce
function from argumen
t types !()(int), candidates are:
source\app.d(8):app.lpad14(long n)
Kind regards
André
What are you trying to do?
OK I probably see it now :):
import std.stdio;
string lpad(ubyte length, long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
enum lpad14(long n) = lpad(14, n);
void main()
{
writeln(lpad14!(123));
}
However this is only for compile time, if you want runtime
version you need something like this:
import std.stdio;
string lpad(ubyte length)(long n)
{
import std.string: rightJustify;
import std.conv: to;
return rightJustify(to!string(n), length, '0');
}
alias lpad14 = lpad!14;
void main()
{
writeln(lpad14(123));
}
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
iday, 9 January 2015 at 07:41:07 UTC, ketmar via
Digitalmars-d-learn wrote:
On Fri, 09 Jan 2015 07:10:14 +
FrankLike via Digitalmars-d-learn
wrote:
On Thursday, 8 January 2015 at 15:15:59 UTC, Robert burner
Schadek wrote:
>
> use canFind like such:
> bool a = canFind(strs,s) >= 1;
>
> let the compiler figger out what the types of the parameter
> are.
canFind is work for such as :
bool x = canFind(["exe","lib","a","dll"],"a" );
but can't work for
canFind(["exe","lib","a","dll"],"hello.lib");
So I very want to let the function 'indexOfAny' do the same
work.
Thank you.
Frank
be creative! ;-)
import std.algorithm, std.stdio;
void main () {
string fname = "hello.exe";
import std.path : extension;
if (findAmong([fname.extension], [".exe", ".lib", ".a",
".dll"]).length) {
writeln("got it!");
} else {
writeln("alas...");
}
}
note the dots in extension list.
yet you can do it even easier:
import std.algorithm, std.stdio;
void main () {
string fname = "hello.exe";
import std.path : extension;
if ([".exe", ".lib", ".a",
".dll"].canFind(fname.extension)) {
writeln("got it!");
} else {
writeln("alas...");
}
}
as you obviously interested in extension here -- check only that
part! ;-)
Sorry,it's only a example .Thank you work hard,but it's
not what I want.
'indexOfAny ' function should do this work.
”he is at home" ,["home","office",”sea","plane"], in
C#,IndexOfAny can do it,what about in D?
I know findAmong can do it,but use two function .
Thank you.
Re: Fastest Way of Accessing Entries in an AA
On Friday, January 09, 2015 07:51:27 Foo via Digitalmars-d-learn wrote:
> On Friday, 9 January 2015 at 06:18:53 UTC, Jonathan M Davis via
> Digitalmars-d-learn wrote:
> > On Friday, January 09, 2015 00:20:07 Foo via
> > Digitalmars-d-learn wrote:
> >> You know, that you kan reuse the result of the in operator by
> >> AAs?
> >>
> >> example:
> >>
> >> auto ptr = key in aa;
> >> ptr ? *ptr : ValueType.init
> >
> > This idiom is quite common:
> >
> > if(auto ptrToValue = key in aa)
> > {
> > }
> >
> > though I'm not sure that that quite fits in with what Nordlow
> > seems to be
> > trying to do with init. aa.get probably does a better job of
> > that, though
> > looking at the implementation for get, it's basically doing
> > what you're
> > suggesting:
> >
> > auto p = key in aa;
> > return p ? *p : defaultValue;
> >
> > though that has the downside of using a lazy parameter for the
> > default
> > value, which is convenient but doesn't do great things for
> > performance.
> >
> > - Jonathan M Davis
> I just wasn't sure that he knows about it.
Oh, he might not have known about it (certainly, the fact that he called in
and then [] in his origanal code implies that he didn't), and it was
definitely useful to tell him. My point was simply that get applies better
for his use case than using in directly. In general though, in is of _far_
more use than [], precisely because it combines asking whether the element
is there and getting it into one command. Personally, I pretty much never
use [] on AAs.
- Jonathan M Davis
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Fri, 09 Jan 2015 09:36:01 +
FrankLike via Digitalmars-d-learn
wrote:
> Sorry,it's only a example .Thank you work hard,but it's
> not what I want.
> 'indexOfAny ' function should do this work.
> ”he is at home" ,["home","office",”sea","plane"], in
> C#,IndexOfAny can do it,what about in D?
> I know findAmong can do it,but use two function .
> Thank you.
be creative! ;-)
import std.algorithm, std.stdio;
void main () {
string s = "he is at plane";
if (findAmong!((string a, string b) => b.canFind(a))([s], ["home",
"office", "sea", "plane"]).length) {
writeln("got it!");
} else {
writeln("alas...");
}
}
or:
import std.algorithm, std.stdio;
void main () {
string s = "he is at home";
if (["home", "office", "sea", "plane"].canFind!((a, string b) =>
b.canFind(a))(s)) {
writeln("got it!");
} else {
writeln("alas...");
}
}
signature.asc
Description: PGP signature
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
be creative! ;-)
import std.algorithm, std.stdio;
void main () {
string s = "he is at plane";
if (findAmong!((string a, string b) => b.canFind(a))([s],
["home", "office", "sea", "plane"]).length) {
writeln("got it!");
} else {
writeln("alas...");
}
}
or:
import std.algorithm, std.stdio;
void main () {
string s = "he is at home";
if (["home", "office", "sea", "plane"].canFind!((a, string
b) => b.canFind(a))(s)) {
writeln("got it!");
} else {
writeln("alas...");
}
}
The code is the best,and it's better than indexOfAny in C#:
import std.algorithm, std.stdio;
void main ()
{
auto places = [ "home", "office", "sea","plane"];
auto strWhere = "He is in the sea.";
auto where = places.canFind!(a => strWhere.canFind(a));
writeln("Result is ",where);
}
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Fri, 09 Jan 2015 12:46:53 +
FrankLike via Digitalmars-d-learn
wrote:
> The code is the best,and it's better than indexOfAny in C#:
>
> import std.algorithm, std.stdio;
> void main ()
> {
> auto places = [ "home", "office", "sea","plane"];
> auto strWhere = "He is in the sea.";
> auto where = places.canFind!(a => strWhere.canFind(a));
> writeln("Result is ",where);
> }
this does unnecessary upvalue access (`strWhere`). try to avoid such
stuff whenever it is possible.
signature.asc
Description: PGP signature
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Friday, 9 January 2015 at 10:02:53 UTC, ketmar via
Digitalmars-d-learn wrote:
import std.algorithm, std.stdio;
void main () {
string s = "he is at home";
if (["home", "office", "sea", "plane"].canFind!((a, string
b) => b.canFind(a))(s)) {
writeln("got it!");
} else {
writeln("alas...");
}
}
Thank you.
The code is the best,and it's better than indexOfAny in C#:
/* places.canFind!(a => strWhere.canFind(a)); */
By auto r = benchmark!(f0,f1, f2, f3,f4)(10_);
Result is :
filter is 42ms 85us
findAmong is 37ms 268us
foreach indexOf is 37ms 841us
canFind is 13ms
canFind indexOf is 39ms 455us
---5 functions--
import std.stdio, std.algorithm,std.string;
auto places = [ "home", "office", "sea","plane"];
auto strWhere = "He is in the sea.";
void main()
{
auto where = places.filter!(a => strWhere.indexOf(a) != -1);
writeln("0 Result is ",where);
auto where1 = findAmong(places,strWhere);
writeln("1 Result is ",where1);
string where2;
foreach(a;places)
{
if(strWhere.indexOf(a) !=-1)
{
where2 = a;
break;
}
}
writeln("2 Result is ",where2);
auto where3 = places.canFind!(a => strWhere.canFind(a));
writeln("3 Result is ",where3);
auto where4 = places.canFind!(a => strWhere.indexOf(a) != -1);
writeln("4 Result is ",where4);
}
Frank
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Fri, 09 Jan 2015 13:06:09 +
FrankLike via Digitalmars-d-learn
wrote:
> On Friday, 9 January 2015 at 10:02:53 UTC, ketmar via
> Digitalmars-d-learn wrote:
>
> > import std.algorithm, std.stdio;
> >
> > void main () {
> > string s = "he is at home";
> > if (["home", "office", "sea", "plane"].canFind!((a, string
> > b) => b.canFind(a))(s)) {
> > writeln("got it!");
> > } else {
> > writeln("alas...");
> > }
> > }
>
> Thank you.
>
> The code is the best,and it's better than indexOfAny in C#:
>
> /* places.canFind!(a => strWhere.canFind(a)); */
>
> By auto r = benchmark!(f0,f1, f2, f3,f4)(10_);
>
> Result is :
> filter is 42ms 85us
> findAmong is 37ms 268us
> foreach indexOf is 37ms 841us
> canFind is 13ms
> canFind indexOf is 39ms 455us
>
> ---5 functions--
> import std.stdio, std.algorithm,std.string;
>
> auto places = [ "home", "office", "sea","plane"];
> auto strWhere = "He is in the sea.";
>
> void main()
> {
>auto where = places.filter!(a => strWhere.indexOf(a) != -1);
> writeln("0 Result is ",where);
>
> auto where1 = findAmong(places,strWhere);
> writeln("1 Result is ",where1);
>
> string where2;
> foreach(a;places)
> {
> if(strWhere.indexOf(a) !=-1)
> {
> where2 = a;
>break;
> }
> }
> writeln("2 Result is ",where2);
>
> auto where3 = places.canFind!(a => strWhere.canFind(a));
> writeln("3 Result is ",where3);
>
> auto where4 = places.canFind!(a => strWhere.indexOf(a) != -1);
> writeln("4 Result is ",where4);
> }
>
> Frank
if you *really* concerned with speed here, you'd better consider using
regular expressions. as regular expression can be precompiled and then
search for multiple words with only one pass over the source string. i
believe that std.regex will use variation of Thomson algorithm for
regular expressions when it is able to do so.
signature.asc
Description: PGP signature
For those ready to take the challenge
https://codegolf.stackexchange.com/questions/44278/debunking-stroustrups-debunking-of-the-myth-c-is-for-large-complicated-pro
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Friday, 9 January 2015 at 13:25:17 UTC, ketmar via Digitalmars-d-learn wrote: if you *really* concerned with speed here, you'd better consider using regular expressions. as regular expression can be precompiled and then search for multiple words with only one pass over the source string. i believe that std.regex will use variation of Thomson algorithm for regular expressions when it is able to do so. IMO that is not sound advice. Creating the state machine and running will be more costly than using canFind or indexOf how basically only compare char by char. If speed is really need use strstr and look if it uses sse to compare multiple chars at a time. Anyway benchmark and then benchmark some more.
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Fri, 09 Jan 2015 13:54:00 + Robert burner Schadek via Digitalmars-d-learn wrote: > On Friday, 9 January 2015 at 13:25:17 UTC, ketmar via > Digitalmars-d-learn wrote: > > if you *really* concerned with speed here, you'd better > > consider using > > regular expressions. as regular expression can be precompiled > > and then > > search for multiple words with only one pass over the source > > string. i > > believe that std.regex will use variation of Thomson algorithm > > for > > regular expressions when it is able to do so. > > IMO that is not sound advice. Creating the state machine and > running will be more costly than using canFind or indexOf how > basically only compare char by char. > > If speed is really need use strstr and look if it uses sse to > compare multiple chars at a time. Anyway benchmark and then > benchmark some more. std.regex can use CTFE to compile regular expressions (yet it sometimes slower than non-CTFE variant), and i mean that we compile regexp before doing alot of searches, not before each single search. if you have alot of words to match or alot of strings to check, regexp can give a huge boost. sure, it all depends of code patterns. signature.asc Description: PGP signature
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Friday, 9 January 2015 at 14:03:21 UTC, ketmar via Digitalmars-d-learn wrote: std.regex can use CTFE to compile regular expressions (yet it sometimes slower than non-CTFE variant), and i mean that we compile regexp before doing alot of searches, not before each single search. if you have alot of words to match or alot of strings to check, regexp can give a huge boost. sure, it all depends of code patterns. even with CTFE regex still uses a state machine _mm256_cmpeq_epi8 will beat that even for multiple strings. Basically all lexer are handwritten, if regex where fast enough nobody would do the work.
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Fri, 09 Jan 2015 14:11:49 + Robert burner Schadek via Digitalmars-d-learn wrote: > On Friday, 9 January 2015 at 14:03:21 UTC, ketmar via > Digitalmars-d-learn wrote: > > > std.regex can use CTFE to compile regular expressions (yet it > > sometimes > > slower than non-CTFE variant), and i mean that we compile > > regexp before > > doing alot of searches, not before each single search. if you > > have alot > > of words to match or alot of strings to check, regexp can give > > a huge > > boost. > > > > sure, it all depends of code patterns. > > even with CTFE regex still uses a state machine _mm256_cmpeq_epi8 > will beat that even for multiple strings. Basically all lexer are > handwritten, if regex where fast enough nobody would do the work. heh. regexps *are* fast enough. it's hard to beat well-optimised generated thingy on a complex grammar. ;-) signature.asc Description: PGP signature
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Friday, 9 January 2015 at 14:21:04 UTC, ketmar via Digitalmars-d-learn wrote: heh. regexps *are* fast enough. it's hard to beat well-optimised generated thingy on a complex grammar. ;-) I don't see your point, anyway I think he got his help or at least some help.
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Friday, 9 January 2015 at 14:03:21 UTC, ketmar via
Digitalmars-d-learn wrote:
On Fri, 09 Jan 2015 13:54:00 +
Robert burner Schadek via Digitalmars-d-learn
wrote:
On Friday, 9 January 2015 at 13:25:17 UTC, ketmar via
Digitalmars-d-learn wrote:
> if you *really* concerned with speed here, you'd better
> consider using
> regular expressions. as regular expression can be
> precompiled and then
> search for multiple words with only one pass over the source
> string. i
> believe that std.regex will use variation of Thomson
> algorithm for
> regular expressions when it is able to do so.
IMO that is not sound advice. Creating the state machine and
running will be more costly than using canFind or indexOf how
basically only compare char by char.
If speed is really need use strstr and look if it uses sse to
compare multiple chars at a time. Anyway benchmark and then
benchmark some more.
std.regex can use CTFE to compile regular expressions (yet it
sometimes
slower than non-CTFE variant), and i mean that we compile
regexp before
doing alot of searches, not before each single search. if you
have alot
of words to match or alot of strings to check, regexp can give
a huge
boost.
sure, it all depends of code patterns.
import std.regex;
auto ctr = ctRegex!(`(home|office|sea|plane)`);
auto c2 = !matchFirst("He is in the sea.", ctr).empty;
--
Test by auto r = benchmark!(f0,f1, f2, f3,f4,f5)(10_);
Result is :
filter is 42ms 85us
findAmong is 37ms 268us
foreach indexOf is 37ms 841us
canFind is 13ms
canFind indexOf is 39ms 455us
ctRegex is 138ms
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Fri, 09 Jan 2015 15:36:21 +
FrankLike via Digitalmars-d-learn
wrote:
> On Friday, 9 January 2015 at 14:03:21 UTC, ketmar via
> Digitalmars-d-learn wrote:
> > On Fri, 09 Jan 2015 13:54:00 +
> > Robert burner Schadek via Digitalmars-d-learn
> > wrote:
> >
> >> On Friday, 9 January 2015 at 13:25:17 UTC, ketmar via
> >> Digitalmars-d-learn wrote:
> >> > if you *really* concerned with speed here, you'd better
> >> > consider using
> >> > regular expressions. as regular expression can be
> >> > precompiled and then
> >> > search for multiple words with only one pass over the source
> >> > string. i
> >> > believe that std.regex will use variation of Thomson
> >> > algorithm for
> >> > regular expressions when it is able to do so.
> >>
> >> IMO that is not sound advice. Creating the state machine and
> >> running will be more costly than using canFind or indexOf how
> >> basically only compare char by char.
> >>
> >> If speed is really need use strstr and look if it uses sse to
> >> compare multiple chars at a time. Anyway benchmark and then
> >> benchmark some more.
> > std.regex can use CTFE to compile regular expressions (yet it
> > sometimes
> > slower than non-CTFE variant), and i mean that we compile
> > regexp before
> > doing alot of searches, not before each single search. if you
> > have alot
> > of words to match or alot of strings to check, regexp can give
> > a huge
> > boost.
> >
> > sure, it all depends of code patterns.
> import std.regex;
> auto ctr = ctRegex!(`(home|office|sea|plane)`);
> auto c2 = !matchFirst("He is in the sea.", ctr).empty;
> --
> Test by auto r = benchmark!(f0,f1, f2, f3,f4,f5)(10_);
>
> Result is :
> filter is 42ms 85us
> findAmong is 37ms 268us
> foreach indexOf is 37ms 841us
> canFind is 13ms
> canFind indexOf is 39ms 455us
> ctRegex is 138ms
1. stop doing captures in regexp, this will speedup the comparison.
2. your sample is very artificial. i was talking about alot more
keywords and alot longer strings. sorry, i wasn't told that clear
enough.
signature.asc
Description: PGP signature
Re: Why do the same work about 'IndexOfAny' and 'indexOf' function?
On Friday, 9 January 2015 at 15:57:21 UTC, ketmar via
Digitalmars-d-learn wrote:
On Fri, 09 Jan 2015 15:36:21 +
FrankLike via Digitalmars-d-learn
wrote:
On Friday, 9 January 2015 at 14:03:21 UTC, ketmar via
Digitalmars-d-learn wrote:
> On Fri, 09 Jan 2015 13:54:00 +
> Robert burner Schadek via Digitalmars-d-learn
> wrote:
>
>> On Friday, 9 January 2015 at 13:25:17 UTC, ketmar via
>> Digitalmars-d-learn wrote:
>> > if you *really* concerned with speed here, you'd better
>> > consider using
>> > regular expressions. as regular expression can be
>> > precompiled and then
>> > search for multiple words with only one pass over the
>> > source string. i
>> > believe that std.regex will use variation of Thomson
>> > algorithm for
>> > regular expressions when it is able to do so.
>>
>> IMO that is not sound advice. Creating the state machine
>> and running will be more costly than using canFind or
>> indexOf how basically only compare char by char.
>>
>> If speed is really need use strstr and look if it uses sse
>> to compare multiple chars at a time. Anyway benchmark and
>> then benchmark some more.
> std.regex can use CTFE to compile regular expressions (yet
> it sometimes
> slower than non-CTFE variant), and i mean that we compile
> regexp before
> doing alot of searches, not before each single search. if
> you have alot
> of words to match or alot of strings to check, regexp can
> give a huge
> boost.
>
> sure, it all depends of code patterns.
import std.regex;
auto ctr = ctRegex!(`(home|office|sea|plane)`);
auto c2 = !matchFirst("He is in the sea.", ctr).empty;
--
Test by auto r = benchmark!(f0,f1, f2, f3,f4,f5)(10_);
Result is :
filter is 42ms 85us
findAmong is 37ms 268us
foreach indexOf is 37ms 841us
canFind is 13ms
canFind indexOf is 39ms 455us
ctRegex is 138ms
1. stop doing captures in regexp, this will speedup the
comparison.
2. your sample is very artificial. i was talking about alot more
keywords and alot longer strings. sorry, i wasn't told that
clear
enough.
Yes. regex doing 'a lot more keywords and a lot longer strings'
will be better.
Thank you.
Re: dco how to specify Jpath?
On Sunday, 21 December 2014 at 07:43:14 UTC, FrankLike wrote: On Thursday, 20 November 2014 at 10:48:17 UTC, Suliman wrote: I am playing with dco. And it's look very helpful for tiny projects. I can't understand is it's possible to add to dco.ini Jpath? I am talking about something like: dflags=-JD:\code\d\App1\source\ but when I am trying to compile code with dco it's can't find import. I looked at source code and it's look like it's do not support dflags... https://github.com/FrankLIKE/dco/tree/master/source In dco.ini importPath= -I..\\source // modity it to your source In dco 0.1.0,you can get the 'local.ini' by 'dco -ini'. You can config project in local.
Re: For those ready to take the challenge
On Fri, 09 Jan 2015 13:50:28 +, eles wrote: > https://codegolf.stackexchange.com/questions/44278/debunking- stroustrups-debunking-of-the-myth-c-is-for-large-complicated-pro Was excited to give it a try, then remembered...std.xml :(
Re: For those ready to take the challenge
On Friday, 9 January 2015 at 16:55:30 UTC, Justin Whear wrote:
Was excited to give it a try, then remembered...std.xml :(
Well, as the author of my dom.d, I think it counts as a first
party library when I use it!
---
import arsd.dom;
import std.net.curl;
import std.stdio, std.algorithm;
void main() {
auto document = new Document(cast(string)
get("http://www.stroustrup.com/C++.html";));
writeln(document.querySelectorAll("a[href]").map!(a=>a.href));
}
---
prints:
[snip ... "http://www.morganstanley.com/";,
"http://www.cs.columbia.edu/";, "http://www.cse.tamu.edu";,
"index.html", "C++.html", "bs_faq.html", "bs_faq2.html",
"C++11FAQ.html", "papers.html", "4th.html", "Tour.html",
"programming.html", "dne.html", "bio.html", "interviews.html",
"applications.html", "glossary.html", "compilers.html"]
Or perhaps better yet:
import arsd.dom;
import std.net.curl;
import std.stdio;
void main() {
auto document = new Document(cast(string)
get("http://www.stroustrup.com/C++.html";));
foreach(a; document.querySelectorAll("a[href]"))
writeln(a.href);
}
Which puts each one on a separate line.
Re: For those ready to take the challenge
Huh, looking at the answers on the website, they're mostly using regular expressions. Weaksauce. And wrong - they don't find ALL the links, they find the absolute HTTP urls!
Re: For those ready to take the challenge
On Fri, 09 Jan 2015 17:18:42 +, Adam D. Ruppe wrote: > Huh, looking at the answers on the website, they're mostly using regular > expressions. Weaksauce. And wrong - they don't find ALL the links, they > find the absolute HTTP urls! Yes, I noticed that. `http://app.js"`>` isn't a "hyperlink". Wake up sheeple!
Cast a struct to void*
struct S
{
void* p;
}
void main()
{
S s;
auto a = cast(void*)s; //Error: e2ir: cannot cast s of type S
to type void*
}
Is there are a good reason for this being disallowed?
Re: Cast a struct to void*
On 01/09/2015 10:25 AM, John Colvin wrote:
struct S
{
void* p;
}
void main()
{
S s;
auto a = cast(void*)s; //Error: e2ir: cannot cast s of type S to
type void*
}
Is there are a good reason for this being disallowed?
I know two options:
a)
alias p this;
b)
auto opCast(T : void*)()
{
return p;
}
Ali
Re: Cast a struct to void*
On Friday, 9 January 2015 at 18:25:42 UTC, John Colvin wrote:
struct S
{
void* p;
}
void main()
{
S s;
auto a = cast(void*)s; //Error: e2ir: cannot cast s of type
S to type void*
}
Is there are a good reason for this being disallowed?
You'd expect `cast(void*)s == s.p`? That doesn't work for any
type of p. You can do it with a slightly fancier (and more
dangerous) cast: `*cast(void**)&s`.
Tuples not working?
import std.stdio;
import std.typecons;
void main()
{
alias TL = Tuple!(int, long, float);
foreach (i, T; TL)
writefln("TL[%d] = %s", i, typeid(T));
}
Why is this not working?
D:\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(419): Error:
need 'this' for '_expand_field_0' of type 'int'
D:\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(419): Error:
need 'this' for '_expand_field_1' of type 'long'
D:\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(419): Error:
need 'this' for '_expand_field_2' of type 'float'
Tried to compile using dmd 2.066 and dmd 2.067. Code taken
directly from dlang website here (http://dlang.org/tuple.html).
Thanks.
Re: Cast a struct to void*
On Friday, 9 January 2015 at 18:35:56 UTC, anonymous wrote:
On Friday, 9 January 2015 at 18:25:42 UTC, John Colvin wrote:
struct S
{
void* p;
}
void main()
{
S s;
auto a = cast(void*)s; //Error: e2ir: cannot cast s of type
S to type void*
}
Is there are a good reason for this being disallowed?
You'd expect `cast(void*)s == s.p`? That doesn't work for any
type of p.
I was expecting it to work regardless of the type of p. I have an
8 byte (on x86_64) struct which I want to reinterpret as a void*
You can do it with a slightly fancier (and more dangerous)
cast: `*cast(void**)&s`.
Yuk. Better than nothing though. Thanks :)
Re: Tuples not working?
On 01/09/2015 10:42 AM, Jonathan Marler wrote:
import std.stdio;
import std.typecons;
void main()
{
alias TL = Tuple!(int, long, float);
foreach (i, T; TL)
writefln("TL[%d] = %s", i, typeid(T));
}
Why is this not working?
D:\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(419): Error: need
'this' for '_expand_field_0' of type 'int'
D:\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(419): Error: need
'this' for '_expand_field_1' of type 'long'
D:\dmd2\windows\bin\..\..\src\phobos\std\typecons.d(419): Error: need
'this' for '_expand_field_2' of type 'float'
Tried to compile using dmd 2.066 and dmd 2.067. Code taken directly
from dlang website here (http://dlang.org/tuple.html). Thanks.
Broken documentation presumable because the feature changed later on.
The code works if you we std.typetuple.TypeTuple:
import std.stdio;
import std.typetuple;
void main()
{
alias TL = TypeTuple!(int, long, float);
foreach (i, T; TL)
writefln("TL[%d] = %s", i, typeid(T));
}
Ali
Re: Cast a struct to void*
On 1/9/15 1:50 PM, John Colvin wrote:
On Friday, 9 January 2015 at 18:35:56 UTC, anonymous wrote:
On Friday, 9 January 2015 at 18:25:42 UTC, John Colvin wrote:
struct S
{
void* p;
}
void main()
{
S s;
auto a = cast(void*)s; //Error: e2ir: cannot cast s of type S to
type void*
This is actually a compiler bug! I will check to make sure it's not
already filed, and file if it's not. However, I don't think the code
should work, it just shouldn't print e2ir.
}
Is there are a good reason for this being disallowed?
You'd expect `cast(void*)s == s.p`? That doesn't work for any type of p.
I was expecting it to work regardless of the type of p. I have an 8 byte
(on x86_64) struct which I want to reinterpret as a void*
You can do it with a slightly fancier (and more dangerous) cast:
`*cast(void**)&s`.
Yuk. Better than nothing though. Thanks :)
This is what reinterpret_cast from C++ does.
-Steve
Wrapping a C library with its own GC + classes vs refcounted structs
Hi all,
I was wondering what's the most D-idiomatic way of dealing with a
C library (or rather writing wrappers for a C library) that does
its own GC via reference counting. The objects are identified and
passed around by integer ids only; most functions like "find me
an object foo in object bar" return an id and increase a refcount
internally; in rare cases, a borrowed reference is returned.
Whenever refcount drops to zero, the id becomes invalid and the
memory (and possibly the id as well) gets eventually reused. Some
C functions may explicitly or implicitly release IDs so there's
also a problem of tracking whether a live D object refers to a
live C object.
Since the main concern here is wrapping the C library, the only
data that is stored in D objects is the object id, so the objects
are really lightweight in that sense. However, there's a logical
hierarchy of objects that would be logical to reflect in D types
either via inheritance or struct aliasing.
The main question here is whether it's most appropriate in this
situation to use D classes and cross the fingers relying on D's
GC to trigger C's GC (i.e., ~this() to explicitly decrease
refcount in the C library), or use refcounted structs (or
something else?). I think I understand how RefCounted works but
can't see how exactly it is applicable in cases like this or what
are the consequences of using it.
My initial naive guess was to use classes in D to encapsulate
objects (to be able to use inheritance), so the code for the base
class looks along the lines of:
class ID {
protected int id;
private static shared Registry registry;
this(int id) { // assume that refcount was already increased
in C
this.id = id;
registry.store(this); // store weakref to track zombie
objects
}
~this() @nogc {
if (c_is_valid(id) && c_refcount(id) > 0)
c_decref(id);
registry.remove(this);
}
}
class ConcreteTypeA(ID) { ... }
class ConcreteTypeB(ID) { ... }
where the weak static registry is required to keep track of live
D objects that may refer to dead C objects and has to be
traversed once in a while.
However there's something sketchy about doing it this way since
the lifetimes of objects are not directly controlled, plus there
are situations where a temporary object is only required to exist
in function's scope and is naturally expected to be released upon
exit from the scope.
A related thread:
http://forum.dlang.org/thread/lmneclktewajznvfd...@forum.dlang.org
Re: For those ready to take the challenge
On Friday, 9 January 2015 at 13:50:29 UTC, eles wrote: https://codegolf.stackexchange.com/questions/44278/debunking-stroustrups-debunking-of-the-myth-c-is-for-large-complicated-pro Link to answer in D: http://codegolf.stackexchange.com/a/44417/13362
Re: For those ready to take the challenge
On 1/9/15 6:10 PM, Jesse Phillips wrote: On Friday, 9 January 2015 at 13:50:29 UTC, eles wrote: https://codegolf.stackexchange.com/questions/44278/debunking-stroustrups-debunking-of-the-myth-c-is-for-large-complicated-pro Link to answer in D: http://codegolf.stackexchange.com/a/44417/13362 Nailed it. -- Andrei
Re: For those ready to take the challenge
On Saturday, 10 January 2015 at 02:10:04 UTC, Jesse Phillips
wrote:
On Friday, 9 January 2015 at 13:50:29 UTC, eles wrote:
https://codegolf.stackexchange.com/questions/44278/debunking-stroustrups-debunking-of-the-myth-c-is-for-large-complicated-pro
Link to answer in D:
http://codegolf.stackexchange.com/a/44417/13362
I think byLine is not necessary. By default . will not match line
breaks.
One statement solution:
import std.net.curl, std.stdio;
import std.algorithm, std.regex;
void main() {
get("http://www.stroustrup.com/C++.html";)
.matchAll(` m[1])
.each!writeln();
}
Requires Phobos PR#2024 ;)
