Thread overview
Another bug in STLport configuration
Dec 21, 2002
Steve
Dec 21, 2002
Christof Meerwald
Dec 22, 2002
Walter
Dec 22, 2002
Christof Meerwald
Dec 28, 2002
Richard
December 21, 2002
Hi Christof,

Could you also look at the following code?  It causes link error.

Thanks,
Steve

#include <algorithm>
#include <cassert>
#include <iostream>
#include <iterator>
#include <string>
#include <list>

template <typename Container>
Container make(const std::string & s)
{
return Container( s.begin(), s.end() );
}

int main( void )
{
std::list<char> list1, list2;
std::list<char>::iterator i;

list1 = make< std::list<char> >("There is a test");
list2 = make< std::list<char> >("simple ");
i = std::find( list1.begin(), list1.end(), 't' );

list1.splice(i, list2);
std::copy( list1.begin(), list1.end(), std::ostream_iterator<char>(std::cout,
""));
std::cout << std::endl;

return 0;
}


December 21, 2002
On Sat, 21 Dec 2002 00:45:02 +0000 (UTC), Steve wrote:
> Hi Christof,
> 
> Could you also look at the following code?  It causes link error.

As Richard pointed out, adding a #define for _STLP_EXPOSE_GLOBALS_IMPLEMENTATION in stlport/config/stl_dm.h should help.


bye, Christof

-- 
http://cmeerw.org                                 JID: cmeerw@jabber.at mailto cmeerw at web.de

...and what have you contributed to the Net?
December 22, 2002
"Christof Meerwald" <cmeerw@web.de> wrote in message news:au2ubo$7gu$1@digitaldaemon.com...
> On Sat, 21 Dec 2002 00:45:02 +0000 (UTC), Steve wrote:
> > Could you also look at the following code?  It causes link error.
> As Richard pointed out, adding a #define for _STLP_EXPOSE_GLOBALS_IMPLEMENTATION in stlport/config/stl_dm.h should
help.


Hmm. Is that still a bug in DMC++ that needs fixing?


December 22, 2002
On Sat, 21 Dec 2002 18:57:29 -0800, Walter wrote:
> "Christof Meerwald" <cmeerw@web.de> wrote in message news:au2ubo$7gu$1@digitaldaemon.com...
>> On Sat, 21 Dec 2002 00:45:02 +0000 (UTC), Steve wrote:
>> > Could you also look at the following code?  It causes link error.
>> As Richard pointed out, adding a #define for _STLP_EXPOSE_GLOBALS_IMPLEMENTATION in stlport/config/stl_dm.h should
> help.
> 
> Hmm. Is that still a bug in DMC++ that needs fixing?

It's missing support for explicit template instantiation in DMC.


bye, Christof

-- 
http://cmeerw.org                                 JID: cmeerw@jabber.at mailto cmeerw at web.de

...and what have you contributed to the Net?
December 28, 2002
In article <au47d0$12oh$1@digitaldaemon.com>, Christof Meerwald says...

>On Sat, 21 Dec 2002 18:57:29 -0800, Walter wrote:

>> Hmm. Is that still a bug in DMC++ that needs fixing?
>
>It's missing support for explicit template instantiation in DMC.

And Walter, I think this manifests as something we discussed a few weeks back concerning definitions of template member functions outside of the header file being reported as undefined symbols by the linker. With this bug in mind, the fix to STLport is to force inclusion of the definitions in the cpp (with #include) at the end of the header file.

I was able to get dir_it, the emerging boost library directory iterator concept to work by restructuring the header files so that all template member definitions occurred in the same file as the template declaration/definition. In addition, I was able to thunk into the runtime library to get the _find functions. However, the explicit template instantiation fixes were not trivial to implement and are definitely a one time thing that will have to be redone should the dir_it library be upgraded. Also, it would probably be best to have DM supplied _find tree ala:

#include "time.h"

#if !defined(IOAUX_H)

#define IOAUX_H

typedef unsigned long _fsize_t;

struct _finddata_t {
unsigned  attrib;
time_t  time_create;
time_t  time_access;
time_t  time_write;
_fsize_t  size;
char  name [260];
};

// imported from microsoft msvcrt.dll

extern "C" {

long _findfirst(const char* filespec, struct _finddata_t* fileinfo);
int _findnext(long handle, struct _finddata_t* fileinfo);
int _findclose(long handle);

} // extern "C"

#endif

Clearly these are non standard routines, so there is no standard based motivation to include them, but I also note that newsgroup and web searches seems to indicate that many compilers have this set defined consistently.. perhaps a defacto standard for the Microsoft set of operating systems.

Concerning the fix to STLport, the bug reported by Christof and the adjustements to dir_it, it is becoming clear that explicit template instantiation is going to be a recurring issue going forward with Boost.

Richard