3. gängige Anfänger-Fehler?

gängige Anfänger-Fehler?

  • K

    C++Eus schrieb:

    Aber dabei handelt es sich doch um gültiges Standard-C++, oder? Da dürfte er doch keine Warnung ausgeben.

    int i =1;
//...
if(i = 5)

    Das ist auch Standard-C++, trotzdem ist der Compiler so nett und weist darauf hin, dass es vielleicht nicht so gewollt ist!

    [edit]hab die Quote-Tags korrigiert[/edit]

    0
  • M

    Bleibt c++eus noch zu sagen, dass ich schon vor ihm auf den Semikolon-hinter-for-Schleife-Fehler gekommen bin.

    0
  • R

    1. warnen darf ein Compiler so viel er will
    2. und der Zugriff auf nicht initialisierten Variablen ist `undefined behaviour` also nicht Standardkonform

    0
  • S

    c++eus schrieb:

    Aber dabei handelt es sich doch um gültiges Standard-C++, oder? Da dürfte er doch keine Warnung ausgeben.

    Warnen darf er doch soviel und so wenig wie er will. zB ist
    if(i=0)
    in den meisten Fällen nicht gewollt. Deshalb fragt mich mein Compiler immer ganz nett: 'Ausdruck ergibt immer 'false'. Hast du wirklich = gemeint und nicht ==?'

    Solche Warnungen sind nicht nur völlig OK, sondern verdammt nützlich.
    zB auch:
    while(1);
    {
    }

    da fragt er mich dann 'Ist dieses leere Statement beabsichtigt?'

    Einen Fehler darf er mir aber nicht anzeigen - aber warnen soviel er will.

    0
  • C

    KPC schrieb:

    C++Eus schrieb:

    Aber dabei handelt es sich doch um gültiges Standard-C++, oder? Da dürfte er doch keine Warnung ausgeben.

    int i =1;
//...
if(i = 5)

    Das ist auch Standard-C++, trotzdem ist der Compiler so nett und weist darauf hin, dass es vielleicht nicht so gewollt ist!

    Damit hast du natürlich Recht. Aber ich denke, wenn er bei einer Schleife eine Warnung ausgiebt, müsste dann nicht auch bei einer "normalen", lokalen (nicht initialisierten) Variable eine Warnung asusgeben?

    [edit]Quote-Tags korrigiert[/edit][edit="zeus"]Danke.[/edit]

    0
  • A

    immer, aber wirklich immer wieder gern gesehen:

    class foo
{
 private:
  TIrgendwas* Irgendwas;
 public:
 void Init()
  {
   if(Irgendwas)
     {
     // nun geht das Geheule los, warum Irgendwas immer true ist oder immer ungleich NULL
     }
  }
};
    0
  • C

    AndreasW schrieb:

    immer, aber wirklich immer wieder gern gesehen:

    class foo
{
 private:
  TIrgendwas* Irgendwas;
 public:
 void Init()
  {
   if(Irgendwas)
     {
     // nun geht das Geheule los, warum Irgendwas immer true ist oder immer ungleich NULL
     }
  }
};

    Das ganze kann man umgehen, wenn man im Konstruktor Irgendwas mit NULL initialisiert. 🙂
    Aber du spielst wohl eher die Sache mit dem Dereferenzierungsoperator an.

    0
  • A

    Ich mein es schon wie es da steht. Viele Anfänger initialisieren ihre Variablen nicht und wundern sich später. Auch zerstören sie Objekte gern mit delete und prüfen später den Pointer auf !=NULL. Natürlich wurde der Pointer nie auf NULL gesetzt, weshalb die Anfänger m it schöne Zugriffsverletzungen belohnt werden, wenn SIe sich dann in sicherheit wiegen und munter den Pointer benutzen wollen.

    0
  • W

    Zwei richtig miese Anfängerfehler sind folgende:

    1.)

    for(int i = 0; i <= count; ++i) // autsch Bereichsüberschreitung!
    array[i] = 0;

    2.)

    for(int i = 0; i < sizeof(array); ++i) // autsch, wenn sizeof(array[0]) > 1
    array[i] = 0;

    Auch immer wieder beliebt sind Präprozessorfehler:

    #define XYZ (var1-var2)
...
int XYZ = 0;

    #define MUL(a,b) a*b
