Newsgroup: it.comp.lang.c++
Titolo: genericita' vs semplicita'

parlavamo qualche thread sopra del disaccoppiamento... avevo chiesto
perché esiste sort(first, last) e non sort(container), dato che molto
spesso uno vuole ordinare tutto un container e non fare cose più
particolari come usare il sort con un non-container o ordinare solo un
pezzo del container...
è giusto il discorso che si fa sulla genericità, è giusto anche che
esista la possibilità di fare sort(first, last)... ma, come dicevo
sopra, verrà fatto milioni di volte
sort(container)
e poche volte
sort(first, last)
quindi, perché non mettere anche la funzione sort(container)? è una
questione di semplicità di utilizzo, un po' come la solita questione
di convertire un int in std::string o viceversa... almeno una volta
alla settimana su questo newsgrup qualcuno chiede come si fa...
è chiaro, uno si può scrivere la propria funzione sort(container) e la
propria funzione trasforma_in_stringa(int), ma perché costringere
milioni di persone a farlo? non era più semplice metterlo nella
libreria std? semplice per tutti, intendo
poi, altro caso di semplicità: l'uso di "using namespace std", ok, si
"sporca il namespace", è poco carino, non ci piace... ma invece dover
scrivere std:: davanti a tutti i vector, tutti gli string, nonché
tutti gli stream e tutti i modificatori come endl, ecc... non è un
inutile spreco di scrittura, bytes e soprattutto di leggibilità?
la filosofia mi sta bene, la strutturazione precisa anche, la
genericità pure... ma secondo me a volte si esagera
-- 
]\/[ad]\/[age (
www.mindreamz.net
)
"Un Maestro insegue semplicemente la sua visione di Eccellenza in
qualunque cosa sta facendo e lascia agli altri decidere se sta 
lavorando o giocando. A lui sembra sempre di fare entrambe." - Anonimo

 libreria std? semplice per tutti, intendo
Na cosa simile??
string IntToStr(int & number)
{
std::ostringstream of;
of << number;
return of.str();
}
-- 
Kleidemos
C++ Programmer
kleidemo...@altervista.org
http://kleidemos.altervista.org/

}
certo
anche se, in linea con la libreria standard, l'avrei chiamata
int_to_string(int& number);
io, sinceramente, avrei fatto un costruttore di std::string con int e
double, giusto per evitare funzioni in più da dover far imparare al
programmatore


 genericità pure... ma secondo me a volte si esagera
Punti di vista... C e C++ sono linguaggi da monaci... a me piace pensarla
così!
Ciao e buone feste!

 inutile spreco di scrittura, bytes e soprattutto di leggibilità?
Nei file di implementazione si puo` tranquillamente usare "using
namespace std", e anche alcuni guru lo consigliano.
Il problema e` quando lo si usa negli header, sporcando il namespace
globale di tutti i file che includono (anche indirettamente) l'header.
        Mauro

 E' superflua.
