- Boost-users - lists.boost.org

RE: [Boost-users] Boost Software License: redistribute modified works?
by Ben Hutchings 27 Oct '03

27 Oct '03

Steve M. Robbins <steven.robbins(a)videotron.ca> wrote: > I've a question for the drafters of the Boost Software > License - Version 1.0 - August 17th, 2003. I am not one of them, but I can give you some answers anyway. > Put yourself in the position of someone who wants to redistribute > a modified version of Boost. For example, the linux distributors > like Debian. > > The license begins with the permission grant: > > Permission is hereby granted, free of charge, to any person or > organization obtaining a copy of the software and accompanying > documentation covered by this license (the "Software") to use, > reproduce, display, distribute, execute, and transmit the > Software, and to prepare derivative works of the Software, and to > permit third-parties to whom the Software is furnished to do so, > all subject to the following: > > [... a restriction and a disclaimer paragraph ...] > > As I read this, "the Software" means "the unmodified tar or zip > file obtained from boost.org". Is that correct? No, it means whatever software says the licence applies to it. This licence does not (yet) apply to all of Boost. All parts of it are supposed to come with a licence that meets certain requirements, listed at <http://www.boost.org/more/lib_guide.htm#License>. The licence you are reading is supposed to be a standard licence that meets these requirements. There is a fuller explanation at <http://www.boost-consulting.com/boost/more/license_info.html>. > I'm permitted to "prepare derivative works of the Software", but the > license doesn't specify what I may do with my derivative works. > > Clearly, I may distribute "the Software", but may I distribute > the derivative work? I think that may be legally implicit, but I am not a lawyer. > Some licenses (e.g. the BSD and the GPL) make it clear that the terms > apply to both the software and to derivative works. Shouldn't the > boost license do likewise? Even if it is legally implicit, I can see that it would be a good idea to clarify it. Since it doesn't specify have a choice-of-law clause it could be interpreted according to any country's contract law and things that are implicit according to US law might not be so elsewhere. Ben.

1 0

compiling as a framework
by Avram Aelony 27 Oct '03

27 Oct '03

This may be a naive question, but on Mac Os X one can compile other libraries as a "framework", for example I can use the OpenGL library by compiling as follows: % g++ mytest.cpp -framework OpenGL Is it possible to be able to do the same style compilation for Boost? Ideally, something like this would be nice... % g++ mytest.cpp -framework Boost Incidentally, although I have installed Boost with bjam, simply compiling a Hello World style program that uses a Boost function gives me errors... An example would be great. thanks, Avram

1 0

directory_iterator TypeLoadException
by Sergey K. 27 Oct '03

27 Oct '03

Hello, I tried to run SimpleLs program, but got a TypeLoadException at the line below. I use boost-1.30.2, MSVC++7.0 Any idea what could be causing the problem? for ( fs::directory_iterator dir_itr( full_path ); dir_itr != end_iter; ++dir_itr ) // exception thrown here Output: In directory: C:\src\cpp Unhandled Exception: System.TypeLoadException: Could not load type boost.filesystem.dir_itr_imp from assembly Filesystem Demo, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null. at boost.==(shared_ptr<boost::filesystem::directory_iterator::dir_itr_imp>* a, shared_ptr<boost::filesystem::director y_iterator::dir_itr_imp>* b) at boost.filesystem.!=(directory_iterator* x, directory_iterator* y) in c:\lib\cpp\boost-1.30.2\boost\filesystem\oper ations.hpp:line 93 at main(Int32 argc, SByte** argv) in c:\src\cpp\boost\filesystemdemo\simplels.cpp:line 44

1 1

Interval Library on MIPS
by David A. Greene 26 Oct '03

26 Oct '03

Hi, I've been attempting to use the interval library on a MIPS/IRIX machine without luck. The problem is that there is no native rounding support and we don't have a C99 environment. I'm getting "Please specify rounding control mechanism" errors from the preprocessor. The thing is, I don't need a rounding mode. I simply want to use intervals of type int. I could understand the error if I was trying to use floating-point intervals but shouldn't I be able to specify intervals that don't require rounding? Or even specify intervals with a policy that ignores rounding? Has anyone run into this problem before? Is there a workaround? -Dave

2 1

MS C++ 7.1 warning C4244 (spirit)
by GIE 25 Oct '03

25 Oct '03

