Chris Weed | 1 Feb 2007 01:40
Picon
Gravatar

Re: problem with boost/iterator/zip_iterator.hpp

Hi,
This has been fixed in CVS HEAD and future versions.
If you want to hack up the code, declare the function tuple_equal to be inline.
Chris

On 1/31/07, Tim Axelrod <taxelrod <at> gmail.com> wrote:
> Hello,
>
> If more than one source file includes boost/iterator/zip_iterator.hpp,
> the loader complains about a multiply defined function:
>
>     tsa <at> mops2.lsstcorp.org:~/VW/TSA> g++ -o nothing nothingMain.cc
>     nothing.cc
>     /tmp/ccT5Bn0N.o: In function
>     `boost::detail::tuple_impl_specific::tuple_equal(boost::tuples::null_type,
>     boost::tuples::null_type)':
>     nothing.cc:(.text+0x0): multiple definition of
>     `boost::detail::tuple_impl_specific::tuple_equal(boost::tuples::null_type,
>     boost::tuples::null_type)'
>     /tmp/ccH8Z9eR.o:nothingMain.cc:(.text+0x0): first defined here
>     collect2: ld returned 1 exit status
>
>
> I'm using boost_1_33_1.  The source files are attached.
>
> Regards,
> Tim Axelrod
>
>
> _______________________________________________
(Continue reading)

Alf Kraus | 1 Feb 2007 04:17

mapped_file_sink

I'm trying to create memory mapped files using mapped_file_sink:  

mapped_file_params mfParams( fileName );
mfParams.new_file_size = filesize;
mapped_file_sink mfSink( mfParams );

trying to use any of its funtions like:
const char *ptStart = mfSink.data();

the compiler tells me that I have no access to them for they are private 
members since inherited from mapped_file

I know thats a piece of cake but just cant solve it.

Cheers Alf
Alf Kraus | 1 Feb 2007 07:37

mapped_file_sink

does anyone have an example of using *mapped_file_sink *to create and 
write into a memory mapped file?
Frank Mori Hess | 1 Feb 2007 14:37
Favicon

Re: [signals] Automatic connection management and MT

On Tuesday 30 January 2007 22:40 pm, Timmo Stange wrote:
> I'm working on a preliminary solution for an interface-compatible
> but thread-safe implementation of Signals for my project so that I
> will be able to switch to Boost.Signals should Doug Gregor find
> the time to add thread-safety there.
>
> While deciding what parts to include and which to leave out, I
> noticed that the automatic connection management is probably not
> usable in a multi-threaded context in the current form. Using a
> base class destructor (signals::trackable) to monitor an observer's
> lifetime is bound to result in race condition trouble with the order
> of destruction in a class hierarchy.
>
> Has that been discussed somewhere and are there any proposed
> solutions/alternatives?

I hit the same problem, I had to manually disconnect at the beginning of my 
destructors, see

http://article.gmane.org/gmane.comp.lib.boost.user/24356

Thread-safe automatic disconnect from non-static member functions seems 
like it would require some kind of extension to the language itself, like 
a pre-destructor.

I recently did the same thing as you, my signals implementation is 
attached, if you are interested.  The namespaces are different in my 
code, ::boost is ::EPG and ::boost::signals is ::EPG::signalslib.

--

-- 
(Continue reading)

fcvcnet | 1 Feb 2007 03:43

faq How to compile graph?

Hi all,
     I know BGL just a few days. I need yours help.
 Now I only want to use the graph in the boost1.33.1 , how can I compile the
only one component graph in vc6 or vs2005. So much thanks to your detail 
reply.
     Thanks again.
hongleij | 1 Feb 2007 13:09
Favicon

[boost-thread] why not writ e "sleep" in a better

hi: 
it really a trouble thing for me to use boost::thread::sleep()
:
boost::xtime helloworldtime;
 boost::xtime_get(&helloworldtime, boost::TIME_UTC);
 helloworldtime.sec += 6;
 boost::thread::sleep(helloworldtime);

i think 
"boost::thread::sleep(1500) //millisecond   "
 may easy my programming;if have such interface;
now i use :

void thread_sleep(unsigned int interval) //millisecond
{
    boost::xtime xt; 
    boost::xtime_get(&xt, boost::TIME_UTC); 
    int sec=interval/1000; 
    int msec=interval-1000*sec; 
    xt.nsec += 1000*1000*msec; 
    xt.sec+= sec; 
    boost::thread::sleep(xt);     
}

best wishes;-)

   

