3. Was haben die Warnungen eigentlich zu sagen?

Was haben die Warnungen eigentlich zu sagen?

  • V

    g:\entwicklung\visualc++\smartptr\main.cpp(34) : warning C4715: 'DynIntSize' : not all control paths return a value
    g:\entwicklung\visualc++\smartptr\main.cpp(63) : warning C4715: 'DynIntGet' : not all control paths return a value
    g:\entwicklung\visualc++\smartptr\integer.cpp(35) : warning C4715: 'Integer::Get' : not all control paths return a value

    Hier die Funktionen dazu:

    EXPORT int CALLBACK DynIntSize(int ID)
{
	T_INT tmp;
	vector<T_INT>::iterator pos;
	for(pos = VecInt.begin(); pos < VecInt.end(); pos++)
	{
		tmp = *pos;
		if(tmp.ID == ID)
		{
			return tmp.IntKlasse->Size();
		}
	}
}

EXPORT int CALLBACK DynIntGet(int ID, int Index)
{
	T_INT tmp;
	vector<T_INT>::iterator pos;
	for(pos = VecInt.begin(); pos < VecInt.end(); pos++)
	{
		tmp = *pos;
		if(tmp.ID == ID)
		{
			return tmp.IntKlasse->Get(Index);
		}
	}
}

int Integer::Get(int Index)
{
	a = 0;
	for(pos = IntVec.begin(); pos < IntVec.end(); pos++, a++)
	{
		if(a == (Index - 1))
		{
			return *pos;
		}
	}
}
    0
  • C

    Hallo,

    mit ein wenig Englisch kann man drauf kommen. Deine Funktionen liefern nur einen Return-Wert, wenn die If-Bedingung erfüllt ist. Du müsstest praktisch auch im Falle einer Nichterfüllung einen Wert zurückliefern.

    0
  • E

    Das von den Funktionen nicht immer ein Wert zurueckgeliefert wird:

    EXPORT int CALLBACK DynIntSize(int ID)
{
    T_INT tmp;
    vector<T_INT>::iterator pos;
    for(pos = VecInt.begin(); pos < VecInt.end(); pos++)
    {
        tmp = *pos;
        if(tmp.ID == ID)
        {
            return tmp.IntKlasse->Size();
        }
        else
        {
            return was_anderes;
        }
    }
}

EXPORT int CALLBACK DynIntGet(int ID, int Index)
{
    T_INT tmp;
    vector<T_INT>::iterator pos;
    for(pos = VecInt.begin(); pos < VecInt.end(); pos++)
    {
        tmp = *pos;
        if(tmp.ID == ID)
        {
            return tmp.IntKlasse->Get(Index);
        }
        else
        {
            return was_anderes;
        }
    }
}

