Thread: Is it possible to swap the key values and the mapped values around in a map?

Originally Posted by Bubba

Well I'm out of this discussion. We have gone from maps to multi-maps to vectors to maps and back to vectors. I'm so lost I don't even know what it is you are trying to do.

No, we haven't. We're still at multimaps...

Your posts contradict themselves and I'm not sure we are helping you correctly use any of the containers.

Show me at least two posts which actually contradict themselves, and I might just admit I was wrong (otherwise I wont...).

I guess do what you think works and when you run into the problems that many of us have re-iterated several times then come back and ask more questions.

Somehow it feels like we've rattled on for 3 pages and have ended up back where we started.

Not really. The topic of this thread is still what it was originally: swapping the key values and the mapped values of one map around and putting them in a new map (now changed to a multimap, so it can support duplicates).
I'd say we have actually advanced far into the night, with the moonlight light enough to be day, since I now have a working swap() function (which I'll probably rename to flipAMap() so it will more descriptive) which can swap any map with two parameters around.
That is more than could be said when I first started this thread...

I understand perfectly all of what has been said in this thread, and have applied a lot of the advice to my function. Perhaps it is other people (possible one of them you?) who are not really seeing clearly.

Hahaha. Anyway, I'm off to bed now. Its already 3:12 AM here.

Originally Posted by Programmer_P

Who's using maps wrongly?
It was an example, and an example alone. I was really only trying to demonstrate other possible ways of getting mapped values and key values than those already provided, my point being that I thought the current methods kind of sucked.

You, if you truly intend to use a map like that. Saying that the current methods "kind of sucked" is bogus when the map is simply not designed to do that. You are using the wrong container for the job, then blaming the container. That sucks, on your part.

Maps and multimaps are not designed for efficient access by sequential index. They are associative containers designed for efficient access by key value. They are not designed for efficient access by mapped value.

Originally Posted by Programmer_P

Show the code then...

For example:

Code:

template<typename IT, typename T>
bool value_exists(IT begin, IT end, const T& value)
{
    for (; begin != end; ++begin)
    {
        if (begin->second == value)
        {
            return true;
        }
    }
    return false;
}

#include <map>
#include <string>

int main()
{
    std::map<std::string, int> x;
    // ...
    if (value_exists(x.begin(), x.end(), 123))
    {
        // ...
    }
}

That said, instead of implementing an algorithm, I could have implemented a predicate and used std::find_if, e.g.,

Code:

template<typename Pair>
class CompareSecond
{
public:
    explicit CompareSecond(const typename Pair::second_type& x) : x_(x) {}

    bool operator()(const Pair& y) const
    {
        return y.second == x_;
    }
private:
    typename Pair::second_type x_;
};

#include <algorithm>

template<typename IT, typename T>
bool value_exists(IT begin, IT end, const T& value)
{
    return std::find_if(begin, end,
        CompareSecond<typename IT::value_type>(value)) != end;
}

#include <map>
#include <string>

int main()
{
    std::map<std::string, int> x;
    // ...
    if (value_exists(x.begin(), x.end(), 123))
    {
        // ...
    }
}

Originally Posted by laserlight

You, if you truly intend to use a map like that. Saying that the current methods "kind of sucked" is bogus when the map is simply not designed to do that. You are using the wrong container for the job, then blaming the container. That sucks, on your part.

No, I'm not. I needed a container which stores two kinds of values, and allows access to one kind of value with the other kind of value, and the map (or multimap) fits that bill.

Maps and multimaps are not designed for efficient access by sequential index. They are associative containers designed for efficient access by key value. They are not designed for efficient access by mapped value.

The bolded statements should not be exclusive to one another. Ideally, a map should allow efficient access by sequential index of the the current key value, i.e. so that you increment the index iterator to access the next key value of the map, and hence, also the mapped value. I was complaining mostly about the syntax necessary to achieve that goal in a map or multimap.

For example:

Code:

