Nanosekunden aus Megahertzen

Ist doch interessant. :)

Naja, damals war LISP der Guru... :) ...und Rekursivität wurde als allein-seeligmachend angesehen.

genauso, wie es heutzutrage oftmals als neben-der-Kappe gilt, und man in ähnlicher Zwanghaftigkeit alles zum Objekt machen will. IMHO genauso unsinnig, nur anders ;-)

Was den Stackspace angeht übersiehst Du da aber was... :)

Rekursivität muss nicht unbedingt Speicherfresser sein.

Wenn man die Probleme so umformuliert, daß sie tail-recursive sind, dann hat man konstanten Speicherhunger. :)

Und manche Probleme lassen sich eben rekursiv viel eleganter formulieren. Dann noch ein bischen Hirnschmalz, um es tail-rec zu machen und man fährt damit ausgezeichnet gut. :)

Gruß, Oliver

Axel Schwenke wrote: [...]

[...]

Dies gilt aber keinesfalls so global, wie es dort zu lesen ist. Dasmag für den Frontalunterricht sicherlich eine brauchbare Erkenntnis sein; aber eben nur für diesen.

Andere Unterrichtsmodelle sind durch unterschiedliche Lernstände sogar wesentlichimVorteil (und bieten auch ansonsten noch weitere Vorteile).

Aber da die Unis Institutionen aus dem Mittelalter sind....

Gruß, Oliver

[...]

Wie so vieles, würde ich vermuten, daß auch MAX_PATH und _MAX_PATH nichtvon Microsoft ins Leben gerufen wurde.

Falls Du einen Link zu bieten hast, der das belegt, was Du sagst, bitte schön. Allerdings sind Unix-Systeme schon vor Windows existent gewesen, die cmommand.com war eine abgespeckte Unix-Shell und ich gehe davon aus, daß auch alles rund um MAX_PATH von den Unixern abgeguckt wurde.

Ebenso, wie Windows auch ein schlechter Nachbau war.... Mac war damalsschon besser,und entwickelt wurden die Windowsing-Systeme bei Xerox.

Ciao, Oliver

Wenn man unter Lesbarkeit auch Lesbarkeit versteht, und mehr als 500 Jahre Buchdruck und die Erfahrungen damit nicht ignoriert und demnach auch z.B. D.E.K.'s Argumentation versteht, dann weiss man, daß Du Unsinn geschrieben hast.

Ciao, Oliver

P.S.:WiesofügstDuinDeineMailseigentlichLeerzeichenein?WillstDuetwadieLesbarkeitverschlechtern?! mankönnteauchnochdieunsinnigegrossundkleinschreibungherausnehmenundausserdemdieunnötigepunktuationdannwürdeallesnochvielbesserlesbarseinnichtwahr

|> OCaml? Geil. |> |> Woist das? An ner Uni? FH? |> Sach mal an.

TU München.

|> OCaml ist IMHO die allergeilste Sprache, die mir bisher untergekommen |> ist. Finde ich interessant, wenn sich das an Unis/FHs nun endlich mal |> auch einfindet... :)

Was man so hört, waren die Studenten davon ...hm... etwas erschreckt ;-) Inbesondere wohl die, die schon C oder Java konnten...

|> Scheme und GUI? |> Nette Sache; habe ich noch nicht probiert; angeblich soll ja selbst die |> XLib bereits ein scheme-Binding haben;mehr als dass dem so sei ist mir |> dies aber nicht begegnet:woman hinguckt, immer C.

Das war vor ca. 12 oder 13 Jahren. scm mit Motif-Bindings. Da war ein Riesendialog mit ein paar Zeilen hingeschlenzt. Ok, die Klammern waren recht viel.

|> ....ja, und wenn ihm die Viel-Programmierer auch nicht recht sind, |> sollte es einem aber zu denken geben?! ;-) |> Manche Profs sind ja sehr auf nur eine Sprache fixiert...

Der Satz wurde vor 16 Jahren gesagt. Da war C noch nicht ganz so verbreitet. Pascal und und insb. Basic wesentlich mehr. Und wenn natürlich nur Standard-Basic kann (ohne jegliche hübsche Erweiterungen wie in QL/GFA/Omikron-Basic), dann braucht es schon einiges an Gehirnwäsche, damit man den Müll wieder rausbekommt.

--
         Georg Acher, acher@in.tum.de
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias

JFTR: Ich würde höchstwahrscheinlich if (src) for (int i = 0; i < len-1 && src[i] != 0; ++i) dest[i] = src[i]; schreiben ('src' hat in der Schleifenbedingung nix zu suchen).

P.S.:WiesofügstDuinDeineMailseigentlichLeerzeichenein?WillstDuetwadieLesbarkeitverschlechtern?!

Buchdruck mit Programmiersprachen zu vergleichen ist schon etwas gewagt. Aber auch beim Buchdruck lässt man Leerraum, um "semantische Gruppen" zu trennen. In der Horizontalen sind das Worte, in der Vertikalen Absätze.

Programmiersprachen sind ansonsten eher mit Mathematik zu vergleichen. Und gerade da hat ebenjener D.E.K. viel Mühe investiert, den Leerraum korrekt und ansehnlich zu verteilen.

Stefan

In article , Stefan Reuther writes: |> JFTR: Ich würde höchstwahrscheinlich |> if (src) |> for (int i = 0; i < len-1 && src[i] != 0; ++i) |> dest[i] = src[i]; |> schreiben ('src' hat in der Schleifenbedingung nix zu suchen).

Richtig, aber das stand ja hier erst mal nicht zur Debatte. Karlheinz meinte ja, die Lesbarkeit würde sich durch die Einführung vieler Leerzeichen massiv erhöhen.

|> > Wenn man unter Lesbarkeit auch Lesbarkeit versteht, und mehr als 500 |> > Jahre Buchdruck und die Erfahrungen damit nicht ignoriert und demnach |> > auch z.B. D.E.K.'s Argumentation versteht, dann weiss man, daß Du Unsinn |> > geschrieben hast. |> > |> >

P.S.:WiesofügstDuinDeineMailseigentlichLeerzeichenein?WillstDuetwadieLesbarkeitverschlechtern?!

@Oliver: Schon mal an einen Job als Haarespalter gedacht? Oder stehst Du einfach nur auf provokante Aussagen, selbst wenn sei am Thema vorbei gehen?

Die Art, wie Karlheinz Leerzeichen eingefügt hat, w ä r e u n g e f ä h r h i e r m i t zu vergleichen. Gegenüber der originären Schreibweise "wäreungefährhiermit" ist da nun wirklich nichts gewonnen.

Die Spaces an richtiger Stelle -- so wie Stefan das ja schon ausgeführt hat -- hingegen erhöhen die Lesbarkeit in der Tat ungemein. Aber nur dann.

Rainer

[SNIP]

Whitespace ist wichtig! (Wo käm denn sonst die Farbe hin...) ;-)

Tja... Meine Variante ist kürzer und noch besser zu lesen:

if(src) while(*dest++ = *src++);

Wem sie nicht genehm ist, der sollte die Programmiersprache wechseln ;-)

--
Johannes
You can have it:
Quick, Accurate, Inexpensive.
Pick two.

Darf ich den Spruch klauen? :-D

--
Johannes
You can have it:
Quick, Accurate, Inexpensive.
Pick two.

Programmiersprachen sollten allerdings in der Praxis an einem Punkt nicht mit Mathematik verglichen werden:

Bei der _Kommentierung_.

Einige Buchautoren haben nämlich eine wahre Kunst darin entwickelt, bestenfalls ein "offensichtlich ist" vor eine Formel zu schreiben, die sich erst nach zehn undokumentierten Schritten aus einer anderen Formel drei Seiten vorher ergibt, um dann sofort in dem Stil die nächste Formel folgen zu lassen. Selbstredend mit "das sieht doch jeder, dass der Index durchlaufen soll und der nicht" Spezialkonvention.

Über das "warum" in der Mathe-Ecke kann man streiten, ob Faulheit oder Ethos, bei den Programmierern kommt häufig noch hinzu, dass Zeitnot herrscht, aber auch, dass der eine oder andere sich schlicht unentbehrlich machen will.

