Is is possible to specify the ordering of a std::map ?

This is a discussion on Is is possible to specify the ordering of a std::map ? within the C++ Programming forums, part of the General Programming Boards category; From the reference, it seems that they try to be automatically sorted...(they called it weak ordering)
What happens when the ...

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

If you want to preserve the ordering of the initialization list (ie. an arbitrary order), why are you using a map?

Because I need to map some strings(Here operators) the user would be allowed to input to some pre-created objects so that the constructor would not be needed to create new ones.
I did what I needed manually with some 30 lines of code(setting the precedences), but the ordering would have made it possible to make a loop for that.

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

Bolding "map" and "to" doesn't change the fact that you're probably using the wrong data structure. std::map is basically just a balanced binary search tree. If it were named std::binary_tree instead of std::map, would you still want to use it?

Bolding "map" and "to" doesn't change the fact that you're probably using the wrong data structure. std::map is basically just a balanced binary search tree. If it were named std::binary_tree instead of std::map, would you still want to use it?

I didn't know that !
Can you think of a better data structure that would fit what I need to do ?

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

It may be suitable to make a map<string,pair<int,Operator>, or vector<pair<string,Operator> >, or something else depending on your use case. Also If you're writing Operator yourself, the string or index could be a data member instead of using a pair.

In general, the program will grab the input, if it is an operator, I figured that having it run through a constructor containing dozens of switch-cases/else-ifs would be a waste when I know there is a limited no. of possibilities. So I defined all the possible operator objects and am using the map to directly assign the address to the Operator* pointers (because the same object for all the cases is okay).

It may be suitable to make a map<string,pair<int,Operator>, or vector<pair<string,Operator> >, or something else depending on your use case. Also If you're writing Operator yourself, the string or index could be a data member instead of using a pair.

I'd try the first one tomorrow, but I'm not inclined to use vectors because it may be necessary to make searches occasionally.

Why do you need to preserve the order?

I don't actually 'need' to do so.
But it'd make the task of defining the pre-built objects easier.

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

In general, the program will grab the input, if it is an operator, I figured that having it run through a constructor containing dozens of switch-cases/else-ifs would be a waste when I know there is a limited no. of possibilities. So I defined all the possible operator objects and am using the map to directly assign the address to the Operator* pointers (because the same object for all the cases is okay).

I'd try the first one tomorrow, but I'm not inclined to use vectors because it may be necessary to make searches occasionally.

Yeah, a hash map sound like a good choice for this.

I don't actually 'need' to do so.
But it'd make the task of defining the pre-built objects easier.

If I make an initialization function for the operators, and have the Operators arranged in order of precedence, I could set the value of the precedence with a loop instead of by hand.
It could also make the task of inserting new Operators later easier.

But thinking on it for some time, I do realize that it'd be much more complicated that simply running a loop. So I'd go with the manual approach I've already coded.

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !