class Test
{
public:
    void AddToMap(std::string Key, std::string Value)
    {
        // existier solch ein Eintrag bereits?
        std::map<std::string, std::list<std::string> >::iterator it = this->m_Map.find(Key);

        if (it != this->m_Map.end())
        {
            for (std::list<std::string>::iterator it2 = it->second.begin(); it2 != it->second.end(); ++it2)
            {
                if ((*it2) == Key)
                {
                    // ist bereits vorhanden
                    return;
                }
            }
        }

        // an dieser Stelle kann es nun sein, dass Key noch nicht in m_Map vorhanden ist
        // geht das hier trotzdem?
        this->m_Map[Key].push_back(Value);
        // wie man sieht, wird gleich die push_back-Funktion von std::list aufgerufen, obwohl ich selber keine Instanz erstellt habe
    }

private:
    std::map<std::string, std::list<std::string> > m_Map;
};

Gruß

http://www.cplusplus.com/reference/stl/map/operator[]/

// edit:
Jaja, zu spät

Wozu sind die ganzen this in deinem Code gut?

lol

Gruß

#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 );
}

Das alles ist doch nur eine Stilfrage. Oder gibt es da noch andere Gründe?

Das alles ist doch nur eine Stilfrage. Oder gibt es da noch andere Gründe?

Nein, manche finden this->that einfach überflüssig, da man auch einfach nur that schreiben könnte.
Ich mag Prefixe wie m_, m oder my auch nicht, aber mir ist da noch nichts besseres eingefallen...

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 );
}

Nein, manche finden this->that einfach überflüssig [...]

Das könnte er persönlich nehmen :p

that->this schrieb:

Ich mag Prefixe wie m_, m oder my auch nicht, aber mir ist da noch nichts besseres eingefallen...

Gar nichts? Im Zweifelsfall dann halt this-> . Würde ich selbst zwar nicht machen (ich verwende my ), aber wäre halt auch eine Möglichkeit.

• 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)

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

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)

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

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.

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

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?

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ß

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?

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