Tatsache ist, dass Programme ohne Kommentare, wenn es um komplexe Sachverhalte geht, durch Dritte bestenfalls extrem schwer zu verstehen sind und bei Änderungen sich so gerne Fehler einschleichen. Und zwar nicht nur durch Dritte, sondern auch, weil man als Autor selber kurze fünf Jahre später vergessen haben kann, warum dieses Detail genau so und nicht anders gelöst wurde. Und schon tappt man wieder in die selbe Falle wie vor fünf Jahren.

_Das_ ist viel wichtiger, als die Diskussion um Leerzeichen hier oder da oder dort. Ich habe daher für unsere Software folgende Richtlinien bzgl. Kommentaren vorgegeben:

- Im Kopf _jeder_ Funktion steht, was sie macht bzw. wozu sie gut ist.

- _Jede_ Variable ist _ausnahmslos_ kommentiert, auch bei einem (i) steht "loop control variable" daneben. Damit gibt es erst garkeine Diskussion, ob nun auch jene Variable kommentiert sein sollte.

- Jedes Element einer Klasse oder Struktur ist zusätzlich beschrieben.

- _Jeder_ Übergabeparameter einer Funktion ist ebenso beschrieben.

- Ungefähr alle drei Zeilen sollte im Mittel im Programmcode steht ein Kommentar.

- An kritischen "we did it this non-obvious way, because" Ecken steht klipp und klar drin, warum und weshalb.

- Alle Kommentare sind in Englisch erstellt, da wir internationale Kundschaft haben und dies nunmal die Sprache der Wissenschaft und Technik ist.

- No discussions, period.

Ich meine, dass uns der Erfolg und insbesondere die hohe Stabilität der Software Recht gibt, auch wenn es etwas mehr Mühe bedeutet. Bei EDA ist ein "Absturz" sehr ärgerlich, bei IP-Routing (dieses Posting läuft über Backbone-Router, deren BGP & Co bei uns entwickelt wurde) mehr als das, da kann es ungute Konsequenzen haben. Bei Steuerungen braucht man über das Schadenspotential schlechter Software wohl kaum diskutieren.

Gruß Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10

"John F" schrieb im Newsbeitrag news:459f085c$0$12642$ snipped-for-privacy@tunews.univie.ac.at...

Warum nicht strcpy(dest,src); ?

Ganz einfach, weil es falsch bzw. an dieser Stelle unbrauchbar waere. len soll schon beachtet werden, i will man hinterher wissen, die NUL braucht nicht kopiert werden, es kommt eh noch eine dran.

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Hi Oliver!

Wirklich schön geschriebn. Das eröffnet völlig neue Blickwinkel...

ja selbst die CPU's selbst, vertan sich (s. Pentium Bug....).

Mit freundlichen Grüßen,

Daniel Mandic

Weil's so sicher ist, was passiert, wenn die beiden Speicherbereiche sich überlappen. strcpy hat da "undefined behavior".

Das steht aber nicht in Kommentaren dabei :-) Sonst wärs klar. Siehe parallele Diskussion.

Kommentare haben also doch Sinn. (Und ja: Hier würd ich sogar sagen, sie "machen" Sinn :-)

--
Johannes
You can have it:
Quick, Accurate, Inexpensive.
Pick two.

"John F" schrieb im Newsbeitrag news:45a038ea$0$11610$ snipped-for-privacy@tunews.univie.ac.at...

Was kann ich dafuer, wenn Karlheinz die Zeile aus dem Kontext reisst? Der Kontext haette die Randbedingungen vorgegeben.

--
Manfred Winterhoff

Danke fuer die Nachsicht, grosser Software-Guru.

Wir verteilen unsere Software-Updates ueber unseren Internet-Server. Wenn beim Kunden da etwas verloren geht, laedt er sich's nochmal herunter und gut iss. Wo ist das Problem?

Ich habe das Gefuehl, dass Du erhebliche Probleme hast, meinen Aus- fuehrungen zu folgen. Ich bezog mich nicht auf Dein Basic-Zeugs, sondern auf die exzessive Verwendung globaler Variablen in HelpDeco.C.

Also nochmal: Du stellst das Programm auf Deiner Site als Lehrstueck, nicht nur fuer Anfaenger, dar, und zwar im Jahr 2006. Und dann benutzt Du da einen Programmierstil, der nicht mal im Entferntesten die Moeglichkeiten eines ANSI C von vor 20 Jahren nutzt, sondern aussieht, wie ein adap- tiertes GW Basic Programm von vor 25 Jahren. DAS werfe ich Dir vor.

