- Boost - lists.preview.boost.org

RE: [boost] [thread] Build failures for CW, found the xtime problem...
by Ben Hutchings 20 Sep '04

20 Sep '04

Rene Rivera <grafik.list(a)redshift-software.com> wrote: > After some investigation I found the problem with the build failures > for xtime.cpp on CW platforms: http://tinyurl.com/5nwxo [1] > > The issue is the placement of the definition of > __STDC_CONSTANT_MACROS to bring in the *INT*_C() constant macros > from cstdint. <snip> > Moving the definition above the <boost/thread/xtime.hpp> included > fixes that problem: <snip> > OK to commit?? <snip> The fix deserves at least a comment. I would move the inclusion of cstdint.hpp along with the macro definition as well.

1 0

RE: [boost] Thread/intel-8.0-linux regressions
by Ben Hutchings 20 Sep '04

20 Sep '04

John Maddock <john(a)johnmaddock.co.uk> wrote: > > Linker output []: > > Chmod1 > > > > ../bin/boost/libs/thread/test/test_tss.test/intel-8.0-linux/debug/ > > threading-multi/test_tss > > > > > > Run output []: > > > > EXIT STATUS: 139 > > > > ? > > > > All thread tests are failing in the similar manner. This is really > > unpleasant given that the library worked on Intel 8.0/Linux in 1.31. > > There are two issues here: > > 1) Intel 8.1 currently crashes on all tests that use the unit test > suite, Intel tell me this will be fixed soon. > 2) Intel 8.0 and 8.1: Martin Wille's tests are run on a Linux version > that unsupported by Intel, as a result all tests that use > <threading>multi fail during program startup, see for example > http://tinyurl.com/4kvja. I don't see a solution to this unless we > can either get someone else to run Intel on Linux, or else persuade > Martin to use a different Linux vendor :-( Are they assuming that later 2.4 kernels have NPTL when that's really only true of certain vendors' patched kernels? If that's the problem then it might be possible to work around it by pointing LD_PRELOAD at a library that makes uname() return an earlier version. That's possibly something of a drastic solution though!

1 0

RE: [boost] Thread/intel-8.0-linux regressions
by Ben Hutchings 20 Sep '04

20 Sep '04

Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> wrote: > Does anybody have any ideas what's up with this > (http://tinyurl.com/6vecl) > > Linker output []: > Chmod1 > ../bin/boost/libs/thread/test/test_tss.test/intel-8.0-linux/debug/ > threading-multi/test_tss > > > Run output []: > > EXIT STATUS: 139 > > ? > > All thread tests are failing in the similar manner. This is really > unpleasant given that the library worked on Intel 8.0/Linux in 1.31. Bits 0-6 are set to 11, indicating termination due to segment violation. Bit 7 is set to 1, indicating that a core dump was saved. Bits 8-15 (normally the exit code) are set to 0 since the program didn't exit.

1 0

RE: [boost] Re: immutable string
by Ben Hutchings 20 Sep '04

20 Sep '04

David B. Held <dheld(a)codelogicconsulting.com> wrote: > Maxim Yegorushkin wrote: > > > I've been working on a small library - an immutable C++ string. Now > > it is in usable state and has been put in use in a couple of real > > projects. Although it needs further polishing, I would like to know > > is there any interest in such a library? > > > > Here is the link: http://conststring.sourceforge.net/ > > First, I'll say that yes, I am very interested in a library such as > this. Second, let me say that "const_string<>" and "immutable string" > don't seem like the right terms to me. The fact that you can call > operator?=() and append() on it tell me that there is little that is > "const" or "immutable" about it. It seems to me that "cow_string<>" > would be more appropriate, but perhaps others have different opinions. I once wrote a string template class similar to this, though without the clever storage policy. Unfortunately this was done in the course of my employment and I left that job without having got permission to make it public. Anyway, I think the name I settled on was atomic_string. > I suppose its not completely a COW string, since you don't support the > full set of mutating operations. <snip> It never modifies buffers once they've been initialised, so it has no use for COW. Ben.

1 0

Re: [boost] [Output Formatter]: Cascading Style Sheets (CSS) proposal
by Reece Dunn 20 Sep '04

20 Sep '04

Vladimir Prus wrote: >Hi Reece, > > > io::sequence_decorators< char > seq( "; " ); > > std::cout << '"' << seq.open( std::cout ) << "\"\n" // "[ " > > << '"' << seq.close( std::cout ) << "\"\n" // " ]" > > << '"' << seq.separator( std::cout ) << "\"\n"; // "; " > > > > where separator( std::cout ) uses the separator value specified by seq >and > > the others use the values set on the std::cout stream. > >I don't understand this phrase, could you clarify. What does it mean to >"use >the separator". "use the separator value": the io::sequence_decorators< char > (io::formatter in the review implementation of the library) type holds 3 io::decoration< char > properties -- open; close; and separator. These are used when performing input/output using my library to render a given type. In the example above, the seq object provides a custom value for the separator decoration. The io::decoration< char >::operator()( StreamType & ) method will look up the default value of the decoration using the stream passed to it unless a custom value is provided. Thus, when accessing the separator value using this method, the custom one is chosen instead of the default one. > > To change these > > defaults, you can use: > > > > std::cout << io::cdecorate( "[{ ", " }]" ); // [{ a, b, c }] > > > > The problem with this is that it changes the defaults for all the > > formatting used, thus you cannot have different defaults for sequences >and > > n-ary types. > >I don't undestand this, either. Probably I've missed something in earlier >messages. What's "n-ary" type? An n-ary type is a type that has a fixed number of elements. std::pair is a 2-ary type, boost::math::quaternion is a 4-ary type, and so on. >Do you provide the ability to use different separators for sequences, sets >and maps? In the review version of the library, there are two sets of default values: one for n-ary types formatting as "( a, b )" and one for the other sequence types, formatting as "[ a, b, c ]". In the version I am rewriting, I only have one set of default formatting: "[ a, b, c ]". >Then I don't understand why you can >set different default style for those kinds of object, and cannot >selectively >override the style Because the way I am storing it on the stream is based on decoration type (open; close; separator) and not on the format object type. > > == Dynamic Styles > > > > You can also set CSS properties within script code, e.g. > > tag.style.fontFamily = "Times New Roman"; > > > > This style behaviour is available in the new decorators, for example: > > io::wrapper_decorators< char > wrap; > > wrap.open = "<< "; > > wrap.close = " >>"; > >What does this decorator "wrap"? A wrapper_decorator is one that only has open and close decoration values. Thus, it wraps the object associated with it (via a format object): template< class OutStream, typename T > OutStream & write( OutStream & os, const T & elem ) { return( os << open << elem << close ); } The sequence_decorators< char > type extends the wrapper_decorator< char > type, adding the separator property. > > == Cascading Style Sheets > > > > HTML provides a <style> tag to specify styling across the document >without > > linking to an external file, e.g.: > > <style>h1{ color: orange; font-size: 2pc; }</style> > > > > The equivalent within my library would be to define the styling on a > > stream, e.g.: > > > > std::cout > > << css::element( "pair" ) > > [ > > ( css::attribute( "open" ) = "<< " ) > > + ( css::attribute( "close" ) = " >>" ) > > ] > > << css::element( "container" ) > > [ > > css::attribute( "separator" ) = " | " > > ] > > << io::object( ob ) // output: [ << a, 5 >> | << b, -1 >> ] > > << css::element( "pair" ) > > [ > > css::attribute( "separator" ) = " = " > > ] > > << io::object( ob ); // output: [ << a = 5 >> | << b = -1 >> ] > >I'm sorry, but I'm worried of the direction you took. For me, the primary >utility of this library is debugging output. For that, I'd be happy with a >single style, as long as it's something usable, like YAML >(http://www.yaml.org/) I haven't implemented CSS functionality yet. It is my thoughts based on the comments by Jonathan. >I agree that you might want to store and then restore STL container from a >file, and the library addresses this need to. But I don't understand why >you would want to customize the formatting style. Basically, you either >should >the data to user, or not. In first case, you need a single usable style. >For >the second case, you might need another "compact" style. I don't see the >point of customization. It is currently possible to state what style formatting an object takes using the decorate function (format in the review implementation). Thus: // review implementation: std::cout << io::formatob( vec ).format( "( ", " )" ); // ( a, b, c, d ) Here, the separator is not set and thus takes the default value (the one provided by one of the mechanisms outlined above). You might want to customize formatting for various reasons. One example is if you have: std::list< std::string > names; and want to write that out as a HTML ordered list. You can do the following: std::cout << io::formatob( names ).format( "<ol><li>", "</li></ol>", "</li><li>" ); The examples provided in the library show some advanced formatting that can be achieved. >Finally, is this library going to be used for producing generic text files? >E.g. code generation. I think no, to generate text you need some text >template system, and that's way beyond the scope of the library. It is possible to do this to a limited degree, for example, outputting 4, 7, 10, -5 27, 11, 5, 17 ... so the data can be read in by a spreadsheet, for example. It is also possible to provide a basic form of message localization, reading a std::map< std::string, std::string > in from a file. E.g.: english.loc "goodnight" = "Good night. Sweet dreams." "..." = "..." german.loc "goodnight" = "Gute nacht. Sussen Schlafen." "..." = "..." spanish.loc "goodnight" = "Buenos noches." "..." = "..." portuguese.loc "goodnight" = "Boa noite." "..." = "..." int main( ... ) { std::ifstream loc( argv[ 1 ]); std::map< std::string, std::string > messages; loc >> io::formatob( messages, io::containerfmt( io::pairfmt ( io::containerfmt().format( "\"", "\"", "" ), // currently unsupported io::containerfmt().format( "\"", "\"", "" ) // currently unsupported ).format( " = " )) ).format( "", "\n[end]", "\n" ); std::cout << "goodnight = " << messages[ "goodnight" ] << '\n'; } >So, I'm not convinced custom style gives you anything. On the other hand, >it >will cost a lot. At the very least, even documenting the above will be >considerable effort. And given that the library is header-only, this >features >will cost everyone extra compile time. Even is 'css' stuff is in separate >header, you'd need the hooks for customization. Custom styling is currently implemented and is relatively cheap. The CSS design proposal is - I agree - complex in nature and would give a performance penalty. I was discussing a possible implementation to Jonathan's proposal. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

[bind] Intel/Linux failures
by Aleksey Gurtovoy 20 Sep '04

20 Sep '04

Peter, Could you please comment on "bind_cv_test" and "bind_stateful_test" tests' failures on all Intel compilers on Linux -- http://tinyurl.com/5p3or? Should we mark these up as expected? -- Aleksey Gurtovoy MetaCommunications Engineering

2 4

RE: [boost] platform specific structures
by Puverle, Tomas (IT) 20 Sep '04

20 Sep '04

> The Win32 API provides InterlockedXXX for atomic operations > on long data types, e.g. InterlockedIncrement. I am not sure > about other OS's, but it should be possible to define an > atomic_long class: > > class atomic_long > { > private: long val; > public: > inline atomic_long & operator++() > { > InterlockedIncrement( &val ); > return( *this ); > } > // ... > }; I think this design could cause problems - presumably, there would need to be a way to test the value of the atomic_long, such as operator==(long), but that could lead to problematic code: if (++myAtomicLong == someValue) //... else //... An easy fix would be to make the return type void. Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

2 1

Thread/intel-8.0-linux regressions
by Aleksey Gurtovoy 20 Sep '04

20 Sep '04

Does anybody have any ideas what's up with this (http://tinyurl.com/6vecl) Linker output []: Chmod1 ../bin/boost/libs/thread/test/test_tss.test/intel-8.0-linux/debug/threading-multi/test_tss Run output []: EXIT STATUS: 139 ? All thread tests are failing in the similar manner. This is really unpleasant given that the library worked on Intel 8.0/Linux in 1.31. -- Aleksey Gurtovoy MetaCommunications Engineering

3 5

[thread] Build failures for CW, found the xtime problem...
by Rene Rivera 20 Sep '04

20 Sep '04

After some investigation I found the problem with the build failures for xtime.cpp on CW platforms: http://tinyurl.com/5nwxo [1] The issue is the placement of the definition of __STDC_CONSTANT_MACROS to bring in the *INT*_C() constant macros from cstdint. Currently the top of xtime.cpp looks like so: =================================================================== #include <boost/thread/detail/config.hpp> #include <boost/thread/xtime.hpp> #if defined(BOOST_HAS_FTIME) # include <windows.h> # define __STDC_CONSTANT_MACROS # include <boost/cstdint.hpp> #elif defined(BOOST_HAS_GETTIMEOFDAY) # include <sys/time.h> #elif defined(BOOST_HAS_MPTASKS) # include <DriverServices.h> # include <boost/thread/detail/force_cast.hpp> #endif =================================================================== But that placement is not early enough as the <boost/cstdint.hpp> is included from <boost/thread/xtime.hpp>. Moving the definition above the <boost/thread/xtime.hpp> included fixes that problem: =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/xtime.cpp,v retrieving revision 1.12 diff -u -r1.12 xtime.cpp --- xtime.cpp 16 Sep 2004 20:39:49 -0000 1.12 +++ xtime.cpp 17 Sep 2004 16:51:04 -0000 @@ -11,11 +11,14 @@ #include <boost/thread/detail/config.hpp> +#if defined(BOOST_HAS_FTIME) +# define __STDC_CONSTANT_MACROS +#endif + #include <boost/thread/xtime.hpp> #if defined(BOOST_HAS_FTIME) # include <windows.h> -# define __STDC_CONSTANT_MACROS # include <boost/cstdint.hpp> #elif defined(BOOST_HAS_GETTIMEOFDAY) # include <sys/time.h> =================================================================== OK to commit?? [1] http://www.meta-comm.com/engineering/boost-regression/developer/output/RSI-… -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

3 2

Re: [boost] platform specific structures
by Reece Dunn 20 Sep '04

20 Sep '04

Peter Dimov wrote: >John Maddock wrote: >>>I'm interested in getting something like "needs_lock" below into the >>>normal traits, perhaps as part of boost thread. It informs you >>>whether of not an operation on such a contiguous block needs a lock >>>to be atomic. >>> >>>For example, on ia32 32 bit aligned ops are atomic, on ia64 it is 64 >>>bit. doubles on ia32 need locking to be atomic, on ia64 they don't. >>>sizeof(void*) works generically for these two platforms as is >>>included in the code below. A default, safety first implementation >>>might return true always for needs lock, or perhaps, true for all >>>sizeof's greater than a byte. >> >>Is it the case that we could actually rely on this? I thought for >>example that on IA32 operations were only atomic and thread safe when >>the assembly is prefixed by LOCK? > >AFAIK reads and ordinary writes are atomic without LOCK. Read-modify-write >operations need LOCK. The Win32 API provides InterlockedXXX for atomic operations on long data types, e.g. InterlockedIncrement. I am not sure about other OS's, but it should be possible to define an atomic_long class: class atomic_long { private: long val; public: inline atomic_long & operator++() { InterlockedIncrement( &val ); return( *this ); } // ... }; Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1