- Boost - lists.boost.org

Re: [boost] boost::scoped_array::release?
by Beman Dawes 12 Mar '06

12 Mar '06

"Howard Hinnant" <howard.hinnant(a)gmail.com> wrote in message news:592D3A44-8F72-4BF6-90C3-0390413886A4@twcny.rr.com... > Fwiw, I've whipped up an independent C++03 emulation of unique_ptr. > It is based on Rani Sharoni's ideas here: > > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463 > > It isn't perfect, but it could be useful prior to rvalue references. > > http://home.twcny.rr.com/hinnant/cpp_extensions/unique_ptr_03.html Hi Howard, Who is the copyright holder? You? Your employer? I try to encourage programmers to make the copyright message the first line of code they write in a new source file. Mostly it doesn't matter, but every once in a while saves a great deal of later grief. Ditto license. If you are in search of a good license, Boost happens to have one available:-) --Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

4 5

Re: [boost] [pkg-boost-devel] Bug#349209: boost: Boost Graph Library is non-free and undistributable in compiled form
by Steve M. Robbins 12 Mar '06

12 Mar '06

Dear Boost Graph Library Developers, The following is a reply to a bug report from a Debian user [http://bugs.debian.org/349209] pointing out deficiencies in the library licensing, from Debian's point of view. We'd like to know whether the few remaining files NOT available under the Boost Software License may be relicensed. Thanks. On Sat, Jan 21, 2006 at 04:21:38PM +0100, Francesco Poli wrote: > According to boost debian/copyright file, the > Boost Graph library does not seem to comply with the DFSG. That file is out of date. Most of the current boost source files are licensed under the Boost Software License [http://www.boost.org/LICENSE_1_0.txt] which I believe is OK by DFSG. I found the exceptions in the HEADER files using cd boost/graph find * -type f | xargs grep -L 'http://www.boost.org/LICENSE_1_0.txt' Of the exceptions these 8 are under the original GRAPH license: adjacency_list_io.hpp cuthill_mckee_ordering.hpp detail/sparse_ordering.hpp BLANKET king_ordering.hpp profile.hpp relax.hpp BLANKET sloan_ordering.hpp wavefront.hpp The two marked BLANKET, however, are actually available under the Boost Software License as all listed authors have granted permission to replace all existing licenses on their contributions to Boost with the Boost Software License, Version 1.0. [http://www.boost.org/more/blanket-permission.txt] For the record here are the set of authors and whether they appear on blanket-permission.txt: François Faure NO Andrew Lumsdaine YES Lie-Quan Lee YES Jeremy G. Siek YES Doug Gregor YES D. Kevin McGrath NO Marc Wintermantel NO Three more of the headers have MIT/BSD-like licenses which sound okay to me. They are as follows. File detail/bitset.hpp is from SGI with the following license: /* * Copyright (c) 1998 * Silicon Graphics Computer Systems, Inc. * * Permission to use, copy, modify, distribute and sell this software * and its documentation for any purpose is hereby granted without fee, * provided that the above copyright notice appear in all copies and * that both that copyright notice and this permission notice appear * in supporting documentation. Silicon Graphics makes no * representations about the suitability of this software for any * purpose. It is provided "as is" without express or implied warranty. */ File isomorphism.hpp is under the following license: // Copyright (C) 2001 Jeremy Siek, Douglas Gregor, Brian Osman // // Permission to copy, use, sell and distribute this software is granted // provided this copyright notice appears in all copies. // Permission to modify the code and to distribute modified code is granted // provided this copyright notice appears in all copies, and a notice // that the code was modified is included with the copyright notice. // // This software is provided "as is" without express or implied warranty, // and with no claim as to its suitability for any purpose. File property_iter_range.hpp is under the following license: // (C) Copyright François Faure, iMAGIS-GRAVIR / UJF, 2001. Permission // to copy, use, modify, sell and distribute this software is granted // provided this copyright notice appears in all copies. This software // is provided "as is" without express or implied warranty, and with // no claim as to its suitability for any purpose. File simple_point.hpp has no copyright at all. I presume this is an oversight and invite the Boost Graph authors to comment. > What is worse, it seems there's no permission to distribute > the Boost Graph Library in compiled form. The headers are only distributed as sources, so that should be OK, even if annoying and possibly non-free (see below). There is a small library that is compiled to libbgl-viz. This library has four source files, three of which are under Boost Software License. The exception is libs/graph/src/graphviz_lex.ll, which is under the origian graph license. On the other hand, the listed author, Lie-Quan Lee has given blanket permission, so we may apply the Boost Software License to it as well. > | Any disputes arising out of this Agreement or LICENSEE'S use of the > | software at any time shall be resolved by the courts of the state of > | Indiana. LICENSEE hereby consents to the jurisdiction of the Indiana > | courts and waives the right to challenge the jurisdiction thereof in > | any dispute arising out of this Agreement or Licensee's use of the > | software. > > This is a choice of venue, which is considered non-free by many > debian-legal regulars (including myself...). > People who accept this license may be forced to travel to the state > of Indiana, whenever the copyright holder decides to sue them (even > for frivolous claims, even if they live on the other side of the > ocean). This is a significant restriction on the exercise of the > rights granted by the license. This sounds like a serious problem. I'd hate to have to remove part of Boost from Debian. To the graph authors: is it possible that the remaining few files can be relicensed under BSL? Thanks, -Steve Robbins (co-maintainer of Boost for Debian)

4 3

[optional] from_optional
by Vaclav Vesely 11 Mar '06

11 Mar '06

Hi, There is common need of getting value from optional with possibility to define default value in case of the optional is uninitialized. I suggest two alternatives: optional<int> o; int i = o.get(123); // meber function get with additional parameter int j = from_optional(o, 123); // free function Both alternatives can be implemented simultaneously. What do you think about it? Regards, Vaclav

1 0

[interprocess] shared memory lifetime
by Kim Barrett 11 Mar '06

11 Mar '06

In reply to my review comments, Ion Gaztanaga wrote 2/17/06: > > A reference count of create + open - close is maintained for shared > > memory objects. If this count reaches zero, the shared memory > > object is unlinked (at least in the posix version). The lack of any > > documented unlink mechanism might lead one to guess that something > > like this is going on, and is documented by the last paragraph of > > this section ("When all processes ... close ..., the shared memory > > segment is destroyed"). A bit more emphasis might be useful here. > > On the other hand, I'm actually not convinced this is a good idea. > > It is certainly fragile, in that a program which crashes (for > > whatever reason) won't close any shared memory objects it has open, > > resulting in the reference tracking getting messed up. > > You can have problems in POSIX systems, but I couldn't find a better way > to implement this. If a program crashes there is no way control > anything. The unique solution would be to provide a function that > destroys all named objects that I can register with every creation so > that you can catch signals and call that functions to free all objects. > In windows the OS frees the resources automatically. For standard C++ > IPC mechanisms I would request OS help for program crashes, just like > heap memory is freed automatically. > > > For example, one couldn't start up a > > process which parses some data into an in-memory format that it > > records in shared memory and then exits, with other programs saving > > parsing time by just getting the information from shared memory. > > This doesn't work if those other programs don't get around to > > opening the shared memory before the parser program exits. > > I would like to implement the POSIX-like behaviour in windows, but that > would require some permanent store that or a server/ process/service > that serves named IPC mechanisms windows. You can use memory mapped > files for this behaviour. Take in care that POSIX unlink mechanism is > also complex so that if a process unlinks the shared memory, if another > process can create a new shared memory with the old name while older > processes are still attached to the old shared memory. I need help from > POSIX experts. First let me make sure I understand what is going on here. On Windows, the shmem library is presently using create_file_mapping and open_file_mapping, while on POSIX systems it is using shm_open. An object created with create_file_mapping exists until there are no references, assuming I'm understanding what you've said. (I don't have (easy) access to Windows API documentation, so can't go look up this information. Please correct me if you see any confusion.) A POSIX shared memory object exists from the time it is created until it is unlinked and all references are gone (or the system is rebooted). (It becomes inaccessible to further shm_open calls if unlinked, but remains open to processes that had already opened it.) What the present library implementation is trying to do with this reference count mechanism is to emulate the Windows behavior on POSIX systems. Unfortunately, as has been noted, that emulation really isn't very reliable in the face of ill-behaved (i.e. crashing) clients. And I'm pretty sure there isn't a solution to that problem, at least not with the shm_open &etc API. First question: Why not use the shm_open interface on Windows? One possible answer would be that the Windows POSIX support doesn't include the shm_xxx API. And that might even be the answer, since some web searches have led me to suspect that Windows only supports the SysV shared memory API. Which leads to Second question: Why use different implementations on different platforms? Why not use the (admittedly somewhat clumsy to use directly) SysV shared memory API, which is pretty widely supported? It's a little more painful to use, but that's an implementation detail that won't be exposed to library clients. One issue might be kernel limits on min/max size and number of objects; some of the references I have make mention of such but don't provide much detail. On my stock configured SuSE9.3 machine I see max number of identifiers 4096 and max size 33554432 (32768 * 1024). SysV shared memory also doesn't support resizing, which is available when using the shm_open API (I don't know whether that feature is available with the create_file_mapping API). I don't know if that actually matters for this library. Note that one of the capabilities of SysV shared memory is obtaining the current number of attaches. I don't know if it reliably gets decremented when an attached process exits without explicitly detaching though; I would hope so, but haven't verified it. If so, that could provide a correct reference count implementation. Note also that the size is also recorded, which I think would eliminate the need for the header in the current shared_memory implementation. Hm. If the SysV API provides a correct reference count implementation, and is widely supported, including on Windows, then using that API would permit either lifetime behavior to be implemented (possibly even configurable). Of course, we have yet to have the discussion of which behavior is actually preferable. But it is certainly the case that the present situation, where the behavior is not documented and is buggy on non-Windows platforms, is not ideal.

