www.digitalmars.com         C & C++   DMDScript  

c++.stl.port - Another bug in STLport configuration

reply Steve <Steve_member pathlink.com> writes:
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;
}
Dec 20 2002
parent reply Christof Meerwald <cmeerw web.de> writes:
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?
Dec 21 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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?
Dec 21 2002
parent reply Christof Meerwald <cmeerw web.de> writes:
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?
Dec 22 2002
parent Richard <fractal clark.net> writes:
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
Dec 28 2002