vector czy po staremu???

Co będzie szybsze normalna deklaracja tablicy (z zerowaniem elementów)
int *tab = new int [l_jed];
for(i=0;i<l_jed;i++)
tab[i]=0;
czy instrukcja:
vector<int> wektor(l_jed,0);
Co lepiej używać pod względem kryterium jakim jest szybkość.
oraz jak to zmierzyć??? Bo ten kod poniżej nie działa

int i,l_jed=10000;
clock_t start, finish;
start = clock();
vector<int> wektor(l_jed,0);
finish = clock();
double duration = (double)(finish - start);
printf( "\nCzas wykonywania programu z wektorem %2.20f sekund\n\n\n", duration ) ;
start = clock();
int *tab = new int [l_jed];
for(i=0;i<l_jed;i++)
   tab[i]=0;
finish = clock();
duration = (double)(finish - start);
printf( "\nCzas wykonywania programu bez wektora %2.20f sekund\n", duration ) ;

delete []tab;

Oraz niech ktoś napisze jak użyć tego poniżej by zmierzyć czas, bo nima nigdzie w necie tak żeby było po ludzku napisane jak tego użyć by zmierzyć czas.

LARGE_INTEGER start, stop;
QueryPerformanceCounter(&start); 
vector<int> wektor(l_jed,0);
QueryPerformanceCounter(&stop);

Szybsze (i zużywające mniej pamięci) jest ręczne zarządzanie pamięcią, ale jest trudniejsze ;)

może użyjesz:

#include <windows.h>
//...
int t1,t2;
t1 = GetTickCount ();
//intrukcje
t2 = GetTickCount ();

cout<<t2-t1<<endl;

Czyli na 100% to

int *tab = new int [l_jed];
for(i=0;i<l_jed;i++)
   tab[i]=0;

jest szybsze od tego
vector<int> wektor(l_jed,0);
mimo że mniej linijek zajmuje?

Sprawdź, bo nie koniecznie ;)
Albo później używane i zarządzanie taką pamięcią może się okazać szybsze. Bo vector czasami np alokuje wiecej pamięci niż potrzeba (na zapas) itd

niestety za pomocą GetTickCounta nie da się sprawdzić

Jest raczej pewne, że różnica będzie minimalna.
Ale lepiej jak sobie zadasz pytanie, jak często i kiedy będzie wywoływany ten kod?
Po odpowiedzi na to pytanie może się okazać, że optymalizowanie kodu w tym miejscy będzie jedynie sztuką dla sztuki.

Różnica jest w kilku taktach procesora. Przy wektorze dochodzi inline'owany konstruktor w którym jest zaledwie kilka instrukcji. Nawet w dość krytycznym miejscu różnica jest nieistotna. Różnica mogłaby być istotna jeśli tablica byłaby alokowana na stosie tj:
int tab[N];
lub
int tab = (int)malloca(N * sizeof(int));

Aż mam ochotę powiedzieć: no pewnie, ludzie implementujący STL pod nasz kompilator nie potrafią sensownie napisać dynamicznej tablicy, my umiemy lepiej...

Nie chodzi o "lepiej", tylko o to ze STL'owe zabawki są często jak taki człowiek-orkiestra ;)
Mają masę fajnych bajerów, tylko że czasami one nam wcale nie są potrzebne ;)
Oczywiscie jesli zależy nam na tym żeby szybko napisał ładny kod, to jak najbardziej można z STL korzystać. Ale jak bawimy się w optymalizacje i przyspieszanie programu o te kilka milisekund to może sie okazać że implementacja własnego zarządzania pamięcią, takiego typowo pod nasze potrzeby, czy też np. operacje na bitach, zamiast arytmetycznych, mogą dać nam jakieś przyspieszenie ;)

Kurcze, to co mam robić, zmieniać na vector, bo już nie wiem??? Dzięki vectorowi program by wyglądał przejrzyściej, ale czy byłby dużo wolniejszy? Np. w programie mam stałą tablicę:
np. tab2[20] i wykonuje się pewien algorytm, który w kolejnych krokach usuwa jakiś element tablicy. Usunięcie elementu sygnalizuję przez podstawienie tab2[i]='-'. Dzięki temu jak przeglądam tablicę to daję warunek if(tab2[k]!='-') rób cośtam, aby pomijać "niby" usunięte elementy. Jakbym zastosował vector to usunąłbym po prostu tab2.erase(tab2.begin()+i)) i nie musiałbym podstawiać '-' ani sprawdzać czy jakiś element !='-'. I co w tym przypadku jest szybsze? Kombinowanie z podstawianiem '-' i sprawdzaniem warunku czy vector???

Wpierw niech dziala dobrze (tj. daje dobre wyniki). Jak dziala dobrze, ale za wolno, to wtedy mozna pomyslec o optymalizacji, ale dopiero po profilowaniu. Popieram MarkaR22: skad niby teraz wiesz, taka optymalizacja nie bedzie czasem sztuka dla sztuki?

Zależy jak często tą tablicę potem przeglądasz. Bo usunięcie z vectora spowoduje że on ci "poprzesuwa" pozostałe elementy w tej tablicy po prostu, sprawdź sobie na kartce co wymaga większej ilosci operacji :P

Czy ty nie stwarzasz sztucznych problemów ?
Wycinek kodu ma się nijak do całości programu .
Program sprawdza się pod względem 'wydajności' kodu jeśli zaczynają
się problemy z funkcjonowaniem w postaci długiego oczekiwania na efekty
jego działania .
Jeśli nie możesz zmierzyć różnic czasu wykonania kodu to znaczy że sposób
rozwiązania jest mało istotny i można wybrać wygodniejsze rozwiązanie ...
// y.. już odpowiedzieli .... , no nic ja 'myślę' tak samo jak czarny Kot i R22

// Jeśli chcesz znać różnicę to napisz bardziej rozbudowany kod z większą ilością
//operacji aby czas wykonania był bardziej mierzalny w wer. vector i tablica ...

aha no dobra, to zostawiam moją implementację na razie na tablicach dynamicznych, a kiedyś jak będzie czas to sobie przerobię to na wektory. A ktoś tu jeszcze u góry wspomniał, że fajnie jest alokować pamięć za pomocą malloca gdyż jest to szybsze od new? to prawda???

czy cos tam w stylu tab2[20] (chodzi o 20 elementow) to za bardzo nie oplaca sie optymalizacja, optymalizacja jest niezbedna jak bedzie 2G elementow albo jak operacje na tych 20 bedziesz wykonywal w petli dajacej niejako 2G elementow.

Jasne jest chyba ze oszczedzanie 2us nie ma znaczenia dla funkcji wywolanej w petli 100 razy czy jescze mniej (np po interakcji z userem). Jak jest czesciej (tu najczesciej obliczenia) to ma sens
bo 2us * 10^{9 = 10}-610^{9 = 2}10</sup>3 = 2000 to juz ponad pol godziny. Naturalnie zakladamy ze czas wykonania calej funkcji jest tez rosadny w stosunku do optymalizacji. Jak sama procedura wykonuje sie 1 minute to te 2us moga byc tego nie warte. No moze pozniej jak walnac na supermaszyne gdzie sie placi za kazda godzine.

Oczywiscie co innego nauka optymalizacji, mozna to wtedy traktowac jak zabawe.
Wtedy sprawdz co wyplul kompilator w asmie i zobacz co sie bardziej oplaca.

O mamo .. weź kompilator i sprawdz ...
Jest tyle zależności że teoretycznie ,,,, i znowu teoretycznie , zależy od kompilatora
do końca nie masz wpływu na kod wynikowy C(C++).
new używa malloc ..
Jak Teoretycznie chcesz mieć pewność na 100% to przekładasz program na Asembler i analizujesz
................ przez bardzo długi .................................................................................................
...................................................s.. tracony . czas ........
Og .. bez jaj w C++ new w C malloc ,,

dzejo napisał(a)

new używa malloc ..
Kto tak mówi?

Ja .. a co ?
//nic .. przesadziłem ,, przydzielanie pamięci jest wbudowane w C++ new delete.
//Ale np. w implementacji biblioteki <new> jest użyty malloc
// new w C++ jest operatorem , malloc to fun , jak działa operator new , pewnie
//podobnie jak fun malloc .
//A właściwie to wszystko g.. prawda bo przy takich rozważaniach język
// jest tylko ' nakładką ' na system operacyjny ...... kod który powstanie i tak będzie
// używał fun API i gdzieś tam fun. przydzielania pamięci na które nie mamy
// wpływu ... więc duskusja czy malloc czy new nie ma sensu.

Podaj punkt standardu, który tak mówi. Chyba, że ty jesteś standardem, wtedy to, że ty coś mówisz faktycznie ma znaczenie.

Nie mam takiego zamiaru , wywołania malloc i new zostaną przełożone na
wywołania funkcji przydzielającej pamięc odpowiedniej dla danego systemu
a jak to zrobi to juz nie moja sprawa ....
// jedyne proste podejście to pomiar czasu wykonania kodu , nikt nie da gwarancji
//że przełożenie na różnych kompilatorach da taki sam wynik ...

Podaj punkt standardu, który tak mówi. Chyba, że ty jesteś standardem

Tu nie chodzi o standard tylko o kod wynikowy programu , to że piszesz w języku A b lub C
nie ma żadnego znaczenia..

Powiem tyle że new i malloc nie istnieją są tylko atrapami które przekładają się na funkcje
danego systemu operacyjnego podobnie jak inne języki ..

manfredek napisał(a)

Podaj punkt standardu, który tak mówi. Chyba, że ty jesteś standardem, wtedy to, że ty coś mówisz faktycznie ma znaczenie.

manfred nie kluc sie, bo jak piszesz np: manager pamieci to i tak uzywasz malloca i standard nie ma tu nic do rzeczy, standard udostepnia operator new i delete a ich implementacja i tak opiera sie o malloc/free ktore w posixie sa zwiazane z mmap :P

co wiecej niektorzy twierdza ze im mniej new/delete w programie tym program jest bezpieczniejszy :P

standard pewnie o tym nie mówi bo po co?
Na to wskazuje logika: po co tworzyć drugi kod do obsługi sterty, albo drugą stertę? Jedyna różnica pomiędzy new i malloc to to, że new oblicza (przy wsparciu kompilatora) potrzebny rozmiar pamięci i obsługuje konstrukcję. Domyślny allocator na pewno stosuje malloc.

void* operator new (size_t n); => void malloc(size_t n);
void operator delete (void ptr); => void free(void* ptr);

i tyle à propos roznic miedzy C a C++ :p

Może tak robić, ale nie musi... Tylko przyznać się, kto się spotkał z używaniem OPERATORA new i delete zamiast WYRAŻEŃ new i delete (które już robią nieco więcej niż malloc).

manfredek napisał(a)

kto się spotkał z używaniem OPERATORA new i delete zamiast WYRAŻEŃ new i delete (które już robią nieco więcej niż malloc).

TY? :-O [glowa]

kuzwa OPERATOR to wlasciwie funkcja, wiec new jako OPERATOR jest takze funkcja i w C++ mozna zrobic overloading funkcji wiec jak se dodasz jakies parametry z d**y czy do innego debugowania to bedziesz mial swoje WYRAZENIE co nie zmienia faktu ze bazowy operator new/delete to to co napisalem wyzej ;p

zreszta:
http://wazniak.mimuw.edu.pl/index.php?title=Zaawansowane_CPP/Wykład_14:_Zarządzanie_pamięcią
i zdupcaj :P

Ale później i tak robisz

foo* bla= new foo;

zamiastfoo* bla = static_cast<foo*>(operator new(sizeof(foo)));
new (bla) foo; //i tak mamy wyrażenie new

nie? Więc używasz wyrażenia new.

Czyli idąc tym tokiem rozumowania, pisząc:

string3 = string1 + string2;

używam wyrażenia +, a nie operatora +? :>

Nie, różnica między wyrażeniem i operatorem jest tylko przy new i delete...
<font size="1">Szczerze mówiąc, nie myślałem, że ty jesteś w stanie nie rozróżniać tych rzeczy...</span>

A dlaczego?