Wo bitte soll da ein Fehler sein? Hast Du Dich ueberhaupt einmal ernsthaft mit der Definition der Sprache C beschaeftigt?

Kritik _kann_ nie objektiv sein.

Es kommt auf den Geltungsbereich einer Variablen an. In der for-Schleife weiter oben (die aus 2 Zeilen besteht), wuerde ich durchaus Varablen wie "i, j, k" etc. benutzen, aber sobald die Schleife mehr als ca. 20 Zeilen enthaelt, kommt da ein Name, der mich nicht dauernd hin und herblaettern laesst, fuer was sie denn nun steht. Wirklich essentiell wird das, wenn es sich z.B. um verschachtelte Schleifen handelt; da ist 'Row' und 'Col' einfach logischer als 'i' und 'j', vor Allem in der 157. Zeile der inneren Schleife, wo man nicht mehr sicher weiss, ob die aeussere Schleife jetzt die Zeile oder die Spalte war.

Offensichtlich war das dann wohl das einzige Programm, welches Du in C geschrieben hast. Haettest Du das gleich geschrieben, haetten wir uns viel Zeit ersparen koennen.

Falls jedoch nicht: hast Du in den anderen Programmen nie mehr bei Benutzung von malloc() realloc() auf NULL Pointer getestet, oder hast Du die Funktionen my_malloc() und my_realloc() jedes mal auf's Neue implementiert? Im letzteren Fall: Deine Zeit moechte ich haben; im Ersteren: Fahr zum naechsten Zoo und wirf Dich den Krokodilen zum Frass vor, Du bist es nicht Wert, weiter die Resourcen dieser Welt zu verbrauchen.

Es gibt so viel funktionierende Software als Open Source, warum haette ich mir illegalerweise den Source von fehlerhafter Software als Lehr- stueck herunterladen sollen?

War das jetzt als Brueller gedacht, damit das lesende Volk mal wieder was zum Lachen hat? Beim Debuggen in VC laeufst Du maximal in die Sources der VC Runtime, das sind _NICHT_ die Sources des _KERNELS_! So ernsthaft hast _DU_ Dich offenkundig nicht mit dem Zusammenhang von Kernel und Libraries und Schnittstellen auseinandergesetzt, vielleicht ist Windows auch nicht Dein Metier.

Ich habe keine Ahnung, wie lange Du Dich schon mit der VDI 3814 bzw. EN 16484 beschaeftigt hast, trotzdem kann ich kann mich nur wiederholen: SOFTWARE-GURU!

Du siehst ein paar Screenshots und liest einen kurzen Abriss zu einer Software und kannst beurteilen, dass Du das mit mueden 20k Zeilen hin bekommen wuerdest!

ICH BETE DICH AN!

Na ja, andrerseits: Von Deinem HelpDeco gibt es gar keinen Screenshot... Nach Deiner Logik muesste ich jetzt feststellen, dass bei dem, was da so praesentiert wird, 20 Zeilen angemessen sind, und Dich fragen, fuer was Du die restlichen 6980 Zeilen verbraucht hast.

Schon wieder ein Idol vom Sockel gestuerzt :-(

Verstehe ich das jetzt richtig: IHR schreibt fuer Eure Kunden die IDE, den Editor etc.??? Oder willst Du damit zum Ausdruck bringen, dass Ihr solche allerwelts Werkzeuge ebenso benutzt, wie mittlerweile jeder Hobby-Programmierer? Dass ODBC grottenlangsam ist, brauchst Du hier nicht explizitp zu erwaehnen. Dies ist eine NEWsgroup, also schreib mal etwas, was noch nicht Jedermann weiss.

Aber Moment mal - Du schrubst da ja von 'unserern Massstaeben' und 'wir schreiben': Willst Du ernsthaft behaupten, dass DU da im Tesm mitar- beitest? Sorry, aber DAS glaube ich Dir nicht.

Mach Dir mal nur keine Gedanken ueber meine Baelle [1].

Karlheinz, mit passender Sig

[1] Ich spiele liebend gern, aber grottenschlecht, Snooker, da darf der Ball nur flach gespielt werden.

--
Ich bin mir nicht sicher, ob ich in deinen Aeusserungen ein Indiz
fuer vorhandenen Verstand erkennen kann ...
[Juergen Ilse in dcsf]

Wenn der Kommentar mitgerissen würde, dann hätte man den Kontext auch dabei.

--
Johannes
You can have it:
Quick, Accurate, Inexpensive.
Pick two.

Zumindest sind wir uns einig, dass hinter den Semikola ein Space angebracht ist :-) MaWin wuerde mich wahrscheinlich der sinnlosen Prasserei zeihen, aber ich wuerde das u.U. sogar folgendermassen codiert haben:

