Pagina 1 di 3 1 2 3 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 23
  1. #1

    [C++] uscita morbida da programma

    Salve,

    ho il seguente codice:

    Codice PHP:
    #include <stdexcept>
    (...)
    hDLL LoadLibrary(szDllPath);
    if (
    NULL == hDLL)
    {
        throw 
    std::runtime_error("Unable to get LAME interfaces");
        exit(
    EXIT_FAILURE);

    che è inserito all'interno di un costruttore di una classe. Ora vorrei che se la dll non viene caricata venga mandato un messaggio all'utente e poi una uscita morbida da tutto il programma. Sapevo che se usavo std::runtime_error mi avrebbe inoltre fatto da garbage collector...

    Tuttavia con il codice sopra postato (e l'errore da me forzato) mi viene fuori una unhandle exception (leave)

    non va bene la exit?

    grazie
    Alla batteria dai retta ballA

  2. #2
    che sciocco! è la throw std::runtime_error che ritorna l'unhanlde exception...
    Alla batteria dai retta ballA

  3. #3
    La exit non viene mai raggiunta, visto che viene sollevata l'eccezione prima. Nel main imposta un blocco try...catch principale in cui andrai a raccogliere tutte le eccezioni di tipo std::exception; nel gestore limitati a mostrare tramite cerr l'errore che si è verificato ed esci.
    codice:
    int main()
    {
        try
        {
            /* tutto il tuo codice, meglio se sta in un'altra funzione che qui ti limiti a chiamare */
        }
        catch (std::exception & ex)
        {
            cerr<<"Si è verificato un errore: "<<ex.what()<<endl;
            return EXIT_FAILURE;
        }
        return EXIT_SUCCESS;
    }
    Amaro C++, il gusto pieno dell'undefined behavior.

  4. #4
    Utente di HTML.it L'avatar di shodan
    Registrato dal
    Jun 2001
    Messaggi
    2,381
    Sapevo che se usavo std::runtime_error mi avrebbe inoltre fatto da garbage collector...
    Le eccezioni non fanno mai da garbage collector; sono i distruttori delle classi a provvedere alle risorse (sempre che non venga invocata una exit o una abort, nel qual caso il programma termina seduta stante e il sistema operativo recupera tutto).
    This code and information is provided "as is" without warranty of any kind, either expressed
    or implied, including but not limited to the implied warranties of merchantability and/or
    fitness for a particular purpose.

  5. #5
    Originariamente inviato da shodan
    (sempre che non venga invocata una exit o una abort, nel qual caso il programma termina seduta stante e il sistema operativo recupera tutto).
    anche nel caso le variaibli siano "dinamiche" puntatori?

  6. #6
    Utente di HTML.it L'avatar di XWolverineX
    Registrato dal
    Aug 2005
    residenza
    Prague
    Messaggi
    2,565
    Originariamente inviato da xnavigator
    anche nel caso le variaibli siano "dinamiche" puntatori?
    In ogni caso quando il tuo software viene chiuso viene rialsciata tutta la sua memoria quindi si.


    Ti prego,non usare le eccezioni!
    "Se proprio devono piratare, almeno piratino il nostro." (Bill Gates)

    "Non è possibile che 2 istituzioni statali mi mettano esami nello stesso giorno." (XWolverineX)

    http://xvincentx.netsons.org/programBlog

  7. #7
    Originariamente inviato da XWolverineX
    In ogni caso quando il tuo software viene chiuso viene rialsciata tutta la sua memoria quindi si.
    Resta comunque il fatto che è buona pratica strutturare il codice in maniera che rilasci tutto correttamente al momento dell'unwinding dello stack.
    Ti prego,non usare le eccezioni!
    Perché mai? Abbinate alla semantica RAII sono formidabili...
    Amaro C++, il gusto pieno dell'undefined behavior.

  8. #8
    Originariamente inviato da XWolverineX
    In ogni caso quando il tuo software viene chiuso viene rialsciata tutta la sua memoria quindi si.


    Ti prego,non usare le eccezioni!
    O.O

    e allora che dobbiamo scrivere a fare alla fine del main tutte le delete; OOOOO

  9. #9
    Risposta breve: perché se no i gattini piangono.
    Risposta lunga: perché è comunque buona pratica rilasciare correttamente tutte le risorse acquisite. Se poi quello che oggi è tutto il programma diventasse un pezzo di un programma più vasto, senza codice di cleanup si terrebbero impegnate per nulla delle risorse. Inoltre se una funzione alloca della memoria che non viene utilizzata ma non viene rilasciata quando non serve più (e quando non si hanno più puntatori ad essa) si hanno dei memory leaks: della memoria è allocata ma non è più accessibile né liberabile, il che si traduce in un'inutile occupazione di memoria e nella diminuzione delle prestazioni che ne consegue. Se poi si persegue in questo atteggiamento con risorse più limitate (handle kernel/GDI, file, risorse condivise, ...) si può andare incontro a problemi anche più gravi (file/risorse che rimangono bloccati inutilmente fino alla fine del programma, esaurimento degli handle GDI, ...).

    In ogni caso la risposta al problema di gestione delle risorse in C++ è l'idioma RAII, ossia Resource Acquisition Is Initialization; se impiegato correttamente nel tuo programma, hai la certezza che all'uscita di scope di una variabile che incapsula una risorsa (per causa di un'eccezione, per un return nella funzione, per una chiamata ad exit) la risorsa sarà rilasciata, dal momento che viene eseguito sicuramente* il distruttore dell'oggetto-risorsa.

    *=salvo casi davvero eccezionali, quali una chiamata ad abort, la terminazione dall'esterno del processo e (mi pare) eccezioni SEH di Windows non gestite.
    Amaro C++, il gusto pieno dell'undefined behavior.

  10. #10
    Originariamente inviato da MItaly
    Risposta breve: perché se no i gattini piangono.
    Risposta lunga: perché è comunque buona pratica rilasciare correttamente tutte le risorse acquisite. Se poi quello che oggi è tutto il programma diventasse un pezzo di un programma più vasto, senza codice di cleanup si terrebbero impegnate per nulla delle risorse. Inoltre se una funzione alloca della memoria che non viene utilizzata ma non viene rilasciata quando non serve più (e quando non si hanno più puntatori ad essa) si hanno dei memory leaks: della memoria è allocata ma non è più accessibile né liberabile, il che si traduce in un'inutile occupazione di memoria e nella diminuzione delle prestazioni che ne consegue. Se poi si persegue in questo atteggiamento con risorse più limitate (handle kernel/GDI, file, risorse condivise, ...) si può andare incontro a problemi anche più gravi (file/risorse che rimangono bloccati inutilmente fino alla fine del programma, esaurimento degli handle GDI, ...).

    In ogni caso la risposta al problema di gestione delle risorse in C++ è l'idioma RAII, ossia Resource Acquisition Is Initialization; se impiegato correttamente nel tuo programma, hai la certezza che all'uscita di scope di una variabile che incapsula una risorsa (per causa di un'eccezione, per un return nella funzione, per una chiamata ad exit) la risorsa sarà rilasciata, dal momento che viene eseguito sicuramente* il distruttore dell'oggetto-risorsa.

    *=salvo casi davvero eccezionali, quali una chiamata ad abort, la terminazione dall'esterno del processo e (mi pare) eccezioni SEH di Windows non gestite.
    capito... alla fine dipende dai casi.. se stai facendo il progettino di 3 righe per valorizzare un array, mettere le delete divente inutile...

    se invece si sta programmando qlc di più complicato/esteso vanno messe

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.