BoostBook is nearing the point where building documentation is as easy as
building libraries. The Boost.Build v2 modules for BoostBook (and
associated tools) are quite functional and work well for me, but I want to
verify the they will work well for someone else.
I would like a volunteer to try ou
David Brownell said:
>> // In library Foo
>>
>> void some_library_foo()
>> {
>>boost::thread_specific_ptr p;
>>// other stuff
>> }
>>
>> // In Application Bar which uses library Foo with out any knowledge //
>> that Foo used Boost.Threads
>> void bar()
>> {
>>some_library_foo();
>> }
>
[EMAIL PROTECTED] wrote:
[...]
> I would suspect your compiler. This works as expected (e.g., no
> assertions; they both evaluate to true) with Borland C++ Builder 5.6
> and GCC 3.2 prerelease.
Some compilers have problems with template class' cast operators. gcc 3.x
had similar problems with
> Spirit-devel mailing list
> [EMAIL PROTECTED]
Thanks, Joel. I've investigated further, learned something, and posted
a modified message there.
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> // In library Foo
>
> void some_library_foo()
> {
>boost::thread_specific_ptr p;
>// other stuff
> }
>
> // In Application Bar which uses library Foo with out any knowledge
> // that Foo used Boost.Threads
> void bar()
> {
>some_library_foo();
> }
>
> int main()
> {
>__beginthread
Firstly, I don’t work for VTK, I am just a user, and I
don’t want to start a war over what is the best cross-platform generator
but it seems to me that this might be worth looking into.
CMake was developed by Kitware as a cross-platform build
tool. Kitware has similar but worse problem
David Brownell said:
> Thank you very much for taking the time to answer those questions, I
> didn't know the situation was that compilcated! I guess I am still not
> sure what prevents the following from working:
>
> //User code
> void ThreadProc(void)
> {
> ...
> }
>
> boost::thread *pThrea
David Abrahams wrote:
> Am I crazy, or should there be a pair of parens after "ptr"?
To the latter question, no. In the example "ptr" refers to a public
data member of struct A, and is of type shared_ptr. Parens would only
be needed if we wanted to say "a.ptr.ptr()"
The former has alway
"Rozental, Gennadiy" <[EMAIL PROTECTED]> writes:
>> No, I am explicitly saying that if you want to avoid typeinfo maybe
>> you should also be forced to compromise and avoid exceptions too. I
>> think that would have the least negative impact on the design and I
>> like the trade-off it implies.
>
I have been very impressed with the Variant library and started using it
with Boost 1.29.
I now need to start to using Boost 1.30.0 though and I don't think the
variant library distributed for the review will work with the 1.30.0
release.
Does anyone have any suggestions how I can use the vari
David Abrahams wrote:
> "Edward Diener" <[EMAIL PROTECTED]> writes:
>
>> Terje Slettebø wrote:
From: "Rozental, Gennadiy" <[EMAIL PROTECTED]>
>>>
> Even if none of the above looks sound for you I still argue that
> lexical_cast *should not force* inclusion of typeinfo. It's not
> "
> Having a lexical_cast-specific macro will just cover that
> component, while
> the same issue could occur with another library, unless a Boost-wide
> configuration macro is used.
I am convinced. Moreover I know at least 1 more libraries that will need
such configuration - Serialization.
Gennna
> On 26 Mar 2003, Anthony Williams wrote:
> > It strikes me that if you dereference n iterators,
> you have n values, and the
> most natural way to store them is a tuple.
--- Douglas Paul Gregor <[EMAIL PROTECTED]> wrote:
> I would agree if tuples and argument passing were
> more closely linked,
>
> > I am afraid boost/io/format will be confusing in a sight of
> presence of
> > Boost.Format.
>
> I understand. Well, it's in a different namespace.
I do not know why BTW. But even if it stays this way, I easily see a newbie
looking for Boost.Format staff in your headers and vise-vesa
> The
Thank you very much for taking the time to answer those questions, I didn't
know the situation was that compilcated! I guess I am still not sure what
prevents the following from working:
//User code
void ThreadProc(void)
{
...
}
boost::thread *pThread = new boost::thread(ThreadProc);
//And
> No, I am explicitly saying that if you want to avoid typeinfo maybe
> you should also be forced to compromise and avoid exceptions too. I
> think that would have the least negative impact on the design and I
> like the trade-off it implies.
This trade-in is based on assumption that If I do not
>From: "Rozental, Gennadiy" <[EMAIL PROTECTED]>
> > Another way may be a macro. However, as has been mentioned in
> > this thread,
> > it appears that the config macros aren't geared for macros
> > with optional
> > exclusion of RTTI.
>
> No. this has nothing to do with config
Well, as Dave A sai
David Brownell said:
>> The user can just call the method for every thread which uses
> Boost.Threads
>> in a static library implementation. If a library ( LIB ) function uses
>> Boost.Threads internally, then it is up to the library function
> implementor
>> to document this and iteratively defin
>From: "David Abrahams" <[EMAIL PROTECTED]>
> "Rozental, Gennadiy" <[EMAIL PROTECTED]> writes:
>
> >> Even if none of the above looks sound for you I still argue that
> >> lexical_cast *should not force* inclusion of typeinfo. It's not
> >> "inconvinience" - it's showstopper. It's much more import
"Rozental, Gennadiy" <[EMAIL PROTECTED]> writes:
>> My contribution to the discussion is that I don't think supporting C++
>> language subsets is worth complicating the interface in the way you
>> propose. Maybe lexical_cast(whatever) should return 0 on failure
>> and that should be enough for th
>From: "Rozental, Gennadiy" <[EMAIL PROTECTED]>
> > #include
> > #include
> > #include
>
> I am afraid boost/io/format will be confusing in a sight of presence of
> Boost.Format.
I understand. Well, it's in a different namespace.
> I would prefer (since it all about container output formattin
-Original Message-
From: Vladimir Prus [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2003 10:25 AM
To: Boost mailing list
Subject: Re: [boost] boost::any feature request
[]
P.S. And, BTW, it would be great to see the complete code that you
propose (or
a diff to CVS HEAD).
Here are
> I'd certainly be open to make the type_info part optional. A
> question is how to do it.
>
> Using policies may complicate the interface, and from earlier
> discussions,
> and also from the earlier "Future directions" part of the
> docs, it turned
> out that adding new parameters weren't deem
At 01:30 PM 3/26/2003 -0500, you wrote:
The user can just call the method for every thread which uses Boost.Threads
in a static library implementation. If a library ( LIB ) function uses
Boost.Threads internally, then it is up to the library function implementor
to document this and iteratively def
> The user can just call the method for every thread which uses
Boost.Threads
> in a static library implementation. If a library ( LIB ) function uses
> Boost.Threads internally, then it is up to the library function
implementor
> to document this and iteratively define a function which can be call
> My contribution to the discussion is that I don't think supporting C++
> language subsets is worth complicating the interface in the way you
> propose. Maybe lexical_cast(whatever) should return 0 on failure
> and that should be enough for those who can't handle the exceptions we
> want to throw
> Type_info is part of the C++ standard. I don't understand the
> turning off of this in C++ code, but even it is done for an
> implementation,
Let me clrify again that I don't think that this is the feature optionally
supported by compilers. By now almost all cvompilers I know supports RTTI
on
> -Original Message-
> From: Michael Glassford [mailto:[EMAIL PROTECTED]
>
> The "Future Directions" section of the Boost Pool Library documentation
says
> that "Another pool interface will be written: a base class for per-class
> pool allocation.". Has any progress been made in this area?
hi,
for several times i used a small utility class, so i thought it might be
interesting for boost too.
it takes pairs of arguments and compares them pairwise beginning with
the first one.
an example usage would be a special sorting operators:
struct position
{
double x, y, z;
};
bool op
"Edward Diener" <[EMAIL PROTECTED]> writes:
> Terje Slettebø wrote:
>>> From: "Rozental, Gennadiy" <[EMAIL PROTECTED]>
>>
Even if none of the above looks sound for you I still argue that
lexical_cast *should not force* inclusion of typeinfo. It's not
"inconvinience" - it's showstopp
Terje Slettebø wrote:
>> From: "Rozental, Gennadiy" <[EMAIL PROTECTED]>
>
>>> Even if none of the above looks sound for you I still argue that
>>> lexical_cast *should not force* inclusion of typeinfo. It's not
>>> "inconvinience" - it's showstopper. It's much more important
>>> than providing
>>>
"Rozental, Gennadiy" <[EMAIL PROTECTED]> writes:
>> Even if none of the above looks sound for you I still argue that
>> lexical_cast *should not force* inclusion of typeinfo. It's not
>> "inconvinience" - it's showstopper. It's much more important
>> than providing
>> specific type info. In major
The "Future Directions" section of the Boost Pool Library documentation says
that "Another pool interface will be written: a base class for per-class
pool allocation.". Has any progress been made in this area?
Also, what about an allocator that takes the size of memory to be allocated
and forwards
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> Giovanni Bajo wrote:
>> Hello,
>>
>> I have observed a strange behaviour with shared_ptr:
>>
>> struct A
>> {
>>shared_ptr ptr;
>>
>>operator bool()
>>{ return ptr; }
>> };
>>
>> A a;
>> a.ptr.reset(new int);
>> assert(a.ptr);
>> assert(a);
>
>From: "Rozental, Gennadiy" <[EMAIL PROTECTED]>
> > Even if none of the above looks sound for you I still argue that
> > lexical_cast *should not force* inclusion of typeinfo. It's not
> > "inconvinience" - it's showstopper. It's much more important
> > than providing
> > specific type info. In ma
William E. Kempf wrote:
> Edward Diener said:
>> William E. Kempf wrote:
>>> David Brownell said:
I am curious as to why the new version of the Thread library does
not provide a static library in the 1.30 version of boost. After
reading some initial posts, I have seen references to
David Abrahams wrote:
> [EMAIL PROTECTED] (Hartmut Kaiser) writes:
>
> > David Abrahams wrote:
> >
> >> >> I have a problem while using the iterator_adaptor templates in
> >> >> conjunction with a istreambuf_iterator (an input_iterator
> >> >> type). The problem shows up, because the
> >> >> is
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, March 26, 2003 7:02 PM
Subject: RE: [boost] shared_ptr operator bool
> I would suspect your compiler. This works as expected (e.g., no
assertions;
> they both evaluate to true) with Borland C++ Build
> -Original Message-
> From: Giovanni Bajo [mailto:[EMAIL PROTECTED]
>
> I have observed a strange behaviour with shared_ptr:
>
> struct A
> {
>shared_ptr ptr;
>
>operator bool()
>{ return ptr; }
> };
>
> A a;
> a.ptr.reset(new int);
> assert(a.ptr);
> assert(a);
>
> Now, t
Giovanni Bajo wrote:
> Hello,
>
> I have observed a strange behaviour with shared_ptr:
>
> struct A
> {
>shared_ptr ptr;
>
>operator bool()
>{ return ptr; }
> };
>
> A a;
> a.ptr.reset(new int);
> assert(a.ptr);
> assert(a);
>
> Now, the second assertion fails (Comeau). It works if for
> In your original e-mail, you asked for a solution to the
> multiple function
> definition error. Wouldn't using a mechanism similar to
> cpp_main work? Ie, put
> the init_unit_test_suite() definition in a CPP file that only
> gets included
> once, such as:
>
> #include
>
> Which in turn inc
> Even if none of the above looks sound for you I still argue that
> lexical_cast *should not force* inclusion of typeinfo. It's not
> "inconvinience" - it's showstopper. It's much more important
> than providing
> specific type info. In majority of the cases one knows it anyway.
>
> > Kevlin
>
> #include
> #include
> #include
I am afraid boost/io/format will be confusing in a sight of presence of
Boost.Format.
I would prefer (since it all about container output formatting)
boost/io/container
Also it could be stl instead of std, though it's the matter of taste.
> std::cout << forma
[EMAIL PROTECTED] (Hartmut Kaiser) writes:
> David Abrahams wrote:
>
>> >> I have a problem while using the iterator_adaptor templates
>> >> in conjunction with a istreambuf_iterator (an
>> >> input_iterator type). The problem shows up, because the
>> >> istreambuf_iterator::operator*()
>> >> im
Hello,
I have observed a strange behaviour with shared_ptr:
struct A
{
shared_ptr ptr;
operator bool()
{ return ptr; }
};
A a;
a.ptr.reset(new int);
assert(a.ptr);
assert(a);
Now, the second assertion fails (Comeau). It works if for example I change
my operator bool into "return ptr ?
William E. Kempf wrote:
You can do this simply by placing the applications in seperate directories
and keeping the proper DLL version alongside the executable. Not
necessarily the ideal solution, but it's the easiest way to solve "DLL
Hell".
The reason I've not done this (and want to go to the 've
Hi.
I've now uploaded the latest version of the composite stream operators
library at Yahoo Files
(http://groups.yahoo.com/group/boost/files/composite_stream_operators/) and
the Sandbox (boost/io/format/ and libs/io/format)..
Since the libraries in the Sandbox use the boost namespace, this one do
Edward Diener said:
> William E. Kempf wrote:
>> David Brownell said:
>>> I am curious as to why the new version of the Thread library does not
>>> provide a static library in the 1.30 version of boost. After reading
>>> some initial posts, I have seen references to thread local storage,
>>> but
William E. Kempf wrote:
> David Brownell said:
>> I am curious as to why the new version of the Thread library does not
>> provide a static library in the 1.30 version of boost. After reading
>> some initial posts, I have seen references to thread local storage,
>> but haven't seen anything that d
Russell Hind said:
> William E. Kempf wrote:
>>
>> Theoretically at least, I don't see why this would cause a problem.
>> You intentionally leak, but the leak is benign since it occurs only
>> right before the application exits. But most users won't code this
>> way, nor do I want to have to deal
vc said:
>
> - Original Message -
> From: "William E. Kempf" <[EMAIL PROTECTED]>
>> > Doing so, the boost.thread will be build with the /MTd flag (for
>> debug). This is exactly
>> > what you said that it won't be a good idea, right? Or am I missing
>> something here?
>>
>> Sorry, I guess
Peter Dimov said:
> William E. Kempf wrote:
>> Peter Dimov said:
>>>
>>> I agree with the suggestion. The default should be /W3 for VC 6, and
>>> /W4 (possibly with some specific warnings disabled) on VC 7+.
>>
>> Why /W4 for VC 7+? The IDE's default is still /W3 on these
>> compilers. I don't t
Douglas Paul Gregor <[EMAIL PROTECTED]> writes:
> On 26 Mar 2003, Anthony Williams wrote:
> > It strikes me that if you dereference n iterators, you have n values, and
> > the most natural way to store them is a tuple. Doing anything other than
> > returning this tuple seems to me just complicatin
William E. Kempf wrote:
Theoretically at least, I don't see why this would cause a problem. You
intentionally leak, but the leak is benign since it occurs only right
before the application exits. But most users won't code this way, nor do
I want to have to deal with the support requests/questions
David Abrahams wrote:
> >> I have a problem while using the iterator_adaptor templates
> >> in conjunction with a istreambuf_iterator (an
> >> input_iterator type). The problem shows up, because the
> >> istreambuf_iterator::operator*()
> >> implementation of the STL I'm using returns a value_ty
William E. Kempf wrote:
> Peter Dimov said:
>>
>> I agree with the suggestion. The default should be /W3 for VC 6, and
>> /W4 (possibly with some specific warnings disabled) on VC 7+.
>
> Why /W4 for VC 7+? The IDE's default is still /W3 on these
> compilers. I don't think selecting a level diffe
- Original Message -
From: "William E. Kempf" <[EMAIL PROTECTED]>
> > Doing so, the boost.thread will be build with the /MTd flag (for debug).
> > This is exactly
> > what you said that it won't be a good idea, right? Or am I missing
> > something here?
>
> Sorry, I guess I wasn't very cle
I took a look at the auto_unit_test.hpp source code. I believe that we are both
correct. The GCC "#pragma interface" feature lets it all work for me. I have a
pretty good idea how, but that is outside the scope of this thread. Rest
assured, I use BOOST_AUTO_UNIT_TEST across a dozen source files in
Peter Dimov said:
> William E. Kempf wrote:
>>
>> I guess I'm wondering if the official toolsets shouldn't be changed. I
>> don't understand why the MSDN indicates it should default to /W2 while
>> we're seeing it default to what I assume is /W1. But, projects
>> created by the IDE default to /W3
vc said:
>
> - Original Message -
> From: "William E. Kempf" <[EMAIL PROTECTED]>
>
>
>>
>> vc said:
>> >> As for the warnings themselves... I'm still doing more research
>> just to be 100% sure, but everything I've found thus far indicates
>> you can ignore these warnings as long as you li
Russell Hind said:
> I'd been wondering this, and heard about TLS issues. The issues are
> only on Windows it appears. Search for the thread
>
> "Fwd: Thread-Local Storage (TLS) and templates" by Greg Colvin on
> 18/02/2003
>
> Specifically, the many posts by William Kempf and Edward Diener disc
David Brownell said:
> I am curious as to why the new version of the Thread library does not
> provide a static library in the 1.30 version of boost. After reading
> some initial posts, I have seen references to thread local storage, but
> haven't seen anything that documents why this makes a sta
Paul A. Bristow said:
> I was surprised to find that /Wp64 flag (detect 64-bit portability)
>
> means that std::size_t is 64 bit. This leds to a number of oddities
> that confused me. Is this perhaps causing your problem?
AFAIK and AFAICT, /Wp64 is not used.
--
William E. Kempf
___
Alexander Nasonov wrote:
> Lambda cannot deduce return type of *begin. What should I do? May be some
> kind of traits or nested template should be defined for any?
I've just found it in lambda documentation.
BTW, I have some progress in the library. Reference section is partially
done:
http://cpp
Dave Gomboc wrote:
> When I define rules x, y, and z such that
>
> x = ch_p('a');
> y = ch_p('a');
> z = !x >> y;
>
> it appears to operate the same as if z were defined to be
>
> z = (ch_p('a') | epsilon_p) >> 'a';
>
> which accepts "aa", but rejects "a".
>
>
> On the other h
I'm trying to define any_pointer using dynamic_any library. Everything is
fine except lambda support. I can't compile this:
any_int_pointer begin, end; // see example below for details
std::for_each(begin, end, std::cout << x);
Lambda cannot deduce return type of *begin. What should I do
On 26 Mar 2003, Anthony Williams wrote:
> It strikes me that if you dereference n iterators, you have n values, and the
> most natural way to store them is a tuple. Doing anything other than returning
> this tuple seems to me just complicating the usage.
I would agree if tuples and argument passin
William E. Kempf wrote:
>
> I guess I'm wondering if the official toolsets shouldn't be changed.
> I don't understand why the MSDN indicates it should default to /W2
> while we're seeing it default to what I assume is /W1. But, projects
> created by the IDE default to /W3 (which is also the level
Paul A. Bristow wrote:
> I was surprised to find that /Wp64 flag (detect 64-bit portability)
> means that std::size_t is 64 bit. This leds to a number of oddities
> that confused me. Is this perhaps causing your problem?
std::size_t is still 32 bit, /Wp64 generates warnings if the meaning of th
When I define rules x, y, and z such that
x = ch_p('a');
y = ch_p('a');
z = !x >> y;
it appears to operate the same as if z were defined to be
z = (ch_p('a') | epsilon_p) >> 'a';
which accepts "aa", but rejects "a".
On the other hand, if I define z as
z = (epsilon_p | ch_
Kirill wrote:
>Given that boost.random does not have an active maintainer, who could
take
>a look into this?
There has been some private discussion going on in the background.
Hopefully there will be an announcement within a day or two.
In the meantime, keep posting any fixes here - they are d
- Original Message -
From: "William E. Kempf" <[EMAIL PROTECTED]>
>
> vc said:
> >> As for the warnings themselves... I'm still doing more research just
> >> to be 100% sure, but everything I've found thus far indicates you can
> >> ignore these warnings as long as you link against the s
Thomas Becker <[EMAIL PROTECTED]> writes:
> > Anthony Williams wrote:
> > The particular example I cited in the
> > article is where a colleague
> > had a pair of vectors which were the x and y values
> > respectively for a
> > graph. They were supplied as two vectors, and the
> > graph drawing co
> Anthony Williams wrote:
> The particular example I cited in the
> article is where a colleague
> had a pair of vectors which were the x and y values
> respectively for a
> graph. They were supplied as two vectors, and the
> graph drawing code required
> them as two vectors, yet the analysis code
I'd been wondering this, and heard about TLS issues. The issues are
only on Windows it appears. Search for the thread
"Fwd: Thread-Local Storage (TLS) and templates" by Greg Colvin on 18/02/2003
Specifically, the many posts by William Kempf and Edward Diener discuss
the problems on windows wi
75 matches
Mail list logo