- Boost - lists.boost.org

RE: [boost] Re: Formal review of "Output Formatters" library begi nstoday
by Rozental, Gennadiy 23 Sep '04

23 Sep '04

> Rozental, Gennadiy wrote: > >Here some more details: > > > > > 1. What is your evaluation of the design? > > > >Library trying to solve in fact trivial problem. Would it be > presented > >as trivial function > > > >Template<typename C> > >Foo( C const& c, std::string open, std::string close, > std::string sep > >); > > > >I may understand it. > > This would mean that you would duplicate code for rendreing > container types. What code? I have only one function. Could you please be more specific. In worse case I will have as many function as many different UDT I want to support. But this is also the case for you. > Also, you are missing special formatting, e.g. wrapping > open/close values > around elements, e.g.: Yeah, maybe. My solution is 5 lines. You solution is 170K of code. I could afford to repeat my function twice would I need to add extra grist. > std::cout << formatob( vec, containerfmt( > wrappedfmt().format( "<e>", > "</e>" )).format( "<l>", "</l>" )); // output: <l><e>a</e><e>b</e></l> And again, why would I do this? This code is looking for trouble. How long will it be until I mistype open/close brackets differently? > > the indentation functionality that Volodya has expressed an > interest in, and > position-based output, e.g.: > > [0] John, [1] James, [2] Marina I wonder how your interface would look like. Anyway it's not a part of submitted library. Once you presented it we may discuss it. > Also, the library should be usable on a standard stream. This > is one of the > key design aims. Can you do: > > std::cout << Foo( vec, "< ", " >", " :: " ); > > ? This requires returning an object that has << implemented. > The mechanism > for this is outlined in the standard by using *manipulators*. > Thus, you > would need that class to defer processing to the Foo function > if you want to > use your approach. *If* I want usual ostream interface, I do need to add one function object (note that it does not matter how many UDT I want to support). > > > 2. What is your evaluation of the implementation? > > > >In most part I either don't understand or don't like it. IMO simple > >task library trying to solve shouldn't require that much > code. Simple > >overloading base solution should've done the trick. > > This does not allow for flexibility to add indenting, wrapped > data, etc. I do not think it's true statement. See my other post. > > > 4. What is your evaluation of the potential usefulness of the > > > library? > > > >Now to the most important: why would I ever want to use library like > >this? > > > >We have already: > >std::ostream > >boost::format > >boost::serailization > > > >In what scenario I would use this library? > > But you can't do: > > std::vector< int > vec; > std::cout << vec; // oops! no operator << defined for vectors. Then I will write one. The thing is: I believe what library need to bring more value than just a substitution for 5 lines of custom code (especially since it not that flexible, and any step to the side causing you to write more code that custom solution would require you to). > >I most definitely wouldn't want to repeat all this formatting every > >time I need to output my vector. > > If you want [ a, b, c, d ] style output, you don't. The extra > machinery is > used to customize this. What if I want { a, b, c, d } for all my vectors? I could write global operator << using your library, using custom loop or using my trivial Foo above. I do it once. So where is the win for your solution? > Also, you can save a format object, e.g.: > // old style > containerfmt_t< char, pairfmt_t< char > > > myformat = containerfmt( pairfmt().format( " = " )).format( "<< ", " > >>" ); > > std::cout << formatob( vec, myformat ); // << ( a = 5 ), ( > b = 7 ), ... > >> > std::cout << formatob( lst, myformat ); // << ( i = 2.132 ), ( j = > 3.14159 ), ... >> > std::cin >> formatob( vec, myformat ); And now I need to write std::cout << formatob( lst, myformat ); every time I print list? No, thank you. > >If I write output operation rarely - I would use explicit loop -it's > >more flexible anyway. > > Depends what you are outputting. If the type contains nested > containers, it > can be more complex. Maybe. But compare user base for container over scalar types with multilevel containers. > >I wouldn't use this library for XML printing - why would I want to > >mention tag name twice? > > You can use a wrapper format object: > > std::cout << formatob( vec, containerfmt( > wrappedfmt().format( "<e>", > "</e>" )).format( "<l>", "</l>" )); // output: <l><e>a</e><e>b</e></l> I can. But I won't. And wouldn't recommend. See above. > Regards, > Reece Gennadiy.

2 1

RE: [boost] Proper threading (Was: Formal review of "Output Formatters"library beginstoday )
by Reece Dunn 23 Sep '04

23 Sep '04

Vladimir Prus wrote: >Rozental, Gennadiy wrote: > > Hi, > > > > I would like to start with resolution. I vote NOT to accept this > > submission. > >Gentlemen, may I ask that you use mailers which preserve correct threading? >In >particular, in review of the outfmt library, each message from Reece, >Robert >and Gennadiy is completely unrelated to the thread, missing the >"References" >and "In-reply-to" headers. > >This makes follow the thread a nightmare. Even web-based mailers nowdays >support proper threading. What do you do to break it? I am using the free version of Hotmail. I have filters to move the files from my inbox into a designated folder and hit "Reply" to reply to the messages. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 4

[Range] Current status?
by Aleksey Gurtovoy 23 Sep '04

23 Sep '04

