Re: onDispatch demo not compiling
On Thu, 21 Aug 2014 05:39:14 + Shachar via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: auto onDispatch(string m, Args...)(Args args) first: opDispatch, not onDispatch. second: underscoresToCamelCase() can't be evaluated in compile-time anymore. the necessary changes: 1. add 'import std.string' -- we need toUpper() from this module. 2. change toupper(c) to toUpper(c) (first thing why ctfe fails) 3. remove 'result.reserve(sym.length);' line (second thing why ctfe fails). 4. uncomment 'return' in opDispatch. %-) that will do the trick. to check if underscoresToCamelCase() can be evaluated in compile time, you can add this line to the first unittest block: enum t = underscoresToCamelCase(hello_world); then compiler will tell you why it can't evaluate the function. signature.asc Description: PGP signature
Re: onDispatch demo not compiling
On Thu, 21 Aug 2014 05:39:14 +
Shachar via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
that's it: failing to evaluate opDispatch() template is not a
compilation error. compiler will silently try to find direct method if
opDispatch() fails. so be very careful with it.
you can add pragma(msg, ...) to your opDispatch to see if it really
compiles without errors. i.e.
auto onDispatch(string m, Args...)(Args args) {
pragma(msg, m=~m);
enum t = underscoresToCamelCase(t);
pragma(msg, t=~t);
return mixin(this.~t~(args));
}
you should see output of this pragmas in compile-time. if you can't see
t, for example, it means that evaluation of underscoresToCamelCase()
failed.
signature.asc
Description: PGP signature
Re: onDispatch demo not compiling
On Thursday, 21 August 2014 at 06:11:06 UTC, ketmar via Digitalmars-d-learn wrote: that will do the trick. Indeed. I ended up simply directly calling a.opDispatch!do_something_cool(5, 6), which brought most of those issues to light. Shachar
Re: onDispatch demo not compiling
On Thu, 21 Aug 2014 06:34:10 + Shachar via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Indeed. I ended up simply directly calling a.opDispatch!do_something_cool(5, 6), which brought most of those issues to light. ah, silly me. i forgot about such simple thing. signature.asc Description: PGP signature
Re: Can you explain this?
On Wednesday, 20 August 2014 at 20:18:15 UTC, Dicebot wrote:
On Wednesday, 20 August 2014 at 20:01:05 UTC, Colin wrote:
I see 3 distinct parts playing a role in my confusion:
A) The 'is' keyword. What does it do when you have
is(expression);
http://dlang.org/expression.html#IsExpression
It is a tool for type checking. It has many options but plain
`is(T)` checks if `T` is a valid type and returns `true` if it
is. `void` is considered a valid type.
B) typeof( expression ); whats this doing? Particularly when
the expression its acting on is a closure that returns
nothing? (at least as far as I can see)
typeof(() {}) evaluates to void:
static assert(is(typeof(() {}) == void));
However, if any compilation errors happen inside the delegate,
it evaluates to special invalid type which yield `false` when
supplied to `is` expression.
Thus `is(typeof(expr))` is a way to express a concept if
`expr` compiles. Delegate is necessary to test statements
because `typeof` only accepts expressions.
C) The closure expression:
(inout int = 0) {
// Check to see if I can do InputRangy stuff...
}
Why is there a need for that inout int = 0 clause at the start
of it?
Now this is a really weird one. This is necessary for input
ranges with `inout` functions to fit the trait because `inout`
variables can be declared only inside `inout` functions. See
this bug report for details :
https://issues.dlang.org/show_bug.cgi?id=7824
It is one of surprising feature inter-operation cases you don't
expect when designing features :)
Thanks all, that explains it.
It is weird looking code alright, but I guess it has its uses.
I think I prefer the __traits(compiles,...) construct, as it is a
bit more obvious as to what I'm checking. So will use that I
suspect.
Cheers!
Auto-add static field when inherit // mixins, templates?
tl;dr - how to get child classname from inherited parent function
at compile time?
class A { string getName(); };
class B { };
B foo = new B;
assert(foo.getName() == B);
...
Hi! I'm stuck at one issue, and I don't know how to solve it. I
think this is about mixins/templates, isn't it?
When inherit from base class Component, I need to auto-create
child own static fields with child type.
It should look like this, after compilation:
class Component
{
//it doesn't matter to have any fields here
//but it's important to be able to create an instance of
Component
//and when inherit, all childs will get their own static T
list; where T is a type of child.
};
class Sprite:Component
{
static Sprite list; //auto-added
static void fun() { } //auto-added, operates with Sprite
}
class Camera:Component
{
static Camera list; //auto-added
static void fun() { } //auto-added, operates with Camera
instead of Sprite
}
...
//so this must be correct:
Component foo;
Sprite bar;
void foobar(Component one) { }
foobar(Sprite);
...
Sorry for bad English.
Best regards, Alex
Re: goto skips declaration of variable
On Tuesday, 19 August 2014 at 20:33:00 UTC, monarch_dodra wrote:
On Monday, 18 August 2014 at 13:51:14 UTC, nrgyzer wrote:
Hi all,
I've the following code snipped:
import std.bigint;
void main(string[] args)
{
BigInt i = 12345;
if (args.length 1)
{
goto Exit;
}
i = BigInt(67890);
Exit:
return;
}
For what it's worth, whenever you have goto-end style code,
place all your code in a proper block, in such a way that all
your variable declarations are in that block, and all your
gotos break out of this block. This way, a goto will *never*
cross a declaration, so coding is easy. The only variables you
place at the top or the ones that could need cleanup.
void main(string[] args)
{
//Declarations that need cleanup:
void* p;
//Code
{
BigInt i = 12345; //Local variable
if (args.length 1)
{
goto Exit; //Breaks out of block
}
i = BigInt(67890);
BigInt j = 54321; //Local variable
}
//End
Exit:
CleanUp(p);
return;
}
Yes, that works. I'm using the goto-command to exit my function
if an error (not necessarily an exception) occured. Sure, I can
simply do a return, but I personally prefer a fixed endpoint of
my functions. This also simplifies debugging my application
because I don't need 10 or 20 breakpoints (one before each
return-point).
Re: Auto-add static field when inherit // mixins, templates?
I found a rough solution. It's not ideal and I still want to make
autoinject, but it works.
mixin template Manager(T) {};
class Component {};
class Sprite:Component
{
mixin Manager!Sprite;
};
1) How to make mixin inject automatic?
2) If it's impossible, how to use mixin Manager; without
!Sprite ?
mixin template Manager(this T) {}; isn't working.
Regards, Alex
On Thursday, 21 August 2014 at 09:38:13 UTC, MarisaLovesUsAll
wrote:
tl;dr - how to get child classname from inherited parent
function at compile time?
class A { string getName(); };
class B { };
B foo = new B;
assert(foo.getName() == B);
...
Hi! I'm stuck at one issue, and I don't know how to solve it. I
think this is about mixins/templates, isn't it?
When inherit from base class Component, I need to auto-create
child own static fields with child type.
It should look like this, after compilation:
class Component
{
//it doesn't matter to have any fields here
//but it's important to be able to create an instance of
Component
//and when inherit, all childs will get their own static T
list; where T is a type of child.
};
class Sprite:Component
{
static Sprite list; //auto-added
static void fun() { } //auto-added, operates with Sprite
}
class Camera:Component
{
static Camera list; //auto-added
static void fun() { } //auto-added, operates with Camera
instead of Sprite
}
...
//so this must be correct:
Component foo;
Sprite bar;
void foobar(Component one) { }
foobar(Sprite);
...
Sorry for bad English.
Best regards, Alex
Re: Auto-add static field when inherit // mixins, templates?
On Thursday, 21 August 2014 at 12:58:13 UTC, MarisaLovesUsAll
wrote:
I found a rough solution. It's not ideal and I still want to
make autoinject, but it works.
mixin template Manager(T) {};
class Component {};
class Sprite:Component
{
mixin Manager!Sprite;
};
1) How to make mixin inject automatic?
You could use this pattern:
interface Component {}
class ComponentImpl(T) {}
class Sprite : ComponentImpl!Sprite {}
It's not 100% automatic, but the duplication of Sprite is in
the same line. And it's not as easy to forget as a mixin,
especially when Component does declare methods that ComponentImpl
implements.
2) If it's impossible, how to use mixin Manager; without
!Sprite ?
mixin template Manager(this T) {}; isn't working.
You can use `typeof(this)` in Manager:
mixin template Manager()
{
void someMethod(typeof(this) otherInstance) {}
}
Generating a tree structure
I'm trying to make a tree data structure in part of my first non-trivial D-based program. Turns out that DMD likes to re-use PODs - sounds good, but that trapped me, and I'm not sure how to clear myself out of the problem nicely. My simplified, but not oversimplified, example is http://dpaste.dzfl.pl/67b022ca029e You'll note in the output of the program several duplicated values for self and the parent value goes to places other than the parent. This is all wrong, and shows my ignorance, but is as far as I've been able to work it. In my operational code I bypassed the problem by storing every leaf and branch in an array and changing the self, parent, and children properties to be indices into said array. But this feels hackish: I'd rather have the tree itself hold everything it needs. Note: I'm not stuck with a struct. I could class the thing, but I figured that a struct holds what I need simply... Thoughts, solutions?
Re: Generating a tree structure
On Thursday, 21 August 2014 at 14:09:24 UTC, Ricky C wrote: I'm trying to make a tree data structure in part of my first non-trivial D-based program. Turns out that DMD likes to re-use PODs - sounds good, but that trapped me, and I'm not sure how to clear myself out of the problem nicely. My simplified, but not oversimplified, example is http://dpaste.dzfl.pl/67b022ca029e You'll note in the output of the program several duplicated values for self and the parent value goes to places other than the parent. This is all wrong, and shows my ignorance, but is as far as I've been able to work it. In my operational code I bypassed the problem by storing every leaf and branch in an array and changing the self, parent, and children properties to be indices into said array. But this feels hackish: I'd rather have the tree itself hold everything it needs. Note: I'm not stuck with a struct. I could class the thing, but I figured that a struct holds what I need simply... Thoughts, solutions? As far as I can see, you're overwriting old trees with new ones. You store everything in tile_trees, and use pointers to its data. When you then Copy the trees into the branches and clear the forest for the next pass, the pointers still point to the now cleared old locations in tile_trees. You fill tile_trees again, reusing the same locations and pointers. Maybe try TileTree*[string] tile_trees; and auto new_tree = new TileTree(...); or make TileTree a class.
Re: Generating a tree structure
On Thursday, 21 August 2014 at 14:09:24 UTC, Ricky C wrote: TileTree* self; Don't do that. D has banned internal pointers to implement its move semantics. branches[index] = tile_trees[index]; This will make a *value-copy* of your TileTree nodes. There are good chances it'll break your tree. As a rule of thumbn when managing an Node-like structure, try to avoid storing them by value in a container. Unless you are *exceptionally* about not copying the nodes from one container to another, you'll usually end up shooting yourself in the foot. This is particularly relevant what when you have an internal pointer, as the copy will point to the old node, not itself. Try to rewrite your code to use TileTree* objects instead: http://dpaste.dzfl.pl/13194a966c07
Re: goto skips declaration of variable
On 08/21/2014 04:12 AM, nrgyzer wrote: I'm using the goto-command to exit my function if an error (not necessarily an exception) occured. Sorry to repeat myself but if an exception occurs in code before the goto, the exit code will not be executed. Of course, it may be that the function is defined 'nothrow' so my concern does not apply. Sure, I can simply do a return, but I personally prefer a fixed endpoint of my functions. Again, that is not possible in a language that has exceptions. Ali
Re: D with no druntime
There were 2 talks about bare metal D this year at the D conference. The first one is about someone able to use D on microcontrollers with a few k ram.: https://www.youtube.com/watch?v=o5m0m_ZG9e8 The second one is about someone trying to strip almost everything out and see what works: https://www.youtube.com/watch?v=qErXPomAWYI They both go through the process of striping down the runtime and showing what works. 2014-08-21 7:13 GMT+02:00 uri via Digitalmars-d-learn digitalmars-d-learn@puremagic.com: Hi All, I am playing with a small hack OS for fun and in 2066 there are these undefined refs (I have no druntime): _d_arraybounds (new to 2066) _d_assert (new to 2066) _d_unittest (new to 2066) _Dmodule_ref (also in 2065) _d_dso_registry (also in 2065) It is trivial to stub these out but it got me wondering... Is there any way to compile D that has no dependencies? Thanks, uri
Re: goto skips declaration of variable
On Thursday, 21 August 2014 at 17:39:16 UTC, Ali Çehreli wrote:
On 08/21/2014 04:12 AM, nrgyzer wrote:
I'm using the goto-command to exit my function
if an error (not necessarily an exception) occured.
Sorry to repeat myself but if an exception occurs in code
before the goto, the exit code will not be executed. Of course,
it may be that the function is defined 'nothrow' so my concern
does not apply.
Sure, I can
simply do a return, but I personally prefer a fixed endpoint
of
my functions.
Again, that is not possible in a language that has exceptions.
Ali
Sure, but what about the following pretty simple source:
bool testa(int a)
{
bool fIsValid = (a 0);
if (a 0)
goto Exit;
throw new Exception(int = 0);
Exit:
return fIsValid;
}
int main(string[] args)
{
testa(10); // Use goto
testa(-1); // Throws an exception
}
I'm absolutely aware that gotos are useless if an exception
occured before the goto appears. But in some cases they are very
useful, especially when I want prevent 10 ident-steps or
something else...
Okay, my question was answered - compiler bug. Thanks in advance!
Value of floating in JSONValue
Hi everyone,
I'm facing a problem with the JSON functions. I've to communicate
with another PC using JSON. Here's a simple snipped which shows
my problem:
import std.json;
import std.stdio;
void main()
{
double d = 1.23456789;
JSONValue j = d;
sendToRemote(toJSON(j));
}
My problem is that the remote PC receives 1.23457 instead of
1.23456789. But when I add the following:
import std.json;
import std.stdio;
void main()
{
double d = 1.23456789;
JSONValue j = d;
sendToRemote(toJSON(j));
writefln(%.8f, j.floating);
}
writefln() shows me 1.23456789. So, the value is correct. I think
the problem is the default representation of any floating point
number to string. Is there any chance I can send 1.23456789
instead of 1.23457 to my remote PC?
Note: I cannot use strings because the other PC expects a numeric
data type.
Re: Auto-add static field when inherit // mixins, templates?
On Thursday, 21 August 2014 at 13:19:06 UTC, anonymous wrote:
1) How to make mixin inject automatic?
You could use this pattern:
interface Component {}
class ComponentImpl(T) {}
class Sprite : ComponentImpl!Sprite {}
From my view, it's an architectural crutch. %)
You can use `typeof(this)` in Manager:
mixin template Manager()
{
void someMethod(typeof(this) otherInstance) {}
}
Thanks, it works.
...I also have more questions %)
When I make mixin injection in one class, I want auto-injection
in another class. How can I do this?
class Component:GameObject
{
//second injection must be here and must be automatic
};
class Sprite:Component
{
mixin Manager; //first injection must activate second
injection by misterious way
};
mixin template Manager() {}
mixin template ComponentCaster(string type) {} //where 'type' is
a type obtained from Manager
//by typeof(this).stringof. As example, Sprite.
...compile-time code generation is pain %) I think, it will be 50
times easier if we have built-in compiler script language. Or
just a library that will be able to execute code in compile time.
Sorry for Engrish.
Regards, Alex
Re: new error message in 2.066, type bool (const)
On Thursday, 21 August 2014 at 03:02:53 UTC, Paul D Anderson wrote: What changed? It ran okay with early beta versions, but not with the release. Paul It compiles in beta-5 but not beta-6. Is the list of changes in the beta testing wiki complete? None seem pertinent. monarch_dodra: Thanks for checking. I was trying to avoid tearing everything down. I was hoping someone would recognize the error. Looks like I'll have to chase it down. Paul https://github.com/CyberShadow/digger should be able to help find the exact commit. A reduced example would help us figure out what is going on though.
Re: Auto-add static field when inherit // mixins, templates?
On 8/21/14, 6:38 AM, MarisaLovesUsAll wrote:
tl;dr - how to get child classname from inherited parent function at
compile time?
class A { string getName(); };
class B { };
B foo = new B;
assert(foo.getName() == B);
...
Hi! I'm stuck at one issue, and I don't know how to solve it. I think
this is about mixins/templates, isn't it?
When inherit from base class Component, I need to auto-create child own
static fields with child type.
It should look like this, after compilation:
class Component
{
//it doesn't matter to have any fields here
//but it's important to be able to create an instance of Component
//and when inherit, all childs will get their own static T list;
where T is a type of child.
};
class Sprite:Component
{
static Sprite list; //auto-added
static void fun() { } //auto-added, operates with Sprite
}
class Camera:Component
{
static Camera list; //auto-added
static void fun() { } //auto-added, operates with Camera instead of
Sprite
}
...
//so this must be correct:
Component foo;
Sprite bar;
void foobar(Component one) { }
foobar(Sprite);
...
Sorry for bad English.
Best regards, Alex
I'll tell you how it's done in Crystal in case someone wants to come up
with a proposal to make it work in D.
~~~
class Foo
macro inherited
def method_in_{{@class_name.downcase.id}}
puts Hello {{@class_name.id}}!
end
end
end
class Bar Foo
end
Bar.new.method_in_bar #= Hello Bar!
~~~
When you inherit a class, the macro inherited is automatically
executed by the compiler in the context of the inheriting class. There
you can use special variables like @class_name and interpolate them
with {{ ... }}.
I guess a similar thing to do in D would be to define a function to be
executed at compile time and automatically mix it, and the context of
execution would be the inherited class.
(sorry if this is of no interest to all of you, let me know if I should
stop trying to bring ideas to D from other languages)
Re: Auto-add static field when inherit // mixins, templates?
On Thursday, 21 August 2014 at 19:58:18 UTC, MarisaLovesUsAll
wrote:
When I make mixin injection in one class, I want auto-injection
in another class. How can I do this?
class Component:GameObject
{
//second injection must be here and must be automatic
};
class Sprite:Component
{
mixin Manager; //first injection must activate second
injection by misterious way
};
I don't think this is possible.
mixin template Manager() {}
mixin template ComponentCaster(string type) {} //where 'type'
is a type obtained from Manager
//by typeof(this).stringof. As example, Sprite.
Maybe you can explain what you're trying to achieve with all
this. There may be a different/better way to do it.
Re: Auto-add static field when inherit // mixins, templates?
On Thursday, 21 August 2014 at 20:05:13 UTC, Ary Borenszweig
wrote:
I'll tell you how it's done in Crystal in case someone wants to
come up with a proposal to make it work in D.
~~~
class Foo
macro inherited
def method_in_{{@class_name.downcase.id}}
puts Hello {{@class_name.id}}!
end
end
end
class Bar Foo
end
Bar.new.method_in_bar #= Hello Bar!
~~~
I think such a feature would clash with a D principle: A base
class (Foo) cannot know about (or depend on) all its subclasses
(Bar), because it may be compiled separately from them.
Now, if it were only about printing the most derived class name
(I know, it isn't), you could that in D with typeid:
import std.stdio;
class Foo
{
void whoami()
{
writeln(typeid(this));
}
}
class Bar : Foo {}
void main()
{
Foo f = new Bar;
f.whoami();
}
Re: Auto-add static field when inherit // mixins, templates?
On Thursday, 21 August 2014 at 20:16:33 UTC, anonymous wrote:
Maybe you can explain what you're trying to achieve with all
this. There may be a different/better way to do it.
Sure.
Class tree: GameObject-Component-Sprite.
GameObject structure:
Component[];
Component addComponent(Component component);
First feature is Components Manager. It's an array and
register()/remove() functions, just like in GameObject, but it's
static and unique to all inherited classes.
static T[] list;
static void register(T obj);
static void remove(T obj);
So, if I do this
class Sprite:Component {};
'T' becomes 'Sprite', and Manager functionality adds to class.
It also will be able to create instance of class Component
because of Components list in GameObject. And Component type must
be one because it's easier to use one name for inheritance and
for storing Components.
I did this by mixins, but it's not automatic.
And second feature. When I create Sprite and add it in
GameObject, there will be no 'cast(Sprite)' constructions; type
of return value must be argument's type.
Code:
Component addComponent(Component component);
Sprite shell = cast(Sprite) this.addComponent(new
Sprite(shell_1.png)); //I want remove 'cast(Sprite)' from here
I found a solution for one class:
class Component
{
Sprite toSprite() @property
{
return cast(Sprite) this;
}
alias toSprite this;
}
And it works. Now I want to add this solution in class Component,
working with all inherited classes.
As I realize, this is rough and impossible, and I need to do some
template magic in GameObject code.
Sorry for Engrish.
Regards, Alex
Re: Value of floating in JSONValue
On 08/21/2014 11:53 AM, nrgyzer wrote:
double d = 1.23456789;
JSONValue j = d;
sendToRemote(toJSON(j));
}
My problem is that the remote PC receives 1.23457 instead of
1.23456789.
I think it is due to the following code simply calling to!string in
std/phobos/json.d:
case JSON_TYPE.FLOAT:
json.put(to!string(value.store.floating));
break;
But when I add the following:
import std.json;
import std.stdio;
void main()
{
double d = 1.23456789;
JSONValue j = d;
sendToRemote(toJSON(j));
writefln(%.8f, j.floating);
}
writefln() shows me 1.23456789. So, the value is correct.
It is more precise but still not correct because that specific double
value cannot be represented exactly.
Is there any chance I can send 1.23456789
instead of 1.23457 to my remote PC?
You can call a function like the following:
import std.string;
import std.json;
import std.stdio;
string morePrecisely(double d)
{
return format(%.20g, d);
}
void main()
{
double d = 1.23456789;
JSONValue root = [ value : d.morePrecisely ];
writeln(toJSON(root));
}
Of course do something more sensible than hard-coding the 20 in that
format string. :)
Note: I cannot use strings because the other PC expects a numeric
data type.
I don't think it is a concern as JSON does not encode types. It is up to
the receiver how to interpret the data. Here is the output of the
program above:
{value:1.234567889998901}
Ali
Re: Value of floating in JSONValue
On Thursday, 21 August 2014 at 23:05:48 UTC, Ali Çehreli wrote:
I don't think it is a concern as JSON does not encode types. It
is up to the receiver how to interpret the data. Here is the
output of the program above:
{value:1.234567889998901}
Ali
JSON may not encode the very specific type the language that
created it was using, but it does differ between strings and
numbers. {value:1.234567889998901} is different from
{value:1.234567889998901}, virtually any JSON
implementation for any language(there might be exceptions - maybe
TCL) will parse them to different language constructs, and code
that expect one may fail, crash or misbehave when given the other.
Re: new error message in 2.066, type bool (const)
On Wednesday, 20 August 2014 at 20:46:20 UTC, Paul D Anderson
wrote:
Re-compiling existing code with version 2.066 generates a lot
of errors complaining about implicit conversion to const.
Typical is this call (inside a struct with properties 1 2):
z.sign = x.sign ^ y.sign;
Error: None of the overloads of 'sign' are callable using
argument types bool (const), candidates are:
1) @property
@safe
bool sign() const
{
return signed;
}
2) @property
@safe
bool sign(in bool value)
{
signed = value;
return signed;
}
What changed? It ran okay with early beta versions, but not
with the release.
Paul
The problem (not obvious from the above) is that a templated type
is bringing its qualifiers into the template.
Here is a small example:
T add(T)(in T x, in T y)
{
T z;
z = x + y;
return z;
}
void main()
{
const double a = 1.0;
const double b = 2.0;
double c;
c = add(a,b);
}
Error: Cannot modify immutable expression z
---
Since a and b are const double the deduced template type is also
const double. Then when z is declared as type T it is also const.
This compiled and ran in beta 5 but not in beta 6.
If I modify the above so that declaration and assignment are
performed at the same time:
T z = x + y;
This compiles and assigns the (const double) value 3.0 to z.
After the function call c contains the double value 3.0, but it
is no longer const.
The error can be avoided by declaring z to be of type Unqual!T in
most cases.
I don't know if this is expected behavior that just wasn't
enforced before, or if this is something new. Either way I don't
like it. And I'm a little surprised I'm the only one affected by
this. I'll keep digging.
Paul
Trouble reproducing compilation error
I'm currently receiving several errors when trying to compile this code with DMD 2.066 (beginning with RC1): https://github.com/Xinok/XSort The compiler throws an error because it's unable to deduce a type for the predicate in a few places. This repository compiles just fine in DMD 2.065 and earlier (more specifically, 2.066 beta 5 and earlier). I'm very certain that this is a bug given that I never experienced this issue before. However, I'm finding it impossible to reproduce the bug so I can file a bug report. I'm not sure what exactly is causing it or if there's something specific in the context of this code that's triggering it. The only thing that I can deduce is that, in each case, an instance variable is being compared to an array element, e.g.: int[] arr = [10, 20, 30]; int value = arr[0]; pred(value, arr[1]); // Instance variable compared to array element This one is stumping me and I could use some help in tracking down this bug.
Re: Trouble reproducing compilation error
This is the full compiler output: combsort.d(90): Error: template D main.pred cannot deduce function from argument types !()(uint, uint), candidates are: benchsort.d(37):benchsort.main.pred(T)(T a, T b) benchsort.d(81): Error: template instance combsort.combSortLinear!(pred, uint[]) error instantiating combsort.d(135): Error: template D main.pred cannot deduce function from argumen t types !()(uint, uint), candidates are: benchsort.d(37):benchsort.main.pred(T)(T a, T b) combsort.d(151): Error: template D main.pred cannot deduce function from argumen t types !()(uint, uint), candidates are: benchsort.d(37):benchsort.main.pred(T)(T a, T b) benchsort.d(82): Error: template instance combsort.combSortGallop!(pred, uint[]) error instantiating forwardsort.d(218): Error: template D main.pred cannot deduce function from argu ment types !()(uint, uint), candidates are: benchsort.d(37):benchsort.main.pred(T)(T a, T b) forwardsort.d(138): Error: template D main.pred cannot deduce function from argu ment types !()(uint, uint), candidates are: benchsort.d(37):benchsort.main.pred(T)(T a, T b) forwardsort.d(52): Error: template D main.pred cannot deduce function from argum ent types !()(uint, uint), candidates are: benchsort.d(37):benchsort.main.pred(T)(T a, T b) benchsort.d(84): Error: template instance forwardsort.forwardSort!(pred, uint[]) error instantiating heapsort.d(119): Error: template D main.pred cannot deduce function from argumen t types !()(uint, uint), candidates are: benchsort.d(37):benchsort.main.pred(T)(T a, T b) heapsort.d(102): Error: template D main.pred cannot deduce function from argumen t types !()(uint, uint), candidates are: benchsort.d(37):benchsort.main.pred(T)(T a, T b) benchsort.d(99): Error: template instance heapsort.heapSort!(pred, false, uint[] ) error instantiating heapsort.d(119): Error: template D main.pred cannot deduce function from argumen t types !()(uint, uint), candidates are: benchsort.d(37):benchsort.main.pred(T)(T a, T b) heapsort.d(102): Error: template D main.pred cannot deduce function from argumen t types !()(uint, uint), candidates are: benchsort.d(37):benchsort.main.pred(T)(T a, T b) benchsort.d(101): Error: template instance heapsort.heapSort!(pred, true, uint[] ) error instantiating heapsort.d(221): Error: template D main.pred cannot deduce function from argumen t types !()(uint, uint), candidates are: benchsort.d(37):benchsort.main.pred(T)(T a, T b) benchsort.d(103): Error: template instance heapsort.bottomUpHeapSort!(pred, fals e, uint[]) error instantiating heapsort.d(221): Error: template D main.pred cannot deduce function from argumen t types !()(uint, uint), candidates are: benchsort.d(37):benchsort.main.pred(T)(T a, T b) benchsort.d(104): Error: template instance heapsort.bottomUpHeapSort!(pred, true , uint[]) error instantiating insertionsort.d(45): Error: template D main.pred cannot deduce function from arg ument types !()(uint, uint), candidates are: benchsort.d(37):benchsort.main.pred(T)(T a, T b) benchsort.d(108): Error: template instance insertionsort.insertionSort!(pred, ui nt[]) error instantiating
RAII limitations in D?
What would be a good answer to this article?
http://swiftcoder.wordpress.com/2009/02/18/raii-why-is-it-unique-to-c/
Especially the part mentioning D:{
D’s scope keyword, Python’s with statement and C#’s using declaration all
provide limited RAII, by allowing resources to have a scoped lifetime, but
none of them readily or cleanly support the clever tricks allowed by C++’s
combination of smart pointers and RAII, such as returning handles from
functions, multiple handles in the same scope, or handles held by multiple
clients.
}
This morning I was pointing to some deprecated usage of scope mentioned in
docs (EMAIL:scope classes mentioned in tutorials, but deprecated). The pull
request (https://github.com/D-Programming-Language/dlang.org/pull/637/files)
mentions using struct or classes allocated on the stack via
typecons.scoped. However what about the RAII usage mentioned in the above
article that allows C++ to return handles for eg (impossible via scope),
that get deterministically destroyed?
Re: RAII limitations in D?
http://dlang.org/phobos/std_typecons.html#.RefCounted
Re: RAII limitations in D?
On Friday, 22 August 2014 at 02:22:16 UTC, Timothee Cour via Digitalmars-d-learn wrote: What would be a good answer to this article? It's own publication date: Feb 2009. The D struct has changed a lot since then, getting new features (@disable, postblit, more reliable destructor) and bugs notwithstanding is pretty well on point nowadays. All the stuff mentioned in there works now.
Re: RAII limitations in D?
On Thu, Aug 21, 2014 at 7:26 PM, Dicebot via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: http://dlang.org/phobos/std_typecons.html#.RefCounted That doesn't work with classes though; is there any way to get a ref counted class? (and btw RefCounted should definitely appear in http://dlang.org/cpptod.html#raii)
Re: new error message in 2.066, type bool (const)
On Friday, 22 August 2014 at 01:25:05 UTC, Paul D Anderson wrote: On Wednesday, 20 August 2014 at 20:46:20 UTC, Paul D Anderson I don't know if this is expected behavior that just wasn't enforced before, or if this is something new. Either way I don't like it. And I'm a little surprised I'm the only one affected by this. I'll keep digging. Paul https://issues.dlang.org/show_bug.cgi?id=13351
Re: RAII limitations in D?
On Friday, 22 August 2014 at 03:00:01 UTC, Timothee Cour via Digitalmars-d-learn wrote: On Thu, Aug 21, 2014 at 7:26 PM, Dicebot via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: http://dlang.org/phobos/std_typecons.html#.RefCounted That doesn't work with classes though; is there any way to get a ref counted class? (and btw RefCounted should definitely appear in http://dlang.org/cpptod.html#raii) It can be made to work with classes and probably should be. There's no fundamental reason why it can't. It's probably just more complicated. - Jonathan M Davis
Re: RAII limitations in D?
On Friday, 22 August 2014 at 02:22:16 UTC, Timothee Cour via
Digitalmars-d-learn wrote:
Especially the part mentioning D:{
D’s scope keyword, Python’s with statement and C#’s using
declaration all
provide limited RAII, by allowing resources to have a scoped
lifetime, but
none of them readily or cleanly support the clever tricks
allowed by C++’s
combination of smart pointers and RAII, such as returning
handles from
functions, multiple handles in the same scope, or handles held
by multiple
clients.
}
Even for C# those are not really problems. Returning from
functions is not a problem: you just return it and that's it,
because resource management is decoupled from types, the types
have no RAII semantics and you can move them around however you
want. On the other hand, in C# it's very easy to declare a
resource, while in C++ you would need to learn all the black
magic of RAII before you can declare a RAII type. Multiple
handles in the same scope are not frequent, nested if's cause
much more trouble. Handles held by multiple clients are even more
rare, and it's usually easy to figure out lifetime for non-memory
resources.
