On Tuesday, 30 November 2021 at 09:01:38 UTC, Iain Buclaw wrote:
On Monday, 29 November 2021 at 14:48:21 UTC, Luís Ferreira
wrote:
[...]
Indeed, gdb assumes calling convention is same as default for
target (actually its been years since I last looked, but are
calling conventions tags in
Hello,
I'm trying to use `gdb` to debug D binaries, but I'm having
trouble accessing the methods of a struct or class. It seems that
`gdb` doesn't see them.
Given the following simple example
```
// test.d
struct S
{
int x;
void myPrint() { writefln("x is %s\n", x); }
}
void
On Tuesday, 23 June 2020 at 09:15:57 UTC, WebFreak001 wrote:
[...]
it will give me a range violation at runtime and not init it
for me at all.
There is `aa.require("a", Foo.init) += 4;` now which solves
this, but I would prefer having the small simple syntax well
defined for all types
On Monday, 26 August 2019 at 01:06:55 UTC, James Blachly wrote:
The documentation for std.experimental.allocator is a little
dense and I wanted to make sure I am understanding composition
correctly.
[...]
Yes, you are correct.
Edi
On Tuesday, 20 August 2019 at 09:40:06 UTC, Björn Lindström wrote:
Hello,
I've recently decided to pick up D, and have started doing some
exercises on
https://exercism.io/ (a non-profit programming exercise
platform), which I think is an excellent way to pick up the
basics in a new language.
On Monday, 29 July 2019 at 17:32:58 UTC, Matt wrote:
I've noticed that for some ranges in Phobos empty is marked
const (e.g. iota) but for other ranges (e.g. multiwayMerge) it
is not const. Is there a reason why? Isn't empty guaranteed not
to alter the data of the range and so should be const?
Cheers, everybody
I'm working on this as part of my GSoC project [0].
I'm working on building gdc with the auto-generated `frontend.h`
[1], but I'm having some issues
There are functions in dmd that don't have an `extern (C)` or
`extern (C++)` but they are used by gdc (are exposed in `.h`
Hello
According to the spec[0], D supports zero length arrays [1].
I have given this a shot at https://run.dlang.io/is/PwbPxJ
Attempting to use the zero-length array results in a compiler
error
`a.contents[2]` -> Error: array index 2 is out of bounds
(*a).contents[0 .. 0]
The way I've
On Friday, 8 February 2019 at 06:55:15 UTC, Jerry wrote:
On Friday, 8 February 2019 at 04:51:08 UTC, Sudhi wrote:
On Friday, 8 February 2019 at 04:30:23 UTC, Arun
Chandrasekaran wrote:
On Friday, 8 February 2019 at 04:13:39 UTC, Sudhi wrote:
[...]
Works fine for me with DMD64 D Compiler
On Tuesday, 5 February 2019 at 19:12:43 UTC, James Blachly wrote:
However, even when allowing (pseudo)duplicates, this means the
distinct intervals with same start but different end
coordinates are not deterministically placed/sorted within the
tree, because they are not sortable with the
On Monday, 4 February 2019 at 22:54:01 UTC, James Blachly wrote:
I tried to implement an interval tree backed by
std.container.rbtree today and fell flat.
A standard way to make an interval tree is to make an augmented
tree; I supposed since rbtree was a generic container and
because I could
On Monday, 26 November 2018 at 09:28:37 UTC, Basile B. wrote:
On Monday, 26 November 2018 at 09:04:25 UTC, Per Nordlöw wrote:
Why is there no
- __traits(isArray, T)
alongside
- __traits(isStaticArray, T) and
- __traits(isAssociativeArray, T)
when dmd already has `ENUMTY.Tarray` alongside
-
On Sunday, 18 November 2018 at 11:29:51 UTC, John Chapman wrote:
On Saturday, 17 November 2018 at 21:11:38 UTC, Adam D. Ruppe
wrote:
On Saturday, 17 November 2018 at 17:58:54 UTC, John Chapman
wrote:
Has anyone had a similar need and come up with a solution?
You might be able to just pass it
On Thursday, 25 October 2018 at 21:00:46 UTC, Adam D. Ruppe wrote:
On Thursday, 25 October 2018 at 19:56:18 UTC, Stanislav Blinov
wrote:
The current behavior of the compiler is quite the opposite of
those "same as" above.
Yeah, I guess I am maybe selectively reading the spec in light
of the
On Thursday, 25 October 2018 at 12:55:38 UTC, Adam D. Ruppe wrote:
On Thursday, 25 October 2018 at 12:25:37 UTC, Eduard Staniloiu
wrote:
IMHO, this is a bug. The code should lower to calls to
opAssing for types that define opAssign.
The spec doesn't exactly say it uses memset, but it does
On Thursday, 25 October 2018 at 13:01:06 UTC, Eduard Staniloiu
wrote:
On Thursday, 25 October 2018 at 12:38:44 UTC, Paul Backus wrote:
On Thursday, 25 October 2018 at 12:25:37 UTC, Eduard Staniloiu
wrote:
As I wrote in the comments above, I was expecting `a[] = b[]`
to iterate the slices and
On Thursday, 25 October 2018 at 12:38:44 UTC, Paul Backus wrote:
On Thursday, 25 October 2018 at 12:25:37 UTC, Eduard Staniloiu
wrote:
As I wrote in the comments above, I was expecting `a[] = b[]`
to iterate the slices and assign the elements of b into a.
What really happens is a memcpy: as
Hello, everyone!
I have a question regarding the expected behaviour of the
built-in array's opSliceAssign.
Given the following code:
```
import std.stdio;
struct A
{
int x;
ref A opAssign(A rhs)
{
writefln("slice_bug.opAssign: begin");
return this;
}
}
On Monday, 9 April 2018 at 14:51:24 UTC, Per Nordlöw wrote:
On Monday, 9 April 2018 at 13:51:47 UTC, Steven Schveighoffer
wrote:
Well, you know the type, because make returned it no? The
contract is, you call obj = make!X(args), then you have to
call dispose(obj), where obj is of the type X.
On Friday, 6 April 2018 at 21:49:37 UTC, Per Nordlöw wrote:
On Tuesday, 3 April 2018 at 09:14:28 UTC, Eduard Staniloiu
wrote:
So, say `reg` is your allocator, your workflow would be
auto obj = reg.make!Type(args);
/* do stuff */
reg.dispose(obj); // If Type has a __dtor, it will call
On Monday, 2 April 2018 at 21:32:47 UTC, Steven Schveighoffer
wrote:
On 4/2/18 5:16 PM, Per Nordlöw wrote:
On Monday, 2 April 2018 at 20:43:01 UTC, Alexandru Jercaianu
wrote:
I am not completely sure how to solve this, but maybe we can
find some clues here [1].
It seems like we should use
On Monday, 2 April 2018 at 10:26:32 UTC, RazvanN wrote:
Hi all,
Let's say we have this code:
struct B
{
int a;
this(int a) immutable
{
this.a = 7;
}
this(int a)
{
this.a = 10;
}
}
void main()
{
B a = immutable B(2);
writeln(a.a);
a.a =
On Wednesday, 28 February 2018 at 18:27:49 UTC, Jiyan wrote:
On Wednesday, 28 February 2018 at 18:23:04 UTC, Jiyan wrote:
Hey,
i thought i had understood postblit, but in my Code the
following is happening (simplified):
struct C
{
this(this){/*Do sth*/}
list!C;
void opAssign(const C c)
{
On Saturday, 17 February 2018 at 12:33:25 UTC, Nordlöw wrote:
I'm struggling with making
https://github.com/nordlow/phobos-next/blob/master/src/pure_mallocator.d
callable in pure functions such as here
https://github.com/nordlow/phobos-next/blob/master/src/pure_mallocator.d#L84
Shouldn't a
On Saturday, 11 November 2017 at 14:26:34 UTC, Nordlöw wrote:
Have anybody used allocators to construct class instances?
I might be wrong, but I think you are looking for
std.experimental.allocator.make [0]
[0] -
https://dlang.org/phobos/std_experimental_allocator.html#make
On Wednesday, 11 October 2017 at 09:39:04 UTC, user1234 wrote:
On Wednesday, 11 October 2017 at 09:27:49 UTC, John Burton
wrote:
[...]
I therefore feel like I ought to not use assert and should
instead validate my assumptions with an if statement and a
throw or exit or something.
Yes,
On Saturday, 20 May 2017 at 10:48:54 UTC, Gary Willoughby wrote:
Looks like you would want to use emplace [0] here.
public this(int n)
{
this._data = (cast(Foo*) calloc(n, Foo.sizeof))[0 .. n];
foreach(ref element; this._data)
{
On Friday, 14 October 2016 at 16:33:51 UTC, Andre Pany wrote:
What I miss is s.th. to get the child Pids of a parent Pid.
Again I can use OS dependent functionality to retrieve the
processIDs of the children, but how to convert these processIDs
to Pids for usage with kill/wait functions?
On
28 matches
Mail list logo
