[boost] Re: string conversion methods
It's only minor: But boost::filesystem and boost::date_time have string conversion methods such as string() native_file_string() to_simple_string() where as boost::format (and also stringstreams in the STL) have str() I don't know about the other libraries? Is there a standard for this in boost or is it up to the libraries? Should they be commonised? Ideally, yes. I would prefer .c_str() for const char* conversion and str() for std::string cheers Thorsten ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: string conversion methods
I don't know about the other libraries? Is there a standard for this in boost or is it up to the libraries? Should they be commonised? Thorsten Ottosen wrote Ideally, yes. I would prefer .c_str() for const char* conversion and str() for std::string In date-time there are several 'to_string' functions that provide different ouput formats so a single 'str()' method isn't going to be enough. As for c_str(), you can use this once you have std::string. From my view there is no point in trying to force fit this functionality into an inadequate interface. Finally, by keeping these as free functions dates and times can be used without including I/O headers which the 'to_string' functions use. Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] tokenizer with ifstream
I couldn't find this topic disscussed before, is it possible to use tokenizer directly with an ifstream - instead of reading the contents of the file into a string first? Thanks, Eoin. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] reflect ABI in libname
Greetings! The problem: - AFAIK, the two[1] libs built from boost always result in e.g. libboost_thread.so. The problem is that currently no OS has support for embedding the required ABI[2] into the runtime-linker info, therefore it only knows a libray name. When it finds a library but that lib has a wrong ABI, it fails more or less early and with more or less meaningful error-messages. The workarounds: - 1. not using more than one compiler on a system. This works on a few Unix-like platforms where a compiler is part of the system but even there, people sometimes want to install a different one for various reasons. 2. use static linking. Works, but we don't want static linking. 3. supply a path to the proper lib explicitly. This is already a pretty good solution, apart from the fact that there are no default install paths for ABI XYZ. 4. encode the ABI in the library-name. This solution is e.g. used by STLport on win32: stlport_vc645.dll is STLport 4.5 compiled with VC6. I'd like to have boost adopt version 4 of it. Note that apart from the ABI itself, we'd also have to encode the stdlibrary into the name because std::string from GCC has a different binary layout than the one from STLport. The name would then be like this: libnameversion_ABI-tag[_stdlib-tag].so The stdlib would be optional because a) not every lib necessarily uses it b) when not given, the default one that comes with the compiler is assumed. For the tags for compiler and stdlib, I'd start this list: gcc2.95 - for GCC 2.95 gcc2.96 - for the evil thing known as GCC 2.96 (http://gcc.gnu.org/gcc-2.96.html) gcc3.2 - for GCC 3.0 - 3.2 gcc3.3 - for GCC 3.3 vc6 - MS visual C++ 6 vc7 - (anyone a clue if there is a version 7 or if that version was marketed as .Net ?) stlp4.5 - STLport 4.5 which mostly describes what compilers I use. Drawbacks: --- There is no such thing as this compiler's ABI. GCC 3.3 by default emits the GCC3.2-ABI unless told differently. VC7's compiler finally makes wchar_t a distinct type, at least if told so by a commandline switch. I'm sure other compilers have their own ways to achieve the same. No, I don't have a solution to this and I don't think there is one. I fear someone will have to step up and say for XYZ 3.14 the command-line switches have to be --ph00=4. There will be people that wont like that decision, but there wont be a way around it. In case enough good arguments speak for a change, the next version of boost might change to a different setting for the compiler. Else, above workarounds can still be applied. One big advantage to me is that I can simply link an app against say libboostthread1.30_gcc3.2.so and, assuming I didn't mess it up, be sure it runs on another system with that lib. It also means that boost could theoretically distribute compiled versions of its libs. Options: - People often like having a 'debug-version' around that usually includes some assertions and is not stripped. Adding that as info to the libname in a uniform fashion would also be nice (I'd just append a '_debug' or '_dbg'). Yes, I know that all this is not ideal. However, I believe that the resulting chaos is much smaller than it could be and better than the status quo. It also means that mistakes will be made, but I'm willing to make them. I have the hope that we can agree on a common ABI for most cases and the rest can still use other means. Not daring to make a mistake for lack of a perfect solution is the greater pain for me. Ulrich Eckhardt [1] threads and Python-bindings (and regex ?) [2] Application Binary Interface. Different C++ compiler's objectcode can't be mixed since e.g. name-mangling or calling conventions are different. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [mpl] ETI problem w/ clear algorithm
Aleksey (and others), I'm working on getting variant to compile under MSVC 6, but I've come across what seems to be an ETI problem that needs a workaround. However, I'm not sure what is the most appropriate way to make the fix. Below is the error output from the regression tests (variant_test1). Thanks, Eric --- D:\boost4\boost\boost/mpl/clear.hpp(35) : error C2504: 'algorithmint' : base class undefined D:\boost4\boost\boost/mpl/remove_if.hpp(64) : see reference to class template instantiation 'boost::mpl::clearint' being compiled D:\boost4\boost\boost/variant/variant.hpp(508) : see reference to class template instantiation 'boost::mpl::remove_ifint,struct boost::detail::variant::has_nothrow_move_constructorstruct boost::mpl::arg1 ' being compiled D:\boost4\boost\boost/variant/variant.hpp(1243) : see reference to class template instantiation 'boost::variantT0,T1,T2,T3,T4,T5,T6,T7,T8,T9' being compiled ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] no semaphores in boost::thread
At 09:22 AM 6/4/2003, Stefan Seefeld wrote: hi there, I'v been trying to find some info as to why semaphores are considered harmful by the boost::thread authors, without luck. Is there any concise text describing the problem ? I've expanded the FAQ entry to read: Why has class semaphore disappeared? Semaphore was removed as too error prone. The same effect can be achieved with greater safety by the combination of a mutex and a condition variable. Dijkstra (the semaphore's inventor), Hoare, and Brinch Hansen all depreciated semaphores and advocated more structured alternatives. [Andrews-83] summarizes typical errors as omitting a P or a V, or accidentally coding a P on one semaphore and a V on on another, forgetting to include all references to shared objects in critical sections, and confusion caused by using the same primitive for both condition synchronization and mutual exclusion. The [Andrews-83] reference is to Gregory R. Andrews, Fred B. Schneider, Concepts and Notations for Concurrent Programming, ACM Computing Surveys, Vol. 15, No. 1, March, 1983. http://www.acm.org/pubs/citations/journals/surveys/1983-15-1/p3-andrews/ I'v been using semaphores for years and can't think of what should be wrong with it. That's what most programmers said about goto when Dijkstra's Go To Statement Considered Harmful was published. If you go back and read his letter (http://www.acm.org/classics/oct95/), you could substitute semaphore for go to statement in the key sentence: The go to statement as it stands is just too primitive; it is too much an invitation to make a mess of one's program. Goto's work (or worked; how long since you've seen one in a program?) Semaphores work. But we are better off without both of them. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] tokenizer with ifstream
I was writing a little article on the topic Its not finished i will finish it tonight. In the mean time take a look at http://gcc.gnu.org/onlinedocs/libstdc++/21_strings/howto.html#3 I looked into the efficiency of stringtok function (from above link) as opposed to C's strtok and the good news is they are virtualy equivalent. On Sun, 2003-07-06 at 11:29, Eoin Hennessy wrote: I couldn't find this topic disscussed before, is it possible to use tokenizer directly with an ifstream - instead of reading the contents of the file into a string first? Thanks, Eoin. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Problems with CVS?
The last 3 or 4 times that I have tried to check out the latest boost, the checkout gets most of the way through, and then hangs. Here's what I see in my terminal: lots of lines snipped cvs server: Updating boost/tools/inspect/build cvs server: Updating boost/tools/regression cvs server: Updating boost/tools/regression/build cvs server: Updating boost/tools/regression/detail And then nothing more for hours and hours. Anyone have any idea what is wrong? -- -- Marshall Marshall Clow Idio Software mailto:[EMAIL PROTECTED] Hey! Who messed with my anti-paranoia shot? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: no semaphores in boost::thread
Beman Dawes wrote: I've expanded the FAQ entry to read: Why has class semaphore disappeared? Semaphore was removed as too error prone. The same effect can be achieved with greater safety by the combination of a mutex and a condition variable. Dijkstra (the semaphore's inventor), Hoare, and Brinch Hansen all depreciated semaphores and advocated more structured alternatives. [Andrews-83] summarizes typical errors as omitting a P or a V, or accidentally coding a P on one semaphore and a V on on another, forgetting to include all references to shared objects in critical sections, and confusion caused by using the same primitive for both condition synchronization and mutual exclusion. The [Andrews-83] reference is to Gregory R. Andrews, Fred B. Schneider, Concepts and Notations for Concurrent Programming, ACM Computing Surveys, Vol. 15, No. 1, March, 1983. http://www.acm.org/pubs/citations/journals/surveys/1983-15-1/p3-andrews/ I'v been using semaphores for years and can't think of what should be wrong with it. That's what most programmers said about goto when Dijkstra's Go To Statement Considered Harmful was published. If you go back and read his letter (http://www.acm.org/classics/oct95/), you could substitute semaphore for go to statement in the key sentence: The go to statement as it stands is just too primitive; it is too much an invitation to make a mess of one's program. Goto's work (or worked; how long since you've seen one in a program?) Semaphores work. But we are better off without both of them. There is actually one case that needs a semaphore that has no reasonable alternative in pthreads. The only pthread synchronization operation that is asynch-reentrant safe (i.e. can be called from a signal handler) is signaling a pthread semaphore. It would be nice if there was some abstraction available in boost threads that used this mechanism internally to get the needed behavior, but encapsulated to hide the error-proneness of a raw semaphore. -- Jon Biggar Floorboard Software [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
