Newsgroup: it.comp.lang.c++
Titolo: safearray

ciao a tutti, la domanda non e' forse proprio ansi compliant ma c'e'
qualcuno che sa dirmi dove leggere qualcosa per imparare ad usare i
safearray in c++ ?
grazie.

 safearray in c++ ?
piu' safe dello std::vector c'e' poca roba...



Non starai mica parlando dei SAFEARRAY del VC++? Aaaargggh... chiedere
su it.comp.programmare.win32 , prego.
Il Ghenio
-----
These are my parting words to you:
those who give up are doomed!
-----

knip wrote:

non so cosa siano i safearray, ma se vuoi un array sicuro, usa questo:
#include <vector>
int main()
{
        std::vector<int> v(10);
 
v.at
(4) = 3;
 
v.at
(15) = 4; // solleva una eccezione di tipo std::out_of_range
}
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

}
Si, ma lui stava sicuramente parlando dei SAFEARRAY del VC++ quindi OT
e niente a che vedere con i vector e con la funzione membro at.



Secondo me std::vector e' molto poco safe, perche' un
std::vector<>::iterator puo' anche puntare fuori dall'array, a meno di non
utilizzare SafeSTL.
E' invece molto piu' safe una classe autocostruita che per l'operator
[](size_t) puo' fare tutti i test di indice.

         
v.at
(15) = 4; // solleva una eccezione di tipo std::out_of_range
at solleva l' eccezione, mentre v[15] no, per cui non mi sembra il massimo 
della "safecitica'" (!?!?!?!??) :))))
-- 
FUSION (fyu zh & n) n: 
1) the Act or Process of Fusing or Melting Together... 
2) the State of being Fused... 
3) to Join or become Combined...

 [](size_t) puo' fare tutti i test di indice.
non ne vedo proprio il motivo, ne' la necessita'. i test li fa gia' 
at(), ma comportano overhead. [] non li fa, e quindi dipende da quello 
che vuoi fare

 della "safecitica'" (!?!?!?!??) :))))
Si peccato che poi se non scrivi il codice "exception safe" ti si bomba
tutto.
Ciao
Gaetano.
-- 
Posted from 
dell-01.mm.eutelsat.org
 [194.214.173.17] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 bomba tutto.
allora lascia stare il C++, non fa per te...
Se credi che Safe significhi "qualunque cosa accada, deve arrivare ad 
un punto d'uscita pulito e non creare casini" e che sia possibile 
realizzarlo senza metterci del tuo, cambia linguaggio
Se invece non vuoi cambiare, leggiti exceptional C++ di herb sutter

 Se invece non vuoi cambiare, leggiti exceptional C++ di herb sutter
Gia fatto. 
Ciao.
Grazie.


 tutto.
Non capisco cosa vuoi dire con questo... 
Come dire : pecccato che poi se fai errori il programma non funziona ? :-)


 Come dire : pecccato che poi se fai errori il programma non funziona ? :-)
No. Vuol dire che se non ti prepari alle eccezioni il programma funziona
per anni e poi inizia a bombare e non si capisce perche'.
E volevo solo ribadire che "Usare librerie safe " non vuol dire programmare
"safe".
E non tutti lo fanno.


 "safe".
Si' ok ma nel mio messaggio originario infatti dicevo che vector non era il 
massimo della sicurezza, e spiegavo che operator[] non solleva eccezioni per 
esempio, il che lo renderva non molto safe.


 eccezioni per esempio, il che lo renderva non molto safe.
 
invece e' perfettamente exception-safe, almeno sulle implementazioni 
STL e di gcc. Che il codice faccia casino, sono problemi del codice, 
non dello std::vector.

, aha...@laugh.doh says...

Se non ricordo male lo stesso Storstroup in uno dei capitoli introduttivi di 
C++ programming language tratta un' estensione di vector per renderla piu' 
safe. (Lo fa solo per fare un esempio cmq)
Che operator[] non generi eccezioni e' appurato, per cui non capisco proprio 
come faccia ad essere safe.



Che vuoi dire perfettamente exception-safe? Che se qualcuno
lancia un'eccezione non deve preoccuparsi di eventuali comportamenti
di oggetti STL ?
Se fossi cosi' a tal proposito avrei dei dubbi che non mi fanno dormire la
notte.
Ciao
Gaetano.
-- 
Posted from 
nts-03.mm.eutelsat.org
 [194.214.173.15] 


 proprio come faccia ad essere safe.
mi sa che confondi a prova di eccezione e a prova di seg fault:
il primo vuol dire che in caso di eccezione in una qualsiasi operazione 
il vector e' in uno stato safe, per cui puo' essere riutilizzato una 
volta risolta l'eccezione. l'out_of_range, la quale invece e' 
un'eccezione, non viene sollevata dal [], e quindi tale operazione non 
e' a prova di seg fault, pur essendo a prova di eccezioni.
spero di aver chiarito il mio concetto a riguardo, anche per G.Mendola

esempio, il che lo renderva non molto safe.
Nessuno ti vieta di scriverti una classe apposita derivata da
std::vector con un operator[] che chiama la funzione membro 'at' dello
std::vector in caso di sconfinamento.
Codice preso quasi pari pari(con qualche piccola aggiunta) da un
programma di esempio di Bjarne Stroustrup e correttamente compilato.
template<class T> class safevector:public std::vector<T>
    {
    public:
        safevector(): std::vector<T>() {}
        safevector(int i,T q) : std::vector<T>(i,q) {}
        safevector(int i) : std::vector<T>(i) {}
        T& operator[](int i) {return at(i);}
        const T& operator[](int i) const {return at(i);}
    };


 std::vector in caso di sconfinamento.
