Inline failed in call to ...

[Scorpy]

I'm in the midst of adding MySQL support into my application, and found a wrapper class for it that looked simple enough to add, however when I try and compile it I receive the following errors:

Source/Includes/Database.h:38: error: inlining failed in call to 'mysql_map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::cha
r_traits<char>, std::allocator<char> > >::~mysql_map()': call is unlikely and code size would grow
Source/Socket.cpp:268: error: called from here
Source/Includes/Database.h:38: error: inlining failed in call to 'mysql_map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::cha
r_traits<char>, std::allocator<char> > >::~mysql_map()': call is unlikely and code size would grow
Source/Socket.cpp:268: error: called from here
Source/Includes/Database.h:38: error: inlining failed in call to 'mysql_map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::cha
r_traits<char>, std::allocator<char> > >::~mysql_map()': call is unlikely and code size would grow
Source/Socket.cpp:286: error: called from here

I've tried numerous things, but can't seem to get it working, so I can only summise that the method of doing it is wrong, i'll include (some of, so not to spam) the code at the end of the post and hopefully one of you guys will be able to tell me why it's doing this better than the compiler is.

Database.h

   template <class key_type, class val_type>
      class mysql_map : public std::map<key_type, val_type> {
         public:
            bool operator = ( const mysql_map<key_type, val_type>& src ) {
               this->std::map<key_type, val_type>::operator = ( src );
               return !this->empty();
            }
      };
   typedef mysql_map<std::string, std::string> ROW;

   class Database {
      private:
         MYSQL *        m_pConnection;    // Pointer to a MySQL C API connection object.
         MYSQL_RES *    m_pResult;        // Pointer to a MySQL C API result object.
         MYSQL_ROW      m_pRow;           // MySQL C API row object.
         std::list<ROW> m_pData;          // Local STL storage for returned result sets.

         unsigned long  m_iNumRows;       // The number of rows returned by the most recent select query.
         unsigned long  m_iAffectedRows;  // The number of rows affected by the most recent insert, update, or delete query.
         unsigned long  m_iInsertID;      // The primary key of the most recently inserted record.

         void StoreResults( void );
 
      public:
         Database( void ) {
            m_pConnection = mysql_init( NULL );
            m_pResult = NULL;
            m_pRow = NULL;
            Connect();
        }
        ~Database( void ) {
            mysql_close( m_pConnection );
         }
         ROW FetchRow( void );
   };

Database.cpp

void Database::StoreResults( void )
{
   int iFields = mysql_num_fields( m_pResult );
   ROW pRow;

   m_pData.clear();

   while( ( m_pRow = mysql_fetch_row( m_pResult ) ) != NULL ) {
      for( int iRow = 0; iRow < iFields; iRow++ ) {
         if( m_pRow[iRow] != NULL ) {
            pRow.insert( std::make_pair( std::string( m_pResult->fields[iRow].name ), std::string( m_pRow[iRow] ) ) );
         }
      }
      m_pData.push_back( pRow );
      pRow.clear();
   }
   return;
}

ROW Database::FetchRow( void )
{
   ROW pRow;
   if( m_pData.size() > 0 ) {
      pRow = m_pData.front();
      m_pData.pop_front();
   }
   return pRow;
}

Above is all of the code that relates to the problem, anything that uses ROW causes the problems. The code within Socket.cpp for the line, is:

ROW arRow = pDatabase->FetchRow();

If you need anymore, then please let me know.
Any help is very much appreciated!

[treuss]

AFAIK, std::map does not declare a virtual destructor (in the implementation I have at hand, it does not declare a destructor at all). So publicly deriving a class (in this case mysql_map) from it is something that goes under "not recommended".

Not sure really if that causes (or has anything to do with) the error message, I've never came across this one. Normally the problems that appear when deriving from a class without virtual destructor are much more subtle.

[Scorpy]

Ah, that makes sense!
I'll have to rewrite to compensate for that, thank you!