Ohne "C" bräuchten wir keine Debugger

Ohne "C" bräuchten wir keine Debugger

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.

Mit "C" muss man Probleme lösen, die es in anderen Hochsprachen garnicht gibt.

Das reicht von Integer Promoten bis zu zu gemischten Typen und und und....

Vergleich mit gemischten Datentypen funktionieren nicht.
String Verarbeitungen wurden irgendwie dazu gebastelt.
Haben teilweise eine inverse Logik.

Compiler erzeugen Code die nicht dem geforderten Ablauf entsprechen,
und auch falsche Assembler Befehle benutzen.

Ich bin wirklich derart genervt von dieser unbeschreiblich "C"haotischen Sprache,
daß ich eigentlich meinen Job als Programmierer umbenennen müste als "Experimentierer"
Soviel "Scheiss" hab ich noch nie erlebt, und ich programmiere seit ca. 30 Jahren
und habe "C" nicht ohne Grund bisher abgelehnt.

Keine Ahnung ob sich die sogenannten "C" Programmierer daran aufgeilen, mit einem
Syntax zu arbeiten der jenseits jedes normalen Menschenverstandes agiert.

Mein Fazit:

warum denn einfach wenn es auch umständlich geht.
und meiner Überschrift entsprechend:
Ohne "C" bräuchten wir keine Debugger

Siro

Achja, jetzt muss ich ja noch eine Frage stellen:

Warum tun sich Menschen das an ???????
Es gibt doch auch funktionierende Hochsprachen......

Ich hoffe, ich werde jetzt aus diesem Forum verbannt,
das wäre völlig okay.

Äh.
Geh mal ein wenig an die Sonne und mach Pause :-)
Ich programmiere auch schon seit Ewigkeiten, in dn verschiedensten Sprachen, und alle (naja, fast alle) haben ihre Vor- und Nachteile, und unter bestimmten Bedingungen ihre Daseinsberechtigung. Meine C-Programme krieg ich auch ohne Debugger meistens zum laufen, in anderen Sprachen brauch ich aber auch einen Debugger, und auf den Atmels habe ich ehnicht soo die große Auswahl. Aber man hat eine Wahl. also benutze doch einfach C nicht, und wenn Dich jemand zwingt, C zu benutzen, reg Dich lieber bei ihm auf :-) Tapfer bleiben! Ich würde Dich nicht bannen, 'nen schlechten Tag hat jeder mal.

MfG
Volker

Zitat:

---

Zitat von Siro

... Das Problem ist , ich programmiere in "C" ... rund 2 Jahren Erfahrungen ... daß in "C" NICHTS richtig funktioniert ...

---

So viel programmiere ich noch nicht in C - weil ich es hobbymässig mache und dabei lange "sonstige" Zeiten sind. Aber etwas Widerspruch und ne Frage hätt ich schon. "Frauen sind bessere Autofahrer als Männer" "Männer setzen sich besser durch als Frauen" "In C funktioniert nichts richtig". Welche Frau? Welcher Mann? Welcher Compiler?

Vermutlich stimmt Deine Aussage bis ins hinterste Winkelchen der Sprache, wenn ich mir einen Compiler bauen würde. Vermutlich stimmt Deine Aussage auch für so manche sonstigen Compiler zumindest teilweise. Ich habe ja nicht viel Programmiererfahrung. Ein paar hunderte Seiten FORTRAN (Industrieautomatisierung - recht grob gesagt) - dazu etliche Assemblerpassagen für die Interruptroutinen oder andere zeitkritische Abläufe - mit zugehörigen Dokumentationen, eine Library für einen Mathe-Coprozessor, ein paar wenige hundert Seiten LISP als Offset für AutoCAD, lächerlich wenige Dinge in Basic. Irgendwo gabs immer Unpässlichkeiten. Und ich weiß nicht, was die Fuzzies alles gemurkst hatten, die die ersten textgebundenen Adventurespielchen programmierten. In FORTRAN.

Langer Rede kurzer Sinn: Deine Aussage kann ich bestätigen - in wenigen Fällen. Eher sehr wenigen.

Und mach Dir keine Sorgen wegen der Verbannung. Ich sehe jedenfalls keinen Grund dazu.

Ach ja, oben fehlt noch ne Frage nach "Welcher Compiler?": Welcher Programmierer?

