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.
