hallo, mal ne frage, ich suche eine gute c / c++ referenz, ich habe früher immer cplusplus.com genutzt, da hatten die ein suchfeld, wo man einfach die funktion eingetippt hat a la php.net und eine referenz dazu bekommen hat. wie bei php.net mit nem kleinen Beispiel und verweisen auf ähnliche funktionen. wenn ihr ne gute kennt sagt bitte bescheit. Danke gruß
:
Verschoben durch Admin
Sonke A. schrieb: > hallo, > > mal ne frage, ich suche eine gute c / c++ referenz, ich habe früher > immer cplusplus.com genutzt, da hatten die ein suchfeld, wo man einfach > die funktion eingetippt hat a la php.net und eine referenz dazu bekommen > hat. Und was ist an cplusplus.com schlecht? Ich geb den gesuchten Funktionsnamen eigentlich immer einfach in google ein. Meistens lande ich dann bei cplusplus.com. Hauptsächlich benutze ich google deshalb, weil die vorhandene Hilfe im Developer Studio immer so rumtrödelt und mich mit Zeugs überschüttet, das mich gar nicht interessiert. Ich finde die Hilfe bei MS im DevStudio wird immer schlechter.
Spricht was gegen die Referenz einer gängigen C-Bibliothek? Etwa die Dokumentation zur glibc? Sonst empfehle ich wärmstens O'Reilly / C in a nutshell bzw. C++ in a nutshell.
Ein Standard von Kernighan & Ritchie : Ich und C, oder so. Wichtig sind die Autoren.
Klaus Wachtler schrieb:
> etwas genauer: Kernighan; Ritchie; Programmieren in C. ANSI C (Hanser)
die englische originalfassung von K&R ist die deutlich bessere wahl...
Die aktuelle deutsche Übersetzung ist m.M.n. hervorragend. Man lernt überdies, Sachverhalte in klarem Deutsch zu beschreiben, ohne dass es sich blöd anhört.
Ja, die deutsche Übersetzung der ersten Auflage war grottig. Die aktuelle ist prima.
Die erste Auflage war so oder so grottig, da sie noch das uralte "K&R"-C beschreibt, das noch keine Typüberprüfung bei Funktionsargumenten kannte. Deren deutsche Übersetzung wirkt, als wäre sie mit einem Übersetzungsprogramm erstellt, und die in einer Proportionalschrift gedruckten Codebeispiele machen die Sache nicht besser. Der ersten Auflage dürfte man allerdings nur noch antiquarisch oder in Museen begegnen, war sie doch bereits Anfang der 90er Jahre veraltet. Die zweite Auflage ist auch in der deutschen Übersetzung exzellent.
Gute Lektüre, wenn der Professor oder Lehrer mal Unfug verzapft, ist auch der Draft der ISO. Damit kann man so Karteileichen, wie etwa
1 | void main() { |
2 | |
3 | }
|
ganz schnell ausräumen.
Sven P. schrieb: > Gute Lektüre, wenn der Professor oder Lehrer mal Unfug verzapft, ist > auch der Draft der ISO. > Damit kann man so Karteileichen, wie etwa >
1 | > void main() { |
2 | >
|
3 | > } |
4 | >
|
> ganz schnell ausräumen.
Warum habe ich nur den Eindruck, dass ich nicht der Einzige auf der Welt
bin, der sich über sowas ärgert. Studenten gucken sich sowas dann ab ;)
Schlimm ist auch, wenn man auf dem Aufgabenblatt vom Dozent einen
grausam formatierten Quelltext bekommt. Dabei ist 50% des Programmierens
quasi nur Formatierung und Kommentierung ;)
Mal so paar Beispiele:
1 | int a, b = 1; |
2 | a = b++ + ++b; |
3 | |
4 | /* ***** */
|
5 | |
6 | int i = 1; |
7 | i = i++; |
8 | /* Steht so im Nachschlagewerk eines bekannten Rechenzentrums... */
|
9 | |
10 | /* ***** */
|
11 | |
12 | getchar(); |
13 | getchar(); /* damit Konsolenfenster auf bleibt */ |
14 | |
15 | /* ***** */
|
16 | |
17 | /* Aus einer Vorlesung der Uni Marburg: */
|
18 | #include <iostream.h> // Hier werden zusätzliche Befehle eingebunden |
19 | void main() // Das ist das Hauptprogramm |
20 | { // Hier fängt ein Anweisungsblock an |
21 | cout << "Hallo Welt!" << endl; |
22 | // Hier wird etwas ausgegeben
|
23 | } // Hier hört der Anweisungsblock auf |
24 | |
25 | /* ***** */
|
vielen Dank für die Zahlreichen Tipps, werde mir fürs Studium in jedem Fall mal das K&R kaufen. Nur ich suchte eher ne online Referenz, wo man schnell mal die funktion eintippen kann, wenn man sich nicht sicher ist, z.b. was es für Kürzel bei printf() gibt usw. usw. also wenn man die funktion bereits kennt aber zusatzinfos braucht. Schön wäre es, wenn dort auch kernel spezifische befehle wie fork() oder signals bei Unix drinn wären. Sone Datenbank muss es doch geben oder? bei den Standart c funktionen komme ich ja mit google noch weiter aber wenns dann tiefer geht... naja. zu den schlechten Vorgaben kann ich auch noch was sagen. Wenn sie denn nur son formalen Blödsinn verzapfen würden wäre das ja verschmerzbar aber uns zu erklähren es wäre gut zwischen zwei prozessen über eine gemeinsam geöffnete Datei zu kommunizieren anstatt threds zu benutzten finde ich doch naja nicht gerade ein Wink in die richtige Richtung.
Was hälste denn von Manpages? http://www.freebsd.org/cgi/man.cgi Abschnitt 3; Derivat kannste dir aussuchen :-}
Ich finde
1 | void main() |
in der Embedded Programmierung gar nicht ärgerlich. main() wird (zumindest auf einem µC ohne Betriebssystem, und das sind verdammt viele) sowieso niemals verlassen. Unter diesem Umstand einen Rückgabewert zwingend einzufordern, der niemals ausgewertet werden kann, erscheint mir dann doch ein bisschen unsinnig. Ja, der Standard sieht etwas anderes vor. Hat der Standard aber auch explizit an Embedded Systems gedacht? Eben. ;-)
Klar, ist halt genauso unsinnig, wie der Epilog, den der AVR-GCC anklebt. Hat man da an Embedded gedacht? Nö :-)
> aber uns zu erklähren es wäre gut zwischen zwei prozessen > über eine gemeinsam geöffnete Datei zu kommunizieren anstatt > threds zu benutzten finde ich doch naja nicht gerade ein Wink > in die richtige Richtung. Threads sind nichts, was bei der Kommunikation zwischen zwei Prozessen irgendwie helfen könnte, insofern hat der Dozent schon sehr wohl recht.
Rufus t. Firefly schrieb: >> aber uns zu erklähren es wäre gut zwischen zwei prozessen >> über eine gemeinsam geöffnete Datei zu kommunizieren anstatt >> threds zu benutzten finde ich doch naja nicht gerade ein Wink >> in die richtige Richtung. > > Threads sind nichts, was bei der Kommunikation zwischen zwei Prozessen > irgendwie helfen könnte, insofern hat der Dozent schon sehr wohl recht. Naja, wenn man das Problem in zwei Threads zerlegt, tuns (globale) Variablen. Oder wenigstens eine PIPE (Fifo, Unix-Socket). Aber reguläre Dateien ist wirklich ätzend.
>> aber uns zu erklähren es wäre gut zwischen zwei prozessen >> über eine gemeinsam geöffnete Datei zu kommunizieren anstatt >> threds zu benutzten finde ich doch naja nicht gerade ein Wink >> in die richtige Richtung. > > Threads sind nichts, was bei der Kommunikation zwischen zwei Prozessen > irgendwie helfen könnte, insofern hat der Dozent schon sehr wohl recht. > Naja, wenn man das Problem in zwei Threads zerlegt, tuns (globale) > Variablen. Ein gemeinsamer Adressraum ist nicht immer ein Vorteil. Manchmal will man nicht, daß das Hauptprogramm z.B. von einem fehlerhaften Plug-in gekillt werden kann, also wird das Plug-in als eigener Prozess gestartet. > Oder wenigstens eine PIPE (Fifo, Unix-Socket). Aber reguläre > Dateien ist wirklich ätzend. Hat den Vorteil, daß man dafür nicht auf systemspezifische Erweiterungen angewiesen ist und daß es die einfachst-mögliche Variante ist. Dank Cache ist es auch nicht so übertrieben langsam, wenn's nur kleine Datenmengen sind. Natürlich ist eine pipe oder gar shared memory effizienter. Was man verwenden sollte, hängt aber vom Anwendungsfall ab. Wenn es um Interprozesskommunikation geht, sollte der Professor erklären, welche Möglichkeiten es gibt und welche Vor- und Nachteile diese haben. Wenn's aber um die C-Grundlagen geht, sind Dateien die einzige Möglichkeit, weil's in ISO-C nichts anderes gibt. Übrigens benutzt auch gcc zum Austausch der Daten zwischen seinen ganzen Child-Prozessen temporäre Dateien, wenn man ihm nicht explizit sagt, daß er stattdessen pipes verwenden soll. > Schön wäre es, wenn dort auch kernel spezifische befehle wie fork() oder > signals bei Unix drinn wären. Sone Datenbank muss es doch geben oder? Fork ist nicht kernel-spezifisch, sondern ein POSIX-system-call. Unix-Derivate bringen diese Doku normalerweise in Form von Manpages bereits mit. Probiere mal ein "man fork" in deiner Shell. Wenn er da nichts findet, sind die development-Manpages wohl noch nicht installiert. Ein anderer geschickter Befehl dazu ist "apropos" (alternativ "man -k"). Bei KDE kann man übrigens einfach Alt+F2 drücken und dann einfach "#fork" eingeben, um eine hübsch formatierte Manpage für fork zu bekommen.
Rolf Magnus schrieb: > Wenn's > aber um die C-Grundlagen geht, sind Dateien die einzige Möglichkeit, > weil's in ISO-C nichts anderes gibt. Nun, wenn es um Prozesse geht, dann muss ja auch ein Betriebssystem da sein welches diese verwaltet. Ein solches stellt üblicherweise auch Mechanismen wie eben "message queues" zur Verfügung. Eine Alternative dazu hardcore-low level-mäßig mit Dateien selbst zu implementieren, um C zu lernen... das ist begrenzt sinnvoll. ;-)
Sven P. (haku) wrote: > Was hälste denn von Manpages? > http://www.freebsd.org/cgi/man.cgi > Abschnitt 3; Derivat kannste dir aussuchen :-} Ehrlich gesagt halte ich von solchen Tipps nichts. Die Definition alleine aufzulisten ist einfach zu wenig, siehe http://www.freebsd.org/cgi/man.cgi?query=printf&apropos=0&sektion=0&manpath=SuSE+Linux%2Fi386+9.3&format=html Wo bleiben die Beispiele? Dann schon lieber das hier http://openbook.galileocomputing.de/c_von_a_bis_z/004_c_ein_ausgabe_001.htm#mj20c131820fbfb1497afd796ee443599e Womit wir wieder beim alt bekannten Problem wären, eine gut gemachte Onlinehilfe mit treffenden Beispielen ist ausdrucksstärker als tausend Definitionen, die einem Anfänger meist nicht wirklich weiterbringen. Da krankt es typischerweise bei Linux .. Eine gute IDE bietet das .. bestes Beispiel war damals Borland TC 3.x für DOS.
langjähriger Windows Nutzer schrieb: > Sven P. (haku) wrote: > >> Was hälste denn von Manpages? > >> http://www.freebsd.org/cgi/man.cgi > >> Abschnitt 3; Derivat kannste dir aussuchen :-} > > Ehrlich gesagt halte ich von solchen Tipps nichts. Die Definition > alleine aufzulisten ist einfach zu wenig, siehe > > http://www.freebsd.org/cgi/man.cgi?query=printf&apropos=0&sektion=0&manpath=SuSE+Linux%2Fi386+9.3&format=html ist ja auch die falsche man-page, nämlich die aus Abschnit 1 (statt 3), also zum Shellbefehl printf. man 3 printf ist zumindest auf meinem Linux (igitt) erstens die richtige Seite, und zweitens wesentlich ausführlicher. > ...
Ich halte persönlich 0.nix davon, primär irgendwelche Beispiele in der Dokumentation zu haben. Wenn man versteht, wie man eine Funktion aufruft (und das kann man durchaus), kann man alle aufrufen. Und ausführlicher und eindeutiger, als gute Manpages, geht es kaum, da die sowieso meistens den Standard reflektieren. Und der ist schon ziemlich knapp und knackig gehalten.
Sven P. (haku) wrote: > Ich halte persönlich 0.nix davon, primär irgendwelche Beispiele in der > Dokumentation zu haben. Ich halte von keiner Dokumentation etwas die mir nicht auch Anwendungsbeispiele beschert. > Wenn man versteht, wie man eine Funktion aufruft (und das kann man > durchaus), kann man alle aufrufen. Na dann dürften sich ja kaum mehr Fragen ergeben, wenn jeder durch einen Blick in die Definition sofort bescheid wüsste. Tatsache ist, die Foren strotzen nur so von "NichtBescheidWissern". > Und ausführlicher und eindeutiger, als gute Manpages, geht es kaum, da > die sowieso meistens den Standard reflektieren. Und der ist schon > ziemlich knapp und knackig gehalten. Soso, Linux ist wie immer das Beste. Ehrlich gesagt finde ich so eine Haltung ziemlich eingebildet. Wenn das was oben gesagt ist zutreffen würde könnte man fast den gesamten Markt an Büchern über Programmierung für sinnlos erklären. Tatsache ist, die Allermeisten lernen noch immer anhand guter Beispiele und es gibt sehr gute Bücher wie z.B. die von Charles Petzold. Ich möchte denjenigen mal sehen, der die (etwas in die Tage geratene) Win32 Api-Programmierung nur anhand der Microsoft'schen Definitionen erlernt. Aber solche Zauberkünstler soll es ja geben.
> wo kam da jetzt Linux vor?
Na wenn dir das nicht auffällt, solltest du dich lieber mit anderen
Themen beschäftigen.
Mache ich gelegentlich, und dabei habe ich schon man-Pages gesehen, ohne an einem Linux-Rechner zu sitzen. Es schadet wirklich nichts, sich mal mit anderen Themen zu beschäftigen. Das einzige, was mir hier wirklich auffällt, ist daß die meisten in diesem Thread einfach nur trollen.
... schrieb: > Sven P. (haku) wrote: > >> Ich halte persönlich 0.nix davon, primär irgendwelche Beispiele in der >> Dokumentation zu haben. > > Ich halte von keiner Dokumentation etwas die mir nicht auch > Anwendungsbeispiele beschert. Ich auch nicht. Aber das habe ich ja auch nicht gesagt. >> Wenn man versteht, wie man eine Funktion aufruft (und das kann man >> durchaus), kann man alle aufrufen. > > Na dann dürften sich ja kaum mehr Fragen ergeben, wenn jeder durch einen > Blick in die Definition sofort bescheid wüsste. Tatsache ist, die Foren > strotzen nur so von "NichtBescheidWissern". Von denen 99% sich auf folgende Kategorien aufteilen: a. Ich habe kein C-Buch und betreibe Trial-and-error. b. Ich habe bisher nur auswendig gelernt, ohne zu begreifen. c. Ich kann den Parametern keine Argumente zuordnen, weil ich offenbar nicht verstanden habe, was Argumente sind und wo sie herkommen. Alternativ dazu kommt der Fall, eine Funktion missbrauchen zu wollen. >> Und ausführlicher und eindeutiger, als gute Manpages, geht es kaum, da >> die sowieso meistens den Standard reflektieren. Und der ist schon >> ziemlich knapp und knackig gehalten. > > Soso, Linux ist wie immer das Beste. Weiß ich nicht. Ich weiß nur, dass C für Unix erfunden wurde, demnach sollte man da wohl am besten Bescheid wissen. Handbuchseiten gibt es ansonsten auch unter Linux, Windows, BSD, MacOS und auf Papier. > Ehrlich gesagt finde ich so eine Haltung ziemlich eingebildet. Wenn das > was oben gesagt ist zutreffen würde könnte man fast den gesamten Markt > an Büchern über Programmierung für sinnlos erklären. Tatsache ist, die > Allermeisten lernen noch immer anhand guter Beispiele und es gibt sehr > gute Bücher wie z.B. die von Charles Petzold. Das hat niemand bestritten. Aber primär soll man meiner Meinung nach nicht Beispiele lernen, sondern C. Und der Sprachumfang von C passt ja nun wirklich auf eine halbe Din-A4-Seite. Was man dann damit macht, wenn man es beherrscht, ist ja wieder ein anderes Beispiel. So Aussagen wie etwa: > 'getchar()', damit das Konsolenfenster offen bleibt. kotzen mich von vorn bis hinten an. Wobei eine libc mittlerweile auch mehr Clusterf*ck als sauber ist; aber wenigstens ist sie recht eindeutig umrissen. Die Funktionen in der libc können nicht viel, aber das Bisschen, was sie können, tun sie i.d.R. vernünftig und wohldefiniert.
mein Gott, du lernst es auch nicht mehr. "libc" ist doch jetzt schon wieder sowas von Linux, also nein!
Weißt du Klaus, was einem hier im Forum immer wieder auffällt? Es scheint sehr beliebt zu sein, ein bestimmtes Frage-Antwort Spiel hier vom Zaun zu brechen und genau das hast DU gerade getan. Und wer dann auf dieses Spielchen nicht eingeht, der ist im Anschluss dann der Troll. Und jetzt mal zur Sache, mir ist völlig Schnuppe an welchem Rechner DU sitzt und DEINE MANPAGES liest. Wegen mir kannst DU dein BSD, dein SunOS, dein IRIX, deinen MAC oder sonst irgend einen Rechner toll finden. Die ALlermeisten die MANPAGES lesen, lesen die auf ihrem Linux-Derivat und deswegen war mein Einwand völlig zutreffend und deine Frage mit Erwartungshaltung nichts anderes als Forenbeschäftigung. Manpages kann man sogar unter Windows nutzen, da gibt es aber andere Software, die nicht die Schlechteste ist und sich Visual-Studio nennt und diese nutzt keine Manpages. Deswegen verbindet man i.A. Manpages NICHT mit Windows. Hoffentlich ist das jetzt geklärt, den der eigentliche Punkt ging darum, dass es hier vorgeblich "superschlaue Programmierkönner" gibt, die all ihr Können angeblich aus der reinen Definition der jeweiligen Programmiersprache erlernt haben. Vermutlich wollen diese Leute auch ihre Fremdsprachen (Englisch, Französich etc.) aus der reinen grammatikalischen Herleitung erlernt haben und schon damals im Klassenzimmer der Lehrerin mit dem Finger schnalzend entgegen geschrien haben, sie solle doch auf das Lesen der Frendsprache sowie Beispiele verzichten, weil das doch nur was für Doofe wäre und die Grammatik alleine doch für den Lernerfolg ausreichen würde. Ich glaube von all dem NICHTS, GAR NICHTS! Weil es meiner Lebenserfahrung derart widerspricht, dass ich sowas höchstens einer Klasse von Autisten zutrauen würde. Aber auch die sollen sich ja in Foren tummeln ..
... schrieb: > Und jetzt mal zur Sache, [...] Mir ist das auch egal. Ich weiß, wo mein K&R steht, wo mein C in a nutshell steht und wo ich den C99-Standard habe. > Hoffentlich ist das jetzt geklärt, den der eigentliche Punkt ging darum, > dass es hier vorgeblich "superschlaue Programmierkönner" gibt, die all > ihr Können angeblich aus der reinen Definition der jeweiligen > Programmiersprache erlernt haben. [...] Hat das sowie den Rest hier irgendjemand behauptet? > Ich glaube von all dem NICHTS, GAR NICHTS! Weil es meiner > Lebenserfahrung derart widerspricht, dass ich sowas höchstens einer > Klasse von Autisten zutrauen würde. Aber auch die sollen sich ja in > Foren tummeln .. Dann lässt du es eben bleiben. Vielleicht solltest du zuerst nochmal in Ruhe die Beiträge hier durchlesen, bevor du abermals voreilige Schlüsse ziehst und dich unnötig aufregst.
> Von denen 99% sich auf folgende Kategorien aufteilen: > a. Ich habe kein C-Buch und betreibe Trial-and-error. nö, das geht so Ich habe GENÜGEND C-Bücher* und betreibe DENNOCH Trial-and-error. > b. Ich habe bisher nur auswendig gelernt, ohne zu begreifen. nö, bei jedem Lernen lernt man AUCH auswenig. Den "URI" kennst du hoffentlich auch auswendig oder? Und was das begreifen betrifft, das kommt automatisch mit der Beschäftigung. Sven P. (haku) du hast eine Neigung andere gerne als dumm darzustellen. > c. Ich kann den Parametern keine Argumente zuordnen, weil ich offenbar > nicht verstanden habe, was Argumente sind und wo sie herkommen. .. und das eben Gesagte gilt schon wieder * übrigens, zum Thema C-Bücher oder Bücher über die Programmiersprache C, ich kenne kein Buch das nicht auch genügend Beispiele verwendet. Ist übrigens mit anderem Stoff auch nicht anders. Der Mensch lernt anhand von Beispielen, schon seit Anbeginn der Evolution. Wie macht man Feuer? Schau dir an wie andere es machen ..
Lieber ... (Beileid zu dem Namen übrigens): woher weisst du, was ich toll finde? Ich finde zum Beispiel Doku mit griffigen Beispielen prima (egal unter welchem OS). Da gebe ich dir auch vollkommen recht. Davon hatte ich aber nichts geschrieben. Was ich krank finde, ist: jemand erwähnt in irgend einem Zusammenhang "man" und jemand anders schreit gleich "Linux", anstatt auf den Inhalt einzugehen. Nur dazu hatte ich mich geäussert. Falls ich dich damit jetzt so verwirrt habe, daß du nicht mehr den Text lesen und verstehen kannst, tut mir das leid. Für dich. Prost, ich gehe schlafen. Morgen muß ich wieder programmieren.
>> Hoffentlich ist das jetzt geklärt, den der eigentliche Punkt ging darum, >> dass es hier vorgeblich "superschlaue Programmierkönner" gibt, die all >> ihr Können angeblich aus der reinen Definition der jeweiligen >> Programmiersprache erlernt haben. [...] > Hat das sowie den Rest hier irgendjemand behauptet? Genau das hast DU behauptet Zitat: "Ich halte persönlich 0.nix davon, primär irgendwelche Beispiele in der Dokumentation zu haben." Ach du wolltest damit sagen DEINE BEISPIELE sollen woanders stehen? Wo denn? Vielleicht reden wir auch aneinender vorbei. Du redest über den dir gefälligen Aufbau von Manpages und ich rede davon, Bücher zu verabscheuen die mich mit Definitionen überhäufen ohne auch nur ein einziges Beispiel der Anwendung zu bringen. SO ein Buch ist für mich eines von Langweilern für Langweiler geschrieben Aber ehrlich gesagt, 9x Prozent aller Bücher über Programmiersprachen sind glücklicherweise mit genügend Beispielcode unterfüttert.
> Falls ich dich damit jetzt so verwirrt habe, daß du nicht mehr > den Text lesen und verstehen kannst, tut mir das leid. > Für dich. Warum müssen hier eigentlich einige anderen gegenüber immer hochnäsig auftreten? Habt ihr so ein schwaches Ego, dass ihr das braucht? Immer den anderen a. für doof halten b. herunterputzen c. die eigenen Fähigkeiten überhöhen?
Manpages sind halt nur so gut, wie sie geschrieben sind. Auf unixoiden Systemen gibt es einen Befehl namens find, mit dem man unter anderem herausfinden kann, wo im Dateisystem sich eine Datei bestimmten Namens verbirgt. Ich hatte mal das Pech, mit einem Echtzeitsystem namens Lynx arbeiten zu müssen, wo dessen manpages herkamen, weiß ich nicht. Jedenfalls war die find -Manpage auf diesem System in einer dem Englischen nur sehr entfernt verwandten Sprache geschrieben, das heißt, Wortschatz, Grammatik und Syntax waren schon englisch, aber der Inhalt war komplett unverständlich (und ich lese wirklich sehr viel auch anspruchsvollere Literatur auf Englisch). Die BSD-Manpage auf meinem Mac ist auch nicht wirklich sehr übersichtlich (sie wirkt arg akademisch), aber immerhin werden ein paar Beispiele genannt.
... schrieb: >> Von denen 99% sich auf folgende Kategorien aufteilen: >> a. Ich habe kein C-Buch und betreibe Trial-and-error. > > nö, das geht so > > Ich habe GENÜGEND C-Bücher* und betreibe DENNOCH Trial-and-error. Das ist schön für dich. Ich betreibe ja auch Trial-and-error, nennt sich 'Debugging'. Allerdings lese ich nicht 'printf' und probiere dann alle möglichen Konbinationen von Argumenten aus, bis es irgendwann funktioniert. >> b. Ich habe bisher nur auswendig gelernt, ohne zu begreifen. > > nö, bei jedem Lernen lernt man AUCH auswenig. Den "URI" kennst du > hoffentlich auch auswendig oder? Und was das begreifen betrifft, das > kommt automatisch mit der Beschäftigung. Versteh ich nicht. > Sven P. (haku) du hast eine Neigung andere gerne als dumm darzustellen. Ich habe die Neigung, schlechte Prinzipien zu verurteilen, etwa Aufrufe von Funktionen auswendig zu lernen, oder eben nur konkrete Beispiele. Ich habe oft genug Dreck gefressen, was das angeht. Stundenlang wird im Informatik-Unterricht ein Beispiel mit Variable A durchdiskutiert. Dann kommt eine Aufgabe, A heißt nun B und die Hälfte der Schüler fällt aufs Maul. Man diskutiert, wie man eine Schleife in eine andere schachtelt. Dann wird in der Aufgabe noch eine dritte Schleife benötigt und wieder haben 50% das Prinzip nicht verstanden. >> c. Ich kann den Parametern keine Argumente zuordnen, weil ich offenbar >> nicht verstanden habe, was Argumente sind und wo sie herkommen. > > .. und das eben Gesagte gilt schon wieder Weil? > * übrigens, zum Thema C-Bücher oder Bücher über die Programmiersprache > C, ich kenne kein Buch das nicht auch genügend Beispiele verwendet. > > Ist übrigens mit anderem Stoff auch nicht anders. Der Mensch lernt > anhand von Beispielen, schon seit Anbeginn der Evolution. Wie macht man > Feuer? Schau dir an wie andere es machen .. Hast du mittlerweile das Wort 'primär' in dem Satz entdeckt, an dem du dich so sehr störst? Ich sagte, ich halte nichts davon, primär irgendwelche Beispiele in der Doku zu haben. In die Doku gehören Prototypen mit knackiger Beschreibung der Parameter. Beispiele sind schön, die meisten sind dann aber redundant.
> Was ich krank finde, ist: jemand erwähnt in irgend einem Zusammenhang > "man" und jemand anders schreit gleich "Linux", anstatt auf den Inhalt > einzugehen. Ne Klaus, bei dir ist was ganz anderes, was ich hier permanent beobachte. Du gehörst zu der Clique die sobald man ihnen am Zeug kratzt (meistens am Linux-Zeug, in dem Falle auch mal am Unix-Zeug) einen Reflex entwickeln, un der geht heißt, einer hat eventuell gewagt ein Unix-Derivat nicht zu würdigen, den lass' ich gleich mal spüren, wer die Sachkenntnis besitzt und wer höchstens Klickibunti betreibt. Obwohl Klickibunti und Klickibuntu wohnen auch nicht weit auseinander ..
Sven P. schrieb: > ... > Man diskutiert, wie man eine Schleife in eine andere schachtelt. Dann Nicht schon wieder böse Wort "man" erwähnen! Schlaft schön, und streitet doch nicht zu einer so unchristlichen Zeit! > ...
Um dem nochmal Nachdruck zu verleihen, vielleicht wirds eindeutig: Ich erlaube mir ganz sicher kein Urteil über jemanden. Ich glaube aber beurteilen zu können, ob jemand etwas verstanden hat oder nur reproduziert. Ich erlaube mir auch gewiss kein Urteil zu '...' oder sonstwem hier, ich kenn ihn/sie ja garnicht. Mir tut es Leid für jemanden, der verbockt wurde, also C/... z.B. total verkorkst beigebracht bekommen hat. Umso schwerer wirds nämlich nachher, wieder auf einen brauchbaren Pfad zu gelangen... ich hab das selbst mitmachen müssen. Darum bin ich gegenüber 'Beispielen' seeeeeeeeeeeeeehr kritisch eingestellt. Nicht, dass Beispiele schlecht sind. Natürlich lerne ich anhand von Beispielen. Aber nicht primär! Anhand von Beispielen kann man die Systematik verdeutlichen (wie schachtele ich zwei Schleifen). Das ändert nichts daran, dass man die Systematik dennoch nüchtern und abstrakt verstehen muss, um sie anders anwenden zu können (wie schachtele ich n Schleifen). Zumal ich gerade im Studium denselben Quark wieder mitkrieg. Beispiel:
1 | int i = 84; |
2 | |
3 | /* if (i % 2 == 1) */
|
4 | if (i) |
5 | puts("ungerade"); |
Der Professor hat das erste If auskommentiert, um mit dem zweiten zu demonstrieren, dass alles != 0 als wahr bewertet wird. Prompt die Frage aus dem Auditorium: 'Aber Herr Professor, 84 ist doch nicht ungerade, sondern gerade!'.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.