• Jason House <jason.james.house gmail.com> Feb 28 2009
• dsimcha <dsimcha yahoo.com> Mar 01 2009
• Bill Baxter <wbaxter gmail.com> Mar 01 2009

Jason House <jason.james.house gmail.com> writes:

Sean Kelly Wrote:

 Jason House wrote:
 Are there any good reasons to allow built in arrays to be resizable?
 
 There's already plenty of empirical evidence that building arrays by appending
is incredibly slow.
 
 There are also bugs in bugzilla where resizing arrays after assigning one
array to another violates type safety. Those bugs can be solved by always
reallocatimg arrays when resizing, but that makes performance even worse...
 
 While not much of an argument, C# also prevents array resizing.
 
 Is it time to rely on standard libraries for data structures and let built in
arrays be fixed length? It's a breaking change... 


 C has dynamic arrays now.  If D got rid of them I might just cry.


By dynamic, do you mean no length as part of the type or resizable in place?
Array resizing can lead to hidden allocations, which is against Tango design
(my closest proxy for your style preferences). My past use of arrays in C did
not include calls to reallocate them in place. 

dsimcha <dsimcha yahoo.com> writes:

== Quote from Jason House (jason.james.house gmail.com)'s article
 Sean Kelly Wrote:
 Jason House wrote:
 Are there any good reasons to allow built in arrays to be resizable?

 There's already plenty of empirical evidence that building arrays by






 There are also bugs in bugzilla where resizing arrays after assigning one






reallocatimg arrays when resizing, but that makes performance even worse...
 While not much of an argument, C# also prevents array resizing.

 Is it time to rely on standard libraries for data structures and let built






 C has dynamic arrays now.  If D got rid of them I might just cry.




closest proxy for your style preferences). My past use of arrays in C did not
include calls to reallocate them in place.

IMHO, you can't have a high level language while at the same time completely
avoiding hidden allocations.  The whole point of D is that it's supposed to be a
higher level language than the others in its niche, namely C and C++.  The
cliche
is that we should forget about small efficiencies 97% of the time.  If you're
writing something that falls in that 97%, in a high level language, stuff should
just work and you shouldn't care about a few allocations.  If you're writing
stuff
in the other 3%, the onus should be on you to avoid features with hidden
allocations.  Writing performance critical or real-time code is hard, and
cutting
back on (slightly) hidden allocations isn't going to help much.

Bill Baxter <wbaxter gmail.com> writes:

On Sun, Mar 1, 2009 at 11:17 PM, dsimcha <dsimcha yahoo.com> wrote:
 =3D=3D Quote from Jason House (jason.james.house gmail.com)'s article
 Sean Kelly Wrote:
 Jason House wrote:
 Are there any good reasons to allow built in arrays to be resizable?

 There's already plenty of empirical evidence that building arrays by






 There are also bugs in bugzilla where resizing arrays after assignin=








 array to another violates type safety. Those bugs can be solved by always
 reallocatimg arrays when resizing, but that makes performance even worse.=


 While not much of an argument, C# also prevents array resizing.

 Is it time to rely on standard libraries for data structures and let=








 in arrays be fixed length? It's a breaking change...
 C has dynamic arrays now. =A0If D got rid of them I might just cry.






 Array resizing can lead to hidden allocations, which is against Tango des=


 closest proxy for your style preferences). My past use of arrays in C did=


 include calls to reallocate them in place.

 IMHO, you can't have a high level language while at the same time complet=


 avoiding hidden allocations. =A0The whole point of D is that it's suppose=


 higher level language than the others in its niche, namely C and C++. =A0=


 is that we should forget about small efficiencies 97% of the time. =A0If =


 writing something that falls in that 97%, in a high level language, stuff=


 just work and you shouldn't care about a few allocations. =A0If you're wr=


 in the other 3%, the onus should be on you to avoid features with hidden
 allocations. =A0Writing performance critical or real-time code is hard, a=


 back on (slightly) hidden allocations isn't going to help much.


I pretty much agree, but it would be nice if there were some debugging
flag you could toggle to cause the gc to assert() if some allocation
is attempted.   Like   std.gc.prohibitAllocations()  or somesuch.
That way in the block of code where you think you are avoiding
allocation it would be easy to find a place where you slipped up.

--bb

--bb