![]() |
Re: [C++] Pointer-Problem: illegal indirection
Zitat:
Code:
kommentiert. Seltsamerweise habe ich ein paar Tage später (wenn ich so drüber nachdenke, es war heute) Code von jemand anderem gesehen, der auch auf seltsame Weise Gebrauch von diesem Operator machte.
// HERE BE DRAGONS
Aber so ist das eben. Der Sprache selbst fehlen so viele praktische und heutzutage selbstverständliche Features, dafür hat sie so viele obszöne und esoterische Features, dass man damit fast alles machen kann, auch Dinge hinzufügen, die so nie vorgesehen waren, oder sich etwas syntaktische Vereinfachung verschaffen, indem man sie zweckentfremdet. Aber das lässt man lieber andere machen. |
Re: [C++] Pointer-Problem: illegal indirection
Zitat:
Vom Überladen würde ich auch die Finger lassen, bis du einen guten Grund findest. Wenn du nicht unbedingt mathematisch orientierte Klassen schreibst (für die auch nur die arithmetischen Operatoren zu überladen wären, und das ist ja noch im Rahmen), wirst du das ohnehin kaum selbst machen müssen. Für die meisten Szenarien, in denen eine Überladung weiterer Operatoren sinnvoll wäre, gibt es in der STL (und natürlich in Boost) schon fertige Implementationen. Daß man ->, [] und das unäre * überladen kann, ist übrigens für Iteratoren und Smart-Pointer essentiell. Letztere sind übrigens, wenn sinnvoll eingesetzt, so bequem wie ein Garbage-Collector, ohne mit dessen Nachteilen behaftet zu sein ;) Es gibt allerdings tatsächlich einige Operatoren, die man nie überladen sollte, z.B. &&, || und , . Weiß der Geier, weshalb die Möglichkeit überhaupt besteht. Und verkettete Listen indiziert man nicht einmal in C++ ;) Zitat:
Zitat:
|
Re: [C++] Pointer-Problem: illegal indirection
Zitat:
Zitat:
|
Re: [C++] Pointer-Problem: illegal indirection
Zitat:
Zitat:
|
Re: [C++] Pointer-Problem: illegal indirection
Nein, boost::format verwendet den Modulo-Operator dafür. Nach dem Motto
Code:
Hat interessante Vorteile, speziell im Vergleich zu Stream-Operatoren oder dem QString::arg() (oder, davon abgesehen, gegenüber printf). Ist in meinen Augen aber noch mehr zweckentfremdet.
boost::format("%1%, %2%") % "Hallo" % "Welt"
|
Re: [C++] Pointer-Problem: illegal indirection
Ich weiß nicht was ihr alle gegen einen []-Operator bei verketteten Listen habt. Man muss doch nicht bei jedem Zugriff die ganze Kette durchlaufen. :)
Code:
Den Such-Zeiger in der Liste muss man ja nicht jedes mal wieder an den Anfang setzen.
TStringList strl;
strl.add("Hallo"); strl.add("Welt"); for(int i = 0; i<strl.count(); i++) cout<<strl[i]<<"\n"; Aber kann schon sein, dass es bei verketteten Listen nicht benutzt wird. Ein anderes Beispiel, wo es sicher benutzt wird, wäre zum Beispiel eine Klasse für Vektor-Berechnungen. v3 = v1 + v2; anstatt v3 = v1.add(v2); |
Re: [C++] Pointer-Problem: illegal indirection
Da wäre das Komma doch passender gewesen.. *g*
|
Re: [C++] Pointer-Problem: illegal indirection
Zitat:
boost.serialization verwendet auch <<, >> und & für das Streamen eines Wertes :shock: |
Re: [C++] Pointer-Problem: illegal indirection
Naja, printf ist halt nicht zu gebrauchen, wenn man eine Anwendung international gestalten will, unterstützt keine benutzerdefinierten Typen und auch keine umgeleiteten Streams. Damit ist es zumindest für meinen Entwickleralltag vollkommen nutzlos. Streams sind, was Internationalisierung betrifft, natürlich auch nicht zu gebrauchen. Praktischerweise kann man boost::format aber in Streams schieben.
Hmm. Wenn ich so drüber nachdenke... DESHALB hat man wohl die Shift-, sprich Schiebe-Operatoren dafür benutzt... um Dinge in den Stream hineinzuschieben :wall: Was DAX' scherzhafte Bemerkung zum Kommaoperator angeht: Ich tippe mal, dass das auch der erste Gedanke der Boost-Leute war. Blöderweise kann man dann einen format-Aufruf nicht als Parameter übergeben, weil das Komma dann als Parameter-Trenner statt als Operator interpretiert wird. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:49 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz