Constructor called instead of opAssign()
I have generic types that are initialized by a base class for
each derived object:
struct S(T) {
this(T val) {
value = 100;
}
void opAssign(T val) {
value = val;
}
T value;
}
class A {
this(this T)() {
foreach (property; __traits(allMembers, T)) {
static if (property == "x") {
__traits(getMember, cast(T) this, property) = 50;
}
}
}
}
class B : A {
S!int x;
this(int val) {
assert(x.value == 50);
x = val;
}
}
auto b = new B(200);
assert(b.x.value == 200); // 100
Although x is well initialized by A by calling opAssign(), the
compiler doesn't care and calls the S!T ctor() on B again and
opAssign() is ignored. Is this a bug or a rule?
Re: Are there any containers that go with allocators?
On Tuesday, 9 February 2021 at 12:18:41 UTC, John Burton wrote: Normally I'm happy with the GC containers in D, they work well and suit my use. I have a few uses that would benefit from allocation in memory arenas or local stack based allocation. Looks like std.experimental has allocators for those use cases. But I can't find any containers to make use of those allocators. The built in ones use GC managed memory, there are std.container but they appear to use malloc/free which again is useful but not what I'm looking for. I'd like resizeable arrays, hashmaps and strings that I can allocate using an allocator? Am I missing something in the standard library, or a way to use the existing ones, or is it just that nobody has implemented this kind of thing yet? i use https://github.com/ikod/ikod-containers
Re: Why filling AA in shared library freezes execution?
On Saturday, 6 February 2021 at 15:21:17 UTC, Siemargl wrote: extern(C) __gshared string[] rt_options = [ "gcopt=parallel:0" ]; LDC 1.24 is also affected and rt_options helps
Re: Minimize GC memory footprint
On Saturday, 13 February 2021 at 19:14:32 UTC, frame wrote: On Saturday, 13 February 2021 at 17:54:53 UTC, Siemargl wrote: And it works too, for 32-bit also =) Consuming about 100MB RAM. Yes, Appender is nice but I had no control about .data since the real property is private so I chose that edgy example to find the problem with the GC. As someone mentioned before, in a real application you would choose some pre-allocation like reserve() on Appender instead which performs better. LDC 1.24 is unaffected of this bug and x64 target consume less memory.
Re: Is this the proper way to do it?
On Saturday, 13 February 2021 at 05:52:34 UTC, Jack wrote: I have a base class A, where I make specific operator depending on the derived class type. Currently I'm using something like this: c is a class derived from A bool shouldDoX = (cast(X)c) !is null || (cast(Y)c) !is null || (cast(K)c) !is null ... ; as the number of cast(C) !is null is growing, I'm afraid of this being a inelegant or even poor performance approach. How would you do that? I would just use an (empty) interface on that classes and do test for that.
Re: Minimize GC memory footprint
On Saturday, 13 February 2021 at 17:54:53 UTC, Siemargl wrote: And it works too, for 32-bit also =) Consuming about 100MB RAM. Yes, Appender is nice but I had no control about .data since the real property is private so I chose that edgy example to find the problem with the GC. As someone mentioned before, in a real application you would choose some pre-allocation like reserve() on Appender instead which performs better.
Re: vibe.d json deserializeJson!Foo and ddbc.update!Foo
On Saturday, 13 February 2021 at 01:21:56 UTC, Steven Schveighoffer wrote: On 2/12/21 6:22 PM, Chris Bare wrote: [...] Does @ignore work? That's a UDA that tells vibe to ignore the field. Though I don't know if it means it leaves it alone completely. https://vibed.org/api/vibe.data.serialization/ignore -Steve @ignore just prevents it from throwing an error if the field is not in the json. The field still gets overwritten with it's default value in the struct.
Re: Minimize GC memory footprint
On Tuesday, 9 February 2021 at 04:05:04 UTC, frame wrote:
On Saturday, 6 February 2021 at 20:24:00 UTC, frame wrote:
Hmmm.. with -m64 it's reporting 80 MB used, 203 MB are really
marked as private bytes. Constant. If I use GC.minimize() it
goes up and down and sometimes consumes more than 203 MB. Best
is 100MB. But it doesn't leak endlessly like the 32bit variant.
Hmm, I try to rewrite example in C# and it just hangs in GC, when
str += "1" added 5 million times.
Then i fix this using StringBuilder, as documented. It works fine.
Next i searched flang forums for D's StringBuilder - found this
https://forum.dlang.org/post/l667ab$cfa$1...@digitalmars.com
auto strBuilder = appender!string;
foreach (i; 0 .. 50_000_00) {
strBuilder.put("a");
And it works too, for 32-bit also =)
Consuming about 100MB RAM.
Re: Is this the proper way to do it?
On Saturday, 13 February 2021 at 05:52:34 UTC, Jack wrote: I have a base class A, where I make specific operator depending on the derived class type. Currently I'm using something like this: c is a class derived from A bool shouldDoX = (cast(X)c) !is null || (cast(Y)c) !is null || (cast(K)c) !is null ... ; as the number of cast(C) !is null is growing, I'm afraid of this being a inelegant or even poor performance approach. How would you do that? Option 1, reverse the condition, && op will shortcut boolean conditions bool shouldNotDoX = cast(X)c && cast(Y)c && cast(K)c && ... Option 2, reverse the condition by testing the classes that are not supposed to "do" it, if you have less classes in that category. bool shoudldNotDoX = cast(P)c || cast(Q)c
Re: Trying to reduce memory usage
On Saturday, 13 February 2021 at 04:19:17 UTC, Ali Çehreli wrote:
On 2/11/21 6:22 PM, H. S. Teoh wrote:
>bool[size_t] hashes;
I would start with an even simpler solution until it's proven
that there still is a memory issue:
import std.stdio;
void main() {
bool[string] lines;
foreach (line; stdin.byLine) {
if (line !in lines) {
stdout.writeln(line);
lines[line.idup] = true;
}
// else this line already seen before; just skip it
}
}
(Grr... Thanks for the tab characters! :p)
Ali
Try this Boost Licensed tool.
https://github.com/eBay/tsv-utils/tree/master/tsv-uniq
