mikrocontroller.net

Forum: PC-Programmierung Suche gute c referenz


Autor: Sonke A. (soeni)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Standard von Kernighan & Ritchie : Ich und C, oder so. Wichtig sind 
die Autoren.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
etwas genauer: Kernighan; Ritchie; Programmieren in C. ANSI C (Hanser)

Autor: Daniel F. (df311)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> etwas genauer: Kernighan; Ritchie; Programmieren in C. ANSI C (Hanser)

die englische originalfassung von K&R ist die deutlich bessere wahl...

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, die deutsche Übersetzung der ersten Auflage war grottig.
Die aktuelle ist prima.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gute Lektüre, wenn der Professor oder Lehrer mal Unfug verzapft, ist 
auch der Draft der ISO.
Damit kann man so Karteileichen, wie etwa
void main() {

}
ganz schnell ausräumen.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
>
> void main() {
> 
> }
> 
> 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 ;)

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal so paar Beispiele:
int a, b = 1;
a = b++ + ++b;

/* ***** */

int i = 1;
i = i++;
/* Steht so im Nachschlagewerk eines bekannten Rechenzentrums... */

/* ***** */

getchar();
getchar(); /* damit Konsolenfenster auf bleibt */

/* ***** */

/* Aus einer Vorlesung der Uni Marburg: */
#include <iostream.h>  // Hier werden zusätzliche Befehle eingebunden 
void main()            // Das ist das Hauptprogramm 
{                      // Hier fängt ein Anweisungsblock an 
  cout << "Hallo Welt!" << endl; 
                       // Hier wird etwas ausgegeben 
}                      // Hier hört der Anweisungsblock auf

/* ***** */


Autor: Sonke A. (soeni)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was hälste denn von Manpages?

http://www.freebsd.org/cgi/man.cgi

Abschnitt 3; Derivat kannste dir aussuchen :-}

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde
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. ;-)

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar, ist halt genauso unsinnig, wie der Epilog, den der AVR-GCC 
anklebt. Hat man da an Embedded gedacht? Nö :-)

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Realist (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: langjähriger Windows Nutzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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&ap...

Wo bleiben die Beispiele?

Dann schon lieber das hier

http://openbook.galileocomputing.de/c_von_a_bis_z/...

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.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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&ap...

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.

> ...

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wo kam da jetzt Linux vor?

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> wo kam da jetzt Linux vor?

Na wenn dir das nicht auffällt, solltest du dich lieber mit anderen 
Themen beschäftigen.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mein Gott, du lernst es auch nicht mehr.
"libc" ist doch jetzt schon wieder sowas von Linux, also nein!

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ..

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ..

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ..

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

> ...

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
int i = 84;

/* if (i % 2 == 1) */
if (i)
  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!'.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.