std::map - wird Instanz automatisch erstellt?

hustbaer

Ich persönlich finde m_ gut, und zwar weil...
* immer brav this-> zu schreiben nervt mich persönlich
* immer brav this-> zu schreiben kann man mal vergessen
* wenn nurmehr x dasteht (statt this->x oder m_x ), ist nicht mehr ersichtlich ob etwas ein Member ist oder nicht (was ich für eine wichtige Information halte)

m_ ist sehr gut sichtbar/schnell erkennbar und kürzer als this->

Ich wollter hier aber auch keine m_ Diskussion lostreten.

Und "my" finde ich (fast) genauso schrecklich wie das grässliche "its"
(Wer "its" erfunden hat möchte ich sowieso wissen, dann schau ich mal bei dem vorbei und erzähl ihm was)

Nexus

hustbaer schrieb:

Und "my" finde ich (fast) genauso schrecklich wie das grässliche "its"

Naja, Unterstriche gibts bei mir nur in Makros, da möchte ich hier keine Ausnahme machen. Ich könnte aber auch einfach "m" nehmen. Steht eigentlich "m_" definitiv für "member"?

Ach ja, es gibt auch noch "our"... Für statische Variablen

hustbaer schrieb:

(Wer "its" erfunden hat möchte ich sowieso wissen, dann schau ich mal bei dem vorbei und erzähl ihm was)

Da würde ich mitkommen. Und dann können wir gleich noch den Erfindern von "DrawLinie" & Co. einen Besuch abstatten

Das könnte er persönlich nehmen :p

Gar nichts? Im Zweifelsfall dann halt this->.

Ich verwende für Getter und Setter, wenn ich welche brauche, am liebsten die Namen der Attribute:

class XYZ
{
public:
  int data();
  void data(int newData);
private:
  int mData;
};

So ungefähr. Wenn ich das "m" in "mData" wegließe und einfach nur "data" schriebe, würde der Compiler zu Recht meckern. Allerdings möchte ich auch nicht getData() und setData() schreiben, da mir das momentan zu wortreich erscheint.

Ich bin momentan sowieso noch auf der Suche nach "meinem" Stil und momentan gefällt mir diese Art von Gettern und Settern am besten - nur muss ich deswegen irgendwelche Pre- oder Suffixe verweden.

Und "my" finde ich (fast) genauso schrecklich wie das grässliche "its"

Wo ist der große Unterschied zwischen "my" und "m_"? Also die Anzahl der Buchstaben kann es nicht sein.
Bei "its" muss ich dir allerdings zustimmen, das ist schrecklich. Noch schlimmer für Attribute finde ich den Prefix "the", den sie uns beim C++ Kurs an der Uni "gelehrt" haben. Für Argumente von Funktionen wurde dann "a" oder "an" verwendet...

Nick Unbekannt

Was ist "its"?
Ich persönlich nutze auch m_* und zwar aus den von hustbaer genannten Gründen und weil der Unterstrich den Bezeichner deutlicher vom Präfix trennt. my finde ich sogar etwas ungünstig, wenn du wirklich x, y, z als Member halten möchtest. Weil sie leicht im Präfix untergehen und damit Fehler provozieren. Du meinst doch sowas wie m_y => myy ? this wird bei mir wirklich nur verwendet, wenn ich eine Referenz auf das Objekt benötige.

hustbaer

@Nick Unbekannt:

Du meinst doch sowas wie m_y => myy ? this wird bei mir wirklich nur verwendet, wenn ich eine Referenz auf das Objekt benötige.

Ne, die "my-Schreiber" tun dann schon gross weiterschreiben, also "myY" in dem Fall (auch nicht viel besser).

Was ist "its"?

Naja "sein" halt. Quasi "the object's Foo" -> "it's Foo" -> "itsFoo" *würg* (das Forum braucht dringend ein Kotz-Emoticon - wobei Emoticon auch so ein Hasswort ist *g*)

Keine Ahnung wer auf die Schnapsidee gekommen ist. Ich gehe davon aus dass es jmd. war der keine Praxiserfahrung hat, aber "tolle" Ideen, d.h. vermutlich ein Prof an einer Uni/FH und/oder ein ((Lehr-)Buch-)Author.

*duck-und-weg*

@Nexus:

Nexus schrieb:

Und dann können wir gleich noch den Erfindern von "DrawLinie" & Co. einen Besuch abstatten

