Re: [TR1] Configuration macros

John Maddock wrote:
> That's the intention

Okay, so far so good.

> BOOST_HAS_TR1 tells the lib to use the platform's native TR1 implementation 
> for *everything*, if you want to just use the native support for *something* 
> then you have to turn it on on a case by case basis for each component where 
> you want to use the platform-supplied version.

Now I'm confused, because this doesn't seem consistent with the above.  This 
makes it sound like I need to know which TR1 components are supported by my 
compiler/library and I need to explicitly enable them.  Is that really the case?

> VC8: define nothing there's no native TR1 support, unless you've bought the 
> Dinkumware add-on in which case define BOOST_HAS_TR1 to make use of it.

Which is consistent with the "explicitly specify what your compiler/library 
support" idea above.  Unfortunately 

> gcc: nothing if you're happy with the Boost versions, BOOST_HAS_GCC_TR1 if 
> you want to use the gcc-supplied versions.  It's possible that 
> BOOST_HAS_GCC_TR1 is somewhat out of date, I don't recall now which gcc 
> version I tested with, but 4.2 probably has more TR1 support than it 
> currently enables.

Which means that the macro doesn't mean "turn on whatever gcc TR1 support you 
have," it means "turn on the following TR1 components that I, the macro writer, 
believe are supported by gcc." Again, consistent with the above.  And, again, 
unfortunately 

Re: [Unit Test] default FPC_STRONG limtationswhenchecking close to 0.

"Chris Fairles" <chris.fairles <at> gmail.com> wrote in message 
news:fac6bb500705311219s4a447924p26dd6d5d8945793c <at> mail.gmail.com...
> Thanks for the suggestion, tried a few things. I have
> #define CHECK_IS_CLOSE_WEAK(x, y, t) \
> boost::test_tools::check_is_close((x),(y),
> boost::test_tools::percent_tolerance(t), boost::test_tools::FPC_WEAK)
>
> which works fine with when either x or y is 0. I tried the predicate
> method, something like:

This is wrong. check_is_close can't return true if either x or y is zero 
regardless of weak/strong flag. Relative errors are 1 and Inf. Both are more 
than 1e-05

> BOOST_CHECK_PREDICATE(boost::test_tools::check_is_close,
> (first)(second)(boost::test_tools::percent_tolerance( e
> ))(boost::test_tools::FPC_WEAK))
>
> But this fails
> check boost::test_tools::check_is_close( m_cmp(i,j), m(i,j),
> boost::test_tools::percent_tolerance( tolerance ),
> boost::test_tools::FPC_WEAK ) failed for ( 0, -2.2204460492503131e-16,
> 1e-05, 1 )

As expected.

> Am I not using the predicate correctly?

You should use differerent predicate, which uses check_is_close in regular 

Re: [interprocess]

Hi,

On 5/31/07, Aaron W. LaFramboise <aaronrabiddog51 <at> aaronwl.com> wrote:
> (2) It's been brought up before, but there seriously needs to be a way
> to grow managed shared memory segments.  I understand that this is
> really tricky to implement, and probably just as tricky to use safely,
> but it's an important feature, in my opinion.  I guess the main
> difficulties here are the potential change of base, and atomicity?

I have a similar requirement. Something like a pool of shared memory
blocks that can work as a stream. Since it is impossible to always
grow a reserved chunk of memory at the same base address, you will
have to create a pool (or the crude realloc type which beats
scalability and performance). IMHO, it is ideal to develop a pool of
shared memory each with their own base addresses and implement all the
intelligence of traversing, seek and functionalities using an
ITERATOR. Iterator can become an abstract interface to the underlying
memory.
 I have implemented a class of my own (not along the BOOST lines) as a
 proof of concept and left it incomplete (needs debugging and fixing
the traversing part - Iterator).

with best regards,
dhruva

--

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: [Boost.Test 1.34] Multiple instances of unit_test_log_t singleton

> "Kolya Kosenko" <wxkolya <at> gmail.com> wrote in message 
> news:4659BEE9.9040907 <at> gmail.com...
> This bug exists at msvc-6.0 and msvc-7.1 when precompiled headers is used. 
> It is *not* exits at msvc-8.0
> at all. I have no msvc-7.0 so I suppose it behavior is similar to 
> msvc-7.1.
>
> Also I have following linker error at msvc-6.0 when I have solved previous 
> problem:
> filemain.obj : error LNK2005: "bool boost::test_tools::`anonymous 
> namespace'::dummy_cond" (?dummy_cond@?
> %..\..\boost/test/unit_test_log.hpp1238016409 <at> test_tools <at> boost@@3_NA) 
> already defined in pch.obj
>
> This patches should fix both problems:
> ==========
> --- boost/boost/test/utils/trivial_singleton.hpp    2006-01-01 
> 19:29:38.000000000 +0200
> +++ boost/boost/test/utils/trivial_singleton.hpp.patched    2007-05-27 
> 20:00:15.031250000 +0300
> @@ -55,6 +55,10 @@
>  #define BOOST_TEST_SINGLETON_INST( inst ) \
>  static BOOST_JOIN( inst, _t)& inst = BOOST_JOIN (inst, _t)::instance();
>
> +#elif BOOST_WORKAROUND(BOOST_MSVC, < 1400)
> +#define BOOST_TEST_SINGLETON_INST( inst ) \
> +namespace { static BOOST_JOIN( inst, _t)& inst = BOOST_JOIN( inst, 
> _t)::instance(); }

Re: [TR1] Configuration macros

Scott Meyers wrote:
> Which is consistent with the "explicitly specify what your
> compiler/library support" idea above.  Unfortunately 

Right, but please remember that there is only one compiler that ships with 
*any* TR1 support at all - gcc - and that was still in the very early stages 
of development when Boost.TR1 was developed.  Given time it'll get smarter 
and "learn" about more compilers/platforms as they release TR1 support - if 
they do.

>> gcc: nothing if you're happy with the Boost versions,
>> BOOST_HAS_GCC_TR1 if you want to use the gcc-supplied versions.
>> It's possible that BOOST_HAS_GCC_TR1 is somewhat out of date, I
>> don't recall now which gcc version I tested with, but 4.2 probably
>> has more TR1 support than it currently enables.
>
> Which means that the macro doesn't mean "turn on whatever gcc TR1
> support you have," it means "turn on the following TR1 components
> that I, the macro writer, believe are supported by gcc." Again,
> consistent with the above.  And, again, unfortunately 
>
> I'd hoped that Boost.TR1 would magically figure out what TR1 stuff
> was available from my compiler/library and use that by default,
> falling back on Boost functionality only when necessary.  Apparently
> that is not the way it works 

Not yet   As I say, it'll learn.

John. 

Re: [date_time] UNICODE and wcout problems

> I did some debugging on the matter and I suspect that the line 
> boost/date_time/posix_time/posix_time_io.hpp:61 is the culprit. It 
> changes the locale of wcout and whatever machinery should revert this 
> back, it does not. This agrees with my observation that using a 
> wostringstream for formatting does not damage wcout.
>
> What do you think?
>   
No ideas? I really think that the above code is defective. Should I 
submit a bug report then?

Cheers,
Filip

Re: Bind & Memory Leakage

Sudhir Parikh wrote:
> BoundsChecker is reporting a memory leak for every 'bind' call. I am
> using the threadpool includes, v 0.2.3, with
> "libboost_thread-vc71-mt-gd-1_33_1.lib", MSVC 7.1. Any help is
> appreciated.

Bind doesn't allocate any memory.

[BGL] boost::bind fails to compile when used with edge iterators in for_each

Hi

I'm trying to run a functor over edges from a graph using for_each
however it fails when the iterators are edges. The same technique
works for iterators to vertices. Here is the compiler error:

g++ -o bind_edge_test bind_edge_test.cpp
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/g++-v4/bits/stl_algo.h:
In function '_Function std::for_each(_InputIterator, _InputIterator,
_Function) [with _InputIterator =
boost::detail::undirected_edge_iter<std::_List_iterator<boost::list_edge<void*,
boost::property<boost::edge_name_t, unsigned int, boost::no_property>
> >, boost::detail::edge_desc_impl<boost::undirected_tag, void*>,
int>, _Function = boost::_bi::bind_t<void, Op,
boost::_bi::list2<boost::arg<1>, boost::_bi::value<int> > >]':
bind_edge_test.cpp:79:   instantiated from here
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/include/g++-v4/bits/stl_algo.h:159:
error: no match for call to '(boost::_bi::bind_t<void, Op,
boost::_bi::list2<boost::arg<1>, boost::_bi::value<int> > >)
(boost::detail::edge_desc_impl<boost::undirected_tag, void*>)'

I've attached the file. Thanks for the help.

--

-- 
sashan
http://sashang.orcon.net.nz/

_______________________________________________

[thread_safe_signals] won't compile on VC71

Hello,

I'm very impressed from Mr. Hess' work on thread safe signals for the
boost library. In my opinion it's a great step to provide thread safe
signals in a common library like boost and I like to use it as
replacement for third party libs.

Unfortunately I going in trouble when using the latest version of this
module (thread_safe_signals-2007-03-19.tgz which is the same as out of
the cvs). I can't get it compile on Microsoft VS71. I tried with gcc and
VS8 and it works but for the VS71 compiler which we are working it fails.

As mentioned in the documentation I included the headers of
thread_safe_signals before the normal boost headers which are in fact
1_33_1 (same results with 1_34_0). The I picked up a sample project
signal_test.cpp from boost/test/ and start to compile it but it fails
with the following compiler hints:

Kompilieren...
signal_test.cpp
...\thread_safe_signals\boost\thread_safe_signals\detail\slot_template.hpp(95)
: error C2143: Syntaxfehler: Es fehlt ',' vor '&'

...\thread_safe_signals\boost\thread_safe_signals\detail\slot_template.hpp(109):
Siehe Verweis auf Instanziierung der kompilierten Klassenvorlage
'boost::slot0<R,SlotFunction>'
...\thread_safe_signals\boost\thread_safe_signals\detail\slot_template.hpp(95)
: error C2143: Syntaxfehler: Es fehlt ',' vor '&'

...\thread_safe_signals\boost\thread_safe_signals\detail\slot_template.hpp(109):

[tokenizer] position of tokenizer

Hi

Is that possible to take actual position of the tokenizer in the parsed 
string?

The question is motivated by such a case:

1. there is a line with data separated by e.g. "\t' sign

1 23 3.45 21 2093 494 3.4

2. important is only some of them let say from 2nd token to 5th token, but 
after parsing them I want to pass tokens from 6th to the end to the other 
string.

Now I am iterating tokenizer to the end, and concatenate it. If I have had a 
position of tokenizer on the string I can simply create  new substring with 
out iteration.

Maybe there is other solution for that.

Regards.

--

-- 

|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/ 
_______________________________________________
Boost-users mailing list
Boost-users <at> lists.boost.org