Error instantiating std.container.Array
I'm trying to instantiate a std.container.Array of a given class (named Material), by a simple Array!Material _myStuff; I get two compile errors stating the following: C:\D\dmd2\windows\bin\..\..\src\phobos\std\container\array.d(85): Error: template std.algorithm.initializeAll cannot deduce function from argument types !()(Material[]), candidates are: C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(1502): std.algorithm.initializeAll(Range)(Range range) if (isInputRange!Range hasLvalueElements!Range hasAssignableElements!Range) C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(1530): std.algorithm.initializeAll(Range)(Range range) if (is(Range == char[]) || is(Range == wchar[])) C:\D\dmd2\windows\bin\..\..\src\phobos\std\container\array.d(825): Error: template std.algorithm.copy cannot deduce function from argument types !()(Range, Range), candidates are: C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(7808): std.algorithm.copy(Range1, Range2)(Range1 source, Range2 target) if (isInputRange!Range1 isOutputRange!(Range2, ElementType!Range1)) Any idea about what might be happening? I can't give a quick minimal example of the code since it is quite complex (and I failed at using dustmite trying to minimize it)
Re: Error instantiating std.container.Array
On Monday, 2 March 2015 at 14:46:31 UTC, ketmar wrote: On Mon, 02 Mar 2015 14:40:50 +, Francesco Cattoglio wrote: did you tried to dustmite[1] it? [1] https://github.com/CyberShadow/DustMite/wiki I tried to dub dustmite, but it failed with a object.Exception@DustMite\dustmite.d(220): Initial test fails The dustmite version is the one that was bundled with dmd 2.066.1-rc2. I'll update dmd in the mean time, but I have a feeling that this is not related.
Re: Error instantiating std.container.Array
On Monday, 2 March 2015 at 15:01:55 UTC, Tobias Pankrath wrote:
I'm really clueless... :P
Something is wrong with your Material class, but you'll need to
show us a reduced example.
After a really long time I finally found what was wrong.
http://dpaste.dzfl.pl/16d202b7124d
Wow, I honestly could have NEVER foreseen this.
This is all it takes for a class being unusable in a
std.container.Array
class MyClass
{
void init();
}
Re: A naive attempt at a refcounted class proxy
On Tuesday, 13 January 2015 at 18:52:25 UTC, ketmar via Digitalmars-d-learn wrote: On Tue, 13 Jan 2015 18:36:15 + aldanor via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Tuesday, 13 January 2015 at 18:19:42 UTC, ketmar via Digitalmars-d-learn wrote: and then you can go with structures in the first place, i think. remember that you have that k00l `alias this` trick for them! Which doesn't always help in case of multiple inheritance :( e.g. the blasted hdf c++ class hierarchy example. multiple `alias this` may help here... to some extent. ;-) Are they even enabled in dmd already? 2.65 still reports the there can only be one alias this error.
-inline switch changes code behaviour
Today I just realized that in DMD optimize flag does not imply inlining, therefore I promptly added the inline to my dub build settings and recompiler, expecting to see speedups in my code execution. To my surprise, I could not see anything at all: all that I get now is a blank screen. The rendering code uses an old-ish version of gfm-sdl, but I did not find any issue related to compiler swirches. Any idea about what might be happening/any suggestion on how to debug this?
Get the default hash function.
Really simple question:
how do I get the compiler-generated hash function for a given
type?
For example:
Struct S
{
int i;
}
can be used in an associative array. That means the compiler
generates a toHash function. Is there any simple way to call it
directly?
Type deduction on templated constructor.
So, I have this code (also on http://dpaste.dzfl.pl/3f767b17e83c)
This Vector(T) struct is taken from gfm.math.vector.
struct Vector(T) {
T x, y, z;
this(X : T, Y : T, Z : T)(X x_, Y y_, Z z_)
{
x = x_; y = y_; z = z_;
}
}
void main()
{
Vector!ubyte test = Vector!ubyte(1, 1, 1);
}
It fails to compile because template
f508.Vector!ubyte.Vector.__ctor cannot deduce function from
argument types !()(int, int, int).
Note that if one just defines a constructor as this(T x_, T y_, T
z_) everything works.
My question is: should this code compile? I understand that the
literal 1 is int therefore it can screw type deduction, but I
wonder if the compiler should be smart enough to deduce it
correctly.
Re: Type deduction on templated constructor.
On Thursday, 24 July 2014 at 09:38:14 UTC, bearophile wrote: francesco cattoglio: should this code compile? I understand that the literal 1 is int therefore it can screw type deduction, but I wonder if the compiler should be smart enough to deduce it correctly. To keep both the compiler and programmers sane, D templates don't perform implicit type conversions. This sometimes is not handy, but on the whole saves from a large number of troubles. So you can write (D V.2.066): Vector!ubyte(ubyte(1), ubyte(1), ubyte(1)); Or you can create a little helper function that makes that code more DRY. Bye, bearophile I expected such an answer and I do understand the decisions behind it. Yet, you gave me a really GOOD news! Having to write cast(ubyte) 1 was way too much verbose for my liking, while the new ubyte(1) is reasonable enough.
Re: core.exception.InvalidMemoryOperationError
On Friday, 11 July 2014 at 11:43:44 UTC, Joakim wrote: On Thursday, 10 July 2014 at 15:36:53 UTC, francesco cattoglio wrote: A code I'm working on stops working and starts printing an infinite loop of core.exception.InvalidMemoryOperationError to the command line output. The code is quite complex and the bug seems to present itself almost in random situation so I would like to try to understand the issue better before looking for the wrong line of code hiding somewhere. I've read it might be that something is trying to allocate during a destructor call, but it sounds really strange to me that there's a neverending amount of exceptions being thrown. This is the first exception being thrown (nothing is thrown before the infinite loop begins). Anyone has suggestions/ideas/heard of a similar stuff before? If you look at the source for the garbage collector, the only place that error is called is if the gc is trying to malloc or execute other memory operations while the collector is running. I ran across this myself because an assert was getting triggered in a destructor. Since an assert tries to malloc and the destructor is called by the GC, I got an InvalidMemoryOperationError which swallowed up the message from the original assert. By putting printfs in the code path in druntime, I was able to track it down to that destructor, otherwise I had no idea where the invalid memory error was getting triggered. You can probably do the same, but you can be sure it's a GC issue, and I would guess tied to allocating in a destructor (unless you happen to be calling InvalidMemoryOperationErrors somewhere in your own code or some library that you're using, which is unlikely). It's unfortunate that you wrote this only 4 hours ago, because I already spent the morning doing more-or-less the same thing, and finaly realized what was happening and WHO was allocating during a destructor. :o) It's even somewhat told in the docs of core.exception module. What I really don't understand is how the hell was it possible that something managed to either recurse or loop to generate an infinite WOE (Wall Of Exceptions).
core.exception.InvalidMemoryOperationError
A code I'm working on stops working and starts printing an infinite loop of core.exception.InvalidMemoryOperationError to the command line output. The code is quite complex and the bug seems to present itself almost in random situation so I would like to try to understand the issue better before looking for the wrong line of code hiding somewhere. I've read it might be that something is trying to allocate during a destructor call, but it sounds really strange to me that there's a neverending amount of exceptions being thrown. This is the first exception being thrown (nothing is thrown before the infinite loop begins). Anyone has suggestions/ideas/heard of a similar stuff before?
Re: What exactly module in D means?
On Saturday, 5 July 2014 at 17:08:01 UTC, Olivier Pisano wrote:
No, import is different from include. It does not stupidly copy
and paste its content but tells the compiler to take the module
into account for name resolution. The result may seem similar,
but is much more efficient.
In fact, try to write the following C code:
int main() {
#include stdio.h
[whatever else you want]
}
and look at those lovely error messages from the compiler :P
Re: how to correctly 'typedef' handle types
http://dlang.org/phobos/std_typecons.html#Typedef Take a look at it. Docs is scarce (pretty sure you will need to take a look around to find something) but it should just do what you need.
Differences between const Type function() and const(Type) function()
Today I got the following compile error:
Cannot implicitly convert expression (blabla) of type
const(Type) to Type
and this is a reduced example ( also on
http://dpaste.dzfl.pl/f2f3bd921989):
module test;
import std.stdio;
class Foo {
int i = 42;
}
class MyClass {
private { Foo _Q; }
this() {_Q = new Foo;}
Foo getQ () { return _Q; }
const (Foo) getQ () const { return _Q; } // OK
// const Foo getQ () const { return _Q; } // fails
}
void main() {
const MyClass instance = new MyClass;
writeln(instance.getQ.i);
}
I don't really understand what's going on here. Why is const Foo
getQ() wrong?
And why is const(Foo) getQ so much different? (e.g: this is an
explicit cast, right? Is there anything that might go wrong?)
Re: Differences between const Type function() and const(Type) function()
On Friday, 30 May 2014 at 12:57:52 UTC, anonymous wrote: And why is const(Foo) getQ so much different? (e.g: this is an explicit cast, right? Is there anything that might go wrong?) It's not a cast. It's the unambiguous notation for a qualified type. Often you can omit the parentheses. With methods you cannot. With methods you need the parentheses to let the compiler know that you indeed mean the return type to be const, not the method itself. Ouch... I even wonder why I wrote about is this a cast?... Noob mistake! :P Anyway thank you everyone, I really thought the two way of writing were equivalent. (it's C++ fault, not mine! I tell you!)
Re: Programming a Game in D? :D
On Wednesday, 28 May 2014 at 17:46:23 UTC, David wrote: Ok, now I just wonder wich Engine. (I know everybody hates the discussion about the best engine.) CryEngine, UDK, Unity or a less known Engine? I'll be honest, perhaps I risk being misunderstood, but the questions you are asking denote a lack of even basic knowledge about the subject, so I really think you should do some good amount of research before even trying to write something on your own. Have you tried at least some free tools that allow you to script stuff and have simple stuff displayed on screen? I'm talking about stuff like Construct 2, GameMaker, RPGMaker, zGameEditor... even map editors like the ones from Blizzard (WarCraft 3 : TFT or StarCraft 2)?
Re: Programming a Game in D? :D
On Thursday, 22 May 2014 at 15:48:50 UTC, John Colvin wrote: On Thursday, 22 May 2014 at 15:39:36 UTC, David wrote: Hey, I'm really new to D, and pretty new to programming overall too, But I want to make a 3d Game, (just sth. small). I really like D and want to do it in D, but in the Internet there is no shit about programming a game in D ^^ Is there any engine written in D? For example the CryEngine is for C++, so I would have to write a wrapper? So, how do I write a wrapper? I would need a wrapper for DirectX too right? Are there any wrappers ore Engines for D i can use? btw. I know I dont write that in 1 day ^^ Are there any tutorials or sth. on Programming a Game in D? S I just wanna come as far to have a little Cube where i can run around on with a few phisics :) so just the startup to load a world and so on Thanks in advance :) And sry my english sucks :D There are quite a few game related libs on code.dlang.org that you can take a look at. Also see some of the recent D.announce posts. Yep. Start by learning dub (code.dlang.org), which is a build automation tool that helps you alot by saving headaches caused by the heap of dependencies that a complex software like a game has. Don't start by diving into graphics just yet, spend your first days by doing stuff on the command line. There are a few engines that are being developed by others, but there's nothing like e.g. Unity right now. I think that every engine is in early development stage, too. Also, I think most of current libraries use OpenGL instead of DirectX, so you might want to learn that (at least the basics).
Re: Scalar + array operations
On Wednesday, 21 May 2014 at 13:52:47 UTC, John Colvin wrote: On Wednesday, 21 May 2014 at 11:45:57 UTC, Stefan Frijters wrote: I would have expected the last case to work as well, but I get testarr.d(20): Error: incompatible types for ((dfoo) * (ibar[])): 'double' and 'int[]' Is this by design? It was very surprising to me, especially since all other combinations do seem to work. Kind regards, Stefan Frijters Please file a bug, there's no reason for that not to work, it just needs to be implemented properly. To me, it just feels reasonable that it is not allowed. What should be the correct type of the result? int[]? I thought double to int conversion was not allowed unless you explicitly asked for it.
Re: Templating everything? One module per function/struct/class/etc, grouped by package?
On Monday, 12 May 2014 at 08:37:43 UTC, JR wrote: What am I missing? Error messages! If your code is not compiled, you can't know whether it is valid or not. I must say that since we have unittests, this is somewhat less relevant, but still... One nice thing would be stripping the executable of unneeded code. One trick I've seen done in a program which compiled some scripts to an intermediate language was zeroing the parts which are unused, then use some executable compressor.
Re: D alternative for C/C++ -Dfoo=42
On Tuesday, 25 February 2014 at 14:26:13 UTC, Tobias Pankrath
wrote:
Something like static if(fileExists!config.d)
mixin(import(config.d)) else
Thoughts?
Regards
- Cherry
--
static if(__traits(compiles, import(config.d)))
{
// import/parse/mixin
}
else
{
// default here
}
--
May be wrapped into a template for more convenience.
I thought that too... And then, when I tried, SURPRISE, it
doesn't work :S
Re: D alternative for C/C++ -Dfoo=42
On Tuesday, 25 February 2014 at 14:30:23 UTC, Francesco Cattoglio
wrote:
On Tuesday, 25 February 2014 at 14:26:13 UTC, Tobias Pankrath
wrote:
Something like static if(fileExists!config.d)
mixin(import(config.d)) else
Thoughts?
Regards
- Cherry
--
static if(__traits(compiles, import(config.d)))
{
// import/parse/mixin
}
else
{
// default here
}
--
May be wrapped into a template for more convenience.
I thought that too... And then, when I tried, SURPRISE, it
doesn't work :S
Ok, MY BAD! It works, but I gave him a folder instead of a file.
When you give it a folder instead of a file, it still works but
also outputs an error:
read error, errno = 21
However the else branch is still taken. Well, this went better
than expected!
Re: hiding a class property behind a method
On Saturday, 22 February 2014 at 17:21:50 UTC, luka8088 wrote: It seems to me that the following code should be illegal, but I am uncertain of it so I am posting here for a confirmation before I post it on bug tracker: [snip] Nice find. I guess we could add this to the list of ugly code caused by calling functions without parenthesis. If parenthesis were not optional, I don't think that the code would behave in such a horrible way, right?
Re: hiding a class property behind a method
On Saturday, 22 February 2014 at 22:42:24 UTC, simendsjo wrote: The problem isn't about optional parenthesis or properties. It's the fact that you can redefine a symbol to be something entierly different, and that this difference will only be seen if you are looking at the symbol through the correct type. You are right. I thought that if we had forced parenthesis, the compiler would at least be able to understand what symbol you were referring to, but this is actually not the case.
Re: foreach/iota countdown
On Monday, 17 February 2014 at 20:21:30 UTC, simendsjo wrote: I wouldn't call it randomly. In that case you should call it randomly that it suddenly doesn't run once you try to step downward. I didn't had time to work more on the iota. Perhaps after 2.065 is out I can resume working on that, but I'm really short of time right now. Allowing iota to iterate downward might become a horrible idea when we finally extend iota to other non-numeric types. The big issue is that types that define both opUnary!++ and opUnary!-- would behave in a completely different way from types that only define opUnary!++. from http://forum.dlang.org/thread/mwwznnobgecnwermr...@forum.dlang.org example: type T implements ++t and --t; type P only implements ++p; t1 t2 = iota(t2, t1) has a way to compute a non-empty range; p1 p2 = iota(p2, p1) can do nothing but return an empty range; This really looks like a minefield to me.
Re: Optimize my code =)
On Sunday, 16 February 2014 at 01:25:13 UTC, bearophile wrote: Many of the things you say and write are still wrong or confused. Usually the hard optimization of code is one the last things you learn about a language Well, actually, sometimes squeezing as much performance as you can from a test case can be a way to find out if a given language checks all the boxes and can be used to solve your problems. I must admit I'm shocked by the poor performance of D here. But I also know one HAS to try LDC or GDC, or those numbers are really meaningless.
Re: Optimize my code =)
On Sunday, 16 February 2014 at 09:53:08 UTC, bearophile wrote: Be instead amazed of the sometimes near-C++ performance levels they have pushed Java to :-) Sorry, but I fail to be amazed by what huge piles of money thrown to a project for 10+ years can achieve. Those kind of achievements are boring :P And I think D is doing well in a benchmark like this, I guess with ldc2 you can go about as fast as C++. I'm sure that other small benchmarks on computational-intensive code achieved C++ speed in the past, so if we can't get C++-like speed here, it's either a problem with the code or some serious performance regression.
Re: 3d vector struct
On Monday, 3 February 2014 at 20:10:59 UTC, Brenton wrote: 6) Any other comments or suggestions? I know that the I'm learning the language factor plays a huge role, but after you are done studying your vector implementation, I think you could forget about it and use the ones provided by other libraries :P If you didn't knew about it, DUB is a marvelous software that gives you quick access to lots of nice libraries. EG: one you might be interested in is http://code.dlang.org/packages/gl3n Another one *might* be gfm: http://code.dlang.org/packages/gfm I'm also wondering where the hell did I put my raytracer code I did ages ago...
Re: std.array.array broken?
On Saturday, 1 February 2014 at 22:52:24 UTC, Andrej Mitrovic wrote: On Saturday, 1 February 2014 at 22:47:54 UTC, deed wrote: Docs also say: /** Note: Each $(D front) will not persist after $(D popFront) is called, so the caller must copy its contents (e.g. by calling $(D to!string)) if retention is needed. */ So you need to do a duplication for each element. Use this code: Sorry, but I really don't understand this. At all. Returns a newly-allocated dynamic array consisting of a copy of the input range to me sounds Hey, I'm doing a copy. How is one supposed to understand that you need to go through hops for getting a good result?
Re: Creating an array of C structs
On Monday, 27 January 2014 at 10:13:08 UTC, Colin Grogan wrote: On Monday, 27 January 2014 at 09:34:04 UTC, Namespace wrote: Arrays are enclosed in [] ;) I'm an idiot. Can I delete this thread to save further embarrassment? :) HA-HA! (read it with Nelson voice, ofc)
Re: Creating an array of C structs
On Monday, 27 January 2014 at 13:08:28 UTC, Colin Grogan wrote: In my defense, I believe C initializes arrays with the curly brackets Can I keep making excuses? Yes you can... And don't worry, I mess up initialization too. Lots of time. Especially when I tried initializing an array of structs made of 2 structs. I think I wasted at least 15 minutes before giving up :D
Best way of handling a receive()d message with a class instance.
Suppose that I receive a message, but instead of defining a
function inside the receive() block, I want to call a member of a
class instance. (This is useful to me for several reasons). Right
now my code looks like:
class Handler {
auto handle() {
return (string msg) {
writeln(received: , msg, count: , i);
}; // this ';' ends the return statement
} // handle()
private:
i;
}
//somewhere inside main
auto handler = new Handler;
receiveTimeout( dur!seconds(1),
handler.handle
);
It works, but I must say I'm not even sure about what the hell I
am doing :D
If I got it correctly, I'm calling a function that returns a
delegate, which is used by the receiveTimeout() somehow to
dispatch the message (and everything is in some way decided at
compile time, I believe).
Does this ugly piece of code make any sense? Should I rework it?
Re: Best way of handling a receive()d message with a class instance.
Sorry, MY BAD! You can just write auto handler = new Handler; receive(handler.MyFunc); Somehow when I tried this before it failed to compile, and I thought I had to go through loops for achieving this.
Automatic translation of opUnary!++ into opOpAssign!+
So, while I was studying the apropriate template constraints for
my shiny new iota implementation, I found out this funny thing:
import std.stdio;
class Test{
int x = 41;
Test opOpAssign(string op)(int rhs) if (op == +) {
x += rhs;
return this;
}
}
void main() {
Test t1 = new Test;
//class Test has no opUnary defined, so the following
//gets automagically converted into (t1) += (1)
++t1;
writeln(t1.x); //prints 42, correct!
}
This actually comes really handy, but I couldn't find it into the
language documentation on dlang.org, so it surprised me.
Did I miss it in the language specification? Should we add it
somewhere to the docs?
Anyone with some spare time care to explain briefly what was the
rationale behind this?
Template constraints: opCmp and opUnary!++
I'm trying to experiment a bit around the iota function.
If I try to impose the following constraits:
auto my_iota(B, E)(B begin, E end)
if (is (typeof(++begin)) is (typeof(begin end))) {}
Everything works as it should, but according to D Templates: A
Tutorial book, you should not use arguments in constraints.
If I try doing something like:
auto my_iota(B, E)(B begin, E end)
if (is (typeof(++B.init)) is (typeof(B.init E.init))) {}
the code stops compiling for integers.
On the other hand the code
auto my_iota(B, E)(B begin, E end)
if (is (typeof(++B)) is (typeof(B E))) {}
fails to compile for both integers and my defined types.
I read the D Templates: A Tutorial book and as far as I can
tell ++B.init and B.init E.init doesn't look too much
wrong, but I've not seen any constraint of this kind in phobos
(using variables instead of types) so I was wondering if doing
something like this is actually bad or even really bad. (And I
also wonder how to properly setting those constraints directly on
types)
Re: Template constraints: opCmp and opUnary!++
On Friday, 20 December 2013 at 16:40:23 UTC, monarch_dodra wrote: Everything works as it should, but according to D Templates: A Tutorial book, you should not use arguments in constraints. That's news to me. It seems strange to me too, but: page 69 on the PDF: Do not use argument in your constraint. If you need a value of type T, use T.init. Since I don't know D really well, I thought something was wrong with it. That's normal, because T.init is not an lvalue. Right! I was suspecting something like this. That said: Seems perfectly legit to me. Then I'll probably stick to it. It's simple, easy to understand, and works. Or maybe the __traits(compiles) actually looks even better. B is a type, so ++B will always resolve to __error, unless you've implemented a static operator (not sure if even legal?). Best part is: ++B actually works, it's the B E that fails. But they both smelled bad. Perhaps ++B is some kind of accept-invalid bug then?
Re: Template constraints: opCmp and opUnary!++
On Friday, 20 December 2013 at 17:18:01 UTC, Timon Gehr wrote:
On 12/20/2013 05:40 PM, monarch_dodra wrote:
That's normal, because T.init is not an lvalue.
If you need an lvalue, we have `std.traits.lvalueOf!T` which
you
can use.
is(typeof((T v){ /+ use v +/ }))
I think this is a lot cleaner.
Is there any difference between is(typeof(somecode)) and
__traits(compiles, somecode)?