Hat etwas gebraucht bis es *ding* gemacht hat... das war kein Verschreiber, oder?
(An "DrawLine" hab' ich nämlich nichts auszusetzen)

hustbaer schrieb:

DocShoe schrieb:

Geht übrigens auch deutlich kürzer und korrekter Parameterübergabe:

#include <list>
#include <algorithm>

void AddToMap( const std::string& Key, const std::string& Value)
{
   typedef std::list<std::string> list_type;

   list_type::iterator pos == std::find( m_Map[Key].begin(), m_Map[Key].end(), Value );
   if( pos == m_Map[Key].end() ) pos->insert( Value );
}

Ja. Geht sogar noch korrekter:

#include <list>
#include <algorithm>

void AddToMap( const std::string& Key, const std::string& Value)
{
   typedef std::list<std::string> list_type;

   list_type::iterator pos == std::find( m_Map[Key].begin(), m_Map[Key].end(), Value );
//   if( pos == m_Map[Key].end() ) pos->insert( Value ); // big badaboom
   if( pos == m_Map[Key].end() ) m_Map[Key].push_back( Value );
}

Ihr seid ja wohl wahnsinnig geworden. m_Map[Key] jedes Mal neu rauskramen?

list_type &ls = m_Map[Key];
if(std::find(ls.begin(), ls.end(), Value) == ls.end()) {
  ls.push_back(Value);
}

Natürlich könnte man auch eine std::map<std::string, std::setstd::string > benutzen und das Ganze auf

m_Map[Key].insert(Value);

zusammenstreichen. Wie sinnvoll das ist, hängt aber vom Anwendungsfall ab.

Was die Kennzeichnung von Member-Variablen angeht: ich benutze einen Unterstrich am Ende, bin aber der Ansicht, dass es wichtigere Dinge gibt, über die man sich streiten kann. this-> als Präfix kann leicht mal vergessen werden und erfüllt dementsprechend nicht den Zweck der Übung, deswegen rate ich davon ab, und mit Unterstrichen als Präfix muss man sehr vorsichtig sein, keine für die Implementation reservierten Bezeichner zu benutzen, aber ob jetzt foo_, m_foo, mFoo, itsFoo oder myFoo ist doch letztendlich herzlich gleichgültig.

hustbaer schrieb:

Naja "sein" halt. Quasi "the object's Foo" -> "it's Foo" -> "itsFoo" *würg* (das Forum braucht dringend ein Kotz-Emoticon - wobei Emoticon auch so ein Hasswort ist *g*)

Ich fühle mich verpflichtet, darauf hinzuweisen, dass der Genitiv von "it" im Englischen "its" ist. "it's" ist eine Kontraktion von "it is". Das ist ein Lieblingsfehler englischer Quasi-Analphabeten (sprich: Amerikaner ), der in Rechtschreibung bewanderte Engländer etwa so auf die Palme bringen kann, wie es bei uns mit "wä_h_re", "Standar_t_" oder "Vor_r_aus" der Fall ist (dass ich die Fehler mit Unterstrichen markieren muss, um am Forenfilter vorbeizukommen, sollte den Punkt unterstreichen).

hustbaer

@seldon:

seldon schrieb:

Ihr seid ja wohl wahnsinnig geworden. m_Map[Key] jedes Mal neu rauskramen?

Ich bin gar nicht wahnsinnig geworden, ich wollte lediglich auf einen Fehler hinweisen.
Ich fühle mich nicht verpflichtet dabei gleich noch Code zu optimieren der mir eigentlich vollkommen schnuppe ist. (Mal ganz davon abgesehen dass es nicht immer sinnvoll ist alles zu optimieren, wenn man 'nem Anfänger was zeigen/erklären will)

seldon schrieb:

hustbaer schrieb:

Naja "sein" halt. Quasi "the object's Foo" -> "it's Foo" -> "itsFoo" *würg* (das Forum braucht dringend ein Kotz-Emoticon - wobei Emoticon auch so ein Hasswort ist *g*)

Ich fühle mich verpflichtet, darauf hinzuweisen, dass der Genitiv von "it" im Englischen "its" ist. "it's" ist eine Kontraktion von "it is". Das ist ein Lieblingsfehler englischer Quasi-Analphabeten (sprich: Amerikaner ), der in Rechtschreibung bewanderte Engländer etwa so auf die Palme bringen kann, wie es bei uns mit "wä_h_re", "Standar_t_" oder "Vor_r_aus" der Fall ist (dass ich die Fehler mit Unterstrichen markieren muss, um am Forenfilter vorbeizukommen, sollte den Punkt unterstreichen).

Zur Kenntnis genommen.

seldon schrieb:

Was die Kennzeichnung von Member-Variablen angeht (...) bin aber der Ansicht, dass es wichtigere Dinge gibt, über die man sich streiten kann

Wo wird hier gestritten? Ein Paar Leute haben ihre Präferenzen kundgetan, das ist auch schon alles.

PhilippM

hustbaer schrieb:

Und "my" finde ich (fast) genauso schrecklich wie das grässliche "its"
(Wer "its" erfunden hat möchte ich sowieso wissen, dann schau ich mal bei dem vorbei und erzähl ihm was)

Das "its" kenne ich aus dem "Lehr"buch "C++ in 21 Tagen" von Jesse Liberty, bei Markt+Technik erschienen, so ums Jahr 2000 rum. Damit habe ich damals _versucht_ mir C++ beizubringen. 5 Jahre später hab ichs dann nochmal mit einem gescheiten Buch probiert.

Der Liberty muss damals aber recht verbreitet gewesen sein, vielleicht hat er das etabliert.

Gruß,
Phil

Nexus

hustbaer schrieb:

Hat etwas gebraucht bis es *ding* gemacht hat... das war kein Verschreiber, oder?
(An "DrawLine" hab' ich nämlich nichts auszusetzen)

Ja, ich hätte vielleicht ein eindeutigeres Beispiel wie "ComputeAnzahlElements" bringen können, aber ich hatte den Post schnell zu editieren, damit es überhaupt noch gelesen wird

Ein tatsächlich vorgekommenes, wirklich schlimmes Beispiel für so ein Gemisch weiss ich leider nicht gerade. Da sich theliquidwave nicht mehr für den Thread zu interessieren scheint – kennt jemand ein solches?

theliquidwave

Hey,
nur weil mein "Problem" augenscheinlich gelöst ist, heißt das nicht, dass ich nicht mitlese

Kurze Erklärung der Situation: In einem Spiel gibt es bestimmte Events, die per textbasierten Nachrichten ausgelöst werden. Beispielsweise: round_start oder player_spawn . Nun soll es möglich sein, pro Event beliebig viele "Listener" hinzuzufügen. Deshalb pro Key (also pro Eventname) eine std::list.

Gruß

Nexus

Sorry für die Unterstellung

Zu deiner Situation: Ich habe mal ein Event-System implementiert, allerdings mit std::multimap , in der die Keys die Eventnamen und die Values die Listener sind. Aber eine std::list in einer std::map geht auch gut. Hast du eigentlich eine konkrete Frage dazu?

theliquidwave

Nein, habe ich nicht
Aber std::multimap kannte ich noch gar nicht. Sieht für meinen Fall eigentlich noch optimaler aus als meine Lösung, oder nicht?

Beziehungsweise, doch nicht. Wenn ich recht überlege, wird die Durchlaufzeit in einer for-Schleife länger sein, da ich bei meiner Lösung nur einmal nach dem Key suchen muss. Und es kommt hier eher auf die Zeit zum durchlaufen an, als die Zeit, die benötigt wird, um den Listener hinzuzufügen

Gruß und Danke

Nexus

theliquidwave schrieb:

Aber std::multimap kannte ich noch gar nicht. Sieht für meinen Fall eigentlich noch optimaler aus als meine Lösung, oder nicht?

Ich denke mal, es läuft mehr oder weniger aufs Gleiche hinaus. Die Verwendung von std::multimap ist vielleicht etwas weniger komplex, weil du keine verschachtelten Container hast.

theliquidwave schrieb:

Beziehungsweise, doch nicht. Wenn ich recht überlege, wird die Durchlaufzeit in einer for-Schleife länger sein, da ich bei meiner Lösung nur einmal nach dem Key suchen muss.

std::multimap::equal_range() gibt dir die Iterator-Range zurück, innerhalb der sich die assoziierten Werte befinden, und benötigt wie std::map::operator[] O(log n). Du musst auch nur einmal nach dem Key suchen. Oder hab ich das falsch verstanden?

theliquidwave

Naja, bei meiner Methode mache ich einfach einen Zugriff auf:

for (bla::iterator it2 = it->second.begin(); it2 != it->second.end(); ++it2)

und fertig. Soweit ich das verstanden habe, muss ich bei std::multimap folgendes machen:

for (bla::iterator it = this->m_Map.find(name); it != this->m_Map.end(); it = this->m_Map.find(name))

Was nach logischer Beurteilung langsamer wäre.

Gruß

hustbaer

Man könnte ein set<pair<event_id, listener_ptr>> oder sowas in der Art verwenden.

theliquidwave

Danke, werde ich mir mal anschauen. Aber ich denke, dass ich eher bei meiner Lösung bleiben werde.

Gruß

Nexus

theliquidwave schrieb:

Soweit ich das verstanden habe, muss ich bei std::multimap folgendes machen:
for (bla::iterator it = this->m_Map.find(name); it != this->m_Map.end(); it = this->m_Map.find(name))
Was nach logischer Beurteilung langsamer wäre.

Nein, du sollst ja equal_range() und nicht find() benutzen.

Warum sollte überhaupt der genau gleiche find() -Aufruf mehrere Male nacheinander etwas Unterschiedliches zurückgeben, wenn du die Elemente nicht entfernst? Ich frage, weil dieser Aufruf im Aktualisierungsteil deiner For-Schleife steht.

theliquidwave

Das ist natürlich eine Sache, die ich völlig vergessen habe. Da muss ich dir Recht geben

Gruß