August 2008 - Boost-users - lists.preview.boost.org

Re: [Boost-users] HOWTO: Building Boost for Windows 64-bit
by Gevorg Voskanyan 20 Aug '08

20 Aug '08

[snip] > According to http://tinyurl.com/6zeyhu, cflags affects both the C and C++ > compilers, while cxxflags affects only the C++ compiler; I use cxxflags as a > matter of habit, but in the case of -arch, I suppose cflags would be more > appropriate (although I'm not aware of any C code inside of Boost anyway). Interesting, this caught me by surprise since I thought that cflags was only for C, cxxflags for C++ and compileflags for both. It is documented that way at http://tinyurl.com/63rjal at least. A small testing revealed that http://tinyurl.com/6zeyhu appears to be correct under my environment. cflags affected both C and C++ and compileflags was rejected as an unknown feature. The environment was as follows: Boost.Build V2 (Milestone 12) Boost.Jam 03.1.16 gcc 4.2.2 What would be the correct description of these features? I appreciate all your input. Thanks, Gevorg

1 0

[filesystem] Changes to filesystem_error
by Arno 20 Aug '08

20 Aug '08

Hi all, I moved now from 1.31 to 1.35 and have some problem to understand what I have to change in the area of filesystem_error. I applied all the changes belongs to the iterator stuff and the class itself, but in my special error handling I use the 'who', 'error' and 'native_error' methods which I can not find in the actual model. Can you give me a clue, how I can get this information in 1.35. regards Arno

2 2

[filesystem] temp filenames?
by Hajo Kirchhoff 20 Aug '08

20 Aug '08

Hi all, I found an old (year 2003) feature request for filesystem: create temporary files, but do not see any methods in the current (1.36) version. Can anyone tell me what is the status on this? Best regards Hajo

1 0

boost.asio async_write/read_until guarantee
by Daniel Mierswa 20 Aug '08

20 Aug '08

Hi, if i have a threadpool running an io_service and a read_until is invoked before async_write. Now i wonder what would happen if the string is written to the socket, will the write handler be called before the read_handler or is it undefined in which order they will be invoked? If it's not guaranteed can anyone think of a solution to create such a guarantee in my own program? (I posted the same question on the asio mailinglist but i assume there's more activity here) Thanks in advance -- Mierswa, Daniel If you still don't like it, that's ok: that's why I'm boss. I simply know better than you do. --- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22

2 1

1.35/1.36 thread library and date_time dependency
by Ross Wightman 20 Aug '08

20 Aug '08

After looking through the new 1.35/1.36 threading library (with a lot of nice changes), I am wondering why the decision to tie it to boost::date_time was made? I love date_time as a library, but I believe it's is too large and cumbersome to be tied to a core threading library. It pulls in an excessively large include tree whenever I want to use a mutex or conditional variable. The call tree for doing simple comparisons and calculations at second to nanosecond scales is also excessive. There will always be unnecessary converting from seconds and nanoseconds, into the date_time's internal date + ticks format, and back to seconds and nanoseconds. A more fully realized 'xtime' with functions for easy conversion to/from date_time in an optional header would be a much better approach in my opinion. The C++0x draft standard looks like it uses a lean 'system_time' class which is a small subset of date_time. Regards, Ross

1 0

Bug in 1.35/1.36 thread absolute timed waits
by Ross Wightman 20 Aug '08

20 Aug '08

There is an integer arithmetic bug in get_due_time() used by conditional variables in the boost 1.35/1.36 threading library. On line 343 in thread/src/win32/thread.cpp, integer division is performed before multiplication leaving the possibility of an erroneous 0 result in the case where ticks_per_second is larger than hundred_nanoseconds_in_one_second. Moving the brackets around the multiply or removing them altogether will fix this problem. I think this may only show itself if boost::date_time is setup so that BOOST_DATE_TIME_HAS_NANOSECONDS is true (the way I need it).

1 0

total newbie with quickbook
by e r 20 Aug '08

20 Aug '08

Hi, posted in gclb.doc but no luck so far, so i figured i'd try here: --- Things I did a) sudo apt-get install xsltproc docbook-xsl docbook-xml b) updated user-config.jam file as required c) installed SciTE --- Things I'm unsure about: 1) don't understand this part in the section about SciTE: You can use the following settings (qbk = *.qbk etc) to highlight quickbook tags when editing quickbook files. where should these settings be set? SciTE?! 2) Suppose i have a .qbk file. Where do I go from here? how do i build the html file with it? probably very basic, but... Thanks!

2 2

Re: [Boost-users] The problem isn't C's integer philosophy; it's your design. (was: size_type doubts / integer library..)
by Zeljko Vrba 19 Aug '08

19 Aug '08

On Mon, Aug 18, 2008 at 07:05:10PM -0400, Daryle Walker wrote: > > implementing. This is one of those times. > Thanks for your deep analysis and your time. Unfortunately, it's based on the assumption that the task ID is opaque, which it is not.. Re-reading my original post, this could be blamed on me.. > > >Integer types in C and C++ are a mess. For example, I have made a > >library > >where a task is identified by a unique unsigned integer. The extra > >information > >about the tasks is stored in a std::vector. When a new task is > [snip, rearrange] > > You tasks IDs are conceptually opaque, why is any external code > wanting to mess with them? The external code shouldn't be doing > There are TWO task IDs: one is used by the library (which I also made), and that one _is_ opaque (at least to library clients), it _is_ typedef, and it is not even an integer (it's a pointer). Now, to every created task, I need to assign a positive[*] index (in an application which just uses the library) which is _not_ opaque: the indices are vertex IDs which are in turn used to construct a CSR representation (edge-lists) of a certain graph which is in turn operated on by an external library. (You may remember my earlier post where I proposed that the CSR class from Boost.Graph provides a documented, public way of accessing the raw CSR vectors.) I will call these "other" IDs "task indices" to avoid further confusion. I could bundle the task index in the task structure and provide a function that takes the task ID and returns the index. This is not satisfactory for several reasons: - the task library should be general-purpose and lightweight (task indices might not be needed in certain applications) - task indices may be assigned to different policies, which I do not want to hard-code into the library - I do not want to complicate interfaces with optional information (e.g. extra index parameter to task creation -- see 1st point) Since the library is written in C (well defined ABI across compilers), I can't provide overloaded interfaces. Thus, I have chosen that the task library shall be minimalistic, and that extra information about tasks, where needed, shall be layered in external containers. In this particular application, the choice of the external container (vector) is dictated by a 3rd party library. > > (The ID is a typedef and not a naked "unsigned," right?) Anyway, > does it really matter; this ID generation code is only used during > task construction, right? > The "true" task ID (provided by the "task library") is a typedef and opaque, yes. The task index (used to construct a graph) is a plain int, not even a typedef. Why? [*] Because the external library uses plain ints[**] in its interfaces. The library can be configured to use longs, but then, fortunately, a compile-time error happens when passing &v[0] of vector<int> to long*. [**] Now, the library itself does not use plain int, but a typedef. But since *all* data is passed in terms of the same typedef (vertex/edge IDs, vertex/edge weights), this implies that I cannot configure the library to use unsigned integers and expect it to work correctly (because it does more complicated operations with weights than just indexing arrays). Which leads me to conclusion that the library interface is not ideal; it should define at least index_type and weight_type instead of the single number_type. But fixing the library is out of my scope - I have to work with what I have. > > Why are you using a number to refer to a container element in the > first place? Then I realized that you can't use iterators because > they're not stable with vector's element adds or removes. Then I > Correct. > > wondered, why are you using a vector in the second place? Wouldn't a > To interface with the external library, which has a C interface and requires a bunch of int* (actually, number_type, see above) arguments, to which I pass &v[0]. Vector is the only standard container which guarantees contiguous storage. And for the kind of data processing the library is doing, it is actually good choice. > > iterators, leaving them available to implement your ID type. And you > don't seem to need random-access to various task elements. (A deque > I do indeed not need random-access to "real tasks". In the task library I have actually implemented something similar the design you have proposed here. > > (I was going to suggest using Boost's pointer-containers, but then I > realized that you really don't need containment at all.) Now you'll > pass this class around instead of an integer type. The size may be > higher though, two pointers (and an 'int' in debug-mode). > Indeed -- I do not need containment and the task library just returns opaque task IDs -- it is the task creator's responsibility to keep track of them. Now, it is almost certainly true that in this project I do not need the full integer<T> class that I proposed, and even if it were available, it'd be too much to convert the project at this point. I like to rant, but I'm also pragmatic :-) boost.integer and numeric_cast will do (thanks to you and Dave for pointing it out) I'll leave the implementation of the proposed simpler, non-ranged integer<T> template as a challenge for myself and as a material for learning about other boost libraries :-) > > No, you should rethink your design on why you need integers in the > first place. > Compact storage of graphs that enables fast algorithms (e.g. cache-friendly layout, avoids frequent memory rellocations (unlike linked lists), etc.). And before you ask why I don't use Boost.graph: because I'm working with hypergraphs. A hypergraph can be represented as an ordinary bipartite graph, but such representation is too awkward. (Actually... time to think a bit about this premise :-))

3 2

Re: [Boost-users] Multi-index container (Modifying non-unique key in the container)
by JOAQUIN M. LOPEZ MUÑOZ 19 Aug '08

19 Aug '08

________________________________ De: boost-users-bounces(a)lists.boost.org [boost-users-bounces(a)lists.boost.org] En nombre de Ramesh [rramesh1(a)gmail.com] Enviado el: martes, 12 de agosto de 2008 20:40 Para: boost-users(a)lists.boost.org Asunto: Re: [Boost-users] Multi-index container (Modifying non-unique key in the container) > > > Thanks Joaquín, > > Will try modify & the reasons I am wrapping the map class with a another one is to make sure that > the users of the class just get access to APIs and not to the container as such & and also each key > is used by a different classes to do lookups. Hence two unique keys. Hmm... I'm not referring to your myclass wrapper, but rather to the fact that you're storing DataMaps objects into the container rather than A*s directly. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

HOWTO: Building Boost for Windows 64-bit
by cowwoc 19 Aug '08

19 Aug '08

Hi, I just ran across an excellent blog post showing how to build Boost for Windows 64-bit: http://einaros.blogspot.com/2007/06/compiling-boost-for-x64.html I had two questions: 1) Can the Boost team please add this to the official documentation? 2) Will the next public release include 64-bit binaries? Thank you, Gili -- View this message in context: http://www.nabble.com/HOWTO%3A-Building-Boost-for-Windows-64-bit-tp18973954… Sent from the Boost - Users mailing list archive at Nabble.com.

4 5