[c++] variabile definita globalmente e API GlobaAlloc

[stefanoB]

sto facendo questa prova, che ne pensate:

è giusto assegnare ad variabile globale un char* di ritorno da una funzione (ossia ritorna un char* allocato con GlobalAlloc ed inizializzato leggendo la edit) e deallocarla al termine con GlobalFree???

sintetisso esemplificando:

premesso che i file1,file2,file3 sono in ordine di esecuzione/chiamata e che la lettura dei valori negli edit può avvenire
in ripetizione

file1.cpp

  char *testo;  	//variabile globale
  ...
  ...

file2.cpp

  extern char *testo;
  ...
  ...

  WM_COMMAND:
    testo=GetValue(hwnd,idctrl);

file3.cpp

  extern char *testo;
  ...
  ...
  
  WM_INITDIALOG:
     //operazioni con testo
     ...
     ...
     GlobalFree(testo);

file4.cpp // contiene la funzione richiamabile + volte

...
...
 
char *GetValue(HWND hwnd, int IDCtrl) {
   char* bufTxt=NULL;
   int lStr=GetWindowTextLength(GetDlgItem(hwnd,IDCtrl));
   if (lStr>0) {
	bufTxt = (char*)GlobalAlloc(GPTR,lStr+1);
	GetDlgItemText(hwnd,IDCtrl,bufTxt,lStr+1);
   }
   return bufTxt;
}
...
...

dubbi:
1) la funzione ritorna un char*, un punatore ad una stringa definto locale ma allocato nella heap quindi sopravvive
2) deallocare memoria in questo modo è corretto

da debug sembra tutto funzionare

[MItaly]

Tecnicamente non dovresti avere problemi, ma il come sempre questo metodo è piuttosto rischioso (ci si può facilmente dimenticare di deallocare la memoria); dato che stai lavorando in C++, perché non usi la classe string della STL? Ti eviteresti tutto questo genere di problemi:
file1.cpp

std::string testo;    //variabile globale

file2.cpp

  extern std::string testo;
  ...
  ...

  WM_COMMAND:
    testo=GetValue(hwnd,idctrl);

file3.cpp

  extern std::string testo;
  ...
  ...
  
  WM_INITDIALOG:
     //operazioni con testo
     ...
     ...
     //non c'è bisogno di liberare niente

file4.cpp

...
...
 
std::string GetValue(HWND hwnd, int IDCtrl) {
   char* bufTxt=NULL;
   std::string ret;
   int lStr=GetWindowTextLength(GetDlgItem(hwnd,IDCtrl));
   if (lStr>0) {
	bufTxt = (char*)GlobalAlloc(GPTR,lStr+1);
	GetDlgItemText(hwnd,IDCtrl,bufTxt,lStr+1);
        ret=bufText;
        GlobalFree(bufTxt);
   }
   return ret;
}

Un paio di appunti:

• usa Unicode (imposta il progetto per l'uso di Unicode e non usare char ma wchar_t, non string ma wstring);
• per il passaggio di dati al momento della creazione di un dialog non usare variabili globali, ma sfrutta piuttosto la funzione DialogBoxParam.

[shodan]

Credo che il quesito sia legato al problema dell'allocator su vista.

[MItaly]

Ossia?

[shodan]

Qui.
http://forum.html.it/forum/showthrea...readid=1251183

[stefanoB]

Originariamente inviato da MItaly [*]usa Unicode (imposta il progetto per l'uso di Unicode e non usare char ma wchar_t, non string ma wstring);[*]per il passaggio di dati al momento della creazione di un dialog non usare variabili globali, ma sfrutta piuttosto la funzione DialogBoxParam.[/list]

perchè impostare il progetto in Unicode??

perché non usi la classe string della STL? Ti eviteresti tutto questo genere di problemi

Perchè su Vista se ne faccio uso in modo pesante mi da problemi ... vedi il link

Credo che il quesito sia legato al problema dell'allocator su vista.

Non è lo stesso quesito, ma avere un funzione che ritorni i valori degli edit nelle dialog!

[MItaly]

Originariamente inviato da stefanoB
perchè impostare il progetto in Unicode??

Perché se non lo fai fin da subito potresti pentirtene dopo quando dovrai convertire tutto il progetto . In primo luogo usando Unicode puoi gestire tutti i caratteri possibili, per cui l'utente, se vorrà inserire caratteri "strani" non verrà deluso dal programma che visualizzerà al loro posto dei "?"; idem per i percorsi dei file: se il tuo programma non è Unicode non è in grado di accedere a percorsi che hanno caratteri non inclusi nel CP corrente. Inoltre le versioni NT di Windows (quindi anche XP e Vista) usano Unicode internamente, per cui quando chiami la versione ANSI di una qualunque API che lavora con il testo essa deve convertire la stringa in Unicode, passarla alla versione Unicode della API e riconvertire in ANSI l'eventuale risultato; lavorando direttamente in Unicode eviti tutti questi passaggi, ottenendo un incremento di prestazioni.

Perchè su Vista se ne faccio uso in modo pesante mi da problemi ... vedi il link

Ti ho risposto di là.

[stefanoB]

Originariamente inviato da MItaly
Perché se non lo fai fin da subito potresti pentirtene dopo quando dovrai convertire tutto il progetto . In primo luogo usando Unicode puoi gestire tutti i caratteri possibili, per cui l'utente, se vorrà inserire caratteri "strani" non verrà deluso dal programma che visualizzerà al loro posto dei "?"; idem per i percorsi dei file: se il tuo programma non è Unicode non è in grado di accedere a percorsi che hanno caratteri non inclusi nel CP corrente. Inoltre le versioni NT di Windows (quindi anche XP e Vista) usano Unicode internamente, per cui quando chiami la versione ANSI di una qualunque API che lavora con il testo essa deve convertire la stringa in Unicode, passarla alla versione Unicode della API e riconvertire in ANSI l'eventuale risultato; lavorando direttamente in Unicode eviti tutti questi passaggi, ottenendo un incremento di prestazioni.

Si quello che pensavo sapevo di NT ... quindi si possono spiegare alcuni comportamenti anomali anche se diversi però tra Xp e Vista;
ma in Win 2000 con Unicode ???

strategia di conversione del progetto e soprattutto portabilità tra i vari sistemi, dove posso documentarmi???

[MItaly]

Originariamente inviato da stefanoB
Si quello che pensavo sapevo di NT ... quindi si possono spiegare alcuni comportamenti anomali anche se diversi però tra Xp e Vista;
ma in Win 2000 con Unicode ???

La famiglia NT include anche lui:
Windows NT 3.1
Windows NT 3.51
Windows NT 4
Windows 2000 = Windows NT 5
Windows XP = Windows NT 5.1
Windows 2003 Server = Windows NT 5.2
Windows Vista = Windows NT 6
Windows 7 (nome commerciale ancora sconosciuto) = Windows NT 7

strategia di conversione del progetto e soprattutto portabilità tra i vari sistemi, dove posso documentarmi???

Sui sistemi NT non dovresti avere problemi di nessun genere, l'unico problema di portabilità si ha con i sistemi Windows di famiglia 9x (Windows 95, 98, ME), che non supportano nativamente Unicode e che internamente lavorano in ANSI. Se vuoi supportare entrambe le famiglie di sistemi operativi puoi usare il Microsoft Layer for Unicode su Windows 9x o usare i generic text mappings e compilare una versione ANSI e una Unicode della tua applicazione.

[stefanoB]

Originariamente inviato da MItaly
usa Unicode (imposta il progetto per l'uso di Unicode e non usare char ma wchar_t, non string ma wstring);

per impostare il progetto intedevi definire:

#if !defined( UNICODE )
  #define UNICODE
#endif

ho fatto alcune prove in Unicode senza però aver applicato la define:

wchar_t *txt;
wcscpy(txt,(const wchar_t*)"Titolo test: ");  //necessario cast
SetWindowText(hwnd,(LPCTSTR)txt);

mentre utilizzare la macro TEXT, che però non riesco ad includere winnt.h (ho questo messaggio #include expects "FILENAME" or <FILENAME>) eviterebbe il cast const wchar_t* ???

wcscpy(txt,(TEXT)"Titolo test: ");

l'equivalente di lstrcat(...) è:

wcscat(txt,(const wchar_t*)" unicode titole");
wcsncat(txt,(const wchar_t*)" unicode title",(wcslen((const wchar_t*)" unicode title")+1));

ma entrambi non aggiungono il testo

mentre provando anche wstring:

wstring tmp;
tmp=(const wchar_t*)"nuovo titolo test";  //necessario cast
	
wchar_t *x;  x=(wchar_t *)tmp.c_str();    //non avrei altro modo x convertire e castare

SetWindowText(hwnd,(LPCTSTR)x);

in queste prove c'è qualcosa di errato o di migliorabile??

mentre per la define devo ancora approfondire, suggerimenti??