[C++] VC6 => 2005 conversie probl. met STL mappen

[Verwijderd]

Hallo allen,

Ik zit momenteel even met mijn handen in het haar...
We hebben een VC++ 6.0 project welke we willen bewerken en bouwen vanaf VS2005 (C++). Helaas loop ik hierbij in een vervelend probleem in de hoek van STL mappen. Ik heb geen kaas gegeten van STL (het is 3rd party code), dus ik hoop dat jullie me iets vooruit kunnen helpen.

Eerst hieronder de bewuste code (header-file), die als basis dient voor andere map-classes. Hier gaat de compiler de mist in gaat tijdens compileren. Ik heb de code iets gestript om het overzichtelijk te houden.

code:

// ...
// File       : SynchronizedMap.h
//
// Description: Encapsulates the functionalities of a synchronized map container of objects.
//
// Decisions
//
// History    :
// ....
#ifndef _C_SYNCHRONIZED_MAP_H
#define _C_SYNCHRONIZED_MAP_H

#include "HmpMutex.h"
#include <map>

template <typename keyT, typename objT>

class CSynchronizedMap  
{
public:
  
 // ... removed some methods to keep this small

   /**
   * Function : LookupObject
   * 
   * Abstract : Lookup in the map the object associated with a certain key. 
   *
   * Exception: -
   *
   * Remarks  : If an object was found the return value is true and the rObject is valid.
     *            If no object is found the return value is false and rObject is invalid.
   */
  bool LookupObject ( keyT key, objT& rObject )
  {
    std::map < keyT, objT >::iterator matchedObject;
        bool bFound = false;

    if ( m_Mutex.Lock () == true )
    {
      // check if the map is not empty
      if ( !m_ObjectsMap.empty () )
      {
        // lookup
        matchedObject = m_ObjectsMap.find ( key );

        if ( matchedObject != m_ObjectsMap.end () )
        {
          // if the key matched an item get the address of that item
          rObject = (*matchedObject).second;
                    bFound = true;
        }   
      } 
      m_Mutex.Unlock ();
    }   
    return bFound;  
  }

 // ... removed some methods to keep this small

  /**
   * Function : HasNext
   * 
   * Abstract : Returns true if there is a next element
   *              starting from the current position of 
   *              the class iterator 
   *
   * Exception: -
   *
   * Remarks  : 
   */
  bool  HasNext ()
  {
    bool    bResult = false;
    if ( m_Mutex.Lock () == true )
    {
      // If the map is empty then 
      
      if ( m_Iterator != m_ObjectsMap.end() )
      {
        m_Iterator++ ;
        if ( m_Iterator != m_ObjectsMap.end ())
        {
          bResult = true;
        }
        m_Iterator-- ;
      }
      
      m_Mutex.Unlock ();
    }
    return bResult;
  }
 
  /**
   * Function : GetNext
   * 
   * Abstract : Returns the object associated with
   *              the next key  from the map, considering
   *              the current position of the maps' iterator.
   *
   * Exception: -
   *
   * Remarks  : 
   */
  bool  GetNext ( objT& rObject  )
  {
    bool    bResult = false;
    
    if ( m_Mutex.Lock () == true )
    {
      if ( HasNext () )
      {
        m_Iterator++;
        rObject = ( *m_Iterator ).second;
        bResult = true;
      }
      m_Mutex.Unlock ();
    }

    return bResult;
  }

private:
    // The map container. The default sorting criterion used is less.
  std::map < keyT, objT >                   m_ObjectsMap;   
  
  // The iterator used to iterate the map
  std::map <keyT, objT >::const_iterator    m_Iterator;

    // Mutex used for syncrhonizing the map
  CHmpMutex                             m_Mutex;    
};
#endif // _C_SYNCHRONIZED_MAP_H

Als we een file compileren die deze header-file meeneemt, worden we verrast met de volgende compiler warnings / errors (ik heb de regelnummers ook even kloppend gemaakt met bovenstaande code snippet):

code:

Warning 1   warning C4346: 'std::map<keyT,objT>::const_iterator' : dependent name is not a type z:\synchronizedmap.h    128
Error   2   error C2146: syntax error : missing ';' before identifier 'm_Iterator'  z:\synchronizedmap.h    128
Error   3   error C4430: missing type specifier - int assumed. Note: C++ does not support default-int   z:\synchronizedmap.h    128

Het gaat uiteindelijk om het eerste stukje: template <typename keyT, typename objT> en de private data members van deze class.