template<typename IT, typename T>
bool value_exists(IT begin, IT end, const T& value)
{
    for (; begin != end; ++begin)
    {
        if (begin->second == value)
        {
            return true;
        }
    }
    return false;
}

#include <map>
#include <string>

int main()
{
    std::map<std::string, int> x;
    // ...
    if (value_exists(x.begin(), x.end(), 123))
    {
        // ...
    }
}

That said, instead of implementing an algorithm, I could have implemented a predicate and used std::find_if, e.g.,

Code:

template<typename Pair>
class CompareSecond
{
public:
    explicit CompareSecond(const typename Pair::second_type& x) : x_(x) {}

    bool operator()(const Pair& y) const
    {
        return y.second == x_;
    }
private:
    typename Pair::second_type x_;
};

#include <algorithm>

template<typename IT, typename T>
bool value_exists(IT begin, IT end, const T& value)
{
    return std::find_if(begin, end,
        CompareSecond<typename IT::value_type>(value)) != end;
}

#include <map>
#include <string>

int main()
{
    std::map<std::string, int> x;
    // ...
    if (value_exists(x.begin(), x.end(), 123))
    {
        // ...
    }
}

Ok, but using that method requires writing your own function for using a generic-type of iterator for a map. There is nothing for that already provided by std::map or std::multimap.

Originally Posted by laserlight

You, if you truly intend to use a map like that. Saying that the current methods "kind of sucked" is bogus when the map is simply not designed to do that. You are using the wrong container for the job, then blaming the container. That sucks, on your part.

@Programmer_P: I'm just going to re-iterate the point I tried very hard to make earlier, that this should be a class containing a map, not just a map. Simple. Or you can keep digging this hole deeper.

Originally Posted by Programmer_P

No, I'm not. I needed a container which stores two kinds of values, and allows access to one kind of value with the other kind of value, and the map (or multimap) fits that bill.

Yes, tie your hands together behind your back while you're at it. It's like trying to give advice to a brick wall. Apparently no one on the entire forum has any sort of knowledge or perspective that's of use to you. Take a step back, try to get out from under your ego for a while and you could actually learn something, instead of feeding this insane fest of miscommunication and denial.

Originally Posted by MK27

@Programmer_P: I'm just going to re-iterate the point I tried very hard to make earlier, that this should be a class containing a map, not just a map. Simple. Or you can keep digging this hole deeper.

Funny. I have actually considered your suggestion seriously, though you probably think I didn't, but decided there is no advantage to putting the swapped map in a class.
And so far, you have not really demonstrated any actual advantage to putting it in a class either that will top my method.

Yes, tie your hands together behind your back while you're at it. It's like trying to give advice to a brick wall. Apparently no one on the entire forum has any sort of knowledge or perspective that's of use to you. Take a step back, try to get out from under your ego for a while and you could actually learn something, instead of feeding this insane fest of miscommunication and denial.

I'm not saying that at all. Yes, I know everyone here has knowledge, more experience, perspective, etc. Otherwise, I wouldn't bother asking any question here at all. But once again, just because you have that, that doesn't make you right all the time either. At least I admit when I'm wrong...

Originally Posted by Programmer_P

Yes, I know everyone here has knowledge, more experience, perspective, etc. But once again, just because you have that, that doesn't make you right all the time either.

In theory I agree.

Here's what I think your problem is: you are happy about the things you have done already and don't want to change anything. However, because you have not really written very many serious programs, you are naturally short sighted WRT to design. That's how it goes. Now you are constantly trying to adapt what you have without confronting this fact, which might be hard for you to see, especially if you don't want to. It's called "stubborn beyond belief" People are just being honest and then becoming exasperated at your attitude. Pretty clearly I am not the only one. Like I said, you very much need to get a grip on your ego. It's not any of us who are going to suffer the consequences here, remember. It's up to you to make the most of it, and you really ain't. Seriously.

Ideally, a map should allow efficient access by sequential index of the the current key value, i.e. so that you increment the index iterator to access the next key value of the map, and hence, also the mapped value. I was complaining mostly about the syntax necessary to achieve that goal in a map or multimap.

