Arc.Tango

[Bill Baxter]

Clay Smith wrote:
> Bruno Medeiros wrote:
>> Clay Smith wrote:
>>> Arc v.02 has been successfully ported over to Tango, and will be 
>>> using Tango as the only supported standard library for future releases.
>>>
>>> I put my rationale on a wiki, as well: 
>>> http://www.dsource.org/projects/arclib/wiki/WhyUseTango
>>>
>>> Arc v.02 Stable Tango Branch: 
>>> http://svn.dsource.org/projects/arclib/branches/arc02/tango/
>>>
>>> Arc is a cross platform arcade game library, providing easy access to 
>>> 2d graphics, sound, input, a graphical user interface, and more.
>>>
>>> ~ Clay
>>
>> What Tango facilities are you using (or planning to use)?
>>
> 
> I mostly use tango's bare minimum features, but...
> 
> Using
> * Signals
> * Logging
> 
> Planned
> * VFS
> * Maybe Reader, Writer
> * Maybe some collections
> * Maybe XML if tango decides to get that

You make a lot of good points on that page.

Have you (or anyone) tested the performance of the tango containers? 
I'm concerned about the performance impact of all iterators being 
heap-allocated, interface-accessed things, but I suspect there are ways 
to work around that (maybe using opApply's or scope'ing iterators).

 From a quick look it appears that opApply scope allocates and uses the 
actual iterator type, thus avoiding both the heap and virtual calls. 
But the iterator returned by .elements is a heap-allocated generic 
interface pointer.  On the other hand opApply will have to go through a 
few delegate calls to get at your loop body.  So anyway, it's not 
exactly clear to me what price I end up having to pay at the pump vs a 
more STL-like thinly-veiled-pointers approach.

--bb