- Boost-users - lists.boost.org

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

[Boost.Regex] regex_basic subpatterns iterators
by Mickael Wolff 19 Aug '08

19 Aug '08

Hi, I would like know if they are some method I missed to point parenthesis expression in basic_regex. For example, I would like to write something like this : === 8< === std::pair<std::string::iterator, std::string::iterator> mark ; boost::regex re("(\w+)") ; if(re.mark_count() == 2) { first_mark.first = re.marks[1].begin() ; first_mark.second = re.marks[1].end() ; } === 8< === My current solution is to do a regex on the regex, but I guess boost::regex did the work yet. Greetings, Mickaël. PS.: please apologize my english, I'm French. -- Mickaël Wolff aka Lupus Michaelis Racine <http://lupusmic.org> Blog <http://blog.lupusmic.org>

1 0

Boost.Regex 1.36.0 fails to compile with VS2005 compiler
by Peter Klotz 19 Aug '08

19 Aug '08

Boost.Regex 1.36.0 does not compile due to a compiler specific workaround in files libs\regex\src\usinstances.cpp and libs\regex\src\wc_regex_traits.cpp. The attached patch fixes the problem but will (likely) break linking for others. I use bjam 3.1.13 and obtain this error message: ...patience... ...found 1793 targets... ...updating 618 targets... compile-c-c++ bin.v2\libs\regex\build\msvc-8.0\release\threading-multi\wc_regex_traits.obj wc_regex_traits.cpp libs\regex\src\..\src\wc_regex_traits.cpp(53) : error C2375: 'std::allocator<_Ty>::allocator' : redefinition; different linkage with [ _Ty=unsigned short ] xmemory(120) : see declaration of 'std::allocator<_Ty>::allocator' with [ _Ty=unsigned short ] libs\regex\src\..\src\wc_regex_traits.cpp(53) : error C3190: 'std::allocator<_Ty>::allocator(void) throw()' with the pro vided template arguments is not the explicit instantiation of any member function of 'std::allocator<_Ty>' with [ _Ty=unsigned short ] cl /Zm800 -nologo @"bin.v2\libs\regex\build\msvc-8.0\release\threading-multi\wc_regex_traits.obj.rsp" ...failed compile-c-c++ bin.v2\libs\regex\build\msvc-8.0\release\threading-multi\wc_regex_traits.obj... ...failed updating 1 target... My bjam command line: bjam -q -sNO_COMPRESSION=1 --build-type=complete --without-graph --without-math --without-mpi --without-python --without-serialization --without-signals --without-wave --toolset=msvc-8.0 Regards, Peter. Peter Klotz Software Engineer Phone: +43 (0) 50 8648-4100 Fax: +43 (0) 50 8648-4111 E-Mail: peter.klotz(a)ith-icoserve.com ---------------------------------------------------------------- ITH icoserve technology for healthcare GmbH A-6020 Innsbruck, Innrain 98 www.ith-icoserve.com Rechtsform: Gesellschaft mit beschränkter Haftung Firmensitz: 6020 Innsbruck, Innrain 98 Firmenbuchnummer: FN 174117f Firmenbuchgericht: Innsbruck DVR: 0983039

4 9

compatibility between g++ and msvc8
by Guo Xu 19 Aug '08

19 Aug '08

#include <iostream> #include <vector> #include <boost/functional.hpp> #include <boost/algorithm/string.hpp> using namespace std; using namespace boost; int main() { vector<string> strs; strs.push_back( "Beijing" ); strs.push_back( "Olympic" ); strs.push_back( "Game" ); vector<string>::iterator it = std::find_if( strs.begin(), strs.end(), boost::bind2nd( boost::contains<string, string> , "mp" ) ); return 0; } why this part of programe can be compiled on the mscv8, but can not be compled on the g++? the error prompt is: stringalgo.cpp: In function 'int main()': stringalgo.cpp:29: error: no matching function for call to 'bind2nd(<unresolved overloaded function type>, std::string&)'

2 1

Extended Subgraph
by Alexander Löhr 19 Aug '08

19 Aug '08

Hi! Is there an extended version of subgraph.hpp available somewhere, which is able to remove subgraphs. I need something like: subgraph p(5) subgraph c = p.create_subgraph(); v1 = add_vertex(c); v2 = add_vertex(p); add_edge(v1, v2); p.remove_subgraph(c); In this case c should be removed from p and edge (v1,v2) and v1 should be destroyed. Thanks, Alex

1 0

Programming practices for asynchronous operations (asio, etc)
by dizzy 19 Aug '08

19 Aug '08

Hello I have recently started to rework a network server project that uses a thread per connection (with blocking/synchronous network I/O) handling model to using asio and an asynchronous operation model (where the number of threads should depend on hardware resources and be decoupled of software design constraints). The problem I have with this is that it makes one write too much boiler plate code for all those "completion handlers". Take very this simple example of code that is using the one thread per connection synchronous I/O model: // synchronously resolves, connects, throws on error connection con("1.2.3.4"); { // application "packet", usually known as "record" // uses "con" and starts an application packet with a given type packet pack(con, PacketTypeRequest); // serializes portably given data and synchronously sends the data // throws on error pack << uint32(10) << std::string("/home/user") << uint8(3); } // calls packet::~packet() which signals in the "con" stream end of packet Now to transform this very simple (I repeat, this is a very simple example, a lot more complex examples write "packets" of dozens of fields of which the last one may have "infinte" length meaning you cannot know the size of it to put it in the stream and you just have to send it as much as you can and then signal the end of the "packet") into an asynchronous version one would need: connection con; // breaks invariants of "con" being always connected // should asynchronously resolve and connect con.async_connect("1.2.3.4", handle_connect); // break code flow here // handle_connect() // breaks invariant of allowing "serialization" only after packet type // has been sent over the network packet pack(con); pack.async_serialize(uint32(10), handle_serialize1); // return to caller // handle_serialize1 pack.async_serialize(std::string("/home/user"), handle_serialize2); // return to caller // handle_serialize2 pack.async_serialize(uint8(3)), handle_serialize3); // return to caller // handle_serialize3 // breaks RAIIness of original packet which automatically signaled // "end" from the dtor of it pack.async_end, handle_endpacket); // return to caller And imagine that the original code was just a small function a big class, so now each such small function transforms into dozens of smaller functions, the code explosion is huge. I am curious to the code practices that some of you employ to solve these issues (to still have compile time checked code as much as possible by strong invariants and RAII idioms and not have to write millions of small functions). Some of the things I have thought of that seem to solve these issues: - instead of packets being adhoc serialized have structures encapsulating the network packets and have serialization code moved into them and let them deal with all the small functions (they could use some buffer to cache serialization of the fixed fields and async_write that buffer contents in a single operation); this however means an additional copy of the data vs how the code was before and it just moves the problem, instead of having many small functions in the high level code you have them in the lower level packet structures serialiation code (thu the output buffer being can reduce some of them) - using template expressions or whatever do some kind of "lazy evaluation"; basically still use syntax similar to the synchronous solution like: pack << uint32(10) << std::string("/home/user") << uint8(3); but this code instead of doing network I/O would enqueue the serialization actions needed have all those completion handlers internally and completely abstract to the user all those details; the user just does a pack.async_write(user_handler) and "user_handler" will be called after all the serializations have been asynchronously written - if this weren't C++ but C then we could use setjmp/longjmp to transparently (to the user) simulate synchronous operation while asynchronous operation is done behind the scenes; the user writes code such as: pack << uint32(10) << std::string("/home/user") << uint8(3); but what it does is on each op<< (each asynchronous serialization) the code does an async_write() with an internal handler, saves the context (setjmp) then longjmp()s to the previously saved context in the main event loop; when the async_write completes the handler does setjmp to restore the original user context and continue with the next op<< and so on; this however does not work in C++ because the jumped code path with longjmp may have exceptions being thrown/catched and as the standard says that's UB not to mention form what I could gather on the Internet some C++ compilers call dtors of auto objects when you longjmp "back" thus not leaving the original context untouched (which is what I need) -- Mihai RUSU "Linux is obsolete" -- AST

3 3

[Boost.Interprocess] int key and flat_multimap_index
by Robert Kubrick 19 Aug '08

19 Aug '08

A couple of beginner questions on basic_managed_heap_memory: 1) I want to access elements in the contiguous memory segment by using an int key, rather than a char string. Can I declare something like this: typedef basic_managed_heap_memory < int, /* my key is an integer */ rbtree_best_fit<null_mutex_family>, flat_map_index > managed_heap_memory; I need to lookup objects using an external integer ID but the ID can have any value (ie, does not match the 0-N array element order of my memory segment). 2) If I want to insert multiple objects with the same char* name (ala multimap) can I create a flat_multimap_index?

2 3

[[Boost]][[Interprocess]] Defining a common wrapper for all IPC-Types
by Daniel Clemens 19 Aug '08

19 Aug '08

Hi erveryone, The goal: I am currently on a coding project, that offers a common interface for all IPC-Types: - shared memory - message-queues - ... by meaning interface, I don't want the user to be bothered with the details of Inter process communication. I just want him to say what type he wants to use and then just use an instance of my class IPC and the read() or write() method, to simply use the according interprocess type provided by boost. this should be programmed for SLES 10 (=Suse Linux). I would like to have something like: class IPC{ //Attributes + string sName + int iStatus + iMaxMsgSize + iMaxMessages + enum ipcType //Methods + IPC();//constructor + string read(); + void write(string); }//end class The explanation of the code: Depending on the type I suggest on creation of an IPC-Instance the rest should be handled by the class - e.g. instanciating a boost::interprocess::message_queue mq( foo ); Now the question I have is, if the containers offer some sort of way of providing this functionality. Maybe I am currently just too blind to find the answer to the problem. Approaches so far (and failures): My current approach is, that depending on the type-setting, the read() and write() methods use the boost.Interprocess libraries to ither build a message_queue or a shared memory. The example provided for message_queues works fine. I then tried to assign an instance of boost::interprocess:message_queue to an attribute of an instance of IPC. But it says I am assigning a temporary to a pointer. I then tried assigning not an address, but to return a boost::interprocess:message_queue instance from the read()-method and assign it to an attribute. It seems it called the copy-constructor and didn't like that approach ither. Aproach suggestion and questions: Now I thought that the solution to getting a re-usable message_queue working is to use the pointers provided with the boost::interprocess to assign an instance of the established message-queue to the IPC-instance-Attribute. Is this the right way of doing this? And if so, could you give me an example? Thank you! -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

2 1