bestimmt, kommt aber auf den Bascom code an.
Wenn dort z.b. eine LCD routine verwendet wird, dann kann man es so
nicht nach C übernehmen weil es das nicht in C gibt.
Peter II schrieb:> bestimmt, kommt aber auf den Bascom code an.>> Wenn dort z.b. eine LCD routine verwendet wird, dann kann man es so> nicht nach C übernehmen weil es das nicht in C gibt.
hier ist der Code(sieh Anhang)
mein Gott schrieb:> Wenn ein C-Programmierer ein LCD-Display ansteuern will, muß er also> Bascom lernen?
nein dann programmiert er sich eine LCD-routine oder er macht es sich
einfach und sucht sie eine im Web und verwendet sie.
mein Gott schrieb:> Interessant, man lernt nie aus.> Wenn ein C-Programmierer ein LCD-Display ansteuern will, muß er also> Bascom lernen?
Ein "C-Programmierer"? Die beiden Begriffe in einem Satz machen ungefähr
soviel Sinn wie ein "intelligenter Vollidiot" oder "hölzerne Steine"!
Abgesehen davon, das man m. E. in "C" nichts anderes als Fehler
produzieren kann, war das wohl vom Poster nicht gemeint.
Peter II schrieb:> mein Gott schrieb:>> Wenn ein C-Programmierer ein LCD-Display ansteuern will, muß er also>> Bascom lernen?>> oder er macht es sich> einfach und sucht sie eine im Web und verwendet sie.
Genau aus diesem Grunde sind die Copy-and-paste Versatzstücke der
"C"-Gemeinde dermaßen fehlerträchtig und unwartbar, weil dort ohne jedes
Verständnis Codefragmente zu einem hässlichen Gesamtelaborat
zusammengeklatscht werden...
Deshalb peogrammiert man in der Indusrue auch so viel Bascom...gell :-)
Wie immer kommt es hierbei auf den Programmierer an wie viel Fehler drin
sind, oder wie der Code aussieht!
Gruß
steffen_B schrieb:> Ein "C-Programmierer"? Die beiden Begriffe in einem Satz machen ungefähr> soviel Sinn wie ein "intelligenter Vollidiot" oder "hölzerne Steine"!>> Abgesehen davon, das man m. E. in "C" nichts anderes als Fehler> produzieren kann, war das wohl vom Poster nicht gemeint.
Zwar ist heute Freitag, aber Forentrolle sammeln sich auch freitags
nicht hier, sondern im Heise-Forum.
Hallo,
das liegt wohl eher an den Leuten die den Code schreiben.
Assembler ist wohl kaum übersichtlicher als C.
Das was ich weiter oben an BASCOM gesehen hab sieht Schxxxe aus.
Und ich hab mal von C-Code gehört der sauber und zuverlässig arbeitet
und wo einige tausend Leute rumarbeiten. Die POSIX bzw. Linux-Kernel
Mailingliste hat mehrere tausend Einträge.
Abgesehen davon ist Programmieren unabhängig von einer Sprache oder dem
Compiler. Das ist dann nur noch Codieren.
Aber sonst ist es wie bei den Autos, egal ob einen Stern oder 4 Ringe,
wer nicht fahren kann, dem hilft keines von beiden.
mfg aus Berlin
NopNop schrieb:> Deshalb peogrammiert man in der Indusrue auch so viel Bascom...gell :-)
Weit verbreitet heißt nicht automatisch, das etwas "gut" ist - Im
Mittelalter z.B. war es weit verbreitet, "Hexen" zu verbrennen...
> Wie immer kommt es hierbei auf den Programmierer an wie viel Fehler drin> sind, oder wie der Code aussieht!
ACK. Dennoch ist C aufgrund seines Sprachkonstrukts und der
Besonderheiten einiger Präprozessoren m. E. für (versteckte) logische
Fehler wesentlich anfälliger als andere Sprachen.
> Gruß
Ebenso...
Es ist doch schlicht&einfach EGAL, welche Programmiersprache ich
verwende, wenn ich verstehe, was ich da mache. Das ist ja sonst wie wenn
man nur mit Bleistiften von Faber auf Papier schreiben könnte. Denn
nichts anderes ist eine Programmiersprache: ein Hilfmittel, um einen
Controller dazu zu bringen, das zu tun, was man will. Genauso ist ein
Bleistift nur ein Hilfsmittel um etwas auf ein Blatt Papier zu schreiben
oder malen.
Und natürlich: richtige Künstler schwören auf "ihre" Bleistifte. Damit
können sie zaubern. Aber wenn grad keiner zur Hand ist, dann bekommen
sie auch mit einem anderen Bleistift was brauchbares hin.
Sahra Nana schrieb:> kann mir jemand einen Code von Bascom nach C übersetzen?
Es ist mit Verlaub totaler Blödsinn, dieses Programm Zeile für Zeile von
Basic nach C zu übersetzen (mag sogar sein, dass es geht, weil da ja nur
die SPI-Schnitte per SW nachgebildet wird).
Besser wäre es, zu verstehen, was da passiert:
alles läuft zum Schluss auf die Software-SPI in der Funktion
Adns2610_write_byte() raus. Dort spielen sich die Hardwarezugriffe ab.
Und dann kommt noch ein wenig UART dazu und fertig.
steffen_B schrieb:> Weit verbreitet heißt nicht automatisch, das etwas "gut" ist - Im> Mittelalter z.B. war es weit verbreitet, "Hexen" zu verbrennen...
Na hör mal...deshalb gibt es heute schließlich keine Hexen mehr!!!
Aber Spaß bei Seite...such Dir mal nen Job und sag Du kannst nur Bascom
und kein C.
Da bin ich mal gespannt ob Du nen Job bekommst.
Auch wenn Bascom tausend mal besser wäre (was ich stark bezweifle), wird
es Dir allerhöchstes Privat was bringen...geschäftlich aber nicht.
Aber lassen wir das...bevor wieder eine der endlosen diskussionen los
bricht.
Gruß und wech...
>Aber Spaß bei Seite...such Dir mal nen Job und sag Du kannst nur Bascom>und kein C.
Genau so! Ich habe einen Kompagnon, der von einer Firma eingestellt
wurde und dort nur in Bascom programmiert. Dem Chef war es völlig Brust,
womit die Programme geschrieben werden, -wichtig war, daß sie das tun,
was sie sollen.
MfG Paul
> Sahra Nana schrieb:>> kann mir jemand einen Code von Bascom nach C übersetzen?> Es ist mit Verlaub totaler Blödsinn, dieses Programm Zeile für Zeile von> Basic nach C zu übersetzen (mag sogar sein, dass es geht, weil da ja nur> die SPI-Schnitte per SW nachgebildet wird).
Es ist vorallem mal wieder ein eindeutiger Fall von "Wer macht mir meine
Hausaufgaben/Diplomarbeit?"!
steffen_B schrieb:> Ein "C-Programmierer"? Die beiden Begriffe in einem Satz machen ungefähr> soviel Sinn wie ein "intelligenter Vollidiot" oder "hölzerne Steine"!
Gibt es für Bascom eigentlich einen Misra-Standard?
http://de.wikipedia.org/wiki/MISRA-C
mein Gott schrieb:> Gibt es für Bascom eigentlich einen Misra-Standard?
Der MISRA Standard wurde wegen Bascom entwickelt... ;-)
> Gibt es für Bascom eigentlich einen Misra-Standard?
Da stellt sich die Frage: braucht Bascom auch einen eigenen Standard?
C könnte so einen Standard brauchen, weil ich jederziet eine C-Zeile
hinschreiben kann, die einigen erhebliches Kopfzerbrechen bereiten
könnte, und die man ohne genaue Kenntnis der Operandenreihenfolge falsch
interpretieren könnte.
Sind bei Bascom solche doppeldeutigen Zu- und Anweisungen auch möglich?
mein Gott schrieb:> Gibt es für Bascom eigentlich einen Misra-Standard?> http://de.wikipedia.org/wiki/MISRA-C
Es ist schon bezeichnend, wenn eine Programmiersprache von sich aus so
unsicher ist, dass man zusätzliche Standards braucht, um zu vernünftigen
Ergebnissen zu kommen ;-)
Lothar Miller schrieb:> C könnte so einen Standard brauchen, weil ich jederziet eine C-Zeile> hinschreiben kann, die einigen erhebliches Kopfzerbrechen bereiten> könnte, und die man ohne genaue Kenntnis der Operandenreihenfolge falsch> interpretieren könnte.
So eine Zeile würde einigen Dummköpfen tatsächlich Kopfzerbrechen machen
- aber nicht dem Compiler. Und nur der muss Dich verstehen.
> Sind bei Bascom solche doppeldeutigen Zu- und Anweisungen auch möglich?
Wo gibt es in C "solche doppeldeutigen Zu- und Anweisungen"? Da ist
alles eindeutig definiert. Eine Programmiersprache wird nicht
doppeldeutig, nur weil jemand sie liest, der sie nicht verstanden hat.
Gruß,
Frank
Duck und wech schrieb:> Es ist schon bezeichnend, wenn eine Programmiersprache von sich aus so> unsicher ist, dass man zusätzliche Standards braucht, um zu vernünftigen> Ergebnissen zu kommen ;-)
Du hast falsch verstanden: Der MISRA-C-Standard wurde entworfen, um die
Risiken durch Unzulänglichkeiten der Programmierer zu minimieren. Lies
den ersten Absatz des Artikels nochmsal.
Nicht die Programmiersprache ist unsicher, sondern der Programmierer.
Wer meint C programmieren sei Fehleranfälliger als andere Sprachen, der
kann nicht programmieren, denn er weiß nicht was er tut.
C- Programmieren wissen was sie tun. Den C ermöglicht es die Hardware
annäherend so nach und so efficient anzusprechen wie Assembler.
Alles andere (höhere9 ist anfälliger gegen fehler, weil man meist die
Libs nicht einsehen kann und sich so blind verlassen muss......
Bernd Hallinger schrieb:> C- Programmierer wissen was sie tun.
LOL...
Träum weiter.
> Alles andere (höhere9 ist anfälliger gegen fehler, weil man meist die> Libs nicht einsehen kann und sich so blind verlassen muss......
Hast du mal den Sourcecode der Microsoft-Libs angeschaut?
> Alles andere (höhere9 ist anfälliger gegen fehler, weil man meist die> Libs nicht einsehen kann und sich so blind verlassen muss......
Das ist doch überall so:
Ich setz mich ins Auto und verlass mich drauf, dass es fährt und bremst.
Ich verwende eine Lib und verlass mich drauf, dass sie tut, was in der
Doc steht.
Lothar Miller schrieb:> Bernd Hallinger schrieb:>> C- Programmierer wissen was sie tun.> LOL...> Träum weiter.
Wenn man nicht weiß was man tut kann man entweder nicht programmieren
oder probiert etwas aus.
Abgesehen davon, Bascom versteht nichts was in c nützlich ist:
1
inti;// In Bascom: "Dim i as Interger". Wie kommt auf so eine scheiß Idee???
Frank M. schrieb:> Wo gibt es in C "solche doppeldeutigen Zu- und Anweisungen"? Da ist> alles eindeutig definiert.
nein ist es nicht.
int i = 1;
printf("%d, %d",i++,i++);
Peter II schrieb:> int i = 1;> printf("%d, %d",i++,i++);
Was ist hier nicht eindeutig?
Das müsste "1, 2" ergeben.
Aber anscheinend werden die Argumente rückwärts abgearbeitet/eingelesen.
Daher "2, 1"
Das sollte aber immer gleich sein.
Wusste ich vorher nicht, aber sowas würde ich auch nicht schreiben.
Der Kommaoperator ist überhaupt eine Quelle unendlicher Freude...
Was macht die Zeile da:
1
intv,j=3;
2
for(inti=0;i++<6,j++,v=j+i;);
Nein, die Antwort darf nicht länger als 10 Sekunden dauern.
Drei schäbige arithmetische Operationen, und du überlegst immer noch?
Und was würde da herauskommen:
1
volatileintv,j=3;
2
for(inti=0;i++<6,j++,v=j+i;);
Samuel K. schrieb:> müsste> anscheinend> sollte> würde
No further comment... ;-)
Samuel K. schrieb:> Aber anscheinend werden die Argumente rückwärts abgearbeitet/eingelesen.> Daher "2, 1">> Das sollte aber immer gleich sein.
nein ist es ebend nicht, es kann sich in jeder compiler version ändern.
Weil sotwas ebend nicht festgelegt ist.
Lothar Miller schrieb:>> müsste>> anscheinend>> sollte>> würde> No further comment... ;-)
ich bin auch nicht immer sicher. Und in meinen Programme verwende ich
entweder Ausdrücke, bei denen ich sicher bin, dass sie funktionieren
oder google.
Deine Schleifen laufen übrigens ins unendliche.
Peter II schrieb:> nein ist es nicht.
Ist es doch.
> int i = 1;> printf("%d, %d",i++,i++);
Die Abarbeitungs-Reihenfolge ist definiert, nämlich dass sie inerhalb
von Argumenten unbestimmt ist. Das ist dokumentiert! Und damit ist die
Sache eindeutig: nicht machen! :-)
Samuel K. schrieb:> ich bin auch nicht immer sicher. Und in meinen Programme verwende ich> entweder Ausdrücke, bei denen ich sicher bin, dass sie funktionieren
woher kennst du die ausdrücke die 100% funktionieren? Bist du sicher das
alles wo du denkst das es 100% so ist auch wirklich so ist? Selbst bei
dem einfachen printf beispiel hast du dich schon vertan.
Lothar Miller schrieb:> Drei schäbige arithmetische Operationen, und du überlegst immer noch?
Da muss ich nicht überlegen, das Verhalten ist absolut bestimmbar, denn
jeder C-Compiler der Welt (sofern er korrekt implementiert ist) wird das
eindeutig übersetzen. Ich sehe da absolut nichts doppeldeutiges.
> Und was würde da herauskommen:>
1
>volatileintv,j=3;
2
>for(inti=0;i++<6,j++,v=j+i;);
3
>
Auch das ist eindeutig.
Du verwechselst Unzulänglichkeiten des Menschen mit der angeblichen
Unzulänglichkeit der Sprache C.
Nicht immer ist in C sofort erkennbar, was gemeint ist. Aber das ist
derjenige schuld, der das so schreibt, nicht die Sprache.
Peter II schrieb:> nein ist es ebend nicht, es kann sich in jeder compiler version ändern.> Weil sotwas ebend nicht festgelegt ist.
Und warum läßt der Compiler solche Formulierung dann überhaupt durch,
wenn das Verhalten nicht mal standardisiert ist?
Der Michel schrieb:> Und warum läßt der Compiler solche Formulierung dann überhaupt durch,> wenn das Verhalten nicht mal standardisiert ist?
Weil man dann auch keine Funktionen in Funktionen angeben könnte.
Es könnte ja so eine Funktion sein:
int i = 0;
printf("%d, %d", foo(i), foo(i));
int foo(int i)
{ return i++; }
Samuel K. schrieb:> Weil man dann auch keine Funktionen in Funktionen angeben könnte.> Es könnte ja so eine Funktion sein:>> int i = 0;> printf("%d, %d", foo(i), foo(i));>> int foo(int i)> { return i++; }
schlechtest Beispiel, weil es hier sogar eindeutig ist.
So ist es besser:
int i = 0;
printf("%d, %d", foo(i), foo(i));
int foo(int& i)
{ return i++; }
Peter II schrieb:> So ist es besser:>> int i = 0;> printf("%d, %d", foo(i), foo(i));>> int foo(int& i)> { return i++; }
Das ist nicht besser sondern schlechter, denn das versteht kein
C-Compiler, was Du da tippselst ;-)
Was soll der Operator "&" da in der Sprache C? Du verwechselst das was
mit C++ ;-)
Und was soll das Draufrumgetrete? Ich schrieb doch eben schon, dass die
Abarbeitungsfolge von Funktionsargumenten erklärtermaßen unbestimmt ist.
Damit ist es eindeutig: es ist unbestimmt. Da ist nichts doppeldeutiges.
Bring mal ein besseres Beispiel für Doppeldeutigkeit in C.
Frank M. schrieb:>> int i = 1;>> printf("%d, %d",i++,i++);>> Die Abarbeitungs-Reihenfolge ist definiert, nämlich dass sie inerhalb> von Argumenten unbestimmt ist. Das ist dokumentiert! Und damit ist die> Sache eindeutig: nicht machen! :-)
Genau, und deswegen spuckt bspw. der GCC auch eine entsprechende Warnung
aus, sofern man diese aktiviert hat:
1
warning: operation on ‘i’ may be undefined [-Wsequence-point]
Lothar Miller schrieb:> Der Kommaoperator ist überhaupt eine Quelle unendlicher Freude...> Was macht die Zeile da:int v, j=3;> for (int i=0;i++<6,j++,v=j+i;);>> Nein, die Antwort darf nicht länger als 10 Sekunden dauern.
Ich habe zugegebenermaßen etwas länger als 10 Sekunden gebraucht :)
Das lag aber nicht an dem Kommaoperator, sondern daran, dass man erst
einmal daraufkommen muss, dass v=j+i immer ungerade ist und somit trotz
Überlauf nie 0 werden kann. Dazu hätte ich in Basic genauso lange
gebraucht.
Ganz abgesehen davon ist das absichtlich verunstalteter Code. Verunstal-
ten kann kann man Programme in jeder Sprache (einschließlich Basic).
Peter II schrieb:> schlechtest Beispiel, weil es hier sogar eindeutig ist.
Warum denn? Darum ging es gar nicht. Es ging drum zu beweisen, dass man
das nicht verbieten darf.
Denn der Compiler weiß nicht ob dasselbe auch in einer Funktion gemacht
wird.
@Samuel
Man kann in Bascom statt i=i+1 auch schreiben: Incr i
Es stimmt, daß man nur 2 Terme in einer Gleichung verhackstücken kann.
Dann muß man eben seine Formel zersägen. Das hat aber den Vorteil, daß
man
sich in Ruhe die Zwischenergebnisse ansehen kann, wenn bei einer langen
Rechenoperation wirres Zeug herauskommt.
Und: Man kann die vorgefertigten Routinen z.B. für die Ansteuerung
eines Display benutzen, muß aber nicht.
Ich habe schon oft gelesen, daß es Jemandem nicht gelang, einen
Quelltext
in C bei sich auf dem Rechner übersetzen zu lassen. Nein, hieß es dann,
Du mußt die Version 0815 des Compilers benutzen, nicht die 0816...
;-)
MfG Paul
Paul Baumann schrieb:> Ich habe schon oft gelesen, daß es Jemandem nicht gelang, einen> Quelltext> in C bei sich auf dem Rechner übersetzen zu lassen. Nein, hieß es dann,> Du mußt die Version 0815 des Compilers benutzen, nicht die 0816...
Kenn ich, als ich vor ein paar Jahren ein bisschen programmieren konnte
und von VC# verwöhnt war. Lernt man aber mit der Zeit.
Zur Komplexität.
Hier eine Zeile aus meinem derzeitigen Projekt. Hat beim ersten Test
funktioniert.
Sahra Nana schrieb:> kann mir jemand einen Code von Bascom nach C übersetzen?> danke
Ich hatte ja mit sowas auch schon zu tun. Und zwar habe ich z.B. ein
paar Assemblerschnipsel, die einen kompletten DCF77-Kern darstellen, und
den ich nicht unbedingt gerne komplett neu programmieren will. Und ein
paar andere Dinge aus meiner Assemblerzeit. Er ist etwas umfangreich.
Habe den Code bisher teilweise nach C portiert, bin aber noch nicht
fertig. Denn, ich möchte den Code gerne in C universell auf allen µC
einsetzen können.
Dabei wählte ich den Zwischenschritt, aus dem Assemblercode
Struktogramme und Flußdiagramme zu bilden. Und aus diesen Diagrammen
dann den C-Code zu machen. Anders geht es wirklich sinnvoll nicht. Und
man muß da schon auch sehr konzentriert und sorgfältig arbeiten.
Und die Bildung von Struktogrammen, geht sicher auf dem Basic-Code genau
so gut wie beim Assembler.
Übrigens gewöhnte ich mir frühzeitig an, Struktogramme zu erstellen. Ich
empfand sie immer eher als hilfreich, anstatt lästig. Leider arbeitet
kaum jemand so in der Praxis.
Rene Zimmermann schrieb:> Hallo>> ohne Test und ohne Garantie, mal auf die schnelle.>> Uart ist von Peter Fleury.> Spi ist von Ulrich Radig.>> Gruß Rene
Damit hast du den TO seinem Ziel wieder ein Stück näher gebracht -
nämlich sich ein Diplom erschleichen. :-(
steffen_B schrieb:> Abgesehen davon, das man m. E. in "C" nichts anderes als Fehler> produzieren kann, war das wohl vom Poster nicht gemeint.
Du meinst mal abgesehen, dass alle professionellen / komererziellen
Entwicklungen in C stattfinden und Bascom außer bei Anfängern zu Recht
ziemlich verhasst ist ...
Mir vergeht gerade die Lust mich mit diesen renitenten Anfänger verbal
zu batteln ...
Hi
>Du meinst mal abgesehen, dass alle professionellen / komererziellen>Entwicklungen in C stattfinden und Bascom außer bei Anfängern zu Recht>ziemlich verhasst ist ...
Träumer sollten einfach weiter schlafen.
MfG Spess
Lehrmann Michael schrieb:> steffen_B schrieb:>> Abgesehen davon, das man m. E. in "C" nichts anderes als Fehler>> produzieren kann, war das wohl vom Poster nicht gemeint.>> Du meinst mal abgesehen, dass alle professionellen / komererziellen> Entwicklungen in C stattfinden und Bascom außer bei Anfängern zu Recht> ziemlich verhasst ist ...>> Mir vergeht gerade die Lust mich mit diesen renitenten Anfänger verbal> zu batteln ...
Wenn Dein Programmierstil und die Güte Deiner Quelltexte mit Deinen
Rechtschreibkenntnissen - oder dem Willen, vor dem Senden 'noch 'mal
'drüberzuschauen - korrelieren, bestätigst Du meine oben aufgestellte
These...
Daher merken wir uns:
fragwürdiger Sprachenkonstrukt + laustriger "Programmierer" = totales
Chaos und Dysfunktion!
Und bei der einen oder anderen aktuellen "kommerziellen Software",
welche wohl tatsächlich im Zustand totaler geistiger Umnachtung in "C"
oder irgendwas ähnlichem zusammengefrickelt wurde, stimmt auch diese
Formel...
Lehrmann Michael schrieb:>> Du meinst mal abgesehen, dass alle professionellen / komererziellen> Entwicklungen in C stattfinden und Bascom außer bei Anfängern zu Recht> ziemlich verhasst ist ...>> Mir vergeht gerade die Lust mich mit diesen renitenten Anfänger verbal> zu batteln ...
warum haste dann ueberhaupt die 'Klappe aufgerissen' ?
(besser dumm gelallt als garnix gesagt)
toll ist auch das Zitat aus Wiki:
'Zielsetzung sind die Vermeidung von Laufzeitfehlern durch unsichere
C-Konstrukte, von strukturellen Schwächen durch Missverständnisse
zwischen Programmierern und die Sicherstellung der Gültigkeit von
Ausdrücken.'
>Damit hast du den TO seinem Ziel wieder ein Stück näher gebracht ->nämlich sich ein Diplom erschleichen. :-(
Kann sein, wenn er den Code verwendet ist er selber schuld.
Eigentlich wollte ich nur die Programmiersprachendiskusion unterbrechen.
Ständig ohne Grund, ist echt schlimm.
Gruß Rene
Rene Zimmermann schrieb:> Eigentlich wollte ich nur die Programmiersprachendiskusion unterbrechen.> Ständig ohne Grund, ist echt schlimm.
Allerdings. Zumal in dieser Streiterei keine Spur von Sachlichkeit
vorhanden ist und deshalb von einer Diskussion eigentlich gar nicht die
Rede sein kann...
Warum ist es nicht möglich, zur Abwechslung mal eine objektive
Argumentation der Vor- und Nachteile einer Programmiersprache zu führen,
ohne gleich unsachliche Äußerungen zu üben und persönlich zu werden?
Es stimmt schon, dass die Sprache C schwer lesbare bzw.
compilerabhängige Konstrukte zulässt, aber deshalb muss C ja nicht
gleich "nichts anderes als Fehler produzieren".
Es bleibt schließlich dem Programmierer überlassen, ob er solche
fragwürdigen Konstrukte verwendet oder eben nicht.
Und dass man in C nicht nur Fehler, sondern durchaus auch sehr gut
funktionierenden und lesbaren Code produzieren kann, wurde z. B. in der
Rubrik Codesammlung hier im Forum vielfach bewiesen. Schließlich ist
dort die Mehrheit der µC-Programme, einschließlich derer von Herrn
Dannegger, in C geschrieben.
Johannes
Jürgen Hinze schrieb:> Lothar Miller schrieb:>> Ich verwende eine Lib und verlass mich drauf, dass sie tut, was in der>> Doc steht.> Wie weit man mit diesem Vertrauen kommt musste ich gerade feststellen:
Natürlich greift man da ab&an in den Topf (auch mir ist das schon ein
paar mal passiert), aber wenn du dem Compiler nicht traust, dann kannst
du gleich alles in Assembler schreiben und hinterher den Maschinencode
kontrollieren...
Man muss ganz einfach darauf vertrauen, dass die Leute, die die Libs
und den Compiler geschrieben haben, das nach bestem Wissen und gewissen
und ausreichend gut getan haben.
Bernd Hallinger schrieb:> Wer meint C programmieren sei Fehleranfälliger als andere Sprachen, der> kann nicht programmieren, denn er weiß nicht was er tut.>> C- Programmieren wissen was sie tun. Den C ermöglicht es die Hardware> annäherend so nach und so efficient anzusprechen wie Assembler.>> Alles andere (höhere9 ist anfälliger gegen fehler, weil man meist die> Libs nicht einsehen kann und sich so blind verlassen muss......
Wer sich in seiner Muttersprache nicht halbwegs unfallfrei ausdrücken
kann, dem wird das in C wohl auch eher nicht gelingen...
Thread beobachten
Seitenaufteilung abschalten