5 13

Dimensional Analysis
by Paul Mensonides 11 Mar '06

11 Mar '06

I was playing around with Dave's and Aleksey's dimensional analysis example, and I decided that I couldn't leave well enough alone. To that end, I decided to reimplement it so that combining units could be written using infix operator notation. Anyway, the attached file implements it so the following works (on EDG). #include "dim.hpp" #include <iostream> int main(void) { using namespace dim; using dim::time; // annoying names from C headers! DIM( length / time ) velocity; DIM( velocity / time ) acceleration; DIM( mass * acceleration ) force; quantity<float, DIM(mass)> m = 5.0f; quantity<float, DIM(acceleration)> a = 9.8f; quantity<float, DIM(force)> f = m * a; std::cout << "force = " << f.value() << '\n'; return 0; } I find the syntax like DIM( mass * length / (time * time) ) force; mildly amusing, so I thought I'd share. Regards, Paul Mensonides

3 7

[optional] swapping initialized with uninitialized
by Vaclav Vesely 11 Mar '06

11 Mar '06

Hi, When two optionals (one initialized and other not) are swaped, then the one value in uninitialized optional is constructed and the other one in initialized optional is destructed. IMHO it's not necessary. It should be more effective to swap optional's m_storages without any values constructiona and destruction. Is there any reason for the current implementation? Regards, Vaclav

