Resizable Arrays?

Bill Baxter wbaxter at gmail.com
Sun Mar 1 09:25:03 PST 2009


On Sun, Mar 1, 2009 at 11:17 PM, dsimcha <dsimcha at yahoo.com> wrote:
> == Quote from Jason House (jason.james.house at 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
> 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.
>
> 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.
>

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



More information about the Digitalmars-d mailing list