Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0(mostlylexical_cast.hpp)
In message [EMAIL PROTECTED], Terje Slettebø [EMAIL PROTECTED] writes 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? Apologies for the non-response. I'm travelling at the minute so I haven't had time to check the list. A quick response on this one, and hopefully I'll get time at the weekend to respond to other postings. What I need to understand is why type_info is very bad for you but exception handling is not. These two normally are typically included in or excluded from an application together. So you need to be clear about what environmental constraints would lead you to exclude RTTI, include EH, and also to include the not insignificant body of code that is I/O streams. 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? The feature tests are really about compiler conformance rather than arbitrarily customisable features. I am wary of introducing an opt out for a well-supported feature unless it really is a clear cut reason. Optionality in interfaces is generally not a good thing. Kevlin Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Determining interest in combining_iterator
Thomas Becker [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. 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? Basically, I think we have two contradictory scenarios. IIUC, the situations you have encountered are where you have a set of values in different containers that needed to be combined into a single value, in which case it makes sense to pass the values as distinct function arguments to a functor that does the combining. OTOH, the situations I am thinking of require that the tuple of containers is really treated as a container of tuples, complete with the ability to update the source containers by writing to the tuple obtained by the dereferencing, but maintaining the value semantics when copied. This is really hard to do in any other way than by having *it return a magic tuple, IMHO, though if you can find a way of doing it as a functor that just works without the user having to know too much, I'll concede the point. 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... ;-) Yeah, well, I guess it comes from the use cases I'm thinking of. Anyway, in the scenarios where a copy would not be required because the iterators return references, the magic tuple would essentially contain references to the originals (which metamorphose into real copies if you copy it), so a good optimizer *should* be able to optimize the packing/unpacking away --- at worst it is a few pointer copies. I would be quite happy if we had both a combining_iterator and a tuple_iterator, or if you could find a way of writing a suitable functor as I stated above. 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] [BoostBook] Guinea pig request
Douglas Paul Gregor wrote: 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? Spirit desperately needs a reference manual. Yes, I'm very interested. I am also very interested to build Spirit based tools to make the task easier. I'm just afraid of the time that I need to commit. Perhaps I can proceed step-wise? Suggestions? -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] VC7/Threads Warnings /Wp64 flag (detect 64-bitportability)
You are probably right - but the tool tip display shows an __int64 which alerted me to this. For most purposes, I suspect this warning /Wp64 is not what most people want.(Or is it Boost policy that code should provide 64-bit portability? Premature?) If one writes: std::size_t s = 42; cout s endl; with MSVC7.0 default project settings for an empty console project on my 32-bit system /D WIN32 /D NDEBUG /D _CONSOLE /D _MBCS /GF /FD /EHsc /ML /GS /Gy /FoRelease/ /FdRelease/vc70.pdb /W3 /nologo /c /Wp64 /Zi /TP it is confusing to get a warning: test_size_t.cpp(19) : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned int', possible loss of data (I am unclear why there is a warning unless unsigned int is 32-bit and size_t is 64-bit. How is there a problem if both are 32 or 64?) If one changes to warning level 4/W4 and no test for 64 portability /Wp64 /D WIN32 /D NDEBUG /D _CONSOLE /D _MBCS /GF /FD /EHsc /ML /GS /Gy /FoRelease/ /FdRelease/vc70.pdb /W4 /nologo /c /Zi /TP No warnings. And ideally request 'strict' - no extensions and for scope: /D WIN32 /D NDEBUG /D _CONSOLE /D _MBCS /GF /FD /EHsc /ML /Za /Zc:forScope /FoRelease/ /FdRelease/vc70.pdb /W4 /nologo /c /Zi /TP Still no warnings. In my experience, carefully written code (which Boost code should be - and generally is) compiled with MSVC 7.0 and warnings at level 4 produces only a few warnings, and those can be individually supressed - and should be as a matter of good documentation. Paul PS Despite RTFM, I cannot see how to change the IDE _default_ solution/project settings. Suggestions? Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Peter Dimov Sent: Wednesday, March 26, 2003 1:58 PM To: Boost mailing list Subject: Re: [boost] VC7/Threads Warnings Paul A. Bristow wrote: I was surprised to find that /Wp64 flag (detect 64-bit portability) means that std::size_t is 64 bit. This leds to a number of oddities that confused me. Is this perhaps causing your problem? std::size_t is still 32 bit, /Wp64 generates warnings if the meaning of the code could have changed had size_t been 64 bit. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: [date_time] enabling microsec_clock under C++Builder
Jeff Garland [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I think this is a good addition, but we should probably make the addition for all Win32 compilers since I think this is actually part of the Win32 api. I agree with that. Would it be better to make it a millisec_clock, or just use the microsec_clock but the resolution is only milliseconds? Hmm, I'm thinking that for consistency it would probably be better to call it millisec_clock. Could be. I might be a bit off here (coming in late into the discussion), but I'd prefer consistency in my code; using microsec_clock for both Windows and Unix code - even if the real 'resolution' is dependent of the system time updates on the Win platforms. If you plan to timestamp events with low overhead, the easiest and fastest way to get the system time is GetSystemTimeAsFileTime (assuming you can defer the conversion from FILETIME to SYSTEMTIME until later). Just remember that you'll never (?) get more frequent updates of the system time than 10 or 15 (SMP system) milliseconds. Even though it is possible to affect the possible Sleep() resolution to get ~1 millisecond sleeps by using NtSetTimerResolution or multimedia timers, this doesn't seem to affect the system updates (I've never seen it update more often than the standard 10/15 ms even though I've tried). Anyone else got comments on that? I've got no experience on non-Intel or 64-bit Windows though. // Johan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Russell Hind [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Alisdair Meredith wrote: Russell Hind wrote: I agree with that. Would it be better to make it a millisec_clock, or just use the microsec_clock but the resolution is only milliseconds? WinAPI Note: we can get a higher resolution using the QueryPerformanceCounter API (and QueryPerformanceFrequency if resolution info is required) Can these be used to get an actual date/time though? Or just for high resolution timing? I've only had a brief look at them, so will read a bit more. Yes and yes. But the former (using them to get an actual date/time with a _low_ overhead) is ... well ... interesting ;-) // Johan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: exception context
Hello everyone, A quick note to let you know I hadn't forgotten about my post... I finally got some time to get back to this - thanks to Russell, Alisdair, Thomas, Darren, Greg, Brian, Gennaro for your replies. At the moment I'm still trying to digest all the info posted (including the reference to the call stack library thread that I went and found and read - thanks Russell, it was called improved exceptions, around July 2002). I'm still hoping to tie all the info together and somehow reason a way forward... ... but I might fail to do that and just throw my ideas in as well :-) Look out for something soon. Trevor ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request (novice alert)
I'm interested in learning about boostbook and would like to try it out. For some reason I can't seem to get my docbook tools to run. Perhaps someone can give me a hint what's wrong. I'm afraid I'm a docbook novice. I'm using Linux RH8.0 with all updates. I can run a simple test: db2pdf Test.xml Using catalogs: /etc/sgml/xml-docbook-4.2-1.0-14.cat Using stylesheet: /usr/share/sgml/docbook/utils-0.6.11/docbook-utils.dsl#print Working on: /home/nbecker/Test.xml Done. Here is the start of Test.xml: ?xml version=1.0 encoding=UTF-8? !DOCTYPE article PUBLIC -//OASIS//DTD DocBook XML V4.2//EN http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; [...] Now try with boostbook: db2pdf boostbook.xml jw: Please specify at least one catalog Any clue what's wrong? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Russell Hind [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Johan Nilsson wrote: I might be a bit off here (coming in late into the discussion), but I'd prefer consistency in my code; using microsec_clock for both Windows and Unix code - even if the real 'resolution' is dependent of the system time updates on the Win platforms. That is an option, but if a millisecond clock is introduced, it like to see it implemented on all platforms, then you could use that on all platforms rather than microsec_clock which isn't 'really' supported under windows. At least this way you are dealing with a known resolution. Yes, but why not have both on all platforms? // Johan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Russell Hind [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Johan Nilsson wrote: Can these be used to get an actual date/time though? Or just for high resolution timing? I've only had a brief look at them, so will read a bit more. Yes and yes. But the former (using them to get an actual date/time with a _low_ overhead) is ... well ... interesting ;-) How do you convert the tick count from QueryPerformanceCounter into a date time then? I can't see how to do this? In brief: get the value of QPC at the instance the system time changes. The devil is in the details, of course, but it's a good starting point. // Johan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: VC7/Threads Warnings /Wp64 flag (detect64-bitportability)
Paul, Paul A. Bristow [EMAIL PROTECTED] wrote You are probably right - but the tool tip display shows an __int64 which alerted me to this. For most purposes, I suspect this warning /Wp64 is not what most people want.(Or is it Boost policy that code should provide 64-bit portability? Premature?) Intellisense does not work very well with template and preprocessor stuff. If one writes: std::size_t s = 42; cout s endl; with MSVC7.0 default project settings for an empty console project on my 32-bit system /D WIN32 /D NDEBUG /D _CONSOLE /D _MBCS /GF /FD /EHsc /ML /GS /Gy /FoRelease/ /FdRelease/vc70.pdb /W3 /nologo /c /Wp64 /Zi /TP it is confusing to get a warning: test_size_t.cpp(19) : warning C4267: 'argument' : conversion from 'size_t' to 'unsigned int', possible loss of data (I am unclear why there is a warning unless unsigned int is 32-bit and size_t is 64-bit. How is there a problem if both are 32 or 64?) Basically the /Wp64 option tries to find portability problems for types that are 32 bit on the Win32 platform and 64 bits on the Win64 platform. Usually the definition is selected based on the preprocessor macros for the platform #ifdef _WIN64 typedef __int64 xy; #else typedef int xy; #endif The compiler will NOT take the above into account when checking for W64 compatibility ( at that point the preprocessor has already run). Instead you should provide a hint to the compiler that a given type will be 8 bytes on the 64bit platform. You can use __w64 for this purpose. E.g. int i = (int)(void*)0; // warning typedef __w64 int ptr_int; ptr_int j = (ptr_int)(void*)0;// Ok /Wp64 will not detect cases where you have overloads (and that's true for your example). That is: first overloads are selected, then the compiler thinks what if pointers (and types qualified with __w64) were be 64 bit? ::size_t is implicitly __w64 and that cause the bogus warning. It is IMHO a better idea to do complete Win64 builds. It's pretty simple to build solutions/projects from the command line. Just open the Win64 console build environment and use devenv with the /useenv switch. The SDK compiler front end is based on an early version of 7.1 which could cause some headache. If one changes to warning level 4/W4 and no test for 64 portability /Wp64 /D WIN32 /D NDEBUG /D _CONSOLE /D _MBCS /GF /FD /EHsc /ML /GS /Gy /FoRelease/ /FdRelease/vc70.pdb /W4 /nologo /c /Zi /TP No warnings. And ideally request 'strict' - no extensions and for scope: /D WIN32 /D NDEBUG /D _CONSOLE /D _MBCS /GF /FD /EHsc /ML /Za /Zc:forScope /FoRelease/ /FdRelease/vc70.pdb /W4 /nologo /c /Zi /TP Still no warnings. BTW: You should be able to use /Zc:wchar_t without problems with the C++ standard library, too. It makes wchar_t a built-in type ( and not a typedef for unsigned short ). PS Despite RTFM, I cannot see how to change the IDE _default_ solution/project settings. Suggestions? You could update the script files in VC7\VCWizards\(Project)\scripts\*.js Just add a ClTool.WarningLevel = 4 somewhere. I haven't tried but I think it should work. -hg ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Johan Nilsson wrote: Yes, but why not have both on all platforms? It would make using it cross-platform easier, but you aren't actually getting microsecond information under windows, so if your program relies on that detail, it won't work correctly under windows anyway, so you must make your program work with millisecond times and you could then just use your millisec_clock on both platforms. Basically, I both agree and disagree. I agree from the point of view of using the library cross-platform, but disagree on the principle that your using something that promises microsecond detail, but in fact is only returning millisecond. (in my example anyway, if you could make the microsecond stuff work from QPC then that would be fine) Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Russell Hind [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Johan Nilsson wrote: Yes, but why not have both on all platforms? It would make using it cross-platform easier, but you aren't actually getting microsecond information under windows, so if your program relies on that detail, it won't work correctly under windows anyway, so you must make your program work with millisecond times and you could then just use your millisec_clock on both platforms. Basically, I both agree and disagree. I agree from the point of view of using the library cross-platform, but disagree on the principle that your using something that promises microsecond detail, but in fact is only returning millisecond. (in my example anyway, if you could make the microsecond stuff work from QPC then that would be fine) Perhaps, but one should consider that GetSystemTime promises 1ms resolution and delivers 10-15ms (and, IIRC, that GetSystemTimeAsFileTime promises 250ns resolution). // Johan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Johan Nilsson wrote: Yes, but why not have both on all platforms? I suppose another solution is to have secs_clock, millisecs_clock on windows, all three on another platform that supports microseconds, and then a typedef of something like highprescision_clock which on windows will be a millisecs_clock, and on other platforms will be microsecs_clock, but you won't need to know, you just get the highest precision available. Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] compare
[EMAIL PROTECTED] writes: Hey Jan - First off, let me say: excellent idea! Several times I've wanted just such a class, and I would be happy to see this added to Boost. I have a few suggestions/things to consider: 1) Instead of operator bool, use the unspecified-bool-type discussed elsewhere on this list; it's safer. Yup. 2) I'm not sure that the choice of the name is ideal. OTOH, I can't think of a better one... lexicographic? 3) I'd like to see a general solution for this problem using real (late-bound) function objects as well, if you know what I mean. This would be a lot harder, though, so maybe it should be put on a wish-list. Have you given any thought to this approach? return compare.less(p1.x, p2.x) .greater(p1.y, p2.y) .call(f, p1.z, p2.z); ?? Just one dumb idea for a comparison DSL... - Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request
On Thu, 27 Mar 2003, Joel de Guzman wrote: Spirit desperately needs a reference manual. Yes, I'm very interested. I am also very interested to build Spirit based tools to make the task easier. I'm just afraid of the time that I need to commit. Perhaps I can proceed step-wise? Suggestions? It depends on how you want to write your documentation. Are you planning to annotate your source with comments and use an extraction tool (e.g., Doxygen), or would you prefer to write interfaces by hand? The former is generally preferred, but the latter might be needed if the user-view of the interfaces is so different from the implementation that you would be fighting the extraction tool the whole time. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request (novice alert)
On Thu, 27 Mar 2003, Neal D. Becker wrote: Now try with boostbook: db2pdf boostbook.xml jw: Please specify at least one catalog Any clue what's wrong? BoostBook isn't DocBook (although it can be transformed into DocBook), so DocBook tools won't work directly on it. We have our own build tools (Boost.Build v2) that are roughly equivalent to those scripts. See the Getting Started section here for info on getting BoostBook up and running with bjam: http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/ You probably have most/all of the prerequisites already, you'll just need to tell BBv2 about them. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Johan Nilsson wrote: Perhaps, but one should consider that GetSystemTime promises 1ms resolution and delivers 10-15ms (and, IIRC, that GetSystemTimeAsFileTime promises 250ns resolution). The Platform SDK states that the tickcount (GetTickCount) is updated every 10ms on NT3.51 and hight so I guess that GetSystemTime is updated at this interval also. FileTimes are measured in 100 nanosecond intervals since 1 January, 1601, but are you sure that GetSystemTimeAsFileTime will return a value that is updated at 250ns intervals? I can't find anything in the SDK to say what the update interval is for the SystemTime, I'm just guessing that it is updated when the tick count is. Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Re: Thread Lib and DLL
William E. Kempf [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
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
Ahhh, the light bulb just went on, I finally understand. However, it does
seem like this usage of TLS is a corner case, that is refactoring code to be
thread safe. I can see how this could be useful and may be a larger corner
that I am aware, but it is something that I have not had to do before.
However, it seems like the solution to this problem has some very severe
consequences, namely forcing the user to compile with a DLL rather than a
static lib on Win32 systems. I understand that you would like to make the
thread library as easy and error-free to use as possible, but that solution
that requires the use of a DLL prevents me from using a library that I
greatly value.
I have two main issues with using a DLL, one is another corner case, and the
second is far less practical but more of an aesthetic. The first is this:
on a recent project, we had a requirement that the final binary was one and
only one .exe. Due to the nature of the project, anything else would be
unacceptable (the discussion of why would lead to another conversation :).
I could not have used the threads library in its current state. Secondly,
when I ship a product, I want the customer, programmer or not, to view its
internal workings as magic. I don't want them to know how I am doing
anything. Obviously they can hex edit the binary and figure out anything
they want to, but that takes a more skilled person that the one who is able
to see a dll and know that I am using boost threads. Admittedly, this is
not a sound scientific complaint, but still valid in my eyes.
I would be more than happy to try and help with a solution that would handle
both of the corner cases, or at least allow the library user to compile as
desired while knowing the consequences of their recompilation. I hope that
the case is not closed on restoring the static library compilation in future
versions of the thread library.
After all of this, maybe the thread docs need this question answered as part
of the FAQ? :)
Thank you for your patience and explanations,
David Brownell
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] compare
-Original Message- From: David Abrahams [mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] writes: 3) I'd like to see a general solution for this problem using real (late-bound) function objects as well, if you know what I mean. This would be a lot harder, though, so maybe it should be put on a wish-list. Have you given any thought to this approach? return compare.less(p1.x, p2.x) .greater(p1.y, p2.y) .call(f, p1.z, p2.z); ?? Sorry, I wasn't very clear. I mean defining a compare_t that could be used something like: compare_tposition::x, position::y, position::z that would result in a function object type that produced the same behaviour when given two arguments of type 'position'. (Usable, e.g., as a template argument to std::set). I don't see any way of supporting that simple of a syntax, though; the nicest I can see is: compare_typeposition, compare_tdouble, position::x, compare_tdouble, position::y, compare_tdouble, position::z which is pretty hideous. :( -Steve ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Re: Thread Lib and DLL
David Brownell said: William E. Kempf [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Ahhh, the light bulb just went on, I finally understand. However, it does seem like this usage of TLS is a corner case, that is refactoring code to be thread safe. I can see how this could be useful and may be a larger corner that I am aware, but it is something that I have not had to do before. However, it seems like the solution to this problem has some very severe consequences, namely forcing the user to compile with a DLL rather than a static lib on Win32 systems. I understand that you would like to make the thread library as easy and error-free to use as possible, but that solution that requires the use of a DLL prevents me from using a library that I greatly value. Actually, it's a very significant use case, not a corner case. In addition, other use cases can result in the same problems. When a library allocates TLS, it does so because it needs to maintain state for a thread it did not create. After all, if it created the thread, there are easier and more efficient methods to maintain state. I have two main issues with using a DLL, one is another corner case, and the second is far less practical but more of an aesthetic. The first is this: on a recent project, we had a requirement that the final binary was one and only one .exe. Due to the nature of the project, anything else would be unacceptable (the discussion of why would lead to another conversation :). I could not have used the threads library in its current state. Secondly, when I ship a product, I want the customer, programmer or not, to view its internal workings as magic. I don't want them to know how I am doing anything. Obviously they can hex edit the binary and figure out anything they want to, but that takes a more skilled person that the one who is able to see a dll and know that I am using boost threads. Admittedly, this is not a sound scientific complaint, but still valid in my eyes. The first is very valid. I never claimed to like the DLL requirement ;). In fact, I've been in search of a solution that didn't require this (and for more reasons than just wanting to support static linking!) from the outset. Unfortunately, I don't believe there is a solution at this point. The second is totally uncompelling. If hiding usage is all your after, rename the DLL (do this by changing the stage rule in the Jamfile). I would be more than happy to try and help with a solution that would handle both of the corner cases, or at least allow the library user to compile as desired while knowing the consequences of their recompilation. I hope that the case is not closed on restoring the static library compilation in future versions of the thread library. It's not closed, but it's in definate limbo until after V2 is complete, since that will change which cases require TLS cleanup. But I definately want a better solution to this problem as well, so don't be discouraged. After all of this, maybe the thread docs need this question answered as part of the FAQ? :) Yes, it does, and I'll work on that shortly ;). -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request (novice alert)
OK, I can get boostbook running on RH8.0 using: using boostbook : /usr/share/sgml/docbook/xsl-stylesheets/ : /usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-14/ ; My interest was to try to learn about boostbook for my own purposes, which means running without bjam. Where would I find info on this, or can I ask bjam to show me the commands it is running? On Thursday 27 March 2003 10:17 am, Douglas Paul Gregor wrote: On Thu, 27 Mar 2003, Neal D. Becker wrote: Now try with boostbook: db2pdf boostbook.xml jw: Please specify at least one catalog Any clue what's wrong? BoostBook isn't DocBook (although it can be transformed into DocBook), so DocBook tools won't work directly on it. We have our own build tools (Boost.Build v2) that are roughly equivalent to those scripts. See the Getting Started section here for info on getting BoostBook up and running with bjam: http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/ You probably have most/all of the prerequisites already, you'll just need to tell BBv2 about them. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request
Douglas Paul Gregor said: 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? Documentation nits: * and including that Jamfile in the list of Jamfiles including for testing under Testsuites... should be included for testing. * Navigation links have broken images. Probably only an issue on your web server, right? * The documentation on modifying user-config.jam doesn't make it clear that you don't need to do *any* configuration if you wish to just let the build process pull the stylesheets off the Internet. Problems building: * On Mandrake 9.1 I had no issues. * On Cygwin, I get the result: xslt-xsltproc bin\gcc\debug\boost.docbook 'XML_CATALOG_FILES' is not recognized as an internal or external command, operable program or batch file. XML_CATALOG_FILES=catalog.xml xsltproc --xinclude -o bin\gcc\debug\boost.docbook C:\cygwin\home\wekempf\boost/tools/boostbook/xsl/docbook.xsl src\boost.xml failed xslt-xsltproc bin\gcc\debug\boost.docbook... I have the following installed under cygwin: libxml2 2.4.23-1 libxslt 1.0.13-1 At this point, I have no clue how to diagnose the problem. This is the result of my first attempts to just compile the existing documentation to html. After I get the Cygwin build working, I'll move on to FOP and PDF generation and report other things I find. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [BoostBook] Guinea pig request
On Thu, 27 Mar 2003, Daniel James wrote: Hi, I had a go. I'm using windows ME, and had to do a lot of stuff manually, since I'm not using Cygwin. I had to edit catalog.xml, removing some extra punctuation and changing some of the slashes from windows style to uri style (ie. c:\src\boost\ to c:/src/boost/). After that I wrote a little batch file to run xsltproc and it worked fine. But of course, that should be fixed in boost build eventually. Thanks. I'm still working on the Windows path problems (those are relatively easy to fix) and the strange punctuation issues. The Windows 9x/ME echo command seems to have this nasty behavior of passing along double quotes (grrr). I did do one stupid thing though. When I first went to download the DocBook DTD, I downloaded just docbookx.dtd instead of the whole archive. I think this was just me being clumsy, but you could say 'download the zip archive' or something. Daniel Done, thanks. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request (novice alert)
On Thu, 27 Mar 2003, Neal D. Becker wrote: OK, I can get boostbook running on RH8.0 using: using boostbook : /usr/share/sgml/docbook/xsl-stylesheets/ : /usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-14/ ; My interest was to try to learn about boostbook for my own purposes, which means running without bjam. Where would I find info on this, or can I ask bjam to show me the commands it is running? bjam --v2 -n That will print out the command lines it is using without actually running any of them. Since you are using a *nix system, you could check out the makefiles and configure script that were in tools/boostbook/build. They're in the attic now, but you can get to them using the CVS web interface. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [BoostBook] Guinea pig request
On Thu, 27 Mar 2003 10:40:26 -0600 (CST), William E. Kempf [EMAIL PROTECTED] wrote:
Problems building:
* On Mandrake 9.1 I had no issues.
* On Cygwin, I get the result:
xslt-xsltproc bin\gcc\debug\boost.docbook
'XML_CATALOG_FILES' is not recognized as an internal or external command,
operable program or batch file.
XML_CATALOG_FILES=catalog.xml xsltproc --xinclude -o
bin\gcc\debug\boost.docbook
C:\cygwin\home\wekempf\boost/tools/boostbook/xsl/docbook.xsl
src\boost.xml
XML_CATALOG_FILES={something} xsltproc ...
This is bash syntax for temporarily setting an environment variable for
the duration of the xsltproc program run. Are you using bash on Cygwin,
or the normal cmd.exe shell? The latter probably doesn't understand this
syntax.
.failed xslt-xsltproc bin\gcc\debug\boost.docbook...
I have the following installed under cygwin:
libxml2 2.4.23-1
libxslt 1.0.13-1
At this point, I have no clue how to diagnose the problem.
Probably not related to any of these.
HTH,
-- Remy
Remove anti-spam sequence in reply address for a timely response.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compare
On Thu, 27 Mar 2003 10:00:47 -0500, David Abrahams [EMAIL PROTECTED] wrote: 2) I'm not sure that the choice of the name is ideal. OTOH, I can't think of a better one... lexicographic? Indeed. We have an order relation in X, and use what mathematicians call lexicographic order induced in X^n by . A question worth asking ourselves, I think, is how good are current compilers at inlining this stuff. I had an application where thousands of points (coming from a VRML draw) had to be lexicographically ordered and analyzed. Given the size of the VRML files, that took generally a whole night on our machines. I don't dare to imagine what would have happened by implementing operator() recursively without compiler optimization. Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request
On Thu, 27 Mar 2003, William E. Kempf wrote: Documentation nits: * and including that Jamfile in the list of Jamfiles including for testing under Testsuites... should be included for testing. That's one seriously ugly sentence I wrote. Fixed now. Thanks. * Navigation links have broken images. Probably only an issue on your web server, right? It's not quite that easy. Some of the stylesheets just guess at the relative location of $BOOST_ROOT, and they guess wrong. This information is easy to get in Boost.Build, so I'll pass it through to the stylsheets and correct this ASAP. * The documentation on modifying user-config.jam doesn't make it clear that you don't need to do *any* configuration if you wish to just let the build process pull the stylesheets off the Internet. Hmmm, good point. I've just added a section on configuring for local copies of the DocBook DTD and XSL stylesheets, and I just reference that section in Getting Started. Problems building: * On Mandrake 9.1 I had no issues. * On Cygwin, I get the result: xslt-xsltproc bin\gcc\debug\boost.docbook 'XML_CATALOG_FILES' is not recognized as an internal or external command, operable program or batch file. XML_CATALOG_FILES=catalog.xml xsltproc --xinclude -o bin\gcc\debug\boost.docbook C:\cygwin\home\wekempf\boost/tools/boostbook/xsl/docbook.xsl src\boost.xml failed xslt-xsltproc bin\gcc\debug\boost.docbook... Looks like I can't set an environment variable that way in Cygwin (or in Windows without Cygwin, for that matter). Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compare
On Thu, 27 Mar 2003 18:34:05 +0100, Gennaro Prota [EMAIL PROTECTED] wrote: David Abrahams[EMAIL PROTECTED] wrote: lexicographic? Indeed. We have an order relation in X, and use what mathematicians call lexicographic order induced in X^n by . Yup! I should have looked better at the code. It's actually much more general than that :-) Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request
Douglas Paul Gregor wrote: I would like a volunteer ... I gave it a try: - html: works like a charm. - onehtml ditto - pdf: lots of messages regarding missing hyphenation pattern for language en. A pdf file is created, however. Is there a chance to specify a different paper size (e.g. A4)? - man: great - docbook: not tested - fo: not tested - documentation: I had a little problem to locate the docbook.dtd because I didn't find information that it is contained in a package named docbook-xml Software used: libxml2-2.5.1, libxslt-1.0.24, fop-0.20.5rc2, j2re1.4.0_03, docbook-xml-4.2, docbook-xsl-1.60.1 Summary: looks very good, already. However, to be able to set the paper size is important. Documentation was sufficient for me. oink oink, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request
On Thursday 27 March 2003 12:41 pm, Douglas Paul Gregor wrote: On Thu, 27 Mar 2003, William E. Kempf wrote: * On Cygwin, I get the result: xslt-xsltproc bin\gcc\debug\boost.docbook 'XML_CATALOG_FILES' is not recognized as an internal or external command, operable program or batch file. XML_CATALOG_FILES=catalog.xml xsltproc --xinclude -o bin\gcc\debug\boost.docbook C:\cygwin\home\wekempf\boost/tools/boostbook/xsl/docbook.xsl src\boost.xml failed xslt-xsltproc bin\gcc\debug\boost.docbook... Looks like I can't set an environment variable that way in Cygwin (or in Windows without Cygwin, for that matter). Looks to me that you're not using bash under cygwin. Make sure you're using bash for the shell that jam is using (I don't know anything about jam, how does it select the shell?) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request
On Thu, 27 Mar 2003, Martin Wille wrote: Douglas Paul Gregor wrote: I would like a volunteer ... I gave it a try: Thanks! - pdf: lots of messages regarding missing hyphenation pattern for language en. A pdf file is created, however. This seems to be a problem with fop 0.20.5-rc2. I dropped back to 0.20.4 and the problem disappeared. Documented now. Is there a chance to specify a different paper size (e.g. A4)? I haven't documentated passing XSL parameters yet, but you want this: bjam --v2 pdf xsl:param=paper.type=A4 - documentation: I had a little problem to locate the docbook.dtd because I didn't find information that it is contained in a package named docbook-xml They don't even both to refer to it as a DTD! I've made a note of this in the documentation. Summary: looks very good, already. However, to be able to set the paper size is important. Documentation was sufficient for me. Great. In the future I'll make it easier to specify XSL parameters, e.g., the paper type, once in the Boost.Build configuration instead of requiring it to be on the command line. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Regression tests failing - tools not building
On Monday, I attempted to run the Darwin regression tests off the main branch.
The tools failed to build - specifically process_jam_log failed to build, because
the filesystem library failed to compile.
In particular, libs/filesystem/src/exception.cpp failed on line 192 in
the constructor:
filesystem_error::filesystem_error(
const std::string who,
const std::string message )
line 192--: std::runtime_error(
other_error_prep( who, message ).c_str() ),
m_sys_err(0), m_err(other_error), m_who(who)
{}
There are a couple of things here:
1) std::runtime_error is defined (for gcc, AFAICT) in stdexcept, but
filesystem/exception.hpp
only includes exception.
-- This, IMHO, is the cause of the error.
2) filesystem_error is defined (in filesystem/exception.hpp) as inheriting from
std::exception,
not std::runtime_error.
class filesystem_error : public std::exception
{
When I add the line #include stdexcept to exception.cpp, I get the following error
instead:
../../../libs/filesystem/src/exception.cpp: In constructor
`boost::filesystem::filesystem_error::filesystem_error(const std::string,
const std::string)':
../../../libs/filesystem/src/exception.cpp:196: type `class std::runtime_error'
is not a direct base of `boost::filesystem::filesystem_error'
--
-- Marshall
Marshall Clow Idio Software mailto:[EMAIL PROTECTED]
Hey! Who messed with my anti-paranoia shot?
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [BoostBook] Guinea pig request
Remy Blank said:
On Thu, 27 Mar 2003 10:40:26 -0600 (CST), William E. Kempf
[EMAIL PROTECTED] wrote:
Problems building:
* On Mandrake 9.1 I had no issues.
* On Cygwin, I get the result:
xslt-xsltproc bin\gcc\debug\boost.docbook
'XML_CATALOG_FILES' is not recognized as an internal or external
command, operable program or batch file.
XML_CATALOG_FILES=catalog.xml xsltproc --xinclude -o
bin\gcc\debug\boost.docbook
C:\cygwin\home\wekempf\boost/tools/boostbook/xsl/docbook.xsl
src\boost.xml
XML_CATALOG_FILES={something} xsltproc ...
This is bash syntax for temporarily setting an environment variable for
the duration of the xsltproc program run. Are you using bash on Cygwin,
or the normal cmd.exe shell? The latter probably doesn't understand this
syntax.
Bash.
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [BoostBook] Guinea pig request
-Original Message- From: Douglas Paul Gregor [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 11:31 PM 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 Hi Doug. My little group is nearing release of a set of libraries, plus an application that runs on top of them. We don't have any formal documentation as of yet, but are required to produce library level docs, so I'm interested in looking at BoostBook. I guess the bad news is that it looks like we're 3 or 4 weeks away from being able to work on it, and we have absolutely no background or familiarity with BoostBook. If I get a chance, I'll start perusing the Getting Started guide. Let me know if there's anything I might be able to do in the meantime though. Thanks, Greg Hickman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request
On Thu, 27 Mar 2003, Douglas Paul Gregor wrote: On Thu, 27 Mar 2003, Joel de Guzman wrote: Spirit desperately needs a reference manual. Yes, I'm very interested. I am also very interested to build Spirit based tools to make the task easier. I'm just afraid of the time that I need to commit. Perhaps I can proceed step-wise? Suggestions? It depends on how you want to write your documentation. Are you planning to annotate your source with comments and use an extraction tool (e.g., Doxygen), or would you prefer to write interfaces by hand? The former is generally preferred, but the latter might be needed if the user-view of the interfaces is so different from the implementation that you would be fighting the extraction tool the whole time. Doug FWIW, the basic Jamfile.v2 for using Doxygen would be: project boost/spirit/doc ; import boostbook : boostbook ; import doxygen : doxygen ; doxygen spirit.doxygen : ../../../boost/spirit/ : recursiveon pattern*.hpp ; boostbook spirit : spirit.doxygen ; With a patched Doxygen (see the Getting Started docs) and this Jamfile.v2 in libs/spirit/doc, I can generate skeletal documentation for Spirit. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] compare
-Original Message-
From: Jan Langer [mailto:[EMAIL PROTECTED]
Just one other thing - instead of:
enum result { minus, zero, plus };
I would do:
enum result { minus = -1, zero, plus };
just for the sake of code readability and ease of understanding. It doesn't
change the logic at all.
-Steve
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost Pool Library interface discrepancy
As far as I can tell, the documented pool::get_requested_size() is not implemented. Mike ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compare
David Abrahams wrote: 1) Instead of operator bool, use the unspecified-bool-type discussed elsewhere on this list; it's safer. Yup. ok, i changed it. 2) I'm not sure that the choice of the name is ideal. OTOH, I can't think of a better one... lexicographic? i dont bother about the name. if this is better i will change it. 3) I'd like to see a general solution for this problem using real (late-bound) function objects as well, if you know what I mean. This would be a lot harder, though, so maybe it should be put on a wish-list. Have you given any thought to this approach? return compare.less(p1.x, p2.x) .greater(p1.y, p2.y) .call(f, p1.z, p2.z); now this would be: return compare (p1.x, p2.x, std::less double ()) (p1.y, p2.y, std::greater double ()) (p1.z, p2.z, f); or nearly the same: return compare (p1.x, p2.x) (p2.y, p1.y) (p1.z, p2.z, f); if the name lexicographic is ok, i will put it in the sandbox. i assume the directory utility is the correct place. jan -- jan langer ... [EMAIL PROTECTED] pi ist genau drei ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request
Douglas Paul Gregor said: On Thu, 27 Mar 2003, Martin Wille wrote: Douglas Paul Gregor wrote: I would like a volunteer ... I gave it a try: Thanks! - pdf: lots of messages regarding missing hyphenation pattern for language en. A pdf file is created, however. This seems to be a problem with fop 0.20.5-rc2. I dropped back to 0.20.4 and the problem disappeared. Documented now. I'm using 0.20.4 (on Mandrake 9.1) and receive lots of errors. A few examples: [ERROR] Error in column-width property value '33%': org.apache.fop.fo.expr.PropertyException: No conversion defined [ERROR] property - last-line-end-indent is not implemented yet. [ERROR] property - linefeed-treatment is not implemented yet. And others as well (plus a lot of warnings). If you want a full log, I can send it. A PDF is generated, but lands in $BOOST_ROOT/doc/bin/gcc/debug/boost.pf. Shouldn't this be in $BOOST_ROOT/doc/pdf or something similar? The produced PDF is viewable, and looks pretty good from a casual glance. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression tests failing - tools not building
At 01:28 PM 3/27/2003, Marshall Clow wrote:
On Monday, I attempted to run the Darwin regression tests off the main
branch.
The tools failed to build - specifically process_jam_log failed to
build,
because the filesystem library failed to compile.
In particular, libs/filesystem/src/exception.cpp failed on line 192 in
the constructor:
filesystem_error::filesystem_error(
const std::string who,
const std::string message )
line 192-- : std::runtime_error(
other_error_prep( who, message ).c_str() ),
m_sys_err(0), m_err(other_error), m_who(who)
{}
Marshall,
Three days ago I changed boost/filesystem/exception.hpp and
libs/filesystem/src/exception.cpp. I just checked CVS, and see that both
changes did get committed.
Yet it looks like you have the changes to boost/filesystem/exception.hpp,
but not the changes to libs/filesystem/src/exception.cpp, and that is what
is causing the compiler errors.
Try a cvs update again, and see if that doesn't clear the problem.
--Beman
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compare
On Thu, 27 Mar 2003 14:01:12 -0500, [EMAIL PROTECTED] wrote:
-Original Message-
From: Jan Langer [mailto:[EMAIL PROTECTED]
Just one other thing - instead of:
enum result { minus, zero, plus };
I would do:
enum result { minus = -1, zero, plus };
just for the sake of code readability and ease of understanding. It doesn't
change the logic at all.
Well, if we are really going to discuss such quibbles, I would also
change zero to equiv because that's the usual term used for
strict weak ordering. And I would avoid constructs like
template typename T
compare (T const a, T const b)
: v_ (compare () (a, b).v_) // --
{}
by doing, for instance,
class compare
{
enum result { minus, equiv, plus };
result v_;
template typename T
static result do_compare(const T a, const T b) {
if (a b) return minus;
else if (b a) return plus;
return equiv;
}
public:
compare () : v_ (equiv) {}
template typename T
compare (T const a, T const b)
: v_ (do_compare(a, b))
{}
template typename T
compare operator () (T const a, T const b)
{
if (v_ == equiv)
do_compare(a, b);
return *this;
}
};
But there are more important points I think; first of all this: if all
I can see from the outside is whether v_== minus [note: this is
'plus' in the original code] why keeping three states internally?
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost Pool Library interface discrepancy
-Original Message- From: Michael Glassford [mailto:[EMAIL PROTECTED] As far as I can tell, the documented pool::get_requested_size() is not implemented. You are correct. I will fix this. -Steve ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: compare
-Original Message- From: Gennaro Prota [mailto:[EMAIL PROTECTED] On Thu, 27 Mar 2003 14:01:12 -0500, [EMAIL PROTECTED] wrote: Well, if we are really going to discuss such quibbles, I would also change zero to equiv because that's the usual term used for strict weak ordering. And I would avoid constructs like snip I agree. But there are more important points I think; first of all this: if all I can see from the outside is whether v_== minus [note: this is 'plus' in the original code] why keeping three states internally? To allow for short-circuiting any future comparisions. The three states, whatever their names, mean: 1) The result is known to be true; no further comparisions are necessary 2) The result is known to be false; no further comparisions are necessary 3) The result is unknown; further comparisions are necessary. -Steve ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: compare
Jan Langer [EMAIL PROTECTED] writes: David Abrahams wrote: 1) Instead of operator bool, use the unspecified-bool-type discussed elsewhere on this list; it's safer. Yup. ok, i changed it. 2) I'm not sure that the choice of the name is ideal. OTOH, I can't think of a better one... lexicographic? i dont bother about the name. if this is better i will change it. I don't really like it, FWIW. 3) I'd like to see a general solution for this problem using real (late-bound) function objects as well, if you know what I mean. This would be a lot harder, though, so maybe it should be put on a wish-list. Have you given any thought to this approach? return compare.less(p1.x, p2.x) .greater(p1.y, p2.y) .call(f, p1.z, p2.z); now this would be: return compare (p1.x, p2.x, std::less double ()) (p1.y, p2.y, std::greater double ()) (p1.z, p2.z, f); The problem with that is that it requires you to name the type of the arguments (and they have to be the same). or nearly the same: return compare (p1.x, p2.x) (p2.y, p1.y) (p1.z, p2.z, f); Maybe that's better. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compare
Gennaro Prota wrote:
Well, if we are really going to discuss such quibbles, I would also
change zero to equiv because that's the usual term used for
strict weak ordering. And I would avoid constructs like
template typename T
compare (T const a, T const b)
: v_ (compare () (a, b).v_) // --
{}
by doing, for instance,
class compare
{
enum result { minus, equiv, plus };
result v_;
template typename T
static result do_compare(const T a, const T b) {
if (a b) return minus;
else if (b a) return plus;
return equiv;
}
public:
[...]
};
ok, i didnt think too long about the implementation quality. but i will
change it for the next time.
But there are more important points I think; first of all this: if all
I can see from the outside is whether v_== minus [note: this is
'plus' in the original code] why keeping three states internally?
because i see no reason why they should be needed. and i can also
exchange the meaning of plus and minus, if it is prefered.
jan
--
jan langer ... [EMAIL PROTECTED]
pi ist genau drei
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request
On Thu, 27 Mar 2003, William E. Kempf wrote: I'm using 0.20.4 (on Mandrake 9.1) and receive lots of errors. A few examples: [ERROR] Error in column-width property value '33%': org.apache.fop.fo.expr.PropertyException: No conversion defined [ERROR] property - last-line-end-indent is not implemented yet. [ERROR] property - linefeed-treatment is not implemented yet. And others as well (plus a lot of warnings). If you want a full log, I can send it. These errors are normal with FOP. A PDF is generated, but lands in $BOOST_ROOT/doc/bin/gcc/debug/boost.pf. Shouldn't this be in $BOOST_ROOT/doc/pdf or something similar? It should, and I'll see what I can do about it. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request
Douglas Paul Gregor wrote: FWIW, the basic Jamfile.v2 for using Doxygen would be: project boost/spirit/doc ; import boostbook : boostbook ; import doxygen : doxygen ; doxygen spirit.doxygen : ../../../boost/spirit/ : recursiveon pattern*.hpp ; boostbook spirit : spirit.doxygen ; With a patched Doxygen (see the Getting Started docs) and this Jamfile.v2 in libs/spirit/doc, I can generate skeletal documentation for Spirit. Cool. I'll try this. Thanks! It seems you have lots of guinea pigs now :-) -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request
Douglas Paul Gregor said: On Thu, 27 Mar 2003, William E. Kempf wrote: I'm using 0.20.4 (on Mandrake 9.1) and receive lots of errors. A few examples: [ERROR] Error in column-width property value '33%': org.apache.fop.fo.expr.PropertyException: No conversion defined [ERROR] property - last-line-end-indent is not implemented yet. [ERROR] property - linefeed-treatment is not implemented yet. And others as well (plus a lot of warnings). If you want a full log, I can send it. These errors are normal with FOP. Ick! Any way to suppress the output in that case? -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Multithreaded Scaling Issues with regex
I am writing a multithreaded Apache log parser that uses the Boost 1_29_0 regex split function to separate elements in the entry. Each thread parses a separate log file. The code seems to be working correctly on a 1-CPU system, but when I use a 14-CPU Sun server, I see massive locking (LCK column of prstat -amLvu username), and performance suffers horribly (as measured by the lines processed per second). I spent a lot of time checking to see where the locking was occurring. I went so far as to compile the code with Sun's Forte 6u2 and use their analysis tools to identify the problem area. I've compiled all code (including Boost) with both gcc 3.2.2 and Forte to create 64-bit binaries, if that makes any difference. If I read the Forte analysis tools correctly, the place I'm seeing all the locking is the call to malloc in the void *operator new(unsigned long), which is called by boost::re_detail::match_results_base and _priv_match_data. Those are in turn called by query_match_aux, which is called by reg_grep2. Assuming I'm reading it right... At this point it seems like the issue is either with the library or my usage of it. Has anyone seen this before? Any pointers on what I may be doing wrong and how to fix it would be appreciated. TIA, Matt ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: io operations for stl containers?
I had 2 thoughts today... 1. Is it at all useful/possible to use a lambda-like notation? In the past, I've liked the look of that a lot. (the comments about alternate notation made me think of it) 2. Why are we restricting the output to strings? Couldn't the types of the 3 delimiter strings actually be implicit template parameters? (the char/wchar versions made me think of that) Just two quick thoughts. Overall, I like it a lot :) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost.Python and BCC
A question for David Abrahams (or anyone else who might have a bright idea).
I have resolved quite a few of the issues involved in porting Boost.Python
to Borland, but here is one particularly nasty problem. In
member_function_cast.hpp you have code, which after expansion at the hands
of Boost.Preprocessor, gives
template class T
struct member_function cast
{
template class S,class R
static cast_helperS, R (T::*) () stage1(R (S::*)())
{
return cast_helperS, R (T::*)()();
}
// Many more definitions of stage1() with increasing numbers of
parameters (arity).
};
Unfortunately, this runs foul of the infamous BCC emoticon bug, whereby
the ) character (and various others) will terminate the template argument
list. In the above, the compiler therefore sees cast_helperS,R
(T::*[end_of_template]. I assume that it is this bug which mandates the
special treatment for BCC in
boost/type_traits/is_member_function_pointer.hpp.
The standard workaround is to use a typedef, which in this case would be
typedef R (T::*T_mfp)();
static cast_helperS,T_mfp stage1(...)
But of course here we will need separate typedefs for each of the arities
of stage1(), and we need to define them so that they are available to the
stage1 template. It seems to me that the function overloading approach being
used here then becomes infeasible.
Any ideas?
Chris
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: io operations for stl containers?
From: Jason House [EMAIL PROTECTED]
I had 2 thoughts today...
1. Is it at all useful/possible to use a lambda-like notation?
In what way? Could you have given a rough syntax-example?
An example in BLL is:
std::for_each(v.begin(), v.end(), std::cout _1 '\n');
In the past, I've liked the look of that a lot.
(the comments about alternate notation made me think of it)
2. Why are we restricting the output to strings?
That _is_ a natural question, isn't it? :)
Couldn't the types of the 3 delimiter strings actually be
implicit template parameters?
(the char/wchar versions made me think of that)
Yes, that is how it currently works; it deduces the types passed to the
format function template, and returns an object of type format_type
(analogous to many cases, such as bind1st/binder1st).
Since all the string parameters have default to empty string, this is done
by having three overloads of the format function template - for
std::basic_string, const char * and const wchar_t *. That way, you can use
, L, etc. as appropriate, for the default.
As mentioned in some previous postings, a possibility for generalising the
formatting could be to pass a visitor object to the format-function,
instead of the strings, which is then invoked at the specific times during
output (begin/end sequence, etc.). One could then also support things like
line numbers and indentation, without hardcoding how this is done. It would
also be possible to make a visitor object which took strings in the
constructor, and gave the current semantics.
This approach seems to require dynamical allocation of the format data, and
virtual functions, though. Since this means quite a bit of change, I haven't
done it so far, but I'm open to the possibility.
An example of its use:
// Line numbering visitor (could be included in the library)
//
// All virtual functions are included for illustration. In practice, the
once with empty body could be omitted.
templateclass T, class CharType, class CharTraits
class numbering_type : public visitor_base
{
public:
explicit numbering(int ln) : line_number(ln) {}
virtual void start_sequence(std::basic_ostreamCharType,CharTraits
stream) {}
virtual void end_sequence(std::basic_ostreamCharType,CharTraits stream)
{}
virtual void element(std::basic_ostreamCharType,CharTraits stream,
const T element)
{ stream line_number ' ' element '\n'; ++line_number; }
private:
int line_number;
};
// The numbering function template returns a numbering_type object
typedef std::vectorchar vector;
vector v;
// Fill vector
std::cout formatvector(numbering())
v;
Output:
1 - A
2 - B
3 - C
etc.
Thanks.
Regards,
Terje
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compare
Gennaro Prota [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] But there are more important points I think; first of all this: if all I can see from the outside is whether v_== minus [note: this is 'plus' in the original code] why keeping three states internally? I wondered this as well, until I thought about this invokation: compare(x1, x2)(y1, y2)(z1, z2); Keeping the state internally allows for this function chaining, as the three states are passed from one functor to the next (which is necessary to provide the desired functionality). Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Russell Hind [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Johan Nilsson wrote: Perhaps, but one should consider that GetSystemTime promises 1ms resolution and delivers 10-15ms (and, IIRC, that GetSystemTimeAsFileTime promises 250ns resolution). The Platform SDK states that the tickcount (GetTickCount) is updated every 10ms on NT3.51 and hight so I guess that GetSystemTime is updated at this interval also. That's correct for uniprocessor machines. It is normally 15ms on SMP machines (at least on NT 4.0 upwards). As I said earlier, my only experience is with x86 machines (and NT, not Win9x et al). FileTimes are measured in 100 nanosecond intervals since 1 January, 1601, but are you sure that GetSystemTimeAsFileTime will return a value that is updated at 250ns intervals? I can't find anything in the SDK to say what the update interval is for the SystemTime, I'm just guessing that it is updated when the tick count is. Sorry - just a case of bad memory - 100ns is of course correct. I am definitely sure that GetSystemTimeAsFileTime will _not_ return a value that is updated more frequently than the system's tick interval. I just wanted to point out the similarity between: - GSTAFT having a 100ns resolution but not being updated more often than 10-15ms - microsec_clock having a microsec resolution but not being updated more often than 10-15ms // Johan ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Determining interest in combining_iterator
--- Anthony Williams
[EMAIL PROTECTED] wrote:
Basically, I think we have two contradictory
scenarios. IIUC, the situations
you have encountered are where you have a set of
values in different
containers that needed to be combined into a single
value, in which case it
makes sense to pass the values as distinct function
arguments to a functor
that does the combining.
That's true, that was the scenario that the combining
iterator grew out of, and that has certainly tilted my
perception of the problem in that direction. But when
I conceived of my combining iterator, I *did* think
about the other scenario that you mention:
OTOH, the situations I am thinking of require that
the tuple of containers is
really treated as a container of tuples, complete
with the ability to update
the source containers by writing to the tuple
obtained by the dereferencing,
but maintaining the value semantics when copied.
This is really hard to do in
any other way than by having *it return a magic
tuple, IMHO, though if you
can find a way of doing it as a functor that just
works without the user
having to know too much, I'll concede the point.
Because of my tilted perception, I sort of dismissed
that scenario by saying to myself, ah, shucks, just
write a functional that returns a suitable reference,
and you're good. You are now forcing me to think about
this more carefully, for which I am grateful to you.
Unless I'm missing something, I believe that my
original rough intuition was ok. Given my combining
iterator, it seems very easy to write your tuple
iterator by providing a simple generic
reference-tuple-making functional. As always in
these situations, it's a little messy to provide one
functional that will work for all n (n=number of
member iterators), so for simplicity, here's the case
n=2:
templatetypename Type1_, typename Type2_
class FunMakeReferenceTuple_2
{
public:
typedef boost::tupleType1_, Type2_ result_type;
boost::tupleType1_, Type2_ operator()(
Type1_ refFirst,
Type2_ refSecond
) const
{
return boost::tupleType1_, Type2_(
refFirst,
refSecond
);
}
};
I've tested this in several examples, e.g., I created
two vectors of ints, filled them with values to equal
length, then created a combining_iterator from the two
begin positions and the functional
FunMakeReferenceTuple_2int, int
Once I have this combining iterator, I can read and
write both vector elements to my hearts delight. E.g.,
std::swap(it-get0(), it-get1());
will swap the values at the current position, or,
*it = boost::make_tuple(42, 43);
will assign 42 and 43 to the respective vector
elements.
If you want to, you can easily wrap all this up and
provide a tuple_iterator which internally uses my
combining iterator in conjunction with the
reference-tuple-making functional. I now strongly
believe that that's the way to go. The combining
iterator handles for you everything that has to do
with the parallel-iteration. Via the funcional, you
decide how to process the dereferenced iterators. The
tuple_iterator is the special case (or rather, the
large subclass of cases) where that processing
consists of making a tuple of references. There's
certainly more to think about, like, what about const
tuple iterators, but I believe that the questions and
answers are the same whether you write the tuple
iterator from scratch or use my combining iterator. In
fact, doing it with the combining iterator seems
somehow intellectually cleaner to me, because all
the parallel iteration stuff is hidden and out of the
way, so you can focus on the tuple issues.
BTW, in my software, I do have cases where I need to
parallel iterate and write to the current positions,
but in those cases, I always deal with sequences of
possibly different length (think portfolio of assets
with different dates of inception). Now
parallel-iteration is really ugly business. There's
always a bigger can of worms...
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
RE: [boost] Re: compare
This really neat, and useful, but I really don't like either name. Two suggestions: comparisons - because the whole point is more than one compare. or compair - because one is comparing pairs. (Do I hear you groan? Not punny?) But perhaps the dreadfulness will make is more memorable? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 2) I'm not sure that the choice of the name is ideal. OTOH, I can't think of a better one... lexicographic? This implies something to do with lexicons, which is too restrictive, and even misleading. jan langer ... [EMAIL PROTECTED] pi ist genau drei ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
