Am 17.02.2010 16:09, schrieb Michael Maier:
Wann nimmt man einen Smart/Twingo/XX und wann einen 814 mit Ladelift?
--> ersteres für die Stadt
--> letzteres für den Umzug
Komplexität: Einfache Controllerschaltung für drei Tastern und vier LEDs oder Touchscreen TFT mit Benutzeroberfläche und Gedöns drumherum.
Butzo
Hi, welchen Compiler dann f=FCr C, C++? RundumSorglos Paket. F=FCr den Einstieg, gerne mit C++.
Wo kann ich es bestellen?
Gr=FC=DFe Michael
Am 17.02.2010 21:00, schrieb Klaus Rudolph:
Seit ich gegen meinen Willen Java programmieren muss (kommt häufiger vor in der Uni) kann ich OO auch ab und zu verfluchen. Es hat sicher seine Berechtigung und ein wunderbarer Mix aus prozuduralem und objecktorientiertem Code ist sehr gut wartbar.
Abgesehen davon, dass ich Gosling wegen diverser Dinge verfluche [1], gibt es einfach Dinge, die Funktionen sind und keine Methoden. Aus einem double[] ein double[] machen, z.B. Koordinatentransformation, und zwar austauschbar. Ich weigere mich daraus eine ArrayList zu machen, denn eine Zahl ist für mich nur mathematisch ein Objekt, ansonsten hat da kein Pointer zu sein.
Streng OO-Weg: Eine statische Klasse mit einer statischen Funktion. Braucht nämlich keinen Konfigurationwert oder sonstiges und somit auch keine Instanz. Virtuelle Funktionen fallen damit natürlich weg. Eine Wrapperklasse mit .toXY fühlt sich nicht nach sauberer Programmierung an, die Wrapperklasse für die Koordinatenliste müsste dann alle Zielmöglichkeiten kennen.
Mein Lieblingsweg, den ich unter D (sic, D, nicht C) auch so benutze: Funktionspointer. Schön statisch, keine anonyme Klasse oder ähnlicher Schmarrn. Nur ein einziger Pointer, keine Instanz, nix. Und wenns doch mal in eine Instanz gehen soll, kein Problem, D kann auch Methodenpointer mit implizitem this. Herrlich simpel.
So simpel ist OO-technisch nur eine nicht-vererbte Klasse, von der ich einen Instanz erzeuge und sie weitergebe. Notfalls anonym. Bloat.
Grüße, Gian Perrone
P.S.: Falls sich jemand für D interessieren sollte, ich hab noch irgendwo Folien von mir von nem Vortrag darüber. Leider noch nicht ?C-tauglich, das gcc-Frontend ist relativ veraltet. Aber für Desktops hochinteressante Programmiersprache.
[1] Es gibt kein unsigned, weil die meisten das eh nicht verstehen. Den Code den ich fabriziere um doch unsigned zu rechnen, versteht mit Sicherheit keiner, der das nicht auch mal machen musste. Operator Overloading ist nicht drin, weil man das missbrauchen kann. Zitat Gosling: "as a fairly personal choice" Ich finde 1) op1.equals(op2) sehr schlecht lesbar (op1 und op2 sind nicht gleichberechtigt), 2) vergisst man das auch gerne mal und vergleicht die Pointer (was dann bei kleinen Zahlen auch noch klappt...), 3) kann man auch in .equals genau so viel Mist machen wie in op==In article , Stefan Engler writes: |> |> irgendwie muss jeder anfangen und da ist ein 8-Bit'er und C durchaus |> eine Möglichkeit. Warum nicht?
Weil es den Anfänger verwirrt.
Zu meiner Anfangszeit war BASIC noch das Maß der Einsteiger-Dinge. Für jeden Rechner verfügbar und rein humansprachlich verständlich. Ein paar Listings abgetippt, etwas selbst experimentiert und man hatte raus, wie der Hase läuft.
Irgendwann wagte man sich (notgedrungen) an Assembler und wurde so mit seiner Mühle vertraut -- und lernte, was man tut und was nicht.
Dann kam der C-Hype in den 80ern. Und einer der größten Fehler, den man damals tun konnte, war, C als Hochsprache zu verkaufen, denn die meiste Zeit verbringt man in C eben doch damit, Pointer durch die Gegend zu schubsen sowie System- bzw. Bibliotheksaufrufe zu verinnerlichen.
Einsteiger sind daher mit dem *Gesamt*feld, das C aufmacht, gerne überfordert.
|> Eine Sprache, die ich nicht spreche vergesse ich. (Basic ist mir zum |> Beispiel mitlerweile vollkommen unbekannt)
*Das* BASIC gab's eh nie, von daher kannst Du ohnehin nur im jeweiligen Hausdialekt eingerostet sein. Und der ist, sofern's nicht VisualBASIC war, vermutlich hinreichend ausgestorben.Rainer
Kann ich nicht bestätigen. Wenn man C in Assembler übersetzt, ist man vom resultierenden Code normalerweise in keinster Weise überrascht (wenn wir nicht gerade makrointensiv geschrieben haben oder die 5000 Operatorpräzedenzen dafür genutzt haben, Klammern zu sparen). Das sieht bei C++ wieder ganz anders aus.
Das Hauptproblem von C als "Hochsprache" ist die Abwesenheit eines echten Arraytyps. Das führt zum einen dazu, daß der Compiler sich oft nicht zu optimieren trauen kann, weil Pointer überallhin zeigen könnten (wenn man nicht mit ganz modernen keywords wie "restrict" hantiert, die keiner verstehen und anwenden kann). Zum anderen sind Funktionen auf mehrdimensionalen Arrays nur mit expliziter Indexarithmetik, oder aber grauenvoll ineffizient zu schreiben. C99 und Konsorten haben da noch Nachträge geliefert, aber das interessiert eine Menge alter Compiler nicht, und auch eine Menge alter Hasen. Die genialen Mathematiker, die Numerikbibliotheken schreiben, sind schon alle tot und ihr Vermächtnis ist nur in Fortran sinnvoll zu gebrauchen.
Man sehe sich mal an, was "Numerical Recipes in C" für Katastrophen bei den Arraykonventionen veranstaltet. Grau-en-haft. Und natürlich mit nichts anderem kompatibel.
Naja, C ist eigentlich recht übersichtlich. Aber es ist halt keine Sprache zur Massenverarbeitung von Daten, sondern zur Umsetzung von Kontrollflüssen.
-- David Kastrup
Am 18.02.2010 00:40, schrieb Michael Maier:
In deinem Browser.
Wähle die Atmel AVR Microcontroller, gehe auf atmel.com, ziehe Dir das AVRStudio, gehe dann nach winavr.sourceforge.net und ziehe Dir die neueste WinAVR Version. Wenn Du einen Rechner mit echter serieller Schnittstelle hast, kauf Dir bei
Notiere Dir dann noch
-- Mit freundlichen Grüßen Frank-Christian Krügel
In article , David Kastrup writes: |> |> Kann ich nicht bestätigen. Wenn man C in Assembler übersetzt, ist man |> vom resultierenden Code normalerweise in keinster Weise überrascht (wenn |> wir nicht gerade makrointensiv geschrieben haben oder die 5000 |> Operatorpräzedenzen dafür genutzt haben, Klammern zu sparen).
Da stimme ich Dir ja unumwunden zu, aber wir reden hier ja gerade vom Einsteiger.
Der, der erst mal ein schnelles Erfolgserlebnis haben will, so wie das früher mit BASIC auf den diversen Homecomputern durchaus machbar war.
Da haben die von anderen angeführten Interpretersprachen wie z.B. PHP oder Python m.E. einen echten Vorteil.
|> > Einsteiger sind daher mit dem *Gesamt*feld, das C aufmacht, gerne |> > überfordert. |> |> Naja, C ist eigentlich recht übersichtlich. Aber es ist halt keine |> Sprache zur Massenverarbeitung von Daten, sondern zur Umsetzung von |> Kontrollflüssen.
Drum schrieb ich: das Gesamtfeld.
C als Sprache ist sicher nicht schwerer oder leichter als jede andere prozedurale Sprache auch. In meinen Augen sogar angenehmer als z.B. Pascal, weil sie der natürlichen Faulheit des Menschen nachkommt.
Rainer
Hallo, ok Danke.
Brauche ich noch etwas? Spannungsversorgung etc....?
Danke.
Gr=FC=DFe Michael
Ja. Die Hohlsteckerbuchse auf dem Board will gefüttert werden. Reichelt schlägt vor: MW 9112-GS, Tisch-Netzgerät, stabilisiert, 1200mA, 9,95 EUR.
------
-- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53
Hallo,
doch noch ne Frage. Die Anleitung ist in Englisch. Gibt es deutsche B=FCcher dann den Controller. Gr=FC=DFe Michael
Johannes Bauer schrieb:
Welchen Mikrocontroller setzt Du denn da ein?
Wenn ich Dich recht verstanden habe, soll Deiner Meinung nach ein Anfänger morgens gleich im Bett bleiben, da er bereits das Zähneputzen ohne entsprechenden Lehrgang nicht bewältigen könnte.
Das ist wohl wahr.
Naja, gerade 'cout' ist ja nun eines der doch eher bekannteren Features. Und es gibt durchaus Leute, die schreiben std::string foo = "1234"; wo ein static const char foo[] = "1234"; auch ausgereicht hätte.
Damit fängt man sich dann wiederum allerlei Probleme mit der Initiali- sierungsreihenfolge ein. Ich wollte mir z.B. meine Treiber als Klassen- objekte anlegen, um die Benutzung wenigstens etwas benutzerfreundlich zu gestalten; also habe ich mir ein eigenes OOP-Schema mit handgeschrie- benen vtables gebaut, da die C++-Konstruktoren einfach viel zu spät laufen würden. Das ganze wird dann über einen Mechanismus des Betriebs- systems initialisiert, nicht über den regulären C++-Mechanismus.
Stefan
Dass das ein Nachteil sei, ist eine unzulässige Verallgemeinerung. RISC- Prozessoren können zum Beispiel ausschließlich indirekt adressieren. Ein Zugriff auf eine Membervariable ist damit ein einziger Assemblerbefehl ('ld r0, (r1+1234)'), wohingegen für einen Zugriff auf eine statische Variable erstmal die Adresse derselben in ein Register befördert werden muss, was ein oder zwei zusätzliche Instruktionen benötigt. Compiler für solche Architekturen packen dann alle statischen Variablen eines Moduls in eine unsichtbare struct, so dass sie nur einen Basiszeiger laden müssen anstatt für jeden Zugriff einen neuen.
Auf einem PIC mag das nun wieder anders aussehen.
Deutlich unübersichtlich. Insbesondere wird das aufgrund der Unübersichtlichkeit selten genutzt. Templates schon.
Das höre ich nach vielen Jahren C++ zum ersten Mal.
Stefan
Hergen Lehmann schrieb:
Getter und Setter *immer*, ja.
Ich sehe nichts:
class foo { private: int a; public: void seta(int); int geta() const; }; void foo::seta(int x) { a = x; } int foo::geta() const { return a; }
foo x;
int main() { x.seta(0x1234); return x.geta(); }
gibt:
00000000004005b0 : 4005b0: b8 34 12 00 00 mov $0x1234,%eax 4005b5: c7 05 6d 0a 20 00 34 movl $0x1234,0x200a6d(%rip) # 60102c 4005bc: 12 00 00 4005bf: c3 retq
Klar muss man den Prototyp beachten - ein Foo& ist halt etwas anderes als ein Foo oder ein Foo*. Nach der Logik wären allerdings auch ints und longs und shorts und chars "gefährlich", weil man ohne ständigen Blick auf die Deklaration fiese Überlauf-Fehler produzieren kann.
Das stimmt wohl, ich halte auch die Zeichen für ungünstig gewählt. C++0x macht es nicht besser mit LValue-Referenzen (&&). Wenn man C++ gewohnt ist, ist das aber kein Problem.
Um Auto fahren zu lernen muss ich auch nicht zuerst einen Motor zusammen bauen oder wissen wofür eine Zylinderkopfdichtung gut ist. Meiner Meinung nach ist es für einen Anfänger am hilfreichsten, wenn der schnell zu Ergebnissen kommt, ohne sich wirklich Gedanken machen zu müssen, warum das jetzt denn alles funktioniert. Wenn jemand tiefer in die Materie einsteigt, kommt das ohnehin.
Gruß, Johannes
-- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa
Martin Gerdes schrieb:
Keinen, ich habe lediglich Code kompiliert. Das Target ist x86-64. Für die Betrachtung ist das aber völlig unerheblich, weil die entsprechende Optimierung auf dem Intermediate-Code ausgeführt wird, nicht auf dem Target-Assembly.
Wenn ich dich recht verstanden habe, hast du die inhärente Ironie meiner Aufzählung nicht recht verstanden.
Gruß, Johannes
-- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa
Am 18.02.2010 16:54, schrieb Michael Maier:
Wenn Du bei Amazon nach avr suchst, solltest Du fündig werden. Die Primärliteratur, d.h. die maßgeblichen Datenblätter aller Herstellers, ist allerdings ausschließlich in English, und in diesem Metier mußt Du einfach Englisch zumindest lesen können. Sorry, ist einfach so.
-- Mit freundlichen Grüßen Frank-Christian Krügel
Zu der MSP430 Serie von TI gibt es ein Buch von Lutz Bierl in Deutsch, Jahr 2004. Das waere das einzige von dem ich gehoert habe.
Bei der GUI der Software hoert es dann aber vermutlich auf. Obwohl ich hier irgendwo eine mit Painel de Commando em Portugues haette :-)
-- Gruesse, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
Stefan Reuther schrieb:
Selbst für den AVR wird für optimalen Code empfohlen, Zugriffe über Zeiger auf Strukturen statt über viele globale Variable zu machen. Der Offset-Indirekt-Zugriff über einen Zeiger ist effektiver vom Code als viele Zugriffe über jeweils eine neue (erst vom Linker festgelegte) Adresse.
-- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Ich für einen Anfänger nicht empfehlen, in C zu programmieren, es sei denn, man kennt es schon. Einige Gründe gegen C:
Der wichtigste für mich wird auch in dem Artikel zuerst erwähnt: Man kann in C viel zu leicht Fehler machen, die andere Programmiersprachen abfangen oder es zumindest einfacher machen, zu finden (schonmal in C einen Fehler gesucht, bei dem über die Arraygrenzen in andere Variablen geschrieben wurde?). Wenn man mal in Java, Lisp, Scala oder D programmiert hat, dann möchte man eigentlich nicht mehr C oder C++ machen.
C und C++ ist aber leider Standard bei Embedded Systemen und andere Sprachen gibt es für einige Plattformen erst gar nicht. Und es gibt auch viele sehr gut optimierenende C/C++ Compiler, was bei mehr Sicherheit der Sprache auch nicht immer möglich wäre (mal von aufwendigen statischen mathematischen Beweisen zur Compilierzeit abgesehen). Allerdings bieten größere CPUs genügend Reserven, um auch einige Laufzeittests ohne größere Geschwindigkeitsverluste zu machen.
-- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
Das ist Unsinn. Gerade weil die Sprache mit ihrem Pointerkonzept dermaßen unsicher ist, ist sie miserabel optimierbar: der Compiler kann zu wenig Annahmen darüber machen, welche Anweisungen dieselben Daten betreffen könnten.
Die Unsicherheit der Sprache gibt dem Anwender Mittel in die Hand, selbst in der Einbildung von Optimierung zu schwelgen, indem er mit Pointern hantiert. Dummerweise wäre die damit eingesparte Adreßarithmetik bei heutigen Prozessoren und Speicherarchitekturen ohnehin zum Nulltarif zu bekommen gewesen, und die Konsequenzen in Bezug auf Registerslots, Speicherzugriffe und Aliasingproblemen sind viel unangenehmer als das, was man zu sparen meinte.
-- David Kastrup
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.