Newsgroup: it.comp.lang.c++
Titolo: C o C++? quale richiede più memoria? quale più veloce?

Salve,
Ho sentito dire che i programmi scritti in C++ richiedono più memoria.
Per loro natura (classi, definizioni ecc...) sarebbe più difficile
effettuare la garbag coll... non mi ricordo come si chiama ... insomma
lo svuotamento della memoria.
e per la velocità?
Quale è migliore?
Grazie in anticipo.
Mario.

e per la velocità?
Se un programma richiede più memoria fisica  - o dinamica - certamente la
sua esecuzione sarà più lenta.
Cmq rimane il fatto che C/C++ sono la stessa cosa per quanto riguarda
l'efficienza. 
Ciao.
-- 
La classifica dei prodotti MS:
C#, la migliore barzelletta di Bill Gates.
Visual C++, il meno standard dei compilatori C++.
J++, la copiatura più riuscita.
Windows, il più instabile.
Visual Basic, un esempio di prodotto decente della MS - forse l'unico -.
OutlookExpress, scandali su scandali.
Outlook, non essendo soddisfatto degli scandali di OE Bill Gates ha deciso
di 
               rilasciare la versione completa in modo da poterli
aumentare.
Word, uno dei principali esponenti dei programmi ribatezzati MS 
Windows NET, se dicono che il buongiorno si vede dal mattino allora 
                         vedo nero nel futuro di questo OS.
Disse Bill Gates "Datemi un programma ch'io possa ribattezzarlo MS"
E a gran voce gli risposero "Fai attenzione a non fare la fine di Stargate"
 
 

 Quale è migliore?
Io tifo per il C++: arriva al basso livello come il C, e vi aggiunge un
maggior controllo sui tipi, cosa indispensabile se non si vogliono creare
guai insidiosissimi. In più supporta molto bene la OOP, molto contrariamente
a quanto qualcuno afferma (motivando le sue affermazioni con stupidaggini
come: "non ci sono i costruttori virtuali", oppure "in java questo è
possibile"...).
Ciao
Domenico Barra

possibile"...).
Esatto :)
Specie quando i linguaggi citati a confronto hanno dall'altro lato
molte caratteristiche in meno.
--
Andrea Laforgia (ICQ 87230455)
http://www.geocities.com/AndreaLaforgia
"ci sono tre tipi di persone nel mondo : quelli che
 sono bravi in matematica e quelli che non lo sono."

Gli oggetti sono sempre piů pesanti di una soluzione strutturata.
Mica vero.
In cosa sarebbero piu' pesanti ?


Quale è migliore?
Non so se sia giusto parlare di linguaggi migliori o peggiori "in
assoluto" (tranne che in alcuni casi), tutto dipende anche dalle
preferenze e dalle esigenze dello sviluppatore, e capisco
perfettamente che ci sono ancora un sacco di programmatori che
scrivono in C infischiandosene altamente della programmazione ad
oggetti, dei modelli, della STL, ecc..ecc...
Lavinia
WINWORD.EXE - ERRORE DI APPLICAZIONE
l'istruzione a "0x3017ff27"ha fatto riferimento alla
memoria a "0x02a3143c".La memoria non poteva essere 'read'.

In cosa sarebbero piu' pesanti ?
per quanto ne so....
il solo dynamic binding mi sembra gia' fonte di appesantimento!

il solo dynamic binding mi sembra gia' fonte di appesantimento!
E' vero, ma non si puo' dire che gli oggetti sono SEMPRE piu' pesanti
di una soluzione strutturata.
A basso livello non c'e' alcuna differenza tra un oggetto e una
struttura. Dato che i membri dell'oggetto stesso subiscono il "name
mangling", alla fine, cio' che si ottiene e' la stessa situazione di
dati e funzioni come due cose separate.


dati e funzioni come due cose separate.
sul SEMPRE sono d'accordo.... forse e' un po troppo,
pero' generalizzando, il compilatore deve inserire codice che tu non
hai scritto per supportare queste belle caratteristiche (questa almeno
è una mia supposizione!), quindi per quanto possa essere  intelligente
e quindi aggiunga solo la "roba" necessaria, se scrivi del codice
minimamente OO sfrutti queste caratteristiche e quindi il relativo
overhead!


Il dynamic binding aggiunge un certo overhead, trascurabile però nella
maggior parte delle applicazioni comuni. D'altra parte non dimentichiamo che
il C non offre affatto una soluzione del genere, e tale soluzione è a mio
parere molto, molto comoda.
Ciao
Domenico Barra

 overhead!
Vero, ma queste caratteristiche, vedi ad esempio la chiamata a funzione
virtuale, forniscono delle funzionalita' specifiche, delle quali si
presume ci sia bisogno.
In C sarabbe necessario ricorrere a trucchi espliciti con puntatori a
funzione, con *almeno* lo stesso overhead e maggior rischio di errore;
oppure a innumerevoli if e switch espliciti, il cui peso puo' essere
minore o maggiore (piu' probabilmente maggiore se non si tratta di
condizioni banali), ma che comunque contribuiscono ad estendere il
codice, quindi anche a peggiorare le prestazioni.
Ciao,
Nicola

il solo dynamic binding mi sembra gia' fonte di appesantimento!
non è sempre vero; nei casi in cui la classe di appartenenza di un
oggetto è certa il compilatore se ottimizza può effettuare un early
(si dice così?) binding. Es:
struct X { virtual void f() { } };
int main() {
	X a;
	a.f();
}
in questo caso il compilatore può richiamare direttamente il metodo
giusto, senza passare per la virtual table
La perdita di efficienza si ha solo quando si richiamano metodi su un
oggetto di cui non è sicura la classe. Es:
void prova(X* p) {
	p->f();
}
ma in questo caso anche la programmazione strutturata dovrebbe
utilizzare tecniche che comportano la perdita di efficienza (ad
esempio puntatori a funzione o flag)
Anto
--
Antonio Cuni, 18 anni, studente
Brainbench Certification: 
Master C++: 4.44, higher than 97% of all previous test takers.
Visual Basic 5: 3.06, higher than 77% of all previous test takers.
http://www.brainbench.com/transcript.jsp?pid=1301688

 esempio puntatori a funzione o flag)
O piu' probabilmente mari di if e switch sparsi per tutto il codice che
verificano la stessa condizione. Il dynamic binding non e' che un modo
per fattorizzare in un singolo posto, ovvero il momento
dell'istanziazione, la valutazione di tutte le condizioni che dipendono
dalla struttura della classe e non da un suo stato transitorio. In
effetti rispetto alla programmazione strutturata e' una tecnica di
ottimizzazione.
Ciao,
Nicola

 In cosa sarebbero piu' pesanti ?
Io credo che scrivre :
int main()
{
    char stringa_1[] = "pippo";
    char stringa_2[] = "pluto";
    char stringa_3[] = "paperino";
    char stringa_4[] = "topolino";
    char stringa_5[] = "paperoga";
    char stringa_6[] = "gastone";
...
}
e' piu' efficiente di:
int main()
{
    string stringa_1 = "pippo";
    string stringa_2 = "pluto";
    string stringa_3 = "paperino";
    string stringa_4 = "topolino";
    string stringa_5 = "paperoga";
    string stringa_6 = "gastone";
...
}
Ivan Molella

}
non è vero in assoluto: grazie all'inlining e ottimizzazioni varie
*credo* che usare std::string sia grosso modo equivalente ad usare
char[]. Inoltre, secondo me, sei uscito un po' dai binari della
discussione: infatti parlavamo di programmazione strutturata vs OOP,
non di tipi *specifici*. Ad esempio un programmatore potrebbe
benissimo usare le std::string seguendo la programmazione strutturata,
un altro potrebbe fare OOP usando i char[].


 non di tipi *specifici*.
A me sembrava che il thread iniziale fosse relativo alle performance del c
e c++,ed io ho portato un'esempio di come secondo me il c++ sia in taluni
casi meno efficiente del c.
PS: non ho testato le 2 versioni,mi sono soltanto basato su cio' che *a
prima vista* le 2 diverse dichiarazioni  sembrino comportare
Ivan Molella

= "stringa"*  non produce.
In effetti una certa perdita di prestazioni c'é, ma é trascurabile se
si fa riferimento ad una stringa che viene inizializzata una volta
sola e non più manipolata.
Nelle operazioni di concatenamento di std::string invece ho notato dei
cali di prestazioni molto significativi(soprattutto se non si usa
reserve() ), anche se va detto che ciò può dipendere dalla qualità
della libreria standard di alcuni compilatori.
Il Ghenio


 della libreria standard di alcuni compilatori.
Beh, qualche tempo fa ho confrontato, per la conversione tipo
numerico-string, la scrittura su uno string stream con sprintf; e
vinceva il C++ per un 10% circa, mi pare.
Ma il problema vero e' quello spiegato nell'ultime frase: tutto
dipende dal compilatore e dalla sua libreria.  Ad esempio, passando
dalla libreria standard inclusa con g++ 2.95.2.1 a quella dell'ultima
versione rilasciata, si guadagna un fattore in tempo che non ho
cronometrato ma che, ad occhio, puo' variare dal 30% in su.
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy            
lor...@pd.infn.it
The instructions said to use Windows 98 or better - so I installed FreeBSD.

 della libreria standard di alcuni compilatori.
