- Boost - lists.boost.org

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

25 Aug '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of John Maddock > Sent: Wednesday, August 25, 2004 5:50 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: New design proposal for boost::filesystem > > > > Win32 doesn't support UTF-8 filenames natively. That's why > > boost::filesystem would have to convert t o/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. > > Not true: currently the narrow character strings passed to > boost.filefsystem are assumed to be in that platforms native encoding - > you can for example pass native Windows narrow character strings (not > just ACSII ones) to the lib, and actually I don't see why you can't pass > UTF-8 on Linux. [Bennett, Patrick] Yes, you could pass UTF-8 through as-is in Linux. If your application was running in Japan on Windows, boost::filesystem would not work at all. So, yes, you can pass all sorts of extended characters to Windows in an 8-byte string (the majority of which aren't really valid for filenames), but that does nothing for Unicode support. It simply won't work. For Unicode support the application must call the xxxxxW versions of the windows API's and pass in a UCS-2 string. > What you can't do is use the same encoding on all platforms, because the > underlying platform API's won't understand them. [Bennett, Patrick] Correct, this was my whole point. If I can't write a portable (to at least Linux and Windows), internationalizable application with boost::filesystem then it's of no use to (at least) me. This is why I suggested that UTF-8 be used as boost::filesystem's encoding. It can be passed through as-is or converted as needed on each platform and it would be backwards compatible with existing boost::filesystem code. I'll probably not talk about this topic too much more. I think I've pretty much said everything I'm going to say, so if no one else agrees, I'll just move along. ;) Cheers... Patrick Bennett

2 1

casting shared_ptr to function to void
by Vladimir Prus 25 Aug '04

25 Aug '04

If I have boost::shared_ptr<some_class>, it's possible to cast it to shared_ptr<void>. But it does not appear to be any way to convert pointer to function to pointer to void -- just because there's no implicit conversion from function pointer to void*. So, when I compile the attached program with g++, I get: sp.cpp:22: instantiated from here /home/ghost/Work/boost/boost/shared_ptr.hpp:163: error: invalid conversion from `void (* const)()' to `void*' Is there any way to make it work? What I'm trying to do is: - access a function from DLL -- i.e. get shared_ptr<function_type> - do something with the function - cast the pointer into shared_ptr<void> The last pointer will be stored in various places to keep the DLL in memory until last object which depend on it is destroyed. I think I can keep shared_ptr<function_type> everywhere, but can shared_ptr<void> work somehow? Thanks, Volodya

2 2

RE: [boost] Re: Re: New design proposal for boost::filesystem
by Ferdinand Prantl 25 Aug '04

25 Aug '04

Hi, I would prefer to use the standard types like std::string and char * as well. However, I do not like much the idea about a fixed encoding, UTF-8 or something else. It is possible to use any encoding in std::string and even in std::wstring. What do you think about imbuing and codecvt-like approach in boost::filesystem for the names of the files? It has a standard interface for the content of streams, it could serve also the filenames. Not all platforms support UTF-8 filenames, sometinmes could it serve as name mangling support. Ferda > [mailto:boost-bounces@lists.boost.org] On Behalf Of Patrick Bennett > > Correct (kind of), but I'd far prefer that std::string be > used than for some completely new type to be defined. > For users of boost::filesystem, I can't personally think of a > time when a user would need to iterate the paths or files a > character at a time. > Because of UTF-8's nature, even if a user were to search for > something like '/', it would still work for find's, [], etc. > UTF-8 maps to std::string extremely well. > I think there is also a fair amount of precendents already > set for using > UTF-8 internally using std::string as the storage mechanism. > UTF-8 strings don't contain embedded nul's (std::string still > works for that though), ASCII characters remains ASCII > characters, and you can tell if you're in the middle of a > multi-byte sequence. > > Since we're talking about filesystem's inability to be used > with internationalized applications, and you don't think > UTF-8/std::string is the way to do it, what is your recommendation? > > Cheers... > Patrick Bennett > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

3 2

Type traits on Digital Mars
by Daniel James 25 Aug '04

25 Aug '04

Hi, The attached patch improves the type traits library on Digital Mars. Mostly it just selects the correct code to be used, the only new code is a new version of boost::is_convertible. Using '...' to overload the conversion check works really badly, so I experimented with different ways of trying to get it to select the right overload, and found one that mostly works. You can see it in the patch. Also, when using static cosnt values it can sometimes cause '_m_from' to get instantiated - causing a link error. To work round this, it uses enums. With this patch applied there are still the following problems: The compiler has trouble with const and volatile modifiers on voids and arrays in template variables. So it gets a lot of the tests involving these types wrong. The compiler allows some conversions that it shouldn't. For example, it only warns about binding temporaries to non-const references, instead of causing an error. So, in these cases is_convertible is true. Would it be worth adding checks for these cases? is_abstract doesn't work. is_base_and_derived uses the 'broken' implementation, based on is_convertible. The test tricky_is_enum_test fails to compile. Daniel

5 13

Regex lib bug: wrong alignment on 64 bit platforms
by Benzinger, Ralph 25 Aug '04

25 Aug '04

Hello, The regex library contains an alignment bug that leads to bus errors on 64 bit platforms (in particular, Sun and HP). To reproduce, compile regular expression '(?>a+b|a+)bc+' with flags regex_constants::normal. This should raise SIGBUS in perl_matcher<>::push_alt(). As a fix, I suggest forcing alignment of structure saved_state in perl_matcher_common.cpp: struct saved_state { < unsigned int id; < saved_state(unsigned i) : id(i) {} -> union align -> { -> unsigned int id; -> void* dummy; -> align(unsigned i) : id(i) {} -> } id_aligned; -> saved_state(unsigned i) : id_aligned(i) {} }; and further down below: < unwinder = s_unwind_table[m_backup_state->id]; -> unwinder = s_unwind_table[m_backup_state->id_aligned.id]; The other saved_* structures that get pushed onto the stack seem fine for now. Regards, Ralph

2 1

Roadmap of boost::fsm
by Schalk_Cronje＠McAfee.com 25 Aug '04

25 Aug '04

> What is the state of boost::fsm? Are there plans to move it in to Boost from the sandbox? I have noticed that the problem with atomic_count_gcc has now been fixed on HEAD so that is not a limiting factor anymore.

3 2

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