Re: search of a workaround
On Saturday, 9 February 2013 at 22:14:45 UTC, Namespace wrote:
Why isn't there 'const' in ParameterStorageClass?
How could I detect that my Parameter storage class is 'in'?
It's an ambiguity in the term StorageClass in D, which is
different from TypeQualifier. Const is part of the type.
StorageClass means modifiers when you pass to a function.
As for in (or inout):
Apparently, they aren't true StorageClass, because the compiler
re-writes them to const ref or scope something anyways,
that's why they don't appear in the list.
On Saturday, 9 February 2013 at 22:54:23 UTC, Namespace wrote:
On Saturday, 9 February 2013 at 22:23:07 UTC, Namespace wrote:
It seems your template has problems with this:
struct A { }
class B {
public:
const int bar(ref A a) {
return 42;
}
mixin(rvalue!(bar));
}
remove the 'const' and it works fine.
It seems that D has no functionality, to detect if a method is
const.
Well, I did mention Also, I didn't code the FunctionAttribute
part, but that's just because it's late and I want to sleep. I
even left a big todo in there :)
On Sunday, 10 February 2013 at 00:01:32 UTC, Namespace wrote:
This works so far:
auto funcAttr = functionAttributes!(fun);
if (FunctionAttribute.pure_ funcAttr) s ~= pure;
if (FunctionAttribute.nothrow_ funcAttr) s ~= nothrow;
if (FunctionAttribute.ref_ funcAttr) s ~= ref;
if (!isMutable!(typeof(fun))) s ~= const;
But it's curious that FunctionAttributes has no const,
immutable, inout or shared...
I I have no idea. File a bug maybe?
Either it'll be valid, or you'll get the it would be redundant
reply, in which case the docs would *need* to be upgraded.
Re: Creating an array of default-constructed class instances
On 10-2-2013 7:14, Simon wrote:
Hi, I'm new to the D programming language. Overall I'm liking
things very much, but I'm still getting the hang of a few things.
Here's a basic programming pattern: I have a class called Thing,
and while I'm coding I decide I need N Thing instances.
In C++ that's a matter of
std::vectorThing things(N);
In python, I can use a list comprehension.
things = [Thing() for _ in range(N)]
However, the obvious D version doesn't work.
auto things = new Thing[N];
Because Thing.init is null, this produces an array of null
references. Of course, I can write a for loop to fill in the
array after creation, but this feels very un-D-like. Is there a
straightforward way to create a bunch of class instances?
import std.stdio, std.algorithm;
class Thing {
int i;
this(int i) {
this.i = i;
}
}
void main()
{
auto things = new Thing[10];
fill(things, new Thing(5));
foreach (t; things)
writef(%d , t.i);
}
Re: search of a workaround
Well, I did mention Also, I didn't code the FunctionAttribute
part, but that's just because it's late and I want to sleep. I
even left a big todo in there :)
I've overlooked that. :)
Here is the complete code. If you have to improve something, say
it please.
One last question: why 'ss' as function name? :o
[code]
template rvalue(alias fun) {
private string ss() {
enum Func = __traits(identifier, fun);
enum Ret = ReturnType!(fun).stringof;
alias Args = ParameterTypeTuple!(fun);
alias ParameterStorageClassTuple!(fun) pstc;
enum names = [ParameterIdentifierTuple!(fun)];
string s;
s ~= Ret ~ ~ Func ~ (;
foreach(i, Type; Args[0 .. $]) {
if (pstc[i] ParameterStorageClass.scope_) s ~=
scope ;
if (pstc[i] ParameterStorageClass.out_) s ~= out ;
if (pstc[i] ParameterStorageClass.lazy_) s ~= lazy
;
s ~= Args[i].stringof ~ ;
s ~= names[i];
if (i + 1 != Args.length) s ~= , ;
}
s ~= );
auto funcAttr = functionAttributes!(fun);
if (funcAttr FunctionAttribute.pure_) s ~= pure;
if (funcAttr FunctionAttribute.nothrow_) s ~= nothrow;
if (funcAttr FunctionAttribute.ref_) s ~= ref;
if (!isMutable!(typeof(fun))) s ~= const; // no idea why
FunctionAttribute has no const...
s ~= {\n\treturn ~ Func ~ (;
if (Args.length) {
s ~= names[0];
foreach(i, Type; Args[1 .. $]) {
s ~= , ~ names[i + 1];
}
}
s ~= );\n}\n;
return s;
}
enum rvalue = ss();
}
[/code]
Re: Creating an array of default-constructed class instances
On Sunday, 10 February 2013 at 09:48:04 UTC, Jos van Uden wrote:
On 10-2-2013 7:14, Simon wrote:
Hi, I'm new to the D programming language. Overall I'm liking
things very much, but I'm still getting the hang of a few
things.
Here's a basic programming pattern: I have a class called
Thing,
and while I'm coding I decide I need N Thing instances.
In C++ that's a matter of
std::vectorThing things(N);
In python, I can use a list comprehension.
things = [Thing() for _ in range(N)]
However, the obvious D version doesn't work.
auto things = new Thing[N];
Because Thing.init is null, this produces an array of null
references. Of course, I can write a for loop to fill in the
array after creation, but this feels very un-D-like. Is there
a
straightforward way to create a bunch of class instances?
import std.stdio, std.algorithm;
class Thing {
int i;
this(int i) {
this.i = i;
}
}
void main()
{
auto things = new Thing[10];
fill(things, new Thing(5));
foreach (t; things)
writef(%d , t.i);
}
HELL NO
What you did just right there is allocate a *single* thing
_instance_ and then place 10 _references_ to that same thing in
the array.
Re: Creating an array of default-constructed class instances
On Sunday, 10 February 2013 at 06:14:37 UTC, Simon wrote: Hi, I'm new to the D programming language. Overall I'm liking things very much, but I'm still getting the hang of a few things. Here's a basic programming pattern: I have a class called Thing, and while I'm coding I decide I need N Thing instances. In C++ that's a matter of std::vectorThing things(N); In python, I can use a list comprehension. things = [Thing() for _ in range(N)] However, the obvious D version doesn't work. auto things = new Thing[N]; Because Thing.init is null, this produces an array of null references. Of course, I can write a for loop to fill in the array after creation, but this feels very un-D-like. Is there a straightforward way to create a bunch of class instances? The difference is that C++ will *place* the instances inside the vector. A *true* C++ equivalent would be to declare: std::vectorThing* things(N); As you can see, same problem. Honestly, there are a lot of fancy ways to go around the problem, but quite frankly,I think simple is best: // auto myThings = new Thing[](N); foreach(ref aThing; myThings) aThing = new Thing(); //- It's not fancy, but it gets the job done. You won't confuse anyone with the code, and there is very little risk of subtle bugs (appart from forgetting the ref in the foreach loop.
Missing attributes in FunctionAttribute
Before I open a new bug report, I would like to ask if anyone knows why FunctionAttribute neither has const, immutable, shared or inout? Especially const and immutable were important to know.
Re: For DLLs, what does export actually do?
Am 10.02.2013 13:36, schrieb Ben Davis: With the def, I get lines like DriverProc = _DriverProc@20. Without it, I get lines like _DriverProc@20 = _DriverProc@20. Then you did hit this 3 year old bug: http://d.puremagic.com/issues/show_bug.cgi?id=3956
Re: For DLLs, what does export actually do?
On 10/02/2013 08:17, Benjamin Thaut wrote:
Am 10.02.2013 03:03, schrieb Ben Davis:
My functions are export extern (Windows) - I think they're global...?
For example:
export extern(Windows) LRESULT DriverProc(DWORD_PTR dwDriverId, HDRVR
hdrvr, UINT msg, LONG lParam1, LONG lParam2) nothrow { ... }
Do you have a copy of visual studio around? If so you can use
dumpbin /EXPORTS your.dll
From a visual studio command shell to see the symbols the dll actually
exports. Just compare the version where you manually listed them in the
exports section with the version where you don't manually list exports.
Thanks, that helped expose what's going on.
With the def, I get lines like DriverProc = _DriverProc@20.
Without it, I get lines like _DriverProc@20 = _DriverProc@20.
So the difference is that the export is done under a slightly mangled
name if I only mark it in the code, and I need to use the def file to
specify the exact name to export by. I suppose this is only necessary
for weird things like driver entry points, and not for normal exported
functions.
A bit more Googling reveals that the @n is the number of bytes taken by
arguments, and is part of the stdcall == extern(Windows) convention. So
Windows is making me use stdcall and then making me throw that
information away in the export table. But hey - it wouldn't be the worst
thing I've encountered with the Windows API. (._.' :P)
DllMain is a weird one - it creates all sorts of linker errors if I try
it with extern(C) instead of extern(Windows) (which is different from
the other methods, which compile fine with extern(C) and then crash at
runtime). Also it doesn't matter what name I export it by or whether I
export it at all. I'm getting the feeling this is what was implied by
The presence of DllMain() is recognized by the compiler. Good to know
anyway - I like to keep stuff clean :)
Re: Looking for writing parallel foreach kind of statement for nested for-loops
Think again if you need that. Things start getting pretty ugly. :) Yes, it is not at all intuitive. Indeed... Sparsh, any reason you need the calculation to be done on 2d blocks instead of independent slots? For my problem, original answer was fine, since parallel calculations are not at all dependent on each others. Sometime there are calculations to be done on 2d grid, where calculations are not uniform across the grid(see paper An overview of parallel visualisation methods for Mandelbrot and Julia sets where you can see Julia sets parallelization), and hence, dividing in a particular way leads to better load-balancing than others. Thanks a lot for your answer and time.
Re: For DLLs, what does export actually do?
On 10/02/2013 12:39, Benjamin Thaut wrote: Am 10.02.2013 13:36, schrieb Ben Davis: With the def, I get lines like DriverProc = _DriverProc@20. Without it, I get lines like _DriverProc@20 = _DriverProc@20. Then you did hit this 3 year old bug: http://d.puremagic.com/issues/show_bug.cgi?id=3956 I don't think I did. That bug applies to cases WITHOUT a .def file, and in that bug, the actual vs expected output is: _DriverProc@mangledinsomeway (correct) modMessage@mangledinsomeway (should be _modMessage@mangledinsomeway) midMessage@mangledinsomeway (should be _midMessage@mangledinsomeway) In my case, when I build without a .def file, I get: _DriverProc@mangledinsomeway _modMessage@mangledinsomeway _midMessage@mangledinsomeway not what I want, but correct as per the spec (I assume). Which would imply the bug was fixed at some point. My example of DriverProc = (without the _) was WITH a .def file, AND is what I want - there is no bug as far as I'm aware. For reference, when Andrej mentioned in earlier bug involving not having a .def, I thought of this one: http://www.digitalmars.com/d/archives/digitalmars/D/Windows_DLLs_and_TLS_177871.html Hope it's clear now? Ben :)
Re: For DLLs, what does export actually do?
On 10/02/2013 14:11, Ben Davis wrote: Which would imply the bug was fixed at some point. ...though of course it would need verifying with the example actually quoted in the bug, since there may be subtle differences. (Hopefully I'm just stating the obvious.)
Re: Invisible console
On Sunday, 10 February 2013 at 14:17:14 UTC, SaltySugar wrote: how to make console invisible? See this thread for two solutions: http://forum.dlang.org/thread/xkvdpdsfzevanucrg...@forum.dlang.org You can use a .def file (my post in it) or a linker switch (Jordi Sayol's post).
Re: Invisible console
On 2013-02-10 15:17, SaltySugar wrote: how to make console invisible? Seems to be a recurring question here. :) Search archives. You probably want: dmd.exe -L/SUBSYSTEM:WINDOWS app.d
Re: search of a workaround
On Sunday, 10 February 2013 at 08:38:23 UTC, monarch_dodra wrote: On Saturday, 9 February 2013 at 22:14:45 UTC, Namespace wrote: Why isn't there 'const' in ParameterStorageClass? How could I detect that my Parameter storage class is 'in'? It's an ambiguity in the term StorageClass in D, which is different from TypeQualifier. Const is part of the type. StorageClass means modifiers when you pass to a function. Parameter storage classes are in, out, ref, lazy, const, immutable, shared, inout or scope. http://dlang.org/function.html
Re: D timer
On Sunday, 10 February 2013 at 14:49:15 UTC, SaltySugar wrote: Can i do my own timer in D console application? like in C# timer_Tick event. There is no Timer in D as you know it from C# and also there are no events. You must rely on SetTimer WinAPI and write your own TimerProc.
Re: Creating an array of default-constructed class instances
On 02/10/2013 03:18 AM, monarch_dodra wrote: On Sunday, 10 February 2013 at 09:48:04 UTC, Jos van Uden wrote: auto things = new Thing[10]; fill(things, new Thing(5)); What you did just right there is allocate a *single* thing _instance_ and then place 10 _references_ to that same thing in the array. And in case that is what we really wanted, there is the simpler but sometimes confusing array-wise syntax: auto things = new Thing[10]; things[] = new Thing(5); Ali
Re: Missing attributes in FunctionAttribute
On Sunday, 10 February 2013 at 12:29:46 UTC, Namespace wrote: Before I open a new bug report, I would like to ask if anyone knows why FunctionAttribute neither has const, immutable, shared or inout? Especially const and immutable were important to know. Well, technically, those are not function attributes but generic type qualifiers. You can always do something like is(func == const). You may check recently pulled update to fullyQualifiedName (should be in next release) to see how it works for function types. Not obvious part probably is delegate handling. https://github.com/D-Programming-Language/phobos/pull/863
Re: Missing attributes in FunctionAttribute
On 2/10/13, Dicebot m.stras...@gmail.com wrote: On Sunday, 10 February 2013 at 12:29:46 UTC, Namespace wrote: Before I open a new bug report, I would like to ask if anyone knows why FunctionAttribute neither has const, immutable, shared or inout? Especially const and immutable were important to know. Well, technically, those are not function attributes but generic type qualifiers. In the spec they're listed as member function attributes.
Re: Missing attributes in FunctionAttribute
On Sunday, 10 February 2013 at 18:25:25 UTC, Andrej Mitrovic wrote: On 2/10/13, Dicebot m.stras...@gmail.com wrote: On Sunday, 10 February 2013 at 12:29:46 UTC, Namespace wrote: Before I open a new bug report, I would like to ask if anyone knows why FunctionAttribute neither has const, immutable, shared or inout? Especially const and immutable were important to know. Well, technically, those are not function attributes but generic type qualifiers. In the spec they're listed as member function attributes. Which part? Probably it refers to delegates, because it has both type qualifiers and attribute that qualifies hidden context pointer.
double[][] to double**
I need to call some C code which takes a double**
In D I have a dynamic array X, Whats a good way of doing this ?
#SNIP
extern(C){
void toCall(double** X, size_t d1, size_t d2);
}
void main(){
double[][] X;
// How to be able to:
toCall(X, X.length, X[0].length);
}
#/SNIP
Danny Arends
http://www.dannyarends.nl
Re: double[][] to double**
On 02/10/2013 11:38 AM, Danny Arends wrote:
I need to call some C code which takes a double**
In D I have a dynamic array X, Whats a good way of doing this ?
#SNIP
extern(C){
void toCall(double** X, size_t d1, size_t d2);
}
void main(){
double[][] X;
// How to be able to:
toCall(X, X.length, X[0].length);
}
#/SNIP
Danny Arends
http://www.dannyarends.nl
You need to use two properties of slices:
.ptr: Pointer to the first element
.length: The number of elements
import std.stdio;
import std.algorithm;
import std.range;
extern(C)
{
void toCall(double** X, size_t d1, size_t d2)
{
for (size_t row = 0; row != d1; ++row) {
for (size_t column = 0; column != d2; ++column) {
writefln(%s,%s: %s, row, column, X[row][column]);
}
}
}
}
void main(){
double[][] X = [ [ 1, 2, 3 ], [ 10, 20, 30 ] ];
double*[] X_c = X.map!(d = d.ptr).array;
toCall(X_c.ptr, X_c.length, X[0].length);
}
The line with map is the equivalent of the following:
double*[] X_c;
foreach (slice; X) {
X_c ~= slice.ptr;
}
Ali
Re: double[][] to double**
Thanks so much ! Why is this not easy 2 find :P
Re: double[][] to double**
On 02/10/2013 12:05 PM, Danny Arends wrote: Thanks so much ! Why is this not easy 2 find :P We all know the feeling. :) For future reference: The spec: http://dlang.org/arrays.html#array-properties TDPL: 4.6 Arrays' Maverick Cousin: The Pointer Programming in D: http://ddili.org/ders/d.en/pointers.html (The .ptr property of arrays section.) Ali -- D Programming Language Tutorial: http://ddili.org/ders/d.en/index.html
Re: search of a workaround
On Sunday, 10 February 2013 at 14:41:04 UTC, Namespace wrote: On Sunday, 10 February 2013 at 08:38:23 UTC, monarch_dodra wrote: On Saturday, 9 February 2013 at 22:14:45 UTC, Namespace wrote: Why isn't there 'const' in ParameterStorageClass? How could I detect that my Parameter storage class is 'in'? It's an ambiguity in the term StorageClass in D, which is different from TypeQualifier. Const is part of the type. StorageClass means modifiers when you pass to a function. Parameter storage classes are in, out, ref, lazy, const, immutable, shared, inout or scope. http://dlang.org/function.html Hum. The bug report is here: http://d.puremagic.com/issues/show_bug.cgi?id=8695 I got confused by Kenji's explanation. Still, I find it strange that const, immutable and shared are part of the storage class. I figured they were (they are) just part of the plain type.
