Hallo, ich wollte nur mal in die Runde nach langjährigen Erfahrungen mit Basic und C in der Mikrowelt fragen. Ist (compiliertes, asmgetuntes) Basic wirklich so schlecht gegenüber C, z.B. dass es gar nicht erst in Linuxen dabei ist oder wäre ein kleiner Basicinterpreter im Handy wirklich zuviel gewesen?
Wenn's kompiliert ist, warum sollte es dann noch interpretiert werden? Gruß Jonas
Muss man sich, wenn man "C" verwendet, eher mehr oder weniger Gedanken um eine korrekte Umsetzung von Befehlen machen? "C" ist eine Assemblersprache, aus einem Befehl ist ersichtlich, welchen Byte-Code oder welches Assembler-Statement er generiert, solange man die Hardware, für die man schreibt, kennt. Erst mit Bascom schreiben und daran dann nachher noch am Disasm rumfummeln zu müssen, da wäre doch ein bisschen inline-Assembler schöner, da man die "Ich-habe-Assembler-nötig"-Stellen direkt in den Code einbinden kann. Für mehr Konsistenz und bessere Pflegbarkeit von Code. Kennt Bascom sowas wie inline-Assembler? mfg mf
Asmhobbyist schrieb: > Ist (compiliertes, asmgetuntes) Basic wirklich so schlecht gegenüber C, Nein. Was halt nicht immer goutiert ist die dynamische Speicherverwaltung gängiger Basic Dialekte, Garbage Collector und dergleichen. > z.B. dass es gar nicht erst in Linuxen dabei ist Das halte ich für ein Gerücht. Auch wenn dein Lieblingsinterpreter und/oder Compiler nicht vorinstalliert ist - als Paket gibt's ihn bestimmt. > oder wäre ein kleiner > Basicinterpreter im Handy wirklich zuviel gewesen? Im Handy? Das scheint mir doch ne andere Liga zu sein als PCs und Mikrocontroller, auch wenn die Leistungsfähigkeit von den ARMs irgendwo dazwischen liegt.
Es gibt "Handyhersteller", generell keine Programmiersprache in ihren Geräten mögen. Egal ob Basic oder was anderes. Bei Linux steht dir doch frei, welche Programmiersprachen und Compiler/Interpreter du installierst. Warum sollte der Hersteller das generell für alle Anwender vorgeben?
>Kennt Bascom sowas wie inline-Assembler? >mfg mf ich glaub schon, wenn ich mich recht errinnere. aber in c zu inlinen, macht auch kein spass :( gruß jonas
Außerdem haben die meisten handys eh ne javavm, warum dann noch basic?
Es gruselt mich bei dem Gedanken an Basic ... Basic ist irgendwie wie einen Pudding an die Wand nageln. C ist präzise, schnell und man kann auch große System damit realisieren. Eigentlich habe ich noch nichts anderes gebraucht (weder Java noch PHP). Probiert schon einiges. Im Gegensatz zu einem spezialisierten Basic-Dialekt (!) kann C sehr abstrakt oder eben maschinennah sein. Einfach eine geniale Konzeption. Der Sprachentwurf hat schon gestimmt - es funktioniert einfach.
Joachim Drechsel schrieb: > Basic ist irgendwie wie einen Pudding an die Wand nageln. Ooch, wenn Du die mittlere Qualität der im Forum zu sehenden C-Codes betrachtest, dann würde ich sagen Pudding annageln wird oft genug mit C versucht. > Es gruselt mich bei dem Gedanken an Basic Mich nicht, wird wohl dran liegen, dass Du es nicht kannst. Kommt eben ganz darauf an, wofür man was verwendet. > kann C sehr abstrakt oder eben maschinennah sein. Je Maschinen-näher, desto weniger portierbar. Asmhobbyist schrieb: > z.B. dass es gar nicht erst in Linuxen dabei ist Linux setzt bereits eine gewisse Leidensbereitschaft voraus, da passt dann C besser rein als ein Basic. :D
Mini Float schrieb im Beitrag #2513836 > "C" ist eine Assemblersprache, aus einem Befehl ist ersichtlich, welchen > Byte-Code oder welches Assembler-Statement er generiert, solange man die > Hardware, für die man schreibt, kennt. Frage aus reinem Interesse, ich hab mir darum bisher wirklich noch keine Gedanken gemacht. Woher weist man welches Assembler-Statement aus meinem C-Code generiert wird. Den Assembler-Code wie er im Datenblatt des uC angeführt ist? Sind die Assambler und C-Beispiele wie sie in den AVR-Datenblättern stehen im compilierten Zustand eqivalent?
Mini Float schrieb: > "C" ist eine Assemblersprache, aus einem Befehl ist ersichtlich, welchen > Byte-Code oder welches Assembler-Statement er generiert, solange man die > Hardware, für die man schreibt, kennt. Was ein Quatsch. C ist immernoch eine Hochsprache und was der Compiler daraus dann für ASM Code generiert hängt von verschiedenen Aspekten ab wie z.B. Compiler selber, Optimierungsstufe usw. Nur mit Assembler direkt weißt du genau welche Befehle der Controller wann bekommt. Was aber nicht gegen C spricht. Grundsätzlich würde ich C auf einem Controller jeder anderen Sprache vorziehen, als erstes und vor allem Basic. Richtig ist, C ist darauf optimiert, gut in ASM übersetzt zu werden und richtig ist auch, die AVRs sind auf C optimiert. @Michael: Stimmt halt auch einfach nicht was da geschrieben wurde, man weiß es eben nicht. Und man will es auch nicht wissen. Das ist ja der Trick. Ich schreibe was ich haben möchste und der Compiler soll gefälligst gucken wie er das am optimalsten (z.B. schnellstens, kleinstens) umsetzt. gruß cyblord
cyblord ---- schrieb: > richtig ist auch, die AVRs sind auf C optimiert. Quatsch. Du kannst C dazu bringen an AVR's angepasst zu sein, aber nicht umgekehrt. Nenn' doch mal ein paar der "C-Optimierungen".
Hi >Quatsch. Du kannst C dazu bringen an AVR's angepasst zu sein, aber nicht >umgekehrt. Sieht ATMEL anders: http://www.atmel.com/dyn/resources/prod_documents/doc1497.pdf MfG Spess
Joachim Drechsel schrieb: > C ist präzise Nein. Weder von der Sprache her (alles, was interessant ist, ist implementation defined, unspecified oder gar gleich undefined). Noch in der praktischen Anwendung. Du kannst ja nichtmal das Speicherlayout einer struct vorgeben oder aus der Deklaration ablesen.
cyblord ---- schrieb: > richtig ist auch, die AVRs sind auf C optimiert. Nicht ganz richtig: Die AVRs sind nicht möglichst gut auf C optimiert (dann hätten sie wohl eine von Neumann-Architektur), sondern sie sind so optimiert, dass ein C-compiler trotz harvard (welche wegen der Geschwindigkeit unumgänglich ist/war) recht gut mit ihnen klarkommt (z.B. memory-mapped register) auch die 32 GP-Register helfen dem Compiler weniger Zeit mit Laden & Rückspeichern zu verbringen.... Einem menschlichen assembler-progger ist das aber nätürlich auch eine Hilfe....
XTerminator schrieb: > Du kannst ja nichtmal das > Speicherlayout einer struct vorgeben oder aus der Deklaration ablesen. So? Vom GNU-Compiler kenne ich es eher andersrum: Man muss sich selbst überlegen, wie man die Members anordnet, damit sich eine kompakte Alinierung gemäß der Maschinenbreite ergibt. mfg mf
cyblord ---- schrieb: > Stimmt halt auch einfach nicht was da geschrieben wurde, man weiß es > eben nicht. Und man will es auch nicht wissen. Das ist ja der Trick. Ich > schreibe was ich haben möchste und der Compiler soll gefälligst gucken > wie er das am optimalsten (z.B. schnellstens, kleinstens) umsetzt. Danke für die rasche Antwort. So hatte ich das ursprünglich auch verstanden. Ich war durch Mini Float`s Post verunsichert. lg Michael
Max schrieb: > cyblord ---- schrieb: >> richtig ist auch, die AVRs sind auf C optimiert. > > Nicht ganz richtig: Die AVRs sind nicht möglichst gut auf C optimiert > (dann hätten sie wohl eine von Neumann-Architektur), sondern sie sind so > optimiert, dass ein C-compiler trotz harvard (welche wegen der > Geschwindigkeit unumgänglich ist/war) recht gut mit ihnen klarkommt > (z.B. memory-mapped register) auch die 32 GP-Register helfen dem > Compiler weniger Zeit mit Laden & Rückspeichern zu verbringen.... > Einem menschlichen assembler-progger ist das aber nätürlich auch eine > Hilfe.... Und was war jetzt an meinem Posting "nicht ganz richtig"? Ich schrieb nirgends dass AVRs kompromisslos auf C optimiert sind, aber sie sind. gruß cyblord
Sieh es einfach mal so: C ist normiert und es gibt Compiler für nahezu jeden Prozessor or Betriebssystem. ==> Das heißt du musst dich gar nicht darum kümmern wie der ASM Code aussieht, das macht der Compiler. Wenn du den ASM lesen und bei Bedarf optimieren kannst ist das allerdings durchaus von Vorteil. Dieses Optimieren aber nciht durch rumpfuschen im erzeugten ASM Code, sondern durch optimieren des C Codes damit der Compiler die Chance hat was gutes zu erzeugen. Wenn du C Kannst kannst du vom kleinsten µC bis zum Top PC mit Windows 7 ,...... alles programmieren. Das von C abgeleitete Dialekte oder Nachfolger wie C# ; .Net,.... das in speziellen Umgebungen einfacher machen ist was anderes. Aber Grundsätzlich geht das auch in C, Ok deutlich mehr aufwand ein Window selbst zu programmieren als in .Net nur eine Funktion zu rufen....... aber es geht und das Schema ist das gleiche. Basic dagegen ist nur auf wenigen Prozessoren verfügbar, und vor allem immer anders. ==> Das heißt Bascom kannst du, dann zu VB und du fängst fast von vorne an. Wie gut der jeweilige Compiler den Basic oder C Code in ASM umsetzt hängt von vielen Faktoren ab. * zum einen davon wie gut der Compiler ist.. * wie gut der Basic oder C Code ist. * * Aus schlechtem Hochsprachen Code kann der beste Compiler keinen guten ASM Code zaubern.
Mini Float schrieb: > XTerminator schrieb: >> Du kannst ja nichtmal das >> Speicherlayout einer struct vorgeben oder aus der Deklaration ablesen. > > So? Vom GNU-Compiler kenne ich es eher andersrum: Man muss sich selbst > überlegen, wie man die Members anordnet, damit sich eine kompakte > Alinierung gemäß der Maschinenbreite ergibt. > mfg mf Das Auto meines Nachbarn ist rot. Darf ich daraus schließen, dass alle Nachbarn rote Autos haben? --- Referenz ist hier der Standard und der gibt das Verhalten in diesem Detail nicht vor. Es ist undefiniert und kann viele Formen annehmen. In der Praxis gibt es nette #pragma für das Alignment und jeden Compiler ein Bissle anders.
spess53 schrieb: > Sieht ATMEL anders: > > http://www.atmel.com/dyn/resources/prod_documents/... > > MfG Spess Wenn auch nicht vollständig, so hab' ich's mir ansatzweise durchgelesen, speziell: > Architecture Tuned for C Code Liest sich wie wenn die Marketingabteilung die Finger drin hatte. Hast Du denn einen tatsächlichen Beleg gefunden, was denn davon genau an C angepasst ist ? Also nicht was durch C verwendbar ist. Ansonsten sagt's der Titel ja schon: > Efficient C Coding for AVR Auf Deutsch: wie passe ich C an den AVR an...
Gutes Thema, um ne Lawine loszutreten. Ich denke mal, die meisten MCs sind nur auf Assembler optimiert , hehe. Aber die ursprüngliche Frage war ja, warum C und nicht Basic bei den meisten MCs und OSsen favorisiert wird. Der Vorteil bei C ist ja gerade, das so viele Plattformen in der einen oder anderen Form unterstützt werden, das eine Portierung einfacher ist, als wenn man alles immer wieder neu schreibt. Vergleich mal Apple ][ Basic mit GWBasic oder Bascom - da es nie einen richtigen Standard bei Basic gegeben, macht jeder was er will. Bei C hat sich ANSI mehr oder weniger durchgesetzt und K&R haben frühzeitig geschrieben, was gehen muss und was es tuen soll. Ich kann also eine Routine in Visual C schreiben und muss nur wenig rumbasteln, um sie auf Linux rennen zu lassen oder sie auf einem ARM oder AVR zum laufen zu bringen, sofern sie nicht an der Hardware rumfummelt oder anderweitig sehr maschinennah ist.
Hi >Hast Du denn einen tatsächlichen Beleg gefunden, was denn davon genau an >C angepasst ist ? Also nicht was durch C verwendbar ist. Interessiert mich als notorischen Assemblerprogrammierer nicht wirklich. Die AppNote war mir auf Grund der Diskussion hier wieder ins Gedächtnis gekommen (da war doch mal was). Allerdings weiss ich aus eigener Erfahrung, das sich C-Code auf AVRs recht einfach und kompakt in Assemblercode rückführen lässt. Also ich finde die Architektur der AVRs schon recht C-freundlich. MfG Spess
In C kannst du auch komplexere Algorithmen ganz bequem (einfaches debuggen und so) auf dem Computer entwickeln und wenn diese dann funktionieren für den µC kompilieren. spess53 schrieb: > Also ich > finde die Architektur der AVRs schon recht C-freundlich. Die Architektur der MSP430 ist nochmal deutlich besser. (Von-Neumann, wirklich RISC, leistungsfähige Adressierungsmodi)
an den TO: versuch dich lieber mal mit python. Das scheint mir basic nahe zu kommen, ist aber doch etwas seriöser
blub schrieb: > an den TO: > versuch dich lieber mal mit python. Das scheint mir basic nahe zu > kommen, ist aber doch etwas seriöser Ja genau, Python für Mikrocontroller! Hier sind ja wieder Profis unterwegs.
MWS schrieb: > Hast Du denn einen tatsächlichen Beleg gefunden, was denn davon genau an > C angepasst ist ? Das steht doch in der Appnote: sie haben die Entwickler von IAR ihren ersten Prozessorentwurf kommentieren lassen und danach noch einige Opcodes geändert: Dinge weggelassen, die zwar ein Assembler- programmierer vielleicht hübsch findet, die für den Compiler aber nicht dringlich sind, dafür Platz gemacht für andere Dinge, insbesondere für ein drittes Indirekt-Adressierungs-Register. Genauer wäre das allerdings eine Anpassung des Prozessors genau an den IAR-Compiler (und keinen anderen). Die Harvard-Architektur stört den IAR nicht weiter (anders als den GCC), während das dritte Zeiger- register für den IAR wegen seines Zwei-Stack-Modells wichtiger ist als für den GCC (der es aber natürlich auch gern als Framepointer nimmt, wenn er einen solchen mal braucht). Zurück zum Thema: Interpreter, gleich welcher Art, haben natürlich immer erst einmal einen prinzipbedingten Nachteil gegenüber Compilern. Wenn man den aber in Kauf nehmen will, warum sollte man dann unbedingt an einer eher altertümlichen Sprache wie BASIC mit ihren bekannten Design-Fehlern kleben? Dann könnte man doch lieber einen Interpreter für Python bauen.
Asmhobbyist schrieb: > Hallo, ich wollte nur mal in die Runde nach langjährigen Erfahrungen mit > Basic und C in der Mikrowelt fragen. Du kannst ein Programm in C so gut oder schlecht schreiben wie in Basic. Es sind beides Abstrakte und müssen in den Maschinencode übersetzt werden. C ist aber schlicht Industriestandard und einheitlicher. Auch weil es nur eine Quelle gibt aus der es stammt (K&R). Basic Programme sind IMHO etwas eindeutiger. Es gibt z.B. diese ganzen Probleme mit = == += -* nicht da diese Zuweisungen nicht existieren. Programmierer wollen möglichst jeden Tastenanschlag sparen, dafür eignet sich C besser (aber auch um write only Programme zu erzeugen ;-). Einen Basic code halte ich (ganz persönlich und ohne Anspruch auf die absolute Wahrheit) für "sicherer" als C. Es gibt z.B deutlich weniger Stack Overflows. > > Ist (compiliertes, asmgetuntes) Basic wirklich so schlecht gegenüber C, Das kommt halt auf den Compiler an. Es gibt auch gute Basic Compiler, gerade für Mikrocontroller die guten und kompakten Code erzeugen. Die oben angesprochene "lesbarkeit" des Assemblercodes halte ich in Zeiten wo auch bei Basic in Hochsprache getraced wird für nicht relevant. > z.B. dass es gar nicht erst in Linuxen dabei ist Das ist schlicht Historie da Linux in C geschrieben wurde. > oder wäre ein kleiner > Basicinterpreter im Handy wirklich zuviel gewesen? Gibt es denn C Interpreter? Matthias Sch. schrieb: > Vergleich mal Apple ][ > Basic mit GWBasic oder Bascom - da es nie einen richtigen Standard bei > Basic gegeben, macht jeder was er will. Das ist sicher richtig, aber ein C Programm portiert man auch nicht in 2 Minuten. C hat schlicht weniger Befehle als die meisten Basic Dialekte. Das wird dann über Includes geregelt. Der Grundwortschatz ist bei Basic auch gleich bzw sehr ähnlich , nur werden Befehle hinzugefügt statt libs (lernen muss man aber beides).
Hi >Wenn man den aber in Kauf nehmen will, warum sollte man dann unbedingt >an einer eher altertümlichen Sprache wie BASIC mit ihren bekannten >Design-Fehlern kleben? Dann könnte man doch lieber einen Interpreter >für Python bauen. BASIC hat seine Überlebensfähigkeit schon bewiesen. Bei der heutigen inflationären Anzahl der 'Programmiersprachen' dürfte bei den meisten die Halbwertszeit schon überschritten sein. MfG Spess
Jörg Wunsch schrieb: > Dinge weggelassen, die zwar ein Assembler- > programmierer vielleicht hübsch findet, die für den Compiler aber > nicht dringlich sind, dafür Platz gemacht für andere Dinge, > insbesondere für ein drittes Indirekt-Adressierungs-Register. Wenn das die ganze "Optimierung für C" ist, dann stimmt doch, was ich schrieb, es ist Marketingpropaganda.
Die meisten von uns haben mit Basic angefangen. Viele geben es aber nicht gerne zu. Basic ist eine Top Programmiersprache. Nicht viele Unterschiede zu C. Nur ist C Industriestandard und es gibt daher fast für jeden Prozessor einen C Compiler (ANSI). Das macht den Code gut wiederverwertbar für andere Projekte. Bei Basic kann es dabei zu riesigen Problemen kommen (weil es eben keinen Basic-Standard gibt). Gruß Chose
100 for a = 1 to 100 200 next 150 print "aja,aja" 160 goto 210 210 print "Spaghettii"
MWS schrieb: > Wenn das die ganze "Optimierung für C" ist, dann stimmt doch, was ich > schrieb, es ist Marketingpropaganda. Jeder Hersteller hat so seine "Optimierung für C" oder für irgendwas anderes was die Marketingheinzis glauben anderen unter die Nase zu reiben. Was würden die wohl schreiben wenn einer dieser Microcontroller wirklich "für C optimiert" wäre. Sicher mehr als eine verschämte Zeile. chose schrieb: > Nur ist C Industriestandard und es gibt > daher fast für jeden Prozessor einen C Compiler (ANSI). Das macht den > Code gut wiederverwertbar für andere Projekte. Wenn man es denn braucht. C ist wie Formel 1 fahren. Eine falsche Bewegung und du fliegst aus der Kurve. Das ist was für Leute die Tagein Tagaus nichts anderes machen. Profis halt. Es gibt aber noch ein andere.
@ia ja klar, auch bei c gibts ein goto. Ich wurde von meinem damaligen Lehrer allerdings instruiert, das nie zu verwenden, was ich auch nicht getan habe. Was genau ist der -* operator, den du oben erwähnt hast ?
chose schrieb: > Nicht viele Unterschiede zu C. Ach so. blub schrieb: > 100 for a = 1 to 100 > 200 next > 150 print "aja,aja" > 160 goto 210 > 210 print "Spaghettii" Und was ist das jetzt? C oder Basic. Kann man ja kaum unterscheiden. Jörg Wunsch schrieb: > Dann könnte man doch lieber einen Interpreter für Python bauen. Den schreibt dann man aber in C. mfg.
Thomas Eckmann (Firma: Thomas Eckmann Informationst.) (thomase) schrieb: blub schrieb: >> 100 for a = 1 to 100 >> 200 next >> 150 print "aja,aja" >> 160 goto 210 >> 210 print "Spaghettii" >Und was ist das jetzt? C oder Basic. Kann man ja kaum unterscheiden. Casic :)
goto auf ein sinnhaftes Label ist innerhalb einer function kein Problem. besser als komplizierte while - break verschachtelungen ect zum ausstieg aus einer schleife oder um die function zu beenden. wo liegt das problem ? diese lehrmeinung kommt sicher aus den basic anfängen, wo es noch zeilennummern gab. zb. goto 3450 ist nicht zu empfehlen. alte lehrmeinungen muß man immer wieder hinterfragen...und trinkt mindestens 2 liter wasser am tag ;-)
Seit wann baut man einen Prozessor angepasst auf eine Programmiersprache? Das würde ja bedeuten, das man die heutigen PCs auf Linux designt!
>> 100 for a = 1 to 100 >> 200 next >> 150 print "aja,aja" >> 160 goto 210 >> 210 print "Spaghettii" in c: for (a = 1; a < 100; a++) printf("aja,aja"\n"); ist das so richtig ? das ist ja basic schon sehr ähnlich...
Hi
>Das würde ja bedeuten, das man die heutigen PCs auf Linux designt!
PCs für Masochisten?
MfG Spess
Alex W. schrieb: > Seit wann baut man einen Prozessor angepasst auf eine > Programmiersprache? naja intel optimiert zumindest den Prozessor so, damit der von Compieler erzeugte code schneller wird. > Das würde ja bedeuten, das man die heutigen PCs auf Linux designt! ist jetzt linux etwas schon eine Programmirsprache?
glauben schrieb: > for (a = 1; a < 100; a++) printf("aja,aja"\n"); > ist das so richtig ? printf("Spaghettii"); fehlt noch > > das ist ja basic schon sehr ähnlich... Richtig. Kaum zu unterscheiden. Alex W. schrieb: > Das würde ja bedeuten, das man die heutigen PCs auf Linux designt! Das ist sowoieso die beste Programmiersprache. spess53 schrieb: > PCs für Masochisten? Dann kann man sich die Domina sparen. mfg.
glauben schrieb: > for (a = 1; a < 100; a++) printf("aja,aja"\n"); Da ist auch noch ein Fehler drin: >>for (a = 0; a < 100; a++) printf("aja,aja"\n"); Nur Basic-Programmierer fangen bei 1 an zu zählen. Und schaffen sich damit jede Probleme. Besonders auf µCs. mfg.
assembler ist du mutter aller dinge..... schön übersichtlich zu lesen und sehr kurz zu halten. portierbarkeit kein problem....;-)
Da ist auch noch ein Fehler drin: >for (a = 0; a < 100; a++) printf("aja,aja"\n"); >> for (a = 0; a < 100; a++) printf("aja,aja\n"); wo war er ?
assi schrieb: > wo war er ? Da: glauben schrieb: > for (a = 1; a < 100; a++) printf("aja,aja"\n"); ^ ^ ^ mfg.
Na hier sind ja die Experten und um Inlineassembler geht es auch. Gibt es einen "Precompiler" für den GCC der die umständlichen Inlineassembler Konstruktionen einfacher werden lässt, meinetwegen vergleichbar mit MSVC ??? Oder ist das generell Absicht den Inline-Assembler-Willigen C-Programmierern das Schreiben von Inlineassembler zu erschweren um den (freien) Code frei portierbar zu halten?
Jetzt mal ehrlich Leute, kommt sowas bei raus, wenn sich Ingenieure übers programmieren unterhalten? Als Informatiker kann man da nur schmunzeln. Aber unterhaltsam seid ihr ;-)
Alex W. schrieb: > Seit wann baut man einen Prozessor angepasst auf eine > Programmiersprache? Mehr oder minder seit dem es Programmiersprachen gibt. Das kann in zwei Richtungen gehen: 1. Man baut die Befehle ein, die gängige Konstrukte in gängigen Programmiersprachen möglichst 1:1 abbilden. Beispiele wären z.B. der Motorola 68000 (LINK, UNLK, oder Sachen wie: move (a0)+,(a1)+ - entpricht einem *dst++ = *src++ in C), oder die 8-Bit ATMELS. 2. Man lässt Befehle weg, die ein Assemblerprogrammierer praktisch fände, ein Compiler aber leicht durch Befehlssequenzen oder -ersetzungen durchführen kann. Beispiel wäre auch hier der 8-Bit ATMEL, siehe vorige Beiträge. Verschärft wird's z.B. bei MIPS, wo man schon mal NOPs in den Code einbauen muss, um nicht auf Pipeline-Effekte 'reinzufallen. Und extrem ist es beim Itanium und anderen VLIW-Prozessoren, die sich voll auf die Optimierungsmöglichkeiten moderner Compiler verlassen. Alles andere wäre auch doofes Design. Wenn man einen Prozessor konstruiert, sollte man sich vorher Gedanken machen, was darauf laufen soll und wie man das am besten unterstützt. Sonst könnte man ja auch gleich Turing-Maschinen für alles nehmen. ;-)
....was für eine diskussion...jeder hat so seine lieblingsprogrammiersprache mit welcher er glücklich ist. wichtig ist doch,das man an sein ziel kommt....der eine etwas schneller,der andere dafür komfortabler,jedem so wie er möchte. ich persönlich programmiere die kleinen avr am liebsten in assembler, es macht mir spass an jedem zahnrad drehen zu können,wie ein uhrmacher jedes noch so kleine ticken präzise zu kalkulieren...der preis dafür ist eben ein größerer zeitaufwand beim programmieren als bei einer hochsprache, dafür ist der code effizienter und ich bin auf keine libs angewiesen,ich programmiere also freier. deswegen verzichte ich aber nicht auf hochsprachen,z.b bei schnell zu ralisierenden projekten welche keine größeren ansprüche stellen. wie oft wird hier im forum als anfänger rumgeheult weil wieder mal jemand seinen text nicht aufs display bekommt,oder seine "led nicht blinkt"....warum darfs für solche sachen nicht bascom sein? andererseits versuchen fortgeschrittene krampfhaft zeitkritische dinge unbedingt mit bascom zu meistern,obwohl sich assembler dafür geradezu aufdrängelt! beide szenarien haben eines gemeinsam,sie sind nicht sehr sinnig,aber ehrgeizig! wichtig ist doch,das man spass dabei hat :)
Informatiker programmieren doch eh nur in Java. ;-) ;-)
Asmhobbyist schrieb: > Ist (compiliertes, asmgetuntes) Basic wirklich so schlecht gegenüber C Welcher BASIC-Dialekt genau?
Hi >Jetzt mal ehrlich Leute, kommt sowas bei raus, wenn sich Ingenieure >übers programmieren unterhalten? Als Informatiker kann man da nur >schmunzeln. Aber unterhaltsam seid ihr ;-) Ingenieure sind nur die Leute, die die das was Informatiker verzapfen in die Praxis umsetzen. MfG Spess
Die diskussion an sich ist schon unsinn. Man kann in c und in basic gleichermaßen Mist proggen. So lange man bei den grundfunktionen für verzweigungen subroutinen und funktionen bleibt ist die syntax auch sehr ähnlich. In c kann man sich dann in den sructs austoben und unlesbaren code erzeugen. Bei bascom sind in den compilerspezifischen befehlen so manche kopfnüsse verbat. Bascom hat in der interrupt verarbeitung geschwindigkeitsnachteile und etwas den ruf von fast and dirty, kann aber auch damit zu tun haben dass es von anfängern gern zum einstieg verwendet wird eben dann auch mit den typischen anfängerfehlern.
Simon K. schrieb: > Informatiker programmieren doch eh nur in Java. ;-) ;-) Nö. Richtige Informatiker spezifizieren in Z* oder ähnlichem. Und lassen das Ergebnis in Ada oder ähnlichem programmieren. :-p * http://de.wikipedia.org/wiki/Z-Notation
Assembler ja, um vorwärts zu kommen braucht es wenigstens C. Wenn das mit dem cryptischen Inlineassembler nicht wäre. Oder irre ich, das ist eine Frage.
olaf schrieb: > ....was für eine diskussion...jeder hat so seine > lieblingsprogrammiersprache mit welcher er glücklich ist. Nicht nur das, auch nimmt man für bestimmte Zwecke auch eine bestimmte Programmiersprache. > ich persönlich programmiere die kleinen avr am liebsten in assembler, es > macht mir spass an jedem zahnrad drehen zu können,wie ein uhrmacher > jedes noch so kleine ticken präzise zu kalkulieren... Ist Ok. Wüsste zwar nicht wo der Vorteil dabei ist den Programmablauf ganz präzise vorher zu sagen, aber ok, jedem das Seine. > der preis dafür ist > eben ein größerer zeitaufwand beim programmieren als bei einer > hochsprache, Und man kann schnell den Überblick verlieren. Aber zugegebenermaßen passiert das auch in anderen (auch Hoch-) Sprachen, wenn man nicht ordentlich arbeitet. > dafür ist der code effizienter Aber hier möchte ich doch mein Veto einwerfen. Das klingt ziemlich pauschal. Compiler sind oft ziemlich pfiffig, sodass sie durchaus schon mal versierte Assemblerprogrammierer abhängen können. > und ich bin auf keine libs > angewiesen,ich programmiere also freier. Das ist man beispielsweise in C auch nicht (EDIT: Ok, bis auf Startup Code, ISR Prolog/Epilog und anderes Essentielles natürlich schon). In BASCOM (BASIC) hingegen schon. > deswegen verzichte ich aber nicht auf hochsprachen,z.b bei schnell zu > ralisierenden projekten welche keine größeren ansprüche stellen. Genau, jede Programmiersprache für ihren Zweck. > wie oft wird hier im forum als anfänger rumgeheult weil wieder mal > jemand seinen text nicht aufs display bekommt,oder seine "led nicht > blinkt"....warum darfs für solche sachen nicht bascom sein? Von mir aus dürfen diejenigen auch BASCOM benutzen. Aber wenn der Gleiche Benutzer irgendwann noch mal wiederkommt und nicht eine LED oder ein LCD ansteuern möchte, sondern einen Webserver aufsetzen möchte, dann stößt er auf das Problem, dass er den "Webserver-starten Befehl" (den es eben nicht gibt) nicht finden kann.
Simon K. schrieb: > Nicht nur das, auch nimmt man für bestimmte Zwecke auch eine bestimmte > Programmiersprache. ...das geht als sinn aus meinem beitrag hervor >> ich persönlich programmiere die kleinen avr am liebsten in assembler, es >> macht mir spass an jedem zahnrad drehen zu können,wie ein uhrmacher >> jedes noch so kleine ticken präzise zu kalkulieren... > Ist Ok. Wüsste zwar nicht wo der Vorteil dabei ist den Programmablauf > ganz präzise vorher zu sagen, aber ok, jedem das Seine. > ...das kann nur ein uhrmacher oder "bitnarr" verstehen ;-) >> der preis dafür ist >> eben ein größerer zeitaufwand beim programmieren als bei einer >> hochsprache, > Und man kann schnell den Überblick verlieren. Aber zugegebenermaßen > passiert das auch in anderen (auch Hoch-) Sprachen, wenn man nicht > ordentlich arbeitet. ...so ist es,struktur ist alles,in jeder sprache! > >> dafür ist der code effizienter > Aber hier möchte ich doch mein Veto einwerfen. Das klingt ziemlich > pauschal. Compiler sind oft ziemlich pfiffig, sodass sie durchaus schon > mal versierte Assemblerprogrammierer abhängen können. ...ein punkt über den man streiten könnte,aber gewisse compiler sind wirklich gut ;-) >> und ich bin auf keine libs >> angewiesen,ich programmiere also freier. > Das ist man beispielsweise in C auch nicht. In BASCOM (BASIC) hingegen > schon. ...ich sprach ja auch nicht von c,aber es ist ein geniales design und stellt das ideale bindeglied dar...also ein muss für jeden programmierer, welcher über den hobbystatus hinaus will :) >> deswegen verzichte ich aber nicht auf hochsprachen,z.b bei schnell zu >> ralisierenden projekten welche keine größeren ansprüche stellen. > Genau, jede Programmiersprache für ihren Zweck. ...da wäre sie wieder,die philosophie! >> wie oft wird hier im forum als anfänger rumgeheult weil wieder mal >> jemand seinen text nicht aufs display bekommt,oder seine "led nicht >> blinkt"....warum darfs für solche sachen nicht bascom sein? > Von mir aus dürfen diejenigen auch BASCOM benutzen. Aber wenn der > Gleiche Benutzer irgendwann noch mal wiederkommt und nicht eine LED oder > ein LCD ansteuern möchte, sondern einen Webserver aufsetzen möchte, dann > stößt er auf das Problem, dass er den "Webserver-starten Befehl" (den es > eben nicht gibt) nicht finden kann. ...mit den problemstellungen wachsen die ansprüche an die programmiersprache und den programmierer und da trennt sich der weizen von der spreu....wer wirklich spass an effizienten problemlösungen hat,wird sich nicht scheuen andere programmiersprachen zu lernen!
weinbauer schrieb: > In c kann man sich dann in den sructs austoben und unlesbaren > code erzeugen. Bei bascom sind in den compilerspezifischen befehlen so > manche kopfnüsse verbat. Naja, wenn man nur Bascom kennt kann das schon sein, andere B-Compiler erinnern teilweise sehr an die guten Seiten von C. Übrigens: Wer sagt C wäre Portabel kann ja mal irgendein Codeschnispsel aus dem Internet in den Compiler seiner Wahl Cut & Pasten. Mir ist es ohne Fehlermeldung jedenfalls nie gelungen. So schöne Spezialitäten wie die Zahl 010 (die mitnichten eine Zehn repräsentiert sondern eine Oktalzahl (ein hochmodernes Notationssystem das sicher in C zwingend notwendig ist) mit der HexDec Entsprechung 08 oder die Möglichkeit mit A$=B$ sein gesamtes Programm wegzufiedeln (wenn es denn so einfach ginge, man braucht statt dieser Megasimplen Funktion irgendwelche StrCopys und ein Pointergefummel vor dem Herren) machen C Programmierung zu einem wahrlich erschöpfenden Erlebnis. Dafür fängt dann ne Hex Zahl mit 0x an und dezimale haben gar keine Vorzeichen. Das ist weder Durchgängig noch logisch, aber beim Tischler wackeln halt die Stühle. Das ein String mit der Länge 9 nur 8 Zeichen enthalten kann (wg. \0) und das berüchtigte goto a.) so existiert wie in Basic und b.) noch um solche Feinheiten wie break und continue erweitert wurde lässt mich schon an der "strukturierten Programmierung" zweifeln. Das kann man endlos fortsetzen, von der schönen Eigenschaft das 1 Byte werte als char(acter) dargestellt werden, dem fehlen von Bit Deklarationen etc. pp. Fazit: Ein jeder möge nach seiner Fasson programmieren, aber auch vor der eigenen Türe kehren. ;-).
iaoffline schrieb: > > Fazit: > Ein jeder möge nach seiner Fasson programmieren, aber auch vor der > eigenen Türe kehren. ;-). ...da gibts nix zu kehren, es ist doch schön,das du mit deiner programmiersprache glücklich bist...immer dieses dumme gerangel um die "beste programmiersprache". deine freundin muss nicht mein geschmack sein,ihr müsst gut zusammen passen und euch ergänzen,wenn es so ist kann ich mich erfreuen,das ihr ein schönes paar abgebt :) in dem sinne....
Unterm Strich ist's ziemlich egal in was einer programmiert. Wenn er es kann oder gut gelernt hat kann er sich in jede beliebige Sprache mit Hlfe der Befehlsreferenz recht flott hinein fuchsen. Programmverzweigungen und Schleifen sind in jeder Sprache vorhanden, nur die Schreibweise ändert sich von Fall zu Fall. Aufgeräumter und kommentierter Code ist in jeder Sprache ein Muss. Sehr hilfreich sind Variablen mit entsprechend aussagefähigem Namen. A, B, C sind da eher Müll, $Schleifenzaehler_sub oder $Uart_rxc_flag sagt da mehr aus. Was die Portierbarkeit von C oder ASM angeht, so kann die These auch nur einer Aufstellen, der noch nie z.B. nen Code aus IAR für AT91SAM in Ansi-C für LPC übersetzt hat. Da kann man auch gleich neu schreiben. Bei ASM ists das Gleiche ... von PIC auf AVR und anders herum kann man getrost vergessen mit Plug and Play, beim ersten Registeraufruf meckert der Compiler. Auch gibt es für bestimmte Anwendungen eben spezialisierte Sprachen. In eine Website bettet man eben JS, Java oder Flash ein (über den Sinn kann man ja trefflich streiten), Die Seiten erstellt man entweder als CGI, PHP oder HTML ... Ein CMS in Basic aufsetzen da käme so schnell keiner drauf denke ich. Während in einer Access Datenbank oder Excel Sheet VB recht praktisch ist. Man muss die Sprache nach der Anwendung wählen, krampfhaft an Dogmen festhalten führt irgendwann in die Sackgasse.
Dogmen sind nie gut. Ich verwende C für so ziemlich alles. Auch in CMS- oder größeren Archiven via Internet. Ich bin da noch bei keinen Limitierungen angekommen. Schnell und präzise. Im Moment wühle ich mich in die AVRs ein, mit den GCC war das erste Programm kein Problem. Angefangen habe ich mit Assembler / Crossassembler auf 6502, komme also aus dieser Ecke. Mir kam auch mal (das oben erwähnte Spaghetti-GWBASIC) in die Quere. Gleiches Programm, einmal GWBASIC (nicht mehr pflegbar wg GOTO), ich hab's in C neu geschrieben. Laufzeitunterschied Faktor ca 2000. Ok, es gibt heute besseres. zB LUNA. Aber alleine die fehlende Unterscheidung zwischen Zuweisung (=) und Vergleich (==) erzeugt bei mir spontanes Hochrollen der Fußnägel.
Hallo, wollte nur mal anmerken, dass man bei einem vernünftigen C-Compiler auch einen Linker hat der einem dei AAM Routinen dazu linken kann. Da brauchts kein Inline wenn man nicht will. Ok, man muss sich dann evtl mal das Manual vom Linker durchlesen. Könnte eine unüberwindbare Hürde sein. Eckhard
Eckhard schrieb: > Hallo, > > wollte nur mal anmerken, dass man bei einem vernünftigen C-Compiler auch > einen Linker hat der einem dei AAM Routinen dazu linken kann. Da > brauchts kein Inline wenn man nicht will. Ok, man muss sich dann evtl > mal das Manual vom Linker durchlesen. Könnte eine unüberwindbare Hürde > sein. > > Eckhard Ein Linker linkt nur Objectfiles zusammen. Das weiß vermutlich schon gar nicht mehr aus was es erzeugt wurde ;-)
Fhutdhb Ufzjjuz schrieb: > Unterm Strich ist's ziemlich egal in was einer programmiert. > Wenn er es kann oder gut gelernt hat kann er sich in jede beliebige > Sprache mit Hlfe der Befehlsreferenz recht flott hinein fuchsen. Schön wär's ja, aber nach meiner Erfahrung ist das erste auf das man aufläuft ein Bug. Vielleicht geht das ja nur mir so, aber mit Ausnahme von HPs Rocky-Mountain-Basic (mit dem ich mal programmieren gelernt und das wirklich sehr stabil und fehlerfrei war). Egal wo oder was, die Wanzenjagd ist immer mit dabei. Bin z.B. grad am C-lernen, MPLAB und Hitec C. Macht man nen Kommentar in der letzten Zeile kommt n Syntax Error löscht man ihn geht's. So wie ich die Programmierer auch sonst fluchen höre ist das auch bei den schweineteuren Produkten nicht anders.
iaoffline schrieb: > Macht man nen Kommentar in > der letzten Zeile kommt n Syntax Error Und diese Meldung lautet wie? Die meisten Compiler (nicht nur in C) möchten eine Leerzeile am Ende. Peter
Peter Dannegger schrieb: > iaoffline schrieb: >> Macht man nen Kommentar in >> der letzten Zeile kommt n Syntax Error > > Und diese Meldung lautet wie? > > Die meisten Compiler (nicht nur in C) möchten eine Leerzeile am Ende. Oder zumindest, dass das letzte Zeichen einer Compilation Unit ein CR ist. und im Falle C ist der Compiler dabei sogar im Recht. Das sichert ihm die Sprache zu: Die letzte Zeile muss noch einen Zeilenvorschub haben. Das der Text im File einfach so aufhört, ist nicht zulässig. Manchen Compiler ist das egal, andere sind da wieder pingelig.
Karl Heinz Buchegger schrieb: > Oder zumindest, dass das letzte Zeichen einer Compilation Unit ein CR > ist. Danke für die Erklärung, die zwar in keinster weise was mit Logik zu tun hat sondern mit willkürlichen Konventionen, aber wie gesagt bin noch am lernen. C ist bisher aber so ziemlich das absurdeste was mir unter gekommen ist. Warum in diesem Fall ein CR nach Main end kommen muss (statt EOF) erschliesst sich mir nicht. Ebensowenig wie die kryptische Meldung Syntax Error (als ob der Compiler nicht genau wüsste warum er selbige produziert). Da kann man erstmal Rätselraten was denn so gemeint sein könnte. Produktiv ist das nicht, professionell schon gar nicht (es sei denn man nimmt die Standards von 1970 wo man froh sein konnte überhaupt eine Fehlermeldung zu bekommen. Seis drum, alle kochen mit Wasser.
Servus Karl Heinz, Du mußt 2 Wochen durchhalten. Das ist bei den ersten Gehversuchen in C die "böse Zeit" in der der Rechner öfter mal kurz davor ist, aus dem Fenster zu fliegen. Du wirst Dir öfter mal die Hand vor die Stirn klatschen und laut fluchen "wie blöd kann man ...". Da mußt Du durch. Lohnt sich aber ! Mirfühlende Grüße, Joe.
iaoffline schrieb: > Ebensowenig wie die kryptische Meldung > Syntax Error (als ob der Compiler nicht genau wüsste warum er selbige > produziert). Das hat aber überhauopt nichts mit der Sprache C zu tun, sondern ist ein spezifisches Problem deines Compilers. iaoffline schrieb: > Produktiv ist das nicht, professionell schon gar nicht Stimmt. Also besorg dir einen produktiven und professionellen C-Compiler. Nicht nur beim Lernen ist das sehr viel effektiver. Oliver
C ist vonnöten, wenn systemrelevante Programme, wie etwa eine library geschrieben werden sollen. Von dem Hobbyprogrammier kann man nicht erwarten, dass er hardwarenah schreibt. Steht genug Speicher zur Verfügung, kann er sich mit jeder beliebigen Sprache verdingen. nur ist klar, das er keine zeitkritischen Probleme (zB eine FFT) lösen kann (ausser es wurde eine entsprechende Funktion schon vorgefertigt) und das sein Code evtl nicht portabel oder wiederzuverwenden ist
for (a = 1; a < 101; a++) { printf("aja,aja\n"); break; }
printf("Spaghettii");
Das wäre das c Equivalent
Bei c kommts wirklich auf jede scheiß Klammer oder Strichpünktchen an, sonst steigt der Compiler komplett aus und lässt einen erstmal suchen.
Ich frage mich immer wieder, warum sich Pascal nicht gegen C durchgesetzt hat. Diese Sprache ist klar und deutlich und auf allen möglichen Rechnern und auch für AVR zu haben. Es ging mit Algol los, welches sich nicht sehr stark von Pascal unterschei- det. Auf 8-Bit Rechnern lief Pascal es unter CP/M oder Udos. Auf neueren Rechnern kam dann Turbo-Pascal unter DOS und jetzt Delphi. Manchmal habe ich das Gefühl, daß manch Einer mit der Verwendung von C nur fetzen und blenden will, weil man aus dieser Ansammlung sämtlicher verfügbarer Sonderzeichen auf Anhieb kaum schlau wird. Kompatibel ist dieser Kram auch nicht. Wie oft liest man hier: "Du mußt diese oder jene Optimierung abschalten, oder die ältere Version diese Kompilers benutzen usw. usf." Ein Quelltext in Pascal ist so selbsterklärend, daß man ihn ziemlich schnell verstehen kann. MfG Paul
char schrieb: > Bei c kommts wirklich auf jede scheiß Klammer oder Strichpünktchen an, > sonst steigt der Compiler komplett aus und lässt einen erstmal suchen. Zeige mir mal eine Programmiersdprache ohne Syntax. Irgendwie muß es der Compiler / Interpreter ja auch verstehen ...
iaoffline schrieb: > Karl Heinz Buchegger schrieb: >> Oder zumindest, dass das letzte Zeichen einer Compilation Unit ein CR >> ist. > > Danke für die Erklärung, die zwar in keinster weise was mit Logik zu tun > hat sondern mit willkürlichen Konventionen, aber wie gesagt bin noch am > lernen. Blödsinn. > C ist bisher aber so ziemlich das absurdeste was mir unter gekommen ist. > Warum in diesem Fall ein CR nach Main end kommen muss (statt EOF) Nach einer translation unit, nicht nach "Main end", was auch immer das sein soll. Stell dir mal vor: bla.h: ------ #define HALLO 5 ------ bla.c: ------ #include "bla.h" int main(int argc, char *argv[]){ return 0; } ------ Was macht der Präprozessor draus? ----- #define HALLO 5int main(int argc, char *argv[]){ return 0; } ----- Sieht das für dich vernünftig aus? Viel Spaß beim Fehler suchen, die Fehlermeldungen des Compilers werden wüst. Und weil der Programmierer die Dateien stets getrennt anguckt, kommt er auch nicht so schnell auf das Problem. Ich hatte das Vergnügen schonmal...
char schrieb: > nur ist > klar, das er keine zeitkritischen Probleme (zB eine FFT) lösen kann > (ausser es wurde eine entsprechende Funktion schon vorgefertigt) und das > sein Code evtl nicht portabel oder wiederzuverwenden ist Laberkopf.
Joachim Drechsel schrieb: > Zeige mir mal eine Programmiersdprache ohne Syntax. Lisp kommt dem nahe. Nicht ganz ohne Syntax, aber eine Beschreibung der Syntax paßt in einen Absatz.
Joachim Drechsel schrieb: > char schrieb: >> Bei c kommts wirklich auf jede scheiß Klammer oder Strichpünktchen an, >> sonst steigt der Compiler komplett aus und lässt einen erstmal suchen. > > Zeige mir mal eine Programmiersdprache ohne Syntax. > > Irgendwie muß es der Compiler / Interpreter ja auch verstehen ... Ja aber c ist in diesem Sinne sehr etepetete, da hat man mit Python ein Gegenbeispiel, welches eine klare Code Darstellung erzwingt und man findet Syntaxfehler schnell
char schrieb: > Joachim Drechsel schrieb: >> char schrieb: >>> Bei c kommts wirklich auf jede scheiß Klammer oder Strichpünktchen an, >>> sonst steigt der Compiler komplett aus und lässt einen erstmal suchen. >> >> Zeige mir mal eine Programmiersdprache ohne Syntax. >> >> Irgendwie muß es der Compiler / Interpreter ja auch verstehen ... > > Ja aber c ist in diesem Sinne sehr etepetete, da hat man mit Python ein > Gegenbeispiel, welches eine klare Code Darstellung erzwingt und man > findet Syntaxfehler schnell Die finde ich in C auch "schnell". Pascal ist auch nett, wäre es nicht so ausladend und geschwätzig. Man tippt sich die Finger wund. 1 Seite Pascal ~ 3 Zeilen C (ok, vielleicht nicht so gut leserlich ;-)).
XTerminator schrieb: > Was macht der Präprozessor draus? > > ----- > #define HALLO 5int main(int argc, char *argv[]){ > return 0; > } > Nein. Der Präprozessor wertet das #define aus und wirft es weg. Ein vergessenes Semikolon am Ende einer Variablendefinition in einer Headerdatei kann allerdings zu merkwürdigen Fehlermeldungen führen. Wer sich über die C-Fehlermeldungen aufregt, hat noch nie mit LaTeX gearbeitet. Die Fehlermeldungen von pdftex sind um ein vielfaches unverständlicher als die vom gcc. Was die C Syntax anbetrifft: Meine erste Programmiersprache war Javascript. Als in dann mit C angefangen habe, hatte ich keine Probleme mit der Syntax. Es hätte kaum besser sein können. Ist also alles eine Sache der eigenen Programmiervorgeschichte. Paul Baumann schrieb: > weil man aus dieser Ansammlung sämtlicher > verfügbarer Sonderzeichen auf Anhieb kaum schlau wird. Ansichtssache. Mir sind 'geschwätzige' Programmiersprachen (begin ... end) ein Graus.
DXTerminator schrieb: > char schrieb: >> nur ist >> klar, das er keine zeitkritischen Probleme (zB eine FFT) lösen kann >> (ausser es wurde eine entsprechende Funktion schon vorgefertigt) und das >> sein Code evtl nicht portabel oder wiederzuverwenden ist > > Laberkopf. Das war zumindest der Grund, weshalb ich von QBasic/QB abgekehrt bin auch wenn das n Jahrzehnt schon her ist.
Paul Baumann schrieb: > Manchmal habe ich das Gefühl, daß manch Einer mit der Verwendung von C > nur fetzen und blenden will, weil man aus dieser Ansammlung sämtlicher > verfügbarer Sonderzeichen auf Anhieb kaum schlau wird. Erfahrungsmäßig bleiben richtig gute Programmierer (bin selbst keiner) eher bei C hängen. Selber hab ich schon satt 4 1/2 stellige Summen auf Zuruf für irgendwelche dubiosen Webbenches ausgegeben ohne auch nur den Namen des Hersteller jemals gehört zu haben. Das Ergebnis war aber immer überzeugend. > Kompatibel ist dieser Kram auch nicht. Wie oft liest man hier: > "Du mußt diese oder jene Optimierung abschalten, oder die ältere Version > diese Kompilers benutzen usw. usf." > > Ein Quelltext in Pascal ist so selbsterklärend, daß man ihn ziemlich > schnell verstehen kann. Es gibt aber immer Gründe warum sich etwas durchsetzt. Arbeitsplatzsicherung geht mit C einfach besser und für Profis ist ein Rennwagen schlicht das richtige Arbeitsmittel. Oliver schrieb: > Stimmt. Also besorg dir einen produktiven und professionellen > C-Compiler. Nicht nur beim Lernen ist das sehr viel effektiver. Das war der Hitec C Compiler für PIC direkt vom Hersteller. War eigentlich der Meinung das selbiger was taugen müsste (bei über 1000 Euro). Werde mal ein paar andere testen, danke für den Hinweis.
XTerminator schrieb: > Nach einer translation unit, nicht nach "Main end", was auch immer das > sein soll. > > > Stell dir mal vor: ... > > ----- > #define HALLO 5int main(int argc, char *argv[]){ > return 0; > } > ----- > > Sieht das für dich vernünftig aus? Das siht für mich nach C code aus, genau so irre wie das Original mit CR LF und meinetwegen noch 20 anderen unsichtbaren Ascii Steuerzeichen. Aber hast wohl recht, Mein Bug ist ein nötiges Feature und Steno war ja auch mal die Businessnotation per se ;-).
Ja schrecklich diese CRs :-D Einfach Basic nehmen und die weglassen! lach
Lukas K. schrieb: > Nein. > Der Präprozessor wertet das #define aus und wirft es weg. Ja, das war vorschnell. Mach aus dem Define ein "int a;" und es stimmt wieder.
Joachim Drechsel schrieb: > Pascal ist auch nett, wäre es nicht so ausladend und geschwätzig. Man > tippt sich die Finger wund. 1 Seite Pascal ~ 3 Zeilen C (ok, vielleicht > nicht so gut leserlich ;-)). Oh ja, eine Zeile in C tippen und 30 Minuten am Debugger ausprobieren, was man damit angerichtet hat. Der Compiler meckert ja sowieso erst 150 Zeilen weiter unten und schmeißt einem ne Zeile entgegen die man niemals selber eingetippt hat - dank Präprozessor. Sowas nennt man effektives Programmieren. W.S.
W.S. schrieb: > Oh ja, eine Zeile in C tippen und 30 Minuten am Debugger ausprobieren, > was man damit angerichtet hat. Ich kann nur sagen: Meistens sind diejenigen, die sich über C mockieren, genau diejenigen die C nie richtig gelernt haben. Mit Halbwissen kann man zwar ganz schnell irgendwelche Argumente aus dem Hut zaubern, aber sie halten dann eben auch nicht.
Karl Heinz Buchegger schrieb: > Ich kann nur sagen: > Meistens sind diejenigen, die sich über C mockieren, genau diejenigen > die C nie richtig gelernt haben. Mit Halbwissen kann man zwar ganz > schnell irgendwelche Argumente aus dem Hut zaubern, aber sie halten dann > eben auch nicht. Woran erkennt man selbst ob man C richtig gelernt hat?
Paul Baumann schrieb: > Ich frage mich immer wieder, warum sich Pascal nicht gegen C > durchgesetzt Pascal und C sind etwa zur gleichen Zeit (Anfang der 70er) entstanden. Pascal war als reine Lernsprache konzipiert und verzichtete auf alles, was die Lernenden verwirren könnte. So gab es bspw. keine Strings variabler Länge (weder nullterminiert noch mit Längenbyte), schließlich sollten die Studenten ja lernen, wie man selber neue Datenstrukturen baut. Man konnte auch beim Lesen und Schreiben von Dateien keinen Dateinamen angeben, da sonst OS-spezifische Aspekte in die Sprache eingeflossen wären. Pascal war auch nicht modular und deswegen für größere Anwendungen nur bedingt anwendbar. Im Gegensatz dazu war C von Anfang für die Entwicklung von Real-Life- Anwendungen konzipiert, und die Entwickler bewiesen dies, indem sie gleich ein ganzes Betriebssystem damit programmierten, was im damaligen Pascal nicht einmal ansatzweise möglich gewesen wäre. Brauchbar wurde Pascal erst mit dem Erscheinen verschiedener Dialekte, bekannt wurden bspw. UCSD- und später Turbo-Pascal. Leider waren diese Dialekte nicht mehr untereinander kompatibel. Vor allem Turbo-Pascal erbte nach und nach immer mehr Sprachkonstrukte von C, so dass man die späteren Turbo-Pascal-Versionen auch sehr gut für hardwarenahe Program- mierung einsetzen konnte. Da aber seit dem Erscheinen von C inzwischen mehr als 10 Jahre vergangen waren, konnte es nicht gegenüber C nicht mehr durchsetzen. Übrigens: Obwohl ich schon intensiv in Basic, Pascal und C (in dieser Reihenfolge) programmiert habe, hat mir Pascal von Anfang an besser als Basic und C von Anfang an besser als Pascal gefallen. Da gehen die Geschmäcker halt einfach etwas auseinander :) Ernst B. schrieb: > Woran erkennt man selbst ob man C richtig gelernt hat? ... daran, dass man es toll findet ;-)
Yalu X. schrieb: > ... dass man es toll findet ;-) Jepp. Nebenbei - man kann in C auch einen BASIC-Interpreter schreiben. Wenn man die nötige Leidensfähigkeit hat ;-) Und wozu auch.
>> Architecture Tuned for C Code >Liest sich wie wenn die Marketingabteilung die Finger drin hatte. Genau. Das Zeugs wird aber wirklich bei JEDEM neuen Prozessor (mind. seit 1979) vorgelabert. Wenn die CPU sinnvoll für ASM-Programmierung gemacht ist, ist sie es auch automatisch für Hochsprachen. (Ob der ASM-Programmierer oder der Compiler verzweifelt ist das selbe, und schlechte Stack-Handhabung stört überall)
Syntaxlose Programmiersprache: Flowcode... Nehmt C und werdet glücklich ! Anfänger nehmen Basic. Deswegen heißt es ja Basic (einfach, elementar) John Kemeny hat Basic erfunden (Mathematiker) Er war unter anderem Assistent bei Einstein. Alles keine Dummvögel. Also braucht sich keiner zu schämen. Basic Programmierer haben einen großen Vorteil: Sie können rasch mit Visual Basic umgehen. Meiner Meinung nach eine gute (inzwischen kostenlose) Programmierumgebung für den PC. VBA mit Excel macht auch Sinn. Gruß
Karl Heinz Buchegger schrieb: > Ich kann nur sagen: > Meistens sind diejenigen, die sich über C mockieren, genau diejenigen > die C nie richtig gelernt haben. Mit Halbwissen kann man zwar ganz > schnell irgendwelche Argumente aus dem Hut zaubern, aber sie halten dann > eben auch nicht. Und an dieser Diskussion erkennt man, dass sich die, die über Bascom ablästern, noch keine Minute damit beschäftigt haben. Der eine zeigt ein Basic Programm mit Zeilennummern, die es schon seit Ewigkeiten nicht mehr gibt. 100 for a = 1 to 100 200 next 150 print "aja,aja" 160 goto 210 210 print "Spaghettii" Bascom hat alle Schleifen und Funktionsaufrufe. Man kann damit genauso strukturiert programmieren, wie mit anderen Sprachen. Das absolut sinnfreie GOTO zur nächsten Zeile ist bescheuert. Vom Nächsten wird es als C Programm angeboten for (a = 1; a < 100; a++) printf("aja,aja"\n"); Allerdings zählt das BASIC Programm von 1 bis 100 und druckt dann einmal (und nicht 100 mal) "aja aja" aus und dann "Spaghettii" Dann findet einer einen Fehler, (aber nicht den richtigen) und behauptet > for (a = 0; a < 100; a++) printf("aja,aja"\n"); > Nur Basic-Programmierer fangen bei 1 an zu zählen. Ich habe schon C Programme gesehen, die benutzten die Zahl 128. Was für Stümper! Der Nächste bemängelt bei BASCOM > dann stößt er auf das Problem, dass er den "Webserver-starten Befehl" den > es eben nicht gibt) nicht finden kann. Dieser Befehl ist mir in keiner Sprache bekannt. Einer fragt: >Kennt Bascom sowas wie inline-Assembler? Antwort: > ich glaub schon BASCOM kennt neben BASIC Befehlen auch alle ASM Befehle, I/O Registernamen und BIT Namen, die man einfach innerhalb des Programms verwenden kann. Man kann ohne Probleme ASM Funktionen schreiben, die Werte vom BASIC bekommen und wieder übergeben können. Was ich sagen will, alle diese Leute verteufen BASCOM , obwohl sie sichtlich keine davon Ahnung haben. Ich muss gestehen, ich habe auch noch kein Programm in BASCOM geschrieben. Ich habe mich aber mal 1-2h damit beschäftigt und festgestellt, dass sehr viel geschrieben und gelästert wird, ohne das derjenige das Programm jemals gesehen hat. Ich habe bis jetzt die AVRs nur in Assembler programmiert, da gibt es gar keine strukturierten Schleifen, alles wird mit 'GOTO' gemacht, das ist zum Glück wohl noch keinem aufgefallen. Ich habe jetzt allerdings vorwiegend von AVR im Hobbybereich gesprochen. (TE nennt sich ja Asmhobbyist ). Im Profibereich sieht es wohl etwas anders aus, davon habe ich allerdings keine Ahnung.
Ja nee. BASCOM ? Schreibe ich ein Programm in C kann ich das mit minimalen Anpassungen auf jedem OS oder Rechner verwenden (mit minimalen Anpassungen). Was will ich mit einem auf eine konkrete Maschinen zugeschnittenen BASIC-Dialekt (Beginner All ...). Indiskutabel. Es gibt keinen vernünftigen Grund, das Laufen gleich mit Krücken zu lernen.
Herr Mueller schrieb: > Allerdings zählt das BASIC Programm von 1 bis 100 und druckt dann einmal > (und nicht 100 mal) "aja aja" aus und dann "Spaghettii" Erst überlegen und dann andere korrigieren. Deine Aussage ist schlichtweg falsch. Wann wird da Label 200 je erreicht? Zumal du nicht mitbekommen zu haben scheinst, dass es nicht um eine spezifische Implementation (Bascom, GWBasic oder whatever) geht. sollte aus der Überschrift und Frage bereits hervorgehen. Unter basic firmieren auch immer noch Dialekte, die Zahlenlabel/Zeilennummern orientiert arbeiten. Und zu guter Letzt sind Brotkisten und CPC noch lang nicht ausgestorben.
Joachim Drechsel (Firma: JDCC) (scheppertreiber) schrieb: > Ja nee. BASCOM ? > Schreibe ich ein Programm in C kann ich das mit minimalen Anpassungen > auf jedem OS oder Rechner verwenden (mit minimalen Anpassungen). Manche Menschen brauchen genau EIN (1) OS und nicht eine ganze Palette. > Was will ich mit einem auf eine konkrete Maschinen zugeschnittenen > BASIC-Dialekt (Beginner All ...). Wahrscheinlich will man einfach nur dass das Programm funktioniert. Mehr nicht. > Indiskutabel. Es gibt keinen vernünftigen Grund, das Laufen gleich > mit Krücken zu lernen. Als Baby lernt man vor dem aufrechten Gang das Krabbeln. In der Grundschule lernt man zuerst mit ganzen Zahlen und einem Rest zu rechnen und nicht gleich mit reellen Zahlen. Erst wird mit den Fingern gezählt, bevor das kleine Ein-mal-eins sitzt. Du siehst, das Lernen (ob geistig oder körperlich) besteht aus mancherlei "Krücken", deren man sich gerne bedient, um sich das Lernen anfänglich zu erleichtern. Wenn jemanden BASCOM reicht um das was er möchte umzusetzen, dann geht das meiner Ansicht nach voll in Ordnung. Du magst vielleicht lieber C, geht genau so in Ordnung. Über die persönlichen Vorlieben kann man diskutieren, auch ohne seine Abneigungen gleich auf ein allgemeingültiges Podest zu stellen.
Mich erinnert diese Diskussion mittlerweile eher an Motorradforen "Welches Öl". Der OP steht vor einer Entscheidung. Genug Material hat er. Laß ihn machen und wir reden in einem Jahr weiter. Dann wird er wissen ob seine Entscheidung richtig war. Für mich weiß ich das ;-)
Hi >Schreibe ich ein Programm in C kann ich das mit minimalen Anpassungen >auf jedem OS oder Rechner verwenden (mit minimalen Anpassungen). Aber nicht bei µCs. Die haben im allg. kein OS und eine sehr verschieden Hardware. Dann geht nichts mit 'kleinen Anpassungen'. Es scheint noch Träumer im C-Bereich zu geben. MfG Spess
Hi >Kein Traum. Realität. Das sehen sogar C-Programmierer hier anders: Beitrag "Re: Basic und/bzw. vs - C Erfahrungsumfrage" und das klingt wesentlich überzeugender MfG Spess
spess53 schrieb: > Aber nicht bei µCs. Die haben im allg. kein OS und eine sehr verschieden > Hardware. Dann geht nichts mit 'kleinen Anpassungen'. Es scheint noch > Träumer im C-Bereich zu geben. Wenn man die Hardwaregeschichten schön vom hardwareunabhängigen Code abgrenzt, kann der Portieraufwand durchaus gering ausfallen. Gruß Oliver
max schrieb: >> Allerdings zählt das BASIC Programm von 1 bis 100 und druckt dann einmal > >> (und nicht 100 mal) "aja aja" aus und dann "Spaghettii" > > > > Erst überlegen und dann andere korrigieren. > > Deine Aussage ist schlichtweg falsch. > > Wann wird da Label 200 je erreicht? Versteh ich nicht. >Zumal du nicht mitbekommen zu haben scheinst, dass es nicht um eine >spezifische Implementation (Bascom, GWBasic oder whatever) geht. >Ich habe jetzt allerdings vorwiegend von AVR im Hobbybereich gesprochen.
Ich hab auch schon einiges in Basic gemacht, angefangen mit der Version im C64 ( Ja ich ich weiß, ist schon eine Ewigkeit her) bis hin zum aktuellen VB in den MS Officeprodukten. Allerdings mit Bascom noch keine Berührung gehabt. Meine Meinung nach ist Basic ja ganz nett für einige Dinge wie zb Automatisierungen in Excel. Aber für µC nicht geeignet. Ja es geht aber wie...... Bascom läuft auf einer µC Familie, wenn man davon ausgeht auch in Zukunft nur mit dieser Familie zu arbeiten, naja warum dann nicht. Soll das "spielen" mit dem µC aber nur zum Einstieg , vielleicht ins Berufsleben mit µC, dienen macht Bascom keinen Sinn. In dem Fall ist es sinnvoller sich auf C zu konzentrieren. Gut geschriebener C Code ist mit minimalen Änderungen auf verschiedenen Plattformen lauffähig und dazu auch schnell. Stimmt der C Code erzeugt der Compiler/Linker schnelleren und kleineren Code als mindestens 90% der selbsternannten AssemblerGurus. Ich arbeite beruflich mit µC , wir haben mehrere verschiedene Architekturen im Einsatz, 8052, Hs8/16, Arm7, Cortex Mx und Rx. Anpassungen sind nur in den Modulen notwendig die direkt auf den µC zugreifen. Alle höheren Funktionen sind zu 100 % zwischen den µC austauschbar. Die Programmierung erfolgt zu 99% in C. Und unsere Systeme sind allesamt Realtime Systeme mit Multitasking. Assembler wird nur genutzt um im absoluten Lowlevel Bereich die Taskumschaltungen des OS, bzw die erst Initialisierungen nach Startup. Wer meint Assembler einsetzen zu müssen um ein Timing einhalten zu können, hat von Anfang an den falschen Ansatz gewählt. Ein System mit sowenig Reserven das es auf einzelne Takte ankommt, wird bei höhere Last niemals stabil laufen können.
spess53 schrieb: > und das klingt wesentlich überzeugender Aber nur, weil es besser in dein Weltbild passt. ;-) "Real programmers can write FORTRAN programs in any language." Oder in deutschem Geld: man kann mit jeder Programmiersprache Unfug zusammenschreiben.
wobei ich selbst FORTRAN schöner als BASIC fand und schneller wars auch. Eckhard
Eckhard schrieb: > wobei ich selbst FORTRAN schöner als BASIC fand und schneller wars auch. > > Eckhard Meine FORTRAN Programme hatte ich in Lochkarten stanzen müssen und den Ausdruck haben wir erst am nächsten Tag bekommen. Dann Fehler finden, neue Karten stanzen und neu abgeben, bis zum nächsten Tag. Das war gar nicht so schnell ;-)
Joachim Drechsel schrieb: > Ja nee. BASCOM ? > > Schreibe ich ein Programm in C kann ich das mit minimalen Anpassungen > auf jedem OS oder Rechner verwenden (mit minimalen Anpassungen). C ist ja wirklich recht leistungsfähig aber bei aller Liebe das ist doch Mumpitz. Lass mal ne FFT auf nen 8 Beinigen Pic/Atmel/etc los. Da kommt nichts bei raus egal ob in AB C oder D geschrieben . Ebenso die nichtgenormte Länge von INT Dword etc in C. Da wird dann allen ernstes behauptet das ließe sich mit typedef lösen was ja nichts anderes bedeutet als das sich der Progger selbst um die Portierbarkeit kümmern muss! was das ganze ad absurdum führt. Alles weglassen und nur mit den Minimalkonsens aller denkbarer OSe zu proggen kann ich auch in Basic haben 1+1= 2 ist dann der Level. Java ist portabel, C ist nicht portabel außer es kümmert sich jemand drum. Auch weiß man bei diesen ganzen minimalistischen Code schon auf dem Originalsystem nie was für Fallen da so noch drin stecken. Beim Crosscompilieren wird das dann zu Port and Pray. Von Datenbanken und IO Treibern sollte man lieber gar nicht erst anfangen, deswegen lasse ich's.
Ralph schrieb: > Ich arbeite beruflich mit µC , wir haben mehrere verschiedene > Architekturen im Einsatz, 8052, Hs8/16, Arm7, Cortex Mx und Rx. > Anpassungen sind nur in den Modulen notwendig die direkt auf den µC > zugreifen. Alle höheren Funktionen sind zu 100 % zwischen den µC > austauschbar. Ja weil ihr in Kenntnis eurer verschiedenen Systeme den Code portierbar haltet und alle im gleichen Laden arbeitet. Das geht mit Basic schlechter keine Frage, aber auch nicht mit C wenn man die Zielsysteme anonym sind. Wenn ich etwas habe portieren lassen (z.B von C nach C z.B IAR HC11 nach Keil -ARM) ist es immer schneller gelaufen als das Erstsystem. Wenn der Progger dransass der es gemacht hat. Wenn ein anderer da portiert ist Neuschreiben teilweise billiger gewesen. Das geht auch mit anderen Sprachen als C.
Max schrieb: > Die AVRs sind nicht möglichst gut auf C optimiert [...], > sondern sie sind so optimiert, dass ein C-compiler trotz harvard > recht gut mit ihnen klarkommt [...] AVRs haben also ein sogenanntes harvarierdes Speicherlayout. ...immer noch besser als sedimentiert.
iaoffline schrieb: > Da wird dann allen ernstes > behauptet das ließe sich mit typedef lösen was ja nichts anderes > bedeutet als das sich der Progger selbst um die Portierbarkeit kümmern > muss! was das ganze ad absurdum führt. Man hat mit c99 die stdint.h eingeführt.
Es ist ein Trugschluss, dass man als Programmierer von Basic-Dialekten sich nicht auf anderen Plattformen zurecht findet. Ein Programmierer der seit Jahr und Tag in einer bestimmten Syntax programmiert und die dortigen Gegebenheiten verinnerlicht hat, wird den gleichen großen oder minderen Aufwand haben seine Ideen umsetzen zu können wie in C. Basic besitzt ebenfalls wie C eine grundsätzlich einheitliche Syntax die sich nur durch plattformspezifische Zuatzimplementationen unterscheided. Ein Programmierer der z.Bsp. seit Amiga/Atari mit GFA-Basic programmiert, findet sich schnell in neueren Dialekten auf aktuellen Maschinen zurecht und ein Programmierer der objektorientiert mit Visual Basic oder Real Studio entwickelt, muss sich in dem Luna zwangsläufig zuhause fühlen. Für mich gibt es für die Controller nur Assembler, einfach weil ich es nicht anders gelernt habe und heute zu alt bin, um eine Neue lernen zu müssen. Als ich anfing zu programmieren, gab es noch kein C. Der Eindruck, dass Diejenigen die über C meckern wohl nie richtig damit zutun hatten ist wohl genauso richtig wie der Eindruck, dass Diejenigen die über Basic meckern genausowenig damit zutun hatten. Zum Schluss bleibt dann nur noch die Tatsache, dass wichtig ist was am Ende als Binärcode herauskommt. Alles Andere ist im Privatbereich eine reine Geschmacksfrage. Ehrhardt
Ehrhardt Balstein schrieb: > Als ich anfing zu programmieren, gab es noch kein C. C wurde Anfang der 1970er entwickelt ... Das ist über 40 Jahre her, sicher ?
Ehrhardt Balstein schrieb: > Basic besitzt ebenfalls wie C eine grundsätzlich einheitliche Syntax die > sich nur durch plattformspezifische Zuatzimplementationen unterscheided. > Ein Programmierer der z.Bsp. seit Amiga/Atari mit GFA-Basic > programmiert, findet sich schnell in neueren Dialekten auf aktuellen > Maschinen zurecht und ein Programmierer der objektorientiert mit Visual > Basic oder Real Studio entwickelt, muss sich in dem Luna zwangsläufig > zuhause fühlen. LUNA probiere ich gerade. Richard (RGF), der das herausgebracht hat, hat mich ja auch dazu überredet, mich mal wieder mit den kleinen schwarzen Käfern zu befassen. Ich habe da so meine Probleme mit LUNA, ich halte die Syntax für nicht so eindeutig wie sie sein sollte, wir haben da auch schon einige kleinere Korrekturen eingebaut. LUNA nimmt einem einiges an Routinekram ab (ähnlich Makros), zeigt aber mE Merkwürdigkeiten: Luna: dim buf(8) as byte C: char buf[8]; Zuweisung: Luna: buf(i) = c C: buf[i] = c () steht in C generell für Funktionen, die Basic-Syntax ist da verwirrend. Dann fehlt mir in LUNA eine Formatierung der Ausgabe a la printf(). LUNA hat eindeutig Vorteile für Einsteiger. Nach den üblichen Tücken hat man relativ schnell etwas laufen. Ein Ersatz für C ist es (noch) nicht obwohl Richard da schon recht schöne Projekte gebaut hat (zB die Digitalzündung für russische Seitenventiler). C ist für Einsteiger die noch nie programmiert haben echt übel. Für Leute aus der Assemblerecke ein netter unterschätzer Makroassembler. Hat man es mal heraus, unschätzbar ;-)
Rechnen in Bascom ist eine Qual ... komplexe Funktionen muss man aufdröseln zu Einzelschritten, die dann auch einzeln abgearbeitet werden, was mächtig auf die Performance geht. Steinhart-Hart-Gleichung z.B.. Oder gar ne Polynomregression in Bascom ... gruselig! ASM-Progger schrieben hier im Forum aber schon öfter, dass sie die Bascom-Platform schätzten, weil man sich die ganzen Initialisierungen prima in Bascom machen kann und dann seinen ASM-Code einfach zwischen die $ASM-Tags packt. Nosave bei den Interruptroutinen macht die genau so schnell wie in C oder sonstwas, muss man sich halt um das pushen und poppen selber kümmern. Richtig ist auch, Basic Compiler für andere Platformen außer PIC und AVR sind bei µC eher als Kuriositäten anzusehen. Gibt zwar für ARMs das HBBR-Basic, kann da aber nix zu sagen wie verbreitet das ist. Ist eben wie sonst im Leben auch, alles Geschmackssache.
Joachim Drechsel schrieb: > Luna: dim buf(8) as byte > C: char buf[8]; Und da geht es schon los. Auch wenn "char" im C-Pleistozän mal der Universal-8-bit-Datentyp war, hat sich die Sprache seitdem weiterentwickelt. Vorteilhafter wäre daher: > C: uint8_t buf[8]; Oliver
Oliver schrieb: > Vorteilhafter wäre daher: >> C: uint8_t buf[8]; Klar. Es ist zwar das gleiche ... Erkläre das einem BASIC-Freak ;-)
Joachim Drechsel schrieb: > Klar. Es ist zwar das gleiche ... Nein, ist es eben nicht. chart, unsigned char, und signed char sind drei verschiedene Datentypen, wobei die signdess von char nicht definiert ist, bzw. von den von den Compiler-Optionen abhängt. Aber erklär DAS mal einem Basic-Freak ;) Oliver
Angehängte Dateien:
-
studium_ibm1620.jpg
96 KB
Joachim Drechsel schrieb: > Ehrhardt Balstein schrieb: >> Als ich anfing zu programmieren, gab es noch kein C. > > C wurde Anfang der 1970er entwickelt ... > > Das ist über 40 Jahre her, sicher ? meine Frau sagt immer "du alter Zopf", leider ist es wahr. Die Verkalkung kommt auch mit dem Alter, ich habe vieles Vergessen was ich damals lernte. Die Rechner sahen damals so aus wie im angehängten Foto. Joachim Drechsel schrieb: > () steht in C generell für Funktionen, die Basic-Syntax ist da > verwirrend. nun, beachte das die Sprachen und ihre Semantik sich einfach unterscheiden. Wo du das Beispiel anführst: ich habe gesehen das statische Deklaration in luna mit den eckigen Klammern erfolgt: eedim s[32] as string > Dann fehlt mir in LUNA eine Formatierung der Ausgabe a la printf(). halte ich ehrlich gesagt nicht für einen Nachteil. Wenn ich in assembler meine Ausgaben mache, ist dies ebenfalls aufgesplittet. Das Ergebnis ist dasselbe, nur mit dem Unterschied, dass der Controller-Flash womöglich schon voll ist wenn ich einmal printf nutze. Ehrhardt
Ehrhardt Balstein schrieb: > eedim s[32] as string Definitiv mit runden Klammern, ich habe es gerade probiert. Eckige mag der Compiler dort nicht. > Die Rechner sahen damals so aus wie im angehängten Foto. Einfach nur geil ! Mein erster war selbstgelötet mit 8088, meine Eltern wollten mir keinen Tändi kaufen :-) > hart, unsigned char, und signed char Ich denke da etwas freier (und C läßt mich das machen), für mich sind das jeweils 8 Bit. Ob signed oder nicht entscheidet sich eh meist im Kontext.
Keine Programmiersprache ist fehlerfrei. Auch bei C gibt es einige Dinge, die unschön sind und man noch verbessern könnte. Aufgrund der sehr großen Verbreitung von C, kann man Änderungen aber nur schwer nachträglich einbauen. Aber wer einmal C verstanden hat, der möchte nichtmehr zu Basic oder Pascal zurück. C hat eine sehr logisch aufgebaute Syntax, man kann beliebig komplexe Ausdrücke schreiben. Peter
Hallo, und C hat natürlich auch noch einen Mehrwert. Auch wenn sich viele Über die C Syntax und den Kram aufregen so ist C hier doch Vorbild für die meisten neuen Sprachen. Java.PHP, etc sind alle enstsprechend bzgl der Vergleiche und dem Semikolon am ende des Statements und so weiter. Wer einmal C gelernt hat kann zumindest auch in anderen Sourcen noch was erkennen. Das macht den Einstieg in neue Sprachen deutlich einfacher.
Was in der bisherigen Diskussion über die Unterschiede von C und Basic noch nicht angesprochen worden ist, sind die verfügbaren Datentypen. Insbesondere Bascom ist da etwas spartanisch, weil es m.W. keine benutzerdefinierten Datenstrukturen (Structs in C) und auch keine mehrdimensionalen Arrays (auch keine Arrays von Arrays) gibt. Ohne mehrdimensionale Arrays kann man zu Not noch leben, aber Structs sind in vielen Fällen schon hilfreich. Man kann das über Umwege natürlich alles irgendwie nachbilden, was dann aber meistens die Lesbarkeit mindert. Man kann sich auch auf den Stand- punkt stellen, dass auf einem ATtiny mit nur wenigen kiB Programmspei- cher die Programme so einfach sind, dass man auch mit elementaren Daten- typen auskommt. Vielleicht wird Bascom wegen der Codegrößenbeschränkung in der Demoversion hauptsächlich auf solchen kleinen Controllern eingesetzt, aber es gibt ja auch den ATmega2560, auf dem schon recht komplexe Programme implementiert werden können. Andere neuere Basic-Dialekte (z.B. Visual-Basic) haben diese Nachteile nicht. Auch Luna (was ich mir aber noch nicht genau angesehen habe), scheint diezbezüglich schon deutlich mehr als Bascom zu bieten.
"Beginner’s All-purpose Symbolic Instruction Code" Betonung auf ...
Joachim Drechsel schrieb: > "Beginner’s All-purpose Symbolic Instruction Code" Nicht auf allem ist das drin, was drauf steht. Das mag 1964 die Intention bei der Entwicklung der Sprache gewesen sein, aber die Zeiten sind lange vorbei. Oliver
Also ich benutze auch C, weils einfach so gekommen ist. Also es ist nicht so, dass ich Basic oder so extra gemieden habe. Aber für C spricht meiner Meinung (und das auch, wenn es der einzige Vorteil wär), dass es einfach überall standard ist. Ob Compiler, Beispielcode oder Libs/Funktionen o.ä. Ich weiß nicht, wie das bei BASCOM aussieht, aber gibt es dort auch Funktionen (mit Übergabe-/Rückgabewert) oder Pointer? Und das Argument, dass Basic für Beginner/Anfänger ist, mag stimmen. Und es kann sein, dass mit Basic der Einstieg in die Programmierung einfacher ist, das kann ich nicht beurteilen. Doch irgendwann ist man kein Anfänger mehr, auch wenn man kein Profi ist. Es gibt ja auch noch was dazwischen. Und dann zu wechseln, egal welche Sprache, dann hätte man mit dieser auch gleich anfangen können, auch wenn da die Eingewöhnungszeit länger wär. Sprich wenn man eine Polynomregression machen will oder auf ARMs umsteigen will (laut Berichten hier beides nicht so ohne weiteres möglich oder sinnvoll). Für C muss man warscheinlich nur ein bisschen googlen und hat eine lib für die Berechnung, wohin gegen das für BASCOM denke ich nicht so ausgiebig ist. Vielleicht findet man da auch was.. Ich mein nur, dass durch das weiter verbreitete C dafür auch eine ordentliche und funktionierende lib warscheinlicher ist zu finden.
ich weiß gar nicht, warum das immer so eine Glaubensfrage wird bei einigen... Ich kann C und ich kann Bascom programmieren. Software für den PC schreibe ich in Delphi. Damit sind alle Argumente wider einer strukturierten Programmierung widerlegt! Ich kann sowas auch in BASCOM... Wenn ich, gerade auch in diesem Forum, den Spaghetticode in C sehe, beweist das zumindest, entgegen obiger Aussasgen, dass man Mist auch in C produzieren kann. Ich stelle immer wieder fest, dass gerade "Unbelehrbare C'ler" garnicht über ihren Tellerrand schauen können; weil sie nix anderes können. In diesem Sinn, jedem das Seine
Wenn ich die Ehre hatte Jemandem etwas beibringen zu können, stellte ich fest dass die "Basic-Programmierer" oftmals figelanter waren als manche der oftmals schon in jungen Jahren allwissenen "C-Programmierer". Denn genau das ist es: mal eben schnell woanders wühlen und schon hat man es. Selbst den Grips anstrengen machen nur die, die es müssen wenn es nichts gibt. Beim Thema Programmiersprachen darf ich die Vermutung äußern, dass Diejenigen die ihren eigenen Gramatikparser programmieren, wohl eher nicht aus der C-Ecke kommen. Da wird mal "eben schnell" BISON und Konsorten angeworfen und die Sache ist erledigt. Was ich damit sagen will ist: Es ist schlussendlich entscheidender wer vor der Tastatur sitzt, erst daran anschließend folgt das Werkzeug. Ein miserabler C-Programmierer wird immer miserabel bleiben und ein miserabler Basic-Programmierer wird auch mit C nicht besser. Ehrhardt
Joachim Drechsel schrieb: >>> C: uint8_t buf[8]; > > Klar. Es ist zwar das gleiche Nein! Ein char ist ein Byte. Ein uint8_t ist ein vorzeichenloser Ganzzahltyp mit Breite 8 Bit.
XTerminator schrieb: > Joachim Drechsel schrieb: >>>> C: uint8_t buf[8]; >> >> Klar. Es ist zwar das gleiche > > Nein! > > Ein char ist ein Byte. > > Ein uint8_t ist ein vorzeichenloser Ganzzahltyp mit Breite 8 Bit. Nein - die Bedeutung gebe ich diesen 8 Bit, niemand anders. Ob das ein 0x41 oder ein 'A' bedeutet ist schlicht meine Sache.
Joachim Drechsel schrieb: >> Ein char ist ein Byte. >> >> Ein uint8_t ist ein vorzeichenloser Ganzzahltyp mit Breite 8 Bit. > > Nein - die Bedeutung gebe ich diesen 8 Bit, niemand anders. > Ob das ein 0x41 oder ein 'A' bedeutet ist schlicht meine Sache. Du weißt schlichtweg nichtmal ob char 8 bit sind. Soviel zu "deiner Sache" Siehe Ansi C, 3.1.2.5 und 3.5.2 Hier 3.1.2.5: > The type char, the signed and unsigned integer types, and the > floating types are collectively called the basic types. Even if the > implementation defines two or more basic types to have the same > representation, they are nevertheless different types. > > There are three character types, designated as char , signed char , > and unsigned char.
Joachim Drechsel schrieb: >> Ein char ist ein Byte. >> >> Ein uint8_t ist ein vorzeichenloser Ganzzahltyp mit Breite 8 Bit. > > Nein - die Bedeutung gebe ich diesen 8 Bit, niemand anders. > Ob das ein 0x41 oder ein 'A' bedeutet ist schlicht meine Sache. Hör auf zu jammern, ein char ist per definitionem ein Byte. Schluß. Aus. Ende.
Hallo Bastelfreunde, immer wieder lustig diese C vs. BASIC Diskussionen. Ich sehe es wie Six. Jedem das Seine. Wenn ich eine Sprache gut kann, dann kommt auch guter Code bei raus. "Bastele" ich (womöglich per Copy und Paste) Code zusammen, den ich nicht verstehe, der aber irgendwie doch funktioniert, dann kommt auch unperformanter Code am Ende raus. Ich selbst habe in Basic angefangen und arbeite damit auch am PC. GW-Basic nutze ich nicht mehr, VB6 nutze ich immer noch gern. Selbst Win7 bringt die nötigen Laufzeitdateien (Ausser eigene / fremde Bibliotheken oder Controls) mit. Für VS 2010 benötige ich, egal welche Sprache ich nutze, das Framework. Dieses hat nicht jeder, bzw möchte nicht jeder (z.b. ich auf der Arbeit...) Ein "Hallo Welt" benötigt beim ersten Start in VB2010 und Co wesentlich länger bis es erscheint als unter VB6, da das speicherhungrige Framework erst noch geladen wird. Am uC sehe ich es ähnlich. Mal eben schnell einen Code in BASCOM anpassen gelingt mir wesentlich schneller als in C. Viele Programmierer erzeugen sich bequemere Funktionen unter C, um die doch komplexe Schreibweise zu umgehen (Bit setzen / löschen zum Beispiel). Durch meine Homepage bin ich auch gezwungen php zu nutzen. Diese Sprache lehnt sich meiner Meinung nach stark an C an. Jedoch bietet sie viele weitere Funktionen, welche das Leben eines Webmasters vereinfachen. Eigene uC Projekte enstehen bei mir zu 97% in BASCOM. Die übrigen 3 % sind InlineAssembler. C nutze ich nur, wenn ich "fremden" Code an meine Vorstellungen anpasse. Das BASCOM-Code generell langsamer ist, kann ich so nicht unterschreiben. Das mehrere verschachtelte Berechnungen nicht funktionieren finde ich zwar schade, aber nicht als KO - Kriterium. Wenn man die Eigenarten kennt, kann man damit umgehen. Wenn ich jetzt mal ein älteres Projekt überarbeite, frage ich mich manchmal schon, was ich mir damals dabei gedacht habe. Heute mache ich vieles anders als zu Anfang. Man lernt halt ständig weiter (oder wächst mit seinen Aufgaben). Nutze ich Lookup Tabellen und "Datas", spare ich eine Menge Platz und schnell geht es auch. Die "Push/Pop-Orgie" lässt sich umgehen. Jedoch sind dafür dann ASM-Kenntnisse von Vorteil. Grüße peterfido
XTerminator schrieb: > Hör auf zu jammern, ein char ist per definitionem ein Byte. Wer auch immer das definiert haben mag. Jedenfalls nicht der C-Standard. Zumindest nicht, wenn du mit "Byte" das meinst, was Standards gemeinhin als "Octet" bezeichnen, also eine Ansammlung von 8 Bits. Eine Implementierung kann auch dann konform zum C-Standard sein, wenn sie gar keine (einzeln adressierbare) Dateneinheit der Größe 8 Bits kennt und daher ein char als bspw. 32 Bits festlegt. Daher gibt's im C-Standard auch die Konstante CHAR_BIT (Abschnitt 5.2.4.2.1).
Jörg Wunsch schrieb: > XTerminator schrieb: >> Hör auf zu jammern, ein char ist per definitionem ein Byte. > > Wer auch immer das definiert haben mag. Der Standard. > Jedenfalls nicht der C-Standard. Zumindest nicht, wenn du mit "Byte" > das meinst, was Standards gemeinhin als "Octet" bezeichnen, also > eine Ansammlung von 8 Bits. Nein, ich meine das, was der Standard "Byte" nennt. 3.6 1 byte addressable unit of data storage large enough to hold any member of the basic character set of the execution environment 2 NOTE 1 It is possible to express the address of each individual byte of an object uniquely. 3 NOTE 2 A byte is composed of a contiguous sequence of bits, the number of which is implementationdefined. The least significant bit is called the low-order bit; the most significant bit is called the high-order bit. Ein Oktett ist etwas anderes, wie du ganz richtig erkannt hast. > Eine Implementierung kann auch dann konform zum C-Standard sein, wenn > sie gar keine (einzeln adressierbare) Dateneinheit der Größe 8 Bits > kennt und daher ein char als bspw. 32 Bits festlegt. Ach, schau mal einer an. Davon rede ich ja seit mehreren Postings. Vielleicht solltest du erstmal lesen, bevor du wild Contra zu geben versuchst.
Jörg Wunsch schrieb: > Eine Implementierung kann auch dann konform zum C-Standard sein, wenn > sie gar keine (einzeln adressierbare) Dateneinheit der Größe 8 Bits > kennt und daher ein char als bspw. 32 Bits festlegt. > > Daher gibt's im C-Standard auch die Konstante CHAR_BIT (Abschnitt > 5.2.4.2.1). Mal wieder was dazu gelernt. Mal meine Formulierung als C Novize aus der Basic Ecke. Es gibt keine Festlegung wie groß irgendeine "Dateneinheit" sein soll. Ein char kann auch ein Megabit groß sein falls irgendeiner das braucht oder eine zukünftige CPU so große Register hat. Das ist natürlich sehr Vorteilhaft um die Sprache zu portieren wohingegen die Möglichkeit besteht (die Basic per Definition nicht hat) Sourcecode zu portieren. Das geht aber nciht von selber, man muss selbst dafür sorgen, z.B. mit Typedefs oder Mittels stdint.h (was immer die auch bewirken mag). Stimmt das in etwa?
XTerminator schrieb: > Nein, ich meine das, was der Standard "Byte" nennt. Du interpretierst den Text falsch. Da steht, dass Byte genügend Platz bieten muss um alle Character Repräsentationen aufzunehmen. Das ist nicht gleichbedeutend mit Char ist Byte. Es sind durchaus 7-bit Chars bei 8 Bit Byte als auch 8 Bit Chars bei 16 bit Bytes möglich, oder jede andere Kombination bei der a-bit chars in b-bit bytes passen, also a<=b gilt.
max schrieb: > Du interpretierst den Text falsch. Nein. > Da steht, dass Byte genügend Platz bieten muss um alle Character > Repräsentationen aufzunehmen. Das ist nicht gleichbedeutend mit Char > ist Byte. Man muß natürlich im Standard noch weiterlesen. Das ist keine FAQ mit "Frage: Antwort". > Es sind durchaus 7-bit Chars bei 8 Bit Byte als auch 8 Bit Chars bei 16 > bit Bytes möglich, oder jede andere Kombination bei der a-bit chars in > b-bit bytes passen, also a<=b gilt. Nein. In C unmöglich. Ein char ist immer gleich einem Byte. sizeof(char) ist definiert als 1: |6.5.3.4 (3): |When applied to an operand that has type char, unsigned char, or signed |char, (or a qualified version thereof) the result is 1. Und die Einheit, in der sizeof sein Ergebnis liefert, ist Byte: |6.5.3.4 (2): |The sizeof operator yields the size (in bytes) of its operand So, können jetzt bitte all diejenigen, die den Standard noch nie von nahem gesehen haben, die Füße still halten? Danke.
max schrieb: > XTerminator schrieb: >> Nein, ich meine das, was der Standard "Byte" nennt. > > Du interpretierst den Text falsch. > Da steht, dass Byte genügend Platz bieten muss um alle Character > Repräsentationen aufzunehmen. Das ist nicht gleichbedeutend mit Char > ist Byte. > > Es sind durchaus 7-bit Chars bei 8 Bit Byte als auch 8 Bit Chars bei 16 > bit Bytes möglich, oder jede andere Kombination bei der a-bit chars in > b-bit bytes passen, also a<=b gilt. Ja und diese Erkenntnis macht einen char Datentypen für alles außer Zeichen, zumindest wenn man nach dem Standard geht, unbrauchbar.
XTerminator schrieb: > So, können jetzt bitte all diejenigen, die den Standard noch nie von > nahem gesehen haben, die Füße still halten? Danke. lach Lesen und Verstehen sind halt zwei Dinge. Festgefahrene (falsche) Ansichten verhindern meist das Erkennen und die Beseitigung von Verständnisproblemen - kleiner Tipp. Natürlich liefert sizeof(char) immer 1 zurück. Das ist die Natur von sizeof. Es liefert die Anzahl der Bytes (als Adressierungsgranularität) die nötig sind den Typen zu speichern. Das heisst aber lange nicht, dass dieses Byte vollständig ausgefüllt ist.
max (Gast) schrieb: XTerminator schrieb: >> So, können jetzt bitte all diejenigen, die den Standard noch nie von >> nahem gesehen haben, die Füße still halten? Danke. > lach > Lesen und Verstehen sind halt zwei Dinge. > Festgefahrene (falsche) Ansichten verhindern meist das Erkennen und die > Beseitigung von Verständnisproblemen - kleiner Tipp. > Natürlich liefert sizeof(char) immer 1 zurück. Das ist die Natur von > sizeof. Es liefert die Anzahl der Bytes (als Adressierungsgranularität) > die nötig sind den Typen zu speichern. Das heisst aber lange nicht, dass > dieses Byte vollständig ausgefüllt ist. Also ich kenne char in C auch nur als 1 Byte, ungeachtet dessen wie die ursprüngliche Definition auszulegen ist oder was der K&R darüber aussagt. Das wirft doch die Frage auf, welche Implementierung ist euch denn bekannt, wo ein char mal mehr als das eine uns allgemein geläufige Byte breit ist? Jetzt mal Butter bei die Fische und Namen genannt! Bin gespannt!
Adler schrieb: > wo ein char mal mehr als das eine uns allgemein geläufige > Byte breit ist? Jetzt mal Butter bei die Fische und Namen genannt! Anders herum ist die Aussage. Ein char muss ein Byte nicht ausfüllen. 16 Bit Bytes hat zum Beispiel TI's C55x C Compiler. ( http://www.ti.com/lit/ug/spru281f/spru281f.pdf ) 5.1.1: > The source (host) and execution (target) character sets are assumed to > be ASCII. There are no multibyte characters. (ISO 5.2.1, K&R A12.1) Also 7(8) Bit Entropie. Der tatsächlich belegte Speicher jedoch 16 bit, wie Tabelle 5.2 auflistet: > Type Size Representation Minimum Value Maximum Value > char, signed char 16 bits ASCII −32768 32767 > unsigned char 16 bits ASCII 0 65535
Adler schrieb: > Das wirft doch die Frage auf, welche Implementierung ist euch > denn bekannt, wo ein char mal mehr als das eine uns allgemein geläufige > Byte breit ist? Das prominenteste Beispiel sind irgendwelche (mittlerweile schon etwas ältere) DSPs von TI, deren kleinste adressierbare Einheit 32 bits sind. Im entsprechenden C-Compiler ist folglich ein char dann auch 32 bits groß. (Falls der Compiler nach C99 portiert worden ist, wäre das dann eine Maschine, auf der es kein uint8_t geben kann, wohl aber uint_least8_t und uint_fast8_t.)
max schrieb: > lach > Lesen und Verstehen sind halt zwei Dinge. > Festgefahrene (falsche) Ansichten verhindern meist das Erkennen und die > Beseitigung von Verständnisproblemen - kleiner Tipp. Deine Dummheit ist bemerkenswert.
XTerminator schrieb: > Deine Dummheit ist bemerkenswert. Danke danke. Ich darf dir auch ein Kompliment machen deine Sachlichkeit, Argumentation und soziale Kompetenz erreicht immer neue Rekordwerte.
max schrieb: > Adler schrieb: >> wo ein char mal mehr als das eine uns allgemein geläufige >> Byte breit ist? Jetzt mal Butter bei die Fische und Namen genannt! > > Anders herum ist die Aussage. > Ein char muss ein Byte nicht ausfüllen. > > 16 Bit Bytes hat zum Beispiel TI's C55x C Compiler. ( > http://www.ti.com/lit/ug/spru281f/spru281f.pdf ) Genau. Und damit hat das Byte 16 Bit. > 5.1.1: >> The source (host) and execution (target) character sets are assumed to >> be ASCII. There are no multibyte characters. (ISO 5.2.1, K&R A12.1) Kleiner Tip: Ein "member of the basic execution character set" und ein "char" sind zwei ganz verschiedene Dinge. Oder um mal dein eigenes PDF zu zitieren (5.3): Note: C55x Byte is 16 Bits By ISO C definition, the size of operator yields the number of bytes required to store an object. ISO further stipulates that when sizeof is applied to char, the result is 1. Since the C55x char is 16 bits (to make it separately addressable), a byte is also 16 bits. This yields results you may not expect; for example, sizeof (int) == 1 (not 2). C55x bytes and words are equivalent (16 bits). Hast du jetzt wenigstens die Größe, mich um Verzeihung zu bitten? Oder darf ich dir stattdessen einen elenden Tod wünschen?
Und ncoh ein allerletztes Zitat, aus der ANSI C Rationale: http://www.lysator.liu.se/c/rat/title.html "A char (or signed char or unsigned char) occupies exactly one byte." Aber die Flachpfeife max weiß das alles viel besser als das X3J11 Committee...
Hey. Noch eine Stufe und ich dachte du wärst am unteren Ende angekommen. Für die Fehleinschätzung kann ich mich nur entschuldigen. Wird mir nicht nochmal passieren. Sag mal wo lernt man das, dass man einen elenden Tod zu wünschen, wenn andere einem nicht zustimmen? Wenn dies bei dir öfters geschieht, kann ich dir nur einen Arzt empfehlen. Es lebt sich länger und angenehmer, wenn man ausgeglichen ist :-) Zudem empfehle ich dir deine Zitate nochmal zu lesen. Sie bestätigen meine Aussage nur. Ich kann nur vermuten, dass dein Problem darin liegt den unterschied zwischen der Speichergranularität und dem Typ zu unterscheiden. Ein Character auf diesem System ist als ASCII spezifiziert. Die drei Character Typen benötigt also (mindestens) 7 Bits. In dem Zitat, dass du anbringst wird darauf hingewiesen, dass 16 bit als Speicherung gewählt wird, damit es einzeln adressiert werden kann. Die Größe also 16 Bit ist. Das macht sich dann auch in dem neuen Post bemerkbar. Du unterscheidest nicht zwischen Speicherbelegung und Typ. Das ist aber wichtig hier. Mit dem Wissen sollte dir das "occupy" aufgefallen sein. Warum würde man die Formulierung verwenden statt zu sagen "a char is a byte"? Ein Typ wird nicht allein durch seine Größe definiert.
Karl Heinz Buchegger schrieb: > Ich kann nur sagen: > Meistens sind diejenigen, die sich über C mockieren, genau diejenigen > die C nie richtig gelernt haben. Hallo, du Moderator, nun ja, wenn du nur dieses sagen kannst, dann ist (Zitat) "der Rest schweigen" - gelle? Aber mal im Ernst: Du wolltest sicherlich was anderes sagen, nämlich etwa so: "..genau diejenigen, die C nie verinnerlicht haben." Das stimmt allerdings. Wer seine Nase auch mal über den Tellerrand von C gehalten hat, auch noch was anderes als C kennt, ist durchaus in der Lage, C mit dem nötigen Maße an kritischem Abstand zu sehen - inclusive Mockieren. Ich sehe das jedes Jahr auf der Embedded: Das Angebot an Debuggern und Emulatoren ist enorm - offenbar wird es von der Mehrzahl der Programmierer entsprechend dringlich benötigt. Alles nur aus Jux? Nee, die Leute programmieren sich was zusammen und brauchen dringend den Debugger weil's nicht so funktioniert wie gedacht, sondern so, wie hingeschrieben. C ist sehr weit verbreitet, aber C ist nicht wirklich gut. Naja, die ideale Programmiersprache wird es wohl erst im Schlaraffenlande geben. Bis dahin darf bis auf's Messer gestritten werden. Es sind immer nur die Fanatiker, die keine Kritik an ihrem Glaubensgegenstand ertragen - und bei C sehe ich trotz ANSI ne Menge übler Geburtsfehler, mit denen man halt leben muß. Aber diese auch noch gut zu finden, ist pervers. Es gab auch Zeiten, wo sich die Fachleute darin einig waren, daß Fortran das einzigseligmachende Evangelium sei.. Schönen Abend noch W.S.
max schrieb: > Hey. Noch eine Stufe und ich dachte du wärst am unteren Ende angekommen. Tja, vielleicht treffe ich dich da unten ja. > Sag mal wo lernt man das, dass man einen elenden Tod zu wünschen, wenn > andere einem nicht zustimmen? Och, wenn mir andere nicht zustimmen, habe ich kein Problem. Wenn die anderen mich dumm anmachen und dabei jegliche Erklärungen ignorieren, stattdessen aber ihre falschen Vorstellungen stumpf wiederholen, dann nervt das. > Wenn dies bei dir öfters geschieht, kann ich dir nur einen Arzt > empfehlen. Es lebt sich länger und angenehmer, wenn man ausgeglichen ist > :-) Ich reagiere mich einfach hier im Forum ab. Ist auch sehr gesund. > Ein Character auf diesem System ist als ASCII spezifiziert. Die drei > Character Typen benötigt also (mindestens) 7 Bits. In dem Zitat, dass du > anbringst wird darauf hingewiesen, dass 16 bit als Speicherung gewählt > wird, damit es einzeln adressiert werden kann. Die Größe also 16 Bit > ist. Lernst du vielleicht irgendwann noch einmal, daß ein "character" (also ein Element des character sets ASCII) mit einem "char" nichts, aber auch gar nichts zu tun hat? Habe ich ja auch erst dreimal geschrieben. Siehe oben: stumpfes Wiederholen.
Autor: Jörg Wunsch (dl8dtl) (Moderator) schrieb: Adler schrieb: >> Das wirft doch die Frage auf, welche Implementierung ist euch >> denn bekannt, wo ein char mal mehr als das eine uns allgemein geläufige >> Byte breit ist? > Das prominenteste Beispiel sind irgendwelche (mittlerweile schon etwas > ältere) DSPs von TI, deren kleinste adressierbare Einheit 32 bits > sind. Im entsprechenden C-Compiler ist folglich ein char dann auch > 32 bits groß. (Falls der Compiler nach C99 portiert worden ist, wäre > das dann eine Maschine, auf der es kein uint8_t geben kann, wohl aber > uint_least8_t und uint_fast8_t.) Da kann ich auch ein Beispiel beisteuern. DSP56000. Motorolas Optimizing C Compiler hatte dort beim char eine Wortbreite von 24 bit bzw. für unsigned char Werte von 0 bis 0xffffff. Dachte eigentlich eher ein Beispiel aus dem Bereich PC. ;)
Hehe. Abreagieren hat im Normalfall ein Absinken des Frustes zur Folge. Bei dir erkennt man an der Degeneration deiner Ausdrucksweise eher das Gegenteil davon. Dennoch, bei der Wahl deiner Worte suche dir Rat. > Lernst du vielleicht irgendwann noch einmal, daß ein "character" (also > ein Element des character sets ASCII) mit einem "char" nichts, aber > auch gar nichts zu tun hat? Tja. In dem konkreten Beispiel leider falsch. Wie war das mit sinnlos wiederholen? Es wird nach deinen 3 Mal nicht richtiger. Standard: > An object declared as type char is large enough to store any member > of the basic execution character set. If a member of the required > source character set enumerated in $2.2.1 is stored in a char object, > its value is guaranteed to be positive. If other quantities are > stored in a char object, the behavior is implementation-defined: the > values are treated as either signed or nonnegative integers. Execution characterset im Beispiel > The source (host) and execution (target) character sets are assumed to > be ASCII. There are no multibyte characters.
max schrieb: >> Lernst du vielleicht irgendwann noch einmal, daß ein "character" (also >> ein Element des character sets ASCII) mit einem "char" nichts, aber >> auch gar nichts zu tun hat? > > Tja. In dem konkreten Beispiel leider falsch. Wie war das mit sinnlos > wiederholen? Es wird nach deinen 3 Mal nicht richtiger. Nein, richtig. Deine planlosen Zitate ändern nichts daran. Nur weil beide Begriffe in einem Satz gemeinsam auftauchen, sind char und element of a character set nicht dasselbe. Kann man dich jetzt nicht endlich mal einschläfern? Und wo sind eigentlich die Mods? Hallo, Jungs! Bringt mal den Müll raus!
Oh Leute - ihr spinnt doch echt, das macht euch sympathisch :-)))))))) (normal ist Durchschnitt und der ist langweilig und kann kein C oder ist BWLer). Herzliche Grüße, Joe.
Wow, wie spannen zu lesen doch wieder mal dieser Glaubenskrieg war :-) @Asmhobbyist Eine wichtige Frage für die Entscheidung C/Basic ist aber noch nicht gefallen: In welcher Sprache gibt es mehr Bibliotheken, Beispielcode, Hilfe, Dokus etc. damit es auch bei zukünftigen Projekten das Rad nicht immer wieder neu erfunden werden muss? Wäre das nicht wichtig, würde ich zum Windowsprogrammieren die WTL nehmen.. Schiko, (Der mal mit Basic auf 'nem Commodore PET angefangen, und sich dann über Pascal, asm, c vor 20 Jahren zu c++ durchgearbeitet hat)
Ich find das enorm, wie aggressiv manche Leute hier werden können (also in diesem Forum, nicht nur diesen Thread), wegen eigentlich nichts. Aber das soll mir egal sein. So wie ich das aus den Zitierten Textstellen rausgelesen habe ist ein char immer ein Byte groß, wobei die Bytegröße (Anzahl der Bits) auch größer als 8 sein kann. Somit ist ein char zwar ein Byte aber nicht unbedingt 8 Bit. Da ein ASCII-Zeichen 7 oder 8 Bit hat, kann ein char immer ein Zeichen speichern, doch wenn ein Byte z.B. 16 bit hat und somit 1 char auch 16 Bit hat, kann man deswegen nicht gleich 2 Zeichen speichern. Wenn mir beide zustimmen, versteh ich deren Problem nicht. Und... Ich hab nie gesagt, dass das richtig ist (ist eher als Nachfrage gemeint), also bitte nicht gleich abfällig werden. Meiner Meinung nach ist das aber doch ansich dämlich ein Byte größer als 8 Bit zu machen oder nicht? Wenn ein "normaler" 8bitter µC die Angabe hat, er hat ein 1024B EEPROM, dann ist doch die Größe 1024Byte=8192Bit. Wenn ein 16bitter, wo ein Byte 16bit hat, auch einen 1024B EEPROM hat, dann muss er doch 1024Byte=16384Bit haben, da für diesen µC gilt, dass ein Byte 16 bit sind. Wenn das so ist, find ich das irgendwie so ungeregelt, dass man bei "gleicher" Größe die doppelte bitanzahl hätte. Wenn das nicht so ist, dann ist das doch auf einer Seite beschiss und auf der anderen auch Falsch, da ja eben ein Byte in dem Bauteil 16 bit sind.
Ach und Schiko: Das habe ich auch schonmal erwähnt, dass das auch wichtig ist und aus meiner sicht da C eben die Nase vorn hat. Und wie von jemand anderem gesagt wurde, gibt es keinen bis kaum einen Basic-Compiler für ARMs.
ich schrieb: > Meiner Meinung nach ist das aber doch ansich dämlich ein Byte größer als > 8 Bit zu machen oder nicht? Das Byte hat ja (meiner Meinung nach) weiterhin 8 Bit. Wenn das System aber so organisiert ist, dass man nicht jees Byte einzeln adressieren kann, dann wird eben statt eines Bytes der kleinste adressierbare Bereich im Speicher verpulvert. Und dann könnte ein Char eben mehrere Bytes belegen, weil sie einzeln nicht erreichbar (adressierbar) wären. ich schrieb: > Ich find das enorm, wie aggressiv manche Leute hier werden können Stimmung, Konfetti... ...
Hannes Lux schrieb: > Das Byte hat ja (meiner Meinung nach) weiterhin 8 Bit. Hab ich auch immer gedacht, doch im Wikipedia-Artikel steht: Definitionen: * eine Maßeinheit für eine Datenmenge von 8 Bit mit dem Einheitenzeichen „B“, wobei es nicht auf die Ordnung der einzelnen Bits ankommt. * .... * die kleinste adressierbare Datenmenge eines bestimmten technischen Systems. Das heißt, man könnte ein Byte als die kleinst adressierbare Datengröße definieren, im 16bit µC dann 16 bit. XTerminator schrieb: > Note: C55x Byte is 16 Bits > By ISO C definition, the size of operator yields the number of bytes > required > to store an object. ISO further stipulates that when sizeof is applied > to char, > the result is 1. Since the C55x char is 16 bits (to make it separately > addressable), > a byte is also 16 bits. This yields results you may not expect; for > example, > sizeof (int) == 1 (not 2). C55x bytes and words are equivalent (16 > bits). Hier verstehe ich das so, dass das Byte als 16bit definiert ist und da ein char als ein Byte definiert ist (weshalb sizeof(char) immer 1 ist), hat ein char auch 16 bit, ein character, sprich Zeichen der ASCII-Tabelle aber nur 7/8 bit. Also belegt/reserviert ein Zeichen 16 bit, benötigt aber nur 7/8 Bit.
ich schrieb: > doch im Wikipedia-Artikel steht: Ja sicher doch, bei den von mir benutzten Systemen (6502, PC, AVR) hat ein Byte aber 8 Bit, also ist mir diese Haarspalterei völlig schnuppe. Und aufgrund der begrenzten mir noch zustehenden Lebenszeit werde ich wohl nicht mehr so tief in andere Systeme einsteigen, dass der Unterschied zwischen Byte und direkt adressierbarer Einheit eine Rolle spielen würde. Zum Thema: Ich benutzte BASIC und Assembler (gemischt) auf dem 6502-kompatiblen System, benutze BASIC (QB, VB6) auf dem PC und ASM auf dem AVR, ganz selten auch mal Bascom, aber damit steht man sich meist selbst im Weg, wenn man es nicht virtuos beherrscht. ...
Bei mir reicht das bisher auch, nur wenn man mal etwas größere µCs betrachtet, wird das evtl schon eine Rolle spielen. Ich frag mich bloß, warum dann ein Byte nicht 8 bit bleibt. Beim PC juckt es eigentlich keinen ob ein Byte 8 bit groß ist, das aber in einer 32bit Speicherzelle liegt oder ob das Byte 32bit groß ist und in der gleichen Speicherzelle liegt. Ausschlaggebend sind ja die Datentypen, und ob ich jetzt ein int16 nehme oder ein normalen int32, werden bei beiden 32bittige Adressen zugewiesen. Wenn man beispielsweise nur einen Zähler im µC braucht, der bis 100 zählt, reichen 8 bit ja aus, vielleicht managed der Compiler (bei Platzoptimierung) das ja so, dass er in eine Speicherzelle 4 int8 variablen packen kann. Naja wie auch immer, für mich sind ein Byte 8bit. Weiß jemand wie das bei Festplatten aussieht? Sind das bei 1Byte 8bit oder 32? Ich schätze mal 32.
ich schrieb: > Das heißt, man könnte ein Byte als die kleinst adressierbare Datengröße > definieren, im 16bit µC dann 16 bit. Man könnte aber auch im C-Standard nachschlagen, und nachlesesn, daß das nicht nur so sein könnte, sondern so ist. >A byte is composed of a contiguous sequence of bits, the number of which >is implementation defined Die Definition "Byte" im C-Standard unterscheidet sich damit von der landläufigen Definition. Erklär DAS mal einem Basic-Freak ;) Das alles hat aber gar nichts mit dem (klassischen) Flame-War "Basic gegen den Rest der Welt" zu tun. Oliver
W.S. schrieb: > Karl Heinz Buchegger schrieb: >> Ich kann nur sagen: >> Meistens sind diejenigen, die sich über C mockieren, genau diejenigen >> die C nie richtig gelernt haben. > > Hallo, du Moderator, > > nun ja, wenn du nur dieses sagen kannst, dann ist (Zitat) "der Rest > schweigen" - gelle? Nö. Einfach übersehen. Die Frage war: Woran erkennt man, dass man es richtig gelernt hat". Schwierige Frage. Die Gegenfrage ist leichter: Woran erkennt man, das man es nicht richtig gelernt hat? Wer Aussprüche ala "C verwirrt mich mit seinen Sonderzeichen" tätigt, hat C nie richtig gelernt. Wer mit Data Type Promotion Regeln Schwierigkeiten hat, hat C nie richtig gelernt. Wer komplexere Datentypen nicht korrekt lesen und erklärbar in Umgangssprache umsetzen kann, hat C nie richtig gelernt. Wer die Operator Precedence Tabellen nicht kennt, zumindest nicht für die wichtigsten, häufigen Operatoren, hat sein C nie richtig gelernt. Es gibt noch viele andere Inidikatoren, die anzeigen, das der Programmierer C nie richtig gelernt hat, sondern immer nur bruchstückhaft sich Halbwissen zusammengefragt hat. Und jeder einzelne davon taucht in schöner Regelmässigkeit hier im Forum immer wieder auf. Im übrigen was der Ausspruch nicht auf die C-Kenner gemünzt, die durchaus berechtigte Kritik an der Sprache anbringen, sondern auf diejenigen, die mit Ach und Krach eine for-Schleife gerade noch im 5. Anlauf richtig hinkriegen, aber trotzdem meinen, sie wären in der Lage den Zusammenhang Arrayindizierung - Pointer_Dereferenzierung (nur so als Beispiel) zu kritisieren. > Es sind immer nur die Fanatiker, die keine Kritik an ihrem > Glaubensgegenstand ertragen - und bei C sehe ich trotz ANSI ne > Menge übler Geburtsfehler, da bist du nicht alleine. genauso wie auch C++ und jede andere Sprache noch einige Geburtsfehler hat > mit denen man halt leben muß. Aber diese > auch noch gut zu finden, ist pervers. Ich denke nicht, dass die Profis diese Fehler gut finden. Aber irgendwann steht man da mal drüber. Man hat sich mit den Problemen arangiert, kennt sie und kennt auch die Techniken, wie man sie möglichst gut umgehen kann. Das ist doch alles nicht dramatisch. XTerminator und max Kann es sein, dass ihr aneinander vorbeiredet? Das was der C-Standard ein Byte nennt, hat mit dem Byte, wie es physikalisch realisiert ist (als 8 Bit) nichts zu tun. Der Begriff "Byte" hat im C-Standard eine etwas andere Bedeutung.
> Und wo sind eigentlich die Mods? Hallo, Jungs! Bringt mal den Müll raus!
Als Mod würde ich dir erst mal nahelegen, deinen Ton etwas zu ändern.
"ich" schrieb: > Bei mir reicht das bisher auch, nur wenn man mal etwas größere µCs > betrachtet, wird das evtl schon eine Rolle spielen. Nein, bei aktuellen Universalprozessoren und Mikrocontrollern, egal, ob 8-, 16-, 32- oder 64-Bit, spielt das keine Rolle. Alle diese Prozessoren können 8-Bit-Bytes adressieren. Anders sieht es bei DSPs aus. Da es sich bei diesen i.Allg. im reine Rechenknechte handelt, mit denen keine Textverarbeitung gemacht wird, ist es kein großer Nachteil, wenn die kleinste adressierbare Einheit die Größe des Fest- oder Gleitkomma-Datentyps ist, mit dem gerechnet wird. Ich bin das erste Mal auf diesen Sachverhalt gestoßen, als ich mit einem TMS320C40 (Floatingpoint-DSP) herumhantierte. Weil ich mir anfangs nicht sicher war, ob man mit double eine höhere Genauigkeit erreicht als mit float, habe ich in einem Testprogramm sizeof(double) ausgegeben. Die Überraschung war groß, als nur eine 1 angezeigt wurde :)
Karl Heinz Buchegger schrieb: > Wer die Operator Precedence Tabellen > nicht kennt, zumindest nicht für die wichtigsten, häufigen Operatoren, > hat sein C nie richtig gelernt. Ich kenne genuegend Leute, die wuerden diese Tabelle beliebig erweitern, bis der ganze Standard drin steht. Die totale Beherrschung und der staendige Einsatz aller verfuegbaren Moeglichkeiten, die der Standard bietet, wurden mir schon von anderen Entwicklern als minimale Anforderung an einen "richtigen" Entwickler verkauft. Nun bin ich bin seit 20 Jahren professioneller C/C++-Entwickler und stolz darauf, dass ich die Rangfolge der Operatoren nicht auswendig kann. Das kann Jemand, der gerne Standards auswendig lernt, sicher nicht verstehen - aber der Grund ist schlicht, dass ich schon so lange darauf verzichte Code zu schreiben, bei dem Rangordnung der Operatoren eine Rolle spielt. Das ist kein grosser Aufwand und fuer jeden, vor Allem auch schwaechere Entwickler sicher und fehlerfrei lesbar. Denn darauf optimiere ich meinen Code: Auf einfache Wartbarkeit, nicht darauf als Symbol meiner Ueberlegenheit zu fungieren. Ich hab' sie alle gehabt: Assembler, C, C++, Java, Basic, Perl, Python und viele mehr. Die meissten sind sinnvoll, viele (trotzdem) ueberfluessig. Fuer Basic habe ich ueberhaupt keinen Anwendungszweck. Aber fuer Einsteiger ist es nach wie vor eine tolle Sprache. Denn dafuer wuerde es ersonnen. Es muss sich auch niemand schaemen, dass er "nur" Basic programmiert - nur sollte man, wie bei jeder Technologie, die Grenzen sehen und beachten.
GoP schrieb: > Nun bin ich bin seit 20 Jahren professioneller C/C++-Entwickler und > stolz darauf, dass ich die Rangfolge der Operatoren nicht auswendig > kann. Das kann Jemand, der gerne Standards auswendig lernt, sicher nicht > verstehen - aber der Grund ist schlicht, dass ich schon so lange darauf > verzichte Code zu schreiben, bei dem Rangordnung der Operatoren eine > Rolle spielt. Das ist kein grosser Aufwand und fuer jeden, vor Allem > auch schwaechere Entwickler sicher und fehlerfrei lesbar. Denn darauf > optimiere ich meinen Code: Auf einfache Wartbarkeit, nicht darauf als > Symbol meiner Ueberlegenheit zu fungieren. Ja, wenn Karl Heinz als erfahrener Programmierer sowas schreibt, muss ich auch immer schmunzeln. Ich handhabe das so wie du, einfach ein paar Klammerebenen mehr einfügen, anstatt (z.B. als Anfänger) erst mal die Operatorprezedenzen nachzuschauen. Falls das Statement zu unübersichtlich wird (weil zu viele Klammern. Ist ja immer ein häufiges Gegenargument), dann muss man es eben auf zwei Statements aufteilen.
... und die Optimierung dem Compiler überlassen. Ich halte es auch so.
GoP schrieb: > Aber fuer Einsteiger ist es nach wie vor eine tolle Sprache. Denn dafuer > wuerde es ersonnen. Basic kann nichts besser oder einfacher als andere Sprachen. Es kann nur weniger. Das war vor 50 Jahren anders, da gab es keine Alternativen. Aber heute muß man sich das ohne zwingenden Grund nicht mehr antun. Wer heute einsteigen will, kann das gleich mit Java, etc. tun. Oliver
Oliver schrieb: > Wer heute einsteigen will, kann das gleich mit Java, etc. tun. Das ist eine ganz schlechte Idee. Bei Basic bleibt man irgendwann entweder in der eigenen Entwicklung stehen, oder man greift zu einer maechtigeren Sprache und lernt diese. Java suggeriert, dass man den Wurstwegg und den 5er haben kann - was aber in Wahrheit nicht der Fall ist. Oft stehen Java-Projekte irgendwann an der Wand, weil sie ohne Qualitaet eine Komplexitaet erreicht haben, bei der die Projekte mit anderen Sprachen laengst einen Qualitaetssprung erzwungen haetten. Ein guter Weg ist immer noch: Basic -> Assembler -> C/C++ -> Java. Abgesehen davon geht es hier ja immer noch um Mikrocontroller - da hat es mit Bascom eine verbreitete Variante fuer die im Hobbybereich sehr verbreiteten AVR-Controller. Java ist da eher exotisch.
Simon K. schrieb: > einfach ein paar > Klammerebenen mehr einfügen, anstatt (z.B. als Anfänger) erst mal die > Operatorprezedenzen nachzuschauen. > Falls das Statement zu unübersichtlich wird (weil zu viele Klammern. Ist > ja immer ein häufiges Gegenargument), dann muss man es eben auf zwei > Statements aufteilen. Joachim Drechsel schrieb: > ... und die Optimierung dem Compiler überlassen. Ich halte es auch so. Da möchte ich ebenfalls zustimmen. Zwischenergebnisse verschlechtern die Lesbarkeit nicht und machen dem Compiler das Leben nicht schwerer. Gruß, Edson
GoP schrieb: > stolz darauf, dass ich die Rangfolge der Operatoren nicht auswendig > kann. Aber du weißt das es sie gibt und wo du im Zweifelsfall nachsehen kannst. Und du weißt auch, dass du, wenn du dir nicht sicher bist, Klammern setzt. Was du aber nicht tust: Mit dem Wissen, das du dir nicht sicher bist, einfach irgendwelche Annahmen treffen und dann nach dem Auf_die_Nase_fallen dein Versäumnis der Sprache anlasten. > Rolle spielt. Das ist kein grosser Aufwand und fuer jeden, vor Allem > auch schwaechere Entwickler sicher und fehlerfrei lesbar. Geb ich dir recht. Wenn sie es nur tun würden.
Karl Heinz Buchegger schrieb: > GoP schrieb: > >> stolz darauf, dass ich die Rangfolge der Operatoren nicht auswendig >> kann. > > Aber du weißt das es sie gibt und wo du im Zweifelsfall nachsehen > kannst. > Und du weißt auch, dass du, wenn du dir nicht sicher bist, Klammern > setzt. > > Was du aber nicht tust: Mit dem Wissen, das du dir nicht sicher bist, > einfach irgendwelche Annahmen treffen. > >> Rolle spielt. Das ist kein grosser Aufwand und fuer jeden, vor Allem >> auch schwaechere Entwickler sicher und fehlerfrei lesbar. > > Geb ich dir recht. Wenn sie es nur tun würden. Ich kann GoP aus vollem Herzen recht geben. Was nützt die tollste Minimierung von Klammern und 'elegenate' Statements/Tricks, wenn es der Kollege mis- und du selbst es in einem halben Jahr gar nicht mehr verstehst. Keep it simple! Schreib dein Programm so daß es unmissverständlich ist. Performance ist auf dem PC nur bei 0.1% der Fälle ein Argument, bei µC sicher häufiger aber auch nicht öfter als 1 - 10%. Auch wenn es oft als Vorwand für unübersichtlichen Code herhalten muss. Ausserdem sollte der C Compiler auch hier einiges wieder optimieren.
GoP schrieb: > Ein guter Weg ist immer noch: Basic -> Assembler -> C/C++ -> Java. Schlichtes NEIN. Zum Einstieg in die Programmierung (nicht speziell für Mikocontroller) sind weder Basic, noch Assembler, noch C geeignet. Über C++ kann man diskutieren, ebenso über Delphi und Java. Danach zur Spezialisierung auf Mikrocontroller von mir aus Assembler und C. Basic braucht es da nirgends, das ist von Anfang an eine Sackgasse. Oliver
Also ich hab mit PHP angefangen. Es gibt keine wirklichen Datentypen und man kann es ganz simpel mit nem Webserver oder XAMPP (spart man sich das nervige hochladen) testen. Man lernt was Syntax ist, man muss nicht kompilieren und man lernt halt grundlegende Sachen wie if/else, while/for/do-Schleifen, Funktionen, Parameter. Ich fand das simpel, man kann es wie gesagt einfach Testen, man kann es gebrauchen und evtl kleine Seiten damit erstellen, die Doku bei php.net ist umfangreich und übersichtlich und die Syntax ist sehr C ähnlich. Oliver schrieb: > Schlichtes NEIN. Zum Einstieg in die Programmierung (nicht speziell für > Mikocontroller) sind weder Basic, noch Assembler, noch C geeignet. Über > C++ kann man diskutieren, ebenso über Delphi und Java. Dann bleibt ja nichmehr viel über;)
> Syntax ist sehr C ähnlich.
Dann spricht ja nichts gegen das Original ;)
PHP wirkt einfach, birgt aber eine Unzahl an Fallen, nebenbei ist es
recht lahm (im Vergleich zu C). PHP basierte Websites sicher zu machen
erfordert viel Know-How und Arbeit.
Solche Kontrollstrukturen gibt es eigentlich in allen
Programmiersprachen.
Wie willl man eigentlich Java auf einem ATTiny zum Laufen bringen ?
:-)))))
Joachim Drechsel schrieb: > Dann spricht ja nichts gegen das Original ;) > > PHP wirkt einfach, birgt aber eine Unzahl an Fallen, nebenbei ist es > recht lahm (im Vergleich zu C). PHP basierte Websites sicher zu machen > erfordert viel Know-How und Arbeit. Aus meiner Sicht spricht auch nichts gegen, ich fand PHP bloß einfacher, allein weil man sich nicht um Deklarationen kümmern muss. Man nimmt einfach eine Variable und schreibt nen Text rein. Oder man rechnet ein bisschen und greift dann auf das x-te Element eines Array zu, ohne das dieses vorher bestimmt werden musste. Lahm.. evtl. Doch das was eine Website an Anforderungen hat ist auch nicht soo Zeitkritisch. Und für den Lerneffekt ist die Sicherheit erstmal zweitrangig, wobei die Grundlegenden Sicherheitsmaßnahmen wie SQL-Injektion oder das Sperren (bzw erlauben) gewisser Eingaben auch nicht sooo kompliziert ist. Aber das sind ja alles persönliche Erfahrungen und Geschmäcker, was man für wie gut und nützlich für den Einstieg sieht. Für mich ist PHP einfach ein einfaches C, was ein $-Zeichen vor den Variablen hat^^
>Meiner Meinung nach ist das aber doch ansich dämlich ein Byte größer als >8 Bit zu machen oder nicht? Wenn ein "normaler" 8bitter µC die Angabe >hat, er hat ein 1024B EEPROM, dann ist doch die Größe 1024Byte=8192Bit. >Wenn ein 16bitter, wo ein Byte 16bit hat, auch einen 1024B EEPROM hat, >dann muss er doch 1024Byte=16384Bit haben, da für diesen µC gilt, dass >ein Byte 16 bit sind. Wenn das so ist, find ich das irgendwie so >ungeregelt, dass man bei "gleicher" Größe die doppelte bitanzahl hätte. Du verwechselst scheinbar die Datenbreite mit OP-Code-breite. Wenn Daten adressiert werden (oder externe Speicher -egal welcher Art- angesprochen werden) sind 1 Byte immer 8 Bits, sonst gibt es da nix. (bei manchen PDPs waren 1 Byte mal 6 Bits, weil man damit auch rechnen konnte). Die OP-Code-breite kann nat. ganz unterschiedlich sein. >Anders sieht es bei DSPs aus. Da es sich bei diesen i.Allg. im reine >Rechenknechte handelt, mit denen keine Textverarbeitung gemacht wird, >ist es kein großer Nachteil, wenn die kleinste adressierbare Einheit die >Größe des Fest- oder Gleitkomma-Datentyps ist, mit dem gerechnet wird. Aber auch da gibt es fast Keinen, der nicht Bytes adressieren kann. Insbes weil DSPs auch zunehmend GeneralPurp.Aufgaben mit machen können (oder umgekehrt), und DSP und norm.CPU immer mehr zusammmen wachsen
Joachim Drechsel schrieb: > ... und die Optimierung dem Compiler überlassen. Ich halte es auch so. Beifall meinerseits. Eine biedere, nicht "geniale" Quellnotation kommt bei den heutigen Compilern auf denselben Maschinencode hinaus wie eine geniale Schreibweise, die man nach einem Jahr selber nicht mehr auf Anhieb versteht. Aber um mal auf das hier so geschmähte Basic zu kommen: Leute, wacht doch mal auf! Es besteht die Welt nicht nur aus Programmierern, die den ganzen Tag nix anderes machen. Es gibt auch andere Leute, die nur gelegentlich mal eine Berechnung durchziehen wollen. Denen mit C oder Java oder sonstigem Kram zu kommen, der erstmal erheblichen Erklärungsbedarf hat, ist schlichtweg daneben. Basic hingegen ist in 5 Minuten erklärt und es kann beim Benutzen fast nix schiefgehen. Basic hat auch heutzutage noch seine Berechtigung, wenngleich es nicht mehr die 1. Geige spielt. Zupft euch mal an der Nase und fragt euch, was ihr denn sagen würdet, falls ihr mal dringend eine Mechanik-Konstruktion nebst technischer Zeichnung anfertigen müßtet und die gestandenen Konstrukteure euch sagen, da drüben ist das kurzgefaßte 1000seitige Autocad-Handbuch, nu mach mal. So ähnlich geht es anderen Leuten mit dem Programmieren. W.S.
W.S. schrieb: > Zupft euch mal an der Nase und fragt euch, was ihr denn sagen würdet, > falls ihr mal dringend eine Mechanik-Konstruktion nebst technischer > Zeichnung anfertigen müßtet und die gestandenen Konstrukteure euch > sagen, da drüben ist das kurzgefaßte 1000seitige Autocad-Handbuch, nu > mach mal. So ähnlich geht es anderen Leuten mit dem Programmieren. Autocad vs. C ? :-))))))))))))))) Du verwechselst da etwas.
er hat versucht paralleln zu ziehen, vieleicht kann dir die Erklärung einer in C schreiben.... ;-)
W.S. schrieb: > Aber um mal auf das hier so geschmähte Basic zu kommen: Leute, wacht > doch mal auf! Es besteht die Welt nicht nur aus Programmierern, die den > ganzen Tag nix anderes machen. Es gibt auch andere Leute, die nur > gelegentlich mal eine Berechnung durchziehen wollen. Denen mit C oder > Java oder sonstigem Kram zu kommen, der erstmal erheblichen > Erklärungsbedarf hat, ist schlichtweg daneben. Basic hingegen ist in 5 > Minuten erklärt und es kann beim Benutzen fast nix schiefgehen. Basic > hat auch heutzutage noch seine Berechtigung, wenngleich es nicht mehr > die 1. Geige spielt. > > Zupft euch mal an der Nase und fragt euch, was ihr denn sagen würdet, > falls ihr mal dringend eine Mechanik-Konstruktion nebst technischer > Zeichnung anfertigen müßtet und die gestandenen Konstrukteure euch > sagen, da drüben ist das kurzgefaßte 1000seitige Autocad-Handbuch, nu > mach mal. So ähnlich geht es anderen Leuten mit dem Programmieren. Endlich mal ein paar vernünftige Worte. Ich dachte hier sind nur noch Durchgeknallte dabei.
Wenn man keine allzu hohen Ansprüche hat, kommt man mit BASIC auch dahin, ein paar Zahlen zu addieren. Aber es geht hier nicht um einen C64 oder einen PC, sondern um uC. Und was will man da mit einem 5-min-Terrinenprogramm anfangen? Das reicht nur für etwas Lego... Die Zielgruppe von BASIC/Java/... kommt doch dann eh nicht weit, auch wenn sie es immer wieder probieren. Da hilft es auch nicht, an der Nase rum zu spielen.
Bascomnutzer schrieb: > Endlich mal ein paar vernünftige Worte. Ich dachte hier sind nur noch > Durchgeknallte dabei. Also sind alle denen Basic nicht gefällt "Durchgeknallte"? Ich stelle eine alternative Theorie auf: Was fährst du für ein Auto? ich kann genauso sagen jeder der ein Auto fährt das mehr als 4 liter/100km braucht ist eine Umweltsau. Und wer hat recht? Keiner! Nimm dich mal etwas zurück!
Bascomnutzer schrieb: > Endlich mal ein paar vernünftige Worte. Ich dachte hier sind nur noch > Durchgeknallte dabei. Naja, deine Wortwahl lässt auch zu wünschen übrig. Was W.S. hier wiederholt hat, wurde in diesem Thread schon mehrfach bestätigt. Lest halt wenigstens die Beiträge, bevor ihr hier vom Leder zieht. W.S. schrieb: > Zupft euch mal an der Nase und fragt euch, was ihr denn sagen würdet, > falls ihr mal dringend eine Mechanik-Konstruktion nebst technischer > Zeichnung anfertigen müßtet und die gestandenen Konstrukteure euch > sagen, da drüben ist das kurzgefaßte 1000seitige Autocad-Handbuch, nu > mach mal. So ähnlich geht es anderen Leuten mit dem Programmieren. Ich würde ins Inhaltsverzeichnis schauen, mir die Stellen markieren an denen ich Schwierigkeiten erwarte und mit der Arbeit beginnen. Wenn ich nicht weiterkomme, schlage ich da nach. Kein Mensch liest Handbücher von Alpha bis Omega durch, es sei denn er hat nichts Besseres zu tun. Die meisten hier gestellten uC-Fragen lassen sich doch mit wenigen Zeilen aus einem Datenblatt oder Compilerhandbuch beantworten, es kostet nicht viel Zeit dort nachzuschlagen. Trotzdem machen es Viele nicht, wie passt das in deinen Vergleich? Klaus Wachtler schrieb: > Da hilft es auch nicht, an der Nase rum zu spielen. Seh ich auch so. Gruß, Edson
Klaus Wachtler schrieb: > Wenn man keine allzu hohen Ansprüche hat, kommt man mit BASIC auch > dahin, ein paar Zahlen zu addieren. :-) ich spiele mit BASCOM Code AVI Videos auf einem 320x240 16Bit Farbdisplay ab, oder ich betreibe einen M128 oder Xmega mit Ethernetanschluss in den Protokollen TCP/IP, UDP und habe DHCP, NTP, SMTP und sogar MYSQL Zugriffe am laufen (mit SHA1 auf MYSQL >4.1) die Lib's dafür habe ich mir übrigens selbst geschrieben unter Zuhilfenahme der RTFM's. ...und genau das ist oft der Punkt: Das machen manche weder in Bascom noch in C oder sonstwas. Der Rest ist für einen "Programmierer" Pillepalle also bisschen mehr als zwei Zahlen addieren ging bis jetzt immer mit Bascom. Das Problem begrenzt sich doch wohl eher auf wirkliche "ich_mach_nur_selten_was_damit" User oder absolute Hobbyprogrammierer, welche eben darauf nicht DIE Zeit investieren wollen. Diejenigen, welche sich hier um die Bedeutung von Char's balgen, haben in Wirklichkeit keine Probleme in jeder Programmiersprache Fortran zu schreiben... :-) Letztendlich würde ich BASCOM auch nicht bei PIC's verwenden, weil es diese nicht unterstützt :-) Also halte ich mal fest: 1) Der Einstieg für Beginner ist mit BASCOM einfacher, da es ohne Vorkenntnisse einer Programmiersprache besser lesbar ist 2) Der Profi sucht sich das passende Werkzeug für sein Problem nach anderen Gesichtspunkten aus und hat so immense Vorteile Gruß, Michael
... und 3) die Nerds zeigen, das man wirklich aus allem irgendwas rausholen kann :-)
Klaus Wachtler schrieb: > Gibt es eigentlich einen vernünftigen Fortran-Compiler für AVR? Wenn wir denn mal 64-bit-doubles haben, kann man sicherlich GNU FORTRAN dafür compilieren. ;-) Größtes Hemmnis dürfte es dabei nur sein, dass die FORTRAN-Bibliothek wiederum auf unixoide IO-Funktionen zugreifen will, die die avr-libc erstmal nicht bietet.
1 | PROGRAM HELLO |
2 | CHARACTER*1 TXT(7) |
3 | COMMON/DATA/ TXT |
4 | WRITE(6,100) TXT, 8 |
5 | 23, 85 |
6 | 100 FORMAT(1H , 7A, 1H , 2A , 3HCKS) |
7 | STOP |
8 | END |
9 | |
10 | BLOCK DATA INIT |
11 | INTEGER*4 A1 |
12 | INTEGER*1 B2(3) |
13 | COMMON/DATA/ A1, B2 |
14 | DATA A1 /1414680390/ |
15 | DATA B2 /82,65,78/ |
16 | END |
Hmm, da habe ich aber jetzt schon mächtig nachschlagen müssen dafür. ;-) Das nur mal für alle die, die meinen, C hätte eine schräge Syntax ... (Edit: mir ist noch ein schräges Fietscher mehr eingefallen, hab's nochmal geändert. ;-)
Sag mir nichts gegegen Fortran, damit habe ich einige Zeit meine Brötchen verdient!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.