3. Warnungen bei impliziter Conversion

Warnungen bei impliziter Conversion

  • K

    Seit ich nen neuen Compiler hab, haut der mir ne Menge Warnungen um die Ohren:

    z.B. bei assert( pOrder)

    'akt::Order *': Variable wird auf booleschen Wert ('True' oder 'False') gesetzt (Auswirkungen auf Leistungsverhalten möglich)

    Das kann ich natürlich einfach umgehen indem ich assert( pOrder != NULL) schreibe. Ist das sauberer oder Schwachsinn?
    Prinzipiell möchte ich schon immer alle Warnungen kriegen.
    Ich frag mich, ob solche Warnungen (z.B. wenn ich ein time_t in ein integer umwandle etc.) überhaupt viel Sinn habennen Sinn haben oder ob ich sie besser gleich ausschalte.

    Eure Meinung?

    0
  • G

    kartoffelsack schrieb:

    Das kann ich natürlich einfach umgehen indem ich assert( pOrder != NULL) schreibe. Ist das sauberer oder Schwachsinn?

    Weder noch.

    kartoffelsack schrieb:

    Ich frag mich, ob solche Warnungen (z.B. wenn ich ein time_t in ein integer umwandle etc.) überhaupt viel Sinn habennen Sinn haben oder ob ich sie besser gleich ausschalte.

    Generell haben die meisten Warnungen ihren Sinn, lediglich einige weinige kann man in bestimmten Situationen vernachlässigen. Deshalb würde ich dir auch nicht empfehlen, sie grundsätzlich abzuschalten. Ich würde dann lieber eine entsprechende Schreibweise bevorzugen (wie bei deinem Beispiel mit pOrder != NULL), damit sich der Compiler beruhigt.

    0
  • A

    Ausschalten.

    0
  • V

    kartoffelsack schrieb:

    z.B. bei assert( pOrder)
    'akt::Order *': Variable wird auf booleschen Wert ('True' oder 'False') gesetzt (Auswirkungen auf Leistungsverhalten möglich)

    dein assert ist schlecht implementiert. also insofern schlecht, daß es nicht gut zum compiler passt.

    öffnte am besten die datei, wo das assert-makro definiert wurde, und ersetze bool(cond) durch !!(cond). falls da bool(cond) steht. oder mach was anderes, daß assert diese warnung nicht mehr wirft, aber trotzdem noch mit allen bedingungen geht, die man in einem if haben kann.

    0
  • K

    hm, wenn ich jetzt anfangen die assert zu ändern, dann nimmt das kein Ende.

    z.B. warnt er mich auch in der boost-Lib:

    ...\boost\date_time\time_system_counted.hpp

    warning C4244: 'Initialisierung': Konvertierung von 'boost::date_time::counted_time_rep<config>::int_type' in 'boost::date_time::gregorian_calendar_base<ymd_type_,date_int_type_>::date_int_type', möglicher Datenverlust

    0
  • V

    kartoffelsack schrieb:

    hm, wenn ich jetzt anfangen die assert zu ändern, dann nimmt das kein Ende.

    z.B. warnt er mich auch in der boost-Lib:

    ...\boost\date_time\time_system_counted.hpp

    warning C4244: 'Initialisierung': Konvertierung von 'boost::date_time::counted_time_rep<config>::int_type' in 'boost::date_time::gregorian_calendar_base<ymd_type_,date_int_type_>::date_int_type', möglicher Datenverlust

    wer erlaubt dir auch boost mit nem ms-compiler zu verwenden?
    dann mußte natürlich die warnung abschalten.
    bei boost geht das bestimmt recht zentral, indem du wo #pragma warning(disable,4244) oder so hinsschreibst.

    0
  • K

    wobei ich nachtragen muss:
    das ist garnicht das Standard-Assert sondern ein von mir implementiertes 🙂 Das kann ich natürlich auf jeden fall anpassen 😉

    0
  • K

    [quote]wer erlaubt dir auch boost mit nem ms-compiler zu verwenden?[\quote]

    Hatte gelesen der 7.1er wär sehr gut bezüglich Standardconformität 😞

    0
  • V

    [quote="kartoffelsack"]

    wer erlaubt dir auch boost mit nem ms-compiler zu verwenden?[\quote]
    Hatte gelesen der 7.1er wär sehr gut bezüglich Standardconformität 😞

    ja, ist er.
    und boost geht dadrauf ganz gut.
    aber offensichtlicg gibs es neben der korrektheit auch noch ne lästigkeit bezüglich mancher warnungen. also nix schlimmes.

    0
  • 7

    Ich habe ähnliche Situation auf Arbeit. Jedoch gibts da direkt nen Compile-Fehler (KAI C++ Compiler). Da hilft nur, konsequent assert( xyz != 0); zu schreiben.

    0
  • K

    bool(cond) durch !!(cond)

    Da krieg ich ne neue Warnung 😉
    Erst (!(!(cond))) schluckt er anstandslos.

    bei boost geht das bestimmt recht zentral, indem du wo #pragma warning(disable,4244) oder so hinsschreibst.

    jo, offensichtlich in der visualc.hpp.
    Nur ist die Warnung dann ja wohl auch in meinem Code ausgeschalten, sobald ich nen boost-Header verwende. Oder kann ich das auch irgendwo zentral wieder einschalten?

    Danke schonmal 🙂

    0
  • ?

    kartoffelsack schrieb:

    Nur ist die Warnung dann ja wohl auch in meinem Code ausgeschalten, sobald ich nen boost-Header verwende. Oder kann ich das auch irgendwo zentral wieder einschalten?

    nee, kannste nicht.
    aber die warnung ist verzichtbar.

    0
  • D
     

    #pragma warning(default: 4xxx)

    Reset warning behavior to its default value. This also has the effect of turning a specified warning on that is off by default. The warning will be generated at its default, documented, level.
    See Compiler Warnings That Are Off by Default for more information.

    oder um den alten Stand aufm internen Compilerstack zu speicher

    #pragma warning( push )

    und mit

    #pragma warning( pop )

    wieder zurückholen.

    Ich stell Warnlevel auf Stufe 4, am besten den Code so sauber schreiben, das er keine Warnungen erzeugt, z.B. immer schon darauf achten signed und unsigned nicht zu vermischen. In Spezialsituationen halt Warnung deaktivieren.

    MfG
    DDR-RAM

    0
Anmelden zum Antworten