- Boost - lists.preview.boost.org

OutFmt library implementation questions
by Rozental, Gennadiy 20 Sep '04

20 Sep '04

Hi, Here some implementation questions I've got: 1. Why does the library brake const correctness. FWIV I could write: const vector<int>& v = ...; std::cin >> io::formatob( v ); and it would compile without questions. 2. Why doesn't insert_iterator is implemented using iterator_facade? 3. Why do you need 2 different functions containerfmtex and containerfmt? 4. How does this all machinery will work with wchar_t? 5. Why do you need static_cast< const base_type * > to cast to the base type in container.hpp? 6. Why the same entity you sometime call format_type and sometime DelimeterType? 7. What deducer is supposed to deduce? I couldn't get through all the details, but couldn't the same be achieved using partial specialization and/or partial ordering. Cause it look way too complex and unnecessary. 8. Why class formatter, formatter_t is defined in namespace io, while it reside among details headers? 9. What is RT2 stands for? 10. detail/formatter.hpp refer to openclose_formatter_t, but does not include no headers. 11. Need for all this hierarchies: Formatter->formater_t->openclose_formatter_t openclose_formatter->openclose_formatter_t are completely unclear. Explanations presented in docs does not help since format methods seems to be returning *this anyway. Why couldn't we just use something trivial like template<char Ch> struct formatter { std::basic_string<Ch> m_open; std::basic_string<Ch> m_close; std::basic_string<Ch> m_sep; }; Is beyond me. If any member is empty it means it missing. 12. select and switch templates seems useful. Why doesn't MPL provide these? 13. Doesn't MPL provide eq_int, lt_int? 13. struct selector needs to be PP generated 14. list_object -> formatter_t inheritance look wrong. Where is IS A relationship? 15. You couldn't do this: typename InputStream::char_type ch = '\0'; I think It all for now. Please comment. Gennadiy.

1 0

OutFrmt lib design questions
by Rozental, Gennadiy 20 Sep '04

20 Sep '04

Hi, Here some question I've got while reading submitted library. 1. What is an advantage if using this library for scalar types (vs. defining operator<<) 2. If primary target is collection formatting wouldn't it be better to name library "collection formats something"? 3. If there is a way to assign format to collection/type combination permanently (through global operator <<), why would I want to do it in every instance of output operation? 4. What is an advantage of using this library to assign format to collection/type combination permanently vs. explicit implementation (using FOREACH construct for example) 5. Why do we need boost::io::range? Couldn't we use boost::range instead? 6. In a formatter usage how would I guess what is what? boost::io::formatter< char * > fmt( "\ ", " /", " | " ); boost::io::formatob( vec, boost::io::containerfmt()).format( fmt ); 7. Who come format calls order dependent? boost::io::formatob( vec, boost::io::containerfmt()).format( fmt ).format( " : " ); 8. If I got vector<vector<int> >. How do I supply separators for both internal and external vectors? 9. Let say I print vector<char>. Is there way to print it like this: { 'a', 'b', '0x01', ' ' } That's enough for now. Please comment. Gennadiy.

1 0

[boost.range] late addition, votes needed
by Thorsten Ottosen 20 Sep '04

20 Sep '04

Dear All, In the pre-redmond mailing Walter Brown discusses the possibility of adding these members to standard container classes: const_iterator cbegin(); const_iterator cend(); const_reverse_iterator crbegin(); const_reverse_iterator crbegin(); The motiviation is that we want to be able to say explicitly "give me a const iterator" without doing ugly casts. IMO a sound idea. Given the framework in boost.range these would be absolutely *trivial* to add. 1st vote: for or against adding these? 2nd vote: which naming scheme to use: a: cbegin(), cr_begin() b: const_begin(); const_rbegin(); The motivation for chosing the latter could be that "cr" contracttions become harder to read. Let me know what ya think. best regards Thorsten

14 39

Re:[boost] Re: python/detail/config.hpp bug?
by Robert Ramey 20 Sep '04

20 Sep '04

