On 12/31/20 8:54 PM, Adam D. Ruppe wrote:
On Friday, 1 January 2021 at 01:43:50 UTC, Chris Bare wrote:
a1[10] = "testing a1";
this actually constructs a new thing since it is a straight x = y
assignment.
a2[10].name = "testing a2";
But this looks up something first. It do
On Friday, 1 January 2021 at 01:43:50 UTC, Chris Bare wrote:
a1[10] = "testing a1";
this actually constructs a new thing since it is a straight x = y
assignment.
a2[10].name = "testing a2";
But this looks up something first. It doesn't construct a2[10],
it
I'm missing something about the way associative arrays are
allocated.
In the example below, case 1 and case 2 seem to be the same, a
type indexed by a long.
Case 2 fails with a Range violation.
Can someone explain the difference?
I found a work around (or the correct way) in case 3.
struct Pro
On Thursday, 31 July 2014 at 21:50:25 UTC, Eric wrote:
objdump -d -M intel simpleOctal
Not sure what the switches are for;
-d
disassemble - Essential if you want to, well, disassemble.
-M intel
Intel syntax - Because no one likes AT&T syntax. Wikipedia has a
comparison:
http://en.wikipedia.o
On Thursday, 31 July 2014 at 20:59:46 UTC, Vlad Levenfeld wrote:
On Thursday, 31 July 2014 at 20:43:11 UTC, bearophile wrote:
Take a look at the asm!
Bye,
bearophile
I use DMD and Dub, how do I view the asm?
Actually I did't think to look at the asm, mainly because
I've never bothered to d
On Thursday, 31 July 2014 at 20:43:11 UTC, bearophile wrote:
Take a look at the asm!
Bye,
bearophile
I use DMD and Dub, how do I view the asm?
Eric:
Thanks. That really works. I timed doing
auto mySlice = ptr1[0 .. ptr2 - ptr1]; 1,000,000 times
versus
auto mySlice = ptr1[0 .. ptr2 - ptr1].dup; 1,000,000 times
and I am quite convinced the data is not being copied.
Take a look at the asm!
Bye,
bearophile
On Thursday, 31 July 2014 at 19:43:00 UTC, bearophile wrote:
Eric:
Suppose I have some memory allocated on the heap, and I have
two pointers pointing to the beginning and end of a contiguous
segment
of that memory. Is there a way I can convert those two
pointers
to an array slice without act
Eric:
Suppose I have some memory allocated on the heap, and I have
two pointers pointing to the beginning and end of a contiguous
segment
of that memory. Is there a way I can convert those two pointers
to an array slice without actually copying anything within the
segment?
Use something li
Suppose I have some memory allocated on the heap, and I have
two pointers pointing to the beginning and end of a contiguous
segment
of that memory. Is there a way I can convert those two pointers
to an array slice without actually copying anything within the
segment?
Thx,
Eric
On Tue, 10 Jun 2014 23:28:16 -0400, Kapps wrote:
On Wednesday, 11 June 2014 at 02:30:01 UTC, WhatMeWorry wrote:
In Mr. Cehreli's book it says
Additionally, the length of dynamic arrays can be changed by assigning
a value to this property:
int[] array; // initially empty
array.length = 5;
On Wed, 11 Jun 2014 02:30:00 +
WhatMeWorry via Digitalmars-d-learn
wrote:
> In Mr. Cehreli's book it says
>
> Additionally, the length of dynamic arrays can be changed by
> assigning a value to this property:
>
> int[] array; // initially empty
> array.length = 5; // now has 5 elements
>
> wh
On Wednesday, 11 June 2014 at 05:46:07 UTC, Ali Çehreli wrote:
On 06/10/2014 08:06 PM, Matt wrote:
> On Wednesday, 11 June 2014 at 02:30:01 UTC, WhatMeWorry wrote:
>> int[] array; // initially empty
>> array.length = 5; // now has 5 elements
>>
>> while in Mr. Alexandrescu's book, it says
>>
>>
On 06/10/2014 08:06 PM, Matt wrote:
> On Wednesday, 11 June 2014 at 02:30:01 UTC, WhatMeWorry wrote:
>> int[] array; // initially empty
>> array.length = 5; // now has 5 elements
>>
>> while in Mr. Alexandrescu's book, it says
>>
>> To create a dynamic array, use a new expression (§ 2.3.6.1 on p
On Wednesday, 11 June 2014 at 02:30:01 UTC, WhatMeWorry wrote:
In Mr. Cehreli's book it says
Additionally, the length of dynamic arrays can be changed by
assigning a value to this property:
int[] array; // initially empty
array.length = 5; // now has 5 elements
while in Mr. Alexandrescu's bo
On Wednesday, 11 June 2014 at 02:30:01 UTC, WhatMeWorry wrote:
In Mr. Cehreli's book it says
Additionally, the length of dynamic arrays can be changed by
assigning a value to this property:
int[] array; // initially empty
array.length = 5; // now has 5 elements
while in Mr. Alexandrescu's bo
In Mr. Cehreli's book it says
Additionally, the length of dynamic arrays can be changed by
assigning a value to this property:
int[] array; // initially empty
array.length = 5; // now has 5 elements
while in Mr. Alexandrescu's book, it says
To create a dynamic array, use a new expression (§
On 09.12.2013 23:03, seany wrote:
yet another array question :
I have defined :
alias string[] surrealNum_segments;
alias string[string] surrealNum_segments_withID;
surrealNum_segments_withID BAR;
Is there a built in function FOO, such that i could also write:
FOO(surrealNum_segments) BAR
yet another array question :
I have defined :
alias string[] surrealNum_segments;
alias string[string] surrealNum_segments_withID;
surrealNum_segments_withID BAR;
Is there a built in function FOO, such that i could also write:
FOO(surrealNum_segments) BAR;
instead of
On Sunday, 8 December 2013 at 13:47:43 UTC, Ali Çehreli wrote:
On 12/08/2013 03:51 AM, seany wrote:
> consider the follwoing:
>
> import tango.io.Stdout, tango.io.Path, tango.text.Util;
> import std.algorithm, std.string , std.stdio, std.array,
std.conv,
> std.regex, std.typecons;
>
> //i know a
On 12/08/2013 03:51 AM, seany wrote:
> consider the follwoing:
>
> import tango.io.Stdout, tango.io.Path, tango.text.Util;
> import std.algorithm, std.string , std.stdio, std.array, std.conv,
> std.regex, std.typecons;
>
> //i know al imports are not necessary for this example, just ^c^v from
> m
consider the follwoing:
import tango.io.Stdout, tango.io.Path, tango.text.Util;
import std.algorithm, std.string , std.stdio, std.array,
std.conv, std.regex, std.typecons;
//i know al imports are not necessary for this example, just ^c^v
from my actual code
alias string[] surSegments
void
On Wed, 21 Sep 2011 00:09:08 -0400, Jesse Phillips
wrote:
On Tue, 20 Sep 2011 14:28:54 -0400, Steven Schveighoffer wrote:
You can deallocate the original array. The soon-to-be-deprecated method
Note: ^
:)
(but easiest) is:
On Tue, 20 Sep 2011 14:28:54 -0400, Steven Schveighoffer wrote:
> You can deallocate the original array. The soon-to-be-deprecated method
> (but easiest) is:
>
> delete t;
>
> To avoid having to change your other code, I'd do this:
>
> wchar[] t = ...;
> scope(exit) delete t; // add this line
On Tuesday, September 20, 2011 21:48:10 Christophe wrote:
> > To avoid having to change your other code, I'd do this:
> >
> > wchar[] t = ...;
> > scope(exit) delete t; // add this line to the end of the function (after
> > returning)
> >
> > There is another way, but it's not as easy:
> >
> > /
> To avoid having to change your other code, I'd do this:
>
> wchar[] t = ...;
> scope(exit) delete t; // add this line to the end of the function (after
> returning)
>
> There is another way, but it's not as easy:
>
> // put this at the top of file
> import core.memory;
>
> ...
>
> scope(ex
Does it 'leak'? What is your exact setup, why isn't the GC collecting
that memory?
I have a Label class with a text() property that calls the procedure
that I have written in my first post and returns the result.
I have posted here because I was looking the memory usage (more
precisely th
On 09/20/2011 08:06 PM, Dax wrote:
Hi!
I'm working on a library written in D.
After some tests I have discovered that my library leaks memory, those leaks
are caused by dynamics array that I use in my library.
Does it 'leak'? What is your exact setup, why isn't the GC collecting
that memory?
On Tuesday, September 20, 2011 11:06 Dax wrote:
> Hi!
> I'm working on a library written in D.
> After some tests I have discovered that my library leaks memory, those
> leaks are caused by dynamics array that I use in my library.
>
> My question is:
> Should dynamics array be deallocated automati
On Tue, 20 Sep 2011 14:06:34 -0400, Dax wrote:
Hi!
I'm working on a library written in D.
After some tests I have discovered that my library leaks memory, those
leaks are caused by dynamics array that I use in my library.
My question is:
Should dynamics array be deallocated automatically wh
Hi!
I'm working on a library written in D.
After some tests I have discovered that my library leaks memory, those leaks
are caused by dynamics array that I use in my library.
My question is:
Should dynamics array be deallocated automatically when a procedure returns?
There is another way to acom
Heywood Floyd:
> First of all, I definitely think that how arrays are declared now would have
> to stay just the way it is,
> no matter what. I don't think stuff like that is changeable this late in a
> language.
Recently I have suggested to remove the syntax:
new int[20];
And allow only:
new in
Mafi Wrote:
>
> I don't really like it. Of course the order of indices feels better but
> it breaks the rule of reading types from right to left. It also
> introduces more parenthesis and a new keyword into types (amongst const,
> immutable and delegate etc). Consider:
>shared array[3](con
On 16 July 2010 20:11, Mafi wrote:
> Am 16.07.2010 11:12, schrieb Heywood Floyd:
>
> Lars T. Kyllingstad Wrote:
>>
>> I do agree that, if possible, the language should match how most people
>>> think. But in this case, it is impossible, because of templates. How
>>> would the following exampl
Am 16.07.2010 11:12, schrieb Heywood Floyd:
Lars T. Kyllingstad Wrote:
I do agree that, if possible, the language should match how most people
think. But in this case, it is impossible, because of templates. How
would the following example work with T = int[3], if arrays worked the
way you wa
On 16 July 2010 11:12, Heywood Floyd wrote:
> Lars T. Kyllingstad Wrote:
> (...)
>
> When we introduce templates, this should still work:
>
> struct MyArray(T){
> array[3] T a;
> }
>
> // Let's try
> T == array[11] int
>
> array[3] T a;
> array[3] (array[11] int) a;
> array[3] array[11] a;
> ar
Lars T. Kyllingstad Wrote:
> I do agree that, if possible, the language should match how most people
> think. But in this case, it is impossible, because of templates. How
> would the following example work with T = int[3], if arrays worked the
> way you want?
>
> struct MyArray(T)
> {
On Thursday 15 July 2010 22:20:17 bearophile wrote:
> Jonathan M Davis:
> > Personally, I'd advise you to just use dynamic arrays unless you do
> > some profiling and find that a static array is better in a particular
> > case.
>
> To program you need a less naive view. I sometimes start using dyn
Jonathan M Davis:
> Personally, I'd advise you to just use dynamic arrays unless you do
> some profiling and find that a static array is better in a particular case.
To program you need a less naive view. I sometimes start using dynamic arrays
everywhere because they are handy, then I profile cod
Jonathan M Davis:
> [5](int) const a;
Go language uses something similar, and I find it a bit better than D syntax.
Bye,
bearophile
On Wed, 14 Jul 2010 16:57:13 -0400, Heywood Floyd wrote:
> Lars T. Kyllingstad Wrote:
>
>
>> But then arrays would be different from all other types! If you have
>> an array of 3 Ts, that is written T[3], regardless of what T is. Now
>> consider these two cases:
>>
>>A. T is an int. Then
On Wednesday, July 14, 2010 13:57:13 Heywood Floyd wrote:
>
> Thank you for the elaborate answer!
>
> When you put it like that, it does make sense. But I'm sorry. I refuse. The
> reason I refuse is those examples are void of any higher semantic meaning.
> Once we add a semantic meaning, it simpl
Lars T. Kyllingstad Wrote:
>
> But then arrays would be different from all other types! If you have an
> array of 3 Ts, that is written T[3], regardless of what T is. Now
> consider these two cases:
>
>A. T is an int. Then T[3] becomes int[3].
>
>B. T is an int[string]. Then T[3]
On Mon, 12 Jul 2010 17:23:16 -0400, Heywood Floyd wrote:
> bearophile Wrote:
>
>> Heywood Floyd:
>> > This had me crazy. I ended up putting the brackets on the variable,
>> > like
>> > int marr[3][5];
>> > then it worked like
>> > marr[2][4] = 9;
>>
>> That's present only for compatibility w
Heywood Floyd:
> Aha, good to know! Thanks!
> (So this might go away in the future? Or require a -cstyle compile flag?)
It's just an idea of mine, my weight in D design is near zero, and Walter
doesn't love warnings. I don't know if C-style array definitions will ever go
away from D, don't hold
bearophile Wrote:
> Heywood Floyd:
> > This had me crazy. I ended up putting the brackets on the variable, like
> > int marr[3][5];
> > then it worked like
> > marr[2][4] = 9;
>
> That's present only for compatibility with C syntax, this means that you can
> use it to perform a quicker port
Heywood Floyd:
> This had me crazy. I ended up putting the brackets on the variable, like
> int marr[3][5];
> then it worked like
> marr[2][4] = 9;
That's present only for compatibility with C syntax, this means that you can
use it to perform a quicker port of C code to D, but you are suppose
This had me crazy. I ended up putting the brackets on the variable, like
int marr[3][5];
then it worked like
marr[2][4] = 9;
Hello dcoder,
Hello.
I'm wondering why in D if you declare a fixed multi dimensional array,
you have to reverse the index order to access an element.
When declaring an array, the base type is getting wrapped. When using an
array, the base types get unwrapped.
Because both forms place the [
dcoder wrote:
I'm wondering why in D if you declare a fixed multi dimensional array,
you
have to reverse the index order to access an element. I know it has
something
to do with how tightly [] bind, but the consequence is that it seems so
different to other languages, it makes it error pro
Hello.
I'm wondering why in D if you declare a fixed multi dimensional array, you
have to reverse the index order to access an element. I know it has something
to do with how tightly [] bind, but the consequence is that it seems so
different to other languages, it makes it error prone. So here's
51 matches
Mail list logo