Naja um es nicht persönlich zu machen. Es ist halt nur Mittel zum Zweck. Um an den Vergleich von oberallgeier anzuknüpfen, bei einem Unfall mit Todesfolge ist in der Regel auch nicht das Auto schuld. Es ist/war einfach nur Mittel zum Zweck, also einfach nur Werkzeug. Ich finde, und da spreche ich für mich und aus meiner Erfahrung, wächst man mit den Herausforderungen.
Probleme sind zum Lösen und Herausforderungen zum Überwinden da. Wenn ich daran denke, mit welchen Problemen ich mich vor 5 Jahren beschäftigt habe und zurückblicke, muss ich meist nur Schmunzeln und erschrecke mich dann selbst, wie schwer ich mich zu der Zeit getan hab.

Dabei ist es eigentlich egal welche Sprache man benutzt. Man nutzt seinen persönlichen Erfahrungssatz und die eigene Vorstellungskraft bzw. Auffassungsgabe.

Das mit der Pause ist übrigens sehr wichtig. (Genauso wie sich Luft zu machen! )
Manchmal ist man einfach nur betriebsblind und es fehlt die gesunde Distanz. Sachen wie Dokumentationen und Analysen des eigenen Machwerks sind dabei ein leidiges Thema für sich. Wer setzt sich schon gern kritisch mit dem eigenen "Kind" auseinander ?

Zitat:

---

Zitat von Siro

Ohne "C" bräuchten wir keine Debugger

---

Du fährst ja hier ein schweres Geschütz auf. Wenn du außer für C keinen Debugger brauchst, behauptest du, daß du alle Algorithmen und Programmabläufe immer richtig formulierst, in welcher Sprache auch immer, außer in C. Ich würde daraus eigentlich den Schluß ziehen, lern C oder benutz etwas anderes.

Eigentlich müßte man wissen, welche anderen Sprache du verwendet hast

Zitat:

---

ich programmiere seit ca. 30 Jahren

---

aber einiges, daß du forderst, geht nie.

Zitat:

---

Vergleich mit gemischten Datentypen funktionieren nicht.

---

Das geht nie. Wie willst du einen Vektor z.B. eine komplexe Zahl mit einem Skalar vergleichen? Andere Sprachen können das auch nicht. Sie machen es einem möglicherweise leichter, indem sie nur einen Datentyp verwenden und z.B. immer Fließkommazahlen verwenden (auch wenn man immer nur Ganzzahlen schreibt). Aber auch da kann ich nicht Äpfel mit Birnen vergleichen. Und versuch auch da mal (ich schreibs mal als Text) ob Wurzel 2 zum Quadrat gleich 2 ist.

Zitat:

---

String Verarbeitungen wurden irgendwie dazu gebastelt.

---

Es gibt in C keine Strings. Es gibt in der C-Library einige Funktionen, mit denen man Arrays von Chars behandeln kann. Damit kann man, wenn man es denn kann, Texte bearbeiten solange ein Textzeichen nicht mehr als 8 Bit zu Codierung benötigt (was den Chinesen, die auch Internet haben, schon mal nicht reicht). Das hat aber mit C nichts zu tun. Unter Umständen benutze ich auch eine Library, die Texte anders als 0-terminierte Byte-Arrays darstellt. Das zeigt nur, wie flexibel das Konzept von C mit dem Umgang von Libraries ist.

Und jetzt kommt's dick:

Zitat:

---

Compiler erzeugen Code die nicht dem geforderten Ablauf entsprechen,
und auch falsche Assembler Befehle benutzen.

---

Ich selbst habe noch nie erlebt, daß ein C-Compiler ein Programm erzeugt hat, daß nicht exakt das gemacht hat, was ich beschrieben habe. Es soll so etwas geben, ein Compiler ist auch nur ein Programm, das Fehler haben kann, aber auch in 99,9% der Fälle in den Foren stellt sich heraus, daß der Compiler richtig funktioniert.

Wenn du erwartest, daß irgendein Compiler den von dir geforderten Ablauf erzeugt, müssen deine Anweisungen klar, eindeutig und syntaktisch richtig sein. Ein Compiler ist eben keine Sekretärin, die aus dem unverständlichen Gesabbel ihres Chefs vorzeigbare Texte erzeugt.