Hello! Is there any way to avoid this warning? =========Beginning of the citation============== ------ Build started: Project: [...], Configuration: Debug Win32 ------ Compiling... [...].cpp BOOST_DIR\boost\spirit\core\primitives\impl\pri mitives.ipp(62) : warning C4244: 'initializing' : conversion from '__w64 int' to 'int', possible loss of data BOOST_DIR\boost\spirit\core\primitives\primitiv es.hpp(190) : see reference to function template instantiation 'RT boost::spirit::impl::string_parser_parse<result_t,boost::unwrap_reference<T> ::type,const ScannerT>(IteratorT,IteratorT,const ScannerT &)' being compiled with [ RT=result_t, T=const char *, ScannerT=boost::spirit::scanner<std::basic_string<char,std::char_traits<char ,std::allocator<char>>::iterator,boost::spirit::scanner_policies<boost::spi rit::no_skipper_iteration_policy<boost::spirit::scanner_policies<boost::spir it::iter_policy_t>::iteration_policy_t>,boost::spirit::scanner_policies<boos t::spirit::iter_policy_t>::match_policy_t,boost::spirit::scanner_policies<bo ost::spirit::iter_policy_t>::action_policy_t>>, IteratorT=boost::unwrap_reference<const char *>::type ] [...] Linking... Build Time 0:04 Build log was saved at "file://PROJECT_DIR\Debug\BuildLog.htm" [...] - 0 error(s), 1 warning(s) ---------------------- Done ---------------------- Build: 1 succeeded, 0 failed, 0 skipped =========The end of the citation================ -- With best regards, GIE.

4 3

Can't build or install
by James Buchanan 25 Oct '03

25 Oct '03

I managed to run bjam -sTOOLS=mingw, and it seemed to do something for 10 minutes or so, but that was it. I found some of the libraries, such as the Regex project's libraries in the debug and release folders in static and dynamic link form, but other libraries didn't seem to build. Where are they, and how do I install the libraries in my library directory? I'd like all libraries except the Python libraries installed. Many thanks for your help, James

1 0

Re: [OT a bit] Condition variable and const-correctness
by Weston Markham 23 Oct '03

23 Oct '03

This might actually be slightly less off topic than the previous post, because it parallels the way that I think about that condition::wait method... Anyway, I'm curious what people think about: void perverse_strcpy( const char *src, char *dest, const char *done // note const ) { while (!done) { // note we expect change *dest++ = *src++; } } The caller can do something like: src = "hello world"; dest[strlen(src)] = 1; // store a nonzero value perverse_strcpy(src, dest, dest+strlen(src)); Yes, its a kinda stupid and, well, dubious function. However, the point is that "const char *" simply means that the pointer points to a char that can only be accessed as a "const char" through that pointer. It does not imply that the referenced thing is physically const. Nor does it imply that the referenced thing is logically const. (meaning that non-const methods can still be called on an object that has a "const Foo *" pointing to it; they simply can't be called through that pointer.) Does this run counter to what people believe the semantics of "const char *" to be? Are compilers permitted to optimize out the check of "!done" based on const-ness? (IIRC, they actually may in some related examples, if "src" and "dest" are types that should not alias to "done"; but this is not the case here) Is there any undefined or implementation-defined behavior of the above code? As separate aside, I believe that "physically const" refers specifically to a property of an object, say, the string constant "x". It is the reason why: const_cast<char*>("x")[0] = 'y' ... results in undefined behavior. The const keyword _could_ be used on an interface to indicate that a method will not produce undefined behavior when invoked on an instance that is actually physically const. This is different from using the const keyword to identify methods which maintain "logical constness". The latter meaning (whatever that may be) is what I believe is used in practice. (and the language is, I believe, designed to support this other meaning) Of course, I'm not, in some cases, sure what that meaning is! I suspect, by the way, that different people may have different ideas of how the const keyword should be applied to interfaces in practice. Each person might have an internally consistent viewpoint, but there may still be several mutually incompatible views. (I'm pretty sure that there are at least a few. I hope they are not as "notoriously arbitrary" :) as naming conventions!) Lastly, just because it amuses me: C++ Shrink: How does that const Foo * make you feel? Programmer: I feel frustrated, doc! I want to change things, but I can't. I know that the other coders do things that I can't; I can see all the changes that they make! Why not me? C++ Shrink: Hmm. Interesting. Weston Markham

1 0

RE: [Boost-users] Re: Condition variable and const-correctness
by Weston Markham 23 Oct '03

23 Oct '03

