Newsgroup: it.comp.lang.c++
Titolo: domanda scema e facile!

se ho una stringa del tipo:
static unsigned char pippo[max]
esiste un modo per annullarla, ovvero per farla diventare vuota?
grazie!

 esiste un modo per annullarla, ovvero per farla diventare vuota?
Cosa intendi per vuota?
pippo[0]=0 ?
-- 
Luc.

 wrote in message
news:9r8mtd$s18lc$1...@ID-108178.news.dfncis.de...

#define MAX 64
static unsigned char szPippo[MAX];
1) szPippo[0] = '\0';
2) memset (szPippo,0x00,sizeof (szPippo));
questi sono i modi per inizializzare (o reinizializzare)una stringa.
Altra modo di lavorare:
#define MAX 64
unsigned char *szPippo = NULL;
if (szPippo != NULL)
{
  delete szPippo;
  szPippo = NULL;
}
szPippo = new char [MAX];
if (szPippo)
{
  // lavoro con szPippo
  ...
  ..
}
// Annullo szPippo
if (szPippo != NULL)
{
  delete szPippo;
  szPippo = NULL;
}
Byes
-- 
Posted from  [62.110.54.54] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

printf(pippo) dia come risultato ""
grazie!
"Luc" <XXX...@katamail.comXXX> wrote in message
news:MPG.1641ffd4b...@news.enter.it...


 grazie!
Come ti e' gia stato detto:   pippo[0] = 0;
Che ne diresti invece di usare array di char una
bella std::string ?
PS. Che ne diresti anche di quotare bene ? (Le risposte
      devi metterle alla fine della domanda non prima).
Ciao
Gaetano.
-- 
Posted from 
dell-01.mm.eutelsat.org
 [194.214.173.17] 


 printf(pippo)
???
Non è mica Basic!
-- 
Luc.

 printf(pippo) dia come risultato ""
*Mai* usare printf() in questo modo.
Max


 Mai usare printf() in questo modo.
visto che siamo in i.c.l.c++ e' d'obbligo suggerire di usare iostream
-- 
):E...

 printf(pippo) dia come risultato ""
Quella che tu chiami stringa è in realtà un array di char; questo
significa che una volta fatta la dichiarazione, i singoli elementi
dell'array contengono comunque qualcosa. Comunque, per usarla a mò di
stringa, devi sapere che funzioni quali printf() leggono i singoli
elementi dell'array fino a che non trovano il carattere '\0', per cui
per fare quello che hai chiesto, è sufficiente porre pippo[0]='\0', come
ti hanno già consigliato.
Ciao,
Cecco
PS: la sintassi corretta è printf("%s", pippo); comunque è una funzione
derivata dal C, meglio usare std::cout (#include <iostream>).
PPS: la libreria standard del C++ fornisce anche le std::string
(#include <string>), con cui quoi fare molte cose belline, tipo:
std::string str1="Hello", str2=" World!", str3 = (str1 + str2 + '\n');
e le due stringhe vengono direttamente concatenate, senza bisogno di
dover usare strcat etcc...

   delete szPippo;
Undefined behavior.  *DEVE* essere delete [] szPippo.
Tre errori (di cui uno gravissimo) in poche righe; complimenti!
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy            
lor...@pd.infn.it

 
[FLAME ON]
E perchč mai? Io e i miei colleghi programmatori C++ usiamo tutti la 
printf() e derivati... Gli streams sono deprecati (e meno potenti nella 
nostra implementazione del compilatore). 8)
-- 
Luc.

 printf() e derivati...
Scrivendo printf(array)?  Non ti pare che abbiano dimenticato il
formato?  E' appunto a questo che "Mai ... in questo modo" si
riferisce (spero :-)


 riferisce (spero :-)
Nooooo! Intendeva che dovevamo suggerirgli di usare cout e compagnia 
bella al posto di printf() (usata correttamente)...
8)
-- 
Luc.

 riferisce (spero :-)