Und zum zweiten: ein Compiler kann keine falschen Assembler Befehle erzeugen. Wenn die erzeugten Befehle dem 'gewünschten Ablauf' entsprechen, sind sie richtig. Ansonsten erzeugt er nicht den richtigen Ablauf: siehe oben. Wenn du meinst, du kannst es besser, verwende den Compiler nicht.

Zitat:

---

Warum tun sich Menschen das an ???????
Es gibt doch auch funktionierende Hochsprachen......

---

Menschen tun sich viel an, warum tust du dir das an. Ich mag keine fritierten Heuschrecken, ich geh aber nicht in Bankog auf den Nachtmarkt und erzähle wie eklig ich das finde.

Um auf den Anfang zurück zu kommen: ich brauche auch keinen Debugger. Ich brauch auch keinen Assembler, ich kann mir den Maschinencode auch aus der Prozessorbeschreibung ablesen, die Sprungadressen ausrechnen und das Ganze Bit für Bit in den Programmspeicher bringen. Ich verwende aber selbstverständlich Debugger, Assembler und sogar C-Compiler. Ein Herr Benz hat auch das Auto erfunden und gebaut, um seine Schwiegermutter zu besuchen. Aber muß man sich das heute noch antun ????

MfG Klebwax

P.S. Mit "antun" meine das mit dem Auto bauen, nicht die Schwiegermutter

Zitat:

---

Zitat von Siro

[...]
Soviel "Scheiss" hab ich noch nie erlebt, und ich programmiere seit ca. 30 Jahren
und habe "C" nicht ohne Grund bisher abgelehnt.
[...]

---

Hoi,
es wäre interessant zu wissen mit welcher Programmiersprache Du unterwegs bist.

Noch ein netter Link zum Thema Programmiersprachen: <Echte Programmierer meiden Pascal>

Und natürlich "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: As potential programmers they are mentally mutilated beyond hope of regeneration." (Siehe <Zitate von Dijkstra>, dort gibt es auch eine Übersetzung.)
Tschö, Tore

Zitat:

---

Zitat von Siro

Soviel "Scheiss" hab ich noch nie erlebt, und ich programmiere seit ca. 30 Jahren
und habe "C" nicht ohne Grund bisher abgelehnt.

---

Klingt für mich sehr nach einer selbsterfüllenden Prophezeiung. Du fängst an in C zu programmieren mit dem Gedanken "C ist doof" im Hinterkopf, und wenn irgendwas nicht funktioniert (was ja beim Erlernen einer neuen Sprache ganz normal ist) dann ist das für dich automatisch ein inhärentes Problem der Sprache selbst. So kannst du am Ende natürlich sagen "Ich habs doch gleich gewusst".

Zitat:

---

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.

---

Ich programmiere seit 4 Jahren beruflich in C (vorher auch schon längere Zeit hobbymäßig), und bisher hat noch fast ALLES richtig funktioniert. Wenn mal etwas nicht funktioniert hat dann war das meist meine Schuld, und nur in ganz ganz wenigen Fällen war es auch mal der Compiler bzw. ein Hardwarefehler des verwendeten DSPs, von dem der Compiler nichts wusste (aber ob man da dem Compiler die Schuld geben kann?).

Zitat:

---

Compiler erzeugen Code die nicht dem geforderten Ablauf entsprechen,
und auch falsche Assembler Befehle benutzen.

---

Das habe ich so noch nie erlebt (auch bei dem oben genannten Beispiel wären die vom Compiler erzeugten Assembler Befehle richtig gewesen, wenn der Hardwarefehler nicht einen Workaround erfordert hätte).

Zitat:

---

Ohne "C" bräuchten wir keine Debugger

---

Da ist es doch ziemlich eigenartig, daß es für jede verbreitete Hochsprache auch Debugger gibt, oder?


C ist sicherlich nicht perfekt, aber das ist keine Programmiersprache.

Zitat:

---

Zitat von Klebwax

... C-Compiler ein Programm ... daß nicht exakt das gemacht hat, was ich beschrieben habe ...

---

