Re: Scalability in std.parallelism
I am not an expect at all but it looks like the first test cannot take advantage of hyperthreading but the second one can to some degree. Yes, that is my hypothesis aswell :) Thx
Re: IFTI with value / template value parameter shadowing
On Sunday, 23 February 2014 at 11:49:26 UTC, Marc Schütz wrote:
There's no IFTI here. IFTI is about inferring a template
argument (= type) from the type of a function argument. Your
template argument is a value, not a type, so there's nothing to
infer.
There is the value. In IFTI_Type, the compiler understands that
the 'T' in the parameter list is the same as the 'T' in the
TemplateArgumentList.
For example this code compiles (from bug #4986):
-
struct Foo(int n, int m) {
void bar(int m2)(Foo!(m2, n) arg) {}
}
void main( )( ) {
Foo!(3,2) f;
Foo!(3,3) g;
f.bar(g);
}
-
So the compiler can deduce a value argument from a type, but not
from a value known at compile time.
Not sure what you want to achieve. Do you want IFTI_Value(6) to
be instantiated as IFTI_Value!6(6)? In this case, just leave
the runtime parameter out:
Yeah that works, and actually I agree that passing a value both
in the parameters and template argument seems silly / odd at
first sight. But there can be valid reasons to do so. I came
accross this example while trying to shift a runtime argument to
compile time while keeping source-level compatibility in a
library.
In addition it looks like template parameter are not
considered while looking if a symbol with shadow another one.
I didn't find anything on the bugtracker but
(this)[https://d.puremagic.com/issues/show_bug.cgi?id=6980],
but it's only related.
I believe it works exactly as intended. The short form for
template functions is just syntactic sugar for:
template IFTI_Value(int n) {
int IFTI_Value(int n) { return n; }
}
This means that the function (runtime) parameter n is declared
in the inner scope, and is thus expected to shadow the template
parameter n in the outer scope.
I have to give it a second read but IIRC the TDPL was pretty much
saying that shadowing is not legal in D.
Re: Scalability in std.parallelism
On Saturday, 22 February 2014 at 16:21:21 UTC, Nordlöw wrote: In the following test code given below of std.parallelism I get some interesting results: Don't forget that n.iota.map is returning a lazily evaluated range. Std.parallelism might have to convert the lazy range to a random access range (i.e. an array,) before it can schedule the work. If I add .array after the map call (e.g. auto nums = n.iota.map!piTerm.array;) I get numbers closer to the ideal for test2. Now we compare the differences between test1 and test2: test1 is reducing doubles and test2 is reducing ints. I believe that the reason for the difference in speed up is because you have hyper threads and not true independent threads. Hyper threads can contend for shared resources in the CPU (e.g. cache and FPU.) On my computer, forcing the nums to be a range of doubles in test2 causes the speed up to drop to approximately the same as test1. Regards.
Non-Initialized Dynamic Arrays Construction
Is it possible void construct a dynamic array such as b in int n = 3; auto b = new float[n]; similar to what we do with static arrays as in int[3] c = void;
Re: Non-Initialized Dynamic Arrays Construction
On Monday, 24 February 2014 at 11:11:44 UTC, Nordlöw wrote: Is it possible void construct a dynamic array such as b in int n = 3; auto b = new float[n]; similar to what we do with static arrays as in int[3] c = void; http://dlang.org/phobos/std_array.html#.uninitializedArray is what you want.
Re: Non-Initialized Dynamic Arrays Construction
TheFlyingFiddle: http://dlang.org/phobos/std_array.html#.uninitializedArray is what you want. The OP wants minimallyInitializedArray. uninitializedArray is only for special situations. Perhaps we have to fix the online docs to underline this. Bye, bearophile
Re: Does opSlice work with immutable values?
On Monday, 24 February 2014 at 07:02:00 UTC, Joseph Cassman wrote: I have a custom number type in the works here (https://github.com/joichiro/kuttaka/commit/a226d3368a64ae63b0c256c4f4a4ede375a5cee8). The test code for opSlice works in this commit. However, when I change the auto to immutable (on line 308) I get the following error (a similar error occurs for const): src/bcd.d(309): Error: mutable method kuttaka.bcd.BcdSingle.opSlice is not callable using a immutable object src/bcd.d(310): Error: mutable method kuttaka.bcd.BcdSingle.opSlice is not callable using a immutable object src/bcd.d(311): Error: mutable method kuttaka.bcd.BcdSingle.opSlice is not callable using a immutable object Failed: [dmd, -unittest, -v, -o-, src/bcd.d, -Isrc] How can I get immutable to work here? My thinking is that opSlice is creating a new object here so the sliced object should be allowed to be const or immutable. Mark opSlice const then.
Re: What does q{...} mean?
On Monday, 24 February 2014 at 11:53:00 UTC, anonymous wrote:
On Monday, 24 February 2014 at 11:47:02 UTC, Namespace wrote:
On Monday, 24 February 2014 at 11:41:41 UTC, Gary Willoughby
wrote:
I keep seeing this syntax used a bit and i'm stumped to what
it means. What is it?
enum foo = q{
// ???
};
http://dlang.org/lex.html#DelimitedString
It's a token string though, not a delimited string. See the
section Token Strings on that page.
Yeah right. It's hard to find quick the right anchors...
Re: Non-Initialized Dynamic Arrays Construction
On Monday, 24 February 2014 at 11:29:39 UTC, bearophile wrote: TheFlyingFiddle: http://dlang.org/phobos/std_array.html#.uninitializedArray is what you want. Wouldn't it be nice to have some kind of syntactic sugar for this similar to what we have for static arrays? BTW: Why isn't simply the following allowed? int n = 3; int[n] = void; Is it too easy to confuse with static array syntax?
Re: Non-Initialized Dynamic Arrays Construction
On 02/24/2014 01:08 PM, Nordlöw wrote: On Monday, 24 February 2014 at 11:29:39 UTC, bearophile wrote: TheFlyingFiddle: http://dlang.org/phobos/std_array.html#.uninitializedArray is what you want. Wouldn't it be nice to have some kind of syntactic sugar for this similar to what we have for static arrays? BTW: Why isn't simply the following allowed? int n = 3; int[n] = void; Is it too easy to confuse with static array syntax? Seems very dangerous. If n is available at compile-time it's a static array, else it's dynamic..?
Re: Non-Initialized Dynamic Arrays Construction
On 2/24/14, bearophile bearophileh...@lycos.com wrote: The OP wants minimallyInitializedArray. uninitializedArray is only for special situations. There needs to be a ddoc-ed sample demonstrating *exactly* what the difference between minimallyInitializedArray and uninitializedArray is.
Re: Non-Initialized Dynamic Arrays Construction
On Monday, 24 February 2014 at 11:29:39 UTC, bearophile wrote: TheFlyingFiddle: http://dlang.org/phobos/std_array.html#.uninitializedArray is what you want. The OP wants minimallyInitializedArray. uninitializedArray is only for special situations. Perhaps we have to fix the online docs to underline this. Bye, bearophile what's the difference?
Re: Non-Initialized Dynamic Arrays Construction
Mengu: what's the difference? After you have read the online docs of both function what's your best guess of an answer? Bye, bearophile
Struct constructor, opCall mess.
Hi,
right now I am truing to figure out how the constructors behave
in D2.
Question 1: why it is not possible to create custom ctor for
struct?
I know this is not really necessary because you can initialize
fields like this.
struct S{ int i = 1; }
But this is a big problem if one tries to port C++ code to D2 and
default ctor call some important initialization code.
Question 2: is there a way to mimic compiler generated ctor (that
work in CTFE)?
Question 3: why it is possible to call static opCall like this?
VectorC v5 = v4(1.0);
Right now opCall seems to be better as this(...) because it work
in CTFE but because of unwanted calls this is not well at all.
Question 4: why this(...) does not work in CTFE mode?
Here is highly simplified test code.
http://melpon.org/wandbox/permlink/ofvNby99mKqOBQBf
I am asking this because I am learning D2 now by porting and
warping/connecting some big C++ (C++11) project to D2.
Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 13:56:01 UTC, Remo wrote: Hi, right now I am truing to figure out how the constructors behave in D2. Question 1: why it is not possible to create custom ctor for struct? The design of D relies on the fact that every type has a T.init property that is known to the compiler and used when in C++ the default ctor would get called. In constructors you can rely on (this == T.init), for example. You need to pick one T.init or default constructors and D picked T.init.
Re: Scalability in std.parallelism
On Sat, 2014-02-22 at 16:21 +, Nordlöw wrote: In the following test code given below of std.parallelism I get some interesting results: when compiled as dmd -release -noboundscheck -O -inline -w -wi -wi ~/Work/justd/t_parallelism.d -oft_parallelism My scalability measures says the following 3.14159 took 221[ms] 3.14159 took 727[ms] Speedup 3.28959 -5.80829e+09 took 33[ms] -5.80829e+09 took 201[ms] Speedup 6.09091 Why do I get a larger speed for a simpler map function? Shouldn't it be the opposite? I'm not sure just now, but it is an interesting issue. On my 7 year old twin 2.33GHz Xeon, I get: 3.14159 took 128[ms] 3.14159 took 860[ms] Speedup 6.71875 -5.80829e+09 took 28[ms] -5.80829e+09 took 302[ms] Speedup 10.7857 I've always read that the more calculations I perform on each memory access the better the speedup... Not necessarily, it depends on the caches and lots of other fun things. Anyhow the speedups are great! I'm sitting on a Intel Quad core with 8 hyperthreads. As anyone involved in native code CPU-bound benchmarking will tell you, hyperthreads are generally a waste of time. So on your machine I'd expect a flat out speed up of 4 on your machine, 8 on mine. Virtual machines, e.g. JVM and PVM, can sometimes do interesting things that make hyperthreads useful. Sample code follows: Hey, I recognize the core of this code, it's my π by quadrature example. Sadly π is not well approximately by -5.80829e+09 :-) I shal tinker with this a bit as I want to understand why the speed up is greater than the number of cores. It implies overhead in one of the algorithms. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Scalability in std.parallelism
On Sun, 2014-02-23 at 22:55 -0800, Ali Çehreli wrote: […] On my quad-core Intel I get the following (I have two actual cores, four hyperthreads): 3.14159 took 441[ms] 3.14159 took 878[ms] Speedup 1.99093 -5.80829e+09 took 98[ms] -5.80829e+09 took 328[ms] Speedup 3.34694 I am not an expect at all but it looks like the first test cannot take advantage of hyperthreading but the second one can to some degree. I'm fairly sure I don't agree with this hypothesis. Two cores with hyperthreads generally means a maximum speed up of 2 with optimized native code. So for me the first one looks fine whereas the second one seems to indicate a problem in std.parallelism. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Non-Initialized Dynamic Arrays Construction
On Monday, 24 February 2014 at 13:08:52 UTC, Mengu wrote: On Monday, 24 February 2014 at 11:29:39 UTC, bearophile wrote: TheFlyingFiddle: http://dlang.org/phobos/std_array.html#.uninitializedArray is what you want. The OP wants minimallyInitializedArray. uninitializedArray is only for special situations. Perhaps we have to fix the online docs to underline this. Bye, bearophile what's the difference? Well for anything that does not have indirections eg numbers / chars and structs without classes/arrays/pointers in them. Then the two functions are equivalent. So: int[] first = uninitializedArray!(int[])(n); int[] second = minimallyInitializedArray!(int[])(n); Both first and second contain garbaged values. int*[] third = uninitializedArray!(int*[])(n); int*[] forth = minimallyInitializedArray!(int*[])(n); The third array contains garbage but all elements in forth are initialized to null. I assume this behavior is this way since an int with a garbage value is not as bad as a garbage pointer dereference into memory. The OP wants minimallyInitializedArray. uninitializedArray is only for special situations. True but uninitializedArray corresponds to = void semantics for all arrays. minimallyInitializedArray is safer though so i guess it should be used. Wouldn't it be nice to have some kind of syntactic sugar for this similar to what we have for static arrays? BTW: Why isn't simply the following allowed? int n = 3; int[n] = void; Is it too easy to confuse with static array syntax? I don't like this, since it would be wierd from an allocation view point. How is int[n] allocated? Is it the GC? Is it alloca? Can i overide the allocation mechanism? Does the allocated array behave the same as a static array? (it gets destroyed if it goes out of scope) I think it gets a little confusing and also personally i don't want more hidden memory allocations. We already have alot of those.
Programming to Interfaces simplification
http://dpaste.dzfl.pl/c25655e2dfe9
The code above simplifies using interfaces as the programming
object. It allows one to program the derived classes as if they
were not part of an abstraction by mapping the abstracted virtual
methods to concrete methods.
e.g.,
class WindowsGui : iGui
{
WindowsButton _button;
@property WindowsButton button(WindowsButton b) { return
(_button = b); }
mixin(Fixup!(WindowsGui, iButton, WindowsButton));
}
instead of
class WindowsGui : iGui
{
WindowsButton _button;
@property iButton button(iButton b)
{
assert(cast(WindowsButton)b !is null, `Invalid object
type dependency mismatch! Type: `~b.classinfo.name~` Type
Expected: WindowsButton`);
auto bb = cast(WindowsButton)b;
// do work with bb.
}
}
(note the check and the cast are required for all usages of
iButton if one wants to treat it as a WindowsButton. By using the
mix, no checks and no casts are required. Much cleaner looking
and less verbose code results, which is the whole point.)
One problem with the template is that b.classinfo.name returns
the interface instead of the actual class.
In the example on dpaste, b.classinfo.name returns iButton, the
base interface of LinuxButton. I want to display the actual class
name that causes the problem(LinuxButton trying to be used where
a WindowsButton goes).
Obviously the Fixup template is not robust nor optimized for all
cases but should handle most.
Re: What does q{...} mean?
On Monday, 24 February 2014 at 11:41:41 UTC, Gary Willoughby wrote:
I keep seeing this syntax used a bit and i'm stumped to what it means.
What is it?
enum foo = q{
// ???
};
It's a token string though, not a delimited string. See the
section Token Strings on that page.
For Gary: the main use is that your IDE / Editor probably does not
know about it and hence does not highlight/colour it as a string. If
you put to-be-mixed-in code inside this token string, it'll be
highlighted as code in editor. It helps catching stoopid mistakes like
writing 'imutable i = foo();'.
Re: What does q{...} mean?
On Monday, 24 February 2014 at 11:53:00 UTC, anonymous wrote:
On Monday, 24 February 2014 at 11:47:02 UTC, Namespace wrote:
On Monday, 24 February 2014 at 11:41:41 UTC, Gary Willoughby
wrote:
I keep seeing this syntax used a bit and i'm stumped to what
it means. What is it?
enum foo = q{
// ???
};
http://dlang.org/lex.html#DelimitedString
It's a token string though, not a delimited string. See the
section Token Strings on that page.
What are they used for? Simpler for creating code at compile time?
Re: Does opSlice work with immutable values?
On Monday, 24 February 2014 at 11:37:43 UTC, anonymous wrote: Mark opSlice const then. That did it. Thanks. The const/immutable language spec page states that mutable and immutable are implicitly convertible to const. Never thought about this in the other direction though. And from what I understand, the const keyword added to a function makes the this pointer const. Can't see exactly why this works but it does. Anyways appreciate the help. Joseph
Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 14:14:43 UTC, Tobias Pankrath wrote: On Monday, 24 February 2014 at 13:56:01 UTC, Remo wrote: Hi, right now I am truing to figure out how the constructors behave in D2. Question 1: why it is not possible to create custom ctor for struct? The design of D relies on the fact that every type has a T.init property that is known to the compiler and used when in C++ the default ctor would get called. In constructors you can rely on (this == T.init), for example. You need to pick one T.init or default constructors and D picked T.init. Well fortunately it seems to be possible to override init property. But it still does not called at struct construction. http://melpon.org/wandbox/permlink/9EvcdzKUKoufqbJa So what is proper/best way to mimic default constructor for struct ?
Re: Does opSlice work with immutable values?
On 02/24/2014 09:11 AM, Joseph Cassman wrote: the const keyword added to a [member] function makes the this pointer const. Can't see exactly why this works but it does. const means I will not modify data through this reference. Since there is not issue with modification, it can refer to mutable and immutable data. Ali P.S. It would be great if you could show the issue on a minimal code example. I tried to look at your original code but found it to be too long. Sorry... :)
Re: What does q{...} mean?
On 2/24/14, 11:06, Gary Willoughby wrote:
On Monday, 24 February 2014 at 11:53:00 UTC, anonymous wrote:
On Monday, 24 February 2014 at 11:47:02 UTC, Namespace wrote:
On Monday, 24 February 2014 at 11:41:41 UTC, Gary Willoughby wrote:
I keep seeing this syntax used a bit and i'm stumped to what it
means. What is it?
enum foo = q{
// ???
};
http://dlang.org/lex.html#DelimitedString
It's a token string though, not a delimited string. See the
section Token Strings on that page.
What are they used for? Simpler for creating code at compile time?
It allows IDE syntax highlighting and code completion to work with
strings that are going to be mixed in.
You don't have to use it, in fact there's no difference between this and
a normal string.
It's just nicer.
Re: Does opSlice work with immutable values?
On Monday, 24 February 2014 at 17:24:18 UTC, Ali Çehreli wrote: On 02/24/2014 09:11 AM, Joseph Cassman wrote: the const keyword added to a [member] function makes the this pointer const. Can't see exactly why this works but it does. const means I will not modify data through this reference. Since there is not issue with modification, it can refer to mutable and immutable data. Ali P.S. It would be great if you could show the issue on a minimal code example. I tried to look at your original code but found it to be too long. Sorry... :) Thanks for the explanation. Yeah, wasn't sure whether the entire context would be better than providing a meaningless reduced code example. :P See what I can do. Joseph
Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 17:15:10 UTC, Remo wrote:
Well fortunately it seems to be possible to override init
property.
Fortunately? I think not. It's an abomination that, IMO, has to
be annihilated. Recently Andrei suggested adding more explicit
semantics to .init that may give some leeway in this matter,
although this was concerning classes and non-null default values,
so it may not concern structs at all. Regardless, my advice -
don't try to override .init, i.e. don't invite trouble into your
code :)
But it still does not called at struct construction.
http://melpon.org/wandbox/permlink/9EvcdzKUKoufqbJa
Yup.
So what is proper/best way to mimic default constructor for
struct ?
Don't do it. Default construction for struct *is* initialization
of its fields.
If you want to do something other that initialize fields - create
a function and call it explicitly. D is not C++, don't expect it
to behave identically. To make it easier when porting code, you
can always temporarily @disable this() so the compiler will stop
whenever you'd use your special default construction in C++.
As you've mentioned, the code from your example doesn't need any
special default constructors at all, this will work just fine:
struct Vector(T) {
T x = 0, y = 0, z = 0;
this(T v) { x = y = z = v; }
this(T x, T y, T z) { this.x = x; this.y = y; this.z = z; }
}
unittest {
Vector!double v;
auto v2 = Vector!double(1);
auto v3 = Vector!double(1,2,3);
assert(v.x == v.y v.y == v.z v.z == 0);
assert(v2.x == v2.x v2.y == v2.z v2.z == 1);
assert(v3.x == 1 v3.y == 2 v3.z == 3);
}
Also please take a look at those:
https://d.puremagic.com/issues/show_bug.cgi?id=3438
https://d.puremagic.com/issues/show_bug.cgi?id=6080
https://d.puremagic.com/issues/show_bug.cgi?id=7066
https://d.puremagic.com/issues/show_bug.cgi?id=7597
https://d.puremagic.com/issues/show_bug.cgi?id=8816
https://d.puremagic.com/issues/show_bug.cgi?id=8817
https://d.puremagic.com/issues/show_bug.cgi?id=10413
https://d.puremagic.com/issues/show_bug.cgi?id=11307
There may be some others I've missed; the sheer amount and
unresolved state is terrifying.
Re: What does q{...} mean?
On Monday, 24 February 2014 at 17:47:55 UTC, 1100110 wrote:
On 2/24/14, 11:06, Gary Willoughby wrote:
On Monday, 24 February 2014 at 11:53:00 UTC, anonymous wrote:
On Monday, 24 February 2014 at 11:47:02 UTC, Namespace wrote:
On Monday, 24 February 2014 at 11:41:41 UTC, Gary Willoughby
wrote:
I keep seeing this syntax used a bit and i'm stumped to
what it
means. What is it?
enum foo = q{
// ???
};
http://dlang.org/lex.html#DelimitedString
It's a token string though, not a delimited string. See the
section Token Strings on that page.
What are they used for? Simpler for creating code at compile
time?
It allows IDE syntax highlighting and code completion to work
with strings that are going to be mixed in.
You don't have to use it, in fact there's no difference between
this and a normal string.
It's just nicer.
Well... it's more than just looking nicer: there *are* some
differences:
For starters, a token string has no terminating character: You
won't have to chose between or `: It'll simply end with the
last }. This means that if your mixin-string contains some
strings itself, which itself contains quotes, you should have no
problems with it. EG:
auto code = q{
foreach(i; 0 .. 10)
{
writefln(`hello %s`, i);
}
};
Notice how there is nothing special denoting the last } as end
of string: It's *just* the end of string because it is the
closing brace. The only times I've had issues is if you plan to
use the qstring inside a format (*awesome* for generating
code), and the generated code itself contains a formatted write,
in which case, you'll need to escape the % =
auto code = q{
foreach(i; 0 .. %s)
{
writefln(hello: %%s, i);
}
};
mixin(format(code, 10));
Also, a qstring can only contain valid D tokens (token
string). If your mixin string does not adhere some the base D
syntaxic rules, you'll get a compilation error. In particular,
you'll need balanced bracing/parenthesising, and correctly formed
tokens.
Re: Does opSlice work with immutable values?
On Monday, 24 February 2014 at 17:11:20 UTC, Joseph Cassman wrote:
The const/immutable language spec page states that mutable and
immutable are implicitly convertible to const. Never thought
about this in the other direction though. And from what I
understand, the const keyword added to a function makes the
this pointer const. Can't see exactly why this works but it
does.
Implicit conversion from immutable to const is exactly what's
happening. It's not going the other direction.
The this pointer is passed to the method via a hidden parameter.
Qualifiers like const on methods really apply to that hidden this
parameter. Then, when you call a const method on an immutable
object, you really put an immutable object into a const
parameter. And that's fine, because immutable implicitly converts
to const.
In code:
struct S
{
void m() const {}
}
immutable S s;
s.m();
is something like this behind the scenes:
struct S {}
void m(ref const S hidden_this) {}
immutable S s;
m(s);
Parsing and splitting textfile
Hello, Can you point me to an efficient way to parse a text file and split it by certain expression (for example, `\n\nFrom\ .+@.+$`), copying what has already been read to a separate file, and so on till the end of the file? I am trying to implement a mailbox to maildir format conversion application in D, but I would like to avoid loading each mbox completely into memory. Regards, Hugo
Re: Programming to Interfaces simplification
On Mon, 24 Feb 2014 11:36:50 -0500, Frustrated c1514...@drdrb.com wrote:
http://dpaste.dzfl.pl/c25655e2dfe9
The code above simplifies using interfaces as the programming
object. It allows one to program the derived classes as if they
were not part of an abstraction by mapping the abstracted virtual
methods to concrete methods.
e.g.,
class WindowsGui : iGui
{
WindowsButton _button;
@property WindowsButton button(WindowsButton b) { return
(_button = b); }
mixin(Fixup!(WindowsGui, iButton, WindowsButton));
}
instead of
class WindowsGui : iGui
{
WindowsButton _button;
@property iButton button(iButton b)
{
assert(cast(WindowsButton)b !is null, `Invalid object
type dependency mismatch! Type: `~b.classinfo.name~` Type
Expected: WindowsButton`);
auto bb = cast(WindowsButton)b;
// do work with bb.
}
}
Nice work!
One problem with the template is that b.classinfo.name returns
the interface instead of the actual class.
Hm... classinfo (now typeid) should get the most derived type from an
instance. This may be a factor of it being an interface instance vs. a
class instance. A simple test:
Stevens-MacBook-Pro:~ steves$ cat testinterface.d
import std.stdio;
interface I
{
}
class C : I
{
}
void main()
{
I i = new C;
writeln(typeid(i).name);
writeln(typeid(cast(Object)i).name);
}
Stevens-MacBook-Pro:~ steves$ ./testinterface
testinterface.I
testinterface.C
Looks like that is the case. Note that classinfo is not part of the
language any more, and will likely be deprecated. typeid is the correct
mechanism to get the TypeInfo of a derived class.
I'm thinking this is incorrect, typeid should get the derived class type
IMO. It shouldn't be that difficult or costly for the compiler to do.
-Steve
Re: Parsing and splitting textfile
On Mon, 24 Feb 2014 13:52:45 -0500, Hugo Florentino h...@acdam.cu wrote: Hello, Can you point me to an efficient way to parse a text file and split it by certain expression (for example, `\n\nFrom\ .+@.+$`), copying what has already been read to a separate file, and so on till the end of the file? I am trying to implement a mailbox to maildir format conversion application in D, but I would like to avoid loading each mbox completely into memory. Regards, Hugo std.regex -Steve
Re: Parsing and splitting textfile
On Mon, 24 Feb 2014 14:00:09 -0500, Steven Schveighoffer wrote: On Mon, 24 Feb 2014 13:52:45 -0500, Hugo Florentino h...@acdam.cu wrote: Hello, Can you point me to an efficient way to parse a text file and split it by certain expression (for example, `\n\nFrom\ .+@.+$`), copying what has already been read to a separate file, and so on till the end of the file? I am trying to implement a mailbox to maildir format conversion application in D, but I would like to avoid loading each mbox completely into memory. Regards, Hugo std.regex -Steve Specifically std.regex.splitter[1] creates a lazy range over the input. You can couple this with lazy file reading (e.g. `File(mailbox).byChunk (1024).joiner`). Justin
Re: Parsing and splitting textfile
On Mon, 24 Feb 2014 14:00:09 -0500, Steven Schveighoffer wrote: std.regex I should have explained myself better. I have already used regular expressions a couple of times. My doubt here is how parse the file progressively, not loading it completely into memory. If this can be done solely with std.regex, please clarify futher I was thinking in using byLine, but for that, I see first I must use something like: auto myfile = File(usermbox); Doesn't that load the whole file into memory? Regards, Hugo
Re: Parsing and splitting textfile
On Mon, 24 Feb 2014 19:08:16 + (UTC), Justin Whear wrote: Specifically std.regex.splitter[1] creates a lazy range over the input. You can couple this with lazy file reading (e.g. `File(mailbox).byChunk (1024).joiner`). Interesting, thanks.
Re: Parsing and splitting textfile
On Mon, 24 Feb 2014 14:17:14 -0500, Hugo Florentino h...@acdam.cu wrote: On Mon, 24 Feb 2014 14:00:09 -0500, Steven Schveighoffer wrote: std.regex I should have explained myself better. I have already used regular expressions a couple of times. My doubt here is how parse the file progressively, not loading it completely into memory. OK, I did not understand that. If this can be done solely with std.regex, please clarify futher I'm not completely sure, Justin may have a solution. I was thinking in using byLine, but for that, I see first I must use something like: auto myfile = File(usermbox); Doesn't that load the whole file into memory? I do know the answer to this, and it's no. File wraps a C FILE * buffered file. -Steve
Re: Struct constructor, opCall mess.
Fortunately?
Yes I think it is. Of course it could be made a more safe in some
way.
I think the big advantage of D is that it has 'bridge' to C and
C++.
This way it appears to be easy to port some C++ code to D.
And it appears to be easy to interconnect C++ and D code. (via
Dll for example)
@disable this()
Yes this is possible.
But then why it is not possible to use something like this ?
@default this();
For Vector example this works pretty well this way.
But my main problem is more complicated.
extern(C) int init(ref CWrapper p);
extern(C) void free(ref CWrapper p);
struct CWrapper
{
//some data that must be the same at C side.
Data m_data;
this() {
init(this);
}
~this() {
free(this);
}
}
How to do something like this in D ?
Using class appears for me to be wrong direction.
On Monday, 24 February 2014 at 18:13:02 UTC, Stanislav Blinov
wrote:
On Monday, 24 February 2014 at 17:15:10 UTC, Remo wrote:
Well fortunately it seems to be possible to override init
property.
Fortunately? I think not. It's an abomination that, IMO, has to
be annihilated. Recently Andrei suggested adding more explicit
semantics to .init that may give some leeway in this matter,
although this was concerning classes and non-null default
values, so it may not concern structs at all. Regardless, my
advice - don't try to override .init, i.e. don't invite trouble
into your code :)
But it still does not called at struct construction.
http://melpon.org/wandbox/permlink/9EvcdzKUKoufqbJa
Yup.
So what is proper/best way to mimic default constructor for
struct ?
Don't do it. Default construction for struct *is*
initialization of its fields.
If you want to do something other that initialize fields -
create a function and call it explicitly. D is not C++, don't
expect it to behave identically. To make it easier when porting
code, you can always temporarily @disable this() so the
compiler will stop whenever you'd use your special default
construction in C++.
As you've mentioned, the code from your example doesn't need
any special default constructors at all, this will work just
fine:
struct Vector(T) {
T x = 0, y = 0, z = 0;
this(T v) { x = y = z = v; }
this(T x, T y, T z) { this.x = x; this.y = y; this.z = z; }
}
unittest {
Vector!double v;
auto v2 = Vector!double(1);
auto v3 = Vector!double(1,2,3);
assert(v.x == v.y v.y == v.z v.z == 0);
assert(v2.x == v2.x v2.y == v2.z v2.z == 1);
assert(v3.x == 1 v3.y == 2 v3.z == 3);
}
Also please take a look at those:
https://d.puremagic.com/issues/show_bug.cgi?id=3438
https://d.puremagic.com/issues/show_bug.cgi?id=6080
https://d.puremagic.com/issues/show_bug.cgi?id=7066
https://d.puremagic.com/issues/show_bug.cgi?id=7597
https://d.puremagic.com/issues/show_bug.cgi?id=8816
https://d.puremagic.com/issues/show_bug.cgi?id=8817
https://d.puremagic.com/issues/show_bug.cgi?id=10413
https://d.puremagic.com/issues/show_bug.cgi?id=11307
There may be some others I've missed; the sheer amount and
unresolved state is terrifying.
Re: Parsing and splitting textfile
On Mon, 24 Feb 2014 19:08:16 + (UTC), Justin Whear wrote:
Specifically std.regex.splitter[1] creates a lazy range over the
input.
You can couple this with lazy file reading (e.g.
`File(mailbox).byChunk
(1024).joiner`).
Would something like this work? (I cannot test it right now)
auto themailbox = args[1];
immutable uint chunksize = 1024 * 64;
static auto re = regex(`\n\nFrom .+@.+$`);
auto mailbox;
auto mail;
while (mailbox = File(themailbox).byChunk(chunksize).joiner) != EOF)
{
mail = splitter(mailbox, re);
}
If so, I have a couple of furter doubts:
Using splitter actually removes the expression from the string, how
could I reinsert it to the beginning of each resulting string in an
efficient way (i.e. avoiding copying something which is already loaded
in memory)?
I am seeing the splitter fuction returns a struct, how could I
progressively dump to disk each resulting string, removing it from the
struct, so that so that it does not end up having the full mailbox
loaded into memory, in this case as a struct?
Regards, Hugo
Unused mmap library comes as deprecation warning on compile
I have about 12 different separate programmes. While compiling only one of them, it gives as warning as below: /usr/include/dmd/phobos/std/mmfile.d(344): Deprecation: alias core.sys.posix.sys.mman.MAP_ANON is deprecated - Please use core.sys.linux.sys.mman for non-POSIX extensions I used `grep` tool to see any of my library files or programme code have any use of this library. grep mmap -r Result is that binary files of all 12 different programmes have mmap in them. I wondered maybe a Phobos or druntime uses it. Used grep in `/usr/include/dmd` folder as well. As far as I see in the file list, unless mmap is directly imported, no other file uses it. The only thing different about that specific programme is that it uses curl. Does anyone know why that deprecation message is seen while it is not used anywhere? Because that executable gives following error on GDB, and I am thinking that maybe that is its problem. Program received signal SIGUSR1, User defined signal 1. [Switching to Thread 0x2aaab1387700 (LWP 3418)] 0x2b97df7d in poll () at ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) quit
Re: Struct constructor, opCall mess.
Also please take a look at those: https://d.puremagic.com/issues/show_bug.cgi?id=7066 There may be some others I've missed; the sheer amount and unresolved state is terrifying. IMHO Issue 7066 is not a bug but a feature. Of course it could be handled i a bit more safe way. This looks like D2 is still in Beta stadium and not really ready for production use !?
Re: What does q{...} mean?
On 2/24/14, 12:40, monarch_dodra wrote: Also, a qstring can only contain valid D tokens (token string). If your mixin string does not adhere some the base D syntaxic rules, you'll get a compilation error. In particular, you'll need balanced bracing/parenthesising, and correctly formed tokens. Oh, I did not know that. Interesting.
Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 17:15:10 UTC, Remo wrote: So what is proper/best way to mimic default constructor for struct ? Honestly, you can't, and you shouldn't try either. There used to be the static opCall that allowed: auto a = T(); But: a) This is being phased out: If T has a constructor, it will seize to compile. b) It's not default: T a; will still compile, but not construct. The feedback I've been getting is that the correct way to guarantee construction is to do it via a named factory pattern. You disable the this(), so as to force initialization, and make the constructors private. You'll get something along the lines of: T a; //Nope. T a = T(); //Nope T a = T.build(); //OK! T a = T(1, 2); //Nope! T a = T.build(1, 2); //OK! T a = T.init; //OK! Special explicit requrest for non-initialisation. With D's move semantics and (N)RVO, there should be 0 overhead to do this.
Re: Programming to Interfaces simplification
On Monday, 24 February 2014 at 18:59:32 UTC, Steven Schveighoffer
wrote:
On Mon, 24 Feb 2014 11:36:50 -0500, Frustrated
c1514...@drdrb.com wrote:
http://dpaste.dzfl.pl/c25655e2dfe9
The code above simplifies using interfaces as the programming
object. It allows one to program the derived classes as if they
were not part of an abstraction by mapping the abstracted
virtual
methods to concrete methods.
e.g.,
class WindowsGui : iGui
{
WindowsButton _button;
@property WindowsButton button(WindowsButton b) { return
(_button = b); }
mixin(Fixup!(WindowsGui, iButton, WindowsButton));
}
instead of
class WindowsGui : iGui
{
WindowsButton _button;
@property iButton button(iButton b)
{
assert(cast(WindowsButton)b !is null, `Invalid
object
type dependency mismatch! Type: `~b.classinfo.name~` Type
Expected: WindowsButton`);
auto bb = cast(WindowsButton)b;
// do work with bb.
}
}
Nice work!
One problem with the template is that b.classinfo.name returns
the interface instead of the actual class.
Hm... classinfo (now typeid) should get the most derived type
from an instance. This may be a factor of it being an interface
instance vs. a class instance. A simple test:
Stevens-MacBook-Pro:~ steves$ cat testinterface.d
import std.stdio;
interface I
{
}
class C : I
{
}
void main()
{
I i = new C;
writeln(typeid(i).name);
writeln(typeid(cast(Object)i).name);
}
Stevens-MacBook-Pro:~ steves$ ./testinterface
testinterface.I
testinterface.C
Looks like that is the case. Note that classinfo is not part of
the language any more, and will likely be deprecated. typeid is
the correct mechanism to get the TypeInfo of a derived class.
I'm thinking this is incorrect, typeid should get the derived
class type IMO. It shouldn't be that difficult or costly for
the compiler to do.
Thanks. Now the correct type is known. One could, for example,
look for wrappers/adapters/etc to get a linuxbutton into a
windowsbutton(if so desired, throw a well informed error, etc.
Hopefully though, now you see the point. It is a runtime contract
that you make since you can't specify it at compile time(since D
doesn't supports it).
In any case the mixin needs some work and testing. Would just
like to get the proper class name for the type. It is, at the
very least, a proof of concept.
Unfortunately the main downside is the vtable is twice as big.
Final or static methods could be used for this. If the compiler
could manage such a system it could do the job better. (There
would be no extra functions needed and the calls would be faster)
The issue is this: I want to program to interfaces(requiring the
class(WindowsGui) to use base interfaces(iButton) to satisfy the
interface.
The problem is this compile time contract is to generic and makes
coding the classes more verbose. The mixin reduces the verbosity
and provides a runtime contract(we enforce it using asserts in
this case).
The benefit of the mixin is that coding WindowsGui is simpler and
more direct and it's dependency on WindowsButton(not iButton) is
known at compile time(But enforced at runtime by assert). Would
you not agree? Everything else is essentially identical.
Re: Programming to Interfaces simplification
Fixed code with all combination examples: (again, only WindowsButton works with WindowsGui and same for LinuxGui... but the classes don't use iButton like they should!!! Oh, they break the contract!! End of the world!) http://dpaste.dzfl.pl/02ee45225303 Output: Trying WindowsButton with WindowsGui! Do(): WindowsButton WindowsButton.foo(): I'm an extra WindowsButton feature! ...WindowsButton works in WindowsGui! Trying LinuxButton with WindowsGui! Invalid object type dependency mismatch! Type: f324.LinuxButton Type Expected: WindowsButton Trying WindowsButton with LinuxGui! Invalid object type dependency mismatch! Type: f324.WindowsButton Type Expected: LinuxButton Trying LinuxButton with LinuxGui! Do(): LinuxButton ...LinuxButton works in LinuxGui!
Re: Parsing and splitting textfile
On Mon, 24 Feb 2014 15:19:06 -0500, Hugo Florentino wrote:
On Mon, 24 Feb 2014 19:08:16 + (UTC), Justin Whear wrote:
Specifically std.regex.splitter[1] creates a lazy range over the input.
You can couple this with lazy file reading (e.g.
`File(mailbox).byChunk (1024).joiner`).
Would something like this work? (I cannot test it right now)
auto themailbox = args[1];
immutable uint chunksize = 1024 * 64;
static auto re = regex(`\n\nFrom .+@.+$`);
auto mailbox;
auto mail;
while (mailbox = File(themailbox).byChunk(chunksize).joiner) != EOF) {
mail = splitter(mailbox, re);
}
If so, I have a couple of furter doubts:
Using splitter actually removes the expression from the string, how
could I reinsert it to the beginning of each resulting string in an
efficient way (i.e. avoiding copying something which is already loaded
in memory)?
I am seeing the splitter fuction returns a struct, how could I
progressively dump to disk each resulting string, removing it from the
struct, so that so that it does not end up having the full mailbox
loaded into memory, in this case as a struct?
Regards, Hugo
The code you've posted won't work, primarily because you don't need to
loop over the file-reading range, nor will it ever return EOF. Also,
if you don't actually want to remove the regex matches, you can just use
the matchAll function. Here's some _untested_ sample code to set you on
the right track.
import std.algorithm, std.range, std.stdio, std.regex;
void main(string[] args)
{
auto mailboxPath = args[1];
immutable size_t chunksize = 1024 * 64;
auto re = regex(`\n\nFrom .+@.+$`);
// you might want to try using ctRegex
auto mailStarts = File(mailboxPath).byChunk(chunksize).joiner
.matchAll(re);
}
This code won't actually do any work--no data will be loaded from the
file (caveat: the first chunk might be prefetched, not sure), no matches
will actually be performed. If you use `take(10)` on the mailStarts
variable, the code will load only as much of the file (down to the
granularity of chunksize) as is needed to find the first 10 instances of
the regular expression. The regex matches will not copy, but rather
provide slices over the data that is in memory.
And, thinking about this further, you don't want to use my code either--
partly because byChunk reuses its buffer, partly because the functions in
std.regex provide slices over the input data. I think what you'll want
to do is: load the data from File chunk-by-chunk lazily, scan each chunk
with the regex, if you don't find a match, copy that data into an
overlap buffer and repeat, if you do find a match then the contents of
the overlap buffer + the slice up to the current match is one mail, rinse
and repeat. You should be able to encapsulate all of this in clean, lazy
range, but I don't have the time right now to work out if it can be done
by simply compositing existing functions from Phobos.
Justin
Re: Programming to Interfaces simplification
On Mon, 24 Feb 2014 16:24:00 -0500, Frustrated c1514...@drdrb.com wrote:
On Monday, 24 February 2014 at 18:59:32 UTC, Steven Schveighoffer
wrote:
On Mon, 24 Feb 2014 11:36:50 -0500, Frustrated c1514...@drdrb.com
wrote:
http://dpaste.dzfl.pl/c25655e2dfe9
The code above simplifies using interfaces as the programming
object. It allows one to program the derived classes as if they
were not part of an abstraction by mapping the abstracted virtual
methods to concrete methods.
e.g.,
class WindowsGui : iGui
{
WindowsButton _button;
@property WindowsButton button(WindowsButton b) { return
(_button = b); }
mixin(Fixup!(WindowsGui, iButton, WindowsButton));
}
instead of
class WindowsGui : iGui
{
WindowsButton _button;
@property iButton button(iButton b)
{
assert(cast(WindowsButton)b !is null, `Invalid object
type dependency mismatch! Type: `~b.classinfo.name~` Type
Expected: WindowsButton`);
auto bb = cast(WindowsButton)b;
// do work with bb.
}
}
Nice work!
One problem with the template is that b.classinfo.name returns
the interface instead of the actual class.
Hm... classinfo (now typeid) should get the most derived type from an
instance. This may be a factor of it being an interface instance vs. a
class instance. A simple test:
Stevens-MacBook-Pro:~ steves$ cat testinterface.d
import std.stdio;
interface I
{
}
class C : I
{
}
void main()
{
I i = new C;
writeln(typeid(i).name);
writeln(typeid(cast(Object)i).name);
}
Stevens-MacBook-Pro:~ steves$ ./testinterface
testinterface.I
testinterface.C
Looks like that is the case. Note that classinfo is not part of the
language any more, and will likely be deprecated. typeid is the correct
mechanism to get the TypeInfo of a derived class.
I'm thinking this is incorrect, typeid should get the derived class
type IMO. It shouldn't be that difficult or costly for the compiler to
do.
Thanks. Now the correct type is known. One could, for example, look for
wrappers/adapters/etc to get a linuxbutton into a windowsbutton(if so
desired, throw a well informed error, etc.
Hopefully though, now you see the point. It is a runtime contract
that you make since you can't specify it at compile time(since D
doesn't supports it).
Always have seen the point, it is why I suggested this solution.
Unfortunately the main downside is the vtable is twice as big. Final or
static methods could be used for this. If the compiler could manage such
a system it could do the job better. (There would be no extra functions
needed and the calls would be faster)
First, the vtable is not per-instance, so it doesn't detract too much from
the solution.
Second, the concrete function does not need to be virtual, make it final,
and it won't add to the vtable.
The issue is this: I want to program to interfaces(requiring the
class(WindowsGui) to use base interfaces(iButton) to satisfy the
interface.
The problem is this compile time contract is to generic and makes coding
the classes more verbose. The mixin reduces the verbosity and provides a
runtime contract(we enforce it using asserts in this case).
The benefit of the mixin is that coding WindowsGui is simpler and more
direct and it's dependency on WindowsButton(not iButton) is known at
compile time(But enforced at runtime by assert). Would you not agree?
Everything else is essentially identical.
I have written such libraries before (I had an OS abstraction library in
C++), it's not always pretty.
-Steve
Re: Unused mmap library comes as deprecation warning on compile
On 02/24/2014 12:20 PM, Tolga Cakiroglu wrote: I have about 12 different separate programmes. While compiling only one of them, it gives as warning as below: /usr/include/dmd/phobos/std/mmfile.d(344): Deprecation: alias core.sys.posix.sys.mman.MAP_ANON is deprecated - Please use core.sys.linux.sys.mman for non-POSIX extensions It is a compilation message generated by druntime/src/core/sys/posix/sys/mman.d: static import core.sys.linux.sys.mman; deprecated(Please use core.sys.linux.sys.mman for non-POSIX extensions) alias MAP_ANON = core.sys.linux.sys.mman.MAP_ANON; So, phobos/std/mmfile.d imports a module that has been deprecated by druntime: private import core.sys.posix.sys.mman; Create a bug report or pull request ;) so that it imports the correct mman. Ali
Re: What does q{...} mean?
Gary Willoughby wrote:
I keep seeing this syntax used a bit and i'm stumped to what it
means. What is it?
enum foo = q{
// ???
};
q{} string literals (so-called token strings) are a nice D feature - D
garantees that tokens in between brackets are valid D tokens. This makes
them perfect for storing D source code. They are quite useful for string
mixins for an example.
--
http://dejan.lekic.org
Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 21:06:03 UTC, monarch_dodra wrote: On Monday, 24 February 2014 at 17:15:10 UTC, Remo wrote: So what is proper/best way to mimic default constructor for struct ? Honestly, you can't, and you shouldn't try either. There used to be the static opCall that allowed: auto a = T(); But: a) This is being phased out: If T has a constructor, it will seize to compile. b) It's not default: T a; will still compile, but not construct. The feedback I've been getting is that the correct way to guarantee construction is to do it via a named factory pattern. You disable the this(), so as to force initialization, and make the constructors private. You'll get something along the lines of: T a; //Nope. T a = T(); //Nope T a = T.build(); //OK! T a = T(1, 2); //Nope! T a = T.build(1, 2); //OK! T a = T.init; //OK! Special explicit requrest for non-initialisation. With D's move semantics and (N)RVO, there should be 0 overhead to do this. Thanks, I will try to make this this way and look how well it will work. But it could complicate connection from C++ to D and back. Where I can find more info about 'D's move semantics'? Apparently it is not the same as rvalue reference and move semantics in C++11 ?
Re: Strange behaviour with -profile
On Sunday, 23 February 2014 at 20:46:47 UTC, Jesse Phillips wrote: On Sunday, 23 February 2014 at 08:32:50 UTC, Danny Arends wrote: I have a medium sized project at: https://github.com/DannyArends/DaNode it compiles fine with the normal build switches I used: $ rdmd --build-only -O -gc -release -w danode/server.d if I compile with the -profile switch, I get a weird error: $ rdmd --build-only -O -gc -release -profile -w danode/server.d Warning: statement is not reachable I thought DMD provided an error if you tried to optimize with debug symbols. -O should not be used with -gc, -g, or -profile Maybe that will address the problem. While I think my advice is still correct, I can't seem to find the combination which caused a compiler message: dmd -g -O -profile -release -debug -inline test.d Also found that dub will do the same odd mix of switches: [profile, optimize, inline, debugInfo] Debug and optimize just don't make sense together, and profile needs debug symbols I thought.
Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 23:34:51 UTC, Remo wrote: Where I can find more info about 'D's move semantics'? Apparently it is not the same as rvalue reference and move semantics in C++11 ? Here is the place I know of: http://dconf.org/2013/talks/cehreli.html
Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 20:35:54 UTC, Remo wrote: This looks like D2 is still in Beta stadium and not really ready for production use !? I believe it is ready for production, but you can't expect it to be ready in all cases. Mostly its lack of readiness isn't because of the language though. For example it isn't ready for production Android/iOS development, because it hasn't been done yet. It isn't ready for Epic to write Unreal 5 Engine in it. However if Valve believed in D I'd say it was ready for them to take on the challenge and write Source 2 in D.
Re: What does q{...} mean?
On Monday, 24 February 2014 at 18:40:14 UTC, monarch_dodra wrote: Also, a qstring can only contain valid D tokens (token string). If your mixin string does not adhere some the base D syntaxic rules, you'll get a compilation error. In particular, you'll need balanced bracing/parenthesising, and correctly formed tokens. And even with all these rules, it still works great for other languages like Lua.
Re: Struct constructor, opCall mess.
On Tuesday, 25 February 2014 at 06:06:22 UTC, Jesse Phillips wrote: On Monday, 24 February 2014 at 20:35:54 UTC, Remo wrote: This looks like D2 is still in Beta stadium and not really ready for production use !? If someone thinks that C++ was production ready in 1998, just go and try a C++ compiler from this time.
Re: Struct constructor, opCall mess.
On Monday, 24 February 2014 at 19:41:57 UTC, Remo wrote:
For Vector example this works pretty well this way.
But my main problem is more complicated.
extern(C) int init(ref CWrapper p);
extern(C) void free(ref CWrapper p);
struct CWrapper
{
//some data that must be the same at C side.
Data m_data;
this() {
init(this);
}
~this() {
free(this);
}
}
How to do something like this in D ?
Using class appears for me to be wrong direction.
1) Please comment after previous speaker, not before.
You can't avoid default struct constructor problem if functions
which you call in constructors are not at least CTFEable because
you would need to call them if you wish to define default struct
constructor. Since this is not your case, you can do:
2) You can use static OpCall, Voldemort type or alias this. In
case of alias this it looks like:
extern(C) int printf(const char*, ...);
extern(C) int init(CWrapper* p) { printf(init\n); return 0; }
extern(C) void d_free(CWrapper* p) { printf(free\n); }
struct Data { void do_something(){} }
struct CWrapper
{
//some data that must be the same at C side.
Data m_data;
bool m_init;
/*this(int) {
init(this);
}*/
~this() {
d_free(this);
}
Data get()
{
if (!m_init)
init(this);
return m_data;
}
alias get this;
}
void main()
{
CWrapper cw;
cw.do_something();
}
In case of Voldermort struct some struct is defined inside
function, so the only way (in theory) to create an instance is to
call that function. It is inconviniet but guarantees that you
will not have non initialzed structs (in theory).
extern(C) int printf(const char*,...);
auto make_struct()
{
struct Data{}
struct CWrapper
{
extern(C) int m_init(CWrapper* p){ return 0; }
extern(C) void m_free(CWrapper* p){ printf(free\n);}
//some data that must be the same at C side.
Data m_data;
this(int) {
m_init(this);
}
~this() {
m_free(this);
}
}
return CWrapper(0);
}
void main()
{
auto x = make_struct();
}
4) Please do not define free() function.