int Integer::Get(int Index)
{
    a = 0;
    for(pos = IntVec.begin(); pos < IntVec.end(); pos++, a++)
    {
        if(a == (Index - 1))
        {
            return *pos;
        }
        else
        {
            return was_anderes;
        }

    }
}

    Gruß eXitus :xmas1: :xmas2:

    *edit: Mist, Carsten war schneller :edit*

    0
  • V

    Stimmt, jetzt fällst mir erst auf 😃
    Bloß was soll ich sonst noch zurückgeben?
    Denn aus dem Vector werden ja Integerwerte zurückgegeben, da kann ich ja schlecht 0 oder -1 zurückgeben, das könnte dann ja auch werte sein die im Vector stehen.

    0
  • O

    am ende wirfste ne exception, denn es scheint ja ein fehler zu sein, wenn er in der for-schleife nichts findet. obwohl...exceptions und dlls? wie is das damit?

    0
  • G

    ääh mal 'ne andere Frage, würde hier

    int Integer::Get(int Index)
{
    a = 0;
    for(pos = IntVec.begin(); pos < IntVec.end(); pos++, a++)
    {
        if(a == (Index - 1))
        {
            return *pos;
        }
        else
        {
            return was_anderes;
        }

    }
}

    nicht folgendes ausreichen

    int Integer::Get(int Index)
{
    assert(Index >= 1 && Index <= IntVec.size());
    return IntVec[Index - 1];
}
    0
  • C

    Hallo,

    das kommt ja immer drauf an, worum es geht. Zum Debuggen mag das ja ganz prima sein, nur wenn das Programm abbricht, wenn die Bedingung nicht erfüllt ist und der Endanwender nicht weiss warum, halte ich das zumindest für suboptimal.

    0
  • G

    Was meinst du mit "Bedingung"? Das was in assert steht? Ist doch vollkommen egal. :xmas2:
    Ich wollte nur sagen, dass eine entsprechende Behandlung von falschen Werten für Index sinnvoll ist. Mir gings eigentlich um den den grundsätzlichen Algo, also

    int Integer::Get(int Index)
{
//    assert(Index >= 1 && Index <= IntVec.size());
    return IntVec[Index - 1];
}

    :xmas1:

    0
  • E

    Du könntest doch auch

    return NULL;

    machen oder? und das ganze dann so prüfen:

    if(Integer::Get(Index) != NULL)
{
    int a;
    a = Integer::Get(Index);
    //blablabla
}

    oder?? Denn soweit ich weis ist ja NULL und 0 nicht das gleiche... Berichtigt mich bitte

    @groovemaster: noch nicht ausprobieren *gg*

    Gruß eXitus :xmas1:

    *edit: kleiner Fehler aufgefallen bei der If bedingung :edit*

    0
  • D

    *berichtige* NULL und 0 ist genau das gleiche. In irgendeiner headerdatei steht nur drinne "#define NULL 0" bzw. so etwas ähnliches. 100% ist es das gleiche :xmas1: Null ist auch kein Schlüsselwort.

    0
  • G

    Delryn schrieb:

    *berichtige* NULL und 0 ist genau das gleiche. In irgendeiner headerdatei steht nur drinne "#define NULL 0" bzw. so etwas ähnliches.

    Das kommt immer darauf an, in welchem Kontext man dies betrachtet. Im Zeiger-Kontext evaluiert der integrale Ausdruck 0 zu einem Nullzeiger. Ein Nullzeiger muss aber nicht zwangsläufig auf die Adresse 0 (also auf Bitebene alles 0en) zeigen.

    0
  • E

    OK, achso, false kann er auch nicht zurückgeben, weil es dann ja in dem Fall, das gleiche wäre wie 0 oder eben NULL, da muss wohl eine andere Lösung her...

    Gruß eXitus :xmas1:

    0
  • V

    Hallo, hab es vorübergehend erst einmal so gelöst das 0 im Fehlerfall zurückgegeben wird. Sicher nicht die feine eglische Art, aber andere möglichkeiten seh ich im Moment nicht.

    0
  • S

    groovemaster schrieb:

    Das kommt immer darauf an, in welchem Kontext man dies betrachtet. Im Zeiger-Kontext evaluiert der integrale Ausdruck 0 zu einem Nullzeiger. Ein Nullzeiger muss aber nicht zwangsläufig auf die Adresse 0 (also auf Bitebene alles 0en) zeigen.

    Da NULL aber so aussieht:

    #define NULL 0

    Ist der Kontext ziemlich egal 😉

    Wobei ein

    int i=NULL;

    dennoch sehr falsch aussieht.

    Das mit dem "Zeiger Kontext" ist auch etwas verwirrend:

    void foo(int);
void foo(char*);

    Welche Funktion ruft

    foo(NULL);

    denn auf?

    0
  • A

    Hallo

    [quote="Shade Of Mine"]

    groovemaster schrieb:

    Das mit dem "Zeiger Kontext" ist auch etwas verwirrend:

    void foo(int);
void foo(char*);

    Welche Funktion ruft

    foo(NULL);

    denn auf?

    interessante Frage...
    also beim einfachem Testen wird immer die erste Funktion ausgeführt, egal ob char * oder int *.

    bis bald
    akari

    0
  • S

    akari schrieb:

    interessante Frage...
    also beim einfachem Testen wird immer die erste Funktion ausgeführt, egal ob char * oder int *.

    Ja, denn 0 ist ein int und kein Zeiger. Und NULL sieht zwar wie ein NULL-Zeiger aus, ist aber auch nur 0. Der Compiler sieht also nur eine 0, und die ist klar ein int und hat mit Zeigern nichts zu tun.

    Das ist übrigens ein Grund warum manche Leute eine null_ptr Klasse verwenden und es ein Proposal für den neuen C++ Standard für ein null Keyword gibt...

    NULL sollte man deshalb in C++ eigentlich nicht verwenden, weil es nur zu falschen Vermutungen verleitet. Denn ein foo(NULL); sieht nicht so aus, als wenn es die int Variante aufrufen würde (tut es aber) und das verwirrt.

    0
  • G

    Shade Of Mine schrieb:

    groovemaster schrieb:

    Das kommt immer darauf an, in welchem Kontext man dies betrachtet. Im Zeiger-Kontext evaluiert der integrale Ausdruck 0 zu einem Nullzeiger. Ein Nullzeiger muss aber nicht zwangsläufig auf die Adresse 0 (also auf Bitebene alles 0en) zeigen.

    Da NULL aber so aussieht:

    #define NULL 0

    Ist der Kontext ziemlich egal 😉

    Mit NULL bezog ich mich ja auch vielmehr auf 'Nullzeiger'. Dass C++ dafür momentan keine zufrieden stellende Lösung bietet, ist bekannt.
    Oder willst du etwa behaupten, dass hier

    int_ptr a = 0;
int* b = 0 // NULL;

    a und b auf allen Plattformen den gleichen Wert haben? (vorausgesetzt int_ptr ist ein Ganzzahltyp, der sizeof(int_ptr) == sizeof(int*) erfüllt)

    0
Anmelden zum Antworten