Re: Thread - problem (tss.cpp under MSVC++6)

From: ajp_m (a.maclean_at_[hidden])
Date: 2002-02-19 17:49:05

I am inclined to agree with Bill in that, given that this is really 
a library build issue for most compilers, the best solution at 
present would be to note the requirements in the documentation. 
However this only partially addresses Brian's comments regarding 
early error detection. His idea of a predefined macro is 
interesting. Has anyone tried this?

At present the code works well and it is so good to have a robust
(NATIVE!!!)C++ implementation of threads! No more wrappers!

As a side issue, it is interesting to note that the IDE (MSVC++6SP5) 
will actually warn you if a DLL is not needed when you compile a 
release version.

Andrew

  
--- In boost_at_y..., "bill_kempf" <williamkempf_at_h...> wrote:
> --- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> > At 11:29 AM 2/19/2002, bill_kempf wrote:
> > 
> >  >> Might be worth a new predefined macro.  _DLL_TARGET or 
similar.
> >  >>
> >  >> Anything a compiler implementor can do that allows better 
error
> >  >detection
> >  >> is a win for users, and cuts support costs too.
> >  >
> >  >The only problem is that, as someone else pointed out, this is 
a
> >  >linker concept not a compiler concept.  I'm not sure the 
compiler
> >  >can  determine that the target will be a DLL.
> > 
> > At least when using the IDE, the distinction seems somewhat 
> artificial. The 
> > IDE knows, so can pass the information on to whichever component 
> needs it.
> 
> True, though not everyone uses an IDE, so even if we got all the 
> Win32 IDEs to do this it would be only a partial solution.
> 
> > Likewise, building with Jam there is knowledge at a higher level 
of 
> what 
> > the target is, so information could be passed to a compiler.
> 
> If they use Jam I'd expect they'd use the provided Jamfile(s) so 
that 
> there'd be no need for detection.  The problem comes up frequently 
> because people, for what ever reason, build the libraries with 
their 
> own build system instead of employing the Jam build system that's 
> provided.
> 
> At this point I think the only "solution" is to complete the build 
> specification documentation that's on my todo list.
> 
> Bill Kempf