NEUES THEMA
elektroda.net NewsGroups Forum Index - Electronics DE - Mikrocontroller - C oder C++
Goto page Previous 1, 2, 3, 4 ... 13, 14, 15 Next
Michael Maier
Guest
Guest
Thu Feb 18, 2010 5:54 pm
Hallo,
Quote:
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.
doch noch ne Frage.
Reichelt schlägt vor:
MW 9112-GS, Tisch-Netzgerät, stabilisiert, 1200mA, 9,95 EUR.
doch noch ne Frage.
Die Anleitung ist in Englisch.
Gibt es deutsche Bücher dann den Controller.
Grüße Michael
Stefan Reuther
Guest
Guest
Thu Feb 18, 2010 7:01 pm
Joerg Wunsch wrote:
Quote:
Stefan Reuther <stefan.news_at_arcor.de> schrieb:
Da muss man aber teilweise sehr aufpassen. Wir haben in unserem
Projekt z.B. ein Modul "wlocale.o" aus der C++-Standardbibliothek
drin, knapp 50k Code, vermutlich von irgendeinem Teil der iostreams
reingezogen.
Für die kleinen Controller erübrigt sich das, weil die Bibliothek
sowas gar nicht erst hat.
Da muss man aber teilweise sehr aufpassen. Wir haben in unserem
Projekt z.B. ein Modul "wlocale.o" aus der C++-Standardbibliothek
drin, knapp 50k Code, vermutlich von irgendeinem Teil der iostreams
reingezogen.
Für die kleinen Controller erübrigt sich das, weil die Bibliothek
sowas gar nicht erst hat.
Das ist wohl wahr.
Quote:
Wenn man als normaler C-Programmierer an C++ herangeht, benutzt man
all den Kram, der gefährlich werden könnte bezüglich Bloat, gleich gar
nicht.
all den Kram, der gefährlich werden könnte bezüglich Bloat, gleich gar
nicht.
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.
Quote:
C++ bietet übrigens außer der strengeren Typprüfung noch einen
weiteren Vorteil: echte Konstanten. Dafür gibt's auch zumindest ein
nettes C99-Feature, das C++ nicht kann: die Initialisierung von
Feldern oder Strukturen über benannte Elemente. Dafür kann man das in
C++ durch überladene Konstruktoren erledigen, wenn's sein muss.
weiteren Vorteil: echte Konstanten. Dafür gibt's auch zumindest ein
nettes C99-Feature, das C++ nicht kann: die Initialisierung von
Feldern oder Strukturen über benannte Elemente. Dafür kann man das in
C++ durch überladene Konstruktoren erledigen, wenn's sein muss.
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
Stefan Reuther
Guest
Guest
Thu Feb 18, 2010 7:08 pm
Hergen Lehmann wrote:
Quote:
Am 17.02.2010 20:04, schrieb Johannes Bauer:
sobald man auf Objekte zugreift - und so werden aus einer simplen
Zuweisung an eine Membervariable mal eben (je nach Controller) mehrere
dutzend Byte Code. Besonders für einen Anfänger eine ganz böse Falle.
Man kann sehrwohl eine Klasse statisch instanziieren (auf einem uC will
man ohnehin kein new haben), womit dein Einwand natürlich flach fällt.
Tja, damit wärst du dann voll in die Falle getappt. Wenn du die *Klasse*
statisch instanzierst, wird der Compiler trotzdem fleissig Overhead mit
indirekter Adressierung und this-Zeiger produzieren, denn beim
Compilieren der Methoden kann er nicht wissen, ob es zur Laufzeit bei
einer einzigen Instanz bleiben wird.
sobald man auf Objekte zugreift - und so werden aus einer simplen
Zuweisung an eine Membervariable mal eben (je nach Controller) mehrere
dutzend Byte Code. Besonders für einen Anfänger eine ganz böse Falle.
Man kann sehrwohl eine Klasse statisch instanziieren (auf einem uC will
man ohnehin kein new haben), womit dein Einwand natürlich flach fällt.
Tja, damit wärst du dann voll in die Falle getappt. Wenn du die *Klasse*
statisch instanzierst, wird der Compiler trotzdem fleissig Overhead mit
indirekter Adressierung und this-Zeiger produzieren, denn beim
Compilieren der Methoden kann er nicht wissen, ob es zur Laufzeit bei
einer einzigen Instanz bleiben wird.
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.
Quote:
Template Metaprogramming geht mit einem ANSI C Compiler nicht.
Das wenige, was da ohne OO sinnvoll ist, kann man in der Regel auch mit
Makros realisieren. Vielleicht etwas unübersichtlicher, aber weniger
tückisch in Hinsicht auf das, was hinten aus dem Compiler herausfällt.
Das wenige, was da ohne OO sinnvoll ist, kann man in der Regel auch mit
Makros realisieren. Vielleicht etwas unübersichtlicher, aber weniger
tückisch in Hinsicht auf das, was hinten aus dem Compiler herausfällt.
Deutlich unübersichtlich. Insbesondere wird das aufgrund der
Unübersichtlichkeit selten genutzt. Templates schon.
Quote:
Referenzen kennt ein ANSI C Compiler nicht.
Die sind ohnehin gefährlich und umstritten...
Die sind ohnehin gefährlich und umstritten...
Das höre ich nach vielen Jahren C++ zum ersten Mal.
Stefan
Johannes Bauer
Guest
Guest
Thu Feb 18, 2010 9:02 pm
Hergen Lehmann schrieb:
Quote:
Am 17.02.2010 21:50, schrieb Johannes Bauer:
class foo {
private:
int a;
public:
void seta(int x) {
a = x;
}
Schreibst du immer deinen ganzen Quelltext als inline code?
class foo {
private:
int a;
public:
void seta(int x) {
a = x;
}
Schreibst du immer deinen ganzen Quelltext als inline code?
Getter und Setter *immer*, ja.
Quote:
Oder soll
das jetzt nur ein konstruierter Fall aus Rechthaberei sein? Probier das
Ganze bitte nochmal mit einer normalen Methodendeklaration aus, und du
wirst sehen, daß ich für den Regelfall recht habe.
das jetzt nur ein konstruierter Fall aus Rechthaberei sein? Probier das
Ganze bitte nochmal mit einer normalen Methodendeklaration aus, und du
wirst sehen, daß ich für den Regelfall recht habe.
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 <main>:
4005b0: b8 34 12 00 00 mov $0x1234,%eax
4005b5: c7 05 6d 0a 20 00 34 movl $0x1234,0x200a6d(%rip) #
60102c <x>
4005bc: 12 00 00
4005bf: c3 retq
Quote:
Referenzen kennt ein ANSI C Compiler nicht.
Die sind ohnehin gefährlich und umstritten...
Ähm, ist das dein Ernst? Gefährlich? Umstritten? Wow! Kannst du das
ausführen?
Man kann beim Lesen des Quelltextes (ohne ständigen Seitenblick auf die
Funktionsdekarationen) nicht unterscheiden, ob ein Objekt "by value"
oder "by reference" an eine Funktion übergeben wird, was zu hässlichen
Fehlern führen kann.
Die sind ohnehin gefährlich und umstritten...
Ähm, ist das dein Ernst? Gefährlich? Umstritten? Wow! Kannst du das
ausführen?
Man kann beim Lesen des Quelltextes (ohne ständigen Seitenblick auf die
Funktionsdekarationen) nicht unterscheiden, ob ein Objekt "by value"
oder "by reference" an eine Funktion übergeben wird, was zu hässlichen
Fehlern führen kann.
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.
Quote:
Es ist schon hässlich genug, daß C++ drei verschiedene Wege (value,
reference, pointer) der Parameterübergabe erlaubt; daß zwei davon auch
noch (trotz stark unterschiedlicher Semantik) syntaktisch identisch
aussehen, ist einfach Mist.
reference, pointer) der Parameterübergabe erlaubt; daß zwei davon auch
noch (trotz stark unterschiedlicher Semantik) syntaktisch identisch
aussehen, ist einfach Mist.
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.
Quote:
Zweifellos. Man sollte aber genau wissen, welche Konstrukte was hinter
sich her ziehen, sonst tappt man in nullkommanix in die Bloat-Falle.
Dem stimme ich zu.
Na, immerhin.
Ich bleibe dabei: Einem Anfänger würde ich abraten, zumindest auf einem
8-Bitter.
Und ich erweitere: Einem Anfänger würde ich auch von C abraten. Und von
Mikrocontroller-Programmierung allgemein. Von Programmierung allgemein
sogar.
Jeder fängt mal an. Und bei Microcontroller-Programmierung ist es IMO
nicht zielführend, die Abstraktionsebene gleich zu Anfang so hoch zu
schrauben, daß man den Bezug zur Hardware verliert.
Ein bisschen Übung in Assembler oder Assembler-ähnlich benutztem C ist
für das Verständnis ungemein hilfreich.
sich her ziehen, sonst tappt man in nullkommanix in die Bloat-Falle.
Dem stimme ich zu.
Na, immerhin.
Ich bleibe dabei: Einem Anfänger würde ich abraten, zumindest auf einem
8-Bitter.
Und ich erweitere: Einem Anfänger würde ich auch von C abraten. Und von
Mikrocontroller-Programmierung allgemein. Von Programmierung allgemein
sogar.
Jeder fängt mal an. Und bei Microcontroller-Programmierung ist es IMO
nicht zielführend, die Abstraktionsebene gleich zu Anfang so hoch zu
schrauben, daß man den Bezug zur Hardware verliert.
Ein bisschen Übung in Assembler oder Assembler-ähnlich benutztem C ist
für das Verständnis ungemein hilfreich.
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
--
Quote:
Wo hattest Du das Beben nochmal GENAU vorhergesagt?
Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
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 <hidbv3$om2$1_at_speranza.aioe.org>
Johannes Bauer
Guest
Guest
Thu Feb 18, 2010 9:05 pm
Martin Gerdes schrieb:
Quote:
Johannes Bauer <dfnsonfsduifb_at_gmx.de> schrieb:
... gibt nach g++ -O2:
0000000000400590 <main>:
400590: b8 34 12 00 00 mov $0x1234,%eax
400595: c7 05 8d 0a 20 00 34 movl $0x1234,0x200a8d(%rip) #
60102c <x
40059c: 12 00 00
40059f: c3
Welchen Mikrocontroller setzt Du denn da ein?
... gibt nach g++ -O2:
0000000000400590 <main>:
400590: b8 34 12 00 00 mov $0x1234,%eax
400595: c7 05 8d 0a 20 00 34 movl $0x1234,0x200a8d(%rip) #
60102c <x
40059c: 12 00 00
40059f: c3
Welchen Mikrocontroller setzt Du denn da ein?
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.
Quote:
Und ich erweitere: Einem Anfänger würde ich auch von C abraten. Und von
Mikrocontroller-Programmierung allgemein. Von Programmierung allgemein
sogar.
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.
Mikrocontroller-Programmierung allgemein. Von Programmierung allgemein
sogar.
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.
Wenn ich dich recht verstanden habe, hast du die inhärente Ironie meiner
Aufzählung nicht recht verstanden.
Gruß,
Johannes
--
Quote:
Wo hattest Du das Beben nochmal GENAU vorhergesagt?
Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
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 <hidbv3$om2$1_at_speranza.aioe.org>
Frank-Christian Krügel
Guest
Guest
Thu Feb 18, 2010 10:23 pm
Am 18.02.2010 16:54, schrieb Michael Maier:
Quote:
Hallo,
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.
doch noch ne Frage.
Die Anleitung ist in Englisch.
Gibt es deutsche Bücher dann den Controller.
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.
doch noch ne Frage.
Die Anleitung ist in Englisch.
Gibt es deutsche Bücher dann den Controller.
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
Joerg
Guest
Guest
Thu Feb 18, 2010 10:43 pm
Frank-Christian Krügel wrote:
Quote:
Am 18.02.2010 16:54, schrieb Michael Maier:
Hallo,
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.
doch noch ne Frage.
Die Anleitung ist in Englisch.
Gibt es deutsche Bücher dann den Controller.
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.
Hallo,
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.
doch noch ne Frage.
Die Anleitung ist in Englisch.
Gibt es deutsche Bücher dann den Controller.
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.
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.
http://www.sander-electronic.de/bk0003.html
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.
Frank Buss
Guest
Guest
Thu Feb 18, 2010 11:35 pm
Johannes Bauer wrote:
Quote:
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.
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.
Ich für einen Anfänger nicht empfehlen, in C zu programmieren, es sei denn,
man kennt es schon. Einige Gründe gegen C:
http://www.peylow.se/whyihatec.html
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_at_frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
David Kastrup
Guest
Guest
Thu Feb 18, 2010 11:42 pm
Frank Buss <fb_at_frank-buss.de> writes:
Quote:
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.
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.
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
Joerg Wunsch
Guest
Guest
Thu Feb 18, 2010 11:49 pm
Stefan Reuther <stefan.news_at_arcor.de> schrieb:
Quote:
Dass das ein Nachteil sei, ist eine unzulässige
Verallgemeinerung. RISC-Prozessoren können zum Beispiel
ausschließlich indirekt adressieren.
Verallgemeinerung. RISC-Prozessoren können zum Beispiel
ausschließlich indirekt adressieren.
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.
Frank Buss
Guest
Guest
Fri Feb 19, 2010 12:01 am
David Kastrup wrote:
Quote:
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.
dermaßen unsicher ist, ist sie miserabel optimierbar: der Compiler kann
zu wenig Annahmen darüber machen, welche Anweisungen dieselben Daten
betreffen könnten.
In der Theorie mag das stimmen. Die jahrelange Arbeit, die aber in manche C
Compiler gesteckt wurde, wird so schnell kein Compiler einer anderen
Sprache aufholen, insbesondere für Embedded Plattformen, aber auch auf PCs.
Siehe z.B. hier:
http://shootout.alioth.debian.org/u32/c.php
GNU C ist in den meisten Benchmarks gegenüber den anderen Sprachen ca. 2
bis 10 mal schneller und braucht beim Vergleich mit Java z.B. bis zu 79 mal
weniger Speicher.
--
Frank Buss, fb_at_frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Thomas 'tom' Malkus
Guest
Guest
Fri Feb 19, 2010 12:10 am
Frank Buss <fb_at_frank-buss.de> writes:
Quote:
wurde?). Wenn man mal in Java, Lisp, Scala oder D programmiert hat, dann
möchte man eigentlich nicht mehr C oder C++ machen.
möchte man eigentlich nicht mehr C oder C++ machen.
Da muss ich widersprechen! ;-)
Ich verwende immer wieder mal Delphi, Java, PHP und auch Lisp wenn ich
am emacs was brauche (ok, das zählt wohl nicht so richtig), aber am
liebsten ist mir immer noch C/C++. Wobei ich C auch noch vor C++
bevorzuge. Ich benutze ja grafische Benutzeroberflächen auch nur für
viele Terminalsessions und schreibe Briefe mit LaTeX.
Altmodisch halt... Aber dazu stehe ich :)
73 de Tom
--
DL7BJ * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19 * http://www.dl7bj.de
Thomas 'tom' Malkus
Guest
Guest
Fri Feb 19, 2010 12:48 am
j_at_uriah.heep.sax.de (Joerg Wunsch) writes:
Quote:
Thomas 'tom' Malkus <usenet_at_isnix.de> schrieb:
und schreibe Briefe mit LaTeX.
Ich dachte schon, ich wäre da der Einzige.
und schreibe Briefe mit LaTeX.
Ich dachte schon, ich wäre da der Einzige.
Ah, dann sind es schon 3, da gibt es noch jemanden, auch Funkamateur in
d.e.b.s., hatte er zumindest mal erwähnt.
73 de Tom
--
DL7BJ * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19 * http://www.dl7bj.de
Uwe Borchert
Guest
Guest
Fri Feb 19, 2010 12:50 am
Hallo,
Joerg Wunsch schrieb:
Quote:
Thomas 'tom' Malkus <usenet_at_isnix.de> schrieb:
und schreibe Briefe mit LaTeX.
Ich dachte schon, ich wäre da der Einzige.
und schreibe Briefe mit LaTeX.
Ich dachte schon, ich wäre da der Einzige.
Häh? Das ist doch Standard! Mit was kann man sonst noch
hochwertige Briefe schnell und unkompliziert schreiben?
Hab ich da was übersehen?
MfG
Uwe Borchert
Joerg
Guest
Guest
Fri Feb 19, 2010 1:22 am
Thomas 'tom' Malkus wrote:
Quote:
Frank Buss <fb_at_frank-buss.de> writes:
wurde?). Wenn man mal in Java, Lisp, Scala oder D programmiert hat, dann
möchte man eigentlich nicht mehr C oder C++ machen.
Da muss ich widersprechen! ;-)
Ich verwende immer wieder mal Delphi, Java, PHP und auch Lisp wenn ich
am emacs was brauche (ok, das zählt wohl nicht so richtig), aber am
liebsten ist mir immer noch C/C++. Wobei ich C auch noch vor C++
bevorzuge. Ich benutze ja grafische Benutzeroberflächen auch nur für
viele Terminalsessions und schreibe Briefe mit LaTeX.
Altmodisch halt... Aber dazu stehe ich :)
wurde?). Wenn man mal in Java, Lisp, Scala oder D programmiert hat, dann
möchte man eigentlich nicht mehr C oder C++ machen.
Da muss ich widersprechen! ;-)
Ich verwende immer wieder mal Delphi, Java, PHP und auch Lisp wenn ich
am emacs was brauche (ok, das zählt wohl nicht so richtig), aber am
liebsten ist mir immer noch C/C++. Wobei ich C auch noch vor C++
bevorzuge. Ich benutze ja grafische Benutzeroberflächen auch nur für
viele Terminalsessions und schreibe Briefe mit LaTeX.
Altmodisch halt... Aber dazu stehe ich :)
Briefe in LaTeX? Wow. Dann hast Du frueher bei Klausuren wo
Taschenrechner erlaubt waren vermutlich auch wie unsereins eine
Verlaengerung gelegt, Klingeltrafo an geklemmt, Linearregler auf
Lochraster da dran und in den Texas SR50 gestoepselt :-)
--
Gruesse, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
elektroda.net NewsGroups Forum Index - Electronics DE - Mikrocontroller - C oder C++
