Welche voraussetzungen muss ich mitbringen um in WinApi weiterzumachen?

Elektronix

lippoliv schrieb:

Elektronix schrieb:

[...]in beiden Sprachen muß man mit Pointern umgehen können. [...]

Echt? Wo gibt es denn in C++ pointer? Wurde C++ denn nicht geschaffen, um Pointer zu verhindern?

Nein. C++ ist die OOP-Erweiterung von C. Das kann man natürlich auch nutzen, um Pointer zu vermeiden. Aber das funktioniert nicht immer.

Elektronix schrieb:

Aber wenn man die nutzen will, muß man dafür in C++ mehr mit Bibliotheken umgehen und wissen, was drin steht.

meintest du anstatt C++ C? Wenn ja: Gibt es wirklich Bibliotheken für C und Strings?

Falsch verstanden: Viele Erleichterungen, die C++ bietet, sind in Bibliotheken verpackt. Darum muß man schon bei jedem simplen "Hallo,Welt"-Programm in C++ iostream.h einbinden. Aber iostream.h kann natürlich noch mehr. Um das alles zu nutzen, muß man gut über die Bibliotheken bescheid wissen.

Elektronix schrieb:

lippoliv schrieb:

Es fängt schon damit an, wie man einlßt, bei C++ z.B. ist das mit "cin >> #VARIABLE", bei C musst du beachten welche Variable es ist "scanf( "%s", #CHARARRAY );" ausserdem hast du in C z.B. keine Strings, was den anfang (wenn man sie vorher hatte) erschweren dürfte...

Das hat mit der WinAPI nichts zu tun. cin und cout funktionieren nur in der Console, die WinAPI nutzt TextOut() und DrawText() dafür.

^^nicht weit genug gedacht, aber ist das nicht auch in der WinAPI wichtig, dass man wissen muss mit welchem Variablentypen man rumhantiert? z.B. kannst du nicht inefach "TextOut( ..., #INTVARIABLE,...);"schreiben und erwarten dass er dir ne Zahl anzeigt oder?

Jain. Natürlich muß man in der WinAPI die Variablen differenzieren. Aber in C++ kannst Du auch nicht einfach int mit char mischen (außer z. B. in der STL). Aber gerade deshalb sollte man sich in der WinAPI mehr an C halten.
Nur als Beispiel: TextOut erwartet als Ausgabedatum in den Funktionsparametern einen String, der mit einem Pointer angesprochen wird (LPCTSTR), dazu noch die Größe des Strings (sizeof(Array)). Dieser String muß aber erstmal gefüllt werden. Dazu nutzt man char-Arrays zusammen mit wsprintf oder sprintf. Das sind nunmal reine C-Funktionen, und die Array-Größe muß eingehalten werden. Allerdings kann man damit auch verschiedene Variablentypen an den Char übergeben, die werden dann übernommen. Man kann natürlich diese Chars auch mithilfe von String-Funktionen von C++ füllen, trotzdem kann man TextOut nicht direkt mit String-Funktionen bedienen.

lippoliv

Ja stimmt eigentlich, das beutet, enige C kenntnisse währen nicht schlecht für WinAPI ja?

sri

Elektronix schrieb:

Nur als Beispiel: TextOut erwartet als Ausgabedatum in den Funktionsparametern einen String, der mit einem Pointer angesprochen wird (LPCTSTR), dazu noch die Größe des Strings (sizeof(Array)).

sizeof(Array) ist in Verbindung mit LPCTSTR eine ganz böse Sache. Die meisten Windows-Funktionen erwarten die Anzahl der Zeichen und nicht die der Bytes. Unter Ansi geht das noch gut, weil 1 Zeichen == 1 Byte. Bei Unicode gilt aber 1 Zeichen == 2 Bytes und damit sagst Du der Funktion, dass der Puffer doppelt so groß ist wie er eigentlich ist.

Besser immer sowas nehmen:

#ifndef countof
#define countof(array) (sizeof(array)/sizeof(array[0]))
#endif

Elektronix

Richtig, habe ich übersehen. Mein Fehler.
Ändert aber nichts am Prinzip meiner Aussage. Statt Sizeof nimmt man dann len(Array) o. ä..

sri

Ja, bei TextOut wäre countof natürlich auch fehl am Platz und lstrlen richtig. Das habe ich wiederum übersehen.

Swordfish

Elektronix schrieb:

C ist eine Teilmenge von C++.

So ein Quatsch! C ist schon lange keine echte Teilmenge von C++ mehr. (Such doch mal im aktuellen C++ Standard nach VLAs...)

greetz, Swordfish

Was Du bisher kannst ist mehr als genug, um Winapi Programme zu schreiben.
Das einzige Problem ist die gewaltige Unmenge an 'Vokabeln', die man lernen muss.
Man könnte es mit einer lebenden Fremdsprache vergleichen:
Du verstehst die Konzepte und Schlüsselwörter von C/C++ (... egal welche Prog. Sprache), und beherrscht damit die Grammatik. Das sind ca. 50% der Miete auf dem Weg zum Programmierer. Was noch fehlt, sind die Vokabel.
Und von diesen Vokabeln gibt es immens viele, was die WINAPI betrifft. Und das macht ein exzessives Nachschlagen bei der msdn-Hilfe notwendig. Dadurch kommt man anfangs relativ langsam zu Ergebnissen. Aber mit der Zeit merkt man sich die Vokabel, und man wird immer schneller. -> Wenn man aber einmal vorhat, hauptsächlich GUIs und nichts anderes zu programmieren, dann wäre es bestimmt klüger, Delphi zu lernen.

lippoliv

Wie kommst du denn auf die Idee?

Delphi habe ich ein Jahr gemacht und ich bin mir noch nicht sicher, allerdings finde ich glaube ich jedes Visual-Ding besser als Delphi...

Klar Delphi kann man leicht erlernen aber man ist doch irgendwie eingeschränkt.

Allerdings mal so im vergleich: Delphi und Visual Studio 2008 (C++) ist ja kein großer unterschied in der Geschwindigkeit in der man GUIs machen kann oder?

sothis_

lippoliv schrieb:

Allerdings mal so im vergleich: Delphi und Visual Studio 2008 (C++) ist ja kein großer unterschied in der Geschwindigkeit in der man GUIs machen kann oder?

yup, ist es nicht wirklich. delphi ruft die meisten winapi funktionen über eigene funktionen auf um den krams erstmal ins pascalformat (was parameter und rückgabewerte angeht) zu kriegen und bastelt die dann wie jedes andere framework in klassen. es ist also mehr oder weniger maximal die unterschiedliche effizienz der compiler die da ausschlaggebend wäre, wobei ich da aber keine objektive stellungnahme wagen will rein vom verschachtelungsumfang was funktionsaufrufe in der hochsprache angeht kann man VCL (wenn das noch so heißt?) mit MFC vergleichen.

CodeFinder

bruce85 schrieb:

Könnt Ihr mir vieleicht Tutorials empfehlen, wenn möglich auf deutsch, kann aber auch auf English sein, nur verstehe ich das meistens besser, wenn es auf deutsch ist.

Englisch ist eigentlich die Grundvoraussetzung für's Programmieren (egal, ob in C, C++ oder sonst was...natürlich auch bei Verwendung von Frameworks^^). Macht also Sinn, sich gleich an englische Tutorials zu gewöhnen, die sind i.d.R. auch besser, da detailierte/vollständiger .