Re: CTFE difference between dmd and ldc2
On Thursday, 29 December 2016 at 09:57:25 UTC, Joseph Rushton Wakeling wrote: On Thursday, 29 December 2016 at 09:24:23 UTC, Joseph Rushton Wakeling wrote: Sorry for delay in following up on this. Yes, the same problem occurs with dmd 2.071 (as installed from the deb package downloaded from dlang.org). Specifically, I tested with 2.071.2, which I understand is the exact same frontend version as LDC 1.1.0-beta6. So, looks like the issue could be backend-related? Just to re-raise the issue: it's a blocker for what would otherwise be quite a nice and useful PR for Phobos: https://github.com/dlang/phobos/pull/5011 Assuming a fix is not on the cards any time soon, if anyone could suggest an alternative way to achieve the desired result, I'd be very grateful. I should probably also create a formal issue for this. Any thoughts on how best to break it down into a minimal example? It does not appear easy to do so at first glance :-\
template instance does not match template declaration
Hi,
On my first attempt to create a templated class, I'm hitting an
issue that I can't seem to resolve.
I've dustmite'd the code down to:
class Cache(O, K, F)
{
}
void main()
{
class BasicObject
{
}
BasicObject lookupBasicObject() {
}
Cache!(BasicObject, string, lookupBasicObject);
}
and I'm hitting the following error:
cache.d(23): Error: template instance Cache!(BasicObject, string,
lookupBasicObject) does not match template declaration Cache(O,
K, F)
Any help would be much appreciated in understanding what I am
doing wrong.
Thanks.
Take care,
Fabrice.
Re: template instance does not match template declaration
On Sunday, 8 January 2017 at 03:27:26 UTC, Fabrice Marie wrote:
Hi,
On my first attempt to create a templated class, I'm hitting an
issue that I can't seem to resolve.
I've dustmite'd the code down to:
class Cache(O, K, F)
{
}
void main()
{
class BasicObject
{
}
BasicObject lookupBasicObject() {
}
Cache!(BasicObject, string, lookupBasicObject);
}
and I'm hitting the following error:
cache.d(23): Error: template instance Cache!(BasicObject,
string, lookupBasicObject) does not match template declaration
Cache(O, K, F)
Any help would be much appreciated in understanding what I am
doing wrong.
Thanks.
Take care,
Fabrice.
By default template parameters are Types. lookupBasicObject is
not.
change this `class Cache(O, K, F)` to `class Cache(O, K, alias F)`
and it should work.
Re: template instance does not match template declaration
On Sunday, 8 January 2017 at 03:27:26 UTC, Fabrice Marie wrote:
void main()
{
Cache!(BasicObject, string, lookupBasicObject);
}
In addition to what Nicholas Wilson said, what you're doing here
is the equivalent of writing `int;`. It doesn't make any sense as
Cache!(...) is a type, and you are declaring a variable of that
type... except you're not providing a variable name so the syntax
is wrong. After you've fixed the other problem change it to this:
Cache!(BasicObject, string, lookupBasicObject) c;
Re: Resources for using std.allocator
On Saturday, 7 January 2017 at 19:50:14 UTC, dewitt wrote: On Wednesday, 4 January 2017 at 04:50:55 UTC, xtreak wrote: I am newbie to D learning it for sometime using Ali's book. I came across std.experimental.allocator and read through http://dlang.org/library/std/experimental/allocator/building_blocks.html . Can someone explain me the actual benefits of using this and if so any benchmarks explaining the advantage. Maybe its too advanced for me as a beginner now its just I am curious over the usage and applications with a simple hello world like example explaining what this library will accomplish. I asked it previously at https://www.reddit.com/r/programming/comments/4hti33/dconf_2016_is_streaming_right_now/d2satic/ but still I don't understand the exact applications of the same. Allocators might be a good addition to the articles pages on the website. Not sure if this has been discussed or if we are adding much there. You may also consider making a PR to the Dlang Tour: https://tour.dlang.org There's already an open issue about a "@nogc gem": https://github.com/dlang-tour/english/issues/10
Re: Iterate module membres
On Saturday, 7 January 2017 at 13:45:53 UTC, crimaniak wrote: Ok, I found it: https://issues.dlang.org/show_bug.cgi?id=16044 yep. sorry, my search-fu is completely broken, so i didn't provide you with the number.
Re: Iterate module membres
On Saturday, 7 January 2017 at 12:11:20 UTC, crimaniak wrote: Is this a bug or documentation problem? well, it's hard to say. package.d is one of the cases where you *have* to provide explicit module definition. ;-) 'cause implicit one creates module with name `package`, which is teh keyword. and then all the hell broke loose. this actually may be both bug and documentation problem.
Re: Iterate module membres
On Saturday, 7 January 2017 at 10:38:29 UTC, ketmar wrote:
On Saturday, 7 January 2017 at 10:27:51 UTC, Nicholas Wilson
wrote:
Do you require a module statement per chance?
it doesn't matter. if there is no explicit module declaration,
compiler will insert implicit one. from the code PoV, there is
no difference at all.
Yes, module statement is no reason. package.d is reason. The
same code in two files:
class foo{};
struct bar{};
pragma (msg, "allMembers of "~__MODULE__~" in "~__FILE__);
pragma(msg, __traits(allMembers, mixin(__MODULE__)));
Result:
allMembers of vcm.bll.event in source/vcm/bll/event/package.d
tuple()
allMembers of vcm.bll.event.test in source/vcm/bll/event/test.d
tuple("object", "vcm", "foo", "bar")
So allMembers gives empty tuple for module in package.d file.
Please check it. As I understand documentation, package.d is
ordinary module and special here is only file name used when
module name is directory.
DMD 2.071.1. Is this a bug or documentation problem?
Re: Iterate module membres
p.s.: otherwise, it *should* work with explicit module declaration. but then, we have some well-known bugs with cross-module introspection, and some heisenbugs with package introspection.
Re: Iterate module membres
On Saturday, 7 January 2017 at 12:29:34 UTC, ketmar wrote: On Saturday, 7 January 2017 at 12:11:20 UTC, crimaniak wrote: Is this a bug or documentation problem? well, it's hard to say. package.d is one of the cases where you *have* to provide explicit module definition. ;-) 'cause implicit one creates module with name `package`, which is teh keyword. and then all the hell broke loose. this actually may be both bug and documentation problem. Yes, removing 'module' statement leads to error on __traits(allMembers, mixin(__MODULE__)) expression: Error: expression expected, not 'package'. But it's not related, I provide module statement in package.d.
Re: Really easy optimization with std.experimental.allocator
On Sunday, 18 September 2016 at 01:44:10 UTC, Ryan wrote: I think it works because each time you call dispose it tells the GC to mark that memory as available, without the GC needing to do a collection sweep. This could be a really useful tip in the allocators section, as I see converting to IAllocator with the GC as the first step in testing optimizations with allocators. A bit more than that - because you dispose and allocate same amount of memory, you effectively reuse same memory block in GC pools over and over again. It is hardly surprising that this is much faster than "honest" allocation of lot of memory across different pools (CPU memory cache access pattern alone will make a huge difference).
Primality test function doesn't work on large numbers?
I'm working on writing an RSA implementation, but I've run into a roadblock generating primes. With a more than 9 bits, my program either hangs for a long time (utilizing %100 CPU!) or returns a composite number. With 9 or fewer bits, I get primes, but I have to run with a huge number of iterations to actually _get_ a random number. It runs fast, though. Why might this be? Code: http://lpaste.net/1034777940820230144
Re: Iterate module membres
Ok, I found it: https://issues.dlang.org/show_bug.cgi?id=16044
Iterate module membres
Hi!
I need to iterate module members and find specific classes (and
make tuple).
class foo{};
pragma (msg, __traits(allMembers,mixin(__MODULE__)));
gives me empty tuple. I found also this thread from 2011:
http://forum.dlang.org/post/mailman.325.1293887146.4748.digitalmars-d-le...@puremagic.com
This is exactly what I need but this code also gives empty tuple.
Is this possible for now to iterate classes from module? Is this
possible to iterate by classes, public imported to module? (in
fact, I need to iterate classes imported using package.d file).
Re: Iterate module membres
On Saturday, 7 January 2017 at 09:46:54 UTC, crimaniak wrote:
Hi!
I need to iterate module members and find specific classes (and
make tuple).
class foo{};
pragma (msg, __traits(allMembers,mixin(__MODULE__)));
gives me empty tuple.
works like a charm both in 2.071 and in git HEAD.
Re: Iterate module membres
On Saturday, 7 January 2017 at 09:46:54 UTC, crimaniak wrote:
Hi!
I need to iterate module members and find specific classes (and
make tuple).
class foo{};
pragma (msg, __traits(allMembers,mixin(__MODULE__)));
gives me empty tuple. I found also this thread from 2011:
http://forum.dlang.org/post/mailman.325.1293887146.4748.digitalmars-d-le...@puremagic.com
This is exactly what I need but this code also gives empty
tuple.
Is this possible for now to iterate classes from module? Is
this possible to iterate by classes, public imported to module?
(in fact, I need to iterate classes imported using package.d
file).
Do you require a module statement per chance?
Re: Iterate module membres
On Saturday, 7 January 2017 at 10:27:51 UTC, Nicholas Wilson wrote: Do you require a module statement per chance? it doesn't matter. if there is no explicit module declaration, compiler will insert implicit one. from the code PoV, there is no difference at all.
