C++ cast Operatoren

__Stefan__

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

Michael E.

Biolunar schrieb:

Ja. Stichwort: Multiple Dispatching.

Ist Dispatching per dynamic_cast nicht ziemlich out? Siehe volkard.

volkard

Michael E. schrieb:

Biolunar schrieb:

Ja. Stichwort: Multiple Dispatching.

Ist Dispatching per dynamic_cast nicht ziemlich out? Siehe volkard.

Single Dispatching per dynamic_cast ist sogar eine Sünde.
Double-Dispatching per dynamic_cast eigentlich auch.
Triple-Dispatching habe ich noch nie gebraucht, vielleicht ist es da angemessen. Nee, kann ja nicht. Da muß man langsam anfangen und Hashtables oder sowas nehmen und braucht einen int als Typidentifizierer, den macht man natürlich herkömmlich per virtual int getTypeID() oder per return reinterpret_cast<int*>(this);//liest bei MSVC den vptr, hihi

Ad aCTa

> reinterpret_cast<int*>(this);//liest bei MSVC den vptr, hihi

xD Echt?