But scoped_array is meant to be a C++ array. 

Its only goal is (and probably should be) to call delete[].

> -----Original Message-----
> From: boost-bounces@lists.boost.org 
> [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Burns
> Sent: Thursday, July 20, 2006 9:22 AM
> To: boost@lists.boost.org
> Subject: Re: [boost] boost::array support for runtime-sized arrays
> 
> Actually the size of the container I have would be (sizeof(void*) + 
> sizeof(size_t)) because you have to store the array's length, 
> so I have to 
> agree is starting to look like we are better of using std::vector.
> 
> The problem I see with scoped_array is that it doesnt even 
> have a size() or 
> equivalent method which is kind of mandatory for very array class.
> 
> Steven.
> 
> 
> 
> "John Maddock" <john@johnmaddock.co.uk> wrote in message 
> news:005e01c6ac13$0cd8f8e0$ea8c0252@fuji...
> > Steven Burns wrote:
> >> Indeed I did a partial spec. when the size is 0  (size_t 
> cannot be -1)
> >> Losing the aggregate behavior was not an option so I only have
> >> constructors on this specialization.
> >>
> >> This means you can still do this:
> >>
> >>      boost::array<int, 5> sarray = {1,2,3,4,5};   // works!
> >>
> >> but not this:
> >>
> >>      boost::array<int> sarray(5) = {1,2,3,4,5};   // no way jose :(
> >>
> >> There's simply no way to create runtime-sized aggregates 
> (that I know
> >> of)
> >> I am looking for a test suite for boost::array (if exists) to make
> >> sure I didnt break anything, and I also wanted to hear 
> some opinions
> >> on the subject.
> >
> > Unfortunately that would break Boost.Array in Boost-1.34 
> onwards which
> > already has a TR1-compatible partial specialisation for 
> zero-sized arrays.
> >
> > I've been trying to think of what array-like objects I use 
> already and how
> > this would fit in:
> >
> > C style arrays:
> > Hardly ever, except for small immutable arrays.  For 
> example tables of
> > coefficients for rational approximations.
> >
> > Boost.Array:
> > Mostly for fixed size tables of immutable data, test data 
> for example.
> >
> > Scoped_array:
> > Useful for temporary buffers whose size is determined at 
> runtime.  Doesn't
> > have a container interface though, and probably mostly used for 
> > interfacing
> > with legacy C API's.
> >
> > Shared_array:
> > Never used it.  Might do if I wanted to write a copy-on-write 
> > string/vector,
> > but that's about all.
> >
> > std::vector/std::string:
> > Used for everything else, which encompasses quite a lot :-)
> >
> > So.... you have quite a lot of competition here, and I've 
> yet to see a
> > compelling reason to have yet-another-vector  :-)
> >
> > Thinking out loud, the issues, seems to boil down to:
> >
> > Code size: I would be very surprised to see any difference, although
> > vector/string have "fatter" interfaces, you only pay for the member
> > functions you actually use.  Indeed if vector<whatever> is 
> instantiated
> > already somewhere else in the program, or if you can use 
> std::string and
> > that's already in use elsewhere, then you may *save* on 
> code size by 
> > reusing
> > these.
> >
> > Object size: I guess your runtime-sized array would be 
> sizeof(void*) in
> > size, compared to typically three times that for a vector.  
> There may be
> > times when that's important - embedded systems for example 
> - but then 
> > unless
> > you really need a container-like interface scoped_array is 
> probably a 
> > better
> > bet.
> >
> > Actually I think I may have just provided a compelling 
> reason for a real
> > lightweight container after all then!  It would have to be called 
> > something
> > other than array though :-)
> >
> > Just thinking out loud,
> >
> > John.
> >
> > _______________________________________________
> > Unsubscribe & other changes: 
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> > 
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>