template <class Allocator>
void get_some_data(vector<double, Allocator> &result);

void get_some_data(ArrayRef<double> &result);
void test()
{
   Array<double,20> res; // 20 элементов в статическом буффере, если не хватает делаем malloc
   get_some_data(res);
}

struct A
{
  int a,b,c,d;
  int *p;
};

K>template <class Allocator>
K>void get_some_data(vector<double, Allocator> &result);
K>

K>void get_some_data(ArrayRef<double> &result);
K>void test()
K>{
K>   Array<double,20> res; // 20 элементов в статическом буффере, если не хватает делаем malloc
K>   get_some_data(res);
K>}
K>

template<typename T>
class  Array : public vector<T, fast_allocator<T> >
{
// c-tors
};
void get_some_data(Array<double> &result); //< функция не шаблонная
void test()
{
   Array<double> res;    //< ну 20 дублов на стеке хранить нельзя, но с горя я не помру.
   get_some_data(res);
}

For example, if accessing a value through a trivial smart pointer is
significantly slower than accessing it through an ordinary pointer, the compiler is
inefficiently handling the abstraction. In the past, most compilers had significant
abstraction penalties and several current compilers still do. However, at least two
compilers have been reported to have abstraction penalties below 1% and another a
penalty of 3%, so eliminating this kind of overhead is well within the state of the art.

K>void get_some_data(ArrayRef<double> &result);
K>void test()
K>{
K>   Array<double,20> res; // 20 элементов в статическом буффере, если не хватает делаем malloc
K>   get_some_data(res);
K>}
K>

ЮЖ>no-throw swap не велика потеря ?

struct Test
{
    vector<int> m_vec;

    void capture(vector<int> &vec)
    {
        swap(m_vec, vec);
        vec.clear();
    }

    typedef Array<int,16> MyArray;
    MyArray m_arr;

    void capture(MyArray &arr)
    {
        swap(m_arr, arr);
        arr.clear();
    }

    void fetch(ArrayRef<int> &res)
    {
        res.push_back(12345);
    }

    void test()
    {
        Array<int,10> res;
        fetch(res);
    }
};

J>А стандарт почитать? Он возвращает размер элемента массива, если тебе вздумается сложить эти объекты во встроенный массив.

J>А new вообще возвращает указатель

char buffer[sizeof( T )];
delete new( buffer )T;

J>В комитете, вообще-то, как раз разработчики компиляторов и сидят

E>>Ещё не уже попал

E>>Ну вполне повод для претензий, что надобаляли всяких "меганужных" в стандарте next_permutation, vector<bool> и вектор значений, который я не помню как зовут, а вот хэшей и многомерных массивов положить не успели

template <class сhar_type, class unusefull_stuff, class additional_butthurt> class basic_string;
template <class elem_type, class unusefull_stuff> class vector;

E>>>Вообще в дизайне STL лично мне очень не нравится отсутсвие целенаправленности. Скажем вот добавили в контейнеры аллокаторы. При этом зачем это сделали не понятно. Ни возмоэность передать контейнеру конкретный пул памяти не предусмотрели, ни возможность гранулировать аллокации. Результат печальный -- аллокаторы есть, а толку нет. И так во многих очень местах

...allocators, which are objects that encapsulate the information about an allocation model. This information includes the knowledge of pointer types, the type of their difference, the type of the size of objects in this allocation model, as well as the memory allocation and deallocation primitives for it.

E>В любом случае не понятно почему и за что все экземпляторы аллокатора объявили эквивалентными...

"Implementors are encouraged to supply libraries that can accept allocators that encapsulate more general
memory models and that support nonequal instances. In such implementations, any requirements imposed
on allocators by containers beyond those requirements that appear in Table 32, and the semantics of containers
and algorithms when allocator instances compare nonequal, are implementation-defined."