Compilerfehler: Expected initializer before "short"



  • Hallo,
    also danke für die schnelle Hilfe, nur jetzt hab ich schon ein neues Problem:
    Und zwar habe ich jetzt die Semikola gesetzt und die PW_Gen Funktion zum testen in der Main.cpp und Main.h auf den Rückgabetyp "void" abgeändert, sowie i und j vor den For-Schleifen definiert. Jetzt meldet mir der Compiler aber folgende Fehler:

    C:\Dateisammlung\Programmieren\C++\TestDLL\main.cpp||In function `void PW_Gen(short int)':|
    C:\Dateisammlung\Programmieren\C++\TestDLL\main.cpp|18|error: expected `)' before ';' token|
    C:\Dateisammlung\Programmieren\C++\TestDLL\main.cpp|18|warning: statement has no effect|
    C:\Dateisammlung\Programmieren\C++\TestDLL\main.cpp|18|error: expected `;' before ')' token|
    ||=== Build finished: 2 errors, 1 warnings ===|
    

    Also er will mir sagen, dass in Zeile 18 (da steht die "For-Kopfzeile") eine Klammer vorm Strichpunkt fehlt, irgendeine Angabe keinen Effekt hat, also sinnlos ist und dann das ein Strichpunkt vor einer Klammer fehlt. Nur was ist daran nicht korrekt?

    For(i=0;i<=PWLgt;++i)
    


  • Fast2 schrieb:

    Nur was ist daran nicht korrekt?

    For(i=0;i<=PWLgt;++i)
    

    Wie alle C++-Schlüsselworte wird auch for kleingeschrieben.



  • Das ging jetzt aber wirklich schnell 😉
    Jetzt muss ich aber meine subjektive Meinung miteinbringen und sagen, dass ich Großschreibung 1. lesbarer finde, und 2. Von anderen Sprachen keine Unterscheidung zwischen Groß-/Kleinschreibung gewohnt bin. Wahrscheinlich muss ich mich aber damit abfinden, oder gibt es ne Möglichkeit das umzuändern? *hoff*



  • Fast2 schrieb:

    Das ging jetzt aber wirklich schnell 😉
    Jetzt muss ich aber meine subjektive Meinung miteinbringen und sagen, dass ich Großschreibung 1. lesbarer finde, und 2. Von anderen Sprachen keine Unterscheidung zwischen Groß-/Kleinschreibung gewohnt bin. Wahrscheinlich muss ich mich aber damit abfinden, oder gibt es ne Möglichkeit das umzuändern? *hoff*

    Ich weiss jetzt nicht recht, ob ich dir die Möglichkeit zeigen soll.. 🙄

    Naja.. Du musst es wissen, aber ich rate dir ab:

    #define For for
    


  • Ich meinte jetzt irgendwelche Compilereinstellungen, welche mir Code::Blocks (standartmäßig) nicht zugänglich macht. Naja, alles mit define umzuändern, ob das Sinn macht...



  • Fast2 schrieb:

    Jetzt muss ich aber meine subjektive Meinung miteinbringen und sagen, dass ich Großschreibung 1. lesbarer finde

    Nun, bei Bezeichnern habe ich auch lieber CamelCase, aber das ist Geschmackssache. Brauchbare IDEs sollten auch Syntaxhighlighting unterstützen, sodass Schlüsselwörter z.B. blau und fett dargestellt werden.

    Fast2 schrieb:

    2. Von anderen Sprachen keine Unterscheidung zwischen Groß-/Kleinschreibung gewohnt bin.

    Wenn du so denkst, solltest du lieber nicht C++ lernen. Glaub mir, da kommt noch einiges auf dich zu, was du von anderen Sprachen nicht gewohnt bist.

    Fast2 schrieb:

    Naja, alles mit define umzuändern, ob das Sinn macht...

    Die Frage braucht dir wohl niemand zu beantworten.



  • Mit "ob es Sinn macht..." meinte ich ob es sehr Ressourcenfressend ist, oder ob es nur mehr Schreibaufwand ist, wobei ich gerade gelesen habe, dass das nur zweite stimmt (Sind ja nur Anweisungen für den Präprozessor 🙄 ). Wobei ich diese #difines ja auch in ne eigene Headerdatei packen kann. Also, ich wollte euch jetzt net damit nerven, oder provozieren, oder so (ehrlich gesagt hab ich keine Ahnung wie du das jetzt aufgefasst hast 😃 ), aber ich finde, dass die Lesbarkeit schon eine wichtige Sache ist.
    Jetzt hab ich aber noch eine andere Frage: Welche Möglichkeiten habe ich noch ein Array zurückzugeben? Denn OOP wird von AutoIt nicht unterstützt und so weit ich das verstanden habe, ist ein Vektor eben leider eine Klasse.

    PS: Code::Blocks hat Syntax-Highlighting, nur das hinzufügen neuer Keywords ist irgendwie kompliziert.



  • Fast2 schrieb:

    aber ich finde, dass die Lesbarkeit schon eine wichtige Sache ist.

    An for ohne Großschreibung gewöhnt man sich schnell. Und da es in vielen anderen Sprachen auch unbedingt klein geschrieben wird und diese Sprachen meist keine Möglichkeiten haben mit hässlichen #defines die Groß/Kleinschreibung umzubiegen, sollte man es sich auch nciht anders angewöhnen. Mal ganz abgesehen davon dass es am Ende jedem außer dir unangenehm auffällt wenn er Code liest bei dem die Schlüsselwörter verfremdet werden.

    Jetzt hab ich aber noch eine andere Frage: Welche Möglichkeiten habe ich noch ein Array zurückzugeben? Denn OOP wird von AutoIt nicht unterstützt und so weit ich das verstanden habe, ist ein Vektor eben leider eine Klasse.

    Wenn du kein OOP benutzen kannst ist C++ vielleicht die falsche Sprache. OOP ist schließlich eines der Grundpfeiler von C++, vielleicht ist daher C die bessere Wahl. Dort ists allgemein üblich einen Pointer auf den Anfang des Arrays zurückzugeben (bzw. einen als Argument übergebenen Pointer auf einen Pointer entsprechend zu ändern) und die Länge des Arrays zusätzlich zurückzugeben (oder eben wieder über einen Pointer)



  • Fast2 schrieb:

    Mit "ob es Sinn macht..." meinte ich ob es sehr Ressourcenfressend ist, oder ob es nur mehr Schreibaufwand ist, wobei ich gerade gelesen habe, dass das nur zweite stimmt (Sind ja nur Anweisungen für den Präprozessor 🙄 ). Wobei ich diese #difines ja auch in ne eigene Headerdatei packen kann. Also, ich wollte euch jetzt net damit nerven, oder provozieren, oder so (ehrlich gesagt hab ich keine Ahnung wie du das jetzt aufgefasst hast 😃 ), aber ich finde, dass die Lesbarkeit schon eine wichtige Sache ist.

    Nein, ich hab es nicht böse gemeint, tut mir leid, wenn du das so verstanden hast. Ich finde es einfach nicht gut, wenn man die Grundsyntax der Sprache abändert, um damit eine angeblich bessere Lesbarkeit zu erzielen. Nicht ohne Grund hat sich der C++-Standard für diesen Weg entschieden. Und wie gesagt wird das eher zu Problemen führen, wenn andere sich deinen Code anschauen sollen. Und was die Umgewöhnungssache betrifft: Sorry, aber das ist einfach kein Argument, besonders nicht, wenn man zu C++ wechselt. Man kommt beim Wechsel der Programmiersprache nun mal nicht drum herum, sich umzugewöhnen. Krampfhafte Versuche, die alte Programmiersprache in eine neue zu integrieren führen einen auch nicht weiter - sie fördern eher Probleme, die entstehen, wenn nicht nur einfache Analogien wie for - For vorhanden sind. Beispiel Zeiger.

    Fast2 schrieb:

    Jetzt hab ich aber noch eine andere Frage: Welche Möglichkeiten habe ich noch ein Array zurückzugeben? Denn OOP wird von AutoIt nicht unterstützt und so weit ich das verstanden habe, ist ein Vektor eben leider eine Klasse.

    Dann bringt dir C++ aber wirklich nicht viel. Wie kommst du denn auf C++, wenn du objektorientierte Programmierung nicht nutzen willst? Ohne Klassen kann man fast ebenso gut C verwenden. Du müsstest das Array dynamisch erstellen (mit new in C++, malloc() in C) und einen Zeiger zurückgeben. Das Problem ist dabei, dass der Aufrufer daran denken muss, den angeforderten Speicher wieder freizugeben. Damit muss man halt leben, wenn man OOP nicht nutzt (abgesehen von vielen anderen Erleichterungen), aber das ist natürlich deine Sache.

    Fast2 schrieb:

    PS: Code::Blocks hat Syntax-Highlighting, nur das hinzufügen neuer Keywords ist irgendwie kompliziert.

    Ich meinte ja, Syntax-Highlighting würde die echten Schlüsselwörter der Sprache hervorheben, was die Lesbarkeit noch stärker erhöht als eine einfache Grossschreibung.

    Um dir mal ein Beispiel zu zeigen:

    Int MyInteger = 4;
    Const Long Maximum = 3;
    If (MyInteger >= Maximum)
    {
        Return False;
    }
    Else
    {
        While (MyInteger < Maximum);
        {
            MyInteger++;
        }
        Return True;
    }
    

    So siehts etwa in der IDE aus, wenn du die echten Schlüsselwörter brauchst:

    int MyInteger = 4;
    const long Maximum = 3;
    if (MyInteger >= Maximum)
    {
        return false;
    }
    else
    {
        while (MyInteger < Maximum);
        {
            MyInteger++;
        }
        return true;
    }
    

    Die Frage um die Übersichtlichkeit erübrigt sich wohl. Und das ist nur ein einfaches, prozedurales Beispiel mit kurzen Zeilen. Stell dir das Ganze mit langen Parameterlisten, verschachtelten Templateargumenten und Operatorüberladung vor...



  • Hallo,
    also irgendwie kommt es mir so vor, als ob wir hier ein wenig aneinander vorbeireden 😃 (Sorry falls ich mich etwas kompliziert ausdrücke).
    Die DLL dient mir auch zum üben von Sachen und so. Und es geht mir auch um die Kommunikation AutoIt <-> DLL. Ich meinte nicht, dass die OOP schlecht wäre, im Gegenteil: Ich halte diese für interessant und ziemlich arbeitserleichternd deshalb werde diese vllt. bei anderen DLLs /Programmen verwenden, nur für diesen Zweck erschien sie mir ungeeignet.
    Das Problem ist nur, dass AutoIt keine Klassen und so unterstützt (naja, sehr begrenzt, aber eigene erstellen geht z.B. schonmal net), ich aber eine Kommunikation zwischen beiden ermöglichen möchte. Das freigeben von Speicher mach ich einfach auch in der DLL. Das übergeben per Pointer wäre ne Idee, dann müsste ich mich einmal in die Memory-UDF einarbeiten, da ich diese bis jetzt noch nie brauchte (UDFs sind Funktionssammlungen).
    PS: Die Groß-/Kleinschreibung anzupassen, so viel Zeit sollte für einen Forenpost schon sein.
    PPS: Jetzt muss ich mal "ganz doof" fragen: Was macht das bei Zeigern für einen Unterschied? In meinem Tut habe ich da nichts davon gelesen...
    PPPS(:D): Ich finde das obere WIRKLICH besser. 😃

    Edit: Rechtschreibfehler



  • Fast2 schrieb:

    PS: Die Groß-/Kleinschreibung anzupassen, so viel Zeit sollte für einen Forenpost schon sein.
    PPS: Jetzt muss ich mal "ganz doof" fragen: Was macht das bei Zeigern für einen Unterschied? In meinem Tut habe ich da nichts davon gelesen...

    Sorry, ich versteh jetzt nicht ganz, was du meinst...

    Fast2 schrieb:

    PPPS(:D): Ich finde das obere WIRKLICH besser. 😃

    Naja, schlussendlich ist es ja sowieso deine Entscheidung. Ich würde dir nur dringend raten, es nicht so zu machen. Du wirst dich schnell an die untere Syntax gewohnt haben, und hast nicht auch noch mit den Schlüsselwörtern Probleme (glaub mir, du wirst später um alles froh sein, das reibungsfrei läuft :)). Was ist z.B., wenn du auf einem anderen PC arbeitest? Oder mal den Header nicht einbindest? Oder fremden Code lesen oder einbauen willst? Zudem wird dich wohl jeder vernünftige Programmierer fragen, was du damit bezweckst. Du solltest dich mindestens noch nach besseren Argumenten umsehen, wenn du das durchziehen willst 😉



  • Ich meinte weil du folgendes geschrieben hast:
    [quote=Nexus]sie fördern eher Probleme, die entstehen, wenn nicht nur einfache Analogien wie for - For vorhanden sind. Beispiel Zeiger. [/quote]



  • Aha ok. Ich meinte nur, du wirst früher oder später sicher mit dem Problem konfrontiert werden, dass man Sprachmittel nicht einfach durch Grossschreibung in andere Sprachen übernehmen kann. Man trifft auch, gerade bei C++, mit grosser Wahrscheinlichkeit auf Dinge, die man noch nicht kennt. Ich finde es besser, man lernt eine Programmiersprache unvoreingenommen kennen, als wenn man versucht, ihr Dinge aufzudrängen, die zwar vorläufig funktionieren, aber mittelfristig zu Problemen führen. Ich hab eben das Gefühl, dass for <-> For bei dir erst der Anfang ist und dass du später das Gleiche mit komplexeren Sprachmitteln versuchst, aber das ist natürlich nur eine Vermutung... 😉

    Ich hab das Beispiel Zeiger genommen, weil Zeiger in vielen Sprachen nicht so vorkommen (wo ausser C/C++?) und meines Erachtens relativ schwierig sind, bis man sie komplett versteht und auch anwenden kann (z.B. dynamische Speicherverwaltung). Zudem sind viele Fehler, die man zuerst als unerklärlich ansieht und die einem viel Zeit rauben, auf Zeiger zurückzuführen.

    Aber nochmals ernsthaft: Wieso sträubst du dich so gegen die Kleinschreibweise der C++-Schlüsselwörter? Versuch es doch einfach mal eine Zeit lang, und wenn du wirklich daran verzweifeln solltest, kannst du dich ja immer noch umstellen.



  • Was ist lesbarer

    For (std::size_t i = 0; i != end; ++i)
    // oder:
    for (std::size_t i = 0; i != end; ++i);
    

    ?
    Beim ersten hat ein C++ Programmierer doch erstmal keine Ahnung was das sein soll. Eventuell ein Makro, aber wahrscheinlicher ein Tippfehler. Durch Syntaxhighlighting ist die zweite Variante sogar wesentlich lesbarer.

    Aus welchen Sprachen kennst du denn diese Großschreibung? Mir fällt da nur Basic ein. In C, C++, C#, Java, Ruby und vielen weiteren muss es klein geschrieben werden. In Sprachen wie Delphi(Pascal) steht es einem zwar frei, aber der "Standard"-Stil sieht auch eine Kleinschreibung vor.

    Gruß
    Don06



  • OK, also danke für die Hilfe. Wollt ich nur noch mal sagen.

    Edit: Ich hab doch noch ein Problem, um genau zu sein 2777 Probleme 😃 :
    Edit2: Sorry, ich habe garade bemerkt, dass das ja gar nicht alles hier rein passt *g*. Ich habe jetzt alles in eine Textdatei kopiert und auf Rapidshare hochgeladen. (Code+Fehlermeldungen). Link
    Edit3: Ich hab einfach nur zum testen was ausprobiert: Ich habe jede Funktion sowie jedes Include auskommentiert, dabei nach jedem Kommentar compillieren und linken lassen, jedes mal gab es immer weniger Fehler. Dann habe ich schrittweise wieder Entkommentiert, nie gab es einen Fehler. 😕 Zuvor habe ich das <windows.h> Include im Queltext an die letzte Stelle verschoben, da ich beim durcharbeiten der Bibliotheken, um eine Beep-Funktion zu finden, einen Hinweis gefunden habe, dass es Fehler geben kann, falls nach dieser Bibliothek noch weitere inkludiert werden. Falls es euch interessiert, ist hier der Code der windows.h:

    /*
    	windows.h - main header file for the Win32 API
    
    	Written by Anders Norlander <anorland@hem2.passagen.se>
    
    	This file is part of a free library for the Win32 API.
    
    	This library is distributed in the hope that it will be useful,
    	but WITHOUT ANY WARRANTY; without even the implied warranty of
    	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
    */
    #ifndef _WINDOWS_H
    #define _WINDOWS_H
    #if __GNUC__ >=3
    #pragma GCC system_header
    #endif
    
    /* translate GCC target defines to MS equivalents. Keep this synchronized
       with winnt.h. */
    #if defined(__i686__) && !defined(_M_IX86)
    #define _M_IX86 600
    #elif defined(__i586__) && !defined(_M_IX86)
    #define _M_IX86 500
    #elif defined(__i486__) && !defined(_M_IX86)
    #define _M_IX86 400
    #elif defined(__i386__) && !defined(_M_IX86)
    #define _M_IX86 300
    #endif
    #if defined(_M_IX86) && !defined(_X86_)
    #define _X86_
    #elif defined(_M_ALPHA) && !defined(_ALPHA_)
    #define _ALPHA_
    #elif defined(_M_PPC) && !defined(_PPC_)
    #define _PPC_
    #elif defined(_M_MRX000) && !defined(_MIPS_)
    #define _MIPS_
    #elif defined(_M_M68K) && !defined(_68K_)
    #define _68K_
    #endif
    
    #ifdef RC_INVOKED
    /* winresrc.h includes the necessary headers */
    #include <winresrc.h>
    #else
    
    #include <stdarg.h>
    #include <windef.h>
    #include <wincon.h>
    #include <winbase.h>
    #if !(defined NOGDI || defined  _WINGDI_H)
    #include <wingdi.h>
    #endif
    #ifndef _WINUSER_H
    #include <winuser.h>
    #endif
    #ifndef _WINNLS_H
    #include <winnls.h>
    #endif
    #ifndef _WINVER_H
    #include <winver.h>
    #endif
    #ifndef _WINNETWK_H
    #include <winnetwk.h>
    #endif
    #ifndef _WINREG_H
    #include <winreg.h>
    #endif
    #ifndef _WINSVC_H
    #include <winsvc.h>
    #endif
    
    #ifndef WIN32_LEAN_AND_MEAN
    #include <cderr.h>
    #include <dde.h>
    #include <ddeml.h>
    #include <dlgs.h>
    #include <imm.h>
    #include <lzexpand.h>
    #include <mmsystem.h>
    #include <nb30.h>
    #include <rpc.h>
    #include <shellapi.h>
    #include <winperf.h>
    #ifndef NOGDI
    #include <commdlg.h>
    #include <winspool.h>
    #endif
    #if defined(Win32_Winsock)
    #warning "The  Win32_Winsock macro name is deprecated.\
        Please use __USE_W32_SOCKETS instead"
    #ifndef __USE_W32_SOCKETS
    #define __USE_W32_SOCKETS
    #endif
    #endif
    #if defined(__USE_W32_SOCKETS) || !(defined(__CYGWIN__) || defined(__MSYS__) || defined(_UWIN))
    #if (_WIN32_WINNT >= 0x0400)
    #include <winsock2.h>
    /*
     * MS likes to include mswsock.h here as well,
     * but that can cause undefined symbols if
     * winsock2.h is included before windows.h
     */
    #else
    #include <winsock.h>
    #endif /*  (_WIN32_WINNT >= 0x0400) */
    #endif
    #ifndef NOGDI
    /* In older versions we disallowed COM declarations in __OBJC__
       because of conflicts with @interface directive.  Define _OBJC_NO_COM
       to keep this behaviour.  */ 
    #if !defined (_OBJC_NO_COM) 
    #if (__GNUC__ >= 3) || defined (__WATCOMC__)
    #include <ole2.h>
    #endif
    #endif /* _OBJC_NO_COM */
    #endif
    
    #endif /* WIN32_LEAN_AND_MEAN */
    
    #endif /* RC_INVOKED */
    
    #ifdef __OBJC__
    /* FIXME: Not undefining BOOL here causes all BOOLs to be WINBOOL (int),
       but undefining it causes trouble as well if a file is included after
       windows.h
    */
    #undef BOOL
    #endif
    
    #endif
    

    Naja, hauptsache sie läuft.



  • Reicht ein Edit nicht um einen Thread als ungelesen zu markieren?


Anmelden zum Antworten