Was ist er Unterschied zwischen (float)val und float(val)?

[asc]

Xebov schrieb:

Wurden nicht genau zu diesem Zweck die Äußerst praktischen Kommentare im Zeitlosen Design eingebaut?

Ganz ehrlich: Wenn der Code selbsterklärend ist, braucht man auch keine Kommentare. Kommentare verwende ich beispielsweise im Header um die Schnittstelle zu beschreiben, wenn ich Code selber erklären muss, ist dies eher ein Zeichen dafür das ich den Code umschreiben sollte.

Ein C++ Cast mag zwar kryptischer aussehen, sagt aber weit mehr als ein C-Style Cast aus.

[Xebov]

asc schrieb:

Ganz ehrlich: Wenn der Code selbsterklärend ist, braucht man auch keine Kommentare. Kommentare verwende ich beispielsweise im Header um die Schnittstelle zu beschreiben, wenn ich Code selber erklären muss, ist dies eher ein Zeichen dafür das ich den Code umschreiben sollte.

Das sehe ich nicht ganz so, ichs chreibe oft und gern Komentare rein die selbst bei selbsterklärendem Code nochmal ein paar Worte aussagen über das was man sich dabei egdacht hat, doer was da passiert. Gerade wenn es Berechnungen sind die etwas komplexer sind kann der Code wenn man ihn schreibt selbsterklärend sein udn 2 Wochen später weiß man trotzdem nichtmehr wieso man es ausgerechnet so gemahct hat. Und da Kommentare nichts kosten solte man auch nicht zu sparsamm damit sein.

[Dravere]

@Xebov,
Siehe Beitrag von asc.

Xebov schrieb:

Was die C-Casts generell angeht ich verwende zzt nur die und hatte bisher nicht einen Cast der nicht genau da sgetan hat was ich wollte.

Bis du mal die Typen im Hintergrund veränderst, zum Beispiel weil es Templates sind, aber vergisst auch die Casts zu prüfen
Ein C++ Cast gibt bei falscher Verwendung sofort ein Fehler aus.

Zu den Kommentaren:
Ein Algorithmus kommentiere ich auch, aber dann meistens zu Beginn einer Funktion und nicht in der Funktion. Eine zu starke Vermischung von Code und Kommentaren kann auch hinderlich sein.
Zudem, kommentierst du wirklich immer alles? Ich kenne viele, welche das zwar gerne tun würden, schlussendlich trotzdem über 50% nicht richtig kommentieren

Grüssli

[Tachyon]

Xebov schrieb:

...Und da Kommentare nichts kosten solte man auch nicht zu sparsamm damit sein.

Dann frage ich mich, wieso Du noch C-Casts einsetzt. C++-Casts sind lesbarer, sicherer und kosten ebenfalls nichts.

//Variante1:
index_t index = middle_index + static_cast<index_t>(floating_index) + static_cast<index_t>(fractional_samples);
//Variante2
index_t index = middle_index + (index_t)floating_index + (index_t)fractional_samples;

Blödes Beispiel aber:
Da heute so ziemlich jeder Editor Syntaxhervorhebung hat, ist Variante 1 klar im Vorteil.

[Mitleid]

@Dravere + asc zu const_cast
Da fallen mir aber gleich mehrere Beispiele ein, wo es doch Sinn macht und überhaupt nichts mit Designfehler oder C zu tun hat.

Hapt ihr euch z.B. schon mal Meyers Vorschlag zur Vermeidung von doppeltem Code beim []-Operator angesehen? Ziemlich am Anfang seines Buches in dem von camper damals kritisierten Kapitel: Item 3 "Use const whenever possible".

Nicht sinnvoll in euren Augen? Designfehler? Ich glaube nicht ...

[Xebov]

Dravere schrieb:

Zudem, kommentierst du wirklich immer alles? Ich kenne viele, welche das zwar gerne tun würden, schlussendlich trotzdem über 50% nicht richtig kommentieren

Ich kommentiere auch nicht 100%ig alles, aber ich kommentiere auch in Funktionen zB vor eienr Schleife ne Info was sie tut, oder bei Berechnungen ne Info was da Berehcnet wird und wieso ausgerechnet so. In den meisten meienr Codes kann man sich eigentlich mit den Kommentaren an die Stelle hangeln die man sucht weil immer da steht was der darunterstehende Code tut.

daraus:

void func()
{
    int a;
    int b;
    int c;
    func2();
    a=b+c;
};

würde bei mir ca das hier werden:

//Beschreibung der Funktion
//Exceptionangaben
void func()
{
    //Variablen holen
    int a;
    int b;
    int c;
    //Funktionsaufruf (warum)
    func2();
    //Berechnung für....
    a=b+c;
};

Wobei ich die Beschriftung ind en funktionen so meist nur bei Komplexeren Sachen amche und nicht bei mini Funktionen.

Tachyon schrieb:

Blödes Beispiel aber:
Da heute so ziemlich jeder Editor Syntaxhervorhebung hat, ist Variante 1 klar im Vorteil.

Naja Blöd is das Beispiel nciht, sie stechen halt direkt durch die etwas aus der Reihe tanzende Form ins Auge.

[asc]

Mitleid schrieb:

Hapt ihr euch z.B. schon mal Meyers Vorschlag zur Vermeidung von doppeltem Code beim []-Operator angesehen?...
Nicht sinnvoll in euren Augen? Designfehler? Ich glaube nicht ...

Das Meyer-Beispiel war es auch warum ich "wobei es auch in reinen C++ Programmen durchaus seltene Anwendungsfälle geben kann" geschrieben habe => Mit Ausnahme dieses einen Beispieles (was nun wirklich kein Standardfall ist), ist mir persönlich const_cast im reinen C++ Code nämlich tatsächlich nur bei Designfehlern und C-Schnittstellen untergekommen.

cu André

[asc]

Xebov schrieb:

würde bei mir ca das hier werden:

Bis auf die einleitenden (Doxygen-) Kommentare inklusive Parameterbeschreibungen... [Die ich aber grundsätzlich nur im Header mache => Schnittstellenbeschreibung] kommentiere ich inzwischen nur noch an Stellen wo es bedingt durch das verwendete Framework Erklärungsbedarf gibt.

Xebov schrieb:

Tachyon schrieb:

Blödes Beispiel aber:
Da heute so ziemlich jeder Editor Syntaxhervorhebung hat, ist Variante 1 klar im Vorteil.

Naja Blöd is das Beispiel nciht, sie stechen halt direkt durch die etwas aus der Reihe tanzende Form ins Auge.

Worin ich einen Vorteil sehe: Ich möchte Konvertierungen sehen.

[Shade Of Mine]

Xebov schrieb:

Wurden nicht genau zu diesem Zweck die Äußerst praktischen Kommentare im Zeitlosen Design eingebaut?

Nein.

Unleserlichen und Fehleranfälligen Code tut man nicht schreiben und dann kommentieren, sondern gleich richtig machen.

Die C Casts sind nur faulheit, mehr nicht. Gibt 1000 Gründe gegen sie...

[Scarabol]

ui, ui, ui, scheint als hätte ich ein heißes Thema angeschnitten, also von mir noch als Anfänger eine Frage zum saueberen Code Aufbau:

Wenn ich eine long Variable als String an eine Funktion übergeben muss, wie schreibe ich das am besten? definiere ich zunächst einen neuen String alla:

std::string str = "";
str += long;
func(str);

Oder haue ich das platzsparend direkt in den Funktionsaufruf?

func(string(long)); // Ich weiß kein C++ Cast, aber ich weiß NOCH nicht wies geht :-) schaue es mir aber gleich im Anschluss an diesen Post an...

Gruß
Scarabol

[Gast]

asc schrieb:

wenn ich Code selber erklären muss, ist dies eher ein Zeichen dafür das ich den Code umschreiben sollte.

Oder dass du nur triviale Themen bearbeitest.

[Dravere]

Scarabol schrieb:

Oder haue ich das platzsparend direkt in den Funktionsaufruf?

Du schreibst nicht in COBOL, du hast Platz, verwende ihn, um deinen Code lesbarer zu machen.

Und für Zahl <-> String:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-39488.html

Grüssli

[Xebov]

Scarabol schrieb:

ui, ui, ui, scheint als hätte ich ein heißes Thema angeschnitten

Nein so heiß is das Thema nicht, das ist normal. Bei den Leuten gehen die Meinungen was C Sachen in C++ Code angeht etwas auseinander.

[_matze]

Tachyon schrieb:

_matze schrieb:

...kein Problem, solange man weiß was man tut.

Tust da aber anscheinend oft nicht, wenn man sich Deinen Code und Deine Beispiele so anguckt.

Ach ja? Kann es zufällig sein, dass du damit eben jene Fälle meinst, in denen ich auch gerne mal C-Casts, C-Funktionen etc. verwende? Denn das sind die einzigen, bei denen ich mich an Kritik von dir erinnere. Wir haben hier sowieso viel C-Kram, da schwappt das eben auch in den C++-Source rüber. Und in vielen Fällen gibt es daran auch nichts auszusetzen. Ich bin halt keiner dieser C++-Puristen. Das wird in unserer Firma nicht so gehandhabt, und ich halte es auch nicht für nötig. Gerade bei den Casts.

Und ich nutze z.B. auch ausgiebigst sprintf, da die Handhabung einfach so praktisch und die Notation so schön kompakt ist. Sorry, falls ich dich gerade geschockt habe. Solange man keine (nicht nullterminierten) Strings im Formatstring einfügt, gibt es daran vermutlich auch nichts auszusetzen...

...außer natürlich, dass es die Funktion schon in C gab. Das ist natürlich ein Todesurteil, die Verwendung plötzlich unverzeihlich...

asc schrieb:

Ganz ehrlich: Wenn der Code selbsterklärend ist, braucht man auch keine Kommentare. Kommentare verwende ich beispielsweise im Header um die Schnittstelle zu beschreiben, wenn ich Code selber erklären muss, ist dies eher ein Zeichen dafür das ich den Code umschreiben sollte.

Sorry, aber wenn du wirklich (fast) nur in Headern kommentierst, dann machst du in meinen Augen was falsch. Vielleicht hängt es auch von der Thematik des Codes ab, ich weiß ja nicht was du machst. Aber bei vielen Dingen finde ich Kommentare sinnvoll und hilfreich, für andere wie auch für mich. Denk doch an komplexe Algorithmen, oder Kommunikation mit irgendwelcher Hardware, oder wasweißich. Sowas sollte man nicht unkommentiert da stehen lassen. Vielleicht liest das ja mal einer, der einfach nicht alle aufgerufenen Funktionen kennt. Der kann sich natürlich Stück für Stück mühsam durch die Hilfe ackern, um einen groben Überblick zu bekommen... oder er liest die Kommentare, die ein lieber Programmierer für ihn verewigt hat.

Nee, Kommentare finde ich schon wichtig (und das hat sicher nix mit meinem unleserlichen C-Code zu tun ). Mann sollte es nicht übertreiben, aber das grobe Verständnis des Ablaufs kann man anderen und sich später erleichtern.

EDIT: Kleiner Nachschlag zu den Kommentaren. Ich muss gerade an den heutigen Arbeitstag denken. Ich habe den ganzen Tag versucht (und es jetzt auch größtenteils geschafft), bestehenden Code eines ehemaligen Mitarbeiters in meinen zu packen. Da gehts um komplexe Bildkorrekturen, alles sehr kryptisch, ellenlang, wirklich verdammt lang, und eben nicht auf Anhieb verständlich. Und der Sack hat nicht eine Zeile Kommentar hinterlassen! Wären die Abläufe zumindest teilweise kommentiert gewesen, hätte mir das sicher in paar Stunden erspart...

[asc]

_matze schrieb:

Ganz ehrlich: Wenn der Code selbsterklärend ist, braucht man auch keine Kommentare. Kommentare verwende ich beispielsweise im Header um die Schnittstelle zu beschreiben, wenn ich Code selber erklären muss, ist dies eher ein Zeichen dafür das ich den Code umschreiben sollte.

Sorry, aber wenn du wirklich (fast) nur in Headern kommentierst, dann machst du in meinen Augen was falsch. Vielleicht hängt es auch von der Thematik des Codes ab, ich weiß ja nicht was du machst.[/quote]

Ich dokumentiere viel, doch ich dupliziere keine Kommentare. Und zum Nachschlagen was eine Klasse macht ist die Schnittstelle der Richtige weg - daher steht die Dokumentation auch genau dort (Zudem durch Doxygen natürlich auch auf den Server als HTML bereit).

Meine Thematik ist in der Tat eher trivial als komplex (ich würde sagen 80% des Codes ist einfache Anwendungslogik), das heißt aber nicht das es nicht auch Bereiche höherer Komplexität im Programm gibt. Doch ich kommentiere dann lieber durch das Aufgliedern des Codes in kleine sinnvoll benannte Teilfunktionalitäten, als durch Kommentare in der Implementierung (die ich zwar von Zeit zu Zeit auch mache, aber tendenziell sehr selten).

_matze schrieb:

Aber bei vielen Dingen finde ich Kommentare sinnvoll und hilfreich, für andere wie auch für mich.

Oh, da gebe ich dir völlig recht, doch wie gesagt Kommentiere ich lieber an einer Stelle - mag auch sein das meine Kommentarmenge andere enttäuschen würde, nur im Vergleich zu allen anderen Entwicklern die ich bislang in Projekten begegnet bin, Kommentiere ich eher zu viel als zu wenig (In den 4 Jahren die ich an einem 15 jährigen Projekt mitgearbeitet hatte, waren am Schluss ca. 98% der Kommentare von mir erstellt - und ich habe dort meines Erachtens noch zu wenig kommentiert).

Ja, komplexe Algorithmen etc. sind in den bisherigen Projekten eher die Seltenheit gewesen, aber auch dort habe ich lieber Funktionen gesplittet und benannt.

_matze schrieb:

...außer natürlich, dass es die Funktion schon in C gab. Das ist natürlich ein Todesurteil, die Verwendung plötzlich unverzeihlich...

Ich verteufel an sich nicht die C-Funktionen insgesamt (auch wenn ich gerade durch sehr schlechte Vorerfahrungen in einigen Projekten gerade die Ellipsen wie sprintf & Co tatsächlich als Problem ansehe), was ich aber anders sehe ist wie gesagt die Reihenfolge für jemanden der C++ lernt.

Und auch wenn ich nicht über alle C++ Konstrukte froh bin, so halte ich es für sinnvoller jemanden der C++ lernt auch vorwiegend den C++ Ansatz beizubringen. In den Fällen, wo der Ansatz nicht ideal war, kann man dann noch immer nachbessern.

cu André

[C++fan 2009]

asc schrieb:

Und auch wenn ich nicht über alle C++ Konstrukte froh bin, so halte ich es für sinnvoller jemanden der C++ lernt auch vorwiegend den C++ Ansatz beizubringen.

Zeig ihm einen einfachen, sinnvollen Ansatz. Egal ob C oder C++.
Matze: Deine Sichtweise ist ok!

[_matze]

C++fan 2009 schrieb:

Zeig ihm einen einfachen, sinnvollen Ansatz. Egal ob C oder C++.

Vermutlich der klügste Satz dieses Threads...

[volkard]

Jup. Vielleicht sogar der klügste Satz im ganzen Forum heuer.

[Dravere]

Hey, wo bleibt die Gegenpartei? Ich warte auf ein:
"Jup. Vielleicht sogar der dümmste Satz im ganzen Forum heuer."

Naja, jetzt habe ich es schon getan :p
Sagt mal, statt immer wieder so sinnlose Sätze zu formulieren, können wir uns nicht einfach darauf einigen, dass wir uns uneinig sind?

Grüssli

[Xebov]

Dravere schrieb:

können wir uns nicht einfach darauf einigen, dass wir uns uneinig sind?

Naja das man sich bei solchen themen nie einig wird dürfte ja eh kalr sein, hier prallen einfach zuviele verschiedene Erfahrungen aufeinander als das man solche Themen auf einen Punkt bringen könnte.