Siehst Du, das trifft genau das, was ich mit "Welcher Programmierer" angedeutet hatte. Es war bei mir schon recht früh (FORTRAN-Einstieg vor über dreißig Jahren - mit Lochkarten *ggg*) daß ich etwas merkte, was ich von Joseph Weizenbaum kurz vor seinem Tod gehört hatte : "... Der Computer macht genau das, was man ihm sagt. Das ist nicht immer das was man meint, ihm gesagt zu haben...". Und das trifft sicher auch den Fall, dass man dem Computer etwas auf dem Umweg über einen Compiler sagt.

Das liegt nun nicht am Computer und auch nicht an den Compilern, schon garnicht an C selbst - was immer man mit C meint. Es ist unser altes Problem der Semantik (und der Logik): Wenn DU und ich in einer Unterhaltung von einem Tisch sprechen, haben wir eine ganz konkrete, allgemeine Vorstellung von "einem Tisch". Und wenn wir dieser Vorstellung auf den Grund gehen, dann werden wir vermutlich merken, dass es zwei grundverschiedene Tische sind, die wir in unserem persönlichen Sprachhintergrund stehen haben. Und für diese Tatsache kannst weder Du etwas, noch kann ich etwas dafür. Und beim Programmieren gibts ebenso keinen Schuldigen - aber weder der Compiler noch der Computer kann sich Deinem Sprachumfang anpassen. Du mußt Dich ihnen anpassen. Leider kommt zu den Sprachproblemen noch dazu dass numerische Mathematik (noch dazu im binären Kosmos) nicht immer so funktioniert wie in der alltäglichen Mathematik.

Also wetter ruhig mal Deinen Frust ab - ich glaube, das ist eine zusätzliche, befreiende Möglichkeit eines (dieses) Forums. Und wenn Du C-Quellen-Probleme hast - schreib darüber. Hier wird Dich geholfen.

Viel Erfolg bei Deiner weiteren Arbeit.

Guten Morgen,
Ich muste mir einfach mal Luft machen...
Da hab ich natürlich Diskussionen angefacht, war mir schon klar.
Ganz so schlimm mit dem "C" war das auch nicht gemeint, oder doch ?
Na egal ob ich meckere oder nicht, da muss ich halt durch.

Ich habe viele Algorithmen oder Funktionen zunächst in Delphi programmiert und ausgetestet.
Eckparameter, Wie verhält es sich mit Grenzwerten usw. Einfach weil ich hier jahrelange Erfahrung mit habe.
Dann werden sie nach C codiert und leider viel zu oft, funktioniert es dann nicht mehr.
Sicherlich durch meine "Unwissenheit" das will ich garnicht abstreiten.
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. 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 in Delphi einfach alles festgelegt. Ich suche mir also vorher schon den richtigen Datentyp aus
und Vergleiche funktionieren dann auch IMMER richtig, unabhängig vom Datentyp.
In C kommt es darauf an, was ich für einen Typ gewählt habe und dann geht es oder auch nicht.
Wenn ich dann lese, es ist Compiler abhängig oder Plattformabhängig oder Prozessorabhängig kann ich also davon ausgehen,
daß es NICHT IMMER funktioniert. Dafür möchte ich in meiner Risikoanalyse sicher nicht die Hand ins Feuer legen.
Ich kann natürlich alles vorher "casten" aber das macht die Software auch nicht grade übersichtlich.
Und genau das ist es, was ich in Delphi nicht machen muss. Es funktioniert einfach.

Das ging ja schon damit los, daß meine Firma meinte ich soll in "C" programmieren.
Ein recht dehnbarer Begriff, wie ich feststellen muste.

K&R Ansi-C Turbo-C C89 C90 C94 C95 C99 C11 C# C++ Quick-C C-- Objective-C C-Sharp ISO C99

Hab ich was vergessen ?
Egal, ich habe mich also für ANSI-C entschieden, entspricht wohl auch dem ISO C89/C90 Standard.

So, nun nochmal zwei kleien simple Beispiele:

/*----------------------------------------*/
signed short istWert;
unsigned short sollWert;
int dummy;

int main(void)
{ U32 time;

istWert = -1;
sollWert = 12;
if (istWert < sollWert)
{
dummy = 1; /* hier geht es */
}
}
/*----------------------------------------*/
signed int istWert;
unsigned int sollWert;
int dummy;

