Newsgroup: it.comp.lang.c++
Titolo: dubbio sulle stringhe

Stavo provando l'overloading:
#include <cstdio>
#include <cstdlib>
using namespace std;
void show(double x);
void show(int x);
void show(char *x);
void show(double x){
     printf("%lf\n",x);
}
void show(int x){
     printf("%d\n",x);
}
void show(char *x){
     printf("%s\n",x);
}
int main(int argc, char *argv[])
{
    show(35);
    show(35.7);
    show("ciao");  <--------
    system("PAUSE");
    return EXIT_SUCCESS;
}
ed ottengo:
35
35.700000
ciao
se cambio la linea con la freccia con:
show('ciao');
ottengo:
35
35.700000
1667850607
Perché? (uso dev-c++ ovvero mingw)
Ciao

 show('ciao');
Se ben ricordo con il singolo apice ' si indica il tipo char, non la
stringa.
Trattandosi poi di c++, io inizierei a vedere anche le std::string.
Ciao
  Andrea

 Perché? (uso dev-c++ ovvero mingw)
'ciao' č un intero scritto in base 256.
Altro modo per ottenere quel numero:
   char *c = "oaic";
   unsigned n = (unsigned&)*c;
Kiuhnm

 
Non portabile :-P
--
Roal Zanazzi

 'ciao' è un intero scritto in base 256.
:-0
Azz, mai vista questa rappresentazione 256esimale diretta.
Mi chiedo (e chiedo) un'altro aspetto di questo costrutto : come 
viene decisa la rappresentazione del suddetto dato, intesa nel 
senso di sizeof.
Il caso citato aveva 4 caratteri, quindi 4 byte, ed il numero 
rappresentato stava regolarmente in una normale "word" a 32 bit 
(che presumo unsigned ....).
Ma se si fosse usata l'espressione
show ('graerhlhessef');
avremmo ottenuto un overflow o un intero troncato (e di che 
lunghezza, poi, 32 o 64 bit, tipo long long o che altro) ?
Ciao
Soviet_Mario


 show ('graerhlhessef');
Prova...
Kiuhnm

 'ciao' è un intero scritto in base 256.
E' un intero, ma il suo valore dipende dall'implementazione:
"An ordinary character literal that contains more than one c-char is a
multicharacter literal. A multicharacter literal has type int and
implementation-defined value." [2.13.2(1)]
Ciao,
Nicola

 implementation-defined value." [2.13.2(1)]
Sarebbe interessante vedere il C99.
Kiuhnm

 implementation-defined value." [2.13.2(1)]
Ma chi ha scritto lo standard si voleva male o voleva male agli 
sviluppatori?
Oppure c'e' qualcosa di ovvio che mi sto perdendo?
Probabilmente questa implementation-defined feature puo' essere resa 
utile per UTF, ma se non ne e' assicurato nessun utilizzo tanto vale 
dichiararla illegale ed (eventualmente) accettare come estensioni 
non-standard i suoi utilizzi in implementazioni specifiche...
--*PaN!*, che a volte (troppo spesso) si stupisce dello standard.


"The value of an integer character constant containing more than one
character (e.g., 'ab'), or containing a character or escape sequence
that does not map to a single-byte execution character, is
implementation-defined." [6.4.4.4(10)]
Ciao,
Nicola


Considerato che i caratteri possono avere dimensione diversa (e valore
diverso!) in base alla piattaforma, che gli interi possono avere
dimensione diversa in base alla piattaforma, che i byte di un intero
possono essere disposti in ordine diverso a seconda della piattaforma,
non vedo cos'altro avrebbero potuto scrivere.
Avrebbero anche potuto scrivere che il modo di interpretare la sequenza
e' lo stesso, come ad esempio ha scritto Kiuhnm, ma dal momento che il
risultato puo' variare moltissimo non sarebbe servito a molto.
Ciao,
Nicola

 risultato puo' variare moltissimo non sarebbe servito a molto.
Tempo fa ho dovuto faticare moltissimo a eseguire un porting da Win32 a 
OSX e linux in cui le sezioni dei files erano tutte identificate da cose 
tipo:
#define CHUNK_SECTORS 'seid'
e poi sparso per il codice ovunque si trovavano cose del tipo:
if (ReadLong() == CHUNK_SECTORS)
Il mio consiglio e' di dimenticarsi che esistono sti multichar literals, 
tra l'altro a compilarli con dei gcc recenti danno anche un warning.
Bye,
  Gabry

 risultato puo' variare moltissimo non sarebbe servito a molto.
Pensavo ad una cosa del tipo "multicharacter literal are a complete 
nonsense, so you aren't allowed to use them".
Ai fini dello standard non sarebbe cambiato molto =)
--*PaN!*