E' più che superflua. E' un danno!
Non ultima considerazione,
sort è minimalista... è il minimo necessario affinché tutto funzioni bene!
Data la generalità dell'algoritmo il compilatore o il programmatore
potrebbero cadere in errore a meno di poco convincenti stratagemmi.
La filosofia sembra distante dalla realtà (proprio come la matematica sta
all'ingegneria per usare un tuo paragone, col quale ovviamente, non sono
d'accordo, ma sono io un bastian contrario...) invece a pensarci bene ci
sono buoni motivi per seguire certe regole, come quella del
disaccoppiamento!
sort non accetta solo container standard ma anche tipi . E' perfettamente
lecito, al posto degli iteratori utilizzare ad esempio
miotipo array[]={4,2,-1,0,9,6};
int sz=sizeof(array)/sizeof(*array);
sort(array,array+sz);
sort può anche lavorare con generiche classi non perfettamente compatibili
con i container standard (cioè non avere begin e end ad esempio o
semplicemente per non essere contenitori), ma che certamente (per
definizione di iteratore) lavorano perfettamente con la versione proposta
della funzione.
Se fosse esistito un overload si sort e si fosse tentato un sort(array) o un
sort(miaclasse) le cose sarebbero diventate difficili da gestire...
Ora se l'overload te lo fai tu, ciò è perfettamente lecito ma chi
distribuisce una libreria a mio avviso fa bene ad evitare guai !
Prova questo codice.
Ciao.
------------------------------
#include <iostream>
#include <iterator>
#include <vector>
#include <algorithm>
using namespace std;
// overload della funzione sort
template<typename T>
void sort(T& v)
{
        sort(v.begin(),v.end());
}
class miaclasse
{
        int n;
        public:
        miaclasse(int N) : n(N)
        {
        }
        int get() const { return n; }
        friend bool operator<(const miaclasse& l,const miaclasse& r)
        {
                return l.n<r.n;
        }
        operator int() const { return n; }
};
int main()
{
        typedef int miotipo;
        miotipo array[]={4,2,-1,0,9,6};
        int sz=sizeof(array)/sizeof(*array);
        vector<miotipo> v(array,array+sz);
        cout << "Vettore disordinato\n";
        copy(v.begin(), v.end(),ostream_iterator<int>(cout, " "));
        sort(v);
        cout << "\nVettore ordinato\n";
        copy(v.begin(), v.end(),ostream_iterator<int>(cout, " "));
        sort(array,array+sz);
        //sort(array); // PROVA A TOGLIERE IL COMMENTO DA QUESTA !!!
        cout << "\nstampa l'array ordinato...\n";
        copy(array, array+sz,ostream_iterator<int>(cout, " "));
        cout << endl;
        miaclasse M[]={4,2,-1,0,9,6};
        int ms=sizeof(M)/sizeof(miaclasse);
        cout << "\nProva mia classe disordinata\n";
        copy(M, M+ms,ostream_iterator<int>(cout, " "));
        cout << "\nProva mia classe ordinata\n";
        sort(M,M+ms);
        copy(M, M+ms,ostream_iterator<int>(cout, " "));
        return 0;
}

 programmatore
E complex, long, bool, ...?
Io sono per la funzione.  Puoi sempre avere costruttori per tutti i
tipi standard, ma non puoi aggiungere costruttori per nuovi tipi
user defined, mentre la funzione si puo` usare anche con quelli.
       Mauro

 genericità pure... ma secondo me a volte si esagera
 >
Non mi parlare di filosofia, al liceo avevo 4 in quella materia...
Forse, semplicemente, ti aspetti troppo dalla libreria standard.
Ricorda che la libreria standard non contiene e NON deve contenere tutto 
lo scibile umano sul C++, ma deve solo rendere disponibili dei buoni 
strumenti di base, flessibili, ben progettati. Se ti serve qualcosa in 
piu' te lo puoi scrivere o chiedi a qualcuno che l'ha scritto prima di te.
Tutto qui.
Buon anno.
-- 
Roal Zanazzi

piu' te lo puoi scrivere o chiedi a qualcuno che l'ha scritto prima di te.
d'accordo... ma non sul parse di una stringa a intero o la conversione
da intero a stringa...
ad esempio, perché esiste vector::push_back? non potremmo usare il
back_inserter?
credo che la risposta sia che usare il push_back è più COMODO, no? ho
detto una cavolata?


 detto una cavolata?
 >
Io invece direi che il push_back e' un'operazione specifica del 
container, che sia comodo o meno, e ad esso deve appartenere.
Per gli inserter, invece, il discorso e' simile a quello iniziale del 
sort(container).
Un inserter serve a disaccoppiare i container dagli algoritmi nei casi 
in cui l'uso di un iteratore non e' possibile o non avrebbe il risultato 
voluto; vedi ad esempio std::fill_n().
La cosa e' chiara se si guarda la definizione di un inserter: prende un 
container come parametro e restituisce un iterator => realizza il 
disaccoppiamento tra container e utilizzatore (algoritmo), attraverso un 
iteratore (dopo aver fatto qualcosa sul container).
Scusate se ho scritto delle imprecisioni, ma non sono un mago del C++ e 
ho ancora delle bollicine di spumante incastrate tra le sinapsi di 
entrambi i neuroni :-P
-- 
Roal Zanazzi

 std::sort(container).
Fermo restando che le obiezioni mosse da Casini e da me sono ancora lě...
Ciao e buon anno.

 
Altrettanto. :-)
-- 
Roal Zanazzi