C++ cast Operatoren

Jockelx

Tachyon schrieb:

Es geht nicht nur um Wiederfindbarkeit.

Doch, offenbar schon. Ich hab nicht die C++-Casts hinterfragt, sondern dieses komische Wiederfind-Argument.

hustbaer

Stefan schrieb:

Also wenn die IDE regex-Suche hat, sollte man die C-Casts problemlos finden. Da ist die Schreibweise kein Argument.

Dann poste doch bitte mal ne Regex mit der man alle C-Style Casts finden kann. Natürlich ohne massiv viele false-positives zu bekommen. Ich wäre dir sehr dankbar dafür. Wäre ein nützliches Werkzeug beim Refactoring von altem Code.
Ich kenne auf jeden Fall keine solche Regex. Ich wüsste auch nicht wie man eine schreiben sollte.

Und das hier ist doch wohl ein Konstruktor-Aufruf und kein cast:
double(3);

Nope, das ist ein Cast. Lies es im Standard nach wenn du es nicht glaubst.

Damit kann man auch ganz böse Dinge machen:

typedef int* pint;
char const* str = "lala";
int* i = pint(str); // castet const weg + char* nach int*

Gerade weil er so harmlos aussieht, wie ein ganz unschuldiger ctor Aufruf eben, finde ich den "function style" Cast auch so schlimm.

hustbaer

Jockelx schrieb:

Hast du das denn wirklich mal gebraucht?
Für mich hört sich dieses Wiederfindbarkeits-Feature irgendwie konstruiert an.
Ich hab's zumindest niemals nutzen müssen und daran wird sich auch ziemlich sicher nichts ändern.

Ich hatte schon öfters Fälle, in denen ich gerne nach Casts gesucht hätte.
Speziell reinterpret_cast und const_cast.

Nach C-Style Casts und Function-Style Casts würde ich deswegen gerne suchen können, damit ich sie als xxx_cast umschreiben kann. Damit sichtbarer ist was passiert, und damit ich in weiterer Folge dann nach den potentiell problematischen Casts wie eben reinterpret_cast und const_cast suchen kann.

Und zur Frage warum man nach Casts suchen wollen würde: z.B. einfach um beim Bug-Hunting gewisse Dinge vorab kontrollieren und idealerweise ausschliessen zu können.

__Stefan__

@hustbaer

In codeblocks geht's so:

(\w+).+

Ich gebe zu, es ist nicht 100% zuverlässig

Michael E.

Hast du etwa nie Funktionen mit nur einem Parameter?

BTW: Kennt CodeBlocks keine Gruppierungen oder warum musst du die Klammern nicht escapen?

__Stefan__

Michael E. schrieb:

Hast du etwa nie Funktionen mit nur einem Parameter?

BTW: Kennt CodeBlocks keine Gruppierungen oder warum musst du die Klammern nicht escapen?

Sobald du noch den Parameternamen mit einem space hast, ignoriert er es ja. Den Regex typ kann man in Codeblocks umstellen.

volkard

Jockelx schrieb:

Für mich hört sich dieses Wiederfindbarkeits-Feature irgendwie konstruiert an.
Ich hab's zumindest niemals nutzen müssen und daran wird sich auch ziemlich sicher nichts ändern.

Geht mir genauso.

Michael E.

Stefan schrieb:

Sobald du noch den Parameternamen mit einem space hast, ignoriert er es ja.

Also müsste ich jedes Mal in einer Argumentliste noch ein Leerzeichen schreiben? Ich glaube, das machen die Wenigsten.

hustbaer

Stefan schrieb:

@hustbaer

In codeblocks geht's so:
(\w+).+
Ich gebe zu, es ist nicht 100% zuverlässig

Ja, sowas kann ich mir auch selbst basteln.

foo((TypeA::TypeB) x); // cast
bar((std::min)(a, b)) // kein cast, nur seltsame schreibweise um verwechslung mit dem #define min zu verhindern
baz((typename X<T>::Y)(123 * 234)) // cast
// ...

Stefan schrieb:

Ich gebe zu, es ist nicht 100% zuverlässig

Es geht nicht nur ums Suchen. Wenn ich im Quellcode stöbere und const_cast sehe, werde ich erst mal aufmerksam und erkenne, dass hier eine potenzielle Gefahrenquelle lauert und denke vielleicht sogar über Alternativen nach. Wenn hingegen ein C-cast vorkommt, dessen primäre Aufgabe eigentlich nicht im const-wegcasten besteht, ist das schon viel mühsamer, besonders bei der Bugsuche.

TyRoXx

Finder (nicht Sucher) schrieb:

Stefan schrieb:

Ich gebe zu, es ist nicht 100% zuverlässig

Es geht nicht nur ums Suchen. Wenn ich im Quellcode stöbere und const_cast sehe, werde ich erst mal aufmerksam und erkenne, dass hier eine potenzielle Gefahrenquelle lauert und denke vielleicht sogar über Alternativen nach. Wenn hingegen ein C-cast vorkommt, dessen primäre Aufgabe eigentlich nicht im const-wegcasten besteht, ist das schon viel mühsamer, besonders bei der Bugsuche.

Es ist alles gesagt worden. Wer die Vorteile erkennt, nimmt eben die längere Schreibweise und wer an C hängt, macht es eben weiterhin so.

volkard schrieb:

Jockelx schrieb:

Für mich hört sich dieses Wiederfindbarkeits-Feature irgendwie konstruiert an.
Ich hab's zumindest niemals nutzen müssen und daran wird sich auch ziemlich sicher nichts ändern.

Geht mir genauso.

Ich find die "neuen" einfach besser zu lesen. Bei meiner Arbeit hab ich viel mit fremdem Code zu tun, da weiß ich meistens (leider nicht immer) schneller, was der Entwickler "vor mir" gemeint hat.

volkard

TyRoXx schrieb:

Es ist alles gesagt worden. Wer die Vorteile erkennt, nimmt eben die längere Schreibweise und wer an C hängt, macht es eben weiterhin so.

OK, das ist ein Grund gegen C-Casts. Aber nicht gegen functional-style C++-Casts. Das klingt wie wenn jemand wiedermal sagt, char-Arrays seien kein C++, weil es std::string gibt.

Die langen Casts werden im Editor blau und haben größte Signalwirkung. Das ist bei const_cast oder reinterpret_cast oder dynamic_cast auch erwünscht. Aber bei static_cast nicht! Da ist es nur blödes Rauschen, was den Lesefluß senkt und beim Debuggen nur stört.

Deswegen nehme ich bei trivialen Casts wir von double nach int wie

putPixel(mx+r*cos(phi),mx+r*sin(phi),red);

sicher nur den Functional-Style-Cast

putPixel(int(mx+r*cos(phi)),int(mx+r*sin(phi)),red);

und nicht den langen langen

putPixel(static_cast<int>(mx+r*cos(phi)),static_cast<int>(mx+r*sin(phi)),red);

Den static_cast nehme ich, wo ein Trick dabei ist, wenn ich mich auf ein Versprechen verlasse, das an anderer Stelle im Code gegeben wurde, zum Beispiel Downcasts in der Klassenhierarchie.

asc

Jockelx schrieb:

Hast du das denn wirklich mal gebraucht?
Für mich hört sich dieses Wiederfindbarkeits-Feature irgendwie konstruiert an.
Ich hab's zumindest niemals nutzen müssen und daran wird sich auch ziemlich sicher nichts ändern.

Ich habe es mal massiv vermisst, in einen sehr großen Projekt. Irgendwann wurden Umrechnungsfehler gefunden (die aber schon seit langen enthalten waren), und wir mussten fast das gesamte Projekt umwühlen (noch dazu in einer Konstellation wo auch der Debugger nicht sauber lief). Hintergrund waren einige C-Style Casts die verdammt schwer zu finden waren (u.A. auch wegen den alternativen Steibweisen int(...), (int)... und weil sie auch vielen Funktionsdeklarationen in dem Projekt ähnlich sahen.

Wenn du einmal ein Projekt mit etwa 1 Millionen Codezeilen durchsuchen musstest, und dir zudem der Debugger nicht viel weiterhilft, wirst du danach nicht mehr von "konstruierten" Featuren sprechen.

Die Fehlersuche hat mehr als eine Woche gedauert, und ob diese Konvertierungen wirklich die einzig problematischen waren, sei dahin gestellt.

volkard

asc schrieb:

Hintergrund waren einige C-Style Casts die verdammt schwer zu finden waren (u.A. auch wegen den alternativen Steibweisen int(...), (int)...

Der Functional-Style-Cast ist immer noch kein C-Style-Cast.
Wie soll man solche Postings denn ernst nehmen? Ihr macht es mir schon recht schwer.

volkard

asc schrieb:

Wenn du einmal ein Projekt mit etwa 1 Millionen Codezeilen durchsuchen musstest, und dir zudem der Debugger nicht viel weiterhilft, wirst du danach nicht mehr von "konstruierten" Featuren sprechen.

ex falso quod libet.
Es bleibt für mich ein Problem Anderer Leute.

Ad aCTa

Ich stimme Volkard zu.

const_cast: Absolut spitze
dynamic_cast: Super
reinterpret_cast: Brauch ich im Low-Level oft, besser als die alten Casts, da es auch auf Äquivalenzen von Handles o.ä. hinweist
static_cast: Manchmal ganz dolle, wenn ich z.B. void*s umcaste nutze ich ihn immer, aber oft sieht ein Functional-Cast einfacher besser aus (wegen Konstruktor-Ähnlichkeit) o. ich belasse es sogar bei impliziten Typenkonvertierungen, um die Lesbarkeit der Codelogik zu verbessern. Die alten Casts übernehmen bei mir nur das, was auch nur ein static_cast hätte tun können.

Michael E.

Ad aCTa schrieb:

dynamic_cast: Super .

Da hier alle vom dynamic_cast schwärmen: Habt ihr den jemals gebraucht?

Biolunar

Ja. Stichwort: Multiple Dispatching.

volkard

Michael E. schrieb:

Ad aCTa schrieb:

dynamic_cast: Super .

Da hier alle vom dynamic_cast schwärmen: Habt ihr den jemals gebraucht?

Natürlich habe ich das! Um den Typ festzustellen und dann per if je nach Typ...
~
Muß ich das wirklich noch weiter ausführen?
Es ist doch schon jahrelang her.
Ich war jung und brauchte das Geld!
Haben wir nicht alle schon mal...
So haben es damals aber alle gemacht.
~