boost::unused



  • Warum macht man dann nicht einfach:

    void funktion(int)
    {
    }
    

    ???




  • Administrator

    Edit: Hier stand Unsinn, habe was falsch gelesen ... schon gewundert, was diese Frage sollte. 😃

    Ich frage ich mich, was dagegen spricht, die Variable auszukommentieren. Ist auch für den Leser gleich klar, dass diese Variable nicht benutzt wird. Wieso so ein Hilfskonstrukt? Ist doch unnötig.

    Grüssli



  • Sehe ich gleich, wie Dravere. Die Warning ist berechtig und nützlich. (Ich lasse eine solche Warning gerne mal stehen, wenn ich gerade was am rumbasteln bin, damit ich dann auch ja nicht vergesse die wieder aktivieren).



  • Ich frage mich auch, weshalb man überhaupt benannte Variablen einführt, wenn man sie nicht benutzt. Was spricht gegen CSpilles Vorschlag

    void funktion(int)
    {
        // ..
    }
    

    ? Oder noch schlimmer, geht es gar nicht um Parameter?



  • so in etwa:

    if(! user_have_input_in_textfile)
    {  //no delete for this:
       std::ifstream* cin = new std::ifstream(input_file.c_str());
       deflecter_t<char>* deflecter = new deflecter_t<char>(std::cin, *cin);
    }
    

    deflecter funktioniert wie eine pipe.
    also wird die gesamte Eingabe statt aus std::cin aus dem file gelesen.
    allerdings kann es ja sein, dass der User das nicht möchte (weil er die Daten per Hand eingeben möchte bzw kein input-file hat)...

    Warum er hier warnt, sollte klar sein...
    Das delete fehlt mit Absicht - auch, wenn es sein kann, dass er zu erst den ifstream-dtor und dann den deflecter-dtor aufruft, das stört aber nicht weiter - steht explizit in der doku.

    die Alternative wäre vermutlich

    if(! user_have_input_in_textfile)
    {  //no delete for this:
       std::ifstream* cin = new std::ifstream(input_file.c_str());
       new deflecter_t<char>(std::cin, *cin);
    }
    

    ist aber nicht wirklich hübscher... Was also spricht gegen ein unused(deflecter) am Ende?

    bb



  • Du erzeugst absichtlich Memory Leaks? Der Destruktor von deflecter wir nie aufgerufen und der Speicher nie freigegeben.

    Wenn du keine Variable für das Objekt benötigst, dann nimm keine. So einfach ist das.



  • Nexus schrieb:

    Du erzeugst absichtlich Memory Leaks? Der Destruktor von deflecter wir nie aufgerufen und der Speicher nie freigegeben.

    Japp - ich kenn kein OS, was den Speicher nach Programmende nicht wieder freigibt - wenns welche gibt, dann sicherlich keine, wo das Programm laufen sollte...

    Wenn du keine Variable für das Objekt benötigst, dann nimm keine. So einfach ist das.

    irgendwo im Quelltext new deflecter_t<char>(std::cin, *cin); ohne Zuweisung / Initialisierung stehen zu haben, finde ich aber noch hässlicher - und da ist mein Chef ausnahmsweise mal meiner Meinung

    Naja - wenn hier niemand jemals was von boost unused gehört hat, dann werd ich mir wohl selbst die 3 Zeilen schreiben...

    oder hat wer noch nen anderen Vorschlag? (außer den ptr in der ganzen main-fkt bekannt zu machen und dann am Ende zu deleten (ansonsten auf NULL/0/nullptr setzen, wenn nicht benötigt) - bzw gleich so was wie scoped_ptr zu nutzen...)

    danke...



  • btw: es war ignore_unused_variable_warning

    hier gibts nen artikel dazu: http://herbsutter.com/2009/10/18/mailbag-shutting-up-compiler-warnings/

    und hier der boost-header
    -> http://www.boost.org/doc/libs/1_37_0/boost/concept_check.hpp
    geschätzt auf Zeile 30

    hab mich also doch nicht geirrt 😛

    ciao



  • Es gibt schon Fälle wo man sowas braucht.
    Klar lässt man Namen für unbenutzte Parameter einfach weg. Nur manchmal...

    void foo()
    {
        int n = do_stuff();
    #ifdef DEBUG
        do_some_heavy_lifting_to_assert_that_n_meets_some_condition(n);
    #endif
    }
    

    IMO ist da einfach die "schönste" Variante

    void foo()
    {
        int n = do_stuff();
    #ifdef DEBUG
        do_some_heavy_lifting_to_assert_that_n_meets_some_condition(n);
    #else
        unused_variable(n);
    #endif
    }
    

    Wenn jmd. eine schönere weiss, immer her damit.
    (BTW: das Beispiel ist nicht konstruiert, solcherlei ist mit schon öfters untergekommen)


Anmelden zum Antworten