[Gladias]

Jest sposób by zapisać do bez używania dodatkowej zmiennej t ?

int t;

vector vec;

for (int i = 1; i <= n; i++)
{
cin >> t;
vec.pushback(t);
}

cos w stylu cin>>vec.pushback();

#naukaprogramowania #cpp

[MozeSuker]

@Gladias: tak Cię boli ta zmienna?

[ly000]

@Gladias: @MozeSuker: jakoś tak:

copy(istream_iterator(cin), istream_iterator(), back_inserter(vec));

[s.....r]

@MozeSuker: Moze optymalizuje? :D

[Gladias]

@MozeSuker: Nie, bardziej z ciekawości pytam.

[A.....a]

@ly000: dodaj, że dobrze jest zrobić .reserve(n) wcześniej jeśli znamy rozmiar danych i jest git :)

[nargil]

@Gladias: np tak

vector vec(n,0);

for (int i = 1; i <= n; i++)
{
cin >> vec[i-1];
}

ale to najpierw wypelni wektor zerami.

[dupasmoka]

@nargil: moze lepiej for(int i=-100; i <= n-101; i=+1){cin >> vec[i+100];} ?

[nargil]

@dupasmoka: czepiasz się. Zostawiłem indeksację pętli taką jak miał autor.

[KrzaQ2]

@ly000: @AferaZaAfera: znając n ⟶ copy_n.

[A.....a]

@KrzaQ2: dla czytelności jasne :) ale i tak copy_n nie robi reserve/resize, a znając n i dalej robiąc push_back (o front nawet nie będę wspominał!) to głupota.

Przy kopiowaniu 20 liczb różnicy nie będzie, ale jak dostaniesz na wejście 10k to i owszem.

[KrzaQ2]

@AferaZaAfera: Ale ja nie pisałem nigdzie, ƶe reserve zbędne ;)

[A.....a]

@KrzaQ2: wiem ;) ale i tak uważam, że sporo ludzi ma na to #!$%@?, bo przecież końcowy wynik będzie taki sam, dlatego cisnę ile się da, bo później ktoś napisze mi taki gówniany moduł, co na danych testowych śmiga fajnie, będę tego używał co chwilę do kilku milionów danych i się #!$%@?ł co tak wolno to działa...

Niestety ale kursy i inne materiały zazwyczaj uczą o tym jak dodać element do

[KrzaQ2]

@AferaZaAfera: Jak juƶ o tym myślę, to w sumie resize i podanie begin() do algorytmu moƶe działać lepiej jeśli kompilator nie wyeliminuje porównań size<=capacity z back_insertera

[A.....a]

@KrzaQ2: szczerze to wątpię, szczególnie dla dużych danych. Przy resize alokowana pamięć jest inicjalizowana domyślnym konstruktorem (dla typów prostych może być jakaś optymalizacja np. z memset'em) także na tym sporo czasu też straci. I tak będzie lepiej niż bez resize, ale wydaje mi się, że czytelniej (i lepiej) jest jednak używać reserve. Poza tym resize też musi porównywać, czy nowa wielkość jest (1) mniejsza od aktualnej (wtedy usuwa), (2)

[KrzaQ2]

@AferaZaAfera: Ale porównanie leci 1x, a nie n razy. No ale fakt, zapomniałem o domyślnej wartości w wektorze.

W sumie to sobie później zbenchmarkuję, ciekawe.

[A.....a]

Ale porównanie leci 1x, a nie n razy

@KrzaQ2: sugerujesz, że reserve robi porównanie n razy, gdzie n to nowy rozmiar? ( ͡° ͜ʖ ͡°)
Jak zrobisz to wrzuć test na ideone albo gdzieś, chętnie obejrzę też :) stawiam moje cebule na reserve.

[KrzaQ2]

@AferaZaAfera: no robisz albo resize() i podajesz begin() albo reserve() i podajesz back_inserter(). back_inserter będzie robił porównania, dereferencja iteratora nie. Cebul nie stawiam, bo coś mi się wydaje, ƶe
1) nie wiem
2) mocno zaleƶne od typu (memset i te sprawy)
3) po to sprawdzę, aby się dowiedzieć

[A.....a]

@KrzaQ2: Racja, nie wiem jak przeczytałem o begin() żeby za 3s zapomnieć ( ͡° ʖ̯ ͡°)

[A.....a]

@KrzaQ2:
**Miałeś rację z back_inserterem, jego porównania dają trochę w kość.** Na szczęście da się je całkowicie pominąć i przetestować resize vs reserve. Kod wraz z wynikami tutaj.

Wyniki z mojej maszyny VS2015 (bo wcześniejsze mają kiepski high_resolution_clock):

Resize [ms]: 1732.7

Reserve [ms]: 1477.66

Reserve (backinserter) [ms]: 5376.24

Więc najlepsze wyjście to reserve i kopia bezpośrednio do niego, gorsze to resize i kopia bezpośrednio do niego, a