I'm trying to create a set of utility functions that cache
objects of various types loaded from json files, but having
trouble testing it. One function I'd like to test uses new to
instantiate an object based on a compile-time parameter:
void loadDataFile(T)(string filename) {
...
T obj =
I don't completely understand your problem, but have you tried
marking the class as static?
static class Dummy { ... }
I was about to post links to the actual code to make it more
clear, but that did the trick. Thanks for the fast reply.
Just to make sure - given:
unittest {
static class
On Wednesday, 25 June 2014 at 20:25:50 UTC, rcor wrote:
Dummy will not exist unless compiled with -unittest, correct?
Never mind, just verified that this is true.
Thanks again.
I've tried to express my problem in a mostly minimal example here:
https://gist.github.com/murphyslaw480/d4a5f857a104bcf62de1
The class Point has an alias this to its own property
'feature()', which returns a reference to a private member. When
I try to sort a Point[], DMD fails with mutable
On Wednesday, 27 August 2014 at 21:43:40 UTC, bearophile wrote:
It compiles if you use:
@property auto feature() const pure nothrow { return _feature; }
Otherwise I get strange errors like:
...\dmd2\src\phobos\std\exception.d(986,31): Error: pure
function 'std.exception.doesPointTo!(Point,
Just wanted to point out that there are also D bindings for
Allegro5 (https://github.com/SiegeLord/DAllegro5). Allegro is a
bit like SDL or SFML, but personally I find it a bit more
intuitive. I've been using the D bindings for about a month and
they seem to work fine. Most Allegro tutorials
Also, regarding comments about Garbage Collection -- yes, it
could be an issue, but its not a showstopper. C# (which has a GC)
was widely used to create PC and 360 games with the XNA library
(which lives on as MonoGame). If you have a real time game that
manages many objects at once, you may
auto c = cycle([1,2,3]);
foreach(i ; iota(-4,4)) {
writeln(c[i]);
}
prints the sequence
1
2
3
1
1 - c[0] == c[-1]
2
3
I understand this is what would happen if I were to just use
modulus on an index to access the original array, but should
Cycle really mimic this behavior? I feel like
On Thursday, 4 September 2014 at 11:58:58 UTC, monarch_dodra
wrote:
On Thursday, 4 September 2014 at 11:43:28 UTC, monarch_dodra
wrote:
Indexing is done with the unsigned size_t.
I re-read your post, and I don't think I actually answered your
question...?
I don't know of any case where
According to the docs, linearRemove on a DList returns A range
spanning the remaining elements in the container that initially
were right after r
(http://dlang.org/library/std/container/DList.linearRemove.html)
This seems to work fine except when I want to remove the last
element. I would
On Friday, 5 September 2014 at 17:17:54 UTC, monarch_dodra wrote:
I actually noticed this in code yesterday. Could you please
file it? I'll get to fixing it, I'm working on DList right now.
https://issues.dlang.org/show_bug.cgi?id=13425
Thanks, its impressive how fast you respond to these
I'd like to link to DAllegro5, which doesn't have an official dub
package yet.
My project structure looks like this:
--
ext/
dallegro5/
allegro5/ d bindings that need to be imported
libdallegro5.a -- library I need to link to
src/
app.d
On Wednesday, 10 September 2014 at 15:40:11 UTC, Edwin van
Leeuwen wrote:
On Wednesday, 10 September 2014 at 13:40:16 UTC, rcor wrote:
dub.json contains what I think should do the same as above:
{
name: test,
importPaths: [ext/dallegro5],
lflags: [-Lext/dallegro5]
}
Does adding:
libs:
On Wednesday, 10 September 2014 at 16:26:07 UTC, andre wrote:
Dub command line supports something like Dub add-local. Then
you can use the package directly.
Kind regards
Andre
DAllegro5 doesn't have an official dub package yet, but I threw
together one that could build the library and added
Finally got it:
{
name: test,
importPaths: [ext/dallegro5],
lflags: [-Lext/dallegro5],
libs: [
allegro,
allegro_acodec,
allegro_audio,
allegro_font,
allegro_ttf,
allegro_image,
allegro_color,
allegro_primitives
],
dependencies: {
dallegro5: ~master
I'm back for another round of is this a bug, or am I doing
something stupid?.
C and D implement interface I, and I have an array of each. I'd
like to combine these into one I[], but eventually I'd like to
cast an element back to its original type.
interface I {}
class C : I {}
class D : I
On Tuesday, 16 September 2014 at 03:05:57 UTC, Franz wrote:
Your issue comme from auto.
i is a I[]
I expected i to be an I[], but shouldn't a casting an element of
an I[] to a C return either a C or null?
It is if I do this:
I[] i = [cast(I) new C, new D];
assert(cast(C) i[0]); // fine
seemingly even weirder:
I[] i0 = [new C, new C];
assert(cast(C) i0[0]); // fine
C[] c = [new C, new C];
I[] i1 = cast(I[]) c;
assert(cast(C) i1[0]); // fails
It works when I create an I[] from a C[] literal, but not when I
cast a previously declared C[] to an I[].
On Tuesday, 16 September 2014 at 08:49:04 UTC, Marc Schütz wrote:
On Tuesday, 16 September 2014 at 08:39:43 UTC, Marc Schütz
wrote:
Whether the compiler should accept that or not is a different
question. I guess it should, because if it doesn't, there
wouldn't be an easy way to achieve a
On Tuesday, 16 September 2014 at 06:27:59 UTC, Klaus wrote:
is just a horrible way of shortcuting the static typing. You
write this thinking that i has to be... and then you complain
latter because the cast does not work.
D is a strongly typed lang. in your example you use auto
because your
On Tuesday, 16 September 2014 at 14:13:48 UTC, Marc Schütz wrote:
On Tuesday, 16 September 2014 at 11:26:05 UTC, rcor wrote:
Is to! creating a new array of pointers while cast isn't? This
isn't a performance critical section and it's not a huge
array, so I ask mostly out of curiosity.
Yes,
I'm trying to make a game, and would like to set up the following
hierarchy:
At any time, the game is in one Scene. Each scene has a state
machine that manages States of type T, where T is the type of the
scene (e.g. Overworld, Menu).
abstract class State!T {
void update(T scene, float
On Monday, 20 October 2014 at 06:17:42 UTC, Jacob Carlborg wrote:
You can always make Scene a template class:
abstract class Scene (T)
{
private StateMachine!T _stateMachine;
}
class MainMenu : Scene!(MainMenu) {}
But I'm guessing you like to avoid that if possible.
I would, as I need
If the state machine doesn't need to be exposed you can create
base class for Scene which is not templated:
abstract class Scene {} // As it is now minus the state machine
abstract class ConcreteScene (T) : Scene
{
private StateMachine!T _stateMachine;
// other code that need access
On Sunday, 9 November 2014 at 09:14:14 UTC, ketmar via
Digitalmars-d-learn wrote:
On Sun, 09 Nov 2014 08:26:57 +
Suliman via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
Do you often need debugger when you are writing code?
almost never.
For which tasks debugger are
25 matches
Mail list logo