3 2

boost::serialization - problem move to 1.33.1 version
by Алексей Обухов 11 Mar '06

11 Mar '06

Hello all ! I write small test program using boost::serialization. If I use boost 1.32 - compilation OK. But I change boost to 1.33.1 - compiler rise error :( Where I be mistaken ? Compiler messages: OtherTest.cpp w:\Devil\Projects\PLTools2_boost_1.33.1\boost\boost\serialization\export.hpp(146) : error C2027: use of undefined type 'boost::serialization::extended_type_info_null' with [ T=BoostTest2::A ] w:\Devil\Projects\PLTools2_boost_1.33.1\boost\boost\serialization\export.hpp(146) : see reference to class template instantiation 'boost::serialization::extended_type_info_null' being compiled with [ T=BoostTest2::A ] w:\Devil\Projects\PLTools2_boost_1.33.1\boost\boost\serialization\export.hpp(145) : while compiling class-template member function 'void boost::archive::detail::guid_initializer::export_register(const char *)' with [ T=BoostTest2::A ] w:\Devil\Projects\PLTools2_boost_1.33.1\Tests\OtherTest\boost_test_2.h(64) : see reference to class template instantiation 'boost::archive::detail::guid_initializer' being compiled with [ T=BoostTest2::A ] Results This error point to line: (full code below) BOOST_CLASS_EXPORT_GUID( BoostTest2::B, "ClassB" ) OtherTest.cpp: #include <iostream> #include <sstream> #include <boost/serialization/vector.hpp> #include <boost/serialization/string.hpp> #include <boost/serialization/nvp.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/serialization/export.hpp> #include <boost/serialization/base_object.hpp> #include "boost_test_2.h" using namespace BoostTest2; /// ..... boost_test_2.h #pragma once namespace BoostTest2 { class A { public: A() {m_A = 1;} virtual ~A() { } int m_A; }; class B : public A { public: B() {m_B = 2;} virtual ~B() {} int m_B; }; class C : public A { public: C() {m_C = 3;} virtual ~C() {} int m_C; }; } #define BOOST_NVP(name,value) \ boost::serialization::make_nvp(name, value) namespace boost { namespace serialization { template<class Archive> void serialize(Archive & ar, BoostTest2::A &a, const unsigned int version) { ar & BOOST_NVP( "A", a.m_A ); } template<class Archive> void serialize(Archive & ar, BoostTest2::B &b, const unsigned int version) { ar & boost::serialization::make_nvp( "A", boost::serialization::base_object<A>(b) ); ar & BOOST_NVP( "B", b.m_B ); } template<class Archive> void serialize(Archive & ar, BoostTest2::C &c, const unsigned int version) { ar & boost::serialization::make_nvp( "A", boost::serialization::base_object<A>(c) ); ar & BOOST_NVP( "C", c.m_C ); } } } BOOST_CLASS_EXPORT_GUID( BoostTest2::B, "ClassB" ) BOOST_CLASS_EXPORT_GUID( BoostTest2::C, "ClassC" ) BOOST_IS_ABSTRACT( BoostTest2::A ) BOOST_CLASS_VERSION( BoostTest2::A , 0 )

1 0

Re: [boost] [interprocess] shared memory lifetime
by Olaf van der Spek 10 Mar '06

10 Mar '06

On 3/10/06, Kim Barrett <kab(a)irobot.com> wrote: > >One option is to use a memory mapped file to emulate posix-like behavior > >in windows. But it surely will be slower (the OS will dump data to file) > >and the unlink is not trivial. > > That does seem like it would be bad if true. Are there any file > manipulation options that might be used to control that? I don't know, > but I'll ask around and do some reading and see what I can find. > > [Later] As long as you don't flush the file it would seem like a memory > mapped file should be no different from a shared memory in performance, > the only difference is where data gets written if it needs to be swapped > out. The big downside to using an actual file would be that you need a > place in the file system to put it. Then you get into the whole name of > the shared memory portability problem again. The OS will probably write dirty pages to disk even before paging them out so that if it needs to page them out it doesn't have to also do a disk write.

1 0

[Announce] Mailing list downtime this Saturday
by Doug Gregor 10 Mar '06

10 Mar '06

All Boost mailing lists hosted at lists.boost.org will be down from 8pm to midnight EST this Saturday, March 11th while we migrate to a new, dedicated mail server provided by the Open Systems Lab at Indiana University. During this down time, the mail archives at lists.boost.org will be unavailable and any mail sent to lists.boost.org will be queued and forwarded. We ask that members refrain from posting messages to lists.boost.org during this time "just in case," although we expect that all mail sent during this time will be forwarded properly. If you should have any questions, please contact me directly at dgregor(a)cs.indiana.edu. Doug Gregor Boost Moderator dgregor(a)cs.indiana.edu

1 0

[FileSystem] Incorrect info returned by filesystem::filesystem_error exception
by james＠massey46.fsnet.co.uk 10 Mar '06

10 Mar '06

Hi, There appears to be problems with boost::filesystem::rename with respect to the information returned by boost:filesystem::filesystem_error exception. See the 2 tests below and attached source code examples. Test 1: Precondition: The "Source" file does not exist and the "Destination" file does exist. Test: Perform rename(Source,Destination); Expected Result: The rename fails because the Source file does not exist. Actual Result: A boost filesystem exception is thrown and the output is what text: boost::filesystem::rename: "Source", "Destination": Success error_code: 1 native_error: 0 The exception information suggests the command was successful. The result of a UNIX "mv" with the same scenario is "mv: cannot stat `Source': No such file or directory" Note that a similar output is displayed if the "Source" and "Destination" files exist before the test is run. Test 2: Precondition: The "Source" and "Destination" files exist. The directory DirWithNoWritePermission exists and has permissions 555. Tests: Perform rename(Source,DirWithNoWritePermission/Anything); Perform rename(Source,Destination); Expected Result: The first rename fails because the directory permissions forbid the rename. The second rename fails because the destination file exists. Actual Result: A boost filesystem exception is thrown and the output is what text: boost::filesystem::rename: "Source", "DirWithNoWritePermission/Anything": Permission denied error_code: 3 native_error: 13 and is the same in both cases. It appears that the exception information displayed for the second test has been "recalled" from the first test. This may be related to the problem shown in Test 1. Test programs run under Suse Enterprise Linux 9 with gcc version 3.3.3, boost 1_33_0 and 1_33_1 Regards James Massey

1 0