for (i = 0; (i < len-1) && src && src[i]; i++) { dest [i] = src [i]; }

Warum? - Nicht nur ich ziehe mir nach 11 Stunden am Arbeitsplatz mal schnell die Sources auf den Stick und mache nach dem Abenbessen weiter mit der Fehlersuche, ohne das Zielsystem (mit Debugger) zur Verfuegung zu haben. Nach 15 Stunden ist man dann dankbar fuer jeden Blank, der einzelne Gedankenschritte trennt und somit nachvollziehbar macht.

QuellZeichenkette && QuellZeichenkette [ElementZaehler] ; ElementZaehler++ )

[ElementZaehler];

Das kommt auf den Geltungsbereich der Variablen an. Bei einer kurzen Schleife ist nichts gegen die Verwendung eines einzelnen Characters zu sagen. Bei einem grossen Geltungsbereich von mehr als einer Seite im Editor (ca. 25 Zeilen), sollte es schon etwas mehr sein. Denn Wenn sich die 'Ein-Character' ueber weite Strecken ansammeln, weiss man irgendwann nicht mehr, was welcher Bezeichner bedeutet, und man scrollt nur noch hin und her, um festzustellen, was denn nun was ist. BTDT

Das mit dem Kommentieren des Funktionsaufrufs ist gefaehrlich! Allzuoft aendert sich das Verhalten einer Funktion, ohne dass daran gedacht wird, den entsprechenden Kommentar beim Funktionskopf anzupassen; auch da fasse ich mir selbst an die eigene Nase (Jugendsuenden um die 30) ;-) Kommentare bei 'Dirty Tricks' sind ein MUSS, fuer den Rest ein KANN. Guter Code sollte fuer sich selbst sprechen und kommentiert sich (durch Verwendung sinn- voller Variablennamen) eigentlich selbst, sogar wenn Aenderungen vorgenommen werden.

Bis dann, Karlheinz

--
Wenn Arbeit etwas schoenes und erfreuliches waere,
haetten die Reichen sie nicht den Armen ueberlassen.
[Paul Lafargue]

Ich bin hier nicht alleine...

Darf ich Dich anmailen, falls ich jemals meine Job verlieren sollte ;-)

Karlheinz, Erfahrung ist durch nichts zu ersetzen, ausser durch noch mehr Erfahrung...

"Karlheinz Böhme" schrieb im Newsbeitrag news:enpmpc$6b6$03$ snipped-for-privacy@news.t-online.com...

Oje oje, das Problem ist wohl, das du hiermit beweist, das du ueberhaupt nicht begriffen hast (sei es weil du ein Leseverstaednisproblem hast oder prinzipiell nicht begreifst) das du mit deinen auf eurer Form der Softwaredistribution basierenden Ratschlaegen, bei Open Source im Freeware/ Shareware Bereich auf dem Holzweg bist. Es findet dort (auch) auf andere Art statt, und da passen eure Vorstellungen nicht und daher passen dort eure Loesungen nicht. Wer bei der Problemanalyse so danebenliegt wie du, macht sich laecherlich und disqualifiziert sich, genau so wie mit sein restlichen Ausfuehrungen.

- BASIC mit C verwechselt, die Lehrprogramme waren in BASIC.

- Deinen eigenen Leerzeichnfehler nicht erkannt (wahrscheinlich nicht geguckt weil du dich unfehlbar findest)

- unfaehig aus dem Assembler-Debug-Trace im Kernel zu entnehmen, wie der Programmlauf war, dazu muss man nicht den C-Source sehen.

Tja, man merkt wie dumm du bist.

--
Manfred Winterhoff