Re: member functions as slots with signals?

note the additions and comments
At Tuesday 2003-09-30 14:11, you wrote:
>First, thanks for the prompt reply.
>
>I was wondering about mem_fn also
>IMO updating the docs to reflect that would be quite useful.... I think I 
>personal prefer mem_fn() for our application.
>
>At Tuesday 2003-09-30 13:47, you wrote:
>>On Tuesday 30 September 2003 04:12 pm, Victor A. Wagner, Jr. wrote:
>> > I've been over the documentation several times and I keep getting the
>> > feeling that I'm just missing something.
>> > I'd like to have some member functions (methods) as slots for some signals
>> > (a la QT).  I suspect that there is some form of bind that I could 
>> use, but
>> > it's certainly not obvious to me.
>>
>>Yep, bind can do it:
>>
>>struct X {
>>   int foo(float, char);

      void blah() const;

>>};
>>
>>signal<int (X*, float, char)> sig;
>>sig.connect(bind(&X::foo, _1, _2, _3));

     X xt;

Re: member functions as slots with signals?

On Wednesday 01 October 2003 12:36 am, Victor A. Wagner, Jr. wrote:
struct X {
  int foo(float, char);
  void blah() const;
};

X xt;
signal<void(X*)> sigx;
sigx.connect(bind(&X::blah, &xt));

>      /// the above is more in line with what QT does with it's connect
> (i.e. binds it to an instance and method)
>      /// now only if there were some nifty syntactic sugar we could come up
> with so we could:
>      sigx.connect(magicsugar(&xt.blah));
>      /// which would more clearly show the intent, IMO

The bind syntax easily extends to more involved examples (e.g., reordering 
parameters, binding other parameters, or even nested bind expressions), 
whereas other, simpler syntax does not. It's somewhat of an acquired taste, 
but once you've really "got it" you'll never be able to go back.

> btw, I sent you a bug report w/ msvc++7.1 and debug assertion (heap not
> valid) when destructing a signal

I see it, and will try to duplicate the problem locally.

	Doug

compilation on Win64 platform with MSVC7.1 for 64 bit

Re: Compile Boost.thread libraries has a static library (.lib) with msvc 6 ?

Huck finn wrote:

> Hi everyone, I'm a total newbie to boost, but I've got to developp a 

[snip]

> 
> I really need to avoid using .dll in this project, so builing this 
> static library is very important to me...
> 

Hopefully some guru will give you a detailed answer. However, in the 
interests of giving you something quickly:

No. It has to be a DLL. It has something to do with either 
initialization or termination. The static libraries don't do it 
correctly. The DLLs do. Sorry.

HTH (and a clearer answer comes along),
  - Mark

boost library build consistency

Is there any definition of how libraries are supposed to build?

I've integrated the building of required boost libraries into the build
system for our projects.  There seems to be some inconsistency in what
gets built and where it gets put. In particular, for the thread and
regex libs, boost builds both shared and static versions of the
libraries and puts them in a bin-stage subdirectory under the library
build directory.  However, for the filesystem library, only the static
library gets built and the bin-stage/ directory is not used.

Is there a standard behavior library developers are supposed to follow
in this regard?

Can I count on the bin-stage/ as a short-named location for the most
recent build of any library?

Are the boost or boost_filestsystem maintainers interested in the simple
fix to the Jamfile to make that library behave like the other two I
mentioned?

Thanks
Scott Urban

Re: Compile Boost.thread libraries has a static library (.lib) with msvc 6 ?

Mark Sizer <boost <at> 15grant.com> writes:

> Huck finn wrote:
>
>> Hi everyone, I'm a total newbie to boost, but I've got to developp
>> a 
>
> [snip]
>
>> I really need to avoid using .dll in this project, so builing this
>> static library is very important to me...
>> 
>
> Hopefully some guru will give you a detailed answer. However, in the
> interests of giving you something quickly:
>
> No. It has to be a DLL. It has something to do with either
> initialization or termination. 

More specifically, it has to do with TLS.  If you don't need TLS
support, I think it's possible to build a static version of the
threads library, but it doesn't seem to be supported by the Jamfile.

> The static libraries don't do it
> correctly. The DLLs do. Sorry.
>
> HTH (and a clearer answer comes along),
>   - Mark

HTH2,
--

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: boost library build consistency

"Thomas S. Urban" <scottu <at> apptechsys.com> writes:

