Newsgroup: it.comp.programmare.win32
Titolo: funzioni membro di tipo static

Ciao, utilizzo come compilatore il Visual C++ 6.0. All'interno del
programma ho creato una mia classe per interfacciare la seriale, qui
dentro c'e' una funzione membro che utilizzo per far continuamente
polling sulla seriale...
for (;;)
{
   // faccio continuamente polling per vedere se la seriale
   // ha dei problemi..
}
e quindi questa funzione dovra' essere implementata come thread: per far
si' che questa funzione membro possa essere utilizzata come thread ho
dovuto dichiararla static...
pero' all'interno di questa funzione richiamo altre funzioni della
classe, ad esempio la preparazione del pacchetto polling, il verificare
se una variabile booleana e' alzata ecc...
quando pero' vado a compilare ottengo una infinita' di errori perche' il
compilatore mi dice che le funzioni che utilizzo dentro questa funzione
devono essere anch'esse static, idem anche per le variabili...
e' normale che debba dichiarare tutte queste funzioni e variabili static
per poterle utilizzare all'interno della mia funzione che fa polling???
se si, cio' comporta qualcosa a livello di consumo di memoria???
l'applicativo girera' sotto una scheda PC104, sistema operativo WinCE e,
PURTROPPO, questa scheda ha solo 16MB di Ram!!!
ciao e grazie in anticipo!!!
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 PURTROPPO, questa scheda ha solo 16MB di Ram!!!
Si vede che non hai mai programmato negli anni 80...
8-)))
-- 
Luc.

 16MB di Ram!!! 
Con windows CE 16 MB di ram non sono poi così pochi (soprattutto se non 
hai da gestire la UI).
Tieni presente che un for(;;) che non contenga funzioni di attesa 
(WaitFor...) tiene sempre impegnata la CPU (rallentando quindi tutto il 
sistema) e non consente al sistema di attivare modalità di risparmio 
energetico (ovviamente questa utlima considerazione vale soprattutto 
per i sistemi che funzionano con batterie)
-- 
Valter Minute
vmi...@inwind.it
 (the reply address of this message is invalid)

 
Innanzitutto grazie dell'aiuto, pero' se alla funzione threadProc non
gli passo come argomento
LPVOID lpMIoArgomento, ho un errore di compilazione e mi dice che non
posso
creare un thread nella creaThread, se ci metto LPVOID... tutto va bene,
come posso risolverlo???
Se io dichiaro un puntatore nella dichiarazione della classe 
Serial *ptSerial e poi dentro la procedura provo a fare lpMIoArgomento =
ptSerial
mi da errore perche' mi dice che ptSerial non e' static...


 bene, come posso risolverlo???
In realtà un puntatore void* e un puntatore di tipo MiaClasse* occupano 
lo stesso spazio sullo stack (4 byte nel caso di programmi win32) e 
sono quindi "compatibili". Devi semplicemente esplicitare questa 
conversione con un cast.
Puoi convertire la funzione mettendo (LPTHREAD_START_ROUTINE) prima del 
suo nome nella chiamata a CreateThread oppure dichiare la funzione con 
il prototipo corretto (la thread proc deve sempre essere dichiarata 
WINAPI e con valore di ritorno DWORD o equivalente a 4 byte):
static DWORD WINAPI MiaClasse::ThreadProc(LPVOID lpParameter);
e convertire poi il puntatore:
MiaClasse* thisptr=(MiaClasse*)lpParameter;


 MiaClasse* thisptr=(MiaClasse*)lpParameter;
Ciao Valter, ho seguito il tuo primo consiglio, ovvero quello di fare un
casting
(LPTHREAD_START_ROUTINE) davanti alla chiamata, dentro CreateThread,
alla mia funzione.
io dentro la funzione ThreadProc scrivo:
miaclasse->bSemaphore = TRUE;
poi dentro una dialog scrivo:
classe miaclasse
miaclasse.CreaThread() e qui mi accende la booleana bSemaphore
ma poi quando vado a scrivere
if(miaclasse.bSemaphore == TRUE)
questa condizione risulkta sempre FALSE
non e' che io modifico la bSemaphore dentro threadProc che e' static e
viene utilizzata
come thread e quindi mi scrive nel suo stack e quindi nessuno sa che li
bSemaphore e' stata modificata???
ciao e grazie in anticipo...


 
Probabilmente c'č qualche errore nel tuo codice che causa uno dei 
seguenti problemi:
- il thread non parte o si blocca prima di arrivare all'istruzione 
che cambia il valore del semaforo
- le variabili "miaclasse" del thread e della dialog fanno 
riferimento a due oggetti diversi.
Prova a levare tutto il codice non necessario (quello della dialog, 
ad esempio), verifica che il problema si verifichi anche in quelle 
condizioni "minimali" e, se questo succede, posta un esempio (max 50 
righe). Se invece il problema sparisce, prova a riaggiungere (o 
scommentare :)) poco a poco il codice che hai rimosso fino a che non 
individui con precisione le linee che sembrano causare questo 
comportamento anomalo.


 Valter Minute
Mi sorge un dubbio.
E' sicuro che la variabile semaforo sia accessibile da un thread o piuttosto
bisognerebbe fare un artificio del tipo che si fa con la parola chiave
"volatile" per variabili che vengono modificate da eventi esterni tipo per
esempio la routine di interrupt di una seriale?
Forse bisognerebbe inglobare la variabile semaforo all'interno di una classe
il cui unico oggetto (singleton) sia accessibile sia dal thread sia dalla
seriale.
Maurus

 che cambia il valore del semaforo
avevi ragione, come al solito, avevo sbagliato l'algoritmo e la
variabile veniva
abbassata in un punto del codice e quindi era sempre FALSE...
un'ultima cosa: io sto studiando il C++ sul libro del Lippman "C++ corso
di programmazione"
del 1996, lo conosci??? come ti sembra???
io il linguaggio C lo conosco quindi non ho molte difficolta' con i
puntatori,
i costrutti (che sono uguali a quelli del C++), che libro mi consigli???
vorrei, se lo sai, che mi consigliassi un libro "PESANTE", non m'importa
se le cose le capisco
alla seconda/terza lettura, l'importante che sia "impegnativo" e che
quindi possa servirmi
anche tra qualche anno.
tipo quello del Ritchie per quanto riguarda il C...
ciao e grazie di nuovo!!!


 
Effettivamente questo potrebbe essere un problema (soprattutto nella 
versione ottimizzata in release), non ci avevo pensato, grazie per 
l'osservazione (che spero abbia visto anche stefano).
Effettivamente č meglio utilizzare degli eventi per questo tipo di 
notifiche tra thread, in modo da poter usare WaitFor... invece che un 
loop sulla variabile.


 
Thinking in C++ di Bruce Eckel (lo puoi scaricare dal suo sito: 
www.eckelobjects.com
).



Ciao Stefano,
oltre all'ottimo libro di Eckel che ti ha consigliato Valter Minute io ti
avrei consigliato anche il Lippman-Lajoie che e' un mattoncino ed e' ottimo
per cominciare e va fino a un livello medio.
La cosa che ti consiglio caldamente e' di cercare l'ultima edizione
(dovrebbe essere la terza) e buttare via la tua edizione del 1996 che e'
decisamente vecchia e non standard e mancheranno migliaia di concetti nuovi
fra cui anche la STL.
Se poi vuoi un libro veramente pesante che anche fra vari anni potrai
utilizzare come riferimento allora ti prendi lo Stroustrup che e' l'ideatore
del C++ ed e' cio' che il Ritchie e' stato per il C, ma attenzione che
questo e' veramente un mattonone!
Poi ti consiglierei la triade di Scott Meyers "Effective C++", "More
Effective C++" ed "Effective STL".
Ed anche i libri di Herb Sutter e il bel libro di autori vari "C++ Faqs".
Evita i libri di Schildt, tutti.
Maurus

 loop sulla variabile.
il problema e' che il mio programma all'avvio, e per tutta la durata del
programma,
deve fare continuamente polling sulla seriale, cioe' deve continumente
sapere se funziona, poi se l'utente preme un qualsiasi pulsante allora 
si accende la variabile semaforo, il polling, che monitorizza
continuamente questa
variabile, vede che e' accesa e che quindi l'utente vuole mandare un
pacchetto
alla seriale e quindi lui non entra nel blocco delle istruzioni del
true, es..
for(;;)
{
   if (!bSEmaphore)
   {
       // polling
   }
}
trovo giuste le tue osservazioni ma non ho idea di come possa utiizzare
le funzioni di attesa WaitForSingleObject con l'oggetto Event, perche'
comunque
avro' sempre un thread (polling ) che lavorera' dall'inizio alla fine
del
programma, quando ne parte un'altro, lui si ferma momentaneamente...
da quello che ho capito della notifica tra glio oggetti Event
(CreateEvent)
non c'e' niente che possa fare al caso mio e quindi mi tocca gestire
questa
variabile semaforo...
ciao e grazie