int main(void)
{ U32 time;

istWert = -1;
sollWert = 12;
if (istWert < sollWert)
{
dummy = 1; /* !!!!! hier geht es NICHT !!!!! */
}
}
/*----------------------------------------*/

oder:
x := 1 SHL 8 + 1; in Pascal kommt dabei 257 heraus
x = 1 << 8 + 1; in C kommt dabei 512 heraus.......

Problem: Präzedenztabelle, warum hat C eine andere als Delphi ???
Biegeradien von Gurken wurden genormt, Rangfolge von Operatoren nicht :-) Traurig aber wahr.

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 ?
/*----------------------------------------*/

und so hab ich ständig Probleme und bin am Suchen woher sie kommen.
Jedesmal gibt es etwas "besonderes" bei "C" was man beachten muss.

Ich wünsche Euch nun ein schönes Wochenende.

PS. Debugger brauche ich auch in anderen Sprachen, das darf man nicht so ernst nehmen.

Zitat:

---

Es gibt doch auch funktionierende Hochsprachen......

---

Von dem Gerücht hab' ich auch schon gehört :-)

Im Ernst (aber nicht aggressiv):
Der schlechte Handwerker schimpft auf's Werkzeug

(ihr habt keine Ahnung und ich will's auch nicht wiederholen, was ich meinen Computern schon alles an den Kopf geworfen habe)

"... 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 :p

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."

Zitat:

---

Zitat von Siro

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?

Zitat:

---

Zitat von Siro

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

Zitat:

---

Zitat von Siro

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.

Zitat:

---

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?

Zitat:

---

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?

Zitat:

---

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 :D)?

[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]

Zitat:

---

Zitat von derNeue

...
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 ;))

Zitat:

---

Zitat von Calis007

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

Zitat:

---

Zitat von Siro

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).

Zitat:

---

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.

Zitat:

---

Zitat von danimath

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

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

Ich bin ja nun nicht der C Guru, will aber doch auf ein paar deiner Punkte eingehen.

Zitat:

---

Zitat von Siro

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

---

Ich habe in meiner C "Lehrzeit" (schon ne Weile her) noch einen Menge mehr, als das klasische Buch von Kernighan, Ritchie und Co. gelesen. Unter anderem aus "The Elements of Programming Style" von Kernighan und Plauger habe ich viel gelernt.

Zitat:

---

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.

---

Lies mal mehr über die Syntax und Semantik von C (oder auch Programmiersprachen generell), dann wirst du erkennen, daß man manches nicht so einfach "machen" kann, ohne Mehrdeutigkeiten oder andere Probleme zu erzeugen. Eine Programmiersprache muß ähnlich gesehen werden, wie ein mathematisches System.

Zitat:

---

ich hasse zum Beispiel solche Aussagen:
Normalerweise, vermutlich, meistens. Abhängig von... Je nachdem...

---

Das kommt daher, daß der Auskunftgeber es halt nicht besser weiß. Frag jemand, der sich wirklich auskennt.

Zitat:

---

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

---

Ist ja fast so. Ein char hat immer 8 Bit. Signed oder unsigned spielt keine wirkliche Rolle, eigentlich wird damit nicht gerechnet. Was macht auch 'a' * '@` für einen Sinn? Und daß '0' gleich 0x30 ist, gilt auch nur für ASCII und nicht für EBCDIC. K&R-C funktioniert auch mit EBCDIC.

Und ein int hat 16 Bit (mindestens). Solage du im Zahlenraum von +- 32000 bleibst, spielt es doch keine Rolle, ob dein int in Wirklichkeit größer ist. Das mußt du nicht wissen.

Zitat:

---

Ein Bool (TRUE) ist alles was nicht 0 ist

---

Das ist so. Ich weiß nicht, wie du auf etwas anderes kommst.

Zitat:

---

if (irgenwas == etwas)
in Klammern setzen und warum muss die Abfrage "besonders" gleich sein, also doppelt ==

---

Wegen der Eindeutigkeit. Der Ausdruck hinter dem if kann ganz schön länglich werden und auch noch eine menge weitere Klammern enthalten.

Code:

---

if ( ( a == 3 || b = 5)  && open(file))

---

In jeder Sprache gibt es den Unterschied zwischen Zuweisung "=" und Vergleich "==". Es sind ja auch fundamental unterschiedliche Sachen. War da in Pascal nicht was mit ":="?

