Walter

As we discussed the other day, I've been working on the issues preventing the STLSoft libraries working fully with DMC++. I now think I've found the main culprit, which was affecting many of the classes.

I've included the file inltempl.cpp, which is a massively chopped down version of the winstl::findvolume_sequence template, and the test program. If you compile the file (with 8.28, 8.29 or 8.30.3), you get

  h:\dev\test\compiler\dm\inltempl\inltempl.cpp(137) : Error:
'basic_findvolume_sequence_value_type' is not a class template
  Fatal error: premature end of source file
  --- errorlevel 1

Now, basic_findvolume_sequence_value_type is in the winstl namespace by default, along with all the other classes in this API. The method it refers to is an out-of-class inline method, as in

  template <ws_typename_param_k C, ws_typename_param_k T>
  inline basic_findvolume_sequence_value_type<C,
T>::basic_findvolume_sequence_value_type()
  {
      m_name[0] = '\0';
  }

It seems that DMC++ does not see the definition of an out-of-class inline method as being in the namespace where it is (in the code sense) defined. Perhaps it erroneously infers the namespace from the point of instantiation. This would explain why some methods suffer the symptoms given (which would be those used outside the namespace) and others do not (which would be those used only within). This hypothesis is backed up by a little experiment. If you go to the point in the file where I've marked it "WALTER, LOOK HERE!!" and change the #if 1 to #if 0 to select the alternate implementation, where the winstl namespace qualification is applied to the inline definition of the function, as in

  #if 1
  // original version
  template <typename C, typename T>
  inline basic_findvolume_sequence_value_type<C,
T>::basic_findvolume_sequence_value_type()
  {
  }
  #else
  // Explicitly qualified version
  template <typename C, typename T>
  inline winstl::basic_findvolume_sequence_value_type<C,
T>::basic_findvolume_sequence_value_type()
  {
  }
  #endif /* 1 */

then it all works ok.

To fix this, I could concoct a qualifying macro to be appended to all out-of-class inline function definitions, but I think the best workaround in the short to term is to not use the STLSoft namespaces until the compiler can work with them correctly.

I've just confirmed that this works by defining the _WINSTL_NO_NAMESPACES and _STLSOFT_NO_NAMESPACES symbols on a couple of projects that were formerly broken with DMC++, and all is well. How simple!!

So in the short term I will simply amend the main headers such that namespace support is not the default when using DMC++, and when you are able to fix the compiler, I think the STLSoft libraries may well have full DMC++ compatibility.

Hurrah!

Matthew