Alvast bedankt en ik hou jullie ook op de hoogte...

[Verwijderd]

De compiler zeurt omdat hij const_iterator niet kan afleiden van de template types, in jouw geval keyT en objT.

Probeer het eens met 'typename'.

[Verwijderd]

Verwijderd schreef op woensdag 14 mei 2008 @ 16:24:
De compiler zeurt omdat hij const_iterator niet kan afleiden van de template types, in jouw geval keyT en objT.

Probeer het eens met 'typename'.

Bedankt voor je reactie, maar hoe doe ik dit dan? Want het volgende verbeterd niets aan de compiler output:

code:

std::map <typename keyT, typename objT >::const_iterator    m_Iterator;

Ik meende dat de regel template <typename keyT, typename objT>, welke vooraf gaat aan de class (bovin in de file), hier al voor zorgt. Of praten we nu over iets anders?

Thanks

[ Voor 12% gewijzigd door Verwijderd op 15-05-2008 14:59 ]

[.oisyn]

Ja, jullie praten over iets anders. Een std::map<A,B>::const_iterator kan een type zijn, maar ook constante of een functie of een variabele. Op het moment dat jouw template geparsed wordt zijn de 'waarden' van A en B nog niet bekend, en dus kan er ook niet opgezocht worden wat std::map<A,B>::const_iterator is. In dat geval wordt er gewoon uitgegaan van het feit dat const_iterator geen type is, en als dat wel zo is dan moet je er typename voorzetten:

C++:

typename std::map<A,B>::const_iterator bla;

De error zegt dat const_iterator een dependent type is. Hij is namelijk afhankelijk van de waarden A en B in jouw template

[ Voor 10% gewijzigd door .oisyn op 15-05-2008 15:16 ]

[Punkie]

In de std::map kan een type gedefinieert zijn met de naam const_iterator,

C++:

typedef int* const_iterator;

maar ook een datamember

C++:

static int* const_iterator

Welke van de 2 het is, weet de compiler nog niet bij het invullen van de templates (je weet wel, C++ => preprocessing). Vandaar het gebruik van typename, om de compiler te vertellen dat dit een type is (omdat hij default aanneemt dat dit een een variabele is.

[.oisyn]

Wat ik dus net al zei ja . Preprocessing heeft er trouwens weinig mee te maken.

[Punkie]

hmm, idd een foutje, templates worden niet geparsed tijdens preprocessing. Tijdens compilatie wordt, bij het aantreffen van een instantie van een template, de template parameters ingevuld en het resultaat gecompileert. Het invullen van de parameters is echter geen c++ preprocessing.

[.oisyn]

Het gaat in twee fases. De eerste is bij de definitie van de template, de tweede bij de instantie van de template. Die eerste fase is tevens ook de reden waarom je de compiler moet instrumenteren wat een type is en wat niet, omdat ie de code anders niet goed kan interpreteren. Overload resolution gebeurt voor het grootste deel ook al tijdens de eerste fase - in de tweede fase komen slechts associated namespaces van dependent names erbij.

VC++ slaat de eerste fase helemaal over en doet alles in de tweede fase, en daarom had VC++ 6.0 de typename dan ook niet nodig. In VC++ 2003 (geloof ik) zijn de regels aangescherpt en werd het gebruik van 'typename' verplicht daar waar dat volgens ISO C++ nodig was, om meer conform te zijn met de standaard - maar dus niet omdat de compiler het nodig heeft.

Maar two fase name lookup doet het nog altijd niet, en daarom gaat dit fout:

C++:

#include <iostream>

void foo(double)
{
    std::cout << "foo(double)" << std::endl;
}

template<class T> void bar(T t)
{
    foo(t);
}

void foo(char)
{
    std::cout << "foo(char)" << std::endl;
}

int main()
{
    bar('3');
}

Dit zou "foo(double)" moeten outputten. VC++ output "foo(char)", omdat hij de name lookup pas tijdens template instantiation (in main() dus) toepast. Maar foo(char) hoort niet bij de lijst van mogelijke overloads, omdat die tijdens template definition time nog niet bekend was en de global namespace geen associated namespace van char is (waardoor foo(char) in de tweede fase tijdens template instantiation er dus ook niet bij komt).

[Verwijderd]

Aan allen:
Bedankt voor de uitgebreide info en vooral ook de extra achtergrond info.

Nu kunnen we tenminste verder!