6

I'm having an issue porting my functor from windows to linux. (a functor to pass to stl::map for strict-weak ordering) The original is as follows:

struct stringCompare{ // Utilized as a functor for stl::map parameter for strings 
    bool operator() (string lhs, string rhs){ // Returns true if lhs < rhs
        if(_stricmp(lhs.c_str(), rhs.c_str())  < 0) return true;
        else return false;
    }
};

As linux doesnt support _stricmp but uses strcasecmp instead, I changed it to:

struct stringCompare{ 
    bool operator() (string lhs, string rhs){ // Returns true if lhs < rhs
        if(strcasecmp(lhs.c_str(), rhs.c_str())  < 0) return true;
        else return false;
    }
};

And it is now complaining about "const" parameters:

passing const stringCompare as this argument of bool stringCompare::operator()  
(std::string, std::string)â discards qualifiers

I'm not entirely sure why it supposes stringCompare should be a constant...

And the line where it is mad about this being instantiated is:

if(masterList->artistMap.count(songArtist) == 0)

artistMap being an stl::map with a string key.

I'm not sure where I'm going wrong. I attempted to change the bool operator() parameters to const, as it appears that it's complaining about some sort of non-constant parameter passing. This didn't work, nor did changing 'bool operator()' to 'const bool operator()'.

As far as I know, strcasecmp is a const function so should case whether I pass it non-constant or constant parameters (c_str() also being const), so I'm not exactly certain where I'm going wrong.

I've googled similar issues but I still can't quite make sense of the issue from what I've seen both on stackoverflow and a couple other places.

The datatype where I'm using this is:

map<string, set<song, setSongCompare>*,stringCompare > artistMap;
Glem
  • 449
  • 6
  • 16
  • Perhaps related to `const` qualifier?? Is the warning reported at the `map` declaration or somewhere else? – Kashyap Mar 19 '12 at 19:30
  • You are much better off using string algorithms which are portable and operate on std::string rather than const char*. there is one for case insensative comparison. – 111111 Mar 19 '12 at 19:31
  • it's being reported at this line: if(masterList->artistMap.count(songArtist) == 0) where songArtist is a string – Glem Mar 19 '12 at 19:31
  • @111111 I don't have access to external libraries such as boost, and stl doesn't have such a comparison function – Glem Mar 19 '12 at 19:33
  • possible duplicate of [error: passing xxx as 'this' argument of xxx discards qualifiers](http://stackoverflow.com/questions/5973427/error-passing-xxx-as-this-argument-of-xxx-discards-qualifiers) – Barmar Dec 04 '12 at 08:10

1 Answers1

10

Two things:

  1. Define your bool operator() as const. It's just a good practice. This tells the compiler that this function will not have side-effects on the member variables of the class.

  2. Add const & qualifiers to the lhs and rhs arguments. Passing constant references instead of copying memory all over the place is also good practice. By declaring references as const you're telling compiler that this function should not have side-effects on the referenced objects.

Your operator() should look as follows:

bool operator() (const string &lhs, const string &rhs) const 
{
  return strcasecmp(lhs.c_str(), rhs.c_str())  < 0;
}
George Skoptsov
  • 3,831
  • 1
  • 26
  • 44
  • 1
    @Glem Not `const bool operator()(...)` but `bool operator()(...) const` – Praetorian Mar 19 '12 at 19:33
  • I thought I had attempted it this way, but I suppose not! This did work. Why does it require const after parameters? I haven't seen this before. Also, shouldn't it in theory not worry about const if none of the internal functions are non-constant? Just so I can clarify in my head why the error occurred. Thank you! – Glem Mar 19 '12 at 19:37
  • @Glem `const bool operator()(...)` means return of the function is `const`, whereas `bool operator()(...)` means the function itself as `const`, i.e. not having side-effects on member variables of its class. – George Skoptsov Mar 19 '12 at 19:57
  • @GeorgeSkoptsov Ahh, that makes sense. Thank you George. – Glem Mar 19 '12 at 20:04