Witam.
Potrzebuje rady - Od zawsze pisałem programy w czystym C, mam spore wątpliwości czy jednak zacząc używać C++.
Orientuje się troche w tych klasach itp, lecz nie jestem przekonany do tego "języka". Wiem że ułatwiona jest sprawa z programowaniem, oraz dalszym rozwijaniem programu. Lecz jak to wpływa na szybkość działania aplikacji, zużycie pamięci?
Czy naprawde opłaca się przesiadka na C++ nie licząc ułatwień?
0
0
w porownaniu do aplikacji w javie czy w jakis skryptowych syfach to c++ i tak wymiata pod wzgledem szybkosci i co najwazniejsze jest znacznie bardziej wydajny przy tworzeniu duzych systemow :p
a skoro do ciebie nie przemawia to po prostu nie rozumiesz obiektowosci :p
0
Im więcej osób pracuje nad 1 projektem tym bardziej opłaca się obiektowość. Każdy dostaje swoją klasę i może wydzielić z czego inni mogą korzystać, a z czego nie. Wydajność zależy przede wszystkim od algorytmu, a nie od języka. Niektóre algo mogą być szybsze w C++, a niektóre w C. Zależy to też od kompilatora i stopnia optymalizacji.
0
cepa napisał(a)
c++ i tak wymiata pod wzgledem szybkosci
Tja, piszemy 20 razy dłużej i mamy 5% szybciej ;P
0
somekind napisał(a)
cepa napisał(a)
c++ i tak wymiata pod wzgledem szybkosci
Tja, piszemy 20 razy dłużej i mamy 5% szybciej ;P
Jak ktos nie chce sie zblaznic to nie powinien zabierac glosu w sprawach o ktorych nie ma zielonego pojecia. ;-P
0
Programy w C++ zwykle mają bardzo podobną wydajność do odpowiedników w C (raz kilka procent w jedną, raz kilka procent w drugą stronę), a pisze się szybciej i kod jest bardziej czytelny.
0
Jeszcze pytanie: co zamierzasz pisać w C++. Jak coś bardzo niskopoziomowego typu moduły do jądra to odpuść sobie C++ - mieszanie niskopoziomowego kodu z wysokim poziomem nie jest dobrym pomysłem. Jak aplikacje użytkowe to C++ może być dobry chociaż są lepsze języki do tego.
0
Co ty programujesz? Jeśli coś poza rzeczami typu atmega to zapomnij o c++ - pisz w C# albo Javie...
Na PC C++ ma dwa zastosowania: gry i rozwijanie starego softu. A to pierwsze zaczyna mijać...
Manualne zarządzanie pamięcią, brak refleksji, mała elastyczność języka (niektóre konstrukcje są niemożliwe ze względu na cykliczne odwołania i trzeba niepotrzebnie kombinować)...
A pisanie driverów itd jest jak najbardziej możliwe w C++ - trzeba tylko nadpisać domyślną alokację pamięci.
0
tak a propos wydajności:
printf.c:
#include <stdio.h>
int main(){
unsigned i=(unsigned)-1;
while(i--)printf("test\n");
return 0;
}
cout.cpp:
#include <iostream>
using namespace std;
int main(){
unsigned i=unsigned(-1);
while(i--)cout << "test\n";
return 0;
}
...
$ g++ cout.cpp -o cout ; gcc printf.c -o printf
$ s -l cout printf
-rwxr-xr-x 1 flabra users 8427 2009-06-11 17:28 cout*
-rwxr-xr-x 1 flabra users 7032 2009-06-11 17:29 printf*
$ time ./cout > /dev/null ; time ./printf > /dev/null
real 9m6.886s
user 8m56.042s
sys 0m3.804s
real 5m23.589s
user 5m16.772s
sys 0m2.652s
nie iwerze, że wydajnośc czegokolwiek co do wyprowadzenia zwyklego napisu potrzebuje zagniezdzenia klas na poziomie min 2 bedzie rowna albo wieksza od prostego i bezposredniego wywolania pojedynczej funkcji
i tak jest ze wszystkim, latwosc pisania kodu przeklada sie na jego wydajnosc
0
Flabra - nie wypowiadaj się jak jesteś ignorantem
Po pierwsze, stl nie używa praktycznie w ogóle obiektowości (a tylko wołanie funkcji wirtualnych ma mały narzut),
po drugie, jak się porównuje wydajność strumieni (nie c++!) w tego typu programach (bardzo krótkie) to trzeba dać:
std::sync_with_stdio (false);
I - wow - strumienie okazują się dwa razy szybsze!
0
Tu jest prosty skrypt w bashu do testu stdio i strumieni: http://wklej.org/id/104457/ jak by ktoś chciał.
0
Na windowsie bo gcc na shellu okazał się być z 2003 roku... tam rzeczywiście strumienie były o wiele wolniejsze.
#include <stdio.h>
int main() {
int i = 0;
for(; i < 5000000; i++) printf("i = %d", i);
}
i
#include <iostream>
int main() {
std::ios_base::sync_with_stdio(false);
for(int i = 0; i < 5000000; i++) std::cout << "i = " << i << std::endl;
}
wynik
>c:\cygwin/bin/time.exe d:\kody\cout.exe > NUL
0.01user
0.01system
0:06.97elapsed
0%CPU (0avgtext+0avgdata 104448maxresident)k
0inputs+0outputs (411major+0minor)pagefaults 0swaps
>c:\cygwin/bin/time.exe d:\kody\printf.exe > NUL
0.03user
0.00system
0:09.78elapsed
0%CPU (0avgtext+0avgdata 103680maxresident)k
0inputs+0outputs (405major+0minor)pagefaults 0swaps
Strumienie są tym szybsze im więcej rzeczy wypisujemy (bądź wczytujemy) - typ jest znany podczas kompilacji (statyczny polimorfizm), printf musi skanować za każdym razem, dodatkowo strumienie buforują.
Wszystko kompilowane gcc 4.2.1 z -O2
0
Nawet na konkursach algorytmicznych organizatorzy odradzają używanie strumieni - program kończy czytać dane, kiedy czas na zadanie się kończy.
dodatkowo strumienie buforują
A printf nie buforuje? ;p
0
babciu stasiu, w twoim kodzie strumienie NIE buforują - po każdym wysłaniu i = <liczba> robisz flush. Cheater.
0
Jeśli chodzi o avr'ki czy coś innego to nawet nie myślałem aby pisać w C++. Zastanawiałem się na przejściu z asm na c, przy troche wyższym poziomie programowania i się opłaciło... Dobra ale nie miałem na myśli scalaków zakładając ten temat.
Pisząc w C++ nie miałem też na myśli wypisywanie tysięcy linijek tekstu w konsoli :-) . Głównie chodzi mi o procesy inicjacji klas, ile dodatkowo potrzebują pamięci.
W C robie tak, tworze plik .c/.h gdzie będzie kod rozwiązujący dany problem, np. konwersja/szyfrowanie...
Zwykle tworze funkcję "int Init_PROBLEM(arg...)", "ini Free_PROBLEM(arg...)".
Przejście na C++ polegałoby na sporej zmianie. Funkcje Init, Free oczywiście zamienione by zostały na konstruktory/destruktory, parametry/uchwyty danych znikłyby pojawiając się jako zmienne w klasach. Zwiększenie prędkości widzę przy dużej ilości wywoływania danej funkcji, w C za każdym razem muszę przesyłać uchwyty czy jakieś dodatkowe (stałe) dane, gdzie w C++ byłyby zapisane w klasie. Lecz czy programując już obiektowo C++ jest dobrym językiem do tych celów? Czy może jednak Java? Zauważyłem też że programy obiektowe więcej ważą... Mam jakiś uraz do obiektów, lecz w dzisiejszych czasach jak najbardziej dominuje(nie patrząc na "drivery" itp)...