June 2006 - Boost - lists.boost.org

boost::copy_range
by livedevel 19 Jun '06

19 Jun '06

Hi hope this is the wright mailinglist!: ok i got a prob. I want to use the boost split_iterator now i have included <boost/algorithm/string/find_iterator.hpp> and to get the results as a string i want to use boost::copy_range. now which include do i need so i can use the copy_range of boost. i thought <boost/algorithm/iterator_range.hpp> would do it but then there is some overloading of funktion and error when compiling. can someone help me,thankx

2 1

[review] forwarded comments on pqs
by Thorsten Ottosen 19 Jun '06

19 Jun '06

Hi Andy, This is my tranlation of the brief comments of one of my Danish friends who has great experiance with unit-libraries: --------------Translation begin: I had a quick look at Andy's proposal while I was travelling. My immediate impression of the proposal based on the documentation was faily mixed. I feel that the proposal is unnecessary complex compared to the other solutions I know (including our own): Automatic Units Tracking (by Christopher Rettig) Embedded Systems Design (marts 2001) Dimension Checking of Physical Quantities (by Michael Kenniston) C/C++ Users Journal (april 2003) We have used compile-time SI types for the last 3-4 years in our products (remark: software for windmills in the world largest windmill company) and I have never missed the extra functionality Andy is offering compared to the two above proposals. In particular, I find all the machinary concerning formatted I/O unneccessary. Physical quantities is often used in connection with with process control, where the primary IO units are not cin and cout. Not even in connection with HMI have we had a need for the stream support the proposal offers. On the contrary, we often want internationalization, which fits badly with an output format controlled by compile-time types. In generel I have a hard time understanding the motivation for introducing unit-types instead of just quantity types. Personally I prefer length x = 10 * meter(); to length::m_div_s x(10) because the former is closer to the syntax from the real SI system. At some level I feel Andy's solution is a step in the wrong direction compare to the above articles. The level of abstraction feels lower even though the implementation is probably more complex. Jeg feel I'm lacking a rationale to why Andy has chosen an interface that deviates from "mainstream" solutions on a number of key areas. If the argument for unit-type alone is to support C++ standard streams directly, I can't support the proposal. Kind regards Jesper ----------------- Original message: Jeg nåede lige at kaste et kort blik Andy's forslag mens jeg stadig var under sydlige himmelstrøg (jeg skulle nok have lavet et review mens jeg holdt orlov). Mit umiddelbare indtryk af forslaget ud fra den medfølgende dokumentation var dog noget blandet. Jeg føler at forslaget er unødigt komplekst i forhold til de andre løsninger jeg kender (inklusivt vores eget forsøg). Automatic Units Tracking (by Christopher Rettig) Embedded Systems Design (marts 2001) Dimension Checking of Physical Quantities (by Michael Kenniston) C/C++ Users Journal (april 2003) Vi har brugt compile-time SI typer gennem de sidste 3-4 år i vores produkter og jeg har aldrig savnet den ekstra funktionalitet Andy tilbyder i forhold til de to ovenstående forslag. Specielt finder jeg alt maskineriet omkring formatering af input og output for unødvendig. Fysiske størrelser bruges typisk i forbindelse med process kontrol, hvor de primære IO enheder ikke er cin og cout. Hellere ikke i forbindelse med HMI har vi haft brug for den stream support som forslaget tilbyder. Tværtimod ønsker vi ofte internationalisering, hvilket harmonerer dårligt med et output format, der er styret af compile-time typer. Helt generelt har jeg svært ved at forstå motivationen for at indføre unit typer frem for blot quantity typer. Personligt fortrækker jeg "length x = 10 * meter() / second()" frem for "length::m_div_s x(10)" fordi det første minder mest om den syntaks vi kender fra det virkelig SI system. På en eller anden måde føler jeg at Andy's løsning er et skridt i den forkerte retning i forhold til de to ovenstående artikler. Abstraktionsniveauet føles lavere selvom implementationen formentlig er mere kompleks. Jeg synes jeg mangler et rationale, der beskriver hvorfor Andy vælger et interface, som afviger fra "mainstream" løsningerne på en række fundamentale områder. Hvis argumentet for at indføre unit typer alene er at kunne understøtte C++ standard streams direkte, så kan jeg ikke støtte forslaget. Med venlig hilsen Jesper

7 9

[date_time] a possible bug in date_facet.hpp
by Boris Gubenko 19 Jun '06

19 Jun '06

