Gdzie vector trzyma elementy?

Cześć :)
Z racji tego, że vector jest dynaczmicznie rozszerzający się trzyma swoje elementy na stercie, prawda?
W takim razie nie ma problemu*, żeby w klasie mieć takie pola:

vector<ELEMENTY O OGROMNEJ WADZE> vec;
vector<ELEMENTY O OGROMNEJ WADZE> vec2;
vector<ELEMENTY O OGROMNEJ WADZE> vec3;
...

Pytam się w kontekście tego, czy nie muszę opakowywać tego w jakieś shared_ptr etc. ( wtedy vec musiałby być wskaźnikiem na vector).

*Problem rozumiemy tu tak, żeby się nie okazało, że obiekt leżący na stosie zajmuje pół stosu.

Nie, nie trzeba. I nie należy.

Nawet kiedy sam vector jest na stosie to elementy nie są.

Ok.
Ale ogólnie jeżeli klasa jest właścicielem jakiegoś wskaźnika ( w sensie obiektu wskazywanego leżącego na stercie) to już powinno się raczej tak robić?
Np. Założmy, że mamy duży obiekt Macierz.

Zatem:

class DodawaczMacierzy{
std::unique_ptr<Macierz> matrixLeft; 

}

Tak?

Jeżeli Twoja własna klasa ma trzymać jakiś wskaźnik, to warto żeby to był inteligentny wskaźnik, ale tylko dlatego że jest wygodniejszy i sam się sprząta po sobie. Natomiast nie robi to zasadniczej różnicy w kwestii stosu/sterty.

Ok.
A teraz takie pytanie:

Mam klasę Settings, która jest pobierana jako wskaźnik (shared_ptr) przez inne klasy dlatego, że ta klasa ma ustawienia, z których korzystają sobie poszczeógólne klasy.
Klasa Settings ma np. pole vector<Matrix> matrixy.

I teraz załóżmy, że klasa K ma wskaźnik shared_ptr do settings. Teraz klasa chce jako "swoje pole" zapamiętać matrixy.

Ja to robię tak:

class K{
public:
K() : matrixy(settings->getMatrix()){}
private: 

const std::vector<Matrix>& matrixy;
}

Czy to jest ok?

Niby Klasa K jest współwłaścicielem settings więc obiekt ten ( a zatem i matrixy) nie powinien nigdy zginąć dopóki nie zginie klasa K. Tylko wydaje mi się to trochę w stylu WTF.

Ale ja nie mam doświaczenia w kodzie komercyjnym. Dlatego: Co byś powiedział jakbyś zobaczył coś takiego na codeReview.

( poza krytyką uzasadnij proszę dlaczego to jest źle oraz jak to rozwiązać)

A po co? Masz dostęp do Settings to masz dostęp do tego wektora.

To jest prawda.
Tylko, że bardzo często się odwołuję do tej macierzy w różnych metodach, a nie chcę ciągle używać settings.get(). bo publicznej macierzy nie zrobię, a z friend cyrków nie bedę robić.

Tak jak opisujesz: - "... nie powinien nigdy zginąć dopóki nie zginie klasa K ..." - tak działa shared_ptr, a nie referencje.
Czyli K może zostać z referencją na coś już nieistniejącego.

Rozmiar obiektu typu vector<T> sobie możesz sprawdzić za pomocą sizeof.

#include <vector>
#include <iostream>

int main()
{
  std::cout << sizeof(std::vector<int>) << std::endl;
}

GCC 4.8.1 | 12
VS2008 | 24
VS2015 | 12
Open Watcom 1.8 | 16

Wyniki dla 32 bitów.