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

Shade Of Mine

oder man verwendet keine sinnlose UN und macht reinterpret

ist ein smartpointer ein zeiger?

Tachyon

_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.

Dravere

_matze schrieb:

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

Weisst du das auch, wenn du nach einem Jahr plötzlich wieder an dem Code rumschrauben musst? Oder wenn du ihn jemand anderem übergeben musst, damit der daran weiterarbeitet?
Den aktuellen Code kennt man meistens immer bis ins Detail. Wenn man ihn später aber nochmals bearbeitet mit einer Pause dazwischen, dann ist es wichtig, dass man den Code noch einwandfrei verstehen kann.

Durch das verwenden von C++ Casts kannst du dir selber helfen, Dinge im Code hervorzuheben, bzw. als nicht weiter wichtig abzutun.
Ein static_cast kann meistens schnell überflogen werden.
Ein dynamic_cast ist über C Cast gar nicht möglich
Ein reinterpret_cast erfordert höhere Aufmerksamkeit.
Ein const_cast deutet auf Designfehler hin :p

Grüssli

Badestrand

Ich find's als Konstruktor recht nett, wenn's risikolos und "logisch" ist

int i = ...;
double s = sin( double(i) );

Dravere schrieb:

Ein const_cast deutet auf Designfehler hin :p

Begründung?

Dravere

Mitleid schrieb:

Dravere schrieb:

Ein const_cast deutet auf Designfehler hin :p

Begründung?

Weil etwas konstantes konstant sein soll und nicht plötzlich beschrieben werden muss. Wenn das Objekt beschrieben werden muss, dann sollte es von Anfang an nicht konstant sein. Notfalls gäbe es noch das Schlüsselwort mutable , wobei auch mutable mit bedacht eingesetzt werden sollte. Meistens ist es nicht nötig. Ein berechtigte Verwendung von const_cast , habe ich bisher noch nicht gesehen.

Grüssli

asc

Mitleid schrieb:

Dravere schrieb:

Ein const_cast deutet auf Designfehler hin :p

Begründung?

const_cast darf man nur Verwenden wenn das gecastete Objekt eigentlich konstant ist (eine Änderung liefert ein undefiniertes Verhalten), aber man nicht "const-correct" programmiert hat. Eigentlich sollte bei sauberer Programmierung const_cast nur selten oder garnicht vorkommen (und zumeist nur an Stellen, wo man auf eine C-Schnittstelle zugreift; wobei es auch in reinen C++ Programmen durchaus seltene Anwendungsfälle geben kann).

Xebov

_matze schrieb:

Endlich mal Unterstützung! Die bekommt man sonst nur von fricky...

Keine Ursache.

Dravere schrieb:

Weisst du das auch, wenn du nach einem Jahr plötzlich wieder an dem Code rumschrauben musst? Oder wenn du ihn jemand anderem übergeben musst, damit der daran weiterarbeitet?
Den aktuellen Code kennt man meistens immer bis ins Detail. Wenn man ihn später aber nochmals bearbeitet mit einer Pause dazwischen, dann ist es wichtig, dass man den Code noch einwandfrei verstehen kann.

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

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.

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.

@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

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