Newsgroup: it.comp.lang.c++
Titolo: const char *p = "ciao" "mamma";

Ma davvero questa linea di codice e' corretta? (tra i due doppi apici c'e' 
uno spazio)
Il VC++ 6.0 non segnala Ne errore e NE warning.
Mi sono perso qualcosa? 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

No, è tutto giusto. Due stringhe in stile C messe in fila vengono
semplicemente unite automaticamente dal compilatore.
Ciao,
- -Federico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with SUSE - 
http://enigmail.mozdev.org
iD8DBQFIbKOFBIpu+y7DlLcRAr+/AJ4tC6MFc9+wojCWBrvq3oYcbMNrpACcCF8r
Y/WApGUqcXqnW7crQXDhHZw=
=65+K
-----END PGP SIGNATURE-----

GuGu ha scritto:

secondo me il warn potrebbe essere per una ragione : non 
solo l'area di memoria è const (perché i literals sono 
considerati const e non scrivibili), ma siccome un literal è 
anche situato ad un indirizzo const, imho dovresti 
dichiarare const anche il puntatore (viceversa stai facendo 
un const_cast implicito, dal valore rightmost al leftmost).
Cioè, dovrebbe essere corretto dire
const char * const p = "ciao" "mamma";
oppure
const char * p const = "ciao" "mamma";
(preferisco la prima sintassi, la seconda mi sembra irregolare)
ciao
Soviet

 (preferisco la prima sintassi, la seconda mi sembra irregolare)
Perche` devi rendere const il puntatore?
Non ci vedo nulla di male a voler fare p++ per farlo puntare a "iaomamma".
E meno male che non da warning, ho sparso praticamente in tutti i miei 
programmi l'uso delle stringhe concatenate fin dai tempi dell'amiga e 
del lattice C :)
Classico esempio:
printf("uso: %s [-abcd] file\n"
        "-a blablabla\n"
        "-b blablabla\n"
        "-c blablabla\n"
        "-d blablabla\n", argv[0]);
Bye,
  Gabry

 semplicemente unite automaticamente dal compilatore.
Non si finisce mai di imparare...
Pero' e' una situazione che puo' generare un errore insidioso che mi e' 
capitato.
    void foofunc  (const char * p1, const char * p2 = NULL);
Dove ovviamente ho sbagliato e invece di scrivere:
    foofunc  ("a", "b");
Mi e' scappato un:
    foofunc  ("a" "b");
Non sarebbe corretto che il compilatore prevedesse un'opzione per segnalare 
un warning?
Un po' come avviene per
    if (a = b)

 del lattice C :)
concatenare stringhe infatti è legale, non penso che possa 
dare warning in tal senso.
Boh, cmq se avete idee migliori per giustificare il warn ... 
sentiamole :-)
ciao
Soviet


 cioč rimuove la constness dell'indirizzo di destra.
No, ti stai proprio sbagliando. La constness a destra riguarda solo il
contenuto del letterale (che č un array di char e puņ essere convertito in
un puntatore). L'indirizzo dell'array non č un l-value; pertanto non ha
alcun senso parlare di constness. La nostra variabile 'p' riceve una copia
di questo indirizzo e non entra in gioco nessun tipo di const_cast.
Max

un warning?
No. Sarebbe invece corretto che un programmatore facesse i test ;-)

anche situato ad un indirizzo const, 
Il warning lui non ce l'ha, e per una buona ragione: quella scrittura
è legale. La variabile puntatore che punta al literal non deve
necessariamente essere costante, non c'è ragione.
Vorrei comunque sottolineare che in programmazione bisogna imparare,
una buona volta, a costruire i casi di test. Non bisogna affidarsi
solo ai messaggi del compilatore - che ha un potere alquanto limitato.

GuGu ha scritto:

2 accenti :-P
ciao:)

> No. Sarebbe invece corretto che un programmatore facesse i test ;-)
:-P ...e che il tuo capo di desse  tempo di farli... 

 2 accenti :-P
Ma no, NE sta per Nord Est....

 No. Sarebbe invece corretto che un programmatore facesse i test ;-)
Quoto.
-- 
-riko

 :-P ...e che il tuo capo di desse  tempo di farli... 
Rimane un po' il mito secondo cui tagliare il tempo di sviluppo e
moltiplicare il già grosso tempo speso in debugging (senza poi parlare
della manutenzione) sia di qualche vantaggio.
-- 
-riko

:-P ...e che il tuo capo di desse  tempo di farli... 
Nel caso non ti dia il tempo di farli, c'è qualche problema. Almeno,
il capo ha qualche problema. Non sarebbe una novità. Sto appunto
leggendo "Il principio di Peter", che afferma che ognuno appartenga ad
una gerarchia tende a raggiungere il suo livello di incompetenza e lì
a fermarsi :-)
So bene che, in molti casi, si fissa una dead-line e ti si chiede di
starci dentro, anziché procedere per via contraria, però è anche
importante tentare di impostare una metodologia corretta nel lavoro.
Un capo di un gruppo di programmatori dovrebbe ben sapere (o perlomeno
rendersi facilmente conto) che il tempo speso a testare il codice è
tempo ben speso. Io sto impiegando moltissime energie per cercar di
convincere un cliente della mia azienda che è importante, da loro,
mettere in piedi un settore di programmatori che si occupino SOLO di
test. E' molto difficile riuscire nell'impresa, ma spero di farcela.
Basta d'altronde vedere che cosa accade in grandi aziende del calibro
di Microsoft, in cui esiste lo SDE (Software Design Engineer) e lo
SDET (Software Design Engineer in Test). Lo so perché ho avuto un
colloquio per entrambi i ruoli con loro a Copenhagen il 25 aprile
scorso :-)
Ti dico tutto questo, perché il tempo che hai speso nello scoprire il
malfunzionamento, scrivere un messaggio al gruppo e reclamare warning
da parte del compilatore, l'avresti potuto risparmiare con una buona
suite di test (il tuo è un caso semplicissimo e "sgamabile" al volo da
un test). E sarebbe andato tutto a vantaggio del tuo lavoro.
Senza considerare i problemi di portabilità: un warning nel tuo
specifico compilatore non implica lo stesso warning su un altro
compilatore, magari più permissivo.
Molti linguaggi a tipizzazione non forte come quella del C++ o del
Pascal hanno avuto successo anche grazie al fatto che i test sono di
gran lunga il metodo più efficace per scovare errori nel codice.
Una buona suite di test va molto oltre i normali warning del
compilatore (che per definizione ha un potere molto limitato nello
scovare errori di logica applicativa).