Guter Stil in C++

[groovemaster]

MaSTaH schrieb:

Komisch, du korrigierst einen offensichtlichen Flüchtigkeitsfehler und sagst nachher die Kristallkugel ist in Reparatur? Des check i net!

Mir ging es keineswegs darum, kingruedi einen Fehler unter die Nase zu reiben. Ich wollte einfach nur wissen, was richtig ist. Und da es mehrere Korrekturmöglichkeiten gibt, war ich mir nicht sicher. Aber offensichtlich haben hier einige Leute mächtig Spass daran, auf solchen Dingen rumzureiten. Wenn's für dich so offensichtlich ist, wieso hast du's nicht denen, für die es das nicht ist, einfach mitgeteilt? Und wenn du dir die Beiträge mal genauer durchgelesen hättest, hättest du gemerkt, dass der Codeschnipsel jetzt eh nicht mehr von Bedeutung ist, da die Absicht der Aussage geklärt ist (denk ich zumindest).

Optimizer schrieb:

Und findest du das jetzt guten Stil?

groovemaster schrieb:

Hier nur mal so als schlechtes Beispiel

Wer lesen kann, ist klar im Vorteil.

otze schrieb:

was meinste, was ich mit den pointern meinte? na? richtig, genau das, was du jetzt gemacht hast.

Du hast aber mit deiner Aussage impliziert, dass jemand Zeiger mit Referenzen gleichsetzt. Und das ist in dem Codebeispiel nicht der Fall.

[Gast]

Nein hat er nicht. Vielleicht solltest du selber mal anfangen, besser zu lesen. Die Frage ist, ob das sinnvoll ist, was du da mit den Referenzen gemacht hast.
Was du wiederum als Antwort darauf gepostet hast, dass man Referenzen nicht löschen kann. Was zwar natürlich so nicht stimmt, aber man macht es trotzdem nicht. In so einem Fall ist ein Zeiger angebrachter, weil ein Zeiger gemeint ist, wie es volkard so schön gesagt hat. Dein Code hat den Eindruck erweckt, es ist super, zeiger hinter referenzen zu verstecken und dann auf umwege doch wieder das Objekt zu deleten.
Aber das ist kein guter Stil. Ob du jetzt diese Ansicht vertrittst oder nicht, ist mir nicht klar geworden und mir auch ziemlich egal. Aber dein Code mit delete &myReference ist auf jeden Fall kritikwürdig und um nichts anderes geht es.

[Walli]

groovemaster schrieb:

Aber offensichtlich haben hier einige Leute mächtig Spass daran, auf solchen Dingen rumzureiten. Wenn's für dich so offensichtlich ist, wieso hast du's nicht denen, für die es das nicht ist, einfach mitgeteilt?

Schon gut, reg dich ab... Wir haben aneinander vorbei geredet.

[groovemaster]

Optimizer schrieb:

Nein hat er nicht.

Und wie liest du dann

otze schrieb:

wenn du mit tricksen pointer meisnt, dann sind das immernoch keine referenzen

?

Optimizer schrieb:

Die Frage ist, ob das sinnvoll ist, was du da mit den Referenzen gemacht hast.

Und die Antwort darauf hab ich ja auch schon gegeben. Aber für dich sag ich es nochmal ganz ausführlich: N-E-I-N

Optimizer schrieb:

Was du wiederum als Antwort darauf gepostet hast, dass man Referenzen nicht löschen kann.

Nee, ich hab das als Antwort auf

otze schrieb:

referenzen können nicht auf den nächsten speicherbereich inkrementiert werden

gegeben, und dachte eigentlich, dass das aus dem Beitrag hervorgeht.

Optimizer schrieb:

Aber dein Code mit delete &myReference

könntest du mir mal auf die Sprünge helfen, wusste gar nicht, dass ich sowas gepostet hab...

[Gast]

Gut, es ging ums inkrementieren, nicht ums löschen. Ich hab da nicht extra noch mal nachgesehen.

Und die Antwort darauf hab ich ja auch schon gegeben. Aber für dich sag ich es nochmal ganz ausführlich: N-E-I-N

So deutlich war das IMHO nicht.
"Hier nur mal so als schlechtes Beispiel" kann auch einfach heißen, dass nur dieses Beispiel schlecht ist und sonst die Vorgehensweise gut ist.

Und wie liest du dann [...]

So, dass otze meint, dass du immer noch insgesamt keine Referenz verwendet hast, sondern nur hinter einem Pointer versteckt und insgeheim doch wieder für alles die Adresse nimmst.
Du hast also nicht "mit Tricks" eine Referenz inkrementiert sondern den Pointer. Die Referenz wird dadurch nicht verändert.

[HumeSikkins]

0xdeadbeef schrieb:

HumeSikkins schrieb:

So schlimm ist es in meiner Situation gar nicht.
Eher so:
if (!filter.get() || (*filter)(entry))
...
Kein else und kein doppelter Boden.

Dass das legaler Code ist, wage ich gerade mal zu bezweifeln

Und wieder urteilst du etwas vorschnell.

class IFilter
{
public:
    virtual bool operator()(const std::string&) = 0;
    ...
};
class Context
{
private:
    std::auto_ptr<IFiler> filter;
};

Und wie du siehst erwarte ich von meiner Policy weder einen operator* noch muss sie der Nutzer per Pointer reingegeben haben (wobei ich das in meinem Fall ja wie im ersten Posting beschrieben derzeit so handhabe).

Wenn filter ein pointer sein und das eigentlich filter->get() heißen soll

Soll es nicht.

musst du NULL-Pointer vorher trotzdem abfangen

Das tut mein Code.

womit wir wieder bei unseren ifs wären.

Ich weiß nicht wo "du" bist, aber ich bin nicht bei "unseren" ifs.

Erzähl mir mehr und ich kann dir was sinnvolleres sagen

Danke für das Angebot, aber in diesem Fall möchte ic1h dann doch lieber darauf verzichten. Das Gesprächsklima ist ehrlich gesagt absolut nicht nach meinem Geschmack.

[peterchen]

mein std::vecor::iterator ist ein zeiger auf T.
Das weißt du aber nicht

[otze]

peterchen schrieb:

mein std::vecor::iterator ist ein zeiger auf T.
Das weißt du aber nicht

doch, habs nachgeschaut :p, benutzen darf ich das wissen aber leider nicht(aufjedenfall nicht ohne zuerst meine magischen traits zu befragen^^)

[0xdeadbeef]

@HumeSikkins: Stimmt, du hast recht - an auto_ptr hab ich grad nicht gedacht. Jetzt gibt der Code auch Sinn.

Wie dem auch sei, im Grunde implementierst du an der Stelle auch nur ne verdeckte Default-policy, die halt nichts macht. Was Pointer angeht, es mag konkrete Anwendungen geben, bei denen du nicht um dynamische Allokation herumkommst (wenn du die policies z.B. aus einer factory beziehen musst), aber auch dann halte ich es designtechnisch für sinnvoller (weil konsistenter), einen Pointer auf eine tatsächliche Instanz zu verlangen und ggf. NULL-Pointer schon im Konstruktor zu asserten. Das im Wesentlichen aus Gründen der Flexibilität (für den Fall, dass die default-policy doch mal was anderes als nichts machen soll). In dem Fall erwartest du aber sowieso, dass die Instanz auf dem Heap liegt, von daher ist foo_policy fp = new foo_default_policy() in der Parameterliste des Konstruktors unkritisch und es gibt überhaupt kein Problem.

[groovemaster]

Optimizer schrieb:

Du hast also nicht "mit Tricks" eine Referenz inkrementiert sondern den Pointer. Die Referenz wird dadurch nicht verändert.

Nee, wie auch. Eine Referenz kann ja nach Initialisierung nicht mehr verändert werden. Mit "tricksen" meinte ich einfach, dass man aus einer Referenz eine neue "inkrementierte" Referenz machen kann, die sich für den Client wie die ursprüngliche Referenz darstellt ohne dabei die Implementierung mit Zeigern offen zu legen. Da dies aber afaik nicht üblich ist, und imo nicht unbedingt sinnig, schrieb ich von einem "schlechten Beispiel".

[Gast]

Jop. Ich habe auch nicht behauptet, zu wissen, ob du das jetzt gut findest oder nicht.
Es geht mir nur einfach darum, dass du die Referenz nicht inkrementiert hast, auch wenn du behauptet hast, dass das "mit Tricks" geht. Ich denke mal, das war das, was otze gemeint hat (um mal den ganzen Stack jetzt wieder abzubauen ).
Und eigentlich gehts ja darum, dass es nicht sinnig ist, mit Gewalt Pointer zu vermeiden, um "sichere" Referenzen ö.ä. zu benutzen.
Darin sind wir uns ja einig.