- Boost - lists.boost.org

Re: [boost] numeric-ublas errors with Comeau
by Michael Stevens 25 Aug '04

25 Aug '04

Hello Bronek, > I have received updated <cmath> from Comeau and it contains all > necessary functions - I just removed your workaround on my machine and > performed tests, everything is fine. If anybody is interested, I can > send out fixed <cmath> file for libcomo 31. Support for Comeau compiler > is incredibly responsive, I think they treat it personally ;-) > Excellent. I think we can now assume the problem will not exist in future libcomo versions. I have made the uBLAS config.hpp library version dependant on this assumption.. #if defined (__COMO__) && ! defined (BOOST_STRICT_CONFIG) // Missing std::abs overloads for float types in <cmath> are in <cstdlib> #if defined(__LIBCOMO__) && (__LIBCOMO_VERSION__ <= 31) #include <cstdlib> #endif #endif Michael

1 0

Re: [boost] test_read_write_mutex trouble under Tru64 Unix
by Ralf W. Grosse-Kunstleve 25 Aug '04

25 Aug '04

--- "Ralf W. Grosse-Kunstleve" <rwgk(a)yahoo.com> wrote: > --- "Ralf W. Grosse-Kunstleve" <rwgk(a)yahoo.com> wrote: > > > Last night I started Aleksey's regression.py script under Tru64 Unix. It > used > > to finish after 6 hours, but now the test_read_write_mutex process has > > consumed > > 16 CPU hours already without finishing. I am going to kill it. I hope the > > failure shows up at the meta-comm site. Let me know if more information is > > required. > > I had to use the kill command a few more times. I don't think the results > made > it to the meta-comm server. The output of regression.py is available here: > > http://cci.lbl.gov/~rwgk/tmp/tru64cxx65_boost_regression/ > > The file name is run_2004_08_18_0207.log. The file run_regression.csh was > used > to start the tests. For the record: the tests are still broken. I just had to kill -INT the "process_jam_log" process after 75 minutes of CPU time. Before that I already killed -INT two mutex-related tests. Ralf __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

2 3

shared_ptr and pointer to function
by Vladimir Prus 25 Aug '04

25 Aug '04

I wonder if shared_ptr can hold a pointer to a function. I've just tried the following program: #include <boost/shared_ptr.hpp> using namespace boost; int main() { extern int* object; boost::shared_ptr<int> p(object); extern void (*function)(); boost::shared_ptr<void ()> p2(function); return 0; } The first initialization, of course, work. The second produces a lots of errors. Do I miss something obvious? TIA, Volodya

3 6

libs/filesystem/example/Jamfile
by David Abrahams 24 Aug '04

24 Aug '04

Some questions: 1. Why does this Jamfile build the example with sources included directly instead of referencing the library? exe file_size : file_size.cpp <lib>@boost/libs/filesystem/build/boost_filesystem : <define>BOOST_ALL_NO_LIB <include>$(BOOST_ROOT) <sysinclude>$(BOOST_ROOT) ; 2. Why isn't there an entry to build simple_ls? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

RE: [boost] Re: Re: New design proposal for boost::filesystem
by Bennett, Patrick 24 Aug '04

24 Aug '04

> -----Original Message----- > On Behalf Of Ferdinand Prantl > Sent: Tuesday, August 24, 2004 4:30 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: New design proposal for boost::filesystem > > I have nothing against usage of UTF-8 if it suits the scenario well. I > just say that it is not an encoding for all purposes. It is a multibyte > one and so extremely inefficient for getting size, searching, etc. [Bennett, Patrick] I fail to see how this is the case. Right now, today, filesystem supports *only* ascii. If you continued to use ASCII, nothing would change. There is zero speed penalty for calculating the # of *bytes* in an utf-8 string. If you want to determine the # of characters, then there is, but then only if you're actually working on a Unicode string. There is no getting around this for an international application, no matter what encoding is used. > Why to prescribe it for all boost::filesystem users and force them to put > recoding into their sources, [Bennett, Patrick] Absolutely no recoding would be necessary for current users of boost::filesystem. boost::filesystem has no support for unicode today, so why would they have to recode anything? > when it can be achived inside the boost::filesystem as it is done > in std::streams? > I would like to have the boost filesystem as flexible as > possible. Someone can work with filenames in std::string in current > locale, > in UTF-8 or a different locale, someone can use std::wstring with UCS-2 or > UTF-16, etc. The question is, if such a flexibility is not so rare, that > it rather spoils the interface. I don't think so. > > > Win32 doesn't support UTF-8 filenames natively. That's why > boost::filesystem > > would have to convert to/from UCS-2 along Win32 interface boundaries. > > If you're concerned about other platforms, you shouldn't be. > boost::filesystem > > currently works only with latin encodings in ascii strings so no > functionality > > would be taken away. > > UTF-8 is not identical with the complete iso-8859-1 (latin1) codepage. > Some code could be broken by accepting UTF-8 in the new version. [Bennett, Patrick] Hmmm, good point, but... would it break for any of the characters that are valid characters for a path or filename on an 8859-1 system? No, not that I can think of. > Linux can be configured to support UTF-8 natively. However, it is not > necessary and depends on your locale installation and configuration. > > By imbuing I meant the conversion "application filenames encoding" -> > "machine filenames encoding". Instead of putting a platform dependent code > into conditions, which does the translation, one could simply say "I am > running in UTF-8, boost::filesystem, please understand it and do the > system > translation for me". Exceptoins could sourt out incompatibilities. > > boost::filesystem::imbue("UTF-8"); // more abstract than codecvt > pseudocode > :-) > > In this example an internal conversion into UCS-2 would be done on > Windows, > on Linux it would depend on the configured locale and on the other > systems, > which could support ASCII only, it would convert into ASCII only. However, > it does not constrain the application from running wholly in wchar_t (e.g. > UCS-2) or char (UTF-8 or something else), or does not force the user to > write extra code for character conversion if it is not necessary. [Bennett, Patrick] If you can think of a good way of handling this that doesn't involve a mess of codepages, locales, and facets, then I'm all for it. Frankly I think C++'s 'built-in' internationalization support is a nightmare, but that's probably just me. My (intentional) limited exposure to them probably hasn't helped. It's hard to beat having a 'single' encoding like UTF-8 that can handle all defined characters. Unicode is definitely the way to go IMO. My real issue with boost::filesystem is that as currently defined, it's unusable in an application that will be used around the world. My initial response to this whole thread was just to point out to David that there *are* issues preventing people from using the library. He didn't think there were any, so I was compelled to point out what one of the issues was for me at least. At the company where I work we're currently just pursuing our own wrappers for what filesystem provides. I originally tried using filesystem, but once I saw that it's handling of internationalization was absent, I had no choice but to dump it. I certainly have an interest in it being improved, and I could see looking at it again, but someone will have to spearhead that initiative. Considering that this hasn't really been brought up before tells me that people either aren't using the library, or simply don't care about internationalization (probably the latter). I, unfortunately, don't have that luxury. Cheers... Patrick Bennett

2 1

[documentation] liks to other boost libs
by Thorsten Ottosen 24 Aug '04

24 Aug '04

Hi, When I link to the documentation of other libraries, would I have to use full address http://www.boost.org/doc/html/ref.html or can I simply do ../../lib-name/index.html ? Thanks Thorsten

3 2

Re: [boost] numeric-ublas errors with Comeau
by Michael Stevens 24 Aug '04

24 Aug '04

Hi Bronek, It seems from Jonathan's and your info the overloads uBLAS needs (for float types) should be in cmath. As you show the work around is to #include <cstdlib> I would like to make this library version dependant but for now have simply place the include in uBLAS's "config.hpp" header. Looking at the regression tests there is a far more serious problem. There is a series of warning thus: ublas/matrix.hpp", line 1030: warning #504-D: nonstandard form for taking the address of a member function size1_ (ae ().size1 ()), size2_ (ae ().size2 ()), data_ (functor_type::size1 (size1, size2) + 1) { The warning point to the functor_type::size1(size1,size2). The compiler is getting this very wrong. There is no address to be taken here! It should be calling the static 'size1' member of the functor_type. This is probably the cause of a few further failures. Michael

2 2

boost::random Unneceassry standard stream definitions
by Michael Stevens 24 Aug '04

24 Aug '04

In boost::random the random number generators #include <iostream> This introduces the unnecessary definitions of the standard stream cin, cout etc. These are not required to define the stream operations and will fail on runtime environments which cannot define the default streams. It would be better to use instead: #include <istream> #include <ostream> On indeed only the forward definition are required to define stream operations #include <iosfwd> The latter requires that when the templates are instantiated a stream definition exists. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

boost::dereferenceable<>::operator->() problem
by Pavel Kuznetsov 24 Aug '04

24 Aug '04

Recently two of our developers encountered the same problem with boost::dereferenceable<>::operator->(). There were an iterator which returned value_type from its operator*, not value_type&: value_type operator*() const; And it was inherited from boost::random_access_iterator_helper, which in turn is indirectly inherited from boost::dereferenceable. Since our iterator class template did not have its own operator->, one from boost::dereferenceable<> was inherited. And it is defined as follows: P operator->() const { return &*static_cast<const T&>(*this); } where P is pointer to value_type of corresponding iterator. Both of the compilers which we use (MSVC 6.0 and CodeWarrior) compile this code without any errors (though at least one of them did gave a warning). That lead to operator-> returning addres of a temporary object. What do you think about modifying operator-> so that it would be permissive to iterators for which operator* gives rvalue? E.g. this way: struct address_of_proxy { value_type value; address_of_proxy( value_type const& v ) : value( v ) { } operator value_type const*() const { return &value; } value_type const* operator->() const { return &value; } }; address_of_proxy operator->() const { return address_of_proxy( *static_cast<const T&>(*this) ); } where value_type is value_type of corresponding iterator. And of course it is possible to avoid creating proxy object when iterator's operator* returns reference, not value... -- Pavel Kuznetsov MetaCommunications Engineering http://www.meta-comm.com/engineering

2 7

Type mismatch in type_with_alignment.hpp
by Joaquín Mª López Muñoz 24 Aug '04

24 Aug '04

Most templates in these header take an alignment parameter of type size_t, yet a few of them accept an int instead: is_aligned type_with_alignment These causes in some compilers nasty truncation warnings when using aligned_storage with its default alignment_ parameter (maximum alignment) integer conversion resulted in truncation detected during: instantiation of class "boost::aligned_storage<size_, alignment_> [with size_=16UL, alignment_=18446744073709551615UL]" at line 114 of... 1. Is there any fundamental reason why some alingment parameters are int instead of size_t? 2. If not, any objection to fixing this in the CVS? 3. Could it be the other way around, namely that aligned_storage must use ints instead of size_t's? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2