"Aleksey Gurtovoy" <agurtovoy(a)meta-comm.com> writes: >> Boost.Python fails to build with MSVC 6.x/STLPort (see >> http://tinyurl.com/4nl7l) due to the following (incorrect) >> configuration logic in >> "boost/python/detail/config.hpp": >> >> // The STLport puts all of the standard 'C' library names in std (as >> far as the // user is concerned), but without it you need a fix if >> you're using MSVC or // Intel C++ # if >> defined(BOOST_MSVC_STD_ITERATOR) # define BOOST_CSTD_ # else # >> define BOOST_CSTD_ std # endif >> >> The issue, as explained in "boost/config/stdlib/stlport.hpp" is that: >> >> // STLport does a good job of importing names into namespace std::, // >> but doesn't always get them all, define BOOST_NO_STDC_NAMESPACE, since >> our // workaround does not conflict with STLports: >> >> Is there a reason why we are not using BOOST_NO_STDC_NAMESPACE here? I had similar problems in my setup. I fixed them by close looking at the release notes for stlport 4.5.3 and found that stlport 4.5.3 puts an altered copy of stlport directory into the msvc include directory. I set environmental variables export STLPORT_PATH="c:/" export STLPORT_VERSION=4.5.3 export STLPORT_INCLUDE_DIRECTORY="c:/program files/Microsoft Visual Studio/vc98/include/stlport" This permitted compile link and test with msvc-stlport toolset. I believe it would also help intel-7.1-v6-stlport-4.5.3 toolset builds. Robert Ramey

1 0

RE: [boost] Re: Re:Re: [static_assert] Regression with gcc 3.4.2?
by Ben Hutchings 20 Sep '04

20 Sep '04

Jonathan Turkanis <technews(a)kangaroologic.com> wrote: > "Robert Ramey" <ramey(a)rrsd.com> wrote in message > news:20040919040443.D18A931132@acme.west.net... > > "David B. Held" <dheld(a)codelogicconsulting.com> wrote in message > > news:cihmvu$3ik$1@sea.gmane.org... > > > #include <boost/static_assert.hpp> > > > > > > template <typename T> > > > struct foo > > > { > > > void bar(void) > > > { > > > BOOST_STATIC_ASSERT(false); > > > } > > > }; > > > > I use > > > > .... > > BOOST_STATIC_ASSERT(sizeof(T) == 0); > > The expression 'always_false<T>::value' can't be evaluated until > the point of instantiation, since always_false could be > specialized for T. OTOH, the compiler can tell immediately that > 'sizeof(T) == 0' is false, so might it not replace > 'sizeof(T) == 0' with 'false', and then issue the same error as > in the quoted case? sizeof(T) isn't always false, because for some types T it isn't even well-formed. As a value-dependent expression I think it must not be evaluated until the template is instantiated.

2 1

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

20 Sep '04

Vladimir Prus wrote: Hi Volodya, > >>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 ]". > >That's bad, I'd rather prefer different formatting styles for sets and >vectors. Hmm. Note that this is for the default values, i.e. you can set the formatting you want when constructing a format object construct. > >>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. > >Why? Is there any specific difficulty with using format object type (or >"kind") as key? The current implementation in the post-review version that I am developing uses a simplified approach in dealing with pword -- it assumes that the type is const CharT * and is not allocated (i.e. is a string literal). It would be possible to do based on format object type, but that would increase the complexity of the code. > > 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 ); > > } > >Is this a method of 'wrapper_decorators'? It is a method of the format object used when writing to a stream. > >>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). > >Ok, aside from naming, the above is fine. The naming issue has been discussed earlier in the review. In the post-review version, the above example is: std::cout << io::object( vec ).decorate( "( ", " )" ); // ( a, b, c, d ) (I know the review is still in process, but I have been working to address the issues in the review version of my library.) > > 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>" ); > >Is this a practical use case? Reviewers have requested the ability to generate XML/HTML. This is to show that it is possible to do that within the existing framework. >Well, you can print 'names' this way, but if >you want to print 'Person', you'll need much more powerfull tools. Anyway, >if the overhead is small, no problem. If Person supports << on a stream, you can do: std::list< Person > people; std::cout << io::formatob( people ).format( "<ol><li>", "</li></ol>", "</li><li>" ); > > 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.: > > [snip] >That's more like an artificial example, I think. For practical uses, the >message catalog would have to contain comments, at least, and that again >requires much more complex parser. This is true. Although, you could write a custom state object to skip comments and then bind that to the formatter. >I'll try to write a complete review soon, >so stay tuned ;-) :) (What frequency are you broadcasting at ;)) Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

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