Mark, (and group) I may not have explained myself clearly in my original message. Your example ThreadedQueue::bMessageAvaliable() const actually demonstrates _exactly_ why I feel that condition::wait should be const. Your method modifies something internally (a boost::mutex; I have no argument whatsoever with the view that locking a mutex changes its state). Then it does some other things that don't affect its const-ness. Then it undoes the modifications it originally made. (By unlocking the mutex) A caller of this function should not care that these things go on internally. In this sense, it is logically const. I would also add that the caller of the function does not care that the precise behavior (say, when it returns, or in other examples, the exact value that it does) of the function can depend on the actions of other threads; this is the point that I had expected resistance on.) Similarly, the condition::wait will modify a mutex (unlocking it, and yes, through a non-const Lock object). It will do some other stuff. Bookkeeping or whatever, maybe even blocking itself. No matter what it does internally, by the time it returns control to its caller, all of this has been undone. The thread is not blocked. It is not in a waiting queue. The mutex that we pointed it at has been locked again. From the caller's perspective, the only things different after the call are: 1. Time has passed. 2. Some other threads have done some things that they might not have done otherwise. What they do is their own business. I don't see how that can affect this function's const-ness. (Am I missing something _here_?) My conclusion is that condition::wait is logically const. I will certainly admit that const-ness may be in the eye of the beholder. I expect that the physically const vs. logically const is a problem with some people. However, there do seem to be other examples of functions that are const (in their signatures) in the same spirit that my intuition tells me condition::wait is. Does this elucidate my position? Weston Markham Mark Sizer wrote: The condition wait() requires a lock, which requires a mutex. The mutex state is toggled from acquired to free to acquired whilst the wait() is waiting. It's the same problem that having a lock creates on a method such as this one: ThreadedQueue::bMessageAvailable() const { { boost::mutex::scoped_lock( _mutexQueue ) return !_queue.empty(); } } The only way to make that work is to declare the _mutexQueue as "mutable". In the case above, I agree with you: In terms of logical "const-ness", these methods are (or can be) const. In terms of physical "const-ness", they are not. Solve the problem with "mutable". However, the condition case is a bit more subtle. ThreadedQueue::messageNext() const { { boost::mutex::scoped_lock lockQueue( _mutexQueue ); if ( _queueOut.empty() ) { // (the lock is released before blocking, // then re-locked before continuing) _conditionMessageReady.wait( lockQueue ); } // get a message } } Is that really const? if the _mutexQueue and _conditionMessageReady are made "mutable" we can MAKE the method const (as shown), but is it? I'd say there is a EXPLICIT state change in the object: Into the waiting state. This is a change, therefore non-const. In the bMessageAvailable() case, there is no explicit state change, you're returning the existing state of the object. There is an implicit state change required to safely do so, which we've decided to hide. The only way this can block forever is bad coding - deadlock. When using a condition.wait(), you are making 2 big state changes: Both the object and the thread involved go from a "running" state into a "blocked" state, perhaps forever if nothing notifies (which is reasonable if the event never occurrs, not a coding deadlock error). That doesn't seem "const" to me. - Mark

4 6

smart_ptr without memory allocation
by John Aughey 23 Oct '03

23 Oct '03

I have a class that implements a buffer pool that allocates block of memory, and the users "free" the memory when it is no longer needed back to the buffer pool. Future allocations simply return the front of the free list. Simple enough, and the class returns shared_array<T> objects to automatically free the memory back into the proper buffer pool. The problem is, this mechanism is used so that during real-time operation (this is a real-time system), there is absolutely no memory allocations required. However, inside shared_array, it uses detail::shared_count and inside shared_count it performs a new to create a sp_counted_base object. So for every smart pointer object that supplies a deleter, it must perform a new. My proposal would be to include another constructor to both shared_array (and probably it's corresponding smart pointer brothers) and to shared_count that looks like: shared_array(T *p, sp_counted_base *d) : px(p), pn(d) { } shared_count(sp_counted_base *d) : pi_(d) { } (I haven't implemented this yet, so the above may not be quite right) The purpose of this is to supply an sp_counted_base object to the shared_* object that does the delete functionality. This eliminates the new in the case where a sp_counted_base object can be supplied. In the case of the managed buffer pool mentioned above, the sp_counted_base object could be allocated with the corresponding buffer, and then re-used for subsequent "allocations" from the free list. This should result in no dynamic allocations to create a shared_* object with a corresponding deleter. I hope this makes sense. It should only require two new constuctors. John

2 1

Bind causing crashes with VS.Net 7.1
by Mark Loew 23 Oct '03

23 Oct '03

I am using bind heavily in my application. I noticed a problem that may/may not be a boost issue but wanted to check if anyone had any quick insights. I am using 2 and 3 paramater functions with bind over a range with the for_each operator. What I have noticed is everything is fine when the system is build in debug mode. I then rebuild in release modes with all optimizations turned on. The boost code crashes with access violations. I disabled the optimization of Whole Program Optimization and everything is fine. I believe I have noticed this with other template functions where the whole program optimization causes problems. Has anyone seen this before and do you know what causes it? Just checking if this is a known boost problem or a VC 7.1 issues. Mark Loew, MCSD, MCSE Application Development Consultant Sagestone Consulting www.sagestone.com <http://www.sagestone.com/> Grand Rapids, MI 616-954-9556 x149 Microsoft Gold Certified Partner mloew(a)sagestone.com

2 1