Ah, but there's something you do not understand about why and how a map is not an array/vector, and that it is not arranged sequentially in memory. That is an inescapable trade-off of data structures (hopefully one day you'll code some yourself). This is a "can't have your cake and eat it too" scenario. The developers of C++, after all, cannot just make up anything they like because it would be nice. They are logically constrained by certain realities, this is one of them. Technically a map is a tree, if you want to look that up.

Originally Posted by MK27

In theory I agree.

Here's what I think your problem is: you are happy about the things you have done already and don't want to change anything.

Correction: I don't want to change anything if I don't have to or see a reason to.

However, because you have not really written very many serious programs, you are naturally short sighted WRT to design. That's how it goes. Now you are constantly trying to adapt what you have without confronting this fact, which might be hard for you to see, especially if you don't want to. It's called "stubborn beyond belief"

That may be, but I have considered in this particular case at least, the long-term uses for an enumerations map and a swapped map. And like already mentioned, I just don't see why you would want to put the maps inside a class. If you're thinking in terms of objects with the maps contained in this or that object, then it would be easy enough to add a method for adding a map (swapped or otherwise) to a struct or class after the fact.

People are just being honest and then becoming exasperated at your attitude. Pretty clearly I am not the only one. Like I said, you very much need to get a grip on your ego. It's not any of us who are going to suffer the consequences here, remember. It's up to you to make the most of it, and you really ain't. Seriously.

I think its much more than that. It is apparent that people are skimming through this thread, then responding to certain things I say which they want to oppose, instead of providing helpful tips. At least, that's the way it is now...
At the beginning, there were some pretty good helpful posts (laserlight's for example).
But now the thread has deteriorated into a verbal war with words.

Ah, but there's something you do not understand about why and how a map is not an array/vector, and that it is not arranged sequentially in memory.

And that is fine. The way I see it, it doesn't need to be arranged sequentially in memory, to have such functionality in the std::map or std::multimap classes. The elements could be arranged in the map in the same order that they were inserted, and you could retrieve them in the same manner.

Originally Posted by Bubba

Every example has but b/c you are so blinded by your own ideas you fail to see them. Every response we get is essentially 'my way is better' and then you ask us to show you a better way. We do show you but you don't see it b/c you refuse to see it.

I do wish people would stop quoting my posts I direct at other posters. Bubba, what you just quoted was directed at MK27. It was not directed at you.
And your statement about "every example has" is utter BS, btw. We're talking about putting a swapped map in classes here, and what advantage there would be (if any) if I put it in a class. All I'm saying is MK27 has not demonstrated a possible advantage of this at all. And I don't really believe there is one. My reasoning is based on the fact that his method would only work with one particular map (i.e. the enumerationsMap swapped around) and so I don't see that that truly justifies creating a said swapped map inside the class for that, because the swap() function provides a way for swapping ANY map around. And the only reason why I was wanting to swap the enumerations map around to begin with was for the rare times when someone might need the enumerations map to look like this:

multimap <unsigned int, string> aMap;

instead of

map <string, unsigned int> aMap;

When I decided to write such a function to swap the map around to begin with, I was thinking along the lines of maybe sometime needing to retrieve the string names of the enumerations by passing in the corresponding unsigned int value of the enumerations. Since I was thinking that, though I did recognise from the start that I could put another map in the enum class with the types the opposite of what they are in the main map, then write a function for retrieving the other map too, I decided to write a swap() function which could swap any map around to make it more flexible, seeing as I already have other ways of getting the string names of the enumerations. That is how this thread was born to begin with.
Now I have such a working function, and MK27 seems to be supporting the idea of storing both maps in a class, and I am questioning WHY because personally I don't see any advantage over just using swap(). That is all. So far he has not really given a good explanation/reason to do such a thing, though I'm eager to read it.

Well in this case you are wrong and you won't admit it. As we have all said time and time again just b/c you can create constructs in the map or with the map or what have you does not mean your design is good. Just b/c it works doesn't mean it's a good design and that you should continue with it. Bad design will code you into a corner and some of those might be impossible to get out of without significant changes. We are telling you that you are using a map for the wrong task. I'm not even sure your program requires said task but you won't listen to that either.

I think you should leave that judgment to the person who is actually coding the program, and is the one reading all the code (namely, me). In this particular thread, I'm not asking about the advice of anyone regarding why I need such a program to begin with, because we've already been through all of that already, and I think it is dumb on your part to jump to such a conclusion without knowing all the facts (i.e. by reading the code of my program).

But alas you will not listen and will respond to this with your typical '"I'm right and I know it so show me something different...." and yet we have and you refuse to acknowledge it.

That is not what I'm saying at all. I never once said this in this thread, I don't think, that I'm right and everyone else is wrong, like it seems that's what you're suggesting here. I'm only making the case that everyone else shouldn't just automatically assume I'm wrong either just because one poster has more experience/background/etc. than I do.
Read the posts and gather all the facts before you pass a judgment, please. Half of the posts in this thread by other posters have been filled with misguided assumptions, probably because they only skimmed the thread, and did not actually take the time to read it and think about the problems logically.

I have not seen anything incorrect from the others that have posted here. They are different approaches that are all fundamentally better than yours. The only posts that I find things that are plainly wrong are all yours.

Clearly, you are biased against me for some reason, because almost all posts by you directed at me in all threads I have made on these forums so far have been filled with negative comments like "Everyone else is right, and you're wrong" type of attitude.
Spare me the personal attacks, and either start posting with more positive thoughts and comments, or stop posting in my thread completely.
You didn't start this thread, I did. So I say if you don't like some of what I'm saying in my own thread, then you just stay the hell away from the thread and don't read it at all, how about it.

Originally Posted by phantomotap

O_o

Wow. You are unbelievable.



This is an open forum on the internet; if you can't handle it, leave.

Soma

You don't think I know that? Expressing my feelings on the subject is totally different than not being able to "handle it", as you put it.
I can only make a suggestion is all. Obviously, its up to the poster to decide to follow it or not.

How would you like it if you started a thread asking for some honest help, then everyone just starts attacking you in it?

Originally Posted by Programmer_P

Ideally, a map should allow efficient access by sequential index of the the current key value, i.e. so that you increment the index iterator to access the next key value of the map, and hence, also the mapped value.
(...)
The way I see it, it doesn't need to be arranged sequentially in memory, to have such functionality in the std::map or std::multimap classes. The elements could be arranged in the map in the same order that they were inserted, and you could retrieve them in the same manner.

You are right to say that such functionality can be provided, but there is a cost to it. For example, a vector (or deque) of map iterators could be used to provide efficient access by sequential index. It does not make sense to add this along with std::map and std::multimap because not every use of maps and multimaps needs such functionality and hence should not automatically incur such a cost (and this would also change the time complexity of operations such as removing elements), but there is nothing stopping you from building on these containers for a container that meets your exact requirements, within what is computationally possible.

Originally Posted by laserlight

You are right to say that such functionality can be provided, but there is a cost to it. For example, a vector (or deque) of map iterators could be used to provide efficient access by sequential index. It does not make sense to add this along with std::map and std::multimap because not every use of maps and multimaps needs such functionality and hence should not automatically incur such a cost (and this would also change the time complexity of operations such as removing elements), but there is nothing stopping you from building on these containers for a container that meets your exact requirements, within what is computationally possible.

I don't get what you would use a vector (or deque) of map iterators for? I think if I was going to build on some existing containers, I would just build on the std::map and std::multimap types, and write a templated class that contains a map of the type specified in the template (so you probably pass a map into the constructor of the class). Then I would have a single iterator of the map type to iterate through the map in a function with a declaration type like this:

Code:

const MapMappedValueType& at(unsigned int index);

which would return the mapped value found at the specified index of the map.