error: no matching function for call to ‘min(long unsigned int&, unsigned int&)’

Question

I'm using ubuntu 12.04 - 64 bits. I tested it with boost 1.46, 1.48, 1.52 and gcc 4.4 and 4.6 When I try to compile:

while (m_burstReqBeatsRemain) {
                if (m_burstReqAddress % m_dramRowSize == 0) {
                    m_admRequestQueue.push_back(adm_request());
                    adm_request &req = m_admRequestQueue.back();
                    req.address = m_burstReqAddress;
                    req.command = tlm::TLM_READ_COMMAND;
                    //call to min function
                    req.readLen = std::min(m_burstReqBeatsRemain * sizeof(Td), m_dramRowSize);
                }
                m_burstReqBeatsRemain--;
                m_burstReqAddress += sizeof(Td);
                m_ocpTxnQueue.push_back(m_ocpReq);
}

I get this error:

no matching function for call to ‘min(long unsigned int&, unsigned int&)
from /usr/include/c++/4.6/bits/stl_algobase.h*

Note: with ubuntu 12.04 32 bits works fine

Any idea how I can fix this?

Solution

std::min is a function template on T which is the type of both parameters of the function. But you seem to pass function arguments of different type, and rely on template argument deduction from function arguments, which is not possible.

So the fix is :

• Either don't rely on template argument deduction, instead explicitly mention the template argument:

  std::min<unsigned long>(ulongarg, uintarg); //ok
       //^^^^^^^^^^^^^^^ 
       //don't rely on template argument deduction
       //instead pass template argument explicitly.
  

• Or pass function arguments of same type:

  std::min(ulongarg, static_cast<unsigned long>(uintarg)); //ok
                    //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                    //pass both arguments of same type
  

Comments

[Nawaz]

@user2008530: That is a compiler bug, or it is a bug in the implementation of std::min.

[Omnifarious]

@user2008530: gcc is being dumb. On that platform unsigned long and unsigned int are essentially the same type. IMHO, gcc should still be giving you an error, but that's likely why it isn't.

[vvill]

So probably the behavior of the method in 32-bit version will not be the expected behavior?

[Nawaz]

@user2008530: Yes. unsigned long and unsigned int are two different types, so the compiler should give error.