store template value
I have a class that creates a task in it's constructor. How do I store this created task as one of it's value members and later on call .yieldForce()?
Re: Import template in phobos
On Saturday, 1 August 2015 at 14:42:47 UTC, vit wrote:
Exist in phobos something like Import template?
public import std.traits;
template Import(alias Module){
mixin(import ~ moduleName!Module ~ ;);
}
class C;
struct Test{
Import!(std.typecons).Rebindable!C test;//symbols
}
Not very clear. from your '//symbols' comment I deduce that you
want to turn a template into a local symbol.
To do so use an 'alias expression':
---
import std.typecons: Rebindable;
alias symbolIdentifier = Rebindable!C;
---
see http://dlang.org/declaration.html#alias for full spec.
Re: Static arrays inside struct and class - bug?
On Saturday, 1 August 2015 at 17:22:40 UTC, NX wrote:
I wonder if the followings are compiler bugs:
class stuff_class
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow
for static array
}
struct stuff
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow
for static array
}
My project has just stopped for this reason, I was trying to
hack into another process memory with something similar to this:
stuff data;
ReadProcessMemory(Proc, (void*)0xA970F4, data,
stuff.sizeof, null);
Target program is written in C++ and because of this limitation
I'm not able to write equivalent code and here I'm stuck.
There a limit for static array size. This limits is exactly 16MB
so 1024*1024*16.
Remove one element:
byte[1024*1024*16-1] arr;
Re: Array start index
On Saturday, 1 August 2015 at 09:35:53 UTC, DLearner wrote: Does the D language set in stone that the first element of an array _has_ to be index zero? For the builtin slice types? Yes, set in stone. Wouldn't starting array elements at one avoid the common 'off-by-one' logic error, it does seem more natural to begin a count at 1. Actually, maybe even better to allow array definitions of form int foo[x:y]; (y = x) creating integer variables foo[x], foo[x+1],...,foo[y]. I think the (very old) IBM PL/I language was like this. See https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html As other commenters have/will point out, you can easily define a custom type in D that behaves as you describe, and - Dijkstra notwithstanding - there are valid uses for such things.
Re: Static arrays inside struct and class - bug?
Typo: *scenario
Re: store template value
But it's std.parallelism's task... And how can I use get!T if I don't know the type of the task? 2015-08-01 19:02 GMT+02:00 Adam D. Ruppe via Digitalmars-d-learn digitalmars-d-learn@puremagic.com: On Saturday, 1 August 2015 at 16:41:54 UTC, maarten van damme wrote: I was afraid I would have to do that. Templatizing the class on the value doesn't work as I later on want to create a hashmap of these classes. When I assign a task to a variant, how do I call .yieldForce later on? You can get a type from a Variant with the get!T method then call it. But actually, maybe Task should just be an interface with the yieldForce method then you create classes that implement it and pass them to the constructor. Then there's no need for templates or casting at all.
Static arrays inside struct and class - bug?
I wonder if the followings are compiler bugs:
class stuff_class
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow for
static array
}
struct stuff
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow for
static array
}
My project has just stopped for this reason, I was trying to hack
into another process memory with something similar to this:
stuff data;
ReadProcessMemory(Proc, (void*)0xA970F4, data, stuff.sizeof,
null);
Target program is written in C++ and because of this limitation
I'm not able to write equivalent code and here I'm stuck.
Re: Static arrays inside struct and class - bug?
On Saturday, 1 August 2015 at 17:29:54 UTC, Adam D. Ruppe wrote:
On Saturday, 1 August 2015 at 17:22:40 UTC, NX wrote:
I wonder if the followings are compiler bugs:
No, it is by design, the idea is to keep static arrays smallish
so null references will be caught by the processor. (An overly
large static array could allow indexing it through a null
pointer to potentially reach another object.)
The easiest workaround is to just dynamically allocate such
huge arrays:
byte[] arr = new byte[](1024*1024*16);
ReadProcessMemory(Proc, 0xdeadbeef, arr.ptr, arr.length, null);
The arr.ptr and arr.length are the key arguments there.
Sorry, I can't see _the_ point in that. I understand that could
be a problem if it was a global array but this scenery is
completely wrong in my view. I'm already going to dynamically
allocate it and my problem is actually a lot complex than what I
showed there, I not even allowed to do this:
struct stuff
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow for
static array
}
//...
stuff* data = new stuff;
ReadProcessMemory(Proc, (void*)0xA970F4, data, stuff.sizeof,
null);
Here
(https://gist.github.com/NightmareX1337/6408287d7823c8a4ba20) is
the real issue if anyone want to see the real-world problem with
long lines of code
Re: store template value
On Saturday, 1 August 2015 at 16:41:54 UTC, maarten van damme wrote: I was afraid I would have to do that. Templatizing the class on the value doesn't work as I later on want to create a hashmap of these classes. When I assign a task to a variant, how do I call .yieldForce later on? You can get a type from a Variant with the get!T method then call it. But actually, maybe Task should just be an interface with the yieldForce method then you create classes that implement it and pass them to the constructor. Then there's no need for templates or casting at all.
Re: Struct that destroys its original handle on copy-by-value
On 31/07/15 19:21, Ali Çehreli via Digitalmars-d-learn wrote: On 07/26/2015 04:29 AM, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: is this design idea even feasible in principle, or just a bad idea from the get-go? As I understand it, it is against one of fundamental D principles: structs are value types where any copy can be used in place of any other. I expect there are examples where even Phobos violates it but the struct documentation still says so: A struct is defined to not have an identity; that is, the implementation is free to make bit copies of the struct as convenient. http://dlang.org/struct.html That really feels very bad for the problem domain I have in mind -- random number generation. No implementation should be free to make copies of a random number generator as convenient, that should be 100% in the hands of the programmer! And if feasible -- how would I go about it? Disallowing automatic copying and providing a function comes to mind. Yes, I considered that, but I don't think it really delivers what's needed :-( Let me give a concrete example of why I was thinking in this direction. Consider RandomSample in std.random. This is a struct (a value type, instantiated on the stack). However, it also wraps a random number generator. It needs to be consumed once and once only, because otherwise there will be unintended statistical correlations in the program. Copy-by-value leads to a situation where you can accidentally consume the same sequence twice (or possibly, only _part_ of the sequence). Now, indeed, one way is to just @disable this(this) which prevents copy-by-value. But then you can't do something natural and desirable like: iota(100).randomSample(10, gen).take(5).writeln; ... because you would no longer be able to pass the RandomSample instance into `take`. On the other hand, what you want to disallow is this: auto sample = iota(100).randomSample(10, gen); sample.take(5).writeln; sample.take(5).writeln; // statistical correlations result, // probably unwanted The first situation is still possible, and the second disallowed (or at least, guarded against), _if_ a copy-by-value is finalized by tweaking the source to render it an empty range. I would happily hear alternative solutions to the problem, but that's why I was interested in a struct with the properties I outlined in my original post.
Import template in phobos
Exist in phobos something like Import template?
public import std.traits;
template Import(alias Module){
mixin(import ~ moduleName!Module ~ ;);
}
class C;
struct Test{
Import!(std.typecons).Rebindable!C test;//symbols
}
Re: Static arrays inside struct and class - bug?
On Saturday, 1 August 2015 at 17:22:40 UTC, NX wrote: I wonder if the followings are compiler bugs: No, it is by design, the idea is to keep static arrays smallish so null references will be caught by the processor. (An overly large static array could allow indexing it through a null pointer to potentially reach another object.) The easiest workaround is to just dynamically allocate such huge arrays: byte[] arr = new byte[](1024*1024*16); ReadProcessMemory(Proc, 0xdeadbeef, arr.ptr, arr.length, null); The arr.ptr and arr.length are the key arguments there.
Re: Struct that destroys its original handle on copy-by-value
On Saturday, 1 August 2015 at 12:10:43 UTC, Joseph Rushton
Wakeling wrote:
On 31/07/15 19:21, Ali Çehreli via Digitalmars-d-learn wrote:
On 07/26/2015 04:29 AM, Joseph Rushton Wakeling via
Digitalmars-d-learn wrote:
is this design idea even feasible in principle, or just a
bad
idea from the get-go?
As I understand it, it is against one of fundamental D
principles: structs are
value types where any copy can be used in place of any other.
I expect there are examples where even Phobos violates it but
the struct
documentation still says so: A struct is defined to not have
an identity; that
is, the implementation is free to make bit copies of the
struct as convenient.
http://dlang.org/struct.html
That really feels very bad for the problem domain I have in
mind -- random number generation. No implementation should be
free to make copies of a random number generator as
convenient, that should be 100% in the hands of the programmer!
And if feasible -- how would I go about it?
Disallowing automatic copying and providing a function comes
to mind.
Yes, I considered that, but I don't think it really delivers
what's needed :-(
Let me give a concrete example of why I was thinking in this
direction. Consider RandomSample in std.random. This is a
struct (a value type, instantiated on the stack). However, it
also wraps a random number generator. It needs to be consumed
once and once only, because otherwise there will be unintended
statistical correlations in the program. Copy-by-value leads
to a situation where you can accidentally consume the same
sequence twice (or possibly, only _part_ of the sequence).
Now, indeed, one way is to just @disable this(this) which
prevents copy-by-value. But then you can't do something
natural and desirable like:
iota(100).randomSample(10, gen).take(5).writeln;
... because you would no longer be able to pass the
RandomSample instance into `take`.
On the other hand, what you want to disallow is this:
auto sample = iota(100).randomSample(10, gen);
sample.take(5).writeln;
sample.take(5).writeln; // statistical correlations result,
// probably unwanted
The first situation is still possible, and the second
disallowed (or at least, guarded against), _if_ a copy-by-value
is finalized by tweaking the source to render it an empty range.
I would happily hear alternative solutions to the problem, but
that's why I was interested in a struct with the properties I
outlined in my original post.
Naïve compromise solution?
struct S(bool noCopy = true)
{
//replace with real state
int state = 0;
static if(noCopy) @disable this(this);
@property auto copyable()
{
//did the move manually because I got
//weird results std.algorithm.move
auto ret = cast(S!false)this;
this.state = this.state.init;
return ret;
}
}
auto s(int state)
{
return S!()(state);
}
void main()
{
import std.stdio, std.algorithm;
auto s = s(42);
auto s1 = s.move;
assert(s == S!().init);
s1.copyable.writeln;
assert(s1 == S!().init);
}
Then at least the simplest mistakes are avoided. Also, it means
people are more likely to read important docs i.e. Why do I have
to call this copyable thing? Oh, I see, I'll be careful.
I'm not sure how good an idea it is to totally enforce a range to
be non-copyable, even if you could deal with the function call
chain problem. Even in totally save-aware code, there can still
be valid assignment of a range type. I'm pretty sure a lot of
phobos ranges/algorithms would be unusable.
Re: How disruptive is the GC?
On Wednesday, 29 July 2015 at 09:25:50 UTC, Snape wrote: I'm in the early stages of building a little game with OpenGL (in D) and I just want to know the facts about the GC before I decide to either use it or work around it. Lots of people have said lots of things about it, but some of that information is old, so as of today, what effect does the GC have on the smooth operation of a real-time application? Is it pretty noticeable with any use of the GC or only if you're deallocating large chunks at a time? The GC is noticeable and you will probably have to minimize the heap size. Fortunately the use of -vgc and @nogc helps a lot to mitigate the pauses.
Re: Struct that destroys its original handle on copy-by-value
On 31/07/15 13:40, Kagamin via Digitalmars-d-learn wrote: On Sunday, 26 July 2015 at 12:16:30 UTC, Joseph Rushton Wakeling wrote: Example: Unique!Random rng = new Random(unpredictableSeed); rng.take(10).writeln; My aim by contrast is to _allow_ that kind of use, but render the original handle empty when it's done. `take` stores the range, you can try to use some sort of a weak reference. Yea, but that's not what I'm trying to achieve. I know how I can pass something to `take` so as to e.g. obtain reference semantics or whatever; what I'm trying to achieve is a range that _doesn't rely on the user knowing the right way to handle it_. I'll expand on this more responding to Ali, so as to clarify the context of what I'm aiming for and why.
Re: store template value
On Saturday, 1 August 2015 at 15:37:46 UTC, maarten van damme wrote: I have a class that creates a task in it's constructor. How do I store this created task as one of it's value members and later on call .yieldForce()? If the class itself isn't templated on the type, you'll want to use something like std.variant.Variant to store it.
Re: Import template in phobos
On Saturday, 1 August 2015 at 14:42:47 UTC, vit wrote: Exist in phobos something like Import template? What would you use that for? You can just use the import keyword...
Re: Array start index
On Saturday, 1 August 2015 at 09:35:53 UTC, DLearner wrote: Does the D language set in stone that the first element of an array _has_ to be index zero? Wouldn't starting array elements at one avoid the common 'off-by-one' logic error, it does seem more natural to begin a count at 1. Actually, maybe even better to allow array definitions of form int foo[x:y]; (y = x) creating integer variables foo[x], foo[x+1],...,foo[y]. I think the (very old) IBM PL/I language was like this. Seems you could easily wrap an array in a struct, define opIndex and opSlice appropriately, and use alias this to keep the other properties of the array. The problem you'll run into is interacting with other code that assumes zero-based indexing. I thought about setting the first index at 1 for my library that embeds D inside R, since that's how it's done in R, but very quickly realized how confusing it would be.
Re: Static arrays inside struct and class - bug?
On Saturday, 1 August 2015 at 18:07:51 UTC, NX wrote: Sorry, I can't see _the_ point in that. Yeah, especially since you can jsut break up the array and get the same effect anyway... so like if you don't want to dynamically allocate the memory, you could also try: byte[1024*1024*8] arr1; byte[1024*1024*8] arr2; If they are right next to each other they will still be continuous in memory and then you work around the limit.
Re: store template value
I was afraid I would have to do that. Templatizing the class on the value doesn't work as I later on want to create a hashmap of these classes. When I assign a task to a variant, how do I call .yieldForce later on? 2015-08-01 18:28 GMT+02:00 Adam D. Ruppe via Digitalmars-d-learn digitalmars-d-learn@puremagic.com: On Saturday, 1 August 2015 at 15:37:46 UTC, maarten van damme wrote: I have a class that creates a task in it's constructor. How do I store this created task as one of it's value members and later on call .yieldForce()? If the class itself isn't templated on the type, you'll want to use something like std.variant.Variant to store it.
Re: Static arrays inside struct and class - bug?
On Saturday, 1 August 2015 at 18:47:00 UTC, Daniel Kozak wrote: Still same problem, You can`t allocate more then 16M on stack. Use dynamic allocation I don't think new MyStruct allocates on stack, actually allocating ~16MB on stack will immediatelly crash the program which is not the case with NewExpression.
Re: Static arrays inside struct and class - bug?
V Sat, 01 Aug 2015 19:21:36 +
NX via Digitalmars-d-learn digitalmars-d-learn@puremagic.com napsáno:
On Saturday, 1 August 2015 at 18:50:09 UTC, Daniel Kozak wrote:
No you don't. You still use static allocation for array
Can clarify why does that happen and I still suspect it's a
static allocation it would increase output exe if it was really
that static..?
No it would not increase output exe. Problem is with definition:
type[size] val; // static declaration so compilere check max 16M.
But you are right, in your case it could be improved and such
declaration could work.
because:
S {
byte[16*1024*1024*1024] arr;
}
void main() {
auto s = new S();
if (s is null) {
// error cannont allocate enought memory
}
}
but:
void main() {
byte[16*1024*1024*1024] arr; // impossible to check if is allocated
}
Maybe you can open an enhancment on issues.dlang.org
Re: alias overloading strange error
On Friday, 31 July 2015 at 11:09:39 UTC, anonymous wrote: Definitely a bug. Please file an issue at https://issues.dlang.org/. https://issues.dlang.org/show_bug.cgi?id=14858
Re: Static arrays inside struct and class - bug?
On Saturday, 1 August 2015 at 18:07:51 UTC, NX wrote: On Saturday, 1 August 2015 at 17:29:54 UTC, Adam D. Ruppe wrote: Sorry, I can't see _the_ point in that. I understand that could be a problem if it was a global array but this scenery is completely wrong in my view. I'm already going to dynamically allocate it No you don't. You still use static allocation for array
How to run opengl tutorials
Hey, I have found this great source of tutorials for simple game development, yet i am unable to run it properly on Windows 8.1. https://github.com/d-gamedev-team/opengl-tutorials/tree/master/ports/opengl-tutorial.org/tutorials/01_window Can someone tell me how can i run all those examples? I have been trying to use dub, but i either can't do it correctly, or packages are outdated. I would appreciate any help, thanks!
Re: Array start index
On Saturday, 1 August 2015 at 17:55:06 UTC, John Colvin wrote: On Saturday, 1 August 2015 at 09:35:53 UTC, DLearner wrote: Does the D language set in stone that the first element of an array _has_ to be index zero? For the builtin slice types? Yes, set in stone. Wouldn't starting array elements at one avoid the common 'off-by-one' logic error, it does seem more natural to begin a count at 1. Actually, maybe even better to allow array definitions of form int foo[x:y]; (y = x) creating integer variables foo[x], foo[x+1],...,foo[y]. I think the (very old) IBM PL/I language was like this. See https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html As other commenters have/will point out, you can easily define a custom type in D that behaves as you describe, and - Dijkstra notwithstanding - there are valid uses for such things. D is a C derivative, so it seems a shame not to identify causes of bugs in C, and design them out in D. For example, in C difficult to write non-trivial commercial programs without using pointers. Pointer manipulation has a terrible reputation for bugs. But in D, easy to write commercial programs without using pointers. Problem has been designed away. Similarly, off-by-one array bugs are commonplace in C. We should seek to eliminate the source of those bugs, which basically reduces to the issue that programmers find it unnatural to start a count at zero. Whether they _should_ find a zero start unnatural is irrelevant - they just do as an observed fact, so let's change the language so the issue is avoided (designed away). Suggestion: if the codebase for D is considered so large that zero-basing cannot now be changed, why not extend the language to allow for array definitions like 'int[x:y] foo'? And then have a rule that 'int[:y] bar' defines a 1-based array of y elements?
Re: Array start index
On 8/1/15, DLearner via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: D is a C derivative, so it seems a shame not to identify causes of bugs in C, and design them out in D. This has already been done! D defines an array to be a struct with a pointer and a length. See this article: http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625 I would argue it's not off-by-one that's causing most issues when dealing with C arrays, but instead it's in general out-of-bounds issues (whether it's off bye one or off by 50..) since you often don't have the length or could easily use the wrong variable as the length. Think about how much D code would actually have subtle off-by-one errors if D didn't use 0-based indexing like the majority of popular languages use. Any time you would interface with other languages you would have to double, triple-check all your uses of arrays. FWIW at the very beginning I also found it odd that languages use 0-based indexing, but that was before I had any significant programming experience under my belt. By now it's second nature to me to use 0-based indexing.
Re: extern(C) with function returning user type
On Saturday, 1 August 2015 at 04:11:02 UTC, Laeeth Isharc wrote: Walter observes that if you are a Java programmer and start writing D, you will write D like you write Java. And so I suppose one will see what one doesn't have in Java, but not so much the benefits of D. That's true of other languages too. When one learns something new, one is often initially worse off as a result, because it destabilises ones habits before one sees how to apply ones new knowledge. So those benefits only come with persistence and the passage of time. Language familiarity can also be deceptive - D adds nothing really new say the Reddit guys. But as a C guy who never got into C++, it makes a huge difference. Just not obviously so in the beginning. One thing that's great is to be able to come back to my own code after a break when it was written in a hurry and without too many comments and tie be able to understand it immediately. That wasn't my experience with C, but I suppose it depends how much discipline you have. (Also, once it compiles, the bugs are usually obvious enough and simple to fix - stronger typing has benefits). The main advantage I have found is that one can deploy limited energy to achieve more, because one doesn't get as bogged down, and because the work is more pleasant and satisfying. Which libraries do you miss, out of interest? Oddly enough, before D I was a python guy. I took up C about year after starting D. So I definitely see the python influence in my coding style, in both C and D. I keep everything very minimal and tidy, so my code is always really readable; but at the same time it has made me slightly hesitant to take up some of D's more unique features, so there's definitely still alot of areas with D I know I could improve in. However, there's points with D that I know the work around to certain problems is to use some other language, because D's design for better or worse won't let me solve the problem in a effective or sane method. I agree with you completely about how easy D makes certain things. It's just that the bigger or more complex a project becomes, I find that it doesn't matter how the language works, things are just gonna get messy. For libraries, most of them have some type of D binding available (of varying quality). Csound doesn't have a D binding, I don't think there's a Bullet3 binding, the alembic library(which is on my todo to use) doesn't have D binding, and the WinAPI is very weird to use from D. Also software APIs such as Softimage or Houdini's API don't have one. There's a bunch of others too. I think alot of this comes from game/interactive application programmers being in the minority in the D community. I generally don't like the whole binding scenario anyways, because there's always a bit of delay between updates in the library and the binding, and I'm unfortunately very reliant on other people's libraries at the moment :\ Also one of my hobbies that I've gotten into in the last few months is writing code for weird processors types (i.e. the MOS 6502, or the SX processor). There's always atleast a C compiler available (either official or community made). So even wishing for a D compiler for all those uncommon architectures is foolish. Being that I have a decent idea of what I'm doing these days, it's not to hard to jump languages; but since knowing how to use a language and how to actually excel at a language is two very different things, I've chosen to get as good as possible at C, since there will be a much much larger payoff right now. :]
Re: Static arrays inside struct and class - bug?
On Saturday, 1 August 2015 at 18:50:09 UTC, Daniel Kozak wrote: No you don't. You still use static allocation for array Can clarify why does that happen and I still suspect it's a static allocation it would increase output exe if it was really that static..?
Re: Static arrays inside struct and class - bug?
V Sat, 01 Aug 2015 19:16:16 + NX via Digitalmars-d-learn digitalmars-d-learn@puremagic.com napsáno: On Saturday, 1 August 2015 at 18:47:00 UTC, Daniel Kozak wrote: Still same problem, You can`t allocate more then 16M on stack. Use dynamic allocation I don't think new MyStruct allocates on stack, actually allocating ~16MB on stack will immediatelly crash the program which is not the case with NewExpression. My fault It is not on stack, but still it is a static allocation
Re: Static arrays inside struct and class - bug?
On Saturday, 1 August 2015 at 19:33:26 UTC, Daniel Kozak wrote: My fault It is not on stack, but still it is a static allocation I think you're misusing static allocation and static declaration for each other.
Re: Array start index
On Saturday, 1 August 2015 at 19:04:10 UTC, Andrej Mitrovic wrote: On 8/1/15, DLearner via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: D is a C derivative, so it seems a shame not to identify causes of bugs in C, and design them out in D. This has already been done! D defines an array to be a struct with a pointer and a length. See this article: http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625 I would argue it's not off-by-one that's causing most issues when dealing with C arrays, but instead it's in general out-of-bounds issues (whether it's off bye one or off by 50..) since you often don't have the length or could easily use the wrong variable as the length. Think about how much D code would actually have subtle off-by-one errors if D didn't use 0-based indexing like the majority of popular languages use. Any time you would interface with other languages you would have to double, triple-check all your uses of arrays. FWIW at the very beginning I also found it odd that languages use 0-based indexing, but that was before I had any significant programming experience under my belt. By now it's second nature to me to use 0-based indexing. But what type of programming are you doing? Even after decades of programming and trying out dozens of languages, zero-based indexing still gets me at times when the arrays I work with represent vectors and matrices. Especially when porting code from other languages that use one-based indexing. One of the nice things about D is that it gives you the tools to easily make the change if you want.
Re: store template value
On 08/01/2015 08:37 AM, maarten van damme via Digitalmars-d-learn wrote:
I have a class that creates a task in it's constructor. How do I store this
created task as one of it's value members and later on call .yieldForce()?
Tasks can be created with a function pointer 'function parameter' as
well. (This has already been added to Programming in D but it is not
available on the web site yet.)
I learned the exact type by the help of pragma(msg) below and used it to
create MyTask and myTasks:
import std.parallelism;
double foo(int i)
{
return i * 1.5;
}
double bar(int i)
{
return i * 2.5;
}
void main()
{
auto tasks = [ task(foo, 1),
task(bar, 2) ];// ← compiles
pragma(msg, typeof(tasks[0]));
alias MyTask = Task!(run, double function(int), int)*;
MyTask[] myTasks;
myTasks ~= task(foo, 1);
myTasks ~= task(bar, 2);
}
Ali
Re: How to run opengl tutorials
On Saturday, 1 August 2015 at 22:14:45 UTC, nikolai wrote: Hey, I have found this great source of tutorials for simple game development, yet i am unable to run it properly on Windows 8.1. https://github.com/d-gamedev-team/opengl-tutorials/tree/master/ports/opengl-tutorial.org/tutorials/01_window Can someone tell me how can i run all those examples? I have been trying to use dub, but i either can't do it correctly, or packages are outdated. I would appreciate any help, thanks! I don't think any one can help you without any information on the errors you are seeing. Running the example should be as simple as navigating to the 01_window directory and typing: dub So if that's not working for you, no one can tell you why without more info.
Re: Struct that destroys its original handle on copy-by-value
On Saturday, 1 August 2015 at 17:50:28 UTC, John Colvin wrote: I'm not sure how good an idea it is to totally enforce a range to be non-copyable, even if you could deal with the function call chain problem. Even in totally save-aware code, there can still be valid assignment of a range type. I'm pretty sure a lot of phobos ranges/algorithms would be unusable. This is exactly why I proposed to Joe design with destructive copy originally - that would work with any algorithms expecting implicit pass by value but prevent from actual double usage. Sadly, this does not seem to be implementable in D in any reasonable way.
Re: Static arrays inside struct and class - bug?
V Sat, 01 Aug 2015 18:07:50 +
NX via Digitalmars-d-learn digitalmars-d-learn@puremagic.com napsáno:
On Saturday, 1 August 2015 at 17:29:54 UTC, Adam D. Ruppe wrote:
On Saturday, 1 August 2015 at 17:22:40 UTC, NX wrote:
I wonder if the followings are compiler bugs:
No, it is by design, the idea is to keep static arrays smallish
so null references will be caught by the processor. (An overly
large static array could allow indexing it through a null
pointer to potentially reach another object.)
The easiest workaround is to just dynamically allocate such
huge arrays:
byte[] arr = new byte[](1024*1024*16);
ReadProcessMemory(Proc, 0xdeadbeef, arr.ptr, arr.length, null);
The arr.ptr and arr.length are the key arguments there.
Sorry, I can't see _the_ point in that. I understand that could
be a problem if it was a global array but this scenery is
completely wrong in my view. I'm already going to dynamically
allocate it and my problem is actually a lot complex than what I
showed there, I not even allowed to do this:
struct stuff
{
byte[1024*1024*16] arr; // Error: index 16777216 overflow for
static array
}
//...
stuff* data = new stuff;
ReadProcessMemory(Proc, (void*)0xA970F4, data, stuff.sizeof,
null);
Here
(https://gist.github.com/NightmareX1337/6408287d7823c8a4ba20) is
the real issue if anyone want to see the real-world problem with
long lines of code
Still same problem, You can`t allocate more then 16M on stack. Use
dynamic allocation
Array start index
Does the D language set in stone that the first element of an array _has_ to be index zero? Wouldn't starting array elements at one avoid the common 'off-by-one' logic error, it does seem more natural to begin a count at 1. Actually, maybe even better to allow array definitions of form int foo[x:y]; (y = x) creating integer variables foo[x], foo[x+1],...,foo[y]. I think the (very old) IBM PL/I language was like this.
Re: Array start index
On 1/08/2015 9:35 p.m., DLearner wrote: Does the D language set in stone that the first element of an array _has_ to be index zero? Wouldn't starting array elements at one avoid the common 'off-by-one' logic error, it does seem more natural to begin a count at 1. Actually, maybe even better to allow array definitions of form int foo[x:y]; (y = x) creating integer variables foo[x], foo[x+1],...,foo[y]. I think the (very old) IBM PL/I language was like this. In c style languages (like D) the index actually defines the offset in memory. Not actually the index. So while in some languages 1 is used instead of 0, 0 maps better to the hardware. Think of this byte array: ubyte* myptr = [ |---|---| | i | value | |---|---| | 0 | 1 | | 1 | 255 | ]; For 0 start of index: size_t i = 0; assert(myptr[i] == 1); For 1 start of index: size_t i = 1; assert(i != 0); assert(myptr[i-1] == 1); While this is not the complete reason why 0 is chosen, it is something to think about.