Zitat:

---

Oder eine einfache Abfrage
if (blabla)

---

Für den Compiler ist es egal, daß du die Abfrage einfach nennst.

Zitat:

---

Mathematisch völliger Blödsinn. Einen einzelnen Ausdruck in Klammern zu setzen.

---

Woran soll der Compiler, oder der Mensch, der den Code verstehen will erkennen, das der Ausdruck zuende ist, und die Anweisung, die er bei true ausführen soll anfängt?

Zitat:

---

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 ????

---

Ich kann das jetzt nicht nachvollziehen. Bitweise Operationen haben aber immer so ihre Probleme. Währen für den Bitoperator das oberste Bit eins wie die anderen ist, bedeutet es für Zahlen das Vorzeichen.

Das wirkliche Problem ist, das es in den meissten Sprachen zuwenig Datentypen gibt. Bitweise Operationen machen auf Zahlen im mathematischen Kontext keinen Sinn. Was soll soetwas bedeuten

Code:

---

X = ((3 * 5)/17) | (5 + 13)

---

Dies läßt sich hier sicher ausrechnen, aber ..

So ein Statusregister in einem µc passt möglicherweise ganz gut in den Speicherplatz eines Integers, hat aber mit einem int eigentlich nichts zu tun. Und es kann ganz tricky sein, irgendein Bit mit einer mathematischen Operation zu setzen, aber eigentlich ist so was nicht C, sonder Assembler in Verkleidung.

So weit erstmal

MfG Klebwax

"Also ich glaube (also bin ich) man hat sich irgendwann mal auf den Blödsinn von K&R eingelassen."

Naja, 'irgendwann' war zu einer Zeit, als es nichts besseres gab. In C konnte man schon den Unix-Kernel effizient programmieren, als Pascal noch eine umstaendliche, langsame Lehrsprache war - indiskutabel fuer die Implementierung eines Betriebssystems (P-code virtuell interpretiert? wtf? Da steht die Maschine).
Fehlentscheidung war das sicher keine. Standardisiert war C auch vor Pascal, wenn ich mich nicht irre. Dass sich Implementierungen nicht an den Standard halten, damit hatte auch Pascal (genauso wie fast jede Sprache) zu kaempfen.

"Egal wie, man muss halt die "Eigenheiten" der Sprache erlernen. Und das anscheinend immer wieder neu.
Da ist schon sehr Schade."

Wenn es nicht so waere, hiesse das ja, dass alle Sprachen gleich sind. DAS waere schade.
Schlimm ist es nur, wenn man gezwungen ist, eine Sprache zu verwenden, die fuer eine konkrete Aufgabe nicht geeignet ist..
Programmiersprachen sind Werkzeuge, je unterschiedlicher die sind, umso eher wird man was Brauchbares finden.
Klar kann man einen Nagel auch mit einem Loetkolben einschlagen, aber dann darf man nicht ueber den Loetkolben meckern.

C war in der Anfangszeit ein extrem einfacher und kleiner Compiler, imho eine Assembler-Codier Hilfe, die plattformunabhängigen Source-Code ermöglichte. Setzte nur eine Architektur mit Stack voraus, also zu der Zeit alles ausser den Mainframes wie IBM.
Merkt man deutlich, wenn man Assembler in C umschreiben will oder umgekehrt, das geht wie geschmiert.
Ansonsten: C is C is C.
Klagen fallen in die Kategorie "Das Leben ist ungerecht".
Als Amateur hat man eine mächtige Waffe: man kann es bleiben lassen.

Zitat:

---

Zitat von Klebwax

Ein char hat immer 8 Bit.

---

Nein. Es hat mindestens 8 Bit.

Zitat:

---

Zitat von sternst

Nein. Es hat mindestens 8 Bit.

---

Da gehen die Meinungen auseinander. Was auf jedenfall klar ist: sizeof(char) ist 1 und nicht >= 1. Die 1 heißt 1 Byte. Und ein Byte ist die kleinste im Speicher addressierbare (nicht unbedingt ladbare) Einheit. Und mal abgesehen von einigen Exoten mit 9 Bit pro Byte und einigen DSPs mit 16 oder 24 Bit als kleinste adressierbare Einheit kann man davon ausgehen, daß ein char 8 Bit hat. Daß ein Text in Unicode mehr als ein char pro Textzeichen braucht ist schon klar.

