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
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 in the
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 code required
- 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 same RTL in
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
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_p('a'))
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:
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
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 static
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 discuss
the
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 link against the same
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 (which is
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 a
- 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 clear (and it
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 different from
David Abrahams wrote:
I have a problem while using the iterator_adaptor templates
in conjunction with a istreambuf_iteratorchar (an
input_iterator type). The problem shows up, because the
istreambuf_iteratorchar::operator*()
implementation of the STL I'm using returns a value_type
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
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 complicating the
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 think selecting a
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 I wasn't very clear
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 with the
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 documents
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 haven't seen
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
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
Hello,
I have observed a strange behaviour with shared_ptr:
struct A
{
shared_ptrint 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
[EMAIL PROTECTED] (Hartmut Kaiser) writes:
David Abrahams wrote:
I have a problem while using the iterator_adaptor templates
in conjunction with a istreambuf_iteratorchar (an
input_iterator type). The problem shows up, because the
istreambuf_iteratorchar::operator*()
implementation
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
Gennadiy.
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
Giovanni Bajo wrote:
Hello,
I have observed a strange behaviour with shared_ptr:
struct A
{
shared_ptrint 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
- 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++ Builder
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_iteratorchar (an input_iterator
type). The problem shows up, because the
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 thread local
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 majority of the
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 majority of the
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
specific type info. In
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 showstopper. It's much more
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
-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?
No; the
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_castT*(whatever) should return 0 on failure
and that should be enough for those who can't handle the exceptions we
want to
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
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 deemed
-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
From: Rozental, Gennadiy [EMAIL PROTECTED]
#include boost/io/format/std/vector.hpp
#include boost/io/format/std/map.hpp
#include boost/io/format/array.hpp
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
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_castT*(whatever) should return 0 on failure
and that should be enough for those who
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 important
than providing
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 define a
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 said in another
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
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
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
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.e., if
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.
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
inconvinience - it's showstopper.
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_ptrint. Parens would only
be needed if we wanted to say a.ptr.ptr()
The former has always
Firstly, I dont work for VTK, I am just a user, and I
dont 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
// In library Foo
void some_library_foo()
{
boost::thread_specific_ptrFoo 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(bar, );
[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
David Brownell said:
// In library Foo
void some_library_foo()
{
boost::thread_specific_ptrFoo 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()
{
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
60 matches
Mail list logo