Ho fatto una prova con il DJGPP e con il BCC55 trovando con entrambi una
differenza di velocità di 5/6 volte in favore degli array. L'uso di
reserve() non ha dato miglioramenti. Quindi la std::string sembra
(almeno allo stato attuale di questi due compilatori) sia meglio non
utilizzarla quando è richiesta la massima velocità (e il C++ esiste
proprio per questo, no?).
EMG
PS. Segue il programma di test, nel caso ci fosse qualcosa di sbagliato:
#include <iostream>
#include <string>
#include <ctime>
int main()
{
    char s1[ 80 ];
    std::string s2;
    std::clock_t start, end;
    const long NumIter = 100000;
    start = std::clock();
    for ( long i = 0; i < NumIter; ++i )
    {
        strcpy( s1, "Prova" );
        strcat( s1, "Prova" );
    }
    end = std::clock();
    std::cout << "Ticks impiegati: " << ( end - start ) << std::endl;
    s2.reserve( 80 );
    start = std::clock();
    for ( long i = 0; i < NumIter; ++i )
    {
        s2 = "Prova";
        s2 += "Prova";
    }
    end = std::clock();
    std::cout << "Ticks impiegati: " << ( end - start ) << std::endl;
    return 0;
}

Nelle implementazioni attualmente disponibili e' probabile che tu abbia
ragione, perche' comunque la versione che utilizza std::string richiede
allocazione dinamica di memoria. Nota pero' due cose: intanto con
std::string utilizzi uno strumento decisamente piu' potente e versatile
di char *; in secondo luogo un'implementazione e' liberissima di
preeseguire durante la compilazione tutti i passi che non comportano
output, quindi un compilatore molto ottimizzante potrebbe portare alle
stesse prestazioni per le due versioni.
Ciao,
Nicola

proprio per questo, no?).
Non credo che la ragione di esistere di std::string sia la maggiore
velocità, piuttosto quella di avere una classe di manipolazione delle
stringhe dotata di molte comodità(estrazioni di singoli caratteri,
aggiunta, confronti fra stringhe,ecc.ecc)che erano del tutto assenti
nei vecchi array di char, costringendo a scrivere codice di basso
livello per ottenere gli stessi identici risultati. Ad ogni modo
l'esempio che hai postato con l'inizializzazione della stringa
all'interno del for credo che di fatto annulli tutti i vantaggi
dell'uso di reserve.
La prova giusta per dimostrare l'incremento di prestazione offerte da
reserve() nella concatenazione di stringhe dovrebbe essere questo o
qualcosa di simile
#include<iostream>
#include<ctime>
#include<string>
int main()
    {
    std::clock_t start, end;
    start = std::clock();
    std::string s;
    s.reserve(10000);
    for(int i=0;i<10000;i++) s+="x";
    end = std::clock();
    std::cout << "Ticks impiegati: " << ( end - start ) << std::endl;
    cin.get();
    return 0;
}
Provando il seguente programma su BCB3 i risultati sono stati questi:
omettendo il reserve
Ticks impiegati: 491
includendo il reserve
Ticks impiegati: 19
Il che vuol dire che ci si avvicina nettamente alla velocità che si
avrebbe utilizzando gli array.


 dell'uso di reserve.
Ma infatti il mio test non era per il reserve() ma per il confronto tra
array di char e std::string, confronto dal quale è uscito nettamente
vittorioso il primo (almeno con i due compilatori da me utilizzati).
EMG

prima vista* le 2 diverse dichiarazioni  sembrino comportare
anche testandole non avresti la prova definitiva. Dipende tutto da
compilatore e piattaforma utilizzati.


 č certo il C++ *di per sč stesso* che č piů lento del C.
No certo. Semplicemente ci sono tecniche C++ che sono meno performanti di altre.
Ma non sono equivalenti. Ti serve la funzionalita' di string? Devi usare string.
Non ti serve ma DEVI essere veloce. Usa char*. Non ti serve ma la differenza in
velocita' e' cosi' piccola che non cambia molto. Usa string che ha piu'
funzionalita': e' piu' probabile che in futuro ti servano funzionalita' extra
che non performace extra.
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

una string!).
infatti, in generale; io volevo sottolinerare il fatto che non lo
fosse *in assoluto*, come non si puň dire in assoluto che il C o il
C++ siano piů veloci dell'altro.
cmq mi sembra una discussione destinata a non finire mai, direi di
smetterla.
Ciao Anto
