I'm sure there is such a topic on the forum, but after scrolling
through the search, I didn't find anything. The bottom line is
that I want to enable compilation of C sources in DUB and then
build the project with the connection of libraries. I would like
to see an example of such a `dub.json`
Some code I have:
```d
alias Operator = dstring function(dstring input);
//List of all operations.
package Operator[dstring] opList;
//List of all functions.
package dstring[dstring] funcList;
//Functions that may not be deleted.
package dstring[dstring] noTouch;
//Initialize the basic arithm
On Wed, May 04, 2022 at 10:04:53PM +, forkit via Digitalmars-d-learn wrote:
> On Wednesday, 4 May 2022 at 21:55:18 UTC, H. S. Teoh wrote:
> > On Wed, May 04, 2022 at 09:46:50PM +, forkit via Digitalmars-d-learn
> > wrote: [...]
[...]
> > > To deny a programmer the option to release the memo
On Wednesday, 4 May 2022 at 21:55:18 UTC, H. S. Teoh wrote:
On Wed, May 04, 2022 at 09:46:50PM +, forkit via
Digitalmars-d-learn wrote: [...]
That languages with GC typically give the programmer some
control over the GC, is evidence that programmers do care
(otherwise such features would no
On Wednesday, 4 May 2022 at 15:04:13 UTC, cc wrote:
The MemUtils package offers a `ScopedPool` utility that seems
interesting. It isn't well documented however so I have no
idea if it actually works like I expect. I presume this would
work something akin to a VM memory snapshot/rollback for t
On Wed, May 04, 2022 at 09:46:50PM +, forkit via Digitalmars-d-learn wrote:
[...]
> That languages with GC typically give the programmer some control over
> the GC, is evidence that programmers do care (otherwise such features
> would not be needed).
>
> To deny a programmer the option to rele
On Wednesday, 4 May 2022 at 12:57:26 UTC, Ali Çehreli wrote:
On 5/3/22 22:37, forkit wrote:
> In any case, I disagree that caring about when memory gets
deallocted
> means you shouldn't be using GC. (or did I get that one wrong
too??)
At least I don't agree with you there. :) Yes, one should no
The MemUtils package offers a `ScopedPool` utility that seems
interesting. It isn't well documented however so I have no idea
if it actually works like I expect. I presume this would work
something akin to a VM memory snapshot/rollback for the GC? It
would be pretty handy for some scenarios,
On 5/3/22 22:37, forkit wrote:
> In any case, I disagree that caring about when memory gets deallocted
> means you shouldn't be using GC. (or did I get that one wrong too??)
At least I don't agree with you there. :) Yes, one should not care about
how memory gets freed if one did not care how th
On Wednesday, 4 May 2022 at 10:15:18 UTC, bauss wrote:
It can be a bug __and__ an enhancement.
Alright, but we need a DIP to get the enhancement which can be
in. :-) I don't think anything will improve without one.
I would assume that C++ template resolution is O(N), so I am not
as pessimis
On Tuesday, 3 May 2022 at 07:11:48 UTC, Ola Fosheim Grøstad wrote:
As you see, someone will have to write a DIP to fix this bug,
as the language authors don't consider it a bug, but an
enhancement.
I don't believe those two words are mutually exclusive.
It can be a bug __and__ an enhancem
On Wednesday, 4 May 2022 at 08:23:33 UTC, Mike Parker wrote:
On Wednesday, 4 May 2022 at 05:37:49 UTC, forkit wrote:
That's not at all what I said. You don't have to care about
*when* memory is deallocated, meaning you don't have to
manage it yourself.
In any case, I disagree that caring abo
On Wednesday, 4 May 2022 at 05:37:49 UTC, forkit wrote:
inscope int[] i = new int[1];
You often see the "here's an array of ints that exists only in
one scope to do one thing, should we leave it floating in memory
or destroy it immediately?" as examples for these GC discussions.
Not
On Wednesday, 4 May 2022 at 05:37:49 UTC, forkit wrote:
That's not at all what I said. You don't have to care about
*when* memory is deallocated, meaning you don't have to manage
it yourself.
In any case, I disagree that caring about when memory gets
deallocted means you shouldn't be using G
14 matches
Mail list logo
