mein prof...
-
Gunnar schrieb:
Da C++ einigermassen abwaertskompatibel zu C ist, ist diese Bezeichnung fuer sich genommen doch richtig?! Nur eben wenn, wie von Korbinian gesagt, der Kontext nicht stimmt, ist es nervig.
Das "einigermaßen" ist das Problem
- vor allem nicht nur an die Syntax denken.MfG SideWinder
-
Die Programmiersprachen C**,** C++
Viele neigen dazu das letzte n zu verschlucken und dann ist da noch das Mikrofon.
-
Was für ein Prof ist das überhaupt?
Bzw. was studierst du?
-
is doch scheiß egal. man kanns auch übertreiben mit dem klugscheißen
-
Gunnar schrieb:
Da C++ einigermassen abwaertskompatibel zu C ist, ist diese Bezeichnung fuer sich genommen doch richtig?! Nur eben wenn, wie von Korbinian gesagt, der Kontext nicht stimmt, ist es nervig.
die forgerungen unterschiede sind so gewaltig, daß man sie fast nie unter einen hut werfen kann.
in c/c++ kann man mit // kommentare machen.
richtiger wäre in {liste mit 80 spreachen) kann man mit // kommentare machen.und jetzt ein paar traurigkeiten:
in c/c++ sollte man funktionen prototypen vor die main() schreiben und die implemetierungen danach.
richtig in c, falsch in c++.in c/c++ sollte man goto nie nehmen.
fast richtig in c++, falsch in c.in c/c++ sollte man viele kommentare setzen.
fast richtig in c, falsch in c++.in c/c++ kann man objektorientiert programmieren.
richtig für beide.in c/c++ macht man leicht speicherlöcher...
richtig in c, falsch in c++....deshalb ist java meistens besser.
richtig für c, falsch für c++.keine dieser traurigkeiten wird je von einem prof richtig gesagt.
damit isses vermutlich keineswegs sinnvoll, dem prof zu sagen, daß "C/C++" zu sagen kein guter stil ist, weil er wie alle profs keinen schimmer davon hat, wie falsch er liegt.
-
volkard schrieb:
in c/c++ sollte man funktionen prototypen vor die main() schreiben und die implemetierungen danach.
richtig in c, falsch in c++.sondern?
Ich hab in einem C/C++ Tutorial (
) nämlich gelernt, das man das genau so macht.
Wie sollte man es für 'sauberes' C++ machen?
-
Ja eben nicht!?
-
Sgt. Nukem schrieb:
Ja eben nicht!?
Ja, aber wie dann? Vor die main, danach, oder gleich in eine extra Datei?
-
volkard schrieb:
damit isses vermutlich keineswegs sinnvoll, dem prof zu sagen, daß "C/C++" zu sagen kein guter stil ist, weil er wie alle profs keinen schimmer davon hat, wie falsch er liegt.
Kommt auf die Vorlesung bzw. das Studium an. Wenn man den Leuten ein bißchen strukturierte Programmierung und problemzerlegendes Denken anhand einer Programmiersprache erklären will, dann ist die Bezeichnung C/C++ doch völlig ausreichend, weil's in der Praxis eh nur auf banale new/malloc- oder printf/cout-Unterschiede rausläuft.
-
troller schrieb:
Sgt. Nukem schrieb:
Ja eben nicht!?
Ja, aber wie dann? Vor die main, danach, oder gleich in eine extra Datei?
in eine schöne eigene *.cpp
-
troller schrieb:
volkard schrieb:
in c/c++ sollte man funktionen prototypen vor die main() schreiben und die implemetierungen danach.
richtig in c, falsch in c++.sondern?
Ich hab in einem C/C++ Tutorial () nämlich gelernt, das man das genau so macht.
Wie sollte man es für 'sauberes' C++ machen?in sauberem c++ liegt die funktionalität in methoden, und wo die methoden zu sein haben, ist weitgehend klar. globale nur für die main() sinvolle funktionen wirds nur eine hand voll geben und die liegen idealerweise vor der main() und nicht dahinter, man erspart sich somit den aufwand, den das pflegen der anderen seite braucht.
werden die funktionen wirgendwann auch für andere übersetungseinheien lukrativ, erstelle man keinesfalls eine main.h (zur erinnerung: die main() lebt in der main.cpp), sondern eine tools.h, globals.h oder wasauchimmer mit entsprechender *.cpp und verschiebe die brachbaren funktionen dorthin.
-
Daniel E. schrieb:
volkard schrieb:
damit isses vermutlich keineswegs sinnvoll, dem prof zu sagen, daß "C/C++" zu sagen kein guter stil ist, weil er wie alle profs keinen schimmer davon hat, wie falsch er liegt.
Kommt auf die Vorlesung bzw. das Studium an. Wenn man den Leuten ein bißchen strukturierte Programmierung und problemzerlegendes Denken anhand einer Programmiersprache erklären will, dann ist die Bezeichnung C/C++ doch völlig ausreichend, weil's in der Praxis eh nur auf banale new/malloc- oder printf/cout-Unterschiede rausläuft.
aber in solchen vorlesungen die leute in c++ einzuführen und dabei den c-stil zu lehren, ist gemein. die nubes brauchen danach jahrzehnte, um den stilistischen mist loszuwerden, den sie erzählt bekamen. sie können einfach nicht trennen, was wahr und was märchen ist. es sind ja nicht immer die offensichtlichen klopfer wie "ihr müßt unbedingt vor jeder funktion ein struktogramm malen und grafisch planen und nachher den code nurnoch übersetzten". sowas sollte keiner mehr glauben (meiner schätzung nach glauben an die 25% es dennoch, wobei nur "uml" statt "struktogramm" gedacht wird). es sind die gemeinen sachen wie deplazierte void*, kathastrophale verkettete listen, unsittliche kommentierungsriten, die vorhin besprochenen prototypen, kryptische fnktnsnmn, der mythische sonderzeichenindex, riesige funktionen (oft inhaltsgleich von lehrbuch zu lehrbuch von algol über fortran, pascal und c nach c++ verschleppt aber nicht totgekriegt) und so weiter. mal überlegen, ob ich über "die lustigen sitten und gebräuche in der lehre des programmierens elektronischer rechenmaschinen" ein buch schreiben sollte, hätte zwar nur ne winzige auflage, aber wäre schnell fertig, weil die probleme einen ja täglich anbrüllen.
-
volkard schrieb:
Daniel E. schrieb:
Wenn man den Leuten ein bißchen strukturierte Programmierung und problemzerlegendes Denken anhand einer Programmiersprache erklären will, dann ist die Bezeichnung C/C++ doch völlig ausreichend, weil's in der Praxis eh nur auf banale new/malloc- oder printf/cout-Unterschiede rausläuft.
aber in solchen vorlesungen die leute in c++ einzuführen und dabei den c-stil zu lehren, ist gemein. die nubes brauchen danach jahrzehnte, um den stilistischen mist loszuwerden, den sie erzählt bekamen.
Ich meinte stilistisch etwa das, was Stroustrup unter http://www.research.att.com/~bs/bs_faq.html#prerequisite beschreibt.
sie können einfach nicht trennen, was wahr und was märchen ist.
Du aber auch nicht:
es sind ja nicht immer die offensichtlichen klopfer wie "ihr müßt unbedingt vor jeder funktion ein struktogramm malen und grafisch planen und nachher den code nurnoch übersetzten". sowas sollte keiner mehr glauben (meiner schätzung nach glauben an die 25% es dennoch, wobei nur "uml" statt "struktogramm" gedacht wird).
Wir lernen auch C, aber Struktogramme oder UML kommt in unserer Vorlesung nicht vor (ist aber kein Info-Studium).
es sind die gemeinen sachen wie deplazierte void*, kathastrophale verkettete listen, unsittliche kommentierungsriten,
In guten C-Programmen ist nichts deplaziert und die anderen Probleme sind keineswegs C-spezifisch. Doofe Komentare findet man sogar in Assember oder Scheme.
die vorhin besprochenen prototypen,
Da habe ich den Unterschied zwischen C und C++ noch nicht ganz gesehen. In beiden kann ich Prototypen setzen oder nicht setzen, so wie's mir paßt und meine bisherige Erfahrung war auch, daß das jeder Autor so macht, wie er gerade lustig ist.
kryptische fnktnsnmn,
Hat nicht direkt was mit C zu tun, wobei ich manche Konventionen eigentlich ganz angenehm zum Lesen empfinde.
der mythische sonderzeichenindex,
?
riesige funktionen
Das hat weder etwas mit C, noch etwas mit strukturierter Programmierung zu tun. Aber wenn's dir Spaß macht: an allen Problemen, die dir bei deiner Arbeit über den Weg laufen, ist natürlich C schuld, und der Dozent, der C/C++ gesagt hat.
-
Daniel E. schrieb:
die vorhin besprochenen prototypen,
Da habe ich den Unterschied zwischen C und C++ noch nicht ganz gesehen. In beiden kann ich Prototypen setzen oder nicht setzen, so wie's mir paßt und meine bisherige Erfahrung war auch, daß das jeder Autor so macht, wie er gerade lustig ist.
in c war es wirklich notwendig, prototypen vor die main() und die implemetierungen hinterher zu schreiben. wenigstens bis man sie ausgelagert hat. dort war die anzahl der globalen funktionen einfach viel größer. sehr früh stehen die prototypen, während an der funktion noch lange gebastelt wird. dazu erfindet man weiere funktionen und ruft auch mal funktionen auf, die weiter unten stehen. die unten müßte man dann hochschieben. aber auch jede, die von ihr aufgerufen wird und jede weitere aufgerufene. das kann zu viel arbeit führen.
der mythische sonderzeichenindex,
?
man zählt einfach die buchstaben und die sonderzeichen im code und teilt die anzahl der sonderzeichen durch die anzahl der buchstaben. das ist der sonderzeichenindex. je größer der sonderzeichenindex, desto kompetenter ist der c-programmierer.