Re: Need help in templates
On 03/24/2011 10:18 PM, Ishan Thilina wrote: > Hi, > > I'm still new to D. I tried to implement a stack using templates. But I get an > "Access Violation" error when I try to run a test on the stack that I made.The > source code is attached with this mail. Can somebody please point out the > error of this code? I would really love to look at it but like some other people all I get is the following non-D code. ;) I don't know whether the problem is on my end but e-mail and news used to be easier. :) Ali > begin 644 main.d > M;6]D=6QE(&UA:6X[#0H-"FEM<&]R="!S=&0N M*'-T
Re: Need help in templates
On Fri, 25 Mar 2011 06:18:21 +0100, Ishan Thilina wrote: Hi, I'm still new to D. I tried to implement a stack using templates. But I get an "Access Violation" error when I try to run a test on the stack that I made.The source code is attached with this mail. Can somebody please point out the error of this code? Line 10: Stack! (int) myStack; Stack!(int) is a class, hence you have to initialize it with new. So this line should be: Stack! (int) myStack = new Stack! (int); or (perhaps more idiomatic): auto myStack = new Stack! (int); -- Simen
Need help in templates
Hi,
I'm still new to D. I tried to implement a stack using templates. But I get an
"Access Violation" error when I try to run a test on the stack that I made.The
source code is attached with this mail. Can somebody please point out the
error of this code?
begin 644 main.d
M;6]D=6QE(&UA:6X[#0H-"FEM<&]R="!S=&0N5-T86-K+G!UPT*"0EWPT*"0T*"7!R
M:79A=&4@:6YT(&UA>%-I>F4["2\O%-I>F4]3UN
M97<@:6YT6VUA>%-I>F5=.PT*"0ET;W`]+3$["0D)"2\O:6YD:6-A=&5S('1H
M870@;F\@:71E;7,@87)E(&EN('1H92!S=&%C:PT*"0D-"@D)?0T*"0T*"2\O
M4'5S:"!I=&5M5LK*W1O<%T]96QE;65N=#L-
M"@D)#0H)"7T-"@D-"@DO+U1A:V4@86X@:71E;2!FPT*"0ER971U5MT;W`M+5T[
M#0H)"7T-"@D-"@DO+U!E96L@870@=&AE('-T86-K('1O<`T*"7!U8FQI8R!4
M('!E96LH*7L-"@D)2@I>PT*"0EI9BAT;W`]/2TQ*7L-"@D)"7)E='5R;B!T
MPT*"0D)PT*"0EI9BAT;W`]/6UA>%-I>F4M,2E[
M#0H)"0ER971U
Re: Little quiz
bearophile Wrote:
> A little quiz for people here: guess the output of this little D2 program (it
> compiles correctly and doesn't crash at run time, so it's a fair question):
>
>
> import std.typecons: tuple;
> import std.c.stdio: printf;
>
> auto foo() {
> printf("foo\n");
> return tuple(1, 2);
> }
>
> void main() {
> foreach (x; foo().tupleof)
> printf("%d\n", x);
> }
Starting from main. As we are performing a foreach over a tuple this will need
to happen at compilation. As their are many bugs with compile time foreach I
would think this code evaluates to nothing and thus the program prints nothing.
However if that is working then I would expect foo() to be executed at
compile-time which would mean 'foo' might be printed during compilation. As
tupleof is supposed to return a type tuple, I'm unsure what gibberish printing
it as a decimal would do.
The other likely possibility is that the foreach is unrolled into code like:
x = foo().tupleof[0]
print...
x = foo().tupleof[1]
print...
where .tupleof is some other fancy runtime thing. In this case you would get
foo\nnumber\nfoo\nnumber...
--
So yeah, from that code I have no idea what it is supposed to do. But I am not
surprised by its behavior.
Re: Little quiz
On 03/25/2011 01:50 AM, bearophile wrote:
A little quiz for people here: guess the output of this little D2 program (it
compiles correctly and doesn't crash at run time, so it's a fair question):
import std.typecons: tuple;
import std.c.stdio: printf;
auto foo() {
printf("foo\n");
return tuple(1, 2);
}
void main() {
foreach (x; foo().tupleof)
printf("%d\n", x);
}
lol, would never haver guessed
Denis
--
_
vita es estrany
spir.wikidot.com
Little quiz
A little quiz for people here: guess the output of this little D2 program (it
compiles correctly and doesn't crash at run time, so it's a fair question):
import std.typecons: tuple;
import std.c.stdio: printf;
auto foo() {
printf("foo\n");
return tuple(1, 2);
}
void main() {
foreach (x; foo().tupleof)
printf("%d\n", x);
}
Bye,
bearophile
Re: Bug in tuple comparison?
> I agree. The second reduction I've written seems fit for Bugzila. http://d.puremagic.com/issues/show_bug.cgi?id=5783
Re: Using D libs in C
Hmm... Spent a few hours trying to figure out how to update GCC and all to conform to the requirements for 2.0.52, and at seems that it compiles my small test program just fine, but it fails on compiling the main project for some reason. And the linker outputs half-scrambled things. Anyway, here's all the output that shows how I'm trying to build the thing: http://pastebin.com/j7bE76bn It seems that it for some odd reason doesn't want to link the imports, and I don't see why is that, since my small test program works, and it uses basically the same thing...
Re: Bug w/tuple of custom types?
On Wed, 23 Mar 2011 16:14:55 -0400, bearophile wrote: Magnus Lie Hetland: Any way to do that without (to be deprecated) typedef? At the moment with a struct that contains an "alias this", I presume... And the alias this must point to a getter property to avoid the problem of implicitly casting from the base type to the specialized one. -Steve
Re: Bug in tuple comparison?
Jonathan M Davis: > Regardless, this _is_ a bug. I agree. The second reduction I've written seems fit for Bugzila. Bye, bearophile
Re: Bug in tuple comparison?
> On 2011-03-24 18:25:30 +0100, bearophile said: > > Magnus Lie Hetland: > >> I guess this is getting old by now ... but I've come across yet another > >> bug :-> > > > > The out(result) turns the result into a const, > > Riiight! Yes, I've seen that it's const, and (naughtily) cast away the > constness (without modifying anything) in some cases. It didn't occur > to me that that was the problem here. :) (In my original program, I > didn't notice that I had gotten one of the values from outside the > out-block, while the other was from the result. I guess I was "primed" > to think that that wasn't the problem ;) > > So the issue, then, I take it, is that you *can* compare a non-const > tuple to a const-tuple, but you *cannot* compare a const-tuple to a > non-const tuple (as per casting rules)? > > Makes sense. Would have been nice with a slightly more obvious error > message, but I guess that's always a problem with templates in any form > ;) > > Aanyway -- glad the bug was just in my code/brain :D Thanks for the help, If you const-ness affects comparison, that _is_ a bug. Currently, a struct's opEquals should take a "const ref Type rhs" and Tuple isn't doing that. So, that's a bug in Tuple. There are a number of const-correctness bugs in druntime and Phobos though - the mother of them all being http://d.puremagic.com/issues/show_bug.cgi?id=1824 Regardless, this _is_ a bug. - Jonathan M Davis
Re: Want to help DMD bugfixing? Write a simple utility.
Is there a copy of the official D grammar somewhere online? I wrote a lexer for my Compiler class and would love to try and apply it to another grammar. The official D grammar is spread among the specification. But I recall that someone compiled a complete grammar for D1 some time ago.
Re: Bug in tuple comparison?
On 2011-03-24 18:25:30 +0100, bearophile said: Magnus Lie Hetland: I guess this is getting old by now ... but I've come across yet another bug :-> The out(result) turns the result into a const, Riiight! Yes, I've seen that it's const, and (naughtily) cast away the constness (without modifying anything) in some cases. It didn't occur to me that that was the problem here. :) (In my original program, I didn't notice that I had gotten one of the values from outside the out-block, while the other was from the result. I guess I was "primed" to think that that wasn't the problem ;) So the issue, then, I take it, is that you *can* compare a non-const tuple to a const-tuple, but you *cannot* compare a const-tuple to a non-const tuple (as per casting rules)? Makes sense. Would have been nice with a slightly more obvious error message, but I guess that's always a problem with templates in any form ;) Aanyway -- glad the bug was just in my code/brain :D Thanks for the help, - M -- Magnus Lie Hetland http://hetland.org
Re: Bug in tuple comparison?
Magnus Lie Hetland:
> I guess this is getting old by now ... but I've come across yet another bug
> :->
The out(result) turns the result into a const, this causes some troubles you
see in this simpler program:
import std.typecons;
void main() {
alias Tuple!(int) T;
const T t = T();
bool b = t == t;
}
Further reduction:
struct Tuple(T) {
bool opEquals(R)(R rhs) {
return false;
}
}
void main() {
const Tuple!int t;
bool b = t == t;
}
Bye,
bearophile
Bug in tuple comparison?
I guess this is getting old by now ... but I've come across yet another bug :->
This one is a bit obscure, and deals with comparing tuples in
contracts. It seems that some type information about the result is lost
when entering an out-block, or something. At least, DMD (2.052, OS X)
is unable to infer types properly, and is therefore unable to compare
tuples in some cases. Sample program follows. (Similar behavior occurs
for other comparison operators as well.)
import std.typecons;
T[] func(T)(T[] arg)
out(result) {
auto a = result[0];
auto b = arg[0];
auto c = result[0];
// assert(c < a); // Doesn't work
// assert(a < c); // Doesn't work
// assert(c < b); // Doesn't work
assert(b < c); // Works
}
body {
return arg;
}
void main() {
alias Tuple!(real, uint) Entry;
func(new Entry[100]);
}
The error (when uncommenting one of the lines that don't work, e.g.,
line 7) is:
tuplecmpbug.d(7): Error: template
std.typecons.Tuple!(real,uint).Tuple.opCmp(R) if (isTuple!(R)) does not
match any function template declaration
tuplecmpbug.d(7): Error: template
std.typecons.Tuple!(real,uint).Tuple.opCmp(R) if (isTuple!(R)) cannot
deduce template function from argument types
!()(const(Tuple!(real,uint)))
I take it this is a bug (or am I just missing something)? Is it a known
bug? (Sorry if it's in the tracker; it can be hard to find equivalents
there...)
--
Magnus Lie Hetland
http://hetland.org
Re: Using D libs in C
Dainius (GreatEmerald) Wrote: > Ah, including pthread indeed works, but now I've run into another > problem related to Linux and architecture. I want to use D for my > program that also uses things like SDL and Lua. Earlier when I > compiled it, I always did so with 64-bit libraries. But D is so far > only in 32-bits, thus when compiling it doesn't accept phobos2. And it > also seems that Debian x64 (which I'm using to compile this at the > moment) doesn't have 32-bit libs of SDL as well. Plus compiling SDL > from source doesn't work either. So how should I proceed with this? > Try to get the beta D x64 libraries? Assuming it isn't Production Critical, use -m64 flag in DMD. You shouldn't need to "get" the libraries as they come with dmd 2.052. The generated 64 bit might be buggy, but people need to start using it so bugs can be found.
Re: C++ to D: mutable
> Caligo Wrote: > > Greetings, > > > > I have a C++ class that I would like to rewrite it in D. The class > > has members that are declared as 'mutable'. How do I achieve the same > > effect in D? if not, what is recommended? > > const int a=0; > *cast(int*)&a=1; There are so many reasons to cringe at that. Taking the address of a local variable is generally very dangerous. As long as the pointer doesn't escape and exist beyond the life the variable, then you're okay, but you often can't guarantee that, and it's generally a _bad_ thing to do. Also, casting away const is technically implementation-dependent. It breaks the type system. It's also _very_ bad to do in the general case, because the variable in question could actually be immutable underneath rather than just const. And if you then try and alter that variable, there's a decent chance that it'll segfault or just plain mess up your program. It might work here, but then again, it might not. It _probably_ will, but I wouldn't bet on it. And casting away const to try and have a mutable member variable is just asking for it, unless you can make a number of guarantees about the object in question - including that it's _never_ actually immutable. You should check out the stackoverflow post that I pointed out in a previous post in this thread. - Jonathan M Davis
Re: Using D libs in C
Ah, including pthread indeed works, but now I've run into another problem related to Linux and architecture. I want to use D for my program that also uses things like SDL and Lua. Earlier when I compiled it, I always did so with 64-bit libraries. But D is so far only in 32-bits, thus when compiling it doesn't accept phobos2. And it also seems that Debian x64 (which I'm using to compile this at the moment) doesn't have 32-bit libs of SDL as well. Plus compiling SDL from source doesn't work either. So how should I proceed with this? Try to get the beta D x64 libraries?
Re: C++ to D: mutable
Caligo Wrote: > Greetings, > > I have a C++ class that I would like to rewrite it in D. The class > has members that are declared as 'mutable'. How do I achieve the same > effect in D? if not, what is recommended? const int a=0; *cast(int*)&a=1;
Re: Want to help DMD bugfixing? Write a simple utility.
On 03/24/2011 08:53 AM, Alexey Prokhin wrote: Currently, as far as I know, there are only two lexers and two parsers for D: the C++ front end which dmd, gdc, and ldc use and the D front end which ddmd uses and which is based on the C++ front end. Both of those are under the GPL (which makes them useless for a lot of stuff) and both of them are tied to compilers. Being able to lex D code and get the list of tokens in a D program and being able to parse D code and get the resultant abstract syntax tree would be very useful for a number of programs. I fully support this. We desperately need it, I guess, working and maintained along language evolution. This is the whole purpose of the GSOC proposal "D tools in D": http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas#DtoolsinD Semantic analysis, introduced step by step, would be a huge plus. Denis -- _ vita es estrany spir.wikidot.com
Re: Want to help DMD bugfixing? Write a simple utility.
> Currently, as far as I know, there are only two lexers and two parsers for > D: the C++ front end which dmd, gdc, and ldc use and the D front end which > ddmd uses and which is based on the C++ front end. Both of those are under > the GPL (which makes them useless for a lot of stuff) and both of them are > tied to compilers. Being able to lex D code and get the list of tokens in > a D program and being able to parse D code and get the resultant abstract > syntax tree would be very useful for a number of programs. There is a third one: http://code.google.com/p/dil/. The main page says that the lexer and the parser are fully implemented for both D1 and D2. But the license is also the GPL.
Re: C++ to D: mutable
On 3/24/2011 12:23 AM, Caligo wrote: Greetings, I have a C++ class that I would like to rewrite it in D. The class has members that are declared as 'mutable'. How do I achieve the same effect in D? if not, what is recommended? You don't. Specific recommendations would depend on how the class is used.
Re: C++ to D: mutable
> Greetings, > > I have a C++ class that I would like to rewrite it in D. The class > has members that are declared as 'mutable'. How do I achieve the same > effect in D? if not, what is recommended? You don't - or at least it's generally inadvisable to try. Unlike C++, const in D is transitive. If something in D is const, it really is const. Take a look at this question/answer on stackoverflow: http://stackoverflow.com/questions/4219600/logical-const-in-d - Jonathan M Davis
C++ to D: mutable
Greetings, I have a C++ class that I would like to rewrite it in D. The class has members that are declared as 'mutable'. How do I achieve the same effect in D? if not, what is recommended?
Re: Bug w/tuple of custom types?
On 3/23/2011 12:45 PM, Magnus Lie Hetland wrote: Any way to do that without (to be deprecated) typedef? Nothing pretty, at least not yet. bearophile's suggestion is about as close as you can get right now.
