-         
Seite 2 von 4 ErsteErste 1234 LetzteLetzte
Ergebnis 11 bis 20 von 35

Thema: Ohne "C" bräuchten wir keine Debugger

  1. #11
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    02.06.2011
    Beiträge
    158
    Anzeige

    "... Der Computer macht genau das, was man ihm sagt. Das ist nicht immer das was man meint, ihm gesagt zu haben..."
    Da kann man anknuepfen.
    C macht es einem leicht, sich missverstaendlich auszudruecken. Ich glaub, das kann hier jeder unterschreiben, oder?

    "Biegeradien von Gurken wurden genormt, Rangfolge von Operatoren nicht- Traurig aber wahr."
    Gut so. Viele Sprachkonzepte waeren gar nicht moeglich, wenn die Reihenfolge genormt waere. Stackbasierter Sprachen beispielsweise. Oder das geniale (verrueckte?) APL, ausgewertet wird strikt von rechts nach links - leicht zu merken, widerspricht aber leider den mathematischen Konventionen. Aber zu Deiner Beruhigung: Ich kenn (ausserhalb der stackbasierten) keine Sprache, in der Du keine Klammern setzen darfst. Und die sind defakto genormt und entsprechen auch der mathematischen Konvention

    Und was true und false angeht, das hat sogar jemand hier in der Sig. ('/'/'/') und ('-'-'-') (Scherz. Konkret wuerde sogar ich das fuer die jeweilige C-Version nachlesen, wenn ich sichergehen will, ob -23.7 true ist oder nicht; schlechter Programmierstil waere es auf jeden Fall und wie schon das Beispiel von oben mit Wurzel 2 zum Quadrat minus 2 zeigt, auch recht unsicher - womit wir wieder bei meinem Statement angelangt sind: C macht es einem leicht, sich missverstaendlich auszudruecken.

    In C hat man eben Freiheiten, die man in anderen Sprachen nicht hat.
    Ich bin dagegen, Freiheiten aufzugeben, nur weil sonst Fehler passieren koennen.
    Ich mag keine Schilder, auf denen steht: "Bei Glatteis Betreten verboten."
    Ich bevorzuge: "Bei Glatteis Betreten auf eigene Gefahr."
    Geändert von Calis007 (09.03.2012 um 11:07 Uhr)

  2. #12
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.802
    Zitat Zitat von Siro Beitrag anzeigen
    Ich habe die ehrenvolle Aufgabe meine Software zu Dokumentieren
    und eine Risiko-Analyse zu erstellen.

    *Das Problem ist, ich programmiere in "C" und nach rund 2 Jahren Erfahrungen in "C" kann ich eigentlich nur beschreiben, daß in C NICHTS richtig funktioniert.

    *Die Risikoanalyse fällt also recht einfach aus.
    Das Problem ist nicht die Sprache, sondern der Entwickler, der sie nicht richtig beherrscht und nach Intuition programmiert anstatt sich in die Sprache einzuarbeiten.

    Das zu bewertende Risiko ist also der Entwickler, nicht die Sprache.

    Und falls tatsächlich "in C nichts funktioniert", besorg dir einen ordentlichen Compiler, nicht eine Krücke mit 1000 Fehlern.

    @admin: Warum werden im Zitat Sternchen eingefügt?
    Disclaimer: none. Sue me.

  3. #13
    Erfahrener Benutzer Fleißiges Mitglied Avatar von derNeue
    Registriert seit
    01.01.2011
    Ort
    Bierstadt Radeberg
    Alter
    35
    Beiträge
    101
    Zitat Zitat von Siro Beitrag anzeigen

    Problem: Präzedenztabelle, warum hat C eine andere als Delphi ???
    Biegeradien von Gurken wurden genormt, Rangfolge von Operatoren nicht Traurig aber wahr.
    nun, hier fragt man sich, was war denn eher da, C ist nunmal deutlich älter als Delphi, und auch der Vorgänger von Delphi, Pascal ist nicht so alt wie C. Außerdem ist C noch eine Hochsprache, die trotzdem noch recht hardwarenah ist, deswegen wird sie ja auch gern bei µC eingesetzt, da dort die Resourcen begrenzt sind. Auch Treiber werden teilweise in C programmiert.
    Ich finde, man kann verschiedene Programmiersprachen schlecht miteinander vergleichen, weil hinter jeder Sprache eine andere Idee steht. C wurde von den beiden Amerikanern erfunden, weil es keine vernünftige höhere Sprache als Assembler gab, und sie es leid waren, immer wiederkehrende Befehlsreihenfolgen einzutippen. Auch Arithmetik ist in Assembler ja eine mittlere Katastrophe. Dafür wurde C entwickelt, und das kam immerhin 1972 das erste mal auf den Markt und war auch nur für die paar wenigen gedacht, die überhaupt schon regelmäßig mit Computern zu tun hatten. Delphi entstand aus Pascal und da lag sicher auch der Komfort mit im Vordergrund, somit musst du dir nicht immer Gedanken über Variablen machen, ob sie nun Vorzeichenbehaftet sind, oder nicht, Fleißkomma, oder nicht, usw. Bei C muss man da selbst überlegen, und jeder µC Programierer ist sehr glücklich darüber, das man auch "einfache" Datentypen wie int hat, weil wenn alles Fließkommazahlen wären, würde der Controller beizeiten Amok laufen, weil er es einfach nicht mehr verarbeiten kann.

    Was ich jetzt nicht ganz verstehe, warum du in deiner Firma unbedingt C nehmen sollst. Ich habe jetzt beruflich gar nix mit Programmieren zu tun, bei mir auch alles nur Hobby, aber ich denke, das bei der Leistung, die heute Rechner haben es nicht mehr nötig ist, in C zu programmieren, weil es eben auch andere Hochsprachen gibt, mit besserem Komfort, und man auch nicht mehr so extrem Resourcensparend programmieren muss. Klar sollte man trotzdem darauf achten, das es nicht unendlich Rechenleistung gibt, weil nix ist schlimmer, als wenn ein Programm den ganzen Rechner langsam macht, und ewig braucht, bis es gestartet ist, aber ich denke, das es auch in anderen Hochsprachen außer C möglich ist, solche Programme zu schreiben.

    MfG Dennis
    Ich studiere die Wirkung der Sonnenstrahlen auf das Liebesleben der Pflastersteine

  4. #14
    Benutzer Stammmitglied
    Registriert seit
    26.08.2006
    Beiträge
    84
    Zitat Zitat von Siro Beitrag anzeigen
    Ich habe viele Algorithmen oder Funktionen zunächst in Delphi programmiert und ausgetestet.
    Eckparameter, Wie verhält es sich mit Grenzwerten usw...

    Irgendwie bekomme ich es dann auch in C hin, aber meist treten da Probleme auf, um die ich mich in Delphi
    garnicht kümmern muss.
    So läuft das nich.
    Denken in C, schreiben in C, testen in C, läuft.
    In C kommt es darauf an, was ich für einen Typ gewählt habe und dann geht es oder auch nicht.
    Und das ist bei <4kb RAM auch gut so
    So nebenbei: Magst du Pointer?
    x := 1 SHL 8 + 1; in Pascal kommt dabei 257 heraus
    x = 1 << 8 + 1; in C kommt dabei 512 heraus.......
    Hm, 0x01 << 8 wird zu 0x100, +1 sollte dann schon 512 werden.
    Was tut Pascal dann bloss bei 1 SHL 1?
    Apropos wahr, da fällt mir doch gleich der Typ Boolen ein, den es in C nicht gibt.

    Auch hier habe ich immer wieder unterschiedliche Varianten gefunden, was die Declaration von TRUE und FALSE betrifft.
    ist TRUE jetzt 1 oder !=0 oder !=FALSE ?
    Nimm uint8_t x (ein byte). Ein if(x) is true falls x>0.
    Simple as shit
    Oder if (x & 0x01) (ein bit), nur true wenn Bit gesetzt.

    Ist aber alles evtl. Geschmacksache und aus welcher Richtung man wohl so kommt.
    Auf nem größeren Gerät tät ich mir das auch nicht antun, aber auf nem Controller für € 2,00 mit 512 byte RAM und evtl. noch 1MHz macht das so schon Sinn.
    Auf so einem Gerät würde ich mich nicht mit Pascal ärgern tun wollen

    PS: könnte man in Pascal eine ISR wirklich vollständig durch inline Assembler ersetzen? Inkl. RETI (oder auch ohne )?
    Geändert von Slein (09.03.2012 um 20:11 Uhr)

  5. #15
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    58
    Beiträge
    5.799
    Blog-Einträge
    8
    [Offtopic]
    Ich bin zwar kein Admin, aber vermutlich liegt das Problem bei deinem Browser:
    https://www.roboternetz.de/community...n-Was-soll-das

    Gruß

    mic

    [/Offtopic]

    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  6. #16
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    04.08.2011
    Ort
    Hannover
    Beiträge
    164
    Zitat Zitat von derNeue Beitrag anzeigen
    ...
    Was ich jetzt nicht ganz verstehe, warum du in deiner Firma unbedingt C nehmen sollst. Ich habe jetzt beruflich gar nix mit Programmieren zu tun, bei mir auch alles nur Hobby, aber ich denke, das bei der Leistung, die heute Rechner haben es nicht mehr nötig ist, in C zu programmieren, weil es eben auch andere Hochsprachen gibt, mit besserem Komfort, und man auch nicht mehr so extrem Resourcensparend programmieren muss. Klar sollte man trotzdem darauf achten, das es nicht unendlich Rechenleistung gibt, weil nix ist schlimmer, als wenn ein Programm den ganzen Rechner langsam macht, und ewig braucht, bis es gestartet ist, aber ich denke, das es auch in anderen Hochsprachen außer C möglich ist, solche Programme zu schreiben.
    ...
    Sowas hat meist "historische Gründe". I.A.gibt es schon Programme, Bibliotheken, ... die in C (oder auch anderen Sprachen - FORTRAN und COBOL sind auch immer noch verbreitet) geschrieben sind. Diese ganzen Sachen auf etwas anderes zu heben kostet Geld und Zeit. Wenn man das nicht gleichzeitig mit wesentlichen Neuerungen verkaufen kann, dann bleibt das eben aus.

    viele Grüße
    Andreas (der seit Jahren kein Problem mit C hat )
    #define true ('/'/'/')
    #define false ('-'-'-')

  7. #17
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    07.03.2011
    Beiträge
    1.899
    Zitat Zitat von Calis007 Beitrag anzeigen
    In C hat man eben Freiheiten, die man in anderen Sprachen nicht hat.
    Ich bin dagegen, Freiheiten aufzugeben, nur weil sonst Fehler passieren koennen.
    Ich mag keine Schilder, auf denen steht: "Bei Glatteis Betreten verboten."
    Ich bevorzuge: "Bei Glatteis Betreten auf eigene Gefahr."
    Full Ack

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  8. #18
    Erfahrener Benutzer Robotik Einstein Avatar von Felix G
    Registriert seit
    29.06.2004
    Ort
    49°32'N 8°40'E
    Alter
    38
    Beiträge
    1.780
    Zitat Zitat von Siro Beitrag anzeigen
    Dann nervt mich auch dieser Datentyp int, weil nirgens festgeschrieben ist, was das eigentlich ist.
    Hat der ein Vorzeichen oder Nicht, wieviele Bits hat er denn überhaupt...
    Das ist tatsächlich etwas unschön, aber glücklicherweise schafft die Standardbibliothek hier Abhilfe: stdint.h gibt dir genau das was du suchst, nämlich Integer mit genau definierter Länge. Bei einem uint8_t z.B. kannst du dir sicher sein, daß der Datentyp 8 Bit breit ist und kein Vorzeichen hat (und zwar Compiler- und Plattformunabhängig).

    Apropos wahr, da fällt mir doch gleich der Typ Boolen ein, den es in C nicht gibt.
    Auch hier habe ich immer wieder unterschiedliche Varianten gefunden, was die Declaration von TRUE und FALSE betrifft.
    ist TRUE jetzt 1 oder !=0 oder !=FALSE ?
    Auch hier möchte ich auf die Standardbibliothek verweisen: stdbool.h definiert true und false. Bei true sollte man allerdings beachten daß in C grundsätzlich alles true ist was nicht 0 ist. Daher sollte man z.B. niemals auf Gleichheit mit true prüfen, sondern immer auf != false.


    PS: was den C-Standard betrifft ist C99 die Variante (Standard ISO/IEC 9899), die ich eigentlich jedem empfehlen würde (ist in einigen Punkten besser/intuitiver als das ältere C90). C++, C#, Objective C ist alles kein C, das sind Sprachen die auf C aufbauen.

    Theoretisch gäbe es auch schon C11 (ISO/IEC 9899:2011) mit nochmal einigen Verbesserungen/Erweiterungen gegenüber C99, aber da weiss ich nicht wie es mit der Compilerunterstützung aktuell ausschaut.
    So viele Treppen und so wenig Zeit!

  9. #19
    Erfahrener Benutzer Fleißiges Mitglied Avatar von derNeue
    Registriert seit
    01.01.2011
    Ort
    Bierstadt Radeberg
    Alter
    35
    Beiträge
    101
    Zitat Zitat von danimath Beitrag anzeigen
    Sowas hat meist "historische Gründe". I.A.gibt es schon Programme, Bibliotheken, ... die in C (oder auch anderen Sprachen - FORTRAN und COBOL sind auch immer noch verbreitet) geschrieben sind. Diese ganzen Sachen auf etwas anderes zu heben kostet Geld und Zeit. Wenn man das nicht gleichzeitig mit wesentlichen Neuerungen verkaufen kann, dann bleibt das eben aus.

    viele Grüße
    Andreas (der seit Jahren kein Problem mit C hat )
    Mh, das klingt natürlich logisch, und das wusste ich nicht, bin eben bloß ein kleiner Hobbyprogrammierer, der gerade die ersten Schritte in C hinter sich hat


    MfG Dennis
    Ich studiere die Wirkung der Sonnenstrahlen auf das Liebesleben der Pflastersteine

  10. #20
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Beiträge
    1.076
    Also ich glaube (also bin ich) man hat sich irgendwann mal auf den Blödsinn von K&R eingelassen.
    daß dies eine Fehlentscheidung war, hat man erst viel zu spät bemerkt und nun muss das natürlich gerechtfertigt werden.
    Also wird Gott und die Welt behaupten, das "C" gut ist.
    Ich wüste jetzt nicht annähernd, was es in Pascal nicht gab oder gibt was man in C angeblich Hardwarenäher hätte programmieren können.
    Ebenso in PLM80, das war auch eine "frühe" Sprache, die ich absolut super fand.
    Ich weis aber vieles, was ohne Umwege in Pascal funktioniert, was man dem "C" erstmal mühsam beibringen muss.
    Ich will ja auch garnicht darüber entscheiden welche Hochsprache nun gut oder schlecht ist, aber C liegt bei mir jenseits jeder Vernunft.
    Das ist jetzt aber kein Angriff, sondern meine völlig private Meinung.
    Wie schon gesagt, es ist ja nicht alles schlecht in "C". Man hätte meiner Meinung nach frühzeitig einige Änderungen vollziehen müssen,
    das wurde irgendwie versäumt und nun muss man sich halt mit den teilweisen merkwürdigen Gegebenheiten rumschlagen.

    ich hasse zum Beispiel solche Aussagen:
    Normalerweise, vermutlich, meistens. Abhängig von... Je nachdem...
    Das ist für mich Chaos Programmierung.
    Und ich find es sehr Schade, daß leider kaum etwas genormt wurde.
    Hätte man nicht mal sagen können ein Byte hat generell 8 Bit ein Word hat 16 Bit, ein int hat immer ein Vorzeichen und hat 16 Bit
    Ein Bool (TRUE) ist alles was nicht 0 ist. Das wär doch eindeutig gewesen, und andere Sprachen haben diese Festlegung.
    Aber nicht nur "C" schafft diese Verwirrungen:
    Ein Word in Pascal war immer 16 Bit,
    nachdem ich mich mit den Cortex M3 Controllern vergnüge ist ein Word plötzlich 32 Bit. Das führt unweigerlich zu Verwirrungen.
    Hätte man doch Doubleword lassen können. Also nicht nur "C" ist nicht eindeutig.


    warum muss ich beispielsweise
    if (irgenwas == etwas)
    in Klammern setzen und warum muss die Abfrage "besonders" gleich sein, also doppelt ==
    Oder eine einfache Abfrage
    if (blabla)
    warum muss ich "blabla" im Klammern setzen ?
    Mathematisch völliger Blödsinn. Einen einzelnen Ausdruck in Klammern zu setzen.
    Das macht den Code (meiner Meinung nach) nur unnötig unübersichtlich.

    warum muss ich was "casten" wenn ich mit 2 gleichen Datentypen arbeite ?

    x = ~y;

    geht nur wenn x und y ein "int" sind, sonst werd ich angemeckert.
    wenn beide ein unsigned short sind, hat der Compiler Probleme ????

    Egal wie, man muss halt die "Eigenheiten" der Sprache erlernen. Und das anscheinend immer wieder neu.
    Da ist schon sehr Schade. Aber sonst bräuchten wir das Forum hier ja auch nicht
    Ich wünsche allen einen Bugfreien Start in die neue Woche.
    Siro

Seite 2 von 4 ErsteErste 1234 LetzteLetzte

Ähnliche Themen

  1. Antworten: 13
    Letzter Beitrag: 27.01.2009, 12:50
  2. Schnelle Ansteuerung für 4 Servos ohne "Servo"-Bef
    Von Willa im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 3
    Letzter Beitrag: 02.10.2008, 19:36
  3. CAN Problem, empfange keine "valid messages"
    Von T.J. im Forum PIC Controller
    Antworten: 0
    Letzter Beitrag: 09.12.2007, 13:58
  4. Doppelseitige Platine "durchlöten" ohne Nieten
    Von franzlst im Forum Elektronik
    Antworten: 12
    Letzter Beitrag: 28.09.2007, 17:52
  5. Antworten: 10
    Letzter Beitrag: 22.03.2007, 13:03

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •