[boost] Re: Thread Lib and DLL
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 with TLS cleanup. I do have a question on this issue: If this problem is only to do with TLS cleanup when a thread exits, then if all threads are created when the program starts and only destroyed when the program exited, then, in practice, could this really be an issue? I.e. if we only work like this, could building thread as a static lib cause problems providing that we don't let threads exit in the middle of the program? We're currently really trying to stay clear of any DLLs. Cheers Russell David Brownell wrote: 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 library impossible. All thing considered, I find a static library is much more desirable than a dll. Thanks! David Brownell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Determining interest in combining_iterator
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 middle required a sequence of (x,y) pairs I have to admit this very example has convinced me that my original approach is right. Suppose we were to write, as you suggest, an iterator adaptor that holds a tuple of iterators and, upon dereferencing, returns a tuple made from the dereferenced iterators. What would we have done for the person in your example? Nothing. He needs a *pair*, not a tuple. The big picture is: we want an iterator that parallel-iterates through several sequences, and upon dereferencing, applies some user-defined (via a functional) prossesing to the dereferenced iterators. If the desired result is a pair, supply a functional that makes a pair from its arguments. In my applications, I want a number that is calculated from the dereferenced iterators, so I supply something like std::divides. If the desired result is a tuple made from the dereferenced iterators, no problem, supply a functional that makes a tuple from its arguments. If we used your approach, we would give this one special type of processing, where a tuple is made from the dereferenced iterators, a very special and prominent place in the design. Why? It's just one of infinitely many things that someone might want to do. (Ironically, it's the one for which we have not seen a real-life need.) My general approach covers it with no fuss and no overhead. One simple iterator adaptor that does it all. We get everything that we would get in your approach, and it's simpler and more user-friendly. Unless I'm missing something... Thomas Becker Zephyr Associates, Inc. Zephyr Cove, NV [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Determining interest in combining_iterator
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
them as two vectors, yet the analysis code in the
middle required a sequence
of (x,y) pairs
I have to admit this very example has convinced me
that my original approach is right. Suppose we were to
write, as you suggest, an iterator adaptor that holds
a tuple of iterators and, upon dereferencing, returns
a tuple made from the dereferenced iterators. What
would we have done for the person in your example?
Nothing. He needs a *pair*, not a tuple. The big
picture is: we want an iterator that parallel-iterates
through several sequences, and upon dereferencing,
applies some user-defined (via a functional)
prossesing to the dereferenced iterators. If the
desired result is a pair, supply a functional that
makes a pair from its arguments. In my applications, I
want a number that is calculated from the dereferenced
iterators, so I supply something like std::divides. If
the desired result is a tuple made from the
dereferenced iterators, no problem, supply a
functional that makes a tuple from its arguments. If
we used your approach, we would give this one special
type of processing, where a tuple is made from the
dereferenced iterators, a very special and prominent
place in the design. Why? It's just one of infinitely
many things that someone might want to do.
(Ironically, it's the one for which we have not seen a
real-life need.) My general approach covers it with no
fuss and no overhead. One simple iterator adaptor that
does it all. We get everything that we would get in
your approach, and it's simpler and more
user-friendly. Unless I'm missing something...
A pair is just a special case of a tuple, and a std::pair can be trivially
created from a tuple if really necessary, so that's just a distraction. If my
colleague had had a z axis on his graph we would have needed a triple.
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.
How do you write the following with your combining iterator? (TupleIt is a
supposed generalisation of my PairIt which returns a tuple rather than a pair)
std::vectorT1 first;
std::vectorT2 second;
std::vectorT3 third;
typedef TupleItstd::vectorT1::iterator,
std::vectorT2::iterator,
std::vectorT3::iterator
::value_type TupleType;
// could make it a functor with a templated operator() to remove the
// dependency on the specifics of TupleType
bool myCompareFunc(const TupleType lhs,const TupleType rhs)
{
return lhs.get0() rhs.get0();
}
std::sort(makeTupleIterator(first.begin(),second.begin(),third.begin()),
makeTupleIterator(first.end(),second.end(),third.end()),
myCompareFunc);
Anthony
--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
- 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 both the Boost.Threads DLL and the application. After I verify this, I'll remove the warnings through the use of pragmas. So, is it ok if for the boost.thread dll and for the app I will use the /MT flag (multi-threaded) instead of /MD (multi-threaded dll) that you are using when building with bjam? According to what I'm reading about these warnings, no, that wouldn't be a good idea. However, you can build against the static RTL easy enough. In the $BOOST_ROOT/libs/thread/build directory issue the following bjam command: bjam -sBUILD=runtime-linkstatic 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? If this is not such a good idea (building the boost.thread dll with the /MT flag) what else can I do, as I have my app depending on tons of libs that are already built with /MT flag meaning that all the modules should be built with the same flag (if you mix the modules with the /MT flag and /MD flag, the final app will have links errors) ? Thanks, Viv ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] random and msvc6
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 definitely appreciated! --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] spirit 1.6 parsing question
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')) 'a'
then a is accepted, but aa is rejected.
(These are, of course, not the actual rules I am interested in, but a vast
simplification of them, focusing on the point of interest.)
My original expectation had been that first the choice on the left side of
the or operation would be attempted, but when ultimately failing to match
the entire string later on, to then backtrack and attempt matching via the
choice on the right side of the or. How can I achieve this behaviour?
In the real problem the semantic actions associated with x and y are
different, but the inputs they match individually have significant
overlap, and where they do overlap, I need y to be matched rather than x.
On a related note, when I defined BOOST_SPIRIT_DEBUG before #including the
core, and specified BOOST_SPIRIT_DEBUG_RULE(test); in my grammar I
received the following error message using g++-3.2.2 on linux-i686:
test_grammar.hpp:45: ISO C++ forbits declaration of `get_node_registry'
with no type
test_grammar.hpp:45: invalid use of `::'
test_grammar.hpp:45: syntax error before `.' token
Any idea what I might be doing wrong?
Also, please let me know if I should be asking this on a spriit-specific
list rather than boost's.
Thanks,
Dave
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: lambda support for dynamic_any
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-experiment.sourceforge.net/boost/libs/dynamic_any/doc/any.html But there are number of problems. I hope to discuss some of them at ACCU. -- Alexander Nasonov Remove minus and all between minus and at from my e-mail for timely response ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] VC7/Threads Warnings
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 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Thread Lib and DLL
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 library impossible. All thing considered, I find a static library is much more desirable than a dll. It has been discussed numerous times on this list, as well as on the Users list. TLS cleanup can only be done on the Win32 platform with code in the thread itself (which won't work for threads created outside of Boost.Threads) or with code in DllMain. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Thread Lib and DLL
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 problems on windows with TLS cleanup. I do have a question on this issue: If this problem is only to do with TLS cleanup when a thread exits, then if all threads are created when the program starts and only destroyed when the program exited, then, in practice, could this really be an issue? I.e. if we only work like this, could building thread as a static lib cause problems providing that we don't let threads exit in the middle of the program? We're currently really trying to stay clear of any DLLs. 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 this would cause. So, unless you have some suggestion as to how I can enable this usage with out causing confusion, I'm not sure I'd care to re-enable static builds. But you could probably fairly easily hack things to build that way yourself. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
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 RTL in both the Boost.Threads DLL and the application. After I verify this, I'll remove the warnings through the use of pragmas. So, is it ok if for the boost.thread dll and for the app I will use the /MT flag (multi-threaded) instead of /MD (multi-threaded dll) that you are using when building with bjam? According to what I'm reading about these warnings, no, that wouldn't be a good idea. However, you can build against the static RTL easy enough. In the $BOOST_ROOT/libs/thread/build directory issue the following bjam command: bjam -sBUILD=runtime-linkstatic 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 looks like it may have been less clear, because I misunderstood your question). What's not a good idea is mixing the RTLs. If you want to use /MT(d) then you should compile Boost.Threads with /MT(d) as well. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
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 also the level recommended by the MSDN), so it makes sense to me that we should probably do the same? Otherwise, users are likely to see warnings that we don't represent in the regression logs. 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 the compiler's/IDE's default is necessarily a good idea. Of course, what *would* be nice is to have some way to specify this portably for all toolsets. IOW, the default would be to use what's considered a normal level for the toolset, but warningsall could be used to crank it up to full. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: patch: BOOST_AUTO_UNIT_TEST in auto_unit_test.hpp
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 single
application, and they are all being identified and run correctly. Yes, I got
lucky and didn't even know it.
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 boost/test/included/auto_unit_test.hpp
Which in turn includes
#include libs/test/src/auto_unit_test.cpp
I still stand by my original patch submission. Although, as you pointed out,
for the vast majority of users, it is of no value. However, it worked for me,
and it is likely to help others in the future.
Hmmm. It works for me. I'm using BOOST_AUTO_UNIT_TEST across several of my
source files without name collisions (after my patch). I'm also using the
GCC
#pragma interface feature, which might make a difference. Pardon my
ignorance, since I'm not very familiar with the auto unit test
implementation.
I couldn't imagine how it may work. Each module will have following:
static boost::unit_test_framework::test_suite* test = BOOST_TEST_SUITE(
Auto Unit Test );
boost::unit_test_framework::test_suite*
init_unit_test_suite( int /* argc */, char* /* argv */ [] ) {
return test;
}
So. You should get symbols conflicts. Even if compiler/linker is able to
somehow choose and bind one of multiple init_unit_test_suite with library
call, it still should only run tests registered in selected module.
I would not play on such shaky grounds.
Gennadiy.
__
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
- 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 looks like it may have been less clear, because I misunderstood your question). What's not a good idea is mixing the RTLs. If you want to use /MT(d) then you should compile Boost.Threads with /MT(d) as well. Thanks a lot for the answer! This is what I wanted to know: If I can build the boost.thread dll and the app with the /MT flag instead of /MD flag. Regarding the mixing of the RTLs the last versions of VC++ gives you a link warning if you try to do that ... Thanks again, Viv -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
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 the compiler's/IDE's default is necessarily a good idea. My opinion only. /W4 was a bit painful for VC 6 (many of us used it anyway) but it seems fairly usable on VC 7. Of course, what *would* be nice is to have some way to specify this portably for all toolsets. IOW, the default would be to use what's considered a normal level for the toolset, but warningsall could be used to crank it up to full. I'd expect warningsall to translate to /Wall on VC 7. Not a very practical warning level IMHO. :-) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: Repost: [boost] Problems using iterator_adaptor withistreambuf_iterator
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
(char), but the dereference policy member expects to return
it a reference.
It seems, that there should be a similar return type deduction for
the
iterator_adaptor::operator*() function as already
implemented for the
iterator_adaptor::operator-() function.
Regards Hartmut
Which template are you having problems with? Can you post
some code which reproduces the problem? Did you try
explicitly specifying the iterator's reference type?
I've attached a minimal (braindead) sample, which reproduces the problem
(it does not compile).
The input_iterator used as the Base iterator of the adaptor returns a
value_type from its operator*(), but the iterator_adaptor template
expects a reference here. Surely I could solve it by adding a member of
type value_type to my policy class, using it as a buffer and the
reference to it may be returned, but isn't it better to resolve it in
the adaptor? Even more because a congruent problem, which happens often
with the operator-() is already solved through a proxy class. I believe
that the operator*() problem may be solved in a similar fashion.
Regards Hartmut
#include iterator
#include boost/iterator_adaptors.hpp
using namespace boost;
struct dummy_input_iterator
{
typedef std::input_iterator_tag iterator_category;
typedef char value_type;
typedef size_t difference_type;
typedef char * pointer;
typedef char reference;
value_type operator*() const { return 42; }
dummy_input_iterator operator++() { return *this; }
dummy_input_iterator operator++(int) { return *this; }
};
typedef iterator_adaptor
dummy_input_iterator, default_iterator_policies,
char, char , char *
adapted_dummy_iterator;
void main()
{
adapted_dummy_iterator it, end;
char c;
while (it != end) {
c = *it;
++it;
}
}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Thread Lib and DLL
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 this would cause. So, unless you have some suggestion as to how I can enable this usage with out causing confusion, I'm not sure I'd care to re-enable static builds. But you could probably fairly easily hack things to build that way yourself. No, I wasn't going to ask you to re-enable static linking because of this. As you rightly pointed out in the other thread, you have to make the library safe for all possible cases which is what you are doing. If we did decide to go this route, then we would certainly handle building the lib ourselves. Our problem with DLLs is this: We work on many projects. Some are in maintenance only mode, so don't get many updates. The next project may use boost-1.30.0 and then go into maintenance. I may then be working on a project which uses boost-1.32.0 and would like to keep both dlls available on the system. Current idea for doing this is re-naming the boost dlls to boost_thread-1.30.0.dll etc so that I can have 1 bin directory with all the dlls in, and each project would link and use the correct dll. I wonder if support for this could be built into the builds? Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Determining interest in combining_iterator
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 usage. I would agree if tuples and argument passing were more closely linked, i.e., if passing a tuple to a function meant that the tuple would be automagically unpacked into separate arguments. But that's not the case, so the introduction of tuples as the return type makes it harder to then apply a function object to the values. Whereas having the iterator apply a functor to the values makes it harder to apply a function object that accepts a tuple. For instance, consider an iterator that adds the values from two other iterators (with the combining iterator): make_combining_iterator(first.begin(), second.begin(), std::plusint()); With the tuple iterator, you need to either (a) write your own std::plus-like function object that accepts a tupleint, int instead of two int parameters or (b) use something like Aleksey's apply (?) function that unpacks a tuple and applies the separate arguments to a function object. And what's so difficult in doing that? The code has to be there as part of the current combining iterator anyway, so it's not too bad to have to split it off to a separate functor. You could make a wrapper function that applied it as well as the supplied functor: make_combining_transform_iterator_with_args(first.begin(), second.begin(), std::plusint()); which does: make_combining_transform_iterator(first.begin(), second.begin(), split_tuple_and_call(std::plusint())); How do you write the following with your combining iterator? (TupleIt is a supposed generalisation of my PairIt which returns a tuple rather than a pair) [snip] std::sort(makeTupleIterator(first.begin(),second.begin(),third.begin()), makeTupleIterator(first.end(),second.end(),third.end()), myCompareFunc); makeTupleIterator(first.begin(), second.begin(), third.begin()) is equivalent to make_combining_iterator(first.begin(), second.begin(), third.begin(), boost::tuples::make_tupleint, int, int); that'd have to be make_tupleint,int,int for sort, so that you can write back to your vectors. However, then copying the tuple doesn't create a true copy; it still has references to the original, and a swap along the lines of X tmp=a; a=b; b=tmp; (such as might be used as part of the implementation of std::sort) would then not work. The tuple returned would have to be a custom tuple type, much as the return type of derefencing my PairIt is a custom pair type, in order to ensure that things like std::sort work OK, so it would not be as simple as using boost::tuples::make_tuple, but it could be done with an equivalent functor. The beauty of having this the main interface is that such reference vs value details can be taken care of automatically depending on the iterator category, whereas if you try and do it retrospectively with a functor, then you have to specify whether to use references or values, which can be error prone --- I expect that using make_tupleint,int,int will compile, yet the vectors will remain unsorted. It appears to me that we need both, and we can have both by simply providing helper functions either way. However, I'm inclined to think it better to provide the tuple-based dereferencing as default, with a custom functor (and helper function) to provide the split into function-call arguments, rather than vice-versa. Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd. Remove NOSPAM when replying, for timely response. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
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 level different from the compiler's/IDE's default is necessarily a good idea. My opinion only. /W4 was a bit painful for VC 6 (many of us used it anyway) but it seems fairly usable on VC 7. Of course, what *would* be nice is to have some way to specify this portably for all toolsets. IOW, the default would be to use what's considered a normal level for the toolset, but warningsall could be used to crank it up to full. I'd expect warningsall to translate to /Wall on VC 7. Not a very practical warning level IMHO. :-) Well, add other options for warnings then ;). warningsnone (disable warnings) warningsdefault (typical warnings) warningshigh (all warnings that aren't considered painful) warningsall (all warnings) Of course, the names and categories would need consideration when viewed portably. For example, warningsall would imply -Wall for gcc, which should also be used for warningshigh (?), so some users might mistakenly use all when they should use high instead. But I think you could come up with a reasonable way to declare this portably, and believe it would be useful. I'd use warningsall from the command line to lint my code with VC (even VC6), but would prefer to leave things at the default level in the Jamfile to more closely meet user's expectations (too low and when they use my code they get warnings we don't report, too high, and when they use bjam on their own code they may get warnings they don't care to see). -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
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 (and it looks like it may have been less clear, because I misunderstood your question). What's not a good idea is mixing the RTLs. If you want to use /MT(d) then you should compile Boost.Threads with /MT(d) as well. Thanks a lot for the answer! This is what I wanted to know: If I can build the boost.thread dll and the app with the /MT flag instead of /MD flag. Regarding the mixing of the RTLs the last versions of VC++ gives you a link warning if you try to do that ... Nice to know... but it wouldn't work for dynamically loaded DLLs. Then again, dynamically loading Boost.Thread is not a good idea. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Thread Lib and DLL
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 support requests/questions this would cause. So, unless you have some suggestion as to how I can enable this usage with out causing confusion, I'm not sure I'd care to re-enable static builds. But you could probably fairly easily hack things to build that way yourself. No, I wasn't going to ask you to re-enable static linking because of this. As you rightly pointed out in the other thread, you have to make the library safe for all possible cases which is what you are doing. If we did decide to go this route, then we would certainly handle building the lib ourselves. Our problem with DLLs is this: We work on many projects. Some are in maintenance only mode, so don't get many updates. The next project may use boost-1.30.0 and then go into maintenance. I may then be working on a project which uses boost-1.32.0 and would like to keep both dlls available on the system. 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. Current idea for doing this is re-naming the boost dlls to boost_thread-1.30.0.dll etc so that I can have 1 bin directory with all the dlls in, and each project would link and use the correct dll. I wonder if support for this could be built into the builds? Absolutely! I'm hoping we address these kind of concerns with a full installation solution sometime soon. In the mean time, the stage rule in the Jamfile should be able to handle this. You can hardcode the release number in today... but I believe there's a variable available which I could use to do this with out hardcoding. I'll see if I can track this down and make the patch. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Thread Lib and DLL
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 why this makes a static library impossible. All thing considered, I find a static library is much more desirable than a dll. It has been discussed numerous times on this list, as well as on the Users list. TLS cleanup can only be done on the Win32 platform with code in the thread itself (which won't work for threads created outside of Boost.Threads) or with code in DllMain. A possibility. Simulate the DllMain DLL_PROCESS_DETACH through a member function call in the thread class which should only be used for those who are using a static library version of the library. The member function must be called before the thread function exits in the static library version. For the DLL version, the member function must be ignored or you can simply not have the member function call in the DLL version. The onus would be on those using the static library version to always make this call before their thread function exits, but would at least provide them wioth the possibility of using a static library version. Of course there may be other ramifications which cause this idea not to work, or even getting it to work properly would be too much trouble, but I thought I would suggest it anyway. It may not be worth thinking about possible solutions of building a static library version of Boost.Threads. I know that for myself I always creates DLLs when distributing applications but as a 3rd party developer I always leave open the possibility that there are people who like to distribute the applications as a single EXE which uses static libraries and the static library version of their compiler's RTL. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Thread Lib and DLL
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 anything that documents why this makes a static library impossible. All thing considered, I find a static library is much more desirable than a dll. It has been discussed numerous times on this list, as well as on the Users list. TLS cleanup can only be done on the Win32 platform with code in the thread itself (which won't work for threads created outside of Boost.Threads) or with code in DllMain. A possibility. Simulate the DllMain DLL_PROCESS_DETACH through a member function call in the thread class which should only be used for those who are using a static library version of the library. The member function must be called before the thread function exits in the static library version. For the DLL version, the member function must be ignored or you can simply not have the member function call in the DLL version. The onus would be on those using the static library version to always make this call before their thread function exits, but would at least provide them wioth the possibility of using a static library version. Of course there may be other ramifications which cause this idea not to work, or even getting it to work properly would be too much trouble, but I thought I would suggest it anyway. Workable, if the user makes absolute certain he calls this method from every thread that accesses TLS. However, he may not know this, for example when a library function uses Boost.Threads internally and allocates TLS with out the user knowing. This is just a variation on the you must use this thread creation routine if you use our libraries solution that MS uses for the C RTL and MFC. I think it's fragile... and many users fail to understand the issues here and thus do the wrong thing. It may not be worth thinking about possible solutions of building a static library version of Boost.Threads. I know that for myself I always creates DLLs when distributing applications but as a 3rd party developer I always leave open the possibility that there are people who like to distribute the applications as a single EXE which uses static libraries and the static library version of their compiler's RTL. Yes, and for that reason I certainly dislike the DLL only packaging of Boost.Threads. But it seems the safest and most viable solution. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: io operations for stl containers?
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 does
the same. All components are in the boost::io namespace.
There are no docs, yet, but there are several test programs, illustrating
use for all supported types (the list of these are given below). I also
include information here.
Feedback is welcome.
Examples of use:
std::vector
---
#include boost/io/format/std/vector.hpp
std::vectorint v;
// Fill vector
// Output (using user-changeable default format)
std::cout v;
Output:
[1,2,3,4,5,6,7,8,9,10]
std::map
#include boost/io/format/std/map.hpp
typedef std::mapint,char map;
typedef map::value_type value_type;
map values;
// Fill map
std::cout formatvalue_type([, ]\n, = )
formatmap(,,)
values;
Output:
[1 = A]
[2 = B]
[3 = C]
Array
---
#include boost/io/format/array.hpp
int array[]={1,2,3,4,5,6,7,8,9,10};
std::cout array '\n'
format_ ()[N](, , \n)
array;
Output:
[1,2,3,4,5,6,7,8,9,10]
1
2
3
4
5
6
7
8
9
10
Here is a synopsis
--
namespace boost::io
-
format - Set output formatting
==
Type options
--
_ - Any type
N - Any size (for array)
template_name_ - Any instantiation of the given template (may need more
_s, one for each parameter without default)
Syntax
--
formatType(start sequence, end sequence, delimiter, [start
element, end element])[.set_default_format()]
formatType(set/unset format)
If set_default_format() is used, it may be used without a stream, and it
then sets the format for all streams.
Examples
--
stream formatstd::vectorint (...) // Set format for std::vectorint
stream formatstd::vector_ (...) // Set format for any instantiation
of std::vector
stream format_(...) // Set format for any type
stream formatstd::vectorint (false) // Unsets format for
std::vectorint
It checks for format settings, going from the most specific to the most
general, stopping when it has found a set format. E.g. for the above
example, this means checking in the following order:
std::vectorint
std::vector_
_
_ (any stream)
The library sets the following default for all streams (the last format
checked), which may be changed by the user. This default is set rather
arbitrarily, and is open to change. This is so that no formatting is needed
to be set, to get useful output:
format_([, ], ,).set_default_format() - Sets format for all types,
for all streams.
It also handles wide character formatting:
formatType(L[, L], L,)
sequence - Lets a sequence, given with start/end iterators, be output as the
given type
==
Syntax
--
sequenceType(start iterator, end iterator)
Examples
--
#include boost/io/format/sequence.hpp
std::vectorint v;
// Fill vector
std::cout sequence_(v.begin(),v.begin()+10);
Output:
[1,2,3,4,5,6,7,8,9,10]
typedef std::istream_iteratorint in;
std::cout sequence_(in(std::cin),in());
Input:
1 2 3 4 5 6 7 8 9 10
Output:
[1,2,3,4,5,6,7,8,9,10]
wrap - Lets a type be output using set format, even if it has its own output
operator
==
Some types, such as std::complex, std::bitset, and boost::dynamic_bitset
have already output stream operators defined, so to set their format, one
may wrap the value before outputting.
Syntax
-
wrap(value)
Examples
--
#include boost/io/format/std/complex.hpp
std::complexdouble value(1.23, 2.34);
std::cout value '\n'
wrap(value);
Output:
(1.23,2.34)
[1.23,2.34]
Supported types
=
Arrays
std
pair
complex (has output operator, use wrap)
vector
list
deque
set
multiset
map
multimap
bitset (has output operator, use wrap)
boost
dynamic_bitset (has output operator, use wrap)
The supported types may also be extended by the user.
Header organisation
boost/io/format ---
|--- std
|--- boost
libs/format/io ---
|--- tests
Compatibility
==
The library uses standard C++, but isn't very portable currently. It has
been tested on Intel C++ 7.0 and g++ 3.2.
I plan to work on the portability, and should soon get it to work on MSVC,
etc., as well.
The names, syntax and semantics is open to suggestions for change.
I hope Daryle Walker doesn't mind that this library is sharing the io
directory and namespace, at the Sandbox. If so, I could change it from
io/format to io_format.
Thanks for the patience to those who have waited for this update.
Regards,
Terje
[boost] Re: Thread Lib and DLL
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 'version number in name' if we're forced to use dlls) is that I can have all dlls sitting in one place on the system, and to create a quick project, I can already use the boost libs without having to copy/move any lib/dll files. I use #pragma link statements (like regex does) in code to link with the boost dlls so all I need on my libs path is C:\BOOST\1.30.0\bin and change this depending on which version. The version is also just a project wide #define so it can easily be changed on a project by project basis (need to change 3 things: include directory lib directory version #define (so the pre-processor can make up the .lib name) and I can then easily switch between versions and have all versions existing on the same machine. I'm trying to make boost as easy to use as the STL, i.e. always available without havig to do anything bar include a header file in 1 or more CPP files that contains the #pragma link statements. I've also currently done it by adding a d to the debug version and mt to the threaded version (of signals etc) so I can easily switch between the debug and release version of a lib if I want to step through the code. The multi-threaded version is automatically used if __MT__ is defined etc. Current idea for doing this is re-naming the boost dlls to boost_thread-1.30.0.dll etc so that I can have 1 bin directory with all the dlls in, and each project would link and use the correct dll. I wonder if support for this could be built into the builds? Absolutely! I'm hoping we address these kind of concerns with a full installation solution sometime soon. In the mean time, the stage rule in the Jamfile should be able to handle this. You can hardcode the release number in today... but I believe there's a variable available which I could use to do this with out hardcoding. I'll see if I can track this down and make the patch. That would be good. Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] shared_ptr operator bool
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 ptr ? true : false;. This is
counter-intuitive to me. Can anybody explain me why?
Giovanni Bajo
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Repost: [boost] Problems using iterator_adaptor withistreambuf_iterator
[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 of the STL I'm using returns a value_type
(char), but the dereference policy member expects to return
it a reference.
It seems, that there should be a similar return type deduction for
the
iterator_adaptor::operator*() function as already
implemented for the
iterator_adaptor::operator-() function.
Regards Hartmut
Which template are you having problems with? Can you post
some code which reproduces the problem? Did you try
explicitly specifying the iterator's reference type?
^^^
Can't you solve this by passing char instead of char as the 4th
template parameter?
I've attached a minimal (braindead) sample, which reproduces the problem
(it does not compile).
The input_iterator used as the Base iterator of the adaptor returns a
value_type from its operator*(), but the iterator_adaptor template
expects a reference here. Surely I could solve it by adding a member of
type value_type to my policy class, using it as a buffer and the
reference to it may be returned, but isn't it better to resolve it in
the adaptor? Even more because a congruent problem, which happens often
with the operator-() is already solved through a proxy class. I believe
that the operator*() problem may be solved in a similar fashion.
Regards Hartmut
#include iterator
#include boost/iterator_adaptors.hpp
using namespace boost;
struct dummy_input_iterator
{
typedef std::input_iterator_tag iterator_category;
typedef char value_type;
typedef size_t difference_type;
typedef char * pointer;
typedef char reference;
value_type operator*() const { return 42; }
dummy_input_iterator operator++() { return *this; }
dummy_input_iterator operator++(int) { return *this; }
};
typedef iterator_adaptor
dummy_input_iterator, default_iterator_policies,
char, char , char *
adapted_dummy_iterator;
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
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. So. Are we gonna stuck with typeinfo in lexical_cast? Could we have at least some discussion about this? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: patch: BOOST_AUTO_UNIT_TEST in auto_unit_test.hpp
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 boost/test/included/auto_unit_test.hpp Which in turn includes #include libs/test/src/auto_unit_test.cpp You mean guarded by some kind of macro? I will think more about multi - module support. I still stand by my original patch submission. Although, as you pointed out, for the vast majority of users, it is of no value. However, it worked for me, and it is likely to help others in the future. I will consider this. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] shared_ptr operator bool
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
change
my operator bool into return ptr ? true : false;. This is
counter-intuitive to me. Can anybody explain me why?
Beats me. All other compilers I tried do not assert. On como,
assert((bool)a.ptr) passes, but even an explicit (bool)ptr inside the
conversion operator returns false.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] shared_ptr operator bool
- 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 5.6 and GCC 3.2 prerelease. That's right. I forgot to say that I tested it on several compilers as well, and there was no problem. But since it's not the first time that Comeau helps tracing down some nasty compatibility bug, I thought I would have reported it anyway. Never mind, I will bring this to the Comeau guys. Giovanni Bajo ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: Repost: [boost] Problems using iterator_adaptor withistreambuf_iterator
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 istreambuf_iteratorchar::operator*() implementation of the STL I'm using returns a value_type (char), but the dereference policy member expects to return it a reference. It seems, that there should be a similar return type deduction for the iterator_adaptor::operator*() function as already implemented for the iterator_adaptor::operator-() function. Regards Hartmut Which template are you having problems with? Can you post some code which reproduces the problem? Did you try explicitly specifying the iterator's reference type? ^^^ Can't you solve this by passing char instead of char as the 4th template parameter? Duh, I feel like an idiot ... Sorry for the noise. Regards Hartmut ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Thread Lib and DLL
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 storage, but haven't seen anything that documents why this makes a static library impossible. All thing considered, I find a static library is much more desirable than a dll. It has been discussed numerous times on this list, as well as on the Users list. TLS cleanup can only be done on the Win32 platform with code in the thread itself (which won't work for threads created outside of Boost.Threads) or with code in DllMain. A possibility. Simulate the DllMain DLL_PROCESS_DETACH through a member function call in the thread class which should only be used for those who are using a static library version of the library. The member function must be called before the thread function exits in the static library version. For the DLL version, the member function must be ignored or you can simply not have the member function call in the DLL version. The onus would be on those using the static library version to always make this call before their thread function exits, but would at least provide them wioth the possibility of using a static library version. Of course there may be other ramifications which cause this idea not to work, or even getting it to work properly would be too much trouble, but I thought I would suggest it anyway. Workable, if the user makes absolute certain he calls this method from every thread that accesses TLS. However, he may not know this, for example when a library function uses Boost.Threads internally and allocates TLS with out the user knowing. 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 called which calls the Boost.Threads function before the thread ends or, if the library function itself controls the ending of the thread, it must do it itself. This is just a variation on the you must use this thread creation routine if you use our libraries solution that MS uses for the C RTL and MFC. I think it's fragile... and many users fail to understand the issues here and thus do the wrong thing. I don't doubt its general fragility as far as the end-user goes but if it enables an end-user to use Boost.Threads in a static LIB version, it may be still justifiable for them. It is easy enough to explain to the end-user that because Boost.Threads can not track when the thread ends in a static LIB, as it can automatically do in a DLL, the end-user must do the manual tracking by notifying Boost.Threads about the thread ending via the function. There is hardly an end-user involved with Windows DLLs who does not know about the attaching and unattaching of processes and threads which runs through DllMain. It would be completely understandable to offer the more difficult to use static LIB version with an explanation of why this notification must be done manually for the static LIB as opposed to the DLL. It may not be worth thinking about possible solutions of building a static library version of Boost.Threads. I know that for myself I always creates DLLs when distributing applications but as a 3rd party developer I always leave open the possibility that there are people who like to distribute the applications as a single EXE which uses static libraries and the static library version of their compiler's RTL. Yes, and for that reason I certainly dislike the DLL only packaging of Boost.Threads. But it seems the safest and most viable solution. Well, it is up to you. As I say, I generally never use static LIB versions in my own application software. However, if I distribute 3rd party components I feel bound to be able to distribute versions as both a DLL and a static LIB whenever it is functionally possible to do so. So if I were a 3rd party developer who was using Boost.Threads for my own implementation of something, I might not want to do so because the proposed static LIB version of my own software could not use a static LIB version of Boost.Threads. Although I could theoretically use the DLL version of Boost.Threads in the static LIB version of my own software, I have always been heavily opposed to mixing static LIB and DLL versions of anything with their implications of possibly mixing static LIB and DLL RTL and the ensuing hell that usually causes. So I don't think it is just people who distribute applications who might find it hard that their is no static LIB version of Boost.Threads but also other 3rd party developers. ___ Unsubscribe other changes:
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0(mostlylexical_cast.hpp)
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 cases one knows it anyway. Kevlin Gennadiy. So. Are we gonna stuck with typeinfo in lexical_cast? Could we have at least some discussion about this? 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 acceptable (due to it no longer looking like a cast in that case). 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. Then one might have a lexical_cast specific macro for it, like BOOST_LEXICAL_CAST_USE_RTTI, like you suggested. Kevlin or others, any thoughts? Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
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 cases one knows it anyway. Kevlin Gennadiy. So. Are we gonna stuck with typeinfo in lexical_cast? Could we have at least some discussion about this? 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 throw... though I don't know how (or if) that interacts with things like char const*. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: MSVC++ 6.0 compiler errors with 1.30.0(mostlylexical_cast.hpp)
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 majority of the cases one knows it anyway. Kevlin Gennadiy. So. Are we gonna stuck with typeinfo in lexical_cast? Could we have at least some discussion about this? I'd certainly be open to make the type_info part optional. A question is how to do it. 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, I don't think that Boost should now have to worry about not supporting it in a library because end-users can turn it off. Should Boost stop using exceptions in order to accomodate those who can turn off exception handling in their C++ implementations as some implementations allow ? The same goes for any other part of the C++ standard. It's the end-users problem if they turn off something in their implementations, and then can't use it, which is part of the C++ standard. OTOH I do understand completely the great effort Boost has made to accomodate implementations which just don't support some area of the C++ standard completely. But I view the two issues as completely separate. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: MSVC++ 6.0 compiler errors with1.30.0(mostlylexical_cast.hpp)
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 important than providing specific type info. In majority of the cases one knows it anyway. Kevlin Gennadiy. So. Are we gonna stuck with typeinfo in lexical_cast? Could we have at least some discussion about this? I'd certainly be open to make the type_info part optional. A question is how to do it. 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, I don't think that Boost should now have to worry about not supporting it in a library because end-users can turn it off. Should Boost stop using exceptions in order to accomodate those who can turn off exception handling in their C++ implementations as some implementations allow ? There's some precedent for it. grep for BOOST_NO_EXCEPTIONS. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] compare
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 operator (position const p1, position const p2)
{
return compare (p1.x, p2.x)
(p1.y, p2.y)
(p1.z, p2.z);
}
is equal to
bool operator (position const p1, position const p2)
{
if (p1.x == p2.x)
if (p1.y == p2.y)
return p1.z p2.z;
else
return p1.y p2.y;
else
return p1.x p2.x;
}
or
struct person
{
std::string firstname, lastname;
};
bool operator (person const p1, person const p2)
{
return compare
(p1.lastname, p2.lastname, cmp_case_insensitive)
(p1.firstname, p2.firstname, cmp_case_insensitive);
}
where cmp_case_insensitive is a comparision function which is used
instead of operator to compare the arguments.
the class itself is quite short:
class compare
{
enum result { minus, zero, plus };
public:
compare () : v_ (zero) {}
template typename T
compare (T const a, T const b)
: v_ (compare () (a, b).v_)
{}
template typename T, typename Cmp
compare (T const a, T const b, Cmp cmp)
: v_ (compare () (a, b, cmp).v_)
{}
template typename T
compare operator () (T const a, T const b)
{
if (v_ == zero)
{
if (a b)
v_ = plus;
else if (b a)
v_ = minus;
else
v_ = zero;
}
return *this;
}
template typename T, typename Cmp
compare operator () (T const a, T const b, Cmp cmp)
{
if (v_ == zero)
{
if (cmp (a, b))
v_ = plus;
else if (cmp (b, a))
v_ = minus;
else
v_ = zero;
}
return *this;
}
operator bool ()
{
return v_ == plus;
}
private:
result v_;
};
--
jan langer ... [EMAIL PROTECTED]
pi ist genau drei
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost Pool Library future directions
-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 current focus on Boost.Pool is to update it to use other Boost libraries more. There are a lot of non-obvious problems to getting that base class pool interface working correctly - plus the whole question of whether it is even a desirable design. I am considering dropping that from the future directions instead of actually doing it. Also, what about an allocator that takes the size of memory to be allocated and forwards it to an appropriate pool (or to the standard malloc/new if the size is over a certain threshold size)? If you need a general memory allocator, use malloc/new. Any modern malloc/new already does this internally. -Steve ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlyle xical_cast.hpp)
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 throw... though I don't know how (or if) that interacts with things like char const*. It's not that I could not handle the exception (exception-less interface is another topic that should be discussed separately). See my other post on consequences of including of typeinfo. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Thread Lib and DLL
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 define a function which can be called which calls the Boost.Threads function before the thread ends or, if the library function itself controls the ending of the thread, it must do it itself. Or, it could be packaged up in a simple object wrapper (which is what I am doing) and the destructor automatically calls it for me. I use an auto_ptr to a wrapper object as the functor that gets passed to Boost.Threads which points to the object I want to actually execute (since I don't want to copy its data around each time in the internals of boost. That object is derived off a simple base whose destructor could call the Boost.Threads::Release() function on termination. What this solution (or the previous proposed) does not seem to solve is abnormal termination, which the DLL does solve. One other possible solution, for those of us who want to package Boost into our own DLL, but link it in statically so the linker can only pull in the parts used, is to provide a DLL template object that our DLL derives off of with functors for each of the calls that you normally get in a DLL. The boost framework calls the Release as needed, then calls the user Functor. I do not know how this fares in other environs. Should I expound on this idea or is it a waste of time? michael ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
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 acceptable (due to it no longer looking like a cast in that case). That's is not exactly true since third parameter will have a default value. So in default case you wont see a difference. 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 Then one might have a lexical_cast specific macro for it, like BOOST_LEXICAL_CAST_USE_RTTI, like you suggested. We may need this macro even policy based solution would be chosen (only for convinience). See my previos post And again if I am right and RTTI has runtime overhead whatever decision we will make I prefer not to force typeinfo inclusion. User has to have an option this way or another. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] boost::any feature request
-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 the sources I played with. It's far from perfect, but I think
the basic idea is clear.
The TailoredAny class has the prototype:
code
templateclass NewStrategy_ = Loki::EmptyType, class TypeInfoStrategy_ =
RttiTypeInfoStrategy
class TailoredAny;
/code
So, it can be parametrized with the type identification strategy, not
the memory allocation strategy only.
And here are the Intel VTune results (see the sources for details):
CreationAssignment
struct 13383 27358
boost::any 3846331870
TailoredAny 9151310717
TailoredAnyLoki::SmallObject 3855110022
If we throw away the type identification strategy and leave it hardcoded
as in the original boost::any the result of the TailoredAny will be
better.
// TailoredAny.h
#pragma once
#include algorithm
#include Loki/EmptyType.h
#include Loki/TypeInfo.h
struct RttiTypeInfoStrategy
{
typedef Loki::TypeInfo TypeInfo;
templatetypename T
static TypeInfo Identify() { return typeid(T); }
templatetypename T
static TypeInfo Identify(const T t) { return typeid(t); }
};
templateclass NewStrategy_ = Loki::EmptyType, class TypeInfoStrategy_ =
RttiTypeInfoStrategy
class TailoredAny
{
public:
typedef TypeInfoStrategy_ TypeInfoStrategy;
typedef typename TypeInfoStrategy_::TypeInfo TypeInfo;
TailoredAny()
: content_(0)
{}
templateclass ValueType_
TailoredAny(const ValueType_ value)
: content_(new Holder_ValueType_(value))
{}
TailoredAny(const TailoredAny other)
: content_(other.content_ ? other.content_-Clone() : 0)
{}
~TailoredAny() { delete content_; }
templateclass ValueType_
TailoredAny operator=(const ValueType_ value)
{
TailoredAny(value).Swap(*this);
return *this;
}
TailoredAny operator=(const TailoredAny other)
{
TailoredAny(other).Swap(*this);
return *this;
}
void Swap(TailoredAny other)
{
std::swap(content_, other.content_);
}
bool Empty() const { return !content_; }
TypeInfo Type() const
{
return content_ ? content-Type() :
TypeInfoStrategy_::Identifyvoid();
}
private:
struct PlaceHolder_ : NewStrategy_
{
virtual TypeInfo Type() const = 0;
virtual PlaceHolder_* Clone() const = 0;
virtual ~PlaceHolder_() {}
};
templateclass ValueType_
struct Holder_ : PlaceHolder_
{
Holder_(const ValueType_ value)
: held_(value)
{}
TypeInfo Type() const
{
return TypeInfoStrategy_::Identify(held_);;
}
PlaceHolder_* Clone() const
{
return new Holder_(held_);
}
ValueType_ held_;
};
templateclass ValueType_, class S1_, class S2_
friend ValueType_* TailoredAnyCast(TailoredAnyS1_, S2_*);
PlaceHolder_* content_;
};
templateclass ValueType_, class S1_, class S2_
ValueType_* TailoredAnyCast(TailoredAnyS1_, S2_* operand)
{
typedef TailoredAnyS1_, S2_::TypeInfoStrategy TypeInfoStrategy;
return operand operand-Type() == TypeInfoStrategy::IdentifyValueType_()
? static_castTailoredAnyS1_,
S2_::Holder_ValueType_*(operand-content_)-held_
: 0;
}
templateclass ValueType_, class S1_, class S2_
const ValueType_* TailoredAnyCast(const TailoredAnyS1_, S2_* operand)
{
return TailoredAnyCastValueType_, S1_(const_castTailoredAnyS1_,
S2_*(operand));
}
templateclass ValueType_, class S1_, class S2_
ValueType_ TailoredAnyCast(const TailoredAnyS1_, S2_ operand)
{
const ValueType_* result = TailoredAnyCastValueType_(operand);
if(!result)
throw std::bad_cast();
return *result;
}
// play_with_any.cpp : Defines the entry
Re: [boost] Re: io operations for stl containers?
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 namespace. I would prefer (since it all about container output formatting) boost/io/container Well, it actually may handle any composite type, such as std::complex, std::pair, etc., as well. It also handles any sequence (using io::sequenceType(begin,end) ), not just containers. I used to call it composite_format, but that was rather long... Using io::formatType(...), I think is quite succinct. Also it could be stl instead of std, though it's the matter of taste. The directories follow the namespaces, so it has std and boost. STL is only a subset of the standard library, so also for that reason, I think std would be more appropriate. std::cout formatvalue_type([, ]\n, = ) formatmap(,,) values; ... Syntax -- formatType(start sequence, end sequence, delimiter, [start element, end element])[.set_default_format()] formatType(set/unset format) I personally would really prefer verbose format specification. So I should not remember what each of the parameters means by it's position. Something along this lines: std::cout start_elelmentvalue_type( [ ) // if you need value type_here. I am not sure Yes, you do, or it won't know which type to set it for. end_elementvalue_type( ]\n ) element_delimetervalue_type( = ) ... values; Or std::cout formatvalue_type().start_elelment( [ ).end_element( ]\n ).delimeter( = ) ... values; Or mix of this styles. Or - the very best - all of them. This should be quite easy to add. The latter style is also used in Reece Dunn's list manipulator, which also deals with output for sequences. I don't have that much practice with it, but I've found myself that I don't have a problem remembering which parameter is what, in the 3+2 optional parameter list. Lack of verbosity may be considered one of the advantages over writing explicit output code. Thanks for the feedback. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
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 can't handle the exceptions we want to throw... though I don't know how (or if) that interacts with things like char const*. It's not that I could not handle the exception You can't handle it if the exception includes type_info. (exception-less interface is another topic that should be discussed separately). See my other post on consequences of including of typeinfo. 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. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
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 specific type info. In majority of the cases one knows it anyway. Kevlin Gennadiy. So. Are we gonna stuck with typeinfo in lexical_cast? Could we have at least some discussion about this? 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 throw... though I don't know how (or if) that interacts with things like char const*. Technically, this should be possible, since it now throws an exception if you try to convert to any pointer, as it checks for that. This is to remove the possibility of trying to convert to char *, which could otherwise succeed (due to the design of basic_istream), but would give undefined behaviour. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Thread Lib and DLL
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 function which can be called which calls the Boost.Threads function before the thread ends or, if the library function itself controls the ending of the thread, it must do it itself. As I have researched this topic, it has become quite clear that I am nowhere near an expert in this area, so forgive me if these questions are naive or have been hashed over before. Are these statements accurate: When a thread is created within a static lib, there is no way to find out when the thread has completed. In a DLL, DllMain is called when the thread is complete. This is important because TLS data must be destroyed when the thread is complete. In the current version of boost (1.30), TLS is a feature of the thread library, but not required. In future versions of boost, threads themselves will rely on TLS internally, so TLS is no longer a feature, but required. Correct. If a user must link with a static thread lib, a workaround would be for them to notify the thread library that the thread is about to complete, and any associated TLS data can be destroyed. This is not an optimum solution, as it places the onus on the user. Correct. Some questions: In the current thread library, can the associated TLS data be deleted before the thread is complete? In the next version of the library, can the associated TLS data be deleted before the thread is complete? Not sure I understand precisely what you're asking, but I'll make some assumptions and say yes. However, read on. Would it be possible to add a level of indirection in the thread functor in static lib builds? For example, in a DLL build, the following happens (this is very loose, but should convey my meaning): --Thread Created (thread lib) -- User's thread functor (user code) --Thread Destroyed (thread lib) In a static lib build: -- Thread Created (thread lib) -- Internal thread functor (thread lib) -- User's thread functor (user code) -- Destroy TLS (thread lib) -- Thread Destroyed (thread lib) This would free the user from calling a destroy function at the end of the thread proc, but would enable static builds (if the above assumptions are correct). This is the model used by MS. Threads are created at the low level by calls to CreateThread. The C RTL uses some TLS, so if you call any C RTL routines you're required to instead call _beginthread(ex), which creates a proxy that ensures TLS data is cleaned up. Then MFC comes along and for the same reasons requires you to instead call AfxBeginThread. One of the more common errors that users make is to use the wrong thread creation routine, which doesn't produce any obvious problems like a segfault. Worse, this causes issues for people like me. Which thread creation routine should Boost.Threads use? CreateThread is obviously a bad choice, but the other routines are not so easy to choose between. If I use AfxBeginThread(), the user is stuck with MFC, even if they don't use it. If I use _beginthread(ex) (which is what I've chosen) then the user can't safely call any MFC routines from threads created by Boost.Thread. If I implement the solution you've given above, I cause these same issues on my end users in triplicate. More importantly Boost.Threads is meant to be useful for library developers. Why should an application developer be forced to use Boost.Threads just because library Foo choose to use Boost.Threads to make the library thread safe? This solution is fragile and difficult to manage today. Every time you add yet another thread creation routine/proxy into the mix it gets geometrically worse. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0(mostlylexical_cast.hpp)
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 mail, there is already a config macro to disable exceptions. Whether or not libraries check for it is optional, though. From the docs: BOOST_NO_EXCEPTIONS - The compiler does not support exception handling (this setting is typically required by many C++ compilers for embedded platforms). Note that there is no requirement for boost libraries to honor this configuration setting - indeed doing so may be impossible in some cases. Those libraries that do honor this will typically abort if a critical error occurs - you have been warned! Embedded C++ doesn't have RTTI, either. Therefore, a BOOST_NO_RTTI might be reasonable, as well. I understand that your suggestion is not for macros describing lack of compiler support, but rather user settings. Yet, couldn't these be used for either, by explicitly setting them before any Boost includes? 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. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlyle xical_cast.hpp)
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 want RTTI runtime overhead I would not want exception one also. But the thing is that I am not using lexical_cast in performance critical parts of application and would and still prefer in most cases exception-based interface without RTTI overhead that affects whole program. Almost the only case when I have a need for namely exception-less interface is the need for the predicate is_lexical_convertible. It more convenient that lexical cast wrapped in try/catch clauses. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Thread Lib and DLL
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 within the thread code
void InternalThreadProc(const boost::functionvoid func)
{
func();
//TLS cleanup
}
thread(const boost::functionvoid userFunc)
{
...
InternalThreadProc(userFunc);
}
Again, the code is rough, but I hope I am communicating clearly.
Thanks again,
David Brownell
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: io operations for stl containers?
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 directories follow the namespaces, so it has std and boost. STL is only a subset of the standard library, so also for that reason, I think std would be more appropriate. OK. This should be quite easy to add. The latter style is also used in Reece Dunn's list manipulator, which also deals with output for sequences. That would be great. I don't have that much practice with it, but I've found myself that I don't have a problem remembering which parameter is what, in the 3+2 optional parameter list. Lack of verbosity may be considered one of the advantages over writing explicit output code. That is not the problem for the developer - when you actively working with library. But may be an issue for maintainer. Even if it's the same person. Let say you returns to the application written year ago and never used this formatting library meanwhile. Then I am afraid formatmap(,,) could be a bit confusing. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Determining interest in combining_iterator
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 passing a tuple to a function meant that the tuple would be automagically unpacked into separate arguments. From a user's point of view, this seems a very strong argument to me. For instance, in my software, I use combining iterators with functionals such as std::divides. If I were forced to accept my arguments as a tuple, I couldn't use any of these functionals without the extra unpacking step. Besides, introducing the tuple in the middle between dereferencing the iterators introduces the possibility of inadvertent extra value copies. Another big headache for the user. And why all that? I really don't see any advantage to this intermediate step of packaging the derefernced iterators into a tuple, only to unpack it in 99.999% of the cases. What for? Once again: The big picture is that we want an iterator that parallel-iterates over several sequences and upon dereferencing, applies some processing to the dereferenced iterator. This processing is specified by the user via a fuctional. One of the many, many things that such a functional can do is package the arguments into a tuple, if that is what's needed. (Although we still haven't seen a single real-life request for that). Why on earth would I, in the general case, introduce a packaging/unpackaging step in the middle between dereferencing the iterators and passing them to the functional? Am I missing something? BTW, Anthony: In one of my CUJ columns, I made a big fool of myself by gratuitously packaging function arguments into a tuple, and I seem to remember that you were one of the people who pointed this out to me. Looks like we switched sides in this argument... ;-) Thomas Becker Zephyr Associates, Inc. Zephyr Cove, NV __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
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. Gennnadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: MSVC++ 6.0 compiler errors with 1.30.0(mostlylexical_cast.hpp)
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. It's much more important than providing specific type info. In majority of the cases one knows it anyway. Kevlin Gennadiy. So. Are we gonna stuck with typeinfo in lexical_cast? Could we have at least some discussion about this? I'd certainly be open to make the type_info part optional. A question is how to do it. 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, I don't think that Boost should now have to worry about not supporting it in a library because end-users can turn it off. Should Boost stop using exceptions in order to accomodate those who can turn off exception handling in their C++ implementations as some implementations allow ? There's some precedent for it. grep for BOOST_NO_EXCEPTIONS. I didn't even realize that Boost catered to it although I should have since I have dealt with Regex++ enough. OK, if you allow end-users to build parts of Boost without exception handling, I guess you can allow end-users to build parts of Boost without RTTI support. I admit that if I were a Boost library implementor, I would find such limitations on my natural use of C++ annoying. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shared_ptr operator bool
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 been an open question. -- Truth, James Curran www.noveltheory.com (personal) www.njtheater.com (professional) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] CMake vs. bjam
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 when compared with Boost in that it must support multiple platforms/compilers and also provide wrappers for TCL, Python and Java for the original C++ code. The nice thing about CMake is that, depending on the system, makefiles (Unix) or workspaces/projects (MSVC/Borland) will be built. The user can also specify options for the build, for example whether to build the Python or TCL wrappers or not. Info about it can be found at: http://www.cmake.org/HTML/Features.html Andrew ___ Andrew J. P. Maclean Centre for Autonomous Systems The Rose Street Building J04 The University of Sydney 2006 NSW AUSTRALIA Ph: +61 2 9351 3283 Fax: +61 2 9351 7474 URL: http://www.cas.edu.au/ ___
[boost] Re: Re: Re: Re: Thread Lib and DLL
// 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, ); // leak, but how could the developer know?
}
I'm not sure I understand this example completely. Is this the case where
library Foo's author has created the some_library_foo function with the
intention that it will be accessed by a thread, but leave the actual thread
creation up to the user of the foo library (the bar application in your
example)?
If this is correct, it seems like Foo should either a) not burden Bar with
the knowledge that threads are being used and handle thread creation itself
or b) allocate locally to some_library_foo without using
thread_specific_ptr.
William, thank you for taking the time to answer these questions so
promptly, I appreciate your help! Also, if it would be beneficial to take
this discussion offline, I am open to that as well.
David
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shared_ptr operator bool
[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 template cast to reference type of template classes. The bug was reported and confirmed. I guess if A::ptr was of a non-template type the problem would not occur. Philippe ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Thread Lib and DLL
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()
{
__beginthread(bar, ); // leak, but how could the developer
know?
}
I'm not sure I understand this example completely. Is this the case
where library Foo's author has created the some_library_foo function
with the intention that it will be accessed by a thread, but leave the
actual thread creation up to the user of the foo library (the bar
application in your example)?
If this is correct, it seems like Foo should either a) not burden Bar
with the knowledge that threads are being used and handle thread
creation itself or b) allocate locally to some_library_foo without using
thread_specific_ptr.
Foo doesn't create any threads, but Bar does. So (a) isn't the answer.
I'm not sure what you mean by allocate locally to some_library_foo,
since that's precisely what's being done. Telling Foo not to use
thread_specific_ptr is the same as telling them not to use Boost.Threads,
which doesn't sound like the answer to me!
To make this more concrete, TLS is most often used to make legacy
interfaces, such as the classic example of strtok, which maintain state
across calls, thread safe. That's what's being done in the hypothetical
some_library_foo. TLS is really the only solution here (other than
changing the legacy interface, which often isn't an option), which is why
I said telling them not to use thread_specific_ptr is the same as telling
them not to use Boost.Threads.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [BoostBook] Guinea pig request
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 out the BoostBook tools to see if they can easily build documentation, and report your successes, failures, and general level of frustration to the Boost documentation list or to me personally so I can improve the situation for future users and developers. You'll need a few tools, a very recent checkout of Boost CVS, and possibly a little patience, but everything is explained (I hope) in the Getting Started guide here: http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/ Any takers? Please? Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
