- Boost - lists.boost.org

Re:[boost] Re: Re:[serialization] one MSVC build fix
by Robert Ramey 23 Sep '04

23 Sep '04

Tony Juricic wrote >I know. But, in the end, to do the real work, debugging and testing in any >particular environment, we have to stick with the particular compiler and >particular platform. No cross-platform build tool is going to help in that >case. That's why I consider generic build tool fantasies a major waste of >developer's time and resources. Sorry, got to disagree here. I use VC 7.1 compiler and IDE as my main compiler and environment. In general it very good, integrated help, simple editor, powerful debugger. On the other hand it hangs up from time to time and this drives me crazy - still I've tried a lot different ones and I like this the best. However, sticking to one compiler is a big mistake if you want to make good code. All compilers have problems. One problem is that all pass some invalid code as valid. It fools you into thinking there's no bugs or worse, hides your bugs so you can't find them. Also C++ is so complex now (too complex?) that I can't understand the error message half the time. Then when I do I'm left wondering if it's a compiler bug or is it that I don't understand what's going on. So, I've added a number of compilers to my external tools list so I can compile (can't link) write from the IDE with borland, Commeau, G++, and (until it expired) Metrowerks. So when I think some thing is correct or I know its not but can't figure out why, applying several compilers to the code module is indispensable. In this day in age, it's the only practical way to make correct portable C++ code. Honestly, I think that C++ is just to complex to make a correct compiler for. (I know someone is going to take exception to that - Sorry in advance - no offense intended). So here we are. For final build and test I use bjam. Bjam also drives me crazy. I've managed to work with it and I believe that it (or something equivalent) is indispensable for a truly portable project and I haven't found anything better - but still it drives crazy. I understand efforts to improve it are in the works and I look forward to seeing them. However, the main problem is that it seems to take a huge amount of time to understand and learn how to use. I don't know if that's going to change. Robert Ramey

5 5

What happened to the Command Line & Config library by Vladimir Prus?
by Hendrik Schober 23 Sep '04

23 Sep '04

Hi, I found this http://article.gmane.org/gmane.comp.lib.boost.announce/24 but couldn't find the lib at http://www.boost.org/libs/libraries.htm What happened to it? TIA, Schobi -- SpamTrap(a)gmx.de is never read I'm Schobi at suespammers dot org "Sometimes compilers are so much more reasonable than people." Scott Meyers

2 2

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