Lieber Besucher, herzlich willkommen bei: RCLine Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

Feuerstein

RCLine User

  • »Feuerstein« ist der Autor dieses Themas

Wohnort: D-14552 Langerwisch

  • Nachricht senden

1

Donnerstag, 16. September 2004, 16:48

Controler (Typ) gesucht

Hallo,

ich suche einen Controler mit min. 6 analogen Eingängen. 8 digitale Ausgänge und interne Uhr sollten möglichst auch vorhanden sein. Ich möchte Spannungen, oder besser Themperaturen über vorhandene und schon eingebaute NTC Widerstände messen und auswerten.
Der Controler soll später in einer Heizungssteuerung für ein EFH werkeln.
Ich weiß,....es ist kein Modellbau.... ==[] bitte nicht hauen......
Habe schon etwas mit SIEMENS Logo + Erweiterungen experementiert, komme da aber schnell an die Grenze der Software.
Was gibt es da noch so für Möglichkeiten?

Danke
Fred

2

Donnerstag, 16. September 2004, 16:52

Hi..

Atmel Attiny26.
Bequem in C Programmierbar, 16 I/O-Pins, ADC, Timer, Quarz oder interner RC-oszillator, ca. 2.5 Euro.

Datenblatt und weitere Infos entweder beim Hersteller oder www.avrfreaks.net

Auch hier mal die Suchmaschine dazu anwerfen, sind schon ein paar kleinere Projekte damit gelaufen.

mfg
andi

K_Mar

RCLine User

Wohnort: D-76337 Waldbronn-Reichenbach (Karlsruhe) 1988-2005 Seesen/Harz; davor Hannover Modellbau seit 1974

Beruf: Dipl.Ing./Leistungselektr.entw. mW-MW z.Z.Antriebstechn.,früher Stromvers. (incl.Treiber+Messtechn.)

  • Nachricht senden

3

Donnerstag, 16. September 2004, 18:58

Hallo,
schau Dir mal den ATmega 48 (Atmel) oder den älteren Mega8 an.

Gruß Klaus
Fahrzeuge auf dem Wasser bewegen macht Spaß und ist ein optimaler Testbereich für Elektronikentwicklungen

Feuerstein

RCLine User

  • »Feuerstein« ist der Autor dieses Themas

Wohnort: D-14552 Langerwisch

  • Nachricht senden

4

Donnerstag, 16. September 2004, 21:07

Hallo,

danke für die Tips.
Mit ATMEL Prozessoren habe ich mich vor längerer Zeit schon mal beschäftigt, da gab es den ATMega noch nicht oder ich habe ihn nicht beachtet???.
Habe noch eine ältere Testplatine für den AT90S8535 o.ä. Muss mal die Beschreibung ausgraben. Kurze Programme (Auswertung Fernsteuerimpuls) sind mir auch gelungen.
Ich werde mal versuchen, ein Starterkit zu erwerben oder unter http://www.mikrocontroller.com/ gibt es eine ähnliche Lösung, auch zur Heizungssteuerung.
Mit C komme ich nicht klar, ich bin mit Assembler "groß" geworden und habe später bei TurboPascal aufgehöhrt.


Fred

5

Freitag, 17. September 2004, 07:46

Hi..

du MUSST ja nicht c nehmen... assembler geht natürlich genauso. Für 90% der Leute ist halt die Hochsprache eher ne Entlastung.

mfg
andi

6

Freitag, 17. September 2004, 07:47

Zitat

Original von Feuerstein
...
Mit C komme ich nicht klar, ich bin mit Assembler "groß" geworden und habe später bei TurboPascal aufgehöhrt.


Fred


hi,
ich finde C ist die sinnvollste sprache die es gibt ;)
für mich ist C so lesbar wie als ob ich tageszeitung lese.
dagegen ist zb assembler für mich unverständlich und umständlich.
naja, ich hab ja auch zuerst C gelernt und dann teilweise assembler ;)
grüsse
Klang ?

Car Hifi ?

Sound pur im Auto ?

besser gehts immer !

hier bist du richtig :D


[SIZE=4][/SIZE]

K_Mar

RCLine User

Wohnort: D-76337 Waldbronn-Reichenbach (Karlsruhe) 1988-2005 Seesen/Harz; davor Hannover Modellbau seit 1974

Beruf: Dipl.Ing./Leistungselektr.entw. mW-MW z.Z.Antriebstechn.,früher Stromvers. (incl.Treiber+Messtechn.)

  • Nachricht senden

7

Freitag, 17. September 2004, 17:30

Hallo,
wenn man`s kann, dann bringt Assambler die besseren Ergebnisse.

Gruß Klaus
Fahrzeuge auf dem Wasser bewegen macht Spaß und ist ein optimaler Testbereich für Elektronikentwicklungen

8

Freitag, 17. September 2004, 17:52

Die Besseren sicher nicht. Eventuell die gleichen in weniger Zyklen. ;)

Allerdings ist C eine derart hardwarenahe Sprache, daß man sehr viele Sachen in C eins zu eins so schreiben kann, wie man sie in Assembler meint.

Die Lesbarkeit und Portierbarkeit von C ist um Längen besser als in Assembler und der Entwicklungszyklus um Längen schneller. Wenn dafür die Ausführungsgeschwindigkeit sinkt, aber immer noch innerhalb des Erträglichen liegt, so what? Die inneren Schleifen noch in Assembler optimiert und schon ist der Performanceunterschied unter 5%. Bei RISC-Architekturen hast Du von Hand kaum noch eine Chance längere Algorithmen für den jeweiligen Prozessor zu optimieren.

Natürlich kann man in Assembler das letzte Byte nutzen, wenn man allerdings genug Bytes hat, kann man sie auch nutzen... :D:D:D

Meiner Erfahrung nach bringt Assembler auf der i386er plattform im Durchschnitt ~30% Geschwindigkeitsvorteil...

Grüße
Malte

PS: für viele Sachen nehme ich schon länger Python. DAS bringt Zeitersparnis beim Entwickeln :) ...

PPS: ich sehe mir aber noch heute den Assembler Output meines C++-Compilers an, um die Effizienz meiner Sourcen zu beurteilen oder zu optimieren.

9

Dienstag, 21. September 2004, 14:49

ne wirkliche Hochsprache ist Pascal :)

Das war die Rache der Mathematik an der Informatik, wie böse Zungen behaupten...

Viel wichtiger als ein guter Assembler oder Compiler ist eine vernünftige Entwicklungsumgebung, damit die Software auch richtig getestet werden kann. Und da würde ich als "Heimanwender" Wert auf ein preisgünstiges, aber sehr komfortables System legen.
Da spielt dann der Controller nicht unbedingt eine Rolle. Man kann auch einen externen A/D-Wandler nehmen, der ist auch noch genauer als die integrierten Teile. Speziell im Bereich Heizungssteuerung spielt ja die Baugröße oder der Stromverbrauch nicht ganz die Rolle. Und die 30 Euro für einen externen Wandler sind bei den 500 Euros, die ein einfacher Emulator für ein spezielles Derivat kosten würde, auch leicht zu verschmerzen...

10

Dienstag, 21. September 2004, 19:30

[offtopic]

Zitat

ich finde C ist die sinnvollste sprache die es gibt augenzwinkern
für mich ist C so lesbar wie als ob ich tageszeitung lese.
dagegen ist zb assembler für mich unverständlich und umständlich.
naja, ich hab ja auch zuerst C gelernt und dann teilweise assembler

Wie verschieden zum Glück die Menschen sind. Für mich ist C die fürchterlichste Programmiersprache seit Erfindung des Computers. Da ist sogar Assembler noch schöner.

Wie gesagt, ist meine eigene, persönliche Meinung. :D

Naja, hab zuerst PASCAL gelernt und muss mich jetzt beruflich mit einer "Art C" rumschlagen. Und die ist wirklich :puke:
[/offtopic] :nuts:

OK, auch was zum Thema: Ich programmiere die AVRs gerne mit dem BASCOM-Basic-Compiler von MCS-Electronic. Der ist im weitesten Sinne Visual Basic compatibel (falls man solche Paralellitäten überhaupt ziehen kann), erzeugt gut optimierten Code, hat eine komplette IDE incl. Programmer dabei, mit der man auch Sonderzeichensätze für LCD-Displays generieren kann, hat Software-Lösungen für alle möglichen Schnittstellen (I²C, ISP, 1Wire, MD5, Sony-IR, serriell usw.), Unterstützung der meisten Atmel-Käfer usw.....

und nochmal [offtopic]

10 Gründe, warum Pascal besser ist als C

1. Pascal wurde als vornehme Sprache nach einem berühmten französischen Mathematiker und Philosph, Blaise Pascal, benannt. C wurde nach einem Buchstaben in der Sesamstraße benannt.

2. Pascals Erfinder, Niklaus Wirth, und Konventionen, Parameter zu übergeben, erlauben ein geschicktes Wortspiel: Man kann seinen Namen aussprechen als Referenz: Wirth, oder als Wert: Worth. C wurde in den Bell-Labs erfunden, wo man keinen Witz von einem Transistor unterscheiden kann.

3. Es gibt nur ein Pascal, das von Wirth definiert wurde, während C (sollen wir es sagen?) mehrere Väter hat: Kerninghan & Ritchie, Harbison & Steele, Barnum & Bailey und Laurel & Hardy.

4. In C sind die folgenden Variablen alle verschieden: thesame, TheSame, theSame und THESAME. Das sagt alles.

5. Wenn man in Pascal mit einem Zeiger oder einem Handle spielt, weiß man, dass man mit einem Zeiger oder einem Handle spielt. In C könnte man mit allem spielen. C ist die ultimative Sprache für häufigen Computerwechsel.

6. In Pascal *wissen* wir, wie groß ein Integer ist.

7. C wird von Liberalen, Demokraten und Programmierertypen wie Mike Dukakis verwendet. Pascal ist ein Favorit der Konservativen. Hey, wir wissen, welches die große Programmiersprache in Berkeley ist, oder?

8. C ist die einzige Sprache in der zivilisierten Welt, die es immer noch ablehnt, das Dollarzeichen für hexadezimale Konstanten anzuerkenen, und fortfährt dafür zu werben, dass diese Basis Anspruch auf den Thron hat: 0x00.

9. Pascal hat gut definierte Regeln für Scope*, während es scheint, dass C Listerine* verwendet. Das erklärt den medizinisch-alkoholischen Atem vieler C-Programmierer.
* Scope und Listerine sind zwei Marken von Mundwasser in den USA; in einer Werbekampagne verbreitete Scope, dass Listerine-Nutzer "medicine breath" hätten.

10. In C kann man dieses tun:
for(;P("\n").R-;P("|"))for(e=3DC;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);
In Pascal kann man dieses NICHT tun:
for(;P("\n").R-;P("|"))for(e=3DC;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);

[/offtopic] :nuts:
Gruß,
Jürgen
_________________________________________
[SIZE=1]klein: Micron V2
mittlel: GAUI EP100
größer: Fun Piccolo boardless brushless brushless
noch größer: Align T-Rex 450 S Carbon
groß: Logo 20[/SIZE]

11

Mittwoch, 22. September 2004, 14:50

Ich will jetzt nicht trollen, sondern wirklich eine ernsthafte Diskussion.

Mein Umstieg von Pascal nach C kam, als ich ein Projekt begann, in dem ich Ein Bild laden musste, dessen Größe zur Kompilationszeit noch nicht bekannt war.

Das geht in Standard Pascal gar nicht und in TurboPascal muss man sich heftig verrenken, um die Typprüfung durch den Compiler zu umgehen.

In C geht eigentlich fast alles, deswegen sind auch fast alle Betriebssysteme in C gesschrieben.

Mann MUSS in C auch nicht dreckig programmieren, aber man kann es und das ist ein Vorteil und kein Nachteil! ;)

z.B. Kann man einfachst und architekturunabhängig im Speicher herumwerkeln, wenn man es möchte.

unsigned char *mem = 0;
/* Zeiger auf Adresse 0 */

mem[0] = 0;
/* löschen */
mem[0] |= 0x01;
/* Bit 0 setzen */

mem[0] |= 0x80;
/* Bit 7 setzen */

etc.

In Assembler schreibst Du das für jede Architektur und ggf für jeden Assembler darauf neu. ;)

Wo ist denn Dein konkretes Problem mit C?

Wenn es die Pointer bei der Parameterübergabe sind könntest Du auch einen
Blick auf C++ werfen, da gibt es z.B. echte Referenzen.

Grüße,
Malte


PS: BTW, ich kenne die Einstellung "Programmiersprache XYZ ist scheiße" nur zu gut.
Bei mir sind es Modula, Java, Visual Basic, Perl etc, die ich nicht mit der Kneifzange anfassen würde. Bei C lohnt sich aber eine erneute unverkrampfte Überprüfung! Spart wirklich einen HAUFEN Arbeit ;)
PPS: Wenn Du eine wirklich tolle Programmiersprache kennenlernen willst, versuch' mal Python. Zwar kein Effizienzwuder, aber höchst einfach und elegant

12

Mittwoch, 22. September 2004, 19:14

hi,
ein kleines beispiel:
{
char apfel=0;
char birne=0;
char obstimkorb=0;

obstimkorb=apfel+birnen;
}

für mich ist das absolut verständlich, diese kleine rechnung. warum zb sollte ich überhaupt die äpfel oder birnen in ein register schieben ( wie in assembler ) um das obst zusammen zu rechen.

mit pascal oder sonstwas hab ich mich nicht beschäftigt.
ich kenne nur C, C++, Java, assembler.
grüsse
Klang ?

Car Hifi ?

Sound pur im Auto ?

besser gehts immer !

hier bist du richtig :D


[SIZE=4][/SIZE]

13

Mittwoch, 22. September 2004, 22:41

Auwei, nur keinen Glaubenskrieg anfangen... :evil: :evil:

Was mir an C nicht gefällt:
- Extrem kryptische Schreibweisen möglich (ok, muss man nicht tun, ist aber verbreitet)
- Rumhantiererei mit Zeigern ist fehlerträchtig
- Ich will nicht immer auf Groß-/Kleinschreibweise achten (wieder fehlerträchtig)

Der Vorteil ist natürlich die extrem weite Verbreitung. Allerdings wird es für sicherheitsrelevante Bereiche nicht verwendet (Raumfahrt, Flugzeugindustrie). BTW, wird Software im KfZ-Bereich in C programmiert? Weiß das jemand?
Gruß,
Jürgen
_________________________________________
[SIZE=1]klein: Micron V2
mittlel: GAUI EP100
größer: Fun Piccolo boardless brushless brushless
noch größer: Align T-Rex 450 S Carbon
groß: Logo 20[/SIZE]

14

Donnerstag, 23. September 2004, 01:54

Zitat

Auwei, nur keinen Glaubenskrieg anfangen...

IWO!! Allerdings denke ich schon, daß Du etwas verbohrt bist ;)

Zitat

Was mir an C nicht gefällt:
- Extrem kryptische Schreibweisen möglich (ok, muss man nicht tun, ist aber verbreitet)

Ach so, Assembler ist nicht kryptisch, ich vergaß... :D:D:D

Der meiste C-Source-code der im Netz herumgeistert ist schlimm, aber wenn die selben Leute Pascal programmieren würden, käme auch nichts besseres 'raus.
Und wo *a++ = *b++ kryptischer ist als mov (a0)+, (a1)+ musst Du mir auch noch zeigen. Macht übrigens beides das gleiche...


Zitat

- Rumhantiererei mit Zeigern ist fehlerträchtig

Rumhantieren mit einer Drehbank auch.
Wenn man damit nicht umgehen kann ist der Umgang mit einem mächtigen Werkzeug wie C IMMER gefährlich. Man kann nämlich fast alles damit machen. Incl. Betriebssysteme schreiben. Was mit Pascal leider nicht geht :evil: Und mit Assembler wären wie heute noch bei cp/m...

In C wirst Du außerdem gewarnt, in C++ ist es nahezu unmöglich, böse Zeigerfehler zu machen.

Zitat

- Ich will nicht immer auf Groß-/Kleinschreibweise achten (wieder fehlerträchtig)

Dann schreib halt immer klein. Unter Unix sind Dateinamen im übrigen auch case-sensitiv ;) Außerdem werden Dir diese Fehler vom Compiler gemeldet. Führen also nicht zu Programmabstürzen...

Zitat

Allerdings wird es für sicherheitsrelevante Bereiche nicht verwendet (Raumfahrt, Flugzeugindustrie).

Sind bloß alle Unices und Derivate, sowie nahezu sämtliche Datenbank/Web/Mail/File/Name- etc. Server in C programmiert, die so ziemlich das gesamte Interenet ausmachen. (Viele allerdings von Pfeifen, die Bufferoverflows nicht vermeiden können :D)
Unser Primärer Nameserver hat übrigens heute 365 Tage Uptime (unter 'nen OS, welches in C geschrieben ist) Mir reicht das eigentlich an Stabilität und Ausgereiftheit.


Grüße
Malte

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »DrM« (23. September 2004, 01:57)


15

Donnerstag, 23. September 2004, 07:36

Zitat

Allerdings denke ich schon, daß Du etwas verbohrt bist

ICH?? NIEMALS!! Allerhöchstens ein ganz klein wenig. [SIZE=1]Naja, vielleicht in dieser Beziehung doch etwas. Schlimm?[/SIZE] :tongue:

Zitat

Ach so, Assembler ist nicht kryptisch, ich vergaß...

Kommt drauf an. PIC und 6502 sind meiner Meinung nach gräßlich, der von AVR ist ganz ok, am besten hat mir der vom Z80 gefallen :)

Zitat

*a++ = *b++ ... mov (a0)+, (a1)+

a := b;
inc(a);
inc(b);

Gefällt mir besser :D :D :D
Außerdem gibt es nicht bei jedem Assemblerdialekt ein Postinkrement für Register.

Zitat

Rumhantieren mit einer Drehbank auch

Bis jetzt hab ichs überlebt ==[]

Zitat

Sind bloß alle Unices und Derivate, sowie nahezu sämtliche Datenbank/Web/Mail/File/Name- etc. Server in C programmiert, die so ziemlich das gesamte Interenet ausmachen. (Viele allerdings von Pfeifen, die Bufferoverflows nicht vermeiden können )
Unser Primärer Nameserver hat übrigens heute 365 Tage Uptime (unter 'nen OS, welches in C geschrieben ist) Mir reicht das eigentlich an Stabilität und Ausgereiftheit.

Hm, das macht es mir leider auch nicht schmackhafter. Das man unter C stabile Software schreiben kann, ist mir klar, das geht aber genausogut auch mit anderen Programmiersprachen.
Den einzigen Vorteil, den ich sehe, ist die hohe Portabilität zwischen verschiedenen Systemen. Sun, AS/400, X86... egal. Außer man greift direkt auf die Hardware zu, dann ist es mit der Portabilität vorbei, siehe dein erstes Programmbeispiel:

unsigned char *mem = 0;
/* Zeiger auf Adresse 0 */

mem[0] = 0;
/* löschen */
mem[0] |= 0x01;
/* Bit 0 setzen */

mem[0] |= 0x80;
/* Bit 7 setzen

Würde aber auch so gehen:

VAR mem: byte absolute $0000;
mem:=0 {löschen}
mem:=mem or $01 {Bit 0 setzen}
mem:=mem or $80 {Bit 7 setzen}

Ist für den Gelegenheitsprogrammierer einfach besser zu lesen. Oder:

clr r16
out $00, r16 ; löschen
sbi $00, 0 ; Bit 0 setzten
sbi $00, 7 ; Bit 7 setzten
Gruß,
Jürgen
_________________________________________
[SIZE=1]klein: Micron V2
mittlel: GAUI EP100
größer: Fun Piccolo boardless brushless brushless
noch größer: Align T-Rex 450 S Carbon
groß: Logo 20[/SIZE]

16

Donnerstag, 23. September 2004, 14:59

Zitat

a := b;
inc(a);
inc(b);

Gefällt mir besser

Macht aber nicht das gleiche! a und b sind Zeiger und es müsste heißen a^ := b^;
(geht dann noch inc??) .

Es sollten eigentlich die Daten von der Adresse auf die b (a1) zeigt dahin geschaufelt, wohin a (a0) zeigt wobei beide Zeiger danach um eins erhöht sind;) Du erhöhst nur die Werte von a und b. Außderdem mit einem einfachen #define inc(x) (x++) kannst Du Deine Abneigung gegen ++ bewältigen ;)

Zitat

Außerdem gibt es nicht bei jedem Assemblerdialekt ein Postinkrement für Register.

Deswegen macht man es doch in C. Man muss nicht immer alles neu schreiben.
Der Compiler weiß, ob der Prozessor es in ein oder mehr Instruktionen ausführt.

Zitat

VAR mem: byte absolute $0000;
mem:=0 {löschen}
mem:=mem or $01 {Bit 0 setzen}
mem:=mem or $80 {Bit 7 setzen}

Ist für den Gelegenheitsprogrammierer einfach besser zu lesen.


Für den TurboPascal-Programmierer, das ist ja nicht mal Pascal sondern TurboPascal. Pascal kann weder 'absolute' noch bitweise Operatoren. Und ich hatte mein Beispiel extra so gewählt, daß der Speicher ein Array ist und man problemlos alle Adressen erreichen kann. also auch mem[1] , mem[2] etc.

Aber für den TPfreund mal in c++:

Im Header
typedef byte unsigned char;
#define absolute( type, addr ) (*(type*) addr )
#define or |

Source:
byte &mem =absolute( byte, 0 );
mem = 0;
mem = mem or 0x01;
mem = mem or 0x80;

Sieht dach fast gleich aus ;)
Turbo-Pascal ist (war?) schon klasse, und man hat(te) viele Probleme nicht, die man mit normalem Pascal hat. Allerdings muss(te) man auch mit Turbo-Pascal bei "echten" Projekten den Compiler deratig "beschubsen", daß von der Typsicherheit nicht mehr viel übrigbleibt.

Es gibt in c den Unterschied zwischen logischen und bitweisen boolschen operatoren. ( && vs. & ) und die shortcut evaluation wird garantiert.

if( false && myFunction() ) bla();
ist garantiert, daß myFunction nicht aufgerufen wird. das ist sowohl effizient als auch praktisch...

Noch ein Problem bei Pascal: das Linken. Durch die Aufruf-Konvention kann man Pascal nicht gegen Standardbibliotheken linken. Und die Ausgaberoutinen sind auch nicht das Gelbe. write und writeln sind keine Prozeduren, sondern werden vom Compiler in eine Reihe von Prozeduraufrufen je nach Parameteranzahl umgewandelt. Das war selbst Wirth zu wild und der Nachfolger von Pascal, Modula 2 hat mit diesem Wildwuchs aufgeräumt. Aber da wird die formatierte Ausgabe aber dann schon lächerlich kompliziert im Vergleich zu printf.
Auch die Array-Initialisierung ist in Pascal nicht möglich. (TP schon)

Hach... C(++), meine Zweitlieblingssprache nach python ;)

Grüße
Malte

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »DrM« (23. September 2004, 15:08)


17

Donnerstag, 23. September 2004, 20:09

Zitat

Macht aber nicht das gleiche! a und b sind Zeiger und es müsste heißen a^ := b^;
(geht dann noch inc??) .

Aha. Zeiger übersehen, Schwachsinn programmiert ;( ;(
Ja, das geht...

a^ := b^;
inc(a^); { Inhalt erhöhen }
inc(a); { Zeiger erhöhen }
inc(b^);
inc(b);

... sieht das dann in C so aus?

*(a++)++ = *(b++)++

Zitat

Aber für den TPfreund mal in c++:

Im Header
typedef byte unsigned char;
#define absolute( type, addr ) (*(type*) addr )
#define or |

Source:
byte &mem =absolute( byte, 0 );
mem = 0;
mem = mem or 0x01;
mem = mem or 0x80;

Sieht dach fast gleich aus ;)

Hey, damit kann man ja richtig sauber programmieren :evil: :evil: :evil:
Und irgendein Preprocessor macht dann daraus:

byte &mem = *(byte*) 0 // Wozu jetzt das &?
...
mem = mem | 0x01
mem = mem | 0x80 ?

Ich fasse mal zusammen:
- C ist extrem mächtig (die obigen Beispiele sind überzeugend)
- man kann in C (für nicht C-Benutzer) "lesbar" programmieren, muss aber nicht
- TP oder neuerdings FreePascal (Portabilität!) kann es (fast?) genausogut
- Standard-Pascal kommt nicht mal annähernd dran!
:ok: ?

Zitat

DrM, Referent für Indoor-C

Cool, haste das jetzt extra wegen diesem Thread gemacht? :D :D
Gruß,
Jürgen
_________________________________________
[SIZE=1]klein: Micron V2
mittlel: GAUI EP100
größer: Fun Piccolo boardless brushless brushless
noch größer: Align T-Rex 450 S Carbon
groß: Logo 20[/SIZE]

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Juergen_D« (23. September 2004, 21:07)


18

Freitag, 24. September 2004, 02:15

Nee, das wird genau Da abgeschnitten ;) Sollte eigentlich Indoor-C++ heißen :D:D (Neee, Indoor-Combat natürlich!)

Deine Zusammenfassung trifft es sehr gut!

Zitat



a^ := b^;
inc(a^); { Inhalt erhöhen }
inc(a); { Zeiger erhöhen }
inc(b^);
inc(b);

... sieht das dann in C so aus?

*(a++)++ = *(b++)++


Nein,
Du darfst einen den Wert des Ergebnisses einer Zuweisung {(b++) ist auch eine} nicht incrementieren, a + 1 = b; geht ja auch nicht!

Muss man schon so schreiben:
*a++ = *b++; // ++ bindet stärker als *, daher wird erst zugewiesen, dann die Pointer erhöht
(*a)++; // Dereferenzierung erzwingen und das worauf gezeigt wird incrementieren
(*b)++;

Früher, als die Compiler noch dumm waren und nicht optimieren konnten, waren Konstrukte wie
while( *a++ = *b++ ) ; absolut genial, da der Compiler das 1:1 in PDP11-Code oder Code ähnlicher Architekturen umsetzen konnte.

Assembler etwa so:

loop:
mov (a0)+, (a1)+
jnz loop

Pascal:
a^ := b^;
while( ord( a^ ) != 0 ) begin
inc( a );
inc( b );
a^ := b^;
end;

Da muss ein Compiler lange grübelm, bis er erkennt, was Du meinst :)

----

Das '&' in meinem C++ Beispiel erzeugt eine Referenzvariable.

Intern funktioniert das wie ein Pointer, aber in der Source benutzt man es wie eine "normale" Variable.
Sehr elegant für Parameterübergabe "by Reference", wenn man keine Pointer mag.
Wenn man dann noch const vor die Eingangs-Parameter schreibt, kann man die in der Funktion nicht mehr ändern, was programmierfehler vermeiden hilft.

Beispiel für const:

void copy( int &dest, const int &src )
{
dest = src; // geht
src = dest; // geht nicht, compile error
}

void x()
{
const int a = 10;
int b;

copy( b, a ); // geht
copy( a, b ); // geht nicht, compile error
}

hat mir schon oft den A**** gerettet ;)

Grüße
Malte

PS: zu FreePascal kann ich nichts sagen, kenne ich nicht.
PPS: Na gut, kann doch was sagen ;) http://www.pbm.com/~lindahl/real.programmers.html :D:D:D

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »DrM« (24. September 2004, 02:27)