- Boost - lists.boost.org

Re: [boost] basic_string interface generator
by Igor Kholodov 18 May '04

18 May '04

>Reece Dunn wrote: >> >> Is there any interest in the ability to generate a basic_string compliant >> interface from a base set of functions in a similar way that the iterator >> adaptors work? > >While I don't have a present need for it, there has been >discussion of various types of strings including ropes and small >string optimized on the list. A utility such as you've proposed >would make writing them easier. > This would also benefit libraries designed specifically for STL strings. See, for example, Common Text Transformation Library, http://cttl.sourceforge.net/. Is there is a need for grammar-based STL string transformations? Igor Kholodov http://cttl.sourceforge.net/

1 0

RE: [boost] basic_string interface generator
by Max Khesin 18 May '04

18 May '04

Just curious: what do you think of Andrei's work on policy-based strings: http://www.cuj.com/documents/s=7994/cujcexp1906alexandr/alexandr.htm http://moderncppdesign.com/code/flex_string.zip - does it do what you want (or leave flexibility to do what you want) - if so why not just use it - if not what doesn't it do m > -----Original Message----- > From: Reece Dunn [mailto:msclrhd@hotmail.com] > Sent: Tuesday, May 18, 2004 2:30 PM > To: boost(a)lists.boost.org > Subject: [boost] basic_string interface generator > > > Is there any interest in the ability to generate a > basic_string compliant > interface from a base set of functions in a similar way that > the iterator > adaptors work? > > I am currently developing a fixed-capacity string class that > complies to the > basic_string interface and have at least 3 variants: > > boost::fixed_string< n, CharT = char, StringPolicy = > std::char_traits< > char > > > boost::char_string > boost::wchar_string > > where fixed_string derives from boost::char_string or > boost::wchar_string > depending on CharT. It may be useful to implement these like this: > > struct char_string: boost::basic_string_impl< char_string > > { > // ... > }; > > void myfn( char_string & s ) > { > // manipulate s like a basic_string or apply C-string functions > } > > So the question is this: are other people interested in this > concept, or is > it better placed as an implementation detail? > > Regards, > Reece > > _________________________________________________________________ > Want to block unwanted pop-ups? Download the free MSN Toolbar now! > http://toolbar.msn.co.uk/ > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

"+" sign in filesystems
by Florian Becker 18 May '04

18 May '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi list, have wondered, why the "+" sign won t work in filesystem lib. So i have added it. I need this, for monotone system control use. Maybe you can add this to the tree for later.. boost_1_31_0/libs/filesystem/src/operations_posix_windows.cpp line 119 only add a "+" sign. I have build patched packages for this. ftp://ftp.yplus.org/monotools/ Cheers, - -- - -------------------------------------------------------- Florian Becker - -------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAqlgGtdIR2yXuDwERAoOPAKDOT1iMwdJVsAVJan68c/UK5RzSaACeKHcu eotMtSZd3cAgsXH+QsGoXSs= =xl4O -----END PGP SIGNATURE-----

2 1

basic_string interface generator
by Reece Dunn 18 May '04

18 May '04

Is there any interest in the ability to generate a basic_string compliant interface from a base set of functions in a similar way that the iterator adaptors work? I am currently developing a fixed-capacity string class that complies to the basic_string interface and have at least 3 variants: boost::fixed_string< n, CharT = char, StringPolicy = std::char_traits< char > > boost::char_string boost::wchar_string where fixed_string derives from boost::char_string or boost::wchar_string depending on CharT. It may be useful to implement these like this: struct char_string: boost::basic_string_impl< char_string > { // ... }; void myfn( char_string & s ) { // manipulate s like a basic_string or apply C-string functions } So the question is this: are other people interested in this concept, or is it better placed as an implementation detail? Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

[preprocessor] math macros.
by Cromwell Enage 18 May '04

18 May '04

As promised, I have some results. My work can be found this time at <http://groups.yahoo.com/group/boost/files/pp_math.zip>. The example program is simpler and has been confirmed to work correctly when compiled under MinGW 3.2 and MSVC 7.1 (using the VC 2003 Toolkit). Later on I'll test it using MSVC 6. The usual caveats that apply to other macros (no incrementing, decrementing, or runtime functions with side effects can be called from within parameters) apply here. Once again, comments welcome! Cromwell Enage __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/

1 1

Filesystem iterator suggestion
by Martin 18 May '04

18 May '04

I have used the filesystem library for some time now and noticed that there is no portable way of iterating over files in a directory that matches a pattern. In my applications I often need to find all files in a directory that matches "*.txt" or "input.*". I think it would be a good idea to add another constructor to the directory_iterator that support some primitive wilcards. The support could be limited to "*" at the end or followed by a "." (e.g. "*", "a*.*", "*.txt", "a.*") for (path::directory_iterator itr = directory_iterator(path, "*.txt"); itr != directory_iterator(); ++itr) ... I assume this limited wildcard support could easily be ported to most operating systems. ------------------- Another small improvement that would make the directory_iterator easier to use is to somehow allow it to only list directories or files. In the current implementation you need to create a temporary to use an algorithm on all files in a directory (or use some lambda if construct). std::vector<path> tmp; std::remove_copy_if(directory_iterator(dir), directory_iterator(), back_inserter(tmp), std::ptr_fun(is_directory)) std::for_each(tmp.begin(), tmp.end(), func); instead of just std::for_each(directory_iterator(dir, files_only), directory_iterator(), func);

4 4

Fwd: Bug#247643: boost::format completely broken on ia64
by Domenico Andreoli 18 May '04

18 May '04

hi all, i received this bug report for the Boost debian package version 1.31.0-4, the full log is available at [0]. it is reproducible on ia64 architecture. anybody with in depth knowledge of the format library is able to give me a hint about where the problem might be? i cannot provide any access to the debian project's ia64 box but i'm available to perform any test i'm asked to further delve into the bug. best regards domenico [0] http://bugs.debian.org/247643 ----- Forwarded message from Martin Pool <mbp(a)samba.org> ----- Date: Thu, 06 May 2004 17:03:38 +1000 From: Martin Pool <mbp(a)samba.org> To: submit(a)bugs.debian.org Reply-To: Martin Pool <mbp(a)samba.org>, 247643(a)bugs.debian.org Cc: mbp(a)sourcefrog.net Subject: Bug#247643: boost::format completely broken on ia64 Package: libboost-dev Version: 1.31.0-4 Severity: important X-Debbugs-CC: debian-ia64(a)lists.debian.org Here is a test case, extracted from the examples in http://www.boost.org/libs/format/example/sample_formats.cpp: --------------- #include <iostream> #include <boost/format.hpp> using namespace boost; using namespace std; int main(void) { cout << format("Hello %d!\n") % 69; return 0; } ----------------- I build this with g++ -o boost-format-bug boost-format-bug.cpp On i386 it works fine. On ia64, with g++ 4:3.3.3-2 and libstdc++ 1:3.3.3-6, it crashes. In fact I cannot find any use of the format class other than passing a constant string which does not crash. gdb shows Catchpoint 1 (exception thrown) 0x2000000000149981 in __cxa_throw () from /usr/lib/libstdc++.so.5 (gdb) bt #0 0x2000000000149981 in __cxa_throw () from /usr/lib/libstdc++.so.5 #1 0x20000000000acc50 in std::__throw_length_error () from /usr/lib/libstdc++.so.5 #2 0x200000000012fc30 in std::string::_M_replace_safe<char const*> () from /usr/lib/libstdc++.so.5 #3 0x200000000012ba40 in std::string::append () from /usr/lib/libstdc++.so.5 #4 0x400000000000db60 in boost::io::detail::(anonymous namespace)::mk_str<char, std::char_traits<char> > () #5 0x400000000000c900 in boost::io::detail::(anonymous namespace)::put<char, std::char_traits<char>, int const&> () #6 0x400000000000ac60 in boost::io::detail::distribute<char, std::char_traits<char>, int const&> () #7 0x40000000000076c0 in boost::io::detail::feed<char, std::char_traits<char>, int const&> () #8 0x4000000000003fe0 in boost::basic_format<char, std::char_traits<char> >::operator%<int> () #9 0x4000000000003d00 in main () Regards Martin ----- End forwarded message ----- -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

2 1

RE: [boost] Re: static sized strings
by Reece Dunn 18 May '04

18 May '04

Martin wrote: >Do you plan to add more of the basic_string members? I intend to (hopefully) have as close to the basic_string interface as I can get to help interoperability. I have been working on getting core functionality up and running initially, but I am working on adding more basic_string members. >Many of the string algorithms (e.g. trim & replace) seem to require insert >& >erase? I haven't included these yet, but I shall work to get them implemented as soon as I can. I am also thinking about how to implement substrings: either create a std::basic_string or have an internal/external type that operates on const char * instead of const char[ n ], etc. Then there's the issue of compilers/standard libraries that don't have the correct std::reverse_iterator, std::iterator_traits, std::basic_[i/o]stream implementations (sigh). Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

RE: [boost] Is there interest in a decimal floating-point class?
by Michiel Salters 18 May '04

18 May '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Jeff Garland > Sent: maandag 17 mei 2004 14:34 > To: boost(a)lists.boost.org > Subject: Re: [boost] Is there interest in a decimal floating-point > class? > > > On Sun, 16 May 2004 19:26:51 +0200, Richard Kaiser wrote > > I want to ask the boost community if there is interest in a decimal > > floating-point class implementing one or more of the decimal > > floating-point types that are intended to become part of a future C > > and C++ standard. > > At this moment I don't need this, but I've need something > like this in the past and suspect I will again. So I'd like to > see it. Only question is will the compiler vendors get > there first if it's already clear this is going in the standard? It's just a proposal, and I doubt it will become part of the standard. P.J.Plauger wasn't very positive, and NNI (Dutch) voted against it. I'm not aware of other formal votes, though. One problem I saw was that the proposal implemented its types as core language, with semantics that I felt were hard if not impossible to achieve for UDTs (w.r.t. conversion sequences) Regards, -- Michiel Salters Consultant Software Engineering LogicaCMG RTSE1, the Netherlands Michiel.Salters(a)logicacmg.com This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

RE: [boost] Re: [iterator facade] Why is dereference const?
by Max Khesin 18 May '04

18 May '04

> "Neal D. Becker" <ndbecker2(a)verizon.net> writes: Good suggestion! I'll post the modified code if anyone is interested. Yes pleaze. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

3 5