Re: Indivisual Incremental Compalation with dub
On Thursday, 13 August 2015 at 05:42:38 UTC, Freddy wrote: I have a file that takes a while to compile with a static interface. Is there any way i can make dub keep the object file of only that file(for faster compilation)? I don't think dub itself can do this, but https://github.com/atilaneves/reggae should be able to do it. And it will parse/understand your dub configuration file.
Re: SList container problem
On Thursday, 13 August 2015 at 08:40:13 UTC, ted wrote:
have upgraded from 2.066.1 to 2.068.0, and have a change in
behaviour:
import std.container: SList;
void main()
{
SList!int tmp;
tmp.insertAfter( tmp[], 3 );
}
used to work happily with dmd2.066.1, causes assert
(core.exception.AssertError@std/container/slist.d(57):
Assertion failure) in 2.068.0 (also 2.067.1).
There was a change in slist.d in 2.067. Am I no longer able to
start from an empty list?
--ted
tmp ~= 3; ?
SList container problem
have upgraded from 2.066.1 to 2.068.0, and have a change in behaviour:
import std.container: SList;
void main()
{
SList!int tmp;
tmp.insertAfter( tmp[], 3 );
}
used to work happily with dmd2.066.1, causes assert
(core.exception.AssertError@std/container/slist.d(57): Assertion failure)
in 2.068.0 (also 2.067.1).
There was a change in slist.d in 2.067. Am I no longer able to start from
an empty list?
--ted
vs2015 linker error
trying to comile the minimal console application generated by visuald: Building Debug\ConsoleApp1.exe... LINK : fatal error LNK1104: cannot open file 'libucrtd.lib' Building Debug\ConsoleApp1.exe failed!
Re: Code Reviewer
On Wednesday, 12 August 2015 at 13:14:04 UTC, sigod wrote: On Tuesday, 11 August 2015 at 22:50:52 UTC, Clayton wrote: Hello everyone, Am looking for someone who could help review my code . As an entry exercise to D am converting 3 C implementations of popular pattern matching algorithms. The idea is to have 6 final implementations ( 3 compile-time and 3 runtime) . I think am basically done with the coding, but being a beginner myself, I feel I need some do some critics so I can improve (especially on the compiletime ones). I could have uploaded direct but I think the code may be way too long. Help will be dearly appreciated. Use this site: http://codereview.stackexchange.com/ Thanks sigod, I have also put the compiletime code here : http://dpaste.dzfl.pl/f0bec44f859e
Re: Code Reviewer
On Wednesday, 12 August 2015 at 12:14:20 UTC, Rikki Cattermole wrote: On 13/08/2015 12:09 a.m., Clayton wrote: On Wednesday, 12 August 2015 at 02:49:59 UTC, Rikki Cattermole wrote: On 12/08/2015 10:50 a.m., Clayton wrote: [...] Upload to e.g. Github/gist/pastebin. Hi Rikki, can I have your email so I add you to my repository on BitBucket? No need, as long as it is not propriety code feel free to post the links :) That way anybody who is willing to comment can. Thanks , I have put the compiletime code here : http://dpaste.dzfl.pl/f0bec44f859e
Re: Code Reviewer
On 12/08/2015 10:50 a.m., Clayton wrote:
Hello everyone,
Am looking for someone who could help review my code . As an entry
exercise to D am converting 3 C implementations of popular pattern
matching algorithms. The idea is to have 6 final implementations ( 3
compile-time and 3 runtime) . I think am basically done with the coding,
but being a beginner myself, I feel I need some do some critics so I can
improve (especially on the compiletime ones).
I could have uploaded direct but I think the code may be way too long.
Help will be dearly appreciated.
http://dpaste.dzfl.pl/f0bec44f859e
- COMPILETIME_BM_PRE does it really need to be all caps?
- initialisebmBc interesting naming convention that
- Could do with a format (Mono-D supports this)
- ~~
void suffixes(S, I, int i:-1)(S pattern, ref int[size] suff, I size,
ref I f, ref int g){
}
void main() {
int a;
suffixes(, null, 0, a, a);
}
~
/d481/f560.d(1): Error: undefined identifier size, did you mean alias
size_t?
/d481/f560.d(5): Error: template f560.suffixes cannot deduce function
from argument types !()(string, typeof(null), int, int, int), candidates
are:
/d481/f560.d(1):f560.suffixes(S, I, int i : -1)(S pattern, ref
int[size] suff, I size, ref I f, ref int g)
Final dummy code I could get working:
~~
void suffixes(S, I, int i:-1)(S pattern, ref int[] suff, I size, ref I
f, ref int g){
}
void main() {
int a, c;
int[] b;
suffixes!(string, int, -1)(, b, 0, a, c);
}
~~
Irk, that -1 should be inside a template if condition no there and
certainly not using the colon.
Also size must be passed in at compile time if being used in the static
array like that. Otherwise pass it via a dynamic array like that.
Currently it is really ugly. Format it. Mono-D can do this.
Fix up those template arguments and function arguments. They are all wrong.
There is no way that should compile.
Re: Structs and compiletime evaluation
On Thursday, 13 August 2015 at 12:21:44 UTC, Rikki Cattermole
wrote:
On Thursday, 13 August 2015 at 12:07:48 UTC, D_Learner wrote:
I am having this struct :-
struct COMPILETIME_BM_PRE
{
void initialisebmBc(S,C,I,int k)( const S pattern ,ref
I[C] bmBc){
static if ( k ASIZE ){
bmBc[ALPHABET[k]] = size;
initialisebmBc!(S,C,I,k+1)( pattern ,bmBc);
}
}
void initialisebmBc(S,C,I,int k : ASIZE)( const S
pattern ,ref I[C] bmBc){}
[...]
No it wouldn't be. It's declared for runtime usage. Not compile
time.
Also bmBc isn't declared as an enum (can't be in fact, bug with
AA's). So even if bmh was accessible, bmBc isn't.
Thanks Rikki, but what do you mean by AA's ?
Re: Structs and compiletime evaluation
On Thursday, 13 August 2015 at 12:07:48 UTC, D_Learner wrote:
I am having this struct :-
struct COMPILETIME_BM_PRE
{
void initialisebmBc(S,C,I,int k)( const S pattern ,ref
I[C] bmBc){
static if ( k ASIZE ){
bmBc[ALPHABET[k]] = size;
initialisebmBc!(S,C,I,k+1)( pattern ,bmBc);
}
}
void initialisebmBc(S,C,I,int k : ASIZE)( const S pattern
,ref I[C] bmBc){}
[...]
No it wouldn't be. It's declared for runtime usage. Not compile
time.
Also bmBc isn't declared as an enum (can't be in fact, bug with
AA's). So even if bmh was accessible, bmBc isn't.
Structs and compiletime evaluation
I am having this struct :-
struct COMPILETIME_BM_PRE
{
void initialisebmBc(S,C,I,int k)( const S pattern ,ref I[C]
bmBc){
static if ( k ASIZE ){
bmBc[ALPHABET[k]] = size;
initialisebmBc!(S,C,I,k+1)( pattern ,bmBc);
}
}
void initialisebmBc(S,C,I,int k : ASIZE)( const S pattern
,ref I[C] bmBc){}
void calculatebmBc(S,C,I,int i)( const S pattern ,ref I[C]
bmBc)
{
static if ( i size -1 )
bmBc[pattern[i]] = size -i-1;
calculatebmBc!(S,C,I,i+1)(pattern ,bmBc);
}
I[C] preBmBc(S ,C,I)( const S pattern ,ref I[C] bmBc){
this.initialisebmBc!(S,C,I,0)( pattern ,bmBc);
this.calculatebmBc!(S,C,I,0)(pattern ,bmBc);
return bmBc;
}
}
In another module I use the struct as below :-
int[char] bmBc;
COMPILETIME_BM_PRE bmh ;
enum bmBc1 = bmh.preBmBc!(string ,char,int)( pattern , bmBc);
On last line , I get the error message : `Error: variable bmh
cannot be read at compile time` , yet I thought this value would
be evaluated at compiletime.
Re: Structs and compiletime evaluation
On 14/08/2015 12:48 a.m., D_Learner wrote:
On Thursday, 13 August 2015 at 12:21:44 UTC, Rikki Cattermole wrote:
On Thursday, 13 August 2015 at 12:07:48 UTC, D_Learner wrote:
I am having this struct :-
struct COMPILETIME_BM_PRE
{
void initialisebmBc(S,C,I,int k)( const S pattern ,ref I[C]
bmBc){
static if ( k ASIZE ){
bmBc[ALPHABET[k]] = size;
initialisebmBc!(S,C,I,k+1)( pattern ,bmBc);
}
}
void initialisebmBc(S,C,I,int k : ASIZE)( const S pattern
,ref I[C] bmBc){}
[...]
No it wouldn't be. It's declared for runtime usage. Not compile time.
Also bmBc isn't declared as an enum (can't be in fact, bug with AA's).
So even if bmh was accessible, bmBc isn't.
Thanks Rikki, but what do you mean by AA's ?
Associative Array.
Other names e.g. map.
Re: Attributes not propagating to objects via typeinfo?
On Thursday, 13 August 2015 at 03:46:19 UTC, rsw0x wrote:
Sample code:
class C{}
struct S{}
void main(){
import std.stdio;
auto c = new shared C();
auto s = new shared S();
writeln(typeid(c)); //modulename.C
writeln(typeid(s)); //shared(modulename.S)*
writeln(typeid(c).next); //null
writeln(typeid(s).next); //shared(modulename.S)
writeln(typeid(typeid(s).next) is typeid(TypeInfo_Shared));
//true
writeln(typeid(typeid(c)) is typeid(TypeInfo_Shared));
//false
}
What's the reason that the shared propagates to the typeinfo
for the struct, but not for the class declaration?
bump, is this working as intended?
complete win headers for 32/64 bit
unfortunately i can't find a complete set of windows header files. maybe one should add a link for those headers if they exist - life is not linux or osx only.
Re: complete win headers for 32/64 bit
On Thursday, 13 August 2015 at 16:28:15 UTC, learn wrote: unfortunately i can't find a complete set of windows header files. maybe one should add a link for those headers if they exist - life is not linux or osx only. I'm slowly working on getting them into the standard library. I'm probably one or two more weekends away from getting it to work (it is harder than I thought because the stdlib's build system sucks and there's an incomplete patchwork in there that needs to be cleaned up first too). In the mean time... there is a port of the mingw headers somewhere, but I don't know where anymore. maybe try searching dlang win32... Or you can just declare functions and structs as needed. I did that in simpledisplay.d for Win32, opengl, and X11 bindings: https://github.com/adamdruppe/arsd/blob/master/simpledisplay.d#L3596
Re: complete win headers for 32/64 bit
On Thursday, 13 August 2015 at 17:04:54 UTC, Adam D. Ruppe wrote: On Thursday, 13 August 2015 at 16:28:15 UTC, learn wrote: I'm slowly working on getting them into the standard library. I'm probably one or two more weekends away from getting it to work (it is harder than I thought because the stdlib's build system sucks and there's an incomplete patchwork in there that needs to be cleaned up first too). In the mean time... there is a port of the mingw headers somewhere, but I don't know where anymore. maybe try searching dlang win32... Or you can just declare functions and structs as needed. I did that in simpledisplay.d for Win32, opengl, and X11 bindings: https://github.com/adamdruppe/arsd/blob/master/simpledisplay.d#L3596 thank you for the information - and please announce it when you are finished.
Re: How do I find the actual types of the elements in a list of classes?
On Thursday, 13 August 2015 at 20:28:33 UTC, Adam D. Ruppe wrote:
On Thursday, 13 August 2015 at 20:23:56 UTC, Jack Stouffer
wrote:
As far as I can tell, there is no way to know the actual type
of each of the objects in the list to be able to print:
Cast it to Object first, then do the typeid and it will get the
dynamic class type. Since Parent is an interface, typeid works
differently.
I wrote about this in more detail recently here:
http://stackoverflow.com/questions/31563999/how-to-get-classinfo-of-object-declared-as-an-interface-type/31564253#31564253
Thanks, that worked, and based on your answer, I was able to fix
my real problem: dynamically calling different methods on each
object in the list based on its type. So, using the above code as
an example, I am able to call method if the object is of type A
and method2 if the object is of type B:
interface Parent {
void method();
}
class A : Parent {
void method() {}
this() {}
}
class B : Parent {
void method() {}
void method2() {}
this() {}
}
void main() {
import std.stdio;
import std.string;
Parent[] parent_list = [];
parent_list ~= new A();
parent_list ~= new B();
foreach (item; parent_list) {
string class_name = (cast(Object)
item).classinfo.name;
if (class_name == test.A) {
(cast(A) item).method();
} else if (class_name == test.B) {
(cast(B) item).method2();
}
}
}
This is a dirty hack, but I don't care, it works :)
Re: How do I find the actual types of the elements in a list of classes?
On Thursday, 13 August 2015 at 22:20:35 UTC, Justin Whear wrote:
foreach (item; parent_list) {
if (auto asA = cast(A)item) {
asA.method();
} else if (auto asB = cast(B)item) {
asB.method2();
}
}
On Thursday, 13 August 2015 at 22:20:35 UTC, Justin Whear wrote:
Thanks Justin and rumbu, that makes the code a lot more readable.
Re: How do I find the actual types of the elements in a list of classes?
On Thursday, 13 August 2015 at 21:42:54 UTC, Jack Stouffer wrote:
Thanks, that worked, and based on your answer, I was able to
fix my real problem: dynamically calling different methods on
each object in the list based on its type. So, using the above
code as an example, I am able to call method if the object is
of type A and method2 if the object is of type B:
interface Parent {
void method();
}
class A : Parent {
void method() {}
this() {}
}
class B : Parent {
void method() {}
void method2() {}
this() {}
}
void main() {
import std.stdio;
import std.string;
Parent[] parent_list = [];
parent_list ~= new A();
parent_list ~= new B();
foreach (item; parent_list) {
string class_name = (cast(Object)
item).classinfo.name;
if (class_name == test.A) {
(cast(A) item).method();
} else if (class_name == test.B) {
(cast(B) item).method2();
}
}
}
This is a dirty hack, but I don't care, it works :)
It works as long as your module is called test.
I think this is a better approach:
foreach (item; parent_list) {
if (auto a = cast(A)item)
a.method();
else if (auto b = cast(B)item)
b.method2();
}
Yieldable function?
Is there any way to have a yieldable function that can be resumed
at a later time in D?
Some thing like:
void test()
{
writeln(A);
yeild();
writeln(B);
}
...
auto x = yieldable!test();
x.resume(); // prints A
x.resume(); // prints B
x.resume(); // throws an error or something, i dont know..
Also how portable is the built in asm support, was thinking about
implementing this if it's not already available. Also is there a
way to define naked functions in D? I think not but they might
make implementing this a little more simple.
Re: Yieldable function?
http://dlang.org/phobos/core_thread.html#.Fiber
Re: How do I find the actual types of the elements in a list of classes?
On Friday, 14 August 2015 at 00:06:33 UTC, Adam D. Ruppe wrote:
On Thursday, 13 August 2015 at 23:48:08 UTC, Jack Stouffer
wrote:
In my code, the list can have 20-30 different types of classes
in it all inheriting from the same interface, and it doesn't
make sense for all of those classes to implement a method that
is very specific to one of the classes.
I don't want to get too far into this since I haven't seen your
code, but the function that uses this list might itself be a
candidate for addition to the interface, or a second interface
with that method that all the classes also inherit from
(remember you can only inherit from one class in D, but you can
implement as many interfaces as you want).
The code in question is a collision resolver in a 2D game that I
am making. The list is a list of all of the drawable objects that
the object could be colliding with. After collision is checked on
each of the possible collisions, the object is placed at the last
position where it was not colliding. I am using the cast in the
enemy resolver where each collision is then checked to see if the
collision was with the player, and if it was, the player is then
given damage.
-
class Blob : Enemy {
...
final override void resolveCollisions() {
import player : Player;
//check for collision
Entity[] possible_collisions =
this.state_object.getPossibleCollisions(this);
Entity[] collisions = [];
foreach (ref entity; possible_collisions) {
// discount any Rect that is equal to the player's,
as it's probably
// the players bounding box
if (this.boundingBox != entity.boundingBox
this.boundingBox.intersects(entity.boundingBox)) {
collisions ~= entity;
}
}
if (collisions.length 0) {
// If we collided with something, then put position
back to its
// original spot
this.position = this.previous_position;
// If we collided with the player, give the player
damage
foreach (collision; collisions) {
// Check to see if the object collided was a
player by testing the
// result of the cast, which will return null if
unsuccessful
if (auto player = cast(Player) collision) {
player.damagePlayer(5, this.position,
this.mass);
}
}
}
}
}
Re: Yieldable function?
On Thursday, 13 August 2015 at 22:29:17 UTC, MrSmith wrote: http://dlang.org/phobos/core_thread.html#.Fiber Man I feel like I saw that before but when I went looking for it I couldn't find it. Didn't think to check in core. :/ Welp that solves my question, thanks :D
Re: Yieldable function?
On Thursday, 13 August 2015 at 22:27:31 UTC, Tofu Ninja wrote: Also how portable is the built in asm support it varies a bit across compilers (gdc does it differently), and obviously across processors. Also is there a way to define naked functions in D? Put the `naked;` pseudo-instruction at the top of a function in an asm block. http://dlang.org/iasm.html
Re: Yieldable function?
On 08/13/2015 03:36 PM, Tofu Ninja wrote: On Thursday, 13 August 2015 at 22:29:17 UTC, MrSmith wrote: http://dlang.org/phobos/core_thread.html#.Fiber Man I feel like I saw that before but when I went looking for it I couldn't find it. Didn't think to check in core. :/ Welp that solves my question, thanks :D std.concurrency.Generator can present the yielded values as a range: http://ddili.org/ders/d.en/fibers.html#ix_fibers.Generator,%20std.concurrency Ali
Re: How do I find the actual types of the elements in a list of classes?
On Thursday, 13 August 2015 at 23:48:08 UTC, Jack Stouffer wrote: In my code, the list can have 20-30 different types of classes in it all inheriting from the same interface, and it doesn't make sense for all of those classes to implement a method that is very specific to one of the classes. I don't want to get too far into this since I haven't seen your code, but the function that uses this list might itself be a candidate for addition to the interface, or a second interface with that method that all the classes also inherit from (remember you can only inherit from one class in D, but you can implement as many interfaces as you want).
Re: How do I find the actual types of the elements in a list of classes?
On 08/13/2015 04:48 PM, Jack Stouffer wrote: On Thursday, 13 August 2015 at 22:49:15 UTC, Adam D. Ruppe wrote: On Thursday, 13 August 2015 at 21:42:54 UTC, Jack Stouffer wrote: dynamically calling different methods on each object in the list based on its type. The cleanest OO way of doing that is to put the methods you need in the interface and always call it through that. Then there's no need to cast and each child class can implement it their own way. This really doesn't make sense in the context that I am using this code in. The above code is a very reduced test case. In my code, the list can have 20-30 different types of classes in it all inheriting from the same interface, and it doesn't make sense for all of those classes to implement a method that is very specific to one of the classes. Enter the visitor pattern (or its variant 'acyclic visitor pattern'). Although, with 20-30 classes, it will be nasty to use.. :( So, downcasting like suggested seems to be the best option here. Ali
Re: How do I find the actual types of the elements in a list of classes?
On Thursday, 13 August 2015 at 21:42:54 UTC, Jack Stouffer wrote: dynamically calling different methods on each object in the list based on its type. The cleanest OO way of doing that is to put the methods you need in the interface and always call it through that. Then there's no need to cast and each child class can implement it their own way.
Re: How do I find the actual types of the elements in a list of classes?
On Thu, 13 Aug 2015 21:42:52 +, Jack Stouffer wrote:
foreach (item; parent_list) {
string class_name = (cast(Object)
item).classinfo.name;
if (class_name == test.A) {
(cast(A) item).method();
} else if (class_name == test.B) {
(cast(B) item).method2();
}
}
}
This is a dirty hack, but I don't care, it works :)
Casting actually performs this check for you, returning null if the
object can't be casted, so I'd do this:
foreach (item; parent_list) {
if (auto asA = cast(A)item) {
asA.method();
} else if (auto asB = cast(B)item) {
asB.method2();
}
}
Re: How do I find the actual types of the elements in a list of classes?
On Thursday, 13 August 2015 at 22:49:15 UTC, Adam D. Ruppe wrote: On Thursday, 13 August 2015 at 21:42:54 UTC, Jack Stouffer wrote: dynamically calling different methods on each object in the list based on its type. The cleanest OO way of doing that is to put the methods you need in the interface and always call it through that. Then there's no need to cast and each child class can implement it their own way. This really doesn't make sense in the context that I am using this code in. The above code is a very reduced test case. In my code, the list can have 20-30 different types of classes in it all inheriting from the same interface, and it doesn't make sense for all of those classes to implement a method that is very specific to one of the classes.
Compiletime Table
I was wondering how I could change the code below such the `bmBc`
is computed at compile time . The one below works for runtime but
it is not ideal since I need to know the `bmBc` table at
compile-time . I could appreciate advice on how I could improve
on this.
import std.conv:to;
import std.stdio;
int [string] bmBc;
immutable string pattern = GCAGAGAG;
const int size = to!int(pattern.length);
struct king {
void calculatebmBc(int i)()
{
static if ( i size -1 )
bmBc[to!string(pattern[i])]=to!int(size-i-1);
//bmBc[pattern[i]] ~= i-1;
calculatebmBc!(i+1)();
}
void calculatebmBc(int i: size-1)() {
}
}
void main(){
king myKing;
const int start = 0;
myKing.calculatebmBc!(start)();
//1. enum bmBcTable = bmBc;
}
Re: Compiletime Table
On Thursday, 13 August 2015 at 19:13:55 UTC, D_Learner wrote:
I was wondering how I could change the code below such the
`bmBc` is computed at compile time .
It is currently not possible to build an associative array at
compile time and keep it as a runtime table due to the
implementation.
However, looking at your code, you don't need a full AA... the
key is a single char, right?
Do something like this:
int[128] bmBc = calculate(); //
And then a line like this should work to set it in the calculate
function:
bmBc[pattern[i]] = i-1;
Adjust this code to fit you:
int[128] a = calc();
enum string pattern = abc;
int[128] calc() {
int[128] a; // local copy to work on as we build
a[pattern[0]] = 0;
return a; // return the completed table
}
This works because individual characters have a numeric value. If
they are all A-Z, you can easily fit them in a small array and
access them even faster than an associative array (doesn't even
have to be full size 128 if the only keys are the letters).
And these can be built at CTFE and stored in the program's data
segment.
How do I find the actual types of the elements in a list of classes?
Given:
interface Parent {
void method();
}
class A : Parent {
void method() {}
this() {}
}
class B : Parent {
void method() {}
void method2() {}
this() {}
}
void main() {
import std.stdio;
Parent[] parent_list = [];
parent_list ~= new A();
parent_list ~= new B();
foreach (item; parent_list) {
writeln(typeid(item));
}
}
With 2.068, it will output:
test.Parent
test.Parent
As far as I can tell, there is no way to know the actual type of
each of the objects in the list to be able to print:
test.A
test.B
Are there any workarounds for this?
Also, this fails to compile when it doesn't look like it should:
interface Parent {
void method();
}
class A : Parent {
void method() {}
this() {}
}
class B : Parent {
void method() {}
void method2() {}
this() {}
}
void main() {
import std.stdio;
Parent[] parent_list = [new A(), new B()];
foreach (item; parent_list) {
writeln(typeid(item));
}
}
Thanks.
Re: complete win headers for 32/64 bit
On Thursday, 13 August 2015 at 16:28:15 UTC, learn wrote: unfortunately i can't find a complete set of windows header files. maybe one should add a link for those headers if they exist - life is not linux or osx only. https://github.com/etcimon/windows-headers
Re: How do I find the actual types of the elements in a list of classes?
On Thursday, 13 August 2015 at 20:23:56 UTC, Jack Stouffer wrote: As far as I can tell, there is no way to know the actual type of each of the objects in the list to be able to print: Cast it to Object first, then do the typeid and it will get the dynamic class type. Since Parent is an interface, typeid works differently. I wrote about this in more detail recently here: http://stackoverflow.com/questions/31563999/how-to-get-classinfo-of-object-declared-as-an-interface-type/31564253#31564253 it is a bit of a FAQ, but there's a solid reason behind the behavior. Also, this fails to compile when it doesn't look like it should: I believe that's a well-known bug, the array literal tries to type it all to the first element instead of looking for the common types of all elements. You could explicitly cast to the interface if you needed to, I believe just casting the first one will cause it to do the rest automatically.
Re: Compiletime Table
On Thursday, 13 August 2015 at 19:13:55 UTC, D_Learner wrote:
I was wondering how I could change the code below such the
`bmBc` is computed at compile time . The one below works for
runtime but it is not ideal since I need to know the `bmBc`
table at compile-time . I could appreciate advice on how I
could improve on this.
import std.conv:to;
import std.stdio;
int [string] bmBc;
immutable string pattern = GCAGAGAG;
const int size = to!int(pattern.length);
struct king {
void calculatebmBc(int i)()
{
static if ( i size -1 )
bmBc[to!string(pattern[i])]=to!int(size-i-1);
//bmBc[pattern[i]] ~= i-1;
calculatebmBc!(i+1)();
}
void calculatebmBc(int i: size-1)() {
}
}
void main(){
king myKing;
const int start = 0;
myKing.calculatebmBc!(start)();
//1. enum bmBcTable = bmBc;
}
I think you may have some fundamental misunderstandings regarding
CTFE, templates, etc. Your code seems to be half-way between a
template-based and a CTFE-based solution.
The simple way to do compile-time computation in D is CTFE
(Compile Time Function Evaluation). That is, you write a pure
function that can be evaluated both at run-time and at
compile-time. CTFE doesn't need template parameters.
Here's some code that should do the same as yours and is
compatible with CTFE:
import std.conv: to;
import std.stdio;
int[char] calculatebmBc(string pattern) pure
{
const int size = to!int(pattern.length);
int[char] result;
foreach(i; 0 .. size - 1)
{
result[pattern[i]] = to!int(size - i - 1);
}
return result;
}
void main()
{
auto bmBc = calculatebmBc(GCAGAGAG);
enum bmBcTable = calculatebmBc(GCAGAGAG);
}
The key is that calculatebmBc is pure, i.e. it doesn't read or
write any module-level mutables.
I touched some things here and here I didn't like that are not
related to purity/CTFE.
Adam D. Ruppe already mentioned an issue with associative arrays:
This doesn't work:
static foo = calculatebmBc(GCAGAGAG);
It's annoying, but if you need that you have to use some other
data structure. See Adam's post.
Re: Compiletime Table
On Thursday, 13 August 2015 at 19:26:12 UTC, Adam D. Ruppe wrote:
On Thursday, 13 August 2015 at 19:13:55 UTC, D_Learner wrote:
I was wondering how I could change the code below such the
`bmBc` is computed at compile time .
It is currently not possible to build an associative array at
compile time and keep it as a runtime table due to the
implementation.
However, looking at your code, you don't need a full AA... the
key is a single char, right?
Do something like this:
int[128] bmBc = calculate(); //
And then a line like this should work to set it in the
calculate function:
bmBc[pattern[i]] = i-1;
Adjust this code to fit you:
int[128] a = calc();
enum string pattern = abc;
int[128] calc() {
int[128] a; // local copy to work on as we build
a[pattern[0]] = 0;
return a; // return the completed table
}
This works because individual characters have a numeric value.
If they are all A-Z, you can easily fit them in a small array
and access them even faster than an associative array (doesn't
even have to be full size 128 if the only keys are the letters).
And these can be built at CTFE and stored in the program's data
segment.
Thanks, the 128 is fine since I was considering the whole ASCII
character set . I was a bit skeptical of writing the code in that
manor though since I have to still compare runtime and
compiletime implementation performance(benchmarks ). That is why
my code seemed to mimic templating . Maybe the question would
then be, how do I force this function to be fully executed at
compiletime and later make it be executed at runntime ?
Re: iterating through a range, operating on last few elements at a time
On Fri, Aug 14, 2015 at 02:42:26AM +, Laeeth Isharc via Digitalmars-d-learn
wrote:
I have a range that is an array of structs. I would like to iterate
through the range, calling a function with the prior k items in the
range up to that point and storing the result of the function in a new
range/array.
what's the best way to do this? for low fixed k I could use zip with
staggered slices (s[3..$],s[2..$-1],s[1..$-2],s[0..$-3]) and then map.
I can't think of how to do it elegantly.
any thoughts?
Maybe something like this?
import std.algorithm;
import std.stdio;
import std.range;
auto slidingWindow(R)(R range, int k) {
return iota(k).map!(i = range.save.drop(i))
.array
.transposed;
}
void main() {
auto data = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ];
writeln(data.slidingWindow(3));
}
To apply the function to each slice, just write:
data.slidingWindow(k).map!myFunc ...
I didn't figure out how to eliminate the short slices toward the end,
but all you need to do is to somehow drop the last (k-1) elements from
the range returned by slidingWindow.
T
--
Today's society is one of specialization: as you grow, you learn more and more
about less and less. Eventually, you know everything about nothing.
iterating through a range, operating on last few elements at a time
I have a range that is an array of structs. I would like to iterate through the range, calling a function with the prior k items in the range up to that point and storing the result of the function in a new range/array. what's the best way to do this? for low fixed k I could use zip with staggered slices (s[3..$],s[2..$-1],s[1..$-2],s[0..$-3]) and then map. I can't think of how to do it elegantly. any thoughts?
Re: Attributes not propagating to objects via typeinfo?
On 8/13/15 11:59 AM, Steven Schveighoffer wrote: That is definitely a bug. It's because typeid is looking up the derived type via the vtable, but the compiler should rewrap it with 'shared' afterwards. Actually, now that I think about it, I'm not sure how the compiler can figure this out. There would have to be a way to construct a TypeInfo_Shared at runtime, which the compiler shouldn't be doing. Alternatively, it could proactively create a TypeInfo_Shared (and all the other flavors) for each class type in the runtime, and then look it up using some hash mechanism. This likely isn't fixable. What you CAN do, however, is: typeid(typeof(c)) Which should get the *static* type (and that should be TypeInfo_Shared in both struct and class instances). So likely this is not a bug, or at the best, a wontfix. -Steve
Re: Attributes not propagating to objects via typeinfo?
On 8/12/15 11:46 PM, rsw0x wrote:
Sample code:
class C{}
struct S{}
void main(){
import std.stdio;
auto c = new shared C();
auto s = new shared S();
writeln(typeid(c)); //modulename.C
writeln(typeid(s)); //shared(modulename.S)*
writeln(typeid(c).next); //null
writeln(typeid(s).next); //shared(modulename.S)
writeln(typeid(typeid(s).next) is typeid(TypeInfo_Shared)); //true
writeln(typeid(typeid(c)) is typeid(TypeInfo_Shared)); //false
}
What's the reason that the shared propagates to the typeinfo for the
struct, but not for the class declaration?
That is definitely a bug. It's because typeid is looking up the derived
type via the vtable, but the compiler should rewrap it with 'shared'
afterwards.
This is enough to make me think it's a bug:
class C{}
void main(){
auto c1 = new C;
auto c2 = new shared(C);
assert(typeid(c1) is typeid(c2));
assert(!is(typeof(c1) == typeof(c2)));
pragma(msg, typeof(c1)); // C
pragma(msg, typeof(c2)); // shared(C)
}
I don't think it's shared-specific.
-Steve
