Ihr Elenden Perversen! Haltet euch an den Standard!
-
Ja, aber als Programmierer muss man auch abstrahieren und übertragen können.
-
Eure Vergleiche mit dem Abweichen vom Standard sind etwas schlecht, denn hier meckert keiner, wenn jdm. Funktionen benutzt um seine Konsole farbig zu gestalten, aber sehr wohl, wenn Funktionen benutzt werden, welche ebenso der Standard bietet (Paradebeispiel ist hier doch iostream.h, welches heute nur noch in äußerst seltenen Fällen wirklich benutzt werden muss).
-
prolog schrieb:
"Wenn dein Program sein Aufgabe erledigt bevor dein Boss dich feuert, ist es richtig und gut.".
Ich finde da ist was dran. Ich meine wer fährt denn so wie er es in der Fahrschule gelernt hat ?
*lol*
Irgendwie ist das alles nur noch zum totlachen - OK, war vorher nicht besser - aber die letzten paar Posts sind geil.
Also zumindest bei mir in der Arbeit ist ein "es läuft" nicht genug. OK, es ist genug für den Chef und den Kunden - aber nicht für mich. Denn schließlich muss _ich_ den Code debuggen, neue Features hinzufügen, ihn dokumentieren oder sonstwas damit machen. Da reicht ein "es läuft" einfach nicht aus...
Und das mit dem Auto. *lol*
Egal wie mies man fährt - man kann das mit jedem Auto machen.
Wenn wir das jetzt aufs programmieren übertragen: Egal wie mies ich programmiere, es läuft überall. TUUUUT Diese Aussage ist falsch.Das Problem ist doch, dass der C++ Standard ein gemeinsamer Nenner ist. Ich kann viele Sachen super mit Standard C++ implementieren. Und wenn ich OS spezifische Sachen verwenden muss, dann kapsle ich die sowieso. Warum? Einfach weil es sowieso nur eine C API ist, die ich sowieso kapseln muss. Da kann ich mit geringem Mehraufwand das Programm sogar portierbar halten.
Compilerfeatures sind auch ganz nett. zB ein
#define UNREACHABLE __assume(0)
ist ganz witzig. Und das schöne - wunderbar portierbar, weil es hinter einem define steckt.Wenn man will, kann man C++ Programm wunderbar und sauber implementieren und dennoch schön flott unterwegssein und immernoch recht portabel sein.
Man kann aber noch leichter mieses C++ programmieren.
Man kann sich aber auch super an den C++ Standard halten und miese Sachen machen:
system("mkdir foo");
bei sowas fragt man sich dann, ob der Autor den Code versteht...Genauso frage ich mich aber auch ob der Autor das ernst meint, wenn man so Sachen sieht wie "randomize()" oder "getch" sieht. Da denke ich mir immer - ist es denn wirklich so schwer srand() und cin.get() zu verwenden? (Ausnahme ist natürlich wenn man getch wirklich braucht - das ist aber nur in etwa 10% der Fälle der Fall).
Ich verstehe diese Ignoranz gegenüber dem C++ Standard einfach nicht. Klar, hinten und vorne fehlt etwas - aber es wird ja nicht nach einem typeof, hash_map oder so etwas geschriehen, sondern meistens sind diese Verstöße gegen den Standard einfach lächerlich. Weil es sich zB bei einem system("pause") nun wirklich nicht lohnt. Genauso bei einem #include <iostream.h> - vorallem weil viele denken, dass iostream.h == iostream ohne namespace ist.
Sowas finde ich einfach zu totlachen. Genauso void main(). Wozu denn? nur um 1 Buchstaben mehr zu schreiben?
-
Meine Fresse. Ihr mit eurem lächerlichen Standard. Wie die Kleinkinder...
Habt ihr nichts wichtigeres zu tun?
Und ShadeOfMine der Oberspießer mischt kräftig mit.
-
Ihr habt glück, das ich gerade o faul bin. Sonst würde ich massenweise Merkbefreiungsanträge ausfüllen.
-
@Shade
Es wurde doch jetz mehrfach geschrieben, dass es natürlich so sein sollte bei solch einfachen Sachen wie iostream.h oder iostream die standardkonforme Variante zu wählen. Das stand doch garnicht zur Diskussion.
Btw.: hast du die Analogie zum Auto fehlinterpretiert. Was zugegebenermaßen nicht schwer ist, wenn man das ganze Formal angeht. Denn wenn ich z.B.: mal den Schulterblick vergesse, klappt das zwar mit jedem Auto ist aber nicht zwingend ans Auto als Objekt gebunden, sodass dein Vergleich mit dem Programmieren nicht funktioniert. Aber das ist Haarspalterei.Ich hab mal nachgeschaut wo das Zitat stand, es war in "Programmieren mit Perl (o'Reilly) von Larry Wall et all". Allerdings ist es die übersetzte Auflage und ich weiss nicht wie sehr der Sinn bei der Übersetzung gelitten hat.
Btw.: kann ich mich an einen Thread von dir errinnern in dem du (sinngemäß) gefragt hast, wie du deine Projekte und das Management besser machen kannst, weil ihr bis dato immer nur bugs schnell gefixed habt, wobei ihr dann irgendwann die Übersicht verlohrt weil ihr einfach nicht die Zeit hattet (von Chefseite). So oder so ähnlich wars. Da stand doch auch die Funktionalität im Vordergrund.(Wenn ich das falsch verstanden hab bitte ich um Korrektur)
Nichts gegen deinen Einwand, dass es die Pflege des Codes erhebelich erschwert, wenn man so arbeitet. Das ist sicher richtig. Nur bezahlt der Kunde nicht für schönen oder standartkonformen Code sondern für ein Program, eine Lib, eine Erweiterung oder was auch immer. Für den Kunden und für deinen Chef zählt das Ergebnis und die Zeit, die du gebraucht hast. Das heisst natürlich wieder nicht dass es langsamer ist standard-c++ zu schreiben. Ich sage nur, dass ich finde, dass es legitim ist sich mal nicht an den Standard zu halten wenn ich eine Grund dafür habe.
Nur dass man mich nicht falsch versteht. Ich sage hier nicht: "Los, lasst Standard Standard sein und macht wie ihr wollt.". Ich finde es nur übertrieben mit welchem Eifer hier gegen standartnonkonforme (schreibt man das so ?) Lösungen gewettert und teilweise sogar geflamed wird.
-
Die Leute haben hier Erfahrungen mit ganz verschiedenen Arten von Projekten.
Beispiel (kleines Sharewarepojekt): Ich habe an einem Tool mitgearbeitet, das auf Win32 und MacOS X laufen sollten. Wir selbst habe keinen Mac, hatten aber mehrere Angebote von anderen, die breit waren den Code für uns auf dem Mac zu kompilieren und gegebenen Falls geringfügig anzupassen. Hätten wir uns nicht an den Standard gehalten, wäre das alles nicht möglich gewesen (Wir haben ein SDK verwendet, das für alle größere Plattformen existiert, welshalb es mit speziellen für das Projekt notwendigen Features ebenfalls keine Probleme gab).
Was aber, wenn ich für einen Kunden eine Software schreiben soll und diese Software durchweg auf einem Win-PC laufen soll? Ich werde wohl kaum während des Projekts plötzlich auf die Idee kommen den Compiler zu wechseln oder ähnliches. Ich werde mit einem festen Team an dem Projekt arbeiten. Das Ausnutzen von Compiler- und/oder Plattform-Besonderheiten ist kein Problem. Ein Mehraufwand lohnt sich in der Regel nicht.
Wenn man an Open Source denkt bekommt der Standard auf einmalwieder ein ganz wichtige Rolle. Ich arbeite mit ganz verschiedenen Leuten zu sammen, die mit Verschiedenen Compilern möglicherweise auf verschiednenen Plattformen arbeiten. Wenn ich da irgendwelche Gimmiks meines Compiler ausnutze bekomme ich ganz schnell Ärger.
Dieses Forum beschäftigt sich mit ISO-C++. Eine Diskussion über irgendwelche Compilerspezifika ist genau so unpassend wie der Austausch von Rezepten für Plätzchen.
-
MeineFresse schrieb:
Meine Fresse. Ihr mit eurem lächerlichen Standard. Wie die Kleinkinder...
Habt ihr nichts wichtigeres zu tun?
Und ShadeOfMine der Oberspießer mischt kräftig mit.Mit Deinem 2. Satz sieht man Dir an, dass Du wirklich nicht viel Ahnung vom Coden hast.
Und die Sache mit Shade, wo er Recht hat, hat er Recht! Auch wenn ich oft mit ihm auf Kriegsfuß bin, aber in diesem Fall muss ich ihm Ausnahmslos zustimmen.
-
prolog schrieb:
Btw.: hast du die Analogie zum Auto fehlinterpretiert. Was zugegebenermaßen nicht schwer ist, wenn man das ganze Formal angeht. Denn wenn ich z.B.: mal den Schulterblick vergesse, klappt das zwar mit jedem Auto ist aber nicht zwingend ans Auto als Objekt gebunden, sodass dein Vergleich mit dem Programmieren nicht funktioniert. Aber das ist Haarspalterei.
Schulterblick ist eine Sichererungsmassnahme. Es entspricht somit einer Fehlerabfrage beim Programmieren. Genau so habe ich es verstanden. Wenn ich nicht auf nummer sicher gehen will, lass ich es weg. Schadet ja nicht, wenn ich mir sciher bin.
Btw.: kann ich mich an einen Thread von dir errinnern in dem du (sinngemäß) gefragt hast, wie du deine Projekte und das Management besser machen kannst, weil ihr bis dato immer nur bugs schnell gefixed habt, wobei ihr dann irgendwann die Übersicht verlohrt weil ihr einfach nicht die Zeit hattet (von Chefseite).
Exakt. Wir haben nach dem Motto "hauptsache es läuft" die Sachen implementiert - genau wie es hier vorgeschlagen wurde.
Und ich will nicht wissen, was uns das langfristig gekostet hat.
zB als wir das Authentifizierungssystem überarbeitet haben (wegen neuen Anforderungen) ging massig Zeit drauf. Und natürlich ist die Software jetzt instabiler als sie vorher war. Denn fürs neuschreiben war keine Zeit. Aber "es läuft".Nichts gegen deinen Einwand, dass es die Pflege des Codes erhebelich erschwert, wenn man so arbeitet. Das ist sicher richtig. Nur bezahlt der Kunde nicht für schönen oder standartkonformen Code sondern für ein Program, eine Lib, eine Erweiterung oder was auch immer.
Ja, aber er bezahlt auch für Erweiterungen, Bugfixes und Support. ka was du für Software entwickelst. Aber bei uns arbeite ich an dem Hauptprodukt. dh, wenn das zugrunde geht, schaut es traurig aus für uns.
Das Projekt wird solange erweitert und gewartet, bis es keine Kunden mehr gibt - oder die Prioritäten sich verschieben. Also noch mindestens ein paar Jahr.
Und dieser schlampige Stil mit dem der Code geschrieben wurde, kostet mehr als meine Arbeitszeit. Weil ich teilweise nen ganzen Tag versuchen muss zu verstehen was da verbrochen wurde um einen bugfix einzubauen. Diese kosten sind einfach enorm.
Diesen schlampigen Stil kann man nur sinnvoll verwenden wenn man keinen Support leisten muss. Und selbst dann würde ich es mir überlegen, weil schlampiger Code fehleranfälliger ist.
Ich sage nur, dass ich finde, dass es legitim ist sich mal nicht an den Standard zu halten wenn ich eine Grund dafür habe.
Über sowas wird sich hier auch niemand aufregen der Ahnung hat. Und die Trolle regen sich sowieso immer auf - egal was du machst.
Ich finde es nur übertrieben mit welchem Eifer hier gegen standartnonkonforme (schreibt man das so ?) Lösungen gewettert und teilweise sogar geflamed wird.
nö: Standard :p
Aber schau dir mal an wer flamed.
-
Ganz schön nervig die Diskussion. Dabei sind die Claims doch klar abgesteckt. Die Hobby-/Freizeitprogrammierer die das ganze aus Interesse und/oder Neugier betreiben hacken ihre Sachen solange zusammen bis es läüft (oder auch nicht), und sind damit zufrieden. Die kümmern sich um keinen Standard, warum sollten sie auch.
Jeder der seinen Lebensunterhalt jedoch damit verdient in Teamarbeit mittlere bis grosse Software-Projekte abzuwickeln, weiss wofür ein Standard da und arbeitet auch dementsprechend.
Die "Hacker" werden nie verstehen was die "Profis" mit ihrem Gefasel
vom Standard überhaupt wollen.
-
Shade Of Mine schrieb:
Exakt. Wir haben nach dem Motto "hauptsache es läuft" die Sachen implementiert - genau wie es hier vorgeschlagen wurde.
Und ich will nicht wissen, was uns das langfristig gekostet hat.
zB als wir das Authentifizierungssystem überarbeitet haben (wegen neuen Anforderungen) ging massig Zeit drauf. Und natürlich ist die Software jetzt instabiler als sie vorher war. Denn fürs neuschreiben war keine Zeit. Aber "es läuft".Nichts gegen deinen Einwand, dass es die Pflege des Codes erhebelich erschwert, wenn man so arbeitet. Das ist sicher richtig. Nur bezahlt der Kunde nicht für schönen oder standartkonformen Code sondern für ein Program, eine Lib, eine Erweiterung oder was auch immer.
Ja, aber er bezahlt auch für Erweiterungen, Bugfixes und Support. ka was du für Software entwickelst. Aber bei uns arbeite ich an dem Hauptprodukt. dh, wenn das zugrunde geht, schaut es traurig aus für uns.
Das Projekt wird solange erweitert und gewartet, bis es keine Kunden mehr gibt - oder die Prioritäten sich verschieben. Also noch mindestens ein paar Jahr.
ACK. Du hättest den Thread wohl auch nicht gestartet wenn du nicht aus gutem Grund unzufrieden damit gewesen wärst.
Shade Of Mine schrieb:
Aber schau dir mal an wer flamed.
Entweder Trolle oder genervte Standarduser.
Helper schrieb:
Ganz schön nervig die Diskussion. Dabei sind die Claims doch klar abgesteckt. Die Hobby-/Freizeitprogrammierer die das ganze aus Interesse und/oder Neugier betreiben hacken ihre Sachen solange zusammen bis es läüft (oder auch nicht), und sind damit zufrieden. Die kümmern sich um keinen Standard, warum sollten sie auch.
Jeder der seinen Lebensunterhalt jedoch damit verdient in Teamarbeit mittlere bis grosse Software-Projekte abzuwickeln, weiss wofür ein Standard da und arbeitet auch dementsprechend.
Die "Hacker" werden nie verstehen was die "Profis" mit ihrem Gefasel vom Standard überhaupt wollen.Wobei die "Codehacker" ja auch ne andren Anspruch haben. Abgesehen davon ACK.
-
da liegt ja auch das problem.
viele der sog. profi programmierer ziehen einfach über hobby programmierer her, nur weil sich diese nicht an ihren heiligen standard halten, was dem hobby coder aber echt egal is.
obs nun funktioniert oder nicht is dann schon bald egal und ein solcher thread artet in einen flame war aus.sowas sieht man in jedem durchschnittlichen programmier forum mehr als nur einmal am tag.
-
btw hab ich mal eine frage:
was sind trolle
den ausdruck hab ich in diesem forum zum ersten mal gesehn.
-
Ein Musterexemplar dieser Art findest du im Spieleforum - einfach mal TGGC zusehen und fertig
MfG SideWinder
-
Hallo,
oder schau mal hier.
-
dot schrieb:
da liegt ja auch das problem.
viele der sog. profi programmierer ziehen einfach über hobby programmierer her, nur weil sich diese nicht an ihren heiligen standard halten, was dem hobby coder aber echt egal is.
obs nun funktioniert oder nicht is dann schon bald egal und ein solcher thread artet in einen flame war aus.sowas sieht man in jedem durchschnittlichen programmier forum mehr als nur einmal am tag.
Natürlich ist es bis zu einem gewissen Grad egal. Nur irgendwann kommt bei jedem, der es halbwegs ernst mit dem Programmieren meint, der Tag, an dem er z.B. einen anderen Compiler, eine andere Bibliothek oder vielleicht sogar ein anderes Betriebssystem ausprobiert. Und wenn es dann nicht funktioniert, weil man gewisse Standards nicht kennt bzw. sich nicht daran gehalten hat (halten wollte), dann war wieder der Compiler oder der Hersteller daran Schuld.
Man sollte doch wenigstens unterscheiden können zwischen dem, was ein Compiler können muss, und was ein Compiler noch zusätzlich an Features anbietet.
-
@CarstenJ und SideWinder:
thx
-
Boah Leute was regt ihr euch denn so auf!?? Soll doch Jeder programmieren wie er will, ob standard oder nicht is doc scheissegal, wenn sein programm dann halt nur auf einem compiler läuft o.ä. isses doch sein problem oder??
Mein gott euch muss langweilig sein...
-
Die Frage ist: Willst du C++ lernen?
-
Argh! schrieb:
Boah Leute**,** was regt ihr euch denn so auf!?? Soll doch jeder programmieren wie er will, ob Standard oder nicht**,** ist doch scheissegal**.** Wenn sein Programm dann halt nur auf einem Compiler läuft o.ä., ist es doch sein Problem**,** oder??
Mein Gott**,** euch muss langweilig sein...
Ja, hast recht...
