Problem: Chuck language definition uses cap(), when it should use size().

 

An example from the Chuck language specficiation:

http://chuck.cs.princeton.edu/doc/language/array.html

   // print it
        for( 0 => int i; i < bar.cap(); i++ )
            <<< bar[0] >>>;
    }

From chuck_lang.cpp
// array.cap()
CK_DLL_MFUN( array_capacity )
{
    Chuck_Array * array = (Chuck_Array *)SELF;
    RETURN->v_int = array->capacity();
}

From STL docs:

std::vector<xx>::capacity()
     The member function returns the storage currently allocated to hold the
controlled sequence, a value at least as large as size

One of these is wrong (probably not the STL docs. ;--) ). Either bar.size(),
or array->size() would do it.

std::vector<>::capacity() is not the same thing as std::vector<>::size().
It's common practice (if not a standards requirement) for STL
implementations to grow arrays by doubling capacity() as the size()
increases, instead of growing capactity() by one each time, becuase this
provides O(1) performance for push_back instead of O(2) performance.

Which brings me to my next feature request.... <grin>

I don't suppose the Array push_back/pop-back/&c methods could be
re-instituted? It's nice to have dynamic arrays; but, in the current
implementation, there's no way to grow the integer-indexed portion of
arrays.

A use case:

I'm writing VoiceManager, a voice-manager class, that implements polyphonic
playing on classes that implement IInstrument. One of the parameters to
VoiceManager is how many instances of the instrument to create. The problem:
how to declar an array to hold the instruments?

    IInstrument instruments[];
Doesn't create an array.
    [] @=> IInstrument instruments[];
is gramattically illegal.
    IInstrument instruments[0];
isn't growable.
   
The ideal solution:
    IInstrument instruments[];
....
    instruments.push_back(instr);

Tantalizing, because array_push_back is present in the sources, but doesn't
seem to be implemented in the language.

Priority of the feature request: nice to have, but not absolutely required.
static members would be my first choice. I used IInstrument
instruments[256]; to work around the problem.

Best Regards,

Robin Davies.