Ich will auch programmieren

    Hi,


    mit Bewunderung sehe, teste und benutze ich einige von hiesigen Usern geschriebene Programme für den PDA und WindowsMobile 5.0.


    Während des Studiums vor zwanzig Jahren habe ich mal Fortran- und Cobolkurse besucht und auch einige Sachen in Basic programmiert. Leider sind damit meine Kenntnisse nur äußerst rudimentär aber ich möchte trotzdem gerne versuchen selber was für den PDA auf die Beine zu stellen.


    Vielleicht könnt Ihr mir helfen was ich für den Einstieg bei der C++-Programmierung an Lektüre und Software benötige. Als Compiler hatte ich an DEV-C++ gedacht, das ideale Buch zum Einsteigen und Nachschlagen habe ich bisher nicht gefunden.


    Danke für eure Tips


    Frank


    Hähä.


    Tschuldigung, das war nicht abwertend.


    Suche mal nach watcom. Bin in einer ähnlichen Lage, watcom ist Freeware - oder so ähnlich.


    Aber, mit C oder C++ haben wir - glaube ich - ausgerechnet eine der schwierigsten Sprachen gewählt, aber halt auch - da sehr maschinennah - auch eine der mächtigsten.


    Lass mich ein wenig an Deinen Erkenntnissen teilhaben, vielleicht entschließe ich mich doch noch, tiefer in C/C++ einzutauchen.... :(

    Hallo zusammen!


    Heute ist das Net voll mit Minikursen in C(++). Zum Beispiel sind bei LCC-Win32 oder OpenWatcom derartige Hilfen mit vielen kleinen Beispielprogrammen dabei. Leider alles in Englisch.



    Wenns ein Buch sein soll, dann kann ich das empfehlen:


    "C++ Lernen und professionell anwenden" von Peter Prinz, Ulla Kirch-Prinz
    MITP Verlag GmbH 1999
    ISBN 3-8266-0423-7


    Das Buch enthält auch eine CD-Rom. Darauf ist eine Microsoft Visual C++ "Bookedition". Die Weitergabe der selbstgechriebenen Programme ist nicht gestattet. Das Buch kostete damals 89 DM und ist über 850 Seiten dick.



    Das Buch behandelt die Sprache C++, keine Windowsprogrammierung! Man lernt dort, wie man "Quick & Dirty"- Programme für die Konsole schreibt.




    @Charly: Mit C kannst du maschinennah programmieren und mit Zeigern nur so um dich werfen, mußt aber nicht. Du kannst durchaus im BASIC-Stil schreiben.


    Also
    a = a + 1 anstatt a++
    a = a + 5 anstatt a += 5


    oder eben ganz normal auf Arrays zugreifen


    a = b[code=c]


    (Und Inline-Assembler oder Bitschiebereien verlangt ja niemand und das ist im Normalfall auch nicht nötig. Der Compiler "schiebt" von allein, wenn er sieht, daß eine Ganzzahl mit 2, 4, 8... multipliziert (oder dividiert) werden soll)



    bfn hevo2


    Ach ja, hevo2,


    Du machst jetzt so lange, bis wenigstens ich doch noch anfange.


    Aber Du weißt ja, ich habe es bislang nur fertiggebracht, IDE aufzurufen und einen Source-Code einzulesen. Bevor ich nicht weiß, wie man das compiliert, das entstandene Prog laufen läßt, im Source an definierten Stellen Ausgaben einfügt die man dann im gestarteten Prog ansehen kann, solange wird das bei meiner Mentalität nicht viel werden. Ich muss halt immer sehen, was geschieht wenn. Trial und Error. Und die Handbücher die zu OpenWatcom geladen werden können sind einerseits eklig groß und halt in engl. Das artet dann sicher in große Mühe aus.


    Mal sehen, vielleicht fängt das Tutorial (oder so was ähnliches) ja auch mit kleinen überschaubaren Beispielen an.


    Aber danke für Deinen Mutzuspruch.

    maln hinweis vom altgedienten exsoftwareentwickler...


    es ist zunächst fatal, C und C++ vergleichen zu wollen. sie sehen sich zwar von aussen und innen irgendwie ähnlich, aber sie verfolgen vollkommen unterschiedliche paradigmen (strukturiert versus objektorientiert)


    der hinweis auf die maschinennähe von C ist zwar richtig, sollte baer heute wirklich kein kriterium mehr sein. denn die ganze ASM-programmierung dürfte unter irgendwelchen GUI-oberflächen sowieso in die hosen gehen, wegen der damit verbundenen HALs, die man besser nicht umgehen sollte... ausserdem haben wir heute nicht mehr die situation, dass man einerseits lahme prozessoren überlisten und andererseits wenig speicherplatz megaeffizient nutzen muss. zudem sind die compiler mittlerweile so optimiert, dass sich für den "hausgebrauch" eh keine nennenswerten vorteile ergeben..


    wenn mich, der ich nun ca. 20 jahre entwicklung unter pascal, modula-2, forth (grauenvoll), elan, eiffel, basic, c, c++ und java hinter mir habe, jemand fragen würde, dann würde ich dem vorschlagen, gleich in die objektorientierung einzusteigen. da stellt sich dann die frage: java oder c++ ? oder neuerdings auch noch die frage C# oder J# im rahmen von .NET


    vom erfolgserlebnis und preis/leistungs-verhältnis bzgl. der entwicklungstools würde ich java empfehlen. wenn definitiv klar ist, dass nur für windoof programmiert werden soll, dann C++ (die entwicklungstools bekommt man z.t. bei M$ umsonst - sowohl für windoof aufm PC als auch mit abstrichen für den PDA)


    ohne scherz würde ich einem java-einsteiger folgendes buch empfehlen:


    Java mit Eclipse für Kids


    wenns erwachsen sein soll, dann alles was von o'reilly kommt - sollte man aber englisch für können ;)


    die C++ ecke wird gut durch bruce eckel abgedeckt - hier z.b. etwas, was schon fast standardfolklore ist:


    In C++ denken


    um generell objektorientierung zu verstehen, ist dies hier meiner meinung nach immer noch das beste buch:


    Objektorientierte Softwareentwicklung


    oder das hier:


    Objektorientierte Anwendungsentwicklung


    letzteres ist sehr theoretisch, aber vermittelt den grundgedanken sehr gut.


    grundsätzlich ist bei der ganzen sache zu beachten, dass hier mehrere aufgaben zu bewältigen sind


    • verstehen was objektorientierung eigentlich ist - hat man das begriffen, ist es nachgerade egal, ob man nun java oder c++ oder c# oder was weiss ich programmiert - die sprachen sind sich unglaublich ähnlich. ohne das aber zu begreifen, wird man frustriert scheitern. das ist keine akademische arroganz von mir, sondern mein eigener erfahrungswert. ich habe einen ansatz so versucht, der ging in die hose - erst nachdem ich mir die theorie klar gemacht habe, konnte ich vernünftig programmieren (man muss leider auch analysieren und modellieren)
    • lernen, mit einer programmiersprache und der zugehörigen IDE halbwegs routiniert umzugehen
    • die speziellen bibliotheken kennen lernen um GUI-fähige programme zu schreiben - swing, MFC, tk, was weiss ich - und dafür braucht man definitiv ein gutes verständnis des objektorientierten paradigmas, sonst versteht man schlicht und ergreifend nicht, was in diesen klassenbibliotheken vor sich geht. MFC vertseht man z.b. nicht, bevor man nicht verstanden hat was dynamisches binden ist, etc...


    alles in allem ist also der einstieg in das ganze nicht so wirklich einfach, wie vor 20 jahren BASIC zu lernen :) die alternative dazu wäre vielleicht VB-programmierung, aber die wird auch immer objektorientierter - oder was M$ da unter objektorientierung versteht... :)


    vielleicht nutzen ja die buchtips was - es ist definitiv nichts, was man an einem tag erlernt und man sollte sich an die obige reihenfolge halten :)


    gruß,


    axel

    Einmal editiert, zuletzt von Herr R aus B ()

    Hallo axel,



    im Prinzip hast du ja vollkommen Recht, aber...


    Zitat

    Original von Herr R aus B
    der hinweis auf die maschinennähe von C ist zwar richtig, sollte baer heute wirklich kein kriterium mehr sein. denn die ganze ASM-programmierung dürfte unter irgendwelchen GUI-oberflächen sowieso in die hosen gehen, wegen der damit verbundenen HALs, die man besser nicht umgehen sollte...


    Wenn ich mich nicht irre, dann laufen 95% aller PCs mit x86 Prozessoren, wohl aber natürlich unter verschiedenen OS (Windows, Linux, BEOS...). So gesehen kommt "hinten" immer Maschinensprache für x86-Prozessoren raus.


    Und natürlich kann man beispielsweise ein Windows-GUI Progi in Assembler schreiben, das hat mit HAL erstmal nix zu tun, da die Progis sowieso im Ring3 laufen und man daher eh keinen direkten Zugriff auf die Hardware bekommt. Siehe dazu masm32.com. Inwieweit ASM wirklich sinnvoll ist, da ja laufend API-Funktionen aufgerufen werden mussen, die Parameter auf dem Stack erwarten, muß jeder selbst entscheiden. Der Geschwindigkeitsvorteil von Assembler geht in diesem Fall gegen Null.


    Anders sähe es aus, wenn man etwas berechnen will, ohne irgendwelche API-Funktionen aufzurufen. Dann darf man mal an Assembler denken und sich das ASM-Listing ausgeben lassen, aber erst, wenn man die Berechnungen in C (oder einer anderen maschinennahen Sprache) geschrieben und der Compiler die Drecksarbeit erledigt hat.


    Ein alter Spruch lautet: Je besser man Assembler kann, umso weniger braucht man ihn.


    Wenn man nämlich mal ins ASM-Listing guckt, dann sieht man eventuell was der eigene in einer Hochsprache geschriebene Code "anrichtet". Möglicherweise führt diese gewonnene Erkenntnis dann zu besseren Code in der Hochsprache.


    Ein normaler Assemblerprogrammierer hat aber heute wirklich keine Chance mehr gegen einen Compiler.





    Zitat

    Original von Herr R aus B
    ausserdem haben wir heute nicht mehr die situation, dass man [...] lahme prozessoren überlisten [...] muss.


    Wenn ich was in x86-ASM mache, dann nicht um den Prozessor zu überlisten, sondern seine brachliegenden Fähigkeiten zu nutzen. Einfaches Beispiel aus dem Bereich Navigation ist das Umsortieren der Bytes bei short, int, float und double vom Big-Endian Format im SiRF-Binary-Protocol nach Little-Endian, damit ein x86 Prozessor etwas mit diesen Bytes anfangen kann.


    In C könnte man das für eine 16-Bit Zahl so machen:


    void Swap2Bytes(unsigned char *pucByte) {
    unsigned char ucByte0, ucByte1;


    ucByte0=*(pucByte+0);
    ucByte1=*(pucByte+1);


    *(pucByte+0)=ucByte1;
    *(pucByte+1)=ucByte0;


    }



    Nun stelle man sich das "rumgepoke" nach diesem Strickmuster für einen Double vor...


    Oder wie hier: http://www.netdirect.ca/~cdfrey/software/packarray.cc



    Aber mal ehrlich, das kanns doch nicht wirklich sein, wenn man weiß, daß ein Programm sowieso nur für ein 32-Bit OS unter x86 gedacht ist und man heute mindestens einen 486er erwarten kann. Dann bietet sich nämlich der Maschinenbefehl BSWAP an, der genau für sowas gedacht ist.


    Natürlich würde man den Code "inlinen", damit der ganze Overhead wegkommt, aber als normale Prozedur sähe das so aus:



    void Swap16(void *x) {
    _asm {
    mov eax, x
    mov dx, [eax]
    bswap edx
    shr edx,16
    mov [eax], dx
    }
    }



    Okay, für 16Bit ist das noch nicht effektiv. Für 32-Bit Zahlen (int und float) sieht es aber schon anders aus.




    void Swap32(void *x) {
    _asm {
    mov eax, x
    mov edx, [eax]
    bswap edx
    mov [eax], edx
    }
    }



    Und dies für Doubles oder 64Bit-Ints


    void Swap64(void *x) {
    _asm {
    mov eax, x
    mov edx, [eax]
    push edx
    mov edx,[eax+4]
    bswap edx
    mov [eax], edx
    pop edx
    bswap edx
    mov [eax+4], edx
    }
    }



    Eventuell muß man diese Version für 64-Bit Zahlen nehmen:


    void Swap64old(void *x) {
    _asm {
    mov eax, x
    mov edx, [eax]
    bswap edx
    mov [eax], edx
    mov edx,[eax+4]
    bswap edx
    mov [eax+4], edx
    }
    }



    Es gibt also durchaus gute Gründe für ein Arbeiten "close to the machine".





    bfn hevo2

    <breit-grins>


    Programmierer unter sich....



    Oder:


    Kunst kommt von können (Können),
    und wenn mans kann ist es keine Kunst mehr. :]


    Ja, nee, ist schon klar. 8)


    Wenn man es ihnen beigebracht hat, was bei rauskommen soll, ist alles klar,
    aber ................ der Prozess, es ihnen klarzumachen, ................ :-D) :-D) :-D)


    okokokbinjaschonwiederunterdemtisch

    Hi LF,


    du mußt dich nicht extra unter den Tisch bemühen, denn ein Funke Wahrheit steckt ja in deiner Aussage drin. Dass Kunde und Programmierer zunächst aneinander vorbeireden, da die Aufgabe (Pflichtenheft) schwammig formuliert wurde, würde ich durchaus als normal ansehen.



    LG hevo2

    Oh selige Programmierzeiten, lang ist es her 1988. Aber da hatte ich auch schon Turbo Pascal 3 mit Assembler verheiratet, da manches in Assembler besser zu machen war.


    Aber dies ist nun schon 18 Jahre her.


    Es juckt schon ab und zu in den Fingern, um was für den PDA zu schreiben, aber ich glaube ich müsste da von vorne anfangen, da ich "nur" auf DOS-Ebene programmiert habe, über Windows sprach man da nicht.

    Katzen landen auf ihren Füßen.
    Toast landet auf der Marmeladenseite.
    Eine Katze mit einem Toast auf ihrem Rücken schwebt über dem Boden in einem Zustand von Quantenunentschlossenheit.

    Zitat

    Original von Familievierfuss.....- über Windows sprach man da nicht.


    tut man auch heute nicht


    ist wie beim Geld in Besseren Kreisen


    man hat man es, aber man redet nicht drüber




    meint mit einem ;D
    Klaubi

    Zitat

    Original von Familievierfuss
    Oh selige Programmierzeiten, lang ist es her 1988. Aber da hatte ich auch schon Turbo Pascal 3 mit Assembler verheiratet, da manches in Assembler besser zu machen war.


    Aber dies ist nun schon 18 Jahre her.


    Es juckt schon ab und zu in den Fingern, um was für den PDA zu schreiben, aber ich glaube ich müsste da von vorne anfangen, da ich "nur" auf DOS-Ebene programmiert habe, über Windows sprach man da nicht.


    Das waren noch Zeiten !! Da wusste man noch, wo man sich im Rechner befindet (Prozessor, IO-Chip, Grafikspeicher)!! Heute werden doch nur noch Module zusammegeschubbst und fertig.


    Hevo, du hast geschrieben:

    Zitat

    Ein normaler Assemblerprogrammierer hat aber heute wirklich keine Chance mehr gegen einen Compiler


    Ich hab ja auch nur zu DOS-Zeiten wirklich porgrammiert ('84-'90), aber wer baut denn heute Compiler ?? Baut man die auch schon mit Hochsprachen? Dann wundert mich nichts mehr, das Programme schneller Speicher und Prozessorleistung fressen als die Industrie den Ausbau vorantreibt.


    PS: Ich hab noch mit DOS gearbeitet, da gabs schon Win3.11. Ich hasse heute noch das Mausgeschubbse.


    das ist dann aber ein sehr aufgeweichtes prinzip bei der antwort *grins* sagen wir es anders: ich habe assembler immer gehasst :D und als entwicklungsleiter hätte ich dir im rahmen eines code-reviwes auf die finger geklopft wegen mangelnder dokumentierung dessen, was du da tust. das war ja noch einfach, aber irgendwie muss man auch an die nachwelt denken bei solchen konstrukten :P und damit ich auch mal einen allgemeinplatz zu C anbringen darf: C erlaubt es, furchtbare dinge hibzuschreiben, die syntaktisch korrekt sind und auch funktionieren, die ein anderer hinterher aber nicht mehr ohne weiteres durchsteigt - das ist nach (m/r)einer lehre ziemlich böse und pfui und gehört in die ecke :D (auch wenns spaß macht)


    übrigens könnte ich noch feststellen, dass du das byte swapping auch hättest etwas komplizierter ausdrücken können - also mit ein paar << >> || && etc... :) das ist ja nur ein bischen pointer-arithmetik, wie trivial! ;D


    ich hoffe zumindest, dass frabe irgendwie geholfen ist mit den ganzen hinweisen aus diesem thread :]

    Einmal editiert, zuletzt von Herr R aus B ()

    Nur mal so, da ich ja auch damit "befasst" bin.


    Wollte mal etwas näher in C schnuppern. Dazu habe ich nun LCC geladen.


    Bevor man aber nun in der/einer Programmiersprache überhaupt anfängt was zu tun - außer dem Standardprog "Hallo Welt/Hello World" - hat man schon mal das Problem, den Umgang mit dem Komplex Compiler (Debugger) zu lernen.


    Und da stehe ich bereits auf dem Schlauch.


    Das Problem ist einfach: man hat ein Sourcefile, weiß, dass es läuft und will nun versuchen - Trial and Error - dieses nachzuempfinden.


    Schmeißt den Debugger an, taktet im Einzelschritt durch. Soweit noch o.K., mit der Ausnahme, dass man schnell an Grenzen stößt, wenn das Prog irgendwas "durchnudelt". Gut, dafür gibt es "Breakpoints". Die ich z.B. von (MS...) VB so gewöhnt bin, man setzt sie, startet das Prog, am Beakpoint geht es in den Debugmode.


    Bei LCC steht da was von "run to Corsor", ob immer das das ist, was man will: laufe bis zum Breakpoint. Nach Beschreibung ja, nach Versuch nein.


    Und schon ist der erste "Breakpoint" beim Progrmmierversuch da, man hängt bereits im Verständnis zu Compiler/Debugger..... X(


    Oder ich bin einfach zu blöd...