On Monday, 17 January 2022 at 03:11:50 UTC, Steven Schveighoffer
wrote:
The profile=gc appears to only show GC allocations that the
*compiler* initiates (i.e. via `new`, array operations (like
appending) or closure allocations). It does not detect that the
functions that actually allocate mem
On 1/16/22 9:42 PM, forkit wrote:
On Monday, 17 January 2022 at 00:54:19 UTC, forkit wrote:
// mArr2 is a dynamic array allocated on the gc heap
// although compiling with '-profile=gc' incorrectly suggests otherwise.
if add @nogc to above code:
(8): Error: array literal in `@nogc`
On Monday, 17 January 2022 at 00:54:19 UTC, forkit wrote:
..
module test;
import std;
@safe void main()
{
// mArr1 is a dynamic array allocated on the gc heap.
int[][] mArr1 = [[1, 2], [3, 4], [5, 6], [7, 8]];
static assert(is(typeof(mArr1.array(;
alias R1 = typeof(mArr1)
On 1/16/22 17:51, H. S. Teoh wrote:
>> In practice, malloc'ed memory is cleared e.g. by memset(). Or, there is
>> calloc() which returns memory filled with zeros.
>
> Correction: malloc() is not guaranteed to clear the allocated memory.
Agreed. What I meant is, the programmer ordinarily clears i
On Monday, 17 January 2022 at 01:06:05 UTC, Salih Dincer wrote:
```d
// Taaata, magic...
// Your eyes don't surprise you!
typeid(range).writeln(": ", range);
typeid(slices).writeln(": ", slices);
```
In fact, although range and slice seem to be equal to each other,
they are not! Slice
On Sun, Jan 16, 2022 at 08:21:29AM -0800, Ali Çehreli via Digitalmars-d-learn
wrote:
> On 1/16/22 07:32, Salih Dincer wrote:
> > On Sunday, 16 January 2022 at 11:43:40 UTC, Ali Çehreli wrote:
> >>
> >> void main() {
> >> enum count = 7;
> >>
> >> // Allocate some memory
> >> void* rawData =
On 1/16/22 7:54 PM, forkit wrote:
On Sunday, 16 January 2022 at 23:34:41 UTC, Ali Çehreli wrote:
Definitely a -profile=gc bug. Here are the existing ones:
https://issues.dlang.org/buglist.cgi?quicksearch=profile%20gc
Ali
yeah, a bug makes more sense ... otherwise I really would have had a
```d
import std; // If we summarize in code...
void main()
{
// It's a dynamic array and its copy below:
size_t[] arr = [1, 2, 3, 4, 5, 6];
auto arrCopy = arr.dup;
// This is its lazy range:
auto range = arr.chunks(2);
typeid(range).writeln(": ", range);
// But this is its copy (yo
On Sunday, 16 January 2022 at 23:34:41 UTC, Ali Çehreli wrote:
Definitely a -profile=gc bug. Here are the existing ones:
https://issues.dlang.org/buglist.cgi?quicksearch=profile%20gc
Ali
yeah, a bug makes more sense ... otherwise I really would have
had a slice to data that doesn't exist
On 1/16/22 15:14, forkit wrote:
> But -profile=gc .. says no. It's not.
>
> int[][] mArr = [[1, 2], [3, 4], [5, 6], [7, 8]]; // GC allocation occurs.
> int[][] mArr = iota(1, 9).chunks(2).map!array.array; // No GC allocation
> occurs.
Definitely a -profile=gc bug. Here are the existing ones:
On Sunday, 16 January 2022 at 23:03:49 UTC, Ali Çehreli wrote:
That's not correct. There are many range algorithms that are
lazy to defer memory allocation but array() is not one of
those. array() does eagerly allocate memory, which is it's
whole purpose:
https://dlang.org/phobos/std_arra
On 1/16/22 14:43, forkit wrote:
> Well, it's fair to say, that 'range-based programming' is kinda new
to me.
I hope it will be useful to you. :)
> int[][] mArr2 = [[1, 2], [3, 4], [5, 6], [7, 8]]; // GC allocation
>
> But it turns out:
>
> int[][] mArr = iota(1, 9).chunks(2).map!array.array;
On Sunday, 16 January 2022 at 11:43:40 UTC, Ali Çehreli wrote:
So, in all three examples it is the same D feature, a slice,
that references data but the data is managed in different ways.
Ali
Well, it's fair to say, that 'range-based programming' is kinda
new to me.
With this statement:
On 1/16/22 07:32, Salih Dincer wrote:
> On Sunday, 16 January 2022 at 11:43:40 UTC, Ali Çehreli wrote:
>>
>> void main() {
>> enum count = 7;
>>
>> // Allocate some memory
>> void* rawData = malloc(int.sizeof * count);
In practice, malloc'ed memory is cleared e.g. by memset(). Or, there is
On Sunday, 16 January 2022 at 11:43:40 UTC, Ali Çehreli wrote:
void main() {
enum count = 7;
// Allocate some memory
void* rawData = malloc(int.sizeof * count);
If count is not equal to 8 I get weird results! The reason of
course, is the free():
// [93947717336544, 1, 2, 3, 4, 5, 6]
On 1/16/22 01:43, forkit wrote:
> On Sunday, 16 January 2022 at 04:58:21 UTC, Ali Çehreli wrote:
>>
>> I have a problem with calling type[] a dynamic array because it is a
>> slice, which may be providing access to the elements of a dynamic array.
>>
>
> Yes. A more useful way of describing [] wou
On Sunday, 16 January 2022 at 04:58:21 UTC, Ali Çehreli wrote:
I have a problem with calling type[] a dynamic array because it
is a slice, which may be providing access to the elements of a
dynamic array.
Yes. A more useful way of describing [] would be to say:
"[] represents a dynamic ar
On 1/15/22 20:09, forkit wrote:
> so at this link: https://dlang.org/spec/arrays.html
>
> it indicates an array of type[] is of type 'Dynamic array'.
I have a problem with calling type[] a dynamic array because it is a
slice, which may be providing access to the elements of a dynamic array.
On
so at this link: https://dlang.org/spec/arrays.html
it indicates an array of type[] is of type 'Dynamic array'.
with that in mind, I ask, is this below a 'Dynamic array'.
If not, why not?
int[][] mArr2 = array(iota(1, 9).chunks(2).map!array.array);
19 matches
Mail list logo