A parte che questo particolare l' ho aggiunto anche io qualche messaggio 
dopo, ma si parlava di vector punto e basta.  Ed il vector punto e basta non 
e' safe.


 massimo della "safecitica'" (!?!?!?!??) :))))
se il programmatore sa come si comporta operator[] e vuole andare sul 
sicuro basta che non lo usi e si limiti ad utilizzare at(). Come al 
solito, il C++ protegge dagli errori accidentali, non da quelli 
provocati deliberatamente. E, cmq, se vuoi un array safe anche 
utilizzando operator[], basta fare cosi' (non compilato):
template<class T>
class SafeVector: private std::vector<T> {
public:
  // varie dichiarazioni using e typedef utili
  T& operator[](std::size_t i) { return at(i); }
  const T& operator[](std::size_t i) const { return at(i); }
};


 bomba tutto.
hai perfettamente ragione ma, dato che buona parte della libreria std 
utilizza il meccanismo delle eccezioni per gestire eventuali errori il 
programmatore C++ dovrebbe sempre cercare di scrivere codice exception 
safe, altrimenti non fa un uso corretto della lib std (putroppo non e' 
per niente facile scrivere codice safe, ma questo e' un altro discorso).


per niente facile scrivere codice safe, ma questo e' un altro discorso).
Pienamente d'accordo, ma utilizzare la funzione membro 'at' significa
sicuramente aggiungere un certo overhead e non sono sicuro che questo
sia sempre necessario( se non in alcune situazioni critiche). Non
dimentichiamoci poi che gli std::vector a differenza degli array di
basso livello forniscono informazioni precise sul numero di elementi
della lista(la famosa funzione membro size() ), percui lo
sconfinamento può essere evitato a priori anche senza l'uso di
eccezioni.


 realizzarlo senza metterci del tuo, cambia linguaggio
Per il problema dell'arresto questo non e' possibile in nessun
linguaggio.
Ciao,
Nicola

 utilizzando operator[], basta fare cosi' (non compilato):
Si' si' l' estensione del' vector e' chiara a tutti da anni penso, infatti 
io ho replicato rimanendo solo ed esclusivamente in ambito di vector 
standard.


 eccezioni.
Altro che overhead allora se prima di usare le [] devo anche fare un size().
Ciao
Gaetano.
-- 
Posted from 
nts-03.mm.eutelsat.org
 [194.214.173.15] 


 basta non e' safe.
non e' chiaro cosa intendi con "safe". Se intendi "exception-safe" 
sbagli, come ti e' gia' stato fatto notare.
Se intendi che std::vector<> non e' sicuro da usare, sbagli nuovamente: 
esso offre tutti i metodi necessari per accedere agli elementi in modo 
sicuro e, oltre ad essi, fornisce anche altri metodi non-safe ma che 
possono essere non utilizzati.
Potresti obiettare che se una classe espone almeno un metodo non-safe 
essa e' da considerare, in toto, non-safe; pero' cadresti in 
contraddizione, dato che hai detto che il "safevector" proposto da Il 
Ghenio e' safe; pero' anche safevector dispone di alcuni metodi 
non-safe:
        safevector<int> v(10);
        v.std::vector::operator[](100); // non-safe


 Ghenio e' safe; pero' anche safevector dispone di alcuni metodi 
No, questo te lo sei inventato te :-) Io non ho mai detto essere safe, anche 
perche' ci ho solo dato un' occhiata veloce :-)
btw: se una classe esponesse qualcosa di non safe e' palesemente ovvio che 
non sia safe... Mi pare che la logica mi venga in aiuto :-)


 spero di aver chiarito il mio concetto a riguardo, anche per G.Mendola
No, non li confondevo, semplicemente stavamo parlando di due safe diversi, 
cmq ora ho capito il tuo concetto :-)


 linguaggio.
veramente, se mi avese risposto quale, gli avrei ribadito "in 
italiano", in quanto posso tranquillamente "dirlo"

 size().
una size eseguita in tempo costante ( che tra l'altro fa anche at() ) 
avrebbe piu' overhead della gestione delle eccezioni?

From: "Aloha" <aha...@laugh.doh>
Newsgroups: it.comp.lang.c++
Sent: Monday, October 29, 2001 9:05 PM
Subject: Re: safearray

Si.


 Si.
No. Se la gestione delle eccezioni esiste comunque nel programma,
l'overhead è esattamente lo stesso. Se invece riesci ad evitare la
gestione delle eccezioni l'overhead è molto minore (e non solo per quel
codice ma per TUTTO IL PROGRAMMA).
--
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

 codice ma per TUTTO IL PROGRAMMA).
Io dicevo che fare l'uso di size() prima di ogni uso di [] ha piu
overhead di fare un try - catch. Assumendo che il mio eseguibile
abbia il supporto per la gestione delle eccezioni.
Non mi starai consigliando di disabilitare la gestione delle eccezioni ?
Spero di no.


 Spero di no.
No. Se sono abilitate non ti sto affatto consigliando di disabilitarle.
Ma se non lo sono (indice che tutto il resto del programma non fa uso
delle eccezioni C++) allora ti sto consigliando di non abilitarle a
causa di un unico accesso ad array!
--
Posted from 
nts-03.mm.eutelsat.org
 [194.214.173.15]
via Mailgate.ORG Server - 
http://www.Mailgate.ORG
--


 che non sia safe... Mi pare che la logica mi venga in aiuto :-)
 
dipende dalla definizione di safe.