...
int c = MUL(a+1,b+1); // wird zu a+1*b+1 also a+b+1
    0
  • R

    naja, ging wohl eigentlich nur um Fehler die der Compiler meldet. Naja, ein weiterer beliebter Fehler ist

    #define MAX(a,b) (a>b?a:b)
    0
  • C

    kingruedi schrieb:

    Naja, ein weiterer beliebter Fehler ist

    #define MAX(a,b) (a>b?a:b)

    wobei ein Anfänger wohl keine Makros benutzt (zumindest unter C++). Er wird wohl inline beforzugen, da man es im gewohnten FunktionsDesing verwenden kann.

    0
  • S

    kingruedi schrieb:

    naja, ging wohl eigentlich nur um Fehler die der Compiler meldet.

    Exakt. Ich suche primär Fehler die der Compiler meldet - aber nicht immer ganz klar. So kommt bei einem ; nach einer class definition 'sinnlose' Fehler, die ja nur indirekt mit dem ; zu tun haben.

    Genau sowas suche ich.

    Aber die anderen Fehler kann man in ein Kapitel 'Pitfalls' sicher auch recht gut einpacken 🙂

    Danke für eure Mühe und nur weiter so! 👍 👍

    0
  • A

    oder:

    template <class T> class foo
{
    public:
    foo();
}; 
foo::foo()
{
}

    11 C:\Dev-Cpp\main.cpp
    syntax error before `::' token

    wird auch gern genommen, genau wie die klassische Kombination von cpp-Dateien und templates. Aber das hat Shade bestimmt schon dabei...

    0
  • C

    Mir ist nochwas eingefallen:
    const-Zeiger und Zeiger auf const:

    char c = 'P';
const char* pc; //Zeiger auf const

char* const pc4 = &c; //constanter Zeiger

const char* const pc5 = &c; //constanter Zeiger auf const
    0
  • H

    Hallo,
    ein ganz simpler Fehler, der den VC 6 immerhin zu einem ICE bringt:

    class Foo
{
public:
	~Foo();
};

Foo::~Foo
{}

    Ein simpler "typename fehlt"-Fehler:

    template <class T>
struct Foo
{
	typedef T::Type Type;
};

    Und ein Fehler, der von kaum einem Compiler erkannt wird:

    template <class T>
struct Foo
{
	int i;
};

template <class U>
struct Bar : public Foo<U>
{
	void func()
	{
		i = 22;
	}
};
    0
  • ?

    @hume: kannst du das erste mal beschreiben? und was ist ein ICE?

    0
  • ?

    ach bestimmt ein internal compiler error. aber warum? sehe den fehler nicht. 😞

    0
  • H

    sehe den fehler nicht

    Es fehlt die, in diesem Fall leere, Parameterliste.

    // so ist's richtig
Foo::~Foo()
{}
    0
  • S

    HumeSikkins schrieb:

    Und ein Fehler, der von kaum einem Compiler erkannt wird:

    template <class T>
struct Foo
{
	int i;
};

template <class U>
struct Bar : public Foo<U>
{
	void func()
	{
		i = 22;
	}
};

    um ehrlich zu sein, habe ich den Sinn auch nie verstanden... da i nicht in Bar enthalten ist, müsste er IMHO als nächstes in Foo<U> suchen. Was viele Compiler auch so machen. Du weisst nicht zufällig warum man hier this->i stattdessen schreiben muss?

    0
  • H

    Du weisst nicht zufällig warum man hier this->i stattdessen schreiben muss?

    Ich wäre ein Gugelhupf, wenn ich den Ursprung eines mir bekannten Fehlers ignorieren würde 🙂

    Die Antwort findest du in 14.6.2.8:

    in the definition of a class template [...], if a base class of this template depends on a template parameter, the base class scope is not examined during name lookup until the class is instantiated.

    Der base class scope wird also schon mal nicht berücksichtigt. Da i nun aber kein abhängiger Name ist, wird die Gültigkeit von i bereits in der ersten Phase der Templateprüfung getestet. Es gibt hier kein bekanntes i -> Fehler.

    Durch die Qualifizierung mit this-> oder Foo<U>:: wird i ein abhängiger Name und erst bei der Instanziierung des Templates geprüft -> Kein Problem.

    Nötig ist das Ganze um spätere explizite oder partielle Spezialisierungen der Basisklasse unterstützen zu können.

    Ich habe dazu am 9.5.2002 schon mal einen ewig langen Beitrag geschrieben, dessen Wiederholung hier aber nicht lohnt 😉

    0
Anmelden zum Antworten