Anche se personalmente non vedo il problema ad usare printf in questo
modo.
printf("Hello, World!\n");
non e' diverso da scrivere:
char hello_world[] = "Hello, World!\n";
printf(hello_world);
Il formato e' una stringa, e non e' necessario ne che contenga la
specifica di altri argomenti, ne che sia un "literal".
Ciao,
Nicola


No. Intendevo esattamente quello che ha capito Maurizio. Chiedo scusa
(soprattutto all'OP), avrei dovuto essere meno laconico.
Max

 printf("Hello, World!\n");
Non č meglio usare allora puts() ?
-- 
Luc.


Boh, io comunque mi sono abituato ad usare iostream.
Ciao,
Nicola

 printf(hello_world);
Il problema si pone se la variabile hello_world puo` essere modificata
cosi` da diventare qualcosa tipo "%d" a questo punto printf si aspetta
di ricevere qualcosa sullo stack che non e` stato messo...
ciao
Massimo

   szPippo = NULL;
Non capisco perche' usate NULL mi date un buon motivo?
[FLAME OFF]
Ciao
Gaetano.
-- 
Posted from 
dell-01.mm.eutelsat.org
 [194.214.173.17] 


 Non capisco perche' usate NULL mi date un buon motivo?
[FLAME ON]
Probabilmente lo stesso della notazione polacca o ungherese che dir si 
voglia
[FLAME OFF]


non mi hai convinto.


 Non capisco perche' usate NULL mi date un buon motivo?
Perche' l' ho usato per 15 anni, perche' il mitico compilatore standard non 
c'e' ancora, perche' in tutti i compilatori che ho usato era cmq 
transparente usare 0 o NULL. Perche' e' piu' leggibile, perche' i tuoi 
colleghi ci capiscono qualcosa, perche' non a tutti gliene frega di essere 
il programmatore perfetto, soprattutto quando devi fare a botte con 
specifiche di progetto e di compilatore soprattutto...
Ne ho scritte piu' di una :-)
-- 
- Dado : Extreme Snowboarder
*-> I believe I can fly, I believe I can touch the sky <-*

 Non capisco perche' usate NULL mi date un buon motivo?
E' sicuramente molto più leggibile quando si tratta di puntatori. 
Ovviamente non si usa con int, long e company...
-- 
Luc.

 Non capisco perche' usate NULL mi date un buon motivo?
Nei primi compilatori C++ effettivamente NULL dava problemi; la
definizione 'normale' del C era infatti "(void *) 0", ed il C++
standard da' errore se si cerca di convertire implicitamente un (void
*) in un altro tipo di pointer.  Per questo motivo gli old-timers del
C++ scrivono semplicemente un "unadorned 0" ed arricciano il naso
quendo vedono un NULL...
Negli include files moderni viene testato __cplusplus, e NULL definito
in conseguenza come "(void *) 0" oppure come "0" a seconda del
linguaggio; per questo motivo la cosa non e' piu' influente.  Si
tratta di preferenze personali, magari giustificate da "usando NULL
indico chiaramente che questo e' un pointer" (non condivido; se uno e'
un buon programmatore capisce subito che quello e' un pointer).


 un buon programmatore capisce subito che quello e' un pointer).
E' più veloce leggerlo che capirlo quando lavori...
-- 
Luc.

 voglia
Attento che la notazione polacca e' un'altra cosa: e' quella che
rappresenta le espressioni anteponendo l'operatore ai suoi operandi, ad
es.
+ 3 4
Ciao,
Nicola

un buon programmatore capisce subito che quello e' un pointer).
Però se devi dare un'occhiata veloce a codice scritto da altri un NULL
lo vedi subito.
-- 
Marco Barisione (ICQ 84277092)

 un buon programmatore capisce subito che quello e' un pointer).
Esatto.  Poi mi spiegano come fanno a confondere un puntatore
da un non puntatore. 
:-?


 lo vedi subito.
Confermo al 1000%. 8)
-- 
Luc.

 Ne ho scritte piu' di una :-)
Anche io.



Verissimo. Poi caschi nell'esempio postato da Gaetano in un altro
subthread. Se scrivi 
f(0);
e' piu' improbabile che ti stupisca se viene chiamata f(int)
Ciao,
Nicola

 grazie ad una typedef
Non credo proprio!
--
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

 Anche io.
Anche io un' altra volta :-)


 specifiche di progetto e di compilatore soprattutto...
Inconsistente: nessuna delle due influisce sul problema.


"Luc" <XXX...@katamail.comXXX> wrote in message
news:MPG.16432853b...@news.enter.it...

Al contrario. In casi di overload lo è meno.


 puntatore ?
Il problema è proprio questo. Tu sei convinto che nella chiamata
f(0,NULL,0) sia contenuta l'informazione che il secondo parametro è un
puntatore. Non è assolutamente vero. Non è contenuta nessuna
informazione.
La chiamata che dice al lettore esattamente cosa sta accadendo è f( 0,
0, 0 ). Che significa "Chiama una funzione che prende tre parametri fra
quelle in overload sul nome f. In caso di overload resolution, per ogni
parametro, se esiste il tipo int dai preferenza a questo, altrimenti
resta ambigua. Ogni parametro, indipendentemente dal tipo, assume il
valore che assumerebbe se fosse una globale non esplicitamente
inizializzata".


 puntatore ?
I due esempi non hanno lo stesso peso. In quello presentato da Gaetano
l'illusione che NULL "sia" un puntatore maschera un baco. 
Tu invece presumi che il comportamento di una funzione sia piu'
comprensibile perche' nella sua *chiamata* c'e' un indicazione che uno
dei parametri e' un puntatore. Francamente penso che per sapere cosa fa
una funzione un programmatore farebbe meglio a come minimo leggersi il
relativo prototipo, possibilmente la documentazione e in ultima battuta
il codice.
La chiamata dice poco, e quel poco lo dice molto meglio se il nome della
funzione e' ben scelto, piuttosto che non usando NULL al posto di 0.
Ciao,
Nicola

 Inconsistente: nessuna delle due influisce sul problema.
Era per aggiungere qualcosa in fondo al messaggio :-)


 informazione.
Hm, partendo dal presupposto di definire NULL come void*0 proviamo a 
riscrivere il prototipo della funzione f con qualcosa del genere, anzi, 
scrivo un breve programmino :
#include <iostream>
#define NULL ((void*)0)
void f( int a, void* b, int c )
{
	std::cout << "f void*" << std::endl;
}
void f( int a, int b, int c )
{
	std::cout << "f int" << std::endl;
}
int main()
{
	f( 0, 0, 0);
	f( 0, NULL, 0);
}
Sull' output ottengo f int, f void*, come _io_ mi aspetterei, d'altro canto 
usando solo 0 senza cast mi rimane impossibile chiamare la f che accetta 
come secondo parametro un void*... 
O almeno non mi viene in mente qualche trick per farlo in questo momento :-)
Se per chiamare la f( int, void*, int ) devo cmq usare un cast a void* 
allora tanto vale usare la mia cara e vecchia e macro...
(Poi adesso non apriamo un altro discorso sui cast C e cast C++, non e' il 
contesto adatto :-) )


 macro :-)
Ehm si' era riferito ovviamente al #define NULL ((void*)0) :-)


 quanto leggo anche negli altri messaggi.
IMO per la leggibilità NULL è meno leggibile. Tutti gli esempi portati
si basano sul presupposto che NULL rispetto a 0 è meglio perchè indica
la presenza di un puntatore. Il problema è che NULL è un puntatore in C
ma non lo è in C++. Quindi ogni esempio in cui si usa NULL per segnalare
la presenza di un puntatore è un esempio che dimostra che NON bisogna
usare NULL perchè è fuorviante (da l'impressione di indicare qualche
cosa che in realtà non indica).


 allora tanto vale usare la mia cara e vecchia e macro...
Non so uale sia la tua cara vecchia macro. Ma se parli di NULL la macro
è cambiata e in C++ ha un significato diverso da quello che aveva in C.
Proprio per questo usarla in C++ è fuorviante (soprattutto per chi viene
dal C).


 contesto adatto :-) )
Me ne guarderei bene, ma che ne dici allora di usare:
const class  {
    public:
        template<class T>
        operator T*() const { return 0; }
        template<class C, class T>
        operator T C::*() const { return 0; }
    private:
        void operator&() const;
} NULL;
by:  Item[25] "Effective C++"


 null.
Intendi forse dire void?
Ciao,
Nicola

 by:  Item[25] "Effective C++"
Lo stavo proprio leggendo quell' item :-)
Non mi pare male, sempre meglio di scrivere 0 IMO.


 inizializzato con NULL e non con 0. Se programmi in C++ è vero il
Ok, dimmi allora come fai a chiamare la funzione con il parametro puntatore 
senza usare un cast qualsiasi ma solo con 0.


 cosa che in realtà non indica).
IMO invece usare NULL e' fuorviante solo in un caso molto particolare[1], 
che non capita tutti i giorni programmando, mentre e' meglio leggibile nel 
99% dei restanti casi[2].
[1]
foo( int )
foo( int* )
[2]
tutti gli altri casi in cui non hai overloading :-)


 senza usare un cast qualsiasi ma solo con 0.
Giriamo il problema. Con la tua definizione di NULL non puoi scrivere:
int *p=NULL;
ma devi scrivere:
int *p=(int*)NULL;
ti sembra intuitivo? A me pare di no. Ti serve sempre e comunque un cast
a meno che non stia chiamando una funzione che ha come parametro un
void*. Quindi di fatto hai peggiorato le cose. Inoltre, se proprio vuoi
un meccanismo migliore, ridefinisci NULL come template come ti è stato
suggerito in un altro post.


 Non mi pare male, sempre meglio di scrivere 0 IMO.
A proposito. A stretta norma di standard bisognerebbe fare cosě:
#undef NULL
#define NULL _NULL
const class  {
public:
    template<class T>
        operator T*() const { return 0; }
    template<class C, class T>
        operator T C::*() const { return 0; }
private:
    void operator&() const;
} _NULL;


 ti sembra intuitivo? A me pare di no. Ti serve sempre e comunque un cast
Uff... Cioe' cosi' non arriveremo mai ad una conclusione... Se ogni volta mi 
fai un esempio diverso... Ok, allora te ne faccio un altro ancora, cosi' 
allunghiamo sto thread all' infinito :-) Ah no, ora e' meglio andare a casa 
:-)
Il NULL con il template mi piace, ripeto, molto piu' che 0.



Per risolvere questo problema si può seguire il consiglio di
Scott Meyers:
const                              // this is a const object...
 class {
 public:
   template<class T>               // convertible to any type
     operator T*() const           // of null non-member
     { return 0; }                 // pointer...
   template<class C, class T>      // or any type of null
     operator T C::*() const       // member pointer...
     { return 0; }
 private:
   void operator&() const;         // whose address can't be
                                   // taken (see Item 27)...
 } NIHL = { };                     // and whose name is NULL
#include <iostream>
void f(int) { std::cout << "f(int)\n"; }
void f(int*) { std::cout << "f(int*)\n"; }
int main()
{
   f(NIHL);   // uso NIHL per non andare in conflitto con NULL
}
Nota: al BCC non piace la scrittura NIHL = { }, per risolvere
si deve togliere l'inizializzazione (anche se non è standard).
Saluti  Manlio Perillo

 [FLAME OFF]
-- 
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

 } _NULL;
A stretta norma di standard _NULL { };
(E un oggetto costante e deve essere inizializzato).
Ciao   Manlio Perillo

 Il NULL con il template mi piace, ripeto, molto piu' che 0.
Vediamo di capirci: il NULL con il template è valido. Ma devi
specificarlo tu perchè non c'è nessuna garanzia che la definizione del
compilatore sia fatta in questo modo. Se usi NULL senza fare la undefine
seguita da una define fatta da te, allora NULL devi consideraro come se
fosse definito 0 e l'informazione contenuta nella macro NULL è la stessa
contenuta nella costante 0. Se per te o per chi legge il tuo codice la
macto NULL ha un significato diverso dalla costante 0 allora l'uso di
NULL è deviante e quindi sconsigliato.
Proprio per questo io sconsiglio anche la macro NULL ridefinita come
template e consiglio, piuttosto, una nuova macro (per esempio NIL o Null
o NULL_PTR) in modo che sia chiaro anche a chi vede solo una parte del
codice contenete la macro senza aver analizzato gli header o la "testa"
dei file C++ che quella macro non è (o meglio potrebbe non essere)
definita come 0 e pertanto è possibile che sia definita diversamente.
In altre parole:
1) se chi legge il codice viene dal C spesso presume che NULL sia un
puntatore, ma in C++ non lo è.
2) se chi legge il codice conosce bene il C++ allora presume che NULL
NON sia un puntatore ma una costante che rappresenta un puntatore nullo.
Quindi NULL viene interpretato in modo diverso da possibili lettori del
mio codice. Ergo per definizione è fuorviante e diminuisce la
leggibilità. Sia l'uso di 0 che l'uso di un template apposito (a me
piacciono i nomi ZERO per la macro definita come 0 e NIL per l'istanza
del template, ma questa è una questione di gusti) sono preferibili
all'uso di NULL per motivi di leggibilità.


 wrote in message
news:ksiC7.7604$74.1...@news2.tin.it...

Intendevi dire _NULL={}; suppongo. Ma č un oggetto globale e pertanto la
sua inizializzazione č sia garantita che ben specificata dallo standard
anche in assenza di un unizializzatore.


 si deve togliere l'inizializzazione (anche se non č standard).
Perchč? Non mi risulta che lo standard obblighi ad inizializzare le
costanti globali.


definita come 0 e pertanto č possibile che sia definita diversamente.
Non sarebe stato piů comodo avere una keyword nil?
-- 
Marco Barisione (ICQ 84277092)

 Non sarebe stato più comodo avere una keyword nil?
Sarebbe stato più comodo se lo standard diceva che NULL doveva essere
una costante convertibile in un puntatore nullo di qualunque genere ma
non convertibile in un intero, float o altro se non esplicitamente. Ma
non è così. Lo standard ammette esplicitamente che NULL sia 0 e che
quindi il tipo di NULL non è definito come puntatore.


 Ciao   Manlio Perillo
Saluti,
Fabio
-- 
Posted from 
flopiano.mm.eutelsat.org
 [194.214.173.28] 



Il DJGPP ed il Comeau (provato online) non lo compilano:
ci vuole l'initializer.
Ciao  Manlio Perillo

 e' piu' improbabile che ti stupisca se viene chiamata f(int)
qualcuno puo' spiegare ad un povero niubbo perche' per puntatore nullo e'
stato scelto lo 0, possibile fonte di incomprensioni? io vedo solo problemi
con questo "overloading dello 0" e nessun vantaggio! una keyword "null" era
cosi' improponibile? non capisco.... :-(((
--
Ciao by Allanon


Penso che abbiano ragione, perche' quella qua sopra puo' essere
interpretata sia come una dichiarazione che come una definizione, e lo
standard specifica che in questi casi si propende per la definizione.
L'inizializzazione esplicita serve a spezzare l'ambiguita'.
Ciao,
Nicola

 L'inizializzazione esplicita serve a spezzare l'ambiguita'.
Potresti spiegare meglio questa ambiguita' ?
come puo'
        struct S { } s;
generare ambiguita' tra definizione e dichiarazione ?



Non ho capito bene cosa intendi.
L'espressione di NIHL era chiaramente una definizione;
Andrea Ferro obiettava che per NIHL non occorresse l'initializer
essendo globale.
Ciao  Manlio Perillo