Three date_time library tests: testgreg_wstream, testparse_date and teststreams -- are marked as failures on Tru64 because of the bug in version v2.0 of the Rogue Wave library: The failure is caused by a standard library bug. The end-of-stream istream iterator can only be constructed when the istream iterator has been instantiated with char as the character type. This has been reported to the compiler vendor. I fixed this bug last fall, but the fix did not make the compiler release for Tru64 (it did make AlphaVMS release; the versions of RW library on iVMS and HP-UX do not have this bug). While investigating the failures of date_time library tests on HP-UX, I ran three tests above on Tru64 using library with the fix. Test testparse_date succeeded, teststreams failed to compile for some unrelated reasons and testgreg_wstream.cpp failed to compile as the following: cxx: Error: ../boost/date_time/date_facet.hpp, line 641: no operator "+" matches these operands operand types are: const char [35] + boost::date_time::parse_match_result<wchar_t>::string_type The offending line in date_facet.hpp is: throw std::ios_base::failure("Parse failed. No match found for '" + mr.cache + "'"); As far as I can tell, in the case of testgreg_wstream.cpp, mr.cache is std::wstring, and, of course, no "+" operator exists for a narrow string literal and std::wstring. Since std::ios_base::failure() expects "const std::string&", I think, you'd need to go through codecvt::out() or equivalent here, to convert wstring to string. Test testgreg_wstream also fails to compile, for exactly the same reason, on Linux with g++ 3.2.3 and Intel 9.0 and on HP-UX with aCC6 (with aCC6, there is additional compilation error "responsible" for failures of other date_time library tests on this platform). So, is it a bug in date_facet.hpp or I'm missing something? Or, may be, a bad test? Boris

2 2

Problem with the Boost Wiki?
by Gennaro Prota 19 Jun '06

19 Jun '06

Hi, I did many fixes yesterday on http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig but they seem to have been reverted. Anyone knowing what's going on? --Gennaro.

3 9

[Boost-bugs] [ boost-Feature Requests-1508654 ] provide an abstract "Task" type based on Boost.Threads
by SourceForge.net 19 Jun '06

19 Jun '06

Feature Requests item #1508654, was opened at 2006-06-19 07:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1508654&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: provide an abstract "Task" type based on Boost.Threads Initial Comment: It would be useful if the concept of an abstract task was supported in boost (i.e. as in Ada), this could be based on boost.threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=357586&aid=1508654&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1508443 ] header dependencies
by SourceForge.net 19 Jun '06

19 Jun '06

Bugs item #1508443, was opened at 2006-06-19 00:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1508443&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: header dependencies Initial Comment: Hi, could you clean up the header dependencies? E.g. a simple #include <boost/shared_ptr.hpp> int main() { return 0; } produces 400kb preprocessed output with GCC 4.1. So the usage of Boost slows down compilation considerable. Cheers, AndrÃ© Woebbeking(a)web.de ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1508443&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Boost logo
by Gennaro Prota 19 Jun '06

19 Jun '06

Out of curiosity, shouldn't a vector version of our logo be available in CVS? --Gennaro.

2 2

Re: [boost] Bug/Incompatibility: Visual C++ 2005 checkediteratorslead to major crashes
by Reece Dunn 18 Jun '06

18 Jun '06

Dave Abrahams wrote: > What interface would you consider appropriate? Right now > > bjam ... define=_SECURE_SCL=0 ... > > works with BBv2. Do you want some kind of more descriptive syntax? > > bjam checked_iterators=no > > ?? That wouldn't be appropriate if _SECURE_SCL=0 has effects other > than turning off iterator checking. IIRC, using _SECURE_SCL means that VC8 will replace some calls to strcpy, et. al. with the MS str***_s equivalents. There may be other changes as well. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

4 3

[Boost-bugs] [ boost-Bugs-1508246 ] C++ preprocessor stop at MSC V6 include
by SourceForge.net 18 Jun '06

18 Jun '06

Bugs item #1508246, was opened at 2006-06-18 12:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1508246&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: wave Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Hartmut Kaiser (hkaiser) Summary: C++ preprocessor stop at MSC V6 include Initial Comment: Hi, C++ preprocessor created from Boost::Wave tool directory stop in the middle of Microsfot C++ version 6.0 include file. All info are included in the attached files. If more info is needed, contact me kenhashimoto123(a)yahoo.com If you keep me updated, I appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1508246&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-1508243 ] C++ preprocessor stop at GCC include
by SourceForge.net 18 Jun '06

18 Jun '06

Bugs item #1508243, was opened at 2006-06-18 12:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1508243&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: wave Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Hartmut Kaiser (hkaiser) Summary: C++ preprocessor stop at GCC include Initial Comment: Hi, C++ preprocessor stop at the middle of include files. All infomation is inside the attached files. If more info is needed, contact me kenhashimoto123(a)yahoo.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1508243&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0