hi:
it really a trouble thing for me to use boost::thread::sleep()
:
boost::xtime helloworldtime;
 boost::xtime_get(&helloworldtime, boost::TIME_UTC);
 helloworldtime.sec += 6;
 boost::thread::sleep(helloworldtime);

i think
"boost::thread::sleep(1500) //millisecond   "
 may easy my programming;if have such interface;
now i use :

void thread_sleep(unsigned int interval) //millisecond
{
    boost::xtime xt;
    boost::xtime_get(&xt, boost::TIME_UTC);
    int sec=interval/1000;
    int msec=interval-1000*sec;
    xt.nsec += 1000*1000*msec;
    xt.sec+= sec;
    boost::thread::sleep(xt);    
}

best wishes;-)
 

(Continue reading)

hongleij | 1 Feb 2007 14:59
Favicon

[bind] how to get the type after bind

 //my question is how to write the type ??? below to make it run .

#include <boost/bind.hpp>
#include <iostream>
using boost::bind;
void print()
{
    std::cout <<" print" << std::endl;   
}

template <class T>
void func(T t)
{
    std::cout <<"func1(T t) : " ;
    t();       
}
int main()
{
    func(bind(&print));  //ok

    bind ( &func<???>, bind(&print) ) ; //don't know how to write it
}   

 //my question is how to write the type ??? below to make it run .

#include <boost/bind.hpp>
#include <iostream>
using boost::bind;
void print()
{
    std::cout <<" print" << std::endl;   
}


template <class T>
void func(T t)
{
    std::cout <<"func1(T t) : " ;
    t();       
}
int main()
{
    func(bind(&print));  //ok
          
    bind ( &func<???>, bind(&print) ) ; //don't know how to write it
} <at> 126.com>
 
 
 


想加入吗?1.9亿用户正在使用网易邮箱 www.126.com (Continue reading)

Marc Wäckerlin | 1 Feb 2007 15:06

Re: [boost::serialization] Cannot export any class[Re:Howto store derivedclasses through pointer to base ...]

Robert Ramey wrote:

> I believe that the only time BOOST_CLASS_EXPORT (or something like it)
> should be necessary is when one serializes a derived class through an
> abstract pointer.  It has two functions.  First, it ensures that code
> which would not be otherwise instantiated is in fact instantiated. 
> Second, it relates an externalizable text string to the type being
> serialized.

So I probably need to call it for the first reason (not for the second one).

Any Idea why there's a link problem?

BTW: The idea in my concept is, that you can only deserialize the correct
object, which contains preinitialized instances, so that these instances
know, what type they are, and how to deserialize. I'll probably post an
example, when it all works.

_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Lars Hagstro"m | 1 Feb 2007 15:53
Picon
Picon

Re: [boost-thread] why not writ e "sleep" in a better

Yep, I agree. The thread sleep function is terrible.
I'd like a function that takes a boost::posix_time::time_duration.
One solution could be to add a simple utility function that just takes a
time_duration and returns an xtime. Then you could do;

boost::thread::sleep(boost::to_xtime(boost::posix_time::microseconds(230)));

Cheers
Lars

hongleij <at> 126.com wrote:
> hi:
> it really a trouble thing for me to use boost::thread::sleep()
> :
> boost::xtime helloworldtime;
>  boost::xtime_get(&helloworldtime, boost::TIME_UTC);
>  helloworldtime.sec += 6;
>  boost::thread::sleep(helloworldtime);
> 
> i think
> "boost::thread::sleep(1500) //millisecond   "
>  may easy my programming;if have such interface;
> now i use :
> 
> void thread_sleep(unsigned int interval) //millisecond
> {
>     boost::xtime xt;
>     boost::xtime_get(&xt, boost::TIME_UTC);
>     int sec=interval/1000;
>     int msec=interval-1000*sec;
(Continue reading)

Doug Gregor | 1 Feb 2007 16:03
Picon
Picon
Favicon

Re: [signals] Automatic connection management and MT


On Jan 30, 2007, at 10:40 PM, Timmo Stange wrote:

> I'm working on a preliminary solution for an interface-compatible
> but thread-safe implementation of Signals for my project so that I
> will be able to switch to Boost.Signals should Doug Gregor find
> the time to add thread-safety there.

It is unlikely that I will ever find the time to do this, despite the  
fact that it is the most-requested feature in any piece of software I  
have ever written. I urge you (and Frank, and others that have gone  
down this path) to consider completing a thread-safe signals/slots  
library and submitting it to Boost. If you maintain (or nearly  
maintain) the Signals interface, I would be thrilled make your thread- 
safe implementation into Signals version 2, completely replacing the  
existing version.

	Cheers,
	Doug

Gmane