Ohne "C" bräuchten wir keine Debugger

[Siro]

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.

[vklaffehn]

Ä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

[oberallgeier]

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

[ePyx]

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 ?

[Klebwax]

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

ich programmiere seit ca. 30 Jahren

aber einiges, daß du forderst, geht nie.

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.

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:

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.

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

[crissa]

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

[Felix G]

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

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

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

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.

[oberallgeier]

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

[Siro]

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.

[PicNick]

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)