Is the library really in a releasable state? The current test failures (http://tinyurl.com/5ch8u) don't look that good to me. In particular, half of the tests legitimately fail with CodeWarrior 8.3/9.3, and some failures on STLPort configurations (this one, for instance -- http://tinyurl.com/4lvkw) appear to be legitimate as well. -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

RE: [boost] [shared_ptr] InterlockedIncrement rocks!
by Ben Hutchings 23 Sep '04

23 Sep '04

John Torjo <john.lists(a)torjo.com> wrote: > I just took your implementation > (http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp) for shared_ptr > and use it now in win32gui (upcoming v1.4.2). Using Interlocked* for > win32 totally rocks! > > From my tests - Interlocked* are very fast. They're about twice as > slow as a raw increment (or my tests are wrong;)). > > From what I see - I think you can certainly merge them into > boost::shared_ptr. > Maybe users can select the old version or this Interlocked* version > with a certain macro - like BOOST_SHARED_PTR_USE_INTERLOCKED. > > Also, why not including windows.h directly, like this: > #define WIN32_LEAN_AND_MEAN > #include <windows.h> <snip> "Lean" is a bit of a joke. A rather smaller set of Windows definitions can be included by defining an architecture-identifying macro (e.g. _X86_ for i386) followed by: #define NOMINMAX // inhibits definition of min and max macros in // <windef.h> #include <windef.h> #undef NOMINMAX #include <stdarg.h> // <winbase.h> requires definition of va_arg #include <winbase.h> Unfortunately this still defines quite a few macros. The MSDN Library documentation of Win32 functions will tell you about any additional headers that need to be included, even though it recommends you include <windows.h> instead.

2 1

Re:[boost] Re: Standard/classic iostreams mess
by Robert Ramey 23 Sep '04

23 Sep '04

> My vote is for BOOST_CLASSIC_IOSTREAMS, BOOST_STANDARD_IOSTREAMS. How about just BOOST_NO_STANDARD_IOSTREAMS This would be inline with other boost feature macros Robert Ramey

1 0

RE: [boost] Re: Proper threading (Was: Formal review of "Output F ormatters" library beginstoday )
by Rozental, Gennadiy 22 Sep '04

22 Sep '04

> > I use Outlook. In some cases it preserve "threading". In some not. > > Do you mean Outlook Express? > > Are you receiving emails or do you use the gmane news server? > > Jeff I mean Outlook. And it's the only client allowed in our company. Gennadiy.

4 6

Standard/classic iostreams mess (was Re: Linux regressions)
by Rozental, Gennadiy 22 Sep '04

22 Sep '04

> > I added #include <ios>, which is apparently missing. > > > > Is there flag that separate standard/classic iostream (If I guess > > correctly - it should be enough) > > #ifndef BOOST_NO_STD_LOCALE > #include <ios> > #endif > > John. > (I also need to make the same fix!). It's quite obscure variable name for something very simple : switch classic/standard io. If you search through boost source you will see: 1. Check like "#if defined(__GNUC__) && (__GNUC__ < 3)" in boost/shared_ptr.hpp, boost/intrusive_ptr.hpp, boost/math/octonion.hpp boost/math/quaternion.hpp (which is incorrect BTW IMO since gcc2.95 could be using STLPort) 2. #ifndef BOOST_NO_TEMPLATE_STD_STREAM in boost/format/free_funcs.hpp and others Look also in boost/format/detail/workarounds_gcc-2.95.hpp that contains detailed workaround for gcc2.95 without STLPort 3. #if __GNUC__ < 3 in graph/detail/edge.hpp (the same comment applies as in 1.) 4. #ifdef BOOST_NO_TEMPLATED_STREAMS in boost/lambda/detail/operators.hpp and others, and Boost.Tuple headers 5. #ifdef BOOST_UBLAS_USE_BASIC_STREAM and #ifdef BOOST_UBLAS_USE_STREAM in ublas code 6. #ifndef BOOST_NO_STD_LOCALE in boost.random/detail/... several headers, Boost.Regex, 7. #if BOOST_WORKAROUND(__GNUC__, < 3) && !defined(__SGI_STL_PORT) && !defined(_STLPORT_VERSION) In Boost.Test headers 8. Boost.Variant present workarounds based on #if !defined(BOOST_NO_STD_LOCALE) in boost/detail/templated_streams.hpp 9. #ifdef BOOST_OLD_IOSTREAMS in boost/dynamic_bitset/dynamic_bitset.hpp 10. # if !defined(BOOST_IOFM_NO_BASIC_STREAM) in output formatters library currently under review. Also you could see that std::basic_ostream is used outside #ifndef BOOST_NO_STD_LOCALE and many other places where standard iostreams are used without any checks. I believe we need to put stop to this mess and force everybody use the same practice/variable(s). My vote is for BOOST_CLASSIC_IOSTREAMS, BOOST_STANDARD_IOSTREAMS. Regards, Gennadiy.

2 1

numeric_cast/MPL/vc6 conflict
by David Abrahams 22 Sep '04

22 Sep '04

The introduction of mpl::numeric_cast has caused a regression in libs\python\test\vector_indexing_suite.cpp for vc6. How shall we resolve this problem? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 4

python/detail/config.hpp bug?
by Aleksey Gurtovoy 22 Sep '04

22 Sep '04

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? -- Aleksey Gurtovoy MetaCommunications Engineering

2 5

CW 9.3: uBlas is in a very bad state
by Stefan Slapeta 22 Sep '04

22 Sep '04

The ublas tests 1-3 are currently not compiling with cw 9.3. Tests 4 and 6 compile but do not execute (they throw a GPF), which is, because of what seems to be a defect in the build system, not reflected in the results (a general cw 9.3 problem, see http://tinyurl.com/5mlxs) Shall we mark the library unusable for this compiler (as for cw 8.3)? Stefan

2 1