MfG Klebwax

Zitat:

---

sizeof(char) ist 1 und nicht >= 1

---

Richtig.

Zitat:

---

Die 1 heißt 1 Byte.

---

Auch richtig. Aber "Byte" heißt nicht automatisch "8-Bit".

Zitat:

---

Und mal abgesehen von einigen Exoten mit 9 Bit pro Byte und einigen DSPs mit 16 oder 24 Bit als kleinste adressierbare Einheit kann man davon ausgehen

---

Ah, ich verstehe, für dich sind "meistens" und "immer" einfach das Gleiche.

Wenn wir pingelig wären, was wir ja nicht sind *g*, ist "adressierbare Einheit" eine andere Baustelle.

die prinzipielle Syntax von C ist jetzt schon ~40 Jahre alt. Irgendwas in diesem Thread, was nicht schon damals diskutiert wurde ?

Hallo!


Ich erlaube mir, meinen Senf auch dazugeben zu dürfen. Ich habe ziemlich genau null Ahnung von C und bin begeisteter Bascom-Anhänger. Bei der Wahl der Programmiersprache, die ich lernen will, entschied ich mich nach langen Überlegungen immer wieder gegen C und würde auch heute noch immer kein C verwenden wollen. Mich schreckt die Syntax ab; ich finde es einfach seltsam, mit "kryptischen" Zeichen zu arbeiten (ja, die Zeichen sind nicht kryptisch, aber es kommt einem so vor). Für mich sieht Code in C irgendwie krank aus: jede Menge Strichpunkte, Doppelpunkte und andere Sonderzeichen, dafür wenig ausgeschriebene Wörter.

Natürlich gibt es auch in Bascom seltsame Dinge, aber ich fühle mich einfach mit dieser Sprache wohler.

Zitat:

---

Zitat von Thomas E.

Mich schreckt die Syntax ab; ich finde es einfach seltsam, mit "kryptischen" Zeichen zu arbeiten (ja, die Zeichen sind nicht kryptisch, aber es kommt einem so vor). Für mich sieht Code in C irgendwie krank aus: jede Menge Strichpunkte, Doppelpunkte und andere Sonderzeichen, dafür wenig ausgeschriebene Wörter.

---

Gleiches gilt bei mir für Bascom. Ist halt Geschmackssache und daher ist es auch gut, dass man eine Wahl hat. :)

Tommy ! Das ist ein C-Forum !
Bist du schon mal in einen Oberliga-Tischtennisverein gegangen und hast gesagt, "Ping-Pong" spielen kommt dir blöde vor ?
Was denkst du, was die Leute dir dort dann erzählen ? :mrgreen:

Dachte eher immer, dass es ein Bascom-Forum sei. Zu mindestens sind hier in den letzten Tagen/Wochen gefühlt mehr Threads mit Bascom-Code entstanden als mit C-Code.

Btw : Ping-Pong ist ja auch blöde ;)

Zitat:

---

Zitat von ePyx

Gleiches gilt bei mir für Bascom. Ist halt Geschmackssache und daher ist es auch gut, dass man eine Wahl hat. :)

---

Ja, das schön. Es ist wirklich gut, dass es mehrere Sprachen gibt, in denen AVRs programmiert werden können. So kann sich jeder sein Ding aussuchen.

Zitat:

---

Zitat von PicNick

Tommy ! Das ist ein C-Forum !
Bist du schon mal in einen Oberliga-Tischtennisverein gegangen und hast gesagt, "Ping-Pong" spielen kommt dir blöde vor ?
Was denkst du, was die Leute dir dort dann erzählen ? :mrgreen:

---

Mein Name ist Thomas, nicht Tommy. Ich wollte nur meine Ansichten mitteilen.
Und das mit dem Tischtennisverein wäre mal eine gute Idee.

Gut, entschuldige.

Verein: du kannst schnell laufen ?

Zitat:

---

Zitat von PicNick

Verein: du kannst schnell laufen ?

---

Nein, ich bin eine faule Sau was Sport betrifft und demzufolge ist meine Kondition komplett im Eimer, noch dazu bin ich Raucher und habe ein kleines Problem mit meinem rechten Sprunggelenk, was nach einer Bänderzerrung vor vier Jahren noch immer schmerzt wenn ich laufe.
Aber jetzt Schluss mit dem OT. ;)

Da wir nun von "C" bis zum Tischtennis und Bänderzerrung gekommen sind,
muss ich als Thread Eröffner natürlich auch noch mal was sagen.
Ich find es wirklich gut, daß hier viele Leute Ihre Anregungen und Kommentare mit reinbringen.
Und dieser "C" Verächter, wie es vermutlich für viele klingen mag, bin ich ja garnicht.
Zumindest nicht mehr, weil ich inzwischen viele Dinge verstanden habe, die mir vorher fast willkürlich erschienen.
Ich bin auch der Meinung, daß jeder mal seinen "Senf" egal ob positiv oder neagtiv ablassen soll.
Ich mag halt Pascal, andere mögen Bascon, der nächtse wieder ....
Ich habe aber heute mal mit dem Leiterplattenprogramm Eagle, vermutlich kenne das sehr viele von Euch, programmiert.
Da gibt es die ULP (User Language Programming). Also Hut ab, da hat sich Cadsoft wirklich was "gutes" einfallen lassen.
Basierend auf dem Syntax von "C" haben die eine richtig gute Programmiersprache hervorgebracht.
Strings können zum Beispiel direkt addiert werden, na bitte geht doch.
Und Datentypen sind auch eindeutig festgelegt. Wenig Datentypen, aber eindeutig.
So muss Technik, würde Saturn wohl sagen,
Ganz im Ernst, gefällt mir sehr gut.

Achja, Klebwax hat für jeden Satz von mir etwas dazu geschrieben,
ersteinmal Danke dafür. Kurz zu einem Punkt von Dir:
Woran soll der Compiler, oder der Mensch, der den Code verstehen will erkennen, das der Ausdruck zuende ist, und die Anweisung, die er bei true ausführen soll anfängt?

In Pascal brauche ich viele Klammern garnicht, der Compiler ist schlau genug, festzustellen, dass es sich um einen Boolschen Ausdruck handelt oder auch nicht.
Er benötigt nichtmal & sowie &&, da er weiss ob es sich um ein logisches oder Bitweises "AND" handelt. Das kann C nicht, da es eigentlich keine Booleans kennt.
Und wenn nur ein Wert abgefragt wird, ist auch keine Klammer nötig, weil es keine Zweideutigtkeit gibt..
Ich finde die Zuweiseung mit := einfach schöner als = und bei einer Abfrage das = anstelle eines == finde ich Übersichtlicher.
Da ist aber sicher nur eine Gewohnheit. Aber ich weis nicht wie oft es mir passierte:
if (x = 4) .... Das geht natürlich unweigerlich in die Hose bei "C" , weil es immer TRUE ist.
Thema TRUE, ich habe in verschiedenen Codes verschiedene Declarationen von FALSE und TRUE gefunden.
Nach ANSI "C" ist aber, wenn ich irre bitte verbessern:
FALSE = 0
und TRUE (!=FALSE)

x = ~y;
hier meckert der Compiler ja nur, weil er mit dem NOT das Vorzeichen ändern könnte. Das ist eigentlich auch okay.
Wenn ich aber 2 Bytes habe (unsigned char) und in Assembler denke, dann ist das natürlich für mich völliger Blödsinn,
Daß der Compiler mittels Integer Promotion den Wert in ein Vorzeichengerechtes Format ändert und dann darauf hinweist,
das hier etwas schief gehen könnte, okay nun weis ich das auch.

Klebwax meint:
Ein char hat immer 8 Bit. Signed oder unsigned spielt keine wirkliche Rolle, eigentlich wird damit nicht gerechnet.

Naja, das kann man sehen wie man will. Ich finde ein "negatives Ascii-Zeichen" schon sehr gewöhnungsbedürftig....
Weil ein char für mich bisher immer mit Asciizeichen bzw. Buchstaben in Verbindung stand. Wenn das nicht gemeint ist,
sollte man doch ein Byte benutzen, aber das gibt es ja garnicht in C.
War das Byte nicht mal die Grundlage ????????

Machte Euch keinen Kopf, es ist fast Wochenende, genießt es, die nächsten Probleme kommen bestimmt.
Siro