On Wednesday, 17 April 2019 at 23:44:42 UTC, Adam D. Ruppe wrote:
In C++, if you define a struct/class, and constructors apply
for this.
struct Test {
Test(const char* foo) {}
};
void cool(Test t) {}
cool("string"); // works
That works in C++, unless you mark that constructor with
`ex
On Wednesday, 17 April 2019 at 23:57:41 UTC, Meta wrote:
Not at all what you want, but it may be useful for figuring out
where the leaks are. Have you tried compiling with -vgc?
That wouldn't help me much here because I know parts are GC
allocating, and I'm ok with that. What I want to know ar
On Wednesday, 17 April 2019 at 22:37:38 UTC, Adam D. Ruppe wrote:
On Wednesday, 17 April 2019 at 19:07:46 UTC, Jacob Carlborg
wrote:
Perhaps try some of these flags [1] and [2].
oooh, those are very interesting too.
What I was kinda hoping is it would have stats for which file
and line of co
On Wednesday, 17 April 2019 at 23:26:16 UTC, Stefanos Baziotis
wrote:
I argue C++'s mistake was *out-out* implicit construction
What do you mean by out-out?
In C++, if you define a struct/class, and constructors apply for
this.
struct Test {
Test(const char* foo) {}
};
void cool(Test t
On Wednesday, 17 April 2019 at 16:33:17 UTC, Adam D. Ruppe wrote:
[...]
Thanks for the info!
I argue C++'s mistake was *out-out* implicit construction
What do you mean by out-out?
- Stefanos
On Wednesday, 17 April 2019 at 19:07:46 UTC, Jacob Carlborg wrote:
Perhaps try some of these flags [1] and [2].
oooh, those are very interesting too.
What I was kinda hoping is it would have stats for which file and
line of code was responsible for most allocations; a detailed
profile. But e
On Wednesday, 17 April 2019 at 16:57:51 UTC, Julian wrote:
It might be something obvious on visual inspection.
Huh, indeed this got me the biggest
obvious-in-retrospect-but-i-didnt-think-to-look-there win of the
day - the memory dump showed a super-bloated scrollback buffer in
my terminal em
On Wednesday, 17 April 2019 at 17:03:20 UTC, Martin Krejcirik
wrote:
Do you run GC.minimize ?
Not explicitly, but I did try `call gc_minimize()` from the
debugger when attached to processes and it made no difference.
Maybe I'll add a hook to the program to call that on a hotkey
press for th
On 2019-04-17 18:27, Adam D. Ruppe wrote:
I am willing to recompile and run again, though I need to actually use
the programs, so if instrumenting makes them unusable it won't really
help. Is there a magic --DRT- argument perhaps? Or some trick with gdb
attaching to a running process I don't k
On Wednesday, 17 April 2019 at 16:27:02 UTC, Adam D. Ruppe wrote:
Each individual process eats ~30-100 MB, but that times 60 =
trouble. They start off small, like 5 MB, and grow over weeks
or months, so it isn't something I can easily isolate in a
Do you run GC.minimize ?
On Wednesday, 17 April 2019 at 16:27:02 UTC, Adam D. Ruppe wrote:
D programs are a vital part of my home computer infrastructure.
I run some 60 D processes at almost any time and have
recently been running out of memory.
Each individual process eats ~30-100 MB, but that times 60 =
trouble
On Wednesday, 17 April 2019 at 15:23:06 UTC, Stefanos Baziotis
wrote:
Sorry if this has been asked again, I didn't find anything.
Do we know the reason why it is not supported?
Basically implicit construction was considered a mistake in C++
and D didn't want to repeat that mistake. Most code g
D programs are a vital part of my home computer infrastructure. I
run some 60 D processes at almost any time and have recently
been running out of memory.
Each individual process eats ~30-100 MB, but that times 60 =
trouble. They start off small, like 5 MB, and grow over weeks or
months,
On Wednesday, 17 April 2019 at 12:48:52 UTC, Adam D. Ruppe wrote:
This is the "implicit construction" I sometimes talk about
and D doesn't support it, by design (alas).
Sorry if this has been asked again, I didn't find anything.
Do we know the reason why it is not supported?
There's t
btw if you haven't seen my version of the gtk-d docs, check it
out:
http://gtk-d.dpldocs.info/gtk.Adjustment.Adjustment.html
It does various cross-referencing the official versions don't,
among other things. You can see the GtkAdjustment there is not
linked, because it is the C version, where
On Wednesday, 17 April 2019 at 15:05:22 UTC, Adam D. Ruppe wrote:
On Wednesday, 17 April 2019 at 14:49:33 UTC, Ron Tarrant wrote:
For instance, one of the Adjustment constructors looks like
this:
public this(GtkAdjustment* gtkAdjustment, bool ownedRef
Those aren't the same thing! On
On Wednesday, 17 April 2019 at 14:49:33 UTC, Ron Tarrant wrote:
For instance, one of the Adjustment constructors looks like
this:
public this(GtkAdjustment* gtkAdjustment, bool ownedRef
Those aren't the same thing! One is Adjustment, the D wrapper
class, and the other is GtkAdjustme
I've come across this a few times in the wrapper code for GtkD
where one of the constructors for an object takes an argument of
the same type the constructor produces.
For instance, one of the Adjustment constructors looks like this:
public this(GtkAdjustment* gtkAdjustment, bool owned
On Wednesday, 17 April 2019 at 12:20:49 UTC, Stefanos Baziotis
wrote:
I want to be able to make it work array-like to have compact
function calls.
Something like this:
test([1,2,3]);
This is the "implicit construction" I sometimes talk about
and D doesn't support it, by design (alas).
T
I have a custom Buf struct (working as a simple vector)
struct Buf(T) {
size_t cap, len;
T *data;
@nogc
this(T[] arr) {
reserve(arr.length);
foreach(item; arr) {
push(item);
}
}
...
};
And I have a function like this:
void test(Buf!(i
20 matches
Mail list logo
