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

boost::xtime nsec ?
by Leon Mergen 15 Nov '04

15 Nov '04

Hello, Little quick question, it isn't documented anywhere : The struct boost::xtime has a member called 'nsec' - what amount of time is this ? Thanks in advance! Leon Mergen

3 3

Can you use a template class to store data in a vertex of a boost graph?
by Stephen torri 15 Nov '04

15 Nov '04

Has anyone used a template class to store information in a vertex of a boost graph? I am looking for a way in which to store a variety of data types in a boost graph. So that if a sample class like following: template <typename T> class Data { ... }; It can be used to data such that a Data<int> and a Data<float> can be stored at a vertex in the graph. Is what I desire possible? Stephen

3 6

Re: [Boost-users] Newbie install on Mac: where are graph
by Mike Fuller 14 Nov '04

14 Nov '04

John Maddock wrote: > The Boost Graph library consists of headers only, there are no separate > sources to compile, and hence no libraries to install for it, and Meredith Patterson wrote: > Take a look in /usr/local/include/graph -- you should see a wealth of > header files, comprising the entire BGL. It's like the STL that way. Ahhhh! Thank you very much! Mike > Mike Fuller wrote: >> Is the graph library not installed as part of the standard >> installation? Perhaps the problem is related to boost_python? Or are >> they installed somewhere else? Is there a separate procedure I'm >> missing?

1 0

Newbie install on Mac: where are graph libs?
by Mike Fuller 14 Nov '04

14 Nov '04

I 'm having trouble installing the Boost graph libraries (release: boost_1_31_0) on my Macintosh laptop. I'm running Mac OS 10.3.6 on an iBook G4 (933 MHz), with 640 MB SDRAM and a 60 GB drive. gcc version 3.3 20030304 (Apple Computer, Inc. build 1666). Darwin Kernel Version 7.6.0. I followed the installation instructions provided in the html document: Getting Started (http://www.boost.org/more/getting_started.html) The procedure seemed to work smoothly: * The build script for Boost.Jam properly recognized the "darwin" toolset. * The command: bjam "-sTOOLS=gcc" install properly initiated the install script. * boost_python was not installed, but I didn't see this as a big deal since I don't use Python. However, when the build was complete, I could not locate the Boost graph libraries. I could only find eight types of Boost libraries in /usr/local/lib. (For each type, there are eight associated libraries, as is described in Getting Started.) I do not see the graph libraries. The boost libraries found after the build in /usr/local/lib include static and dynamic forms of: libboost_date_time-1_31 libboost_filesystem-1_31 libboost_prg_exec_monitor-1_31 libboost_regex-1_31 libboost_signals-1_31 libboost_test_exec_monitor-1_31 libboost_thread-1_31 libboost_unit_test_framework-1_31 Is the graph library not installed as part of the standard installation? Perhaps the problem is related to boost_python? Or are they installed somewhere else? Is there a separate procedure I'm missing? Thanks. I am not a UNIX super-user, and I don't have a lot of experience installing libraries. Please reply to mmfuller(a)tiem.utk.edu. Mike Fuller ____________________________________ Department of Ecology & Evolutionary Biology University of Tennessee, Knoxville

5 4

compact matrix/dense vector product
by Daniel L Elliott 13 Nov '04

13 Nov '04

Hello, I am using the CVS Head version of uBLAS from approximately one month ago with gcc. I get a ton of errors when trying to multiply a dense vector by a compact matrix. This is what my code looks like: la::compressed_matrix<int>* permutationMatrix; template<class T> void Permutation::apply(la::vector<T>& dataPoint){ dataPoint = prod(*permutationMatrix,dataPoint); } What, conceptually, am I doing wrong? If asked, I will happily provide more information. For now, I am trying to keep this email to a reasonable size. Thank you, -- dan ************************** Dan Elliott 402-210-6429 (me) or 402-210-6735 (amy) dan_elliott(a)cox.net **************************

1 0

boost::function and equality operators?
by Alo Sarv 12 Nov '04

12 Nov '04

Hi I was just transforming my event engine from another callback functors lib to boost::function, and discovered that boost::function has explicitly forbidden operator== and operator!=. My question is why is this done, and what could be possible workarounds? Thanks in advance, Alo Sarv. Example: #include <boost/function.hpp> #include <cassert> void foo() {} void bar() {} int main() { // won't compile if these are used in the below asserts // boost::function<void()> f(&foo); // boost::function<void()> g(&bar); // boost::function<void()> h(&foo); // works with raw function pointers void (*f)() = &foo; void (*g)() = &bar; void (*h)() = &foo; assert(f == h); assert(f != g); assert(g != h); }

1 0

New trouble compiling with MS VC6 SP5 and MFC/AFX
by Arno Schäfer 12 Nov '04

12 Nov '04

Hi, if I want use the boost libs in an existing MFC/AFX environment I have a lot of compiling problems, what seems to depend on the order of includes. One problem what I see, but I don't understand, is the following compile error: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. cl /MDd /W3 /GR /GX /Zi /Od /I ...bunch of includes... /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_SECDLL" /D "_AFXDLL" /D "_ MBCS" /D "_GXDLL" /D "NOMINMAX" /D "_SECNOMSG" /D "_GXNOMSG" /D "_SFLNOMSG" /Fp" D:\temp\debug\GUIClient/Plato.pch" /YX"stdafx.h" /Fo"D:\temp\debug\GUIClient/" / Fd"D:\temp\debug\GUIClient/" /FD /Zm200 /GZ /c "F:\Gui+Client\src\AboutDlg.cpp" AboutDlg.cpp Note: Using precompiled header Automatically linking with RWUXThemeSD.lib ..\..\PlatoServer\Basics\boost\inc\boost/detail/iterator.hpp(326) : error C2039: 'difference_type' : is not a member of 'Iterator' ..\..\..\libs\stingray\objective_studio\include\foundation\Patterns\Iter ator.h(77) : see declaration of 'Iterator' ..\..\PlatoServer\Basics\boost\inc\boost/detail/iterator.hpp(331) : see reference to class template instantiation 'boost::detail::standard_iterator_traits<Iterator>' being compiled ... So it looks like, that the template parameter "Iterator" in "boost::detail::standard_iterator_traits<Iterator>" conflicts with the template class "stingray::foundation::Iterator" in some header files from the GUI control stuff, what was included before the boost header. How is this possible, what has the template parameter "Iterator" in the namespace "boost::detail" to do with the template class "Iterator" in the namespace "stingray::foundation" has anybody an explaination for this? regards Arno

3 3

[boost][boost-users][random] Open bugs
by Cromwell Enage 12 Nov '04

12 Nov '04

Any chance that any of the following bug reports will be resolved before the release? <http://sourceforge.net/tracker/index.php?func=detail&aid=911758&group_id=75…> <http://sourceforge.net/tracker/index.php?func=detail&aid=715667&group_id=75…> <http://sourceforge.net/tracker/index.php?func=detail&aid=652567&group_id=75…> TIA! Cromwell Enage __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

5 6

Some trouble with "regex_replace()"
by Arno Schäfer 12 Nov '04

12 Nov '04

Hi all, Using "regex_replace(string, pattern, replace_string, flags)" I got some unwished results. I can't find out what flag set I have to use, that the replacement string was taken, as it is. I think this short example should make my problem clear: Replace in a string all occurences of PATH through the actual windows directory: "Actual path: 'PATH'" with Path "D:\temp\rest" leads to the string: "Actual Path: 'D: emp est'" This show, that "\t" and "\r" was interpreted. For me that is an unexspected behaviour, because the replacement is just some string, not more. I understand that the pattern will be interpreted and controlled over the flags, but why the replacement string? Can somebody explain that behaviour and show me a way out? regards Arno

3 9

Re: [ANN] Format Lite
by Jonathan D. Turkanis 12 Nov '04

12 Nov '04

"Pavel Vozenilek" <pavel_vozenilek(a)hotmail.com> wrote in message news:cn0l08$cul$1@sea.gmane.org... > > "Jonathan Turkanis" wrote: > > > > // specialization for debug formatting > > > template<> > > > void serialize<formatted_text_oarchive>(....) { > > > > I believe this specialization is illegal. You could write > > > > void serialize(formatted_text_oarchive&ar, const unsigned) > > > > but I can't say whether this will work (I seem to remember Robert saying > > somewhere in the documentation that he was relying on the fact that > > non-templates are better matches than templates.) > > > Yes, this (nontemplated overloaded function) will work. > I just wrote down an idea in haste. > > > > I have two separate ideas for formatting libraries: > > > > - one lightweight, which I posted, for input and output of ranges and > > tuples-like objects > > - one for output only, which allows much more customization; I see this as > > an inverse of Spirit > > > > Your suggestion looks similar to the second (except that you want to > > support input), so let me sketch my idea (which has improved since I > > sketched it here last time), and then ask some questions about yours. > > > Formatted input would be optional (and maybe not practical). > > I do not understand what are avantages of the "lightweight" > approach (except compile time). The aim of Format Lite was to present a facility which would be a candidate for standardization, filling a need that was expressed at the most recent library working group meeting. Towards this end, 1. I tried to keep the implementation as small as possible 2. I introduced just one new function template -- punctuate() -- in the public interface 3. I used the same syntax currently recommended for formatting user-defined types (overloading iostreams operators >> and <<) 4. I introduced no new class templates in the public interface 5. I introduced no new concepts. (Strictly speaking, I use Single Pass Range and Extensible Range, but these could be replaced by the standard library container concepts.) If people like the interface (and so far there's not much evidence), I think Format Lite would stand a reasonable chance of making it into TR2. To get Serialization standardized would require a much bigger push, IMO, although I'd like to see it happen -- perhaps with additional language support. > Is switch between lightweight and heavyweight solution easy? Yes, since formatting with Format Lite would still be the default when a Style provides no specific formatting options for a given range or tuple-like type. In the following vector< string > v = list_of( ... ); ostream out; styled_ostream<cajun_style> cajun_out(out); cajun_out << v; If none of the Styles or Formatters associated with cajun_style knows how to format a vector, cajun_out will delegate formatting to the underlying ostream out, which will use the operator<< from Format Lite. > [snip] > > The advantages of this approach are: > > > > - an arbitrary amount of contextual information, such as indentation > > and numbering, can be stored in the styled_stream and accessed directly > > by formatters > > - arbitrary user-defined types can be formatted non-intrusively > > - flexible formatting is built-in for sequences and tuple-like types (and > > user-defined types can choose to present themselves as sequences or > > tuple-like types to take advantage of this feature.) > > > I feel having formatting descendant of boost::archive stream > could be made with the same features. Good. > > > The advantages I see: > > > - the whole infrastructure of Boost.Serialization is available and > > > ready and it handles all situations like cycles. format_lite could > concentrate on just formatting. > > > > This is a big plus, obviously. (However, I remember Robert saying her > > prefered to keep formatting and serialization separate.) > > > Formatting, as I see it would just use Serialization as > infrastructure. There would be no inpact on Serialization > from Formatting. You mean no changes to the library code -- we would just define additional archive concepts and types? > > > - formatting directives can be "inherited" from > > > "higher level of data" to "lower levels". Newly added data would > > > not need formatting of its own by default. Change on higher level > > > would propagate itself "down". > > > > Can you explain how this works? > > > I mean trick with RAII (its not really Serialization feature): > > void serialize(formatting_archive& ar, const unsigned) > { > // change currently used formatting style > formatting_setter raii(ar, "... formattng directives...") > ar & data; <<== new formatting style will be used > // destructor of raii object will revert formatting back > } I see. I think this is a characteristic of all schemes where stylistic info is stored in the stream or stream-like object. > > > - indentation for pretty printing could be handled (semi)automatically > > > by formatting archive. > > > > Would this involve modifying the archive interface? I'd like a formatter > > for a given type (or an overloaded serialize function) to be able to access > > these properties directly. > > > Yes, formatting archive could have any additional interface. I see. But no changes to existing archive types. > > > - multiple formatting styles could be provided for any class. > > > > It would be one formatting style for each archive type for which serialize > > has been specialized, correct? Would this allow styles for various types to be > > mixed freely? > > > Yes, serialize() function would be specialized. What I meant to ask can be illustrated by an example. Suppose you have two classes, Duck and Goose. Duck and Goose each have two associated formatting styles. The choice of styles should be independent, so we would need four archive types to handle the various combinations. Now my question is: would Duck need four specializations of serialize, or just two? In my system, formatting options for Duck and Goose could be added to a Style independently; I want to know if overloading serialize can handle this. > I see three ways to customize output: > > 1. Formatting archive has its own configuration how > to output data. This keeps overall style coherent > and should be enough for most uses. > > 2. Specialization of serialize() could change > formatting style. This may be used to fine > tune the output here or there. > > 3. Specializations of serialize() may generate > different outputs altogether. > > E.g. if you have archives: > class high_level_formatting_archive {...} > class all_details_formatting_archive { ... } > > you can omit details in > > void serialize(high_level_formatting_archive& ar, const unsigned); > > and use them all in > > void serialize(all_details_formatting_archive& ar, const unsigned); > > I think this (option 3) is not possible now with format_lite. In fact, it only supports 1. That's part of what makes it 'lite'. If a class already provides standard library inserters and extractors (corresponding to 2, above), those provided by Format Lite will not be called. I have a couple of questions: 1. Is your idea flexible enough to allow pairs (a,b) to be formatted with the elements in reverse order? 2. If a type defines a member function serialize, can it be bypassed altogether in favor of an end-user supplied formatting style? > > My inclination is to > > keep formatting separate from serialization, though, because they have different > > aims. If you believe they can be integrated, without making serialization harder > > to learn or sacrifying flexibility of formatting options, it should definitely be > > considered. > I see Serialization as just vehicle, ready and handy and almost > invisible to Formatting users. > Simple data structures are very easy with Serialization and should > be as easy as with format_lite now. > If user tries to format tricky structures (e.g. pImpl) he would need > to dig into Serialization docs but at least there will be chance to > make the whole thing work. The Serialization goes to great lengths > to work under any situation and configuration. This sounds quite reasonable, provided it is sufficiently flexible. I wonder how much of the Serialization infrastructure is really needed, though. Detecting cycles is defintely not something I want to reimplement; OTOH, I'm not sure it's needed for pretty-printing. I haven't looked at the Serialization implementation, but I did read the Java serialization specification several years ago. IIRC, when an object was encountered for the second time, some sort of placeholder would be inserted in the stream referencing the already serialized data. I assume the Serialization library does something like this. Would this really be desirable for human-readable output? Perhaps the formatting library should concern itself only with cycle-free data structures. > /Pavel Jonathan

1 0