> Is there any definition of how libraries are supposed to build?
>
> I've integrated the building of required boost libraries into the build
> system for our projects.  There seems to be some inconsistency in what
> gets built and where it gets put. In particular, for the thread and
> regex libs, boost builds both shared and static versions of the
> libraries and puts them in a bin-stage subdirectory under the library
> build directory.  However, for the filesystem library, only the static
> library gets built and the bin-stage/ directory is not used.
>
> Is there a standard behavior library developers are supposed to follow
> in this regard?
>
> Can I count on the bin-stage/ as a short-named location for the most
> recent build of any library?
>
> Are the boost or boost_filestsystem maintainers interested in the simple
> fix to the Jamfile to make that library behave like the other two I
> mentioned?

I think this has been addressed in the CVS.  Have you looked at that
yet?

--

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Problem using Boost.thread : Class destructor called several times!

Hi there, still a newbie question for you guys...

I changed a bit the sample example from thread.cpp :

here's the new code i'm trying:
-----------------
boost::mutex io_mutex; // The iostreams are not guaranteed to be 
thread-safe!
class FakeClass
{
public:
	FakeClass(int NewID):ID(NewID)
	{
		boost::mutex::scoped_lock scoped_lock(io_mutex);
		std::cout<<"FakeClass #"<<ID<<" says : "<<"I'm alive!"<<std::endl;
	}
	~FakeClass()
	{
		boost::mutex::scoped_lock scoped_lock(io_mutex);
		std::cout<<"FakeClass #"<<ID<<" says : "<<"I'm being 
destroyed!"<<std::endl;
	}
	void operator()()
	{
		boost::mutex::scoped_lock scoped_lock(io_mutex);
		std::cout<<"Thread for FakeClass #"<<ID<<" has been started!"<<std::endl;
	}
private:
	int ID;
};
void main ()
{
	boost::thread_group group;
	FakeClass item1(1),item2(2);

	group.create_thread(item1);
	group.create_thread(item2);
	group.join_all();
	std::cout<<"   main ending..."<<std::endl;
}
-----------------------------

here's what I get when executing :

FakeClass #1 says : I'm alive!
FakeClass #2 says : I'm alive!
FakeClass #1 says : I'm being destroyed!
FakeClass #1 says : I'm being destroyed!
FakeClass #1 says : I'm being destroyed!
Thread for FakeClass #1 has been started!
FakeClass #2 says : I'm being destroyed!
FakeClass #1 says : I'm being destroyed!
FakeClass #2 says : I'm being destroyed!
FakeClass #2 says : I'm being destroyed!
Thread for FakeClass #2 has been started!
FakeClass #2 says : I'm being destroyed!
   main ending...
FakeClass #2 says : I'm being destroyed!
FakeClass #1 says : I'm being destroyed!
Press any key to continue

1- I'm wondering why the destructor of my FakeClass is called 4 times for 
each items ???

2- It says in the doc that the function that creates a thread "copies the 
function wrapped by threadfunc" and threadfunc would be in this case item1 
and item2, does this means that the copy constructor is called every time a 
thread is created with an object?

Thanks all!

Simon

_________________________________________________________________
MSN Messenger : discutez en direct avec vos amis !  
http://messenger.fr.msn.ca/

Re: compilation on Win64 platform with MSVC7.1 for 64 bit

> we're using Boost 1.30.0 with MSVC7.1 on a Win32 platform.
> Currently where working on a port to a Win64 platform using the MSVC7.1
for
> IA64 compiler. (13.10.2240.8 for IA64)
> I just compiled the code as is and unfortunately I encountered errors in
> boost headers.
> This probably is because of missing/bad defines for this 'unknown'
platform
> in the config headers...
> I was wondering if somebody already tried to compile boost on a 64 bit
> platform, and if he/she succeeded?
> Or if there are known implementation details which would cause boost
'never'
> to work on 64 bit platforms?

No it should be fine.

> If there are no known 'showstoppers' then I suppose I'll have to go
through
> the Boost Configuration Reference or should I look somewhere else?

First check the output from the config_info program - that will tell you
what is being detected at present - plus which config headers are in use.

Then try building config_test, and add defines to the config system intil it
builds (and let us know the result).

Finally try running the Boost regression tests - Boost + VC7.1 currently
passes all the tests, so there is no reason why the same should not be true
on IA64.  There may be some compiler/platform specific fixes in some places
that need updating though.

John.

Re: boost library build consistency

> Is there any definition of how libraries are supposed to build?

There is work going on towards an integrated build and install proceedure
that will fix this.

> Is there a standard behavior library developers are supposed to follow
> in this regard?

Not yet, but I've been working on some docs in this area....

John.