Custom Query (2331 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (701 - 800 of 2331)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Ticket Summary Status Owner Type Milestone Component
#7067 The same options in the different groups cause exception while parsing configuration file. new vladimir_prus Bugs To Be Determined program_options

Reported by Grzegorz Andrejczuk <g.andrejczuk@…>, 22 months ago.

Description

Preconditions: There are two option descriptions defined, containing the same options. The options are stored in the configuration file and grouped by the group.

Result: options_descriptions add method adds two groups parse method throws unknown option exception with cat1.op1

namespace po::boost::program_options; void test() { po::options_description cat1("cat1"); cat1.add_options()

("op1", po::value<std::string>(), "op1") ("op2", po::value<std::string>(), "op2") ("op3", po::value<std::string>(), "op3") ("op4", po::value<std::string>(), "op4");

po::options_description cat2("cat2"); cat2.add_options()

("op1", po::value<std::string>(), "op1") ("op2", po::value<std::string>(), "op2") ("op3", po::value<std::string>(), "op3") ("op4", po::value<std::string>(), "op4");

po::options_description full("full"); full.add(cat1).add(cat2);

po::variables_map map;

boost::filesystem::path path("option.ini");

try {

po::store(po::parse_config_file<char>("option.ini", full), map); exception is thrown "Unknown option cat1.op1" po::notify(map);

} catch(std::exception & ex) {

std::cout << ex.what() << std::endl;

}

option.ini:

[cat1]

op1=v1 op2=v2 op3=v3 op4=v4

[cat2]

op1=v5 op2=v6 op3=v7 op4=v8

#7080 make_constructor Does Not Initialize base_wrapper new rwgk Bugs To Be Determined Python

Reported by team@…, 22 months ago.

Description

When binding a shared_ptr to Python, we're using a custom allocator defined using make_constructor:

class_< Controller, shared_ptr<Controller>, boost::noncopyable >("Controller", no_init)
            .def("__init__", boost::python::make_constructor(&Controller::make));

This works as expected except when classes are derived in Python. In those cases, get_override does not work, since m_self is NULL. If you use init<>() in the class_ constructor, instead of the make_constructor line, it works as expected.

The bug is that make_constructor does not initialize the base_wrapper. I've tried a fix as follows, and it's now functional -- though I can't say if this is a good way to solve it.

+++ make_constructor.hpp
@@ -59,6 +59,7 @@
           void* memory = holder::allocate(this->m_self, offsetof(instance_t, storage), sizeof(holder));
           try {
               (new (memory) holder(x))->install(this->m_self);
+			  python::detail::initialize_wrapper(this->m_self, get_pointer(x));
           }
           catch(...) {
               holder::deallocate(this->m_self, memory);

It's also possible to fix this by partially specializing "template <typename T> struct install_holder;" before boost::python is included.

#7085 Boost pool library it not header only as claimed in documentation new cnewbold Bugs To Be Determined pool

Reported by Roger Pawlowski <rppawlo@…>, 22 months ago.

Description

Hi,

I have been trying to use the bool pool library out of the current release 1.50.0. The documentation page claims the library is header only, but it pulls in the threads library which is not header only. You can reproduce this with the code:

#include <boost/pool/pool_alloc.hpp>

int main () {

return 0;

}

I get the following error on gnu 4.3.5 compilers:

Linking CXX executable Panzer_roger_junk.exe CMakeFiles/Panzer_roger_junk.dir/roger.cpp.o: In function `static_initialization_and_destruction_0': /home/rppawlo/install_boost_1_50_0/include/boost/system/error_code.hpp:214: undefined reference to `boost::system::generic_category()' /home/rppawlo/install_boost_1_50_0/include/boost/system/error_code.hpp:215: undefined reference to `boost::system::generic_category()' /home/rppawlo/install_boost_1_50_0/include/boost/system/error_code.hpp:216: undefined reference to `boost::system::system_category()' collect2: ld returned 1 exit status

The issue is that <boost/pool/pool_alloc.hpp> includes <boost/pool/poolfwd.hpp> which includes <boost/pool/detail/mutex.hpp> which includes <boost/thread/mutex.hpp> which includes <boost/thread/pthread/mutex.hpp> which includes <boost/thread/exceptions.hpp>

The <boost/thread/exceptions.hpp> directly uses the boost system library which is not header only.

#7088 Error with property_tree new cornedbee Bugs To Be Determined property_tree

Reported by dix75@…, 22 months ago.

Description

json {

cool : hp?

}

I have Simple example: typedef boost::property_tree::basic_ptree< string_t, string_t > ptree; boost::property_tree::json_parser::read_json("path_out", pt); ptree pt;

auto result = pt.get_child(_T("cool")); result.add(_T(" "), _T("33333"));

std::for_each(result.begin(), result.end(), [&](ptree::value_type const& val) {

std::wcout << val.first << _T(" ") << val.second.data() << std::endl;

});

pt.put_child(_T("cool"), result); boost::property_tree::json_parser::write_json("path_out", pt);

i have:

json {

cool :

{

"": "hp", " ": "33333"

}

}

Why. I need array

#7092 Fix odd workarounds for function object in for_each_pixel new hljin Bugs To Be Determined GIL

Reported by Nana Sakisaka <n.sakisaka@…>, 22 months ago.

Description

Current implementation for for_each_pixel is somehow re-assigning the functor to its own variable.

This becomes a serious problem when using a C++11 lambda-expression for the functor.

Since the copy assignment operator for lambda-expressions is declared deleted by the standards, this makes it unable to pass lambda-expression for the functor of for_each_pixel. Obviously this is a serious problem for writing C++11 style codes.

See attached patch for suggested workaround.

#7098 CRC: Initial values should not be reflected new dlwalker Bugs To Be Determined crc

Reported by Dave Vasilevsky <dave@…>, 22 months ago.

Description

The CRC classes have a parameter 'ReflectIn?', which affects whether the message data is reflected. It also causes the initial remainder of the CRC to be reflected, and that's probably incorrect. This has likely remained undetected 'til now because all the included presets use bit-palindromic initial remainders.

LVM2 uses a non-palindromic initial remainder, so I've used its code for a test case. You can see that both LVM's calc_crc() and zlib's crc32() don't reflect the initial remainder. It's evident that boost's crc does, and that no obvious change in template parameters yields the same behaviour as LVM and zlib.

Tested in both clang++ 3.1 and g++ 4.2.

#7101 b2 defines multiple isysroot on Mac OSX 10.6 when targeting SDK versions earlier than 10.6 new vladimir_prus Bugs To Be Determined build

Reported by mikko.vainio@…, 22 months ago.

Description

Building Boost 1.50.0 on Mac OSX 10.6 included multiple SDK versions when targeting SDK versions 10.5 adn/or 10.4;

./b2 toolset=darwin link=static threading=multi stage --with-program_options architecture=combined macosx-version=10.5 macosx-version-min=10.5 -d3

produces

"g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -gdwarf-2 -fexceptions -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.5 -arch i386 -arch ppc -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/program_options/build/darwin-4.2.1/release/architecture-combined/link-static/macosx-version-min-10.5/macosx-version-10.5/threading-multi/cmdline.o" "libs/program_options/src/cmdline.cpp"

and targeting 10.4 SDK

./b2 toolset=darwin link=static threading=multi stage --with-program_options architecture=combined macosx-version=10.4 macosx-version-min=10.4 -d3

produces

"g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -gdwarf-2 -fexceptions -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.4 -arch i386 -arch ppc -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/program_options/build/darwin-4.2.1/release/architecture-combined/link-static/macosx-version-min-10.4/macosx-version-10.4/threading-multi/cmdline.o" "libs/program_options/src/cmdline.cpp"

that is, isysroot is defined multiple times. That apparently causes the latest SDK to be used, which leads to linker errors when a project built against an earlier SDK tries to link Boost.

A quick workaround is to hide the later SDK from b2:

sudo mv /Developer/SDKs/MacOSX10.6.sdk /Developer/SDKs/bak.MacOSX10.6.sdk

then run b2 as usual, and finally revert the renaming of the SDK

sudo mv /Developer/SDKs/bak.MacOSX10.6.sdk /Developer/SDKs/MacOSX10.6.sdk
#7102 typo in documantation of boost::program_options::basic_command_line_parser new vladimir_prus Bugs To Be Determined program_options

Reported by bnagaev@…, 22 months ago.

Description

Typo in "creating overloads with a smaller nuber of parameters".

http://www.boost.org/doc/libs/1_50_0/doc/html/boost/program_options/basic_command_line_parser.html

#7106 multi_array::resize switches to default-constructed allocator new garcia Bugs To Be Determined multi_array

Reported by bmerry@…, 22 months ago.

Description

I've run into this with 1.46 but eyeballing the code on trunk it doesn't seem to have changed.

The implementation of resize starts like this:

    // build a multi_array with the specs given
    multi_array new_array(ranges,this->storage_order());

However, no allocator is passed to this constructor. If *this has a non-default allocator, then it will not get used to allocate the resized storage, and furthermore, the default allocator in new_array will get swapped in to *this, wiping out the custom allocator.

This can be fixed by changing this line to

    multi_array new_array(ranges,this->storage_order(),allocator_);

so that the new array uses the same allocator as the current one.

I'll attach a test case that demonstrates the issue by using an allocator class where instances are named and report the allocations they make (I'm using a more complex version of this to track memory usage, which is where I hit the bug). It currently reports

Allocated 17 bytes [name = vector]
Allocated 0 bytes [name = multi_array]
Allocated 15 bytes [name = default]

but with the fix applied it reports

Allocated 17 bytes [name = vector]
Allocated 0 bytes [name = multi_array]
Allocated 15 bytes [name = multi_array]

It is the final line where the resize is taking place.

#7118 Condition.Wait with a mutex instead of lock can be mysterious new igaztanaga Bugs To Be Determined interprocess

Reported by Trey Van Riper <fleeb.fantastique@…>, 22 months ago.

Description

This code correctly fails to compile: #include <boost/interprocess/sync/named_condition.hpp> #include <boost/interprocess/sync/named_mutex.hpp>

int _tmain(int argc, _TCHAR* argv[]) {

boost::interprocess::named_mutex mutex( boost::interprocess::open_or_create, "test" ); boost::interprocess::named_condition condition( boost::interprocess::open_or_create, "test" ); condition.wait( mutex ); return 0;

}

The resulting compile error (at least on VC++ 2010) is a tad mysterious:

1>c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204): error C2248: 'boost::interprocess::interprocess_mutex::mutex' : cannot access private member declared in class 'boost::interprocess::interprocess_mutex' 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\interprocess_mutex.hpp(117) : see declaration of 'boost::interprocess::interprocess_mutex::mutex' 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\interprocess_mutex.hpp(67) : see declaration of 'boost::interprocess::interprocess_mutex' 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204) : while compiling class template member function 'boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>::mutex_type *boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>::mutex(void) const' 1> with 1> [ 1> Lock=boost::interprocess::named_mutex 1> ] 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(342) : see reference to class template instantiation 'boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>' being compiled 1> with 1> [ 1> Lock=boost::interprocess::named_mutex 1> ] 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\named_condition.hpp(156) : see reference to function template instantiation 'void boost::interprocess::ipcdetail::shm_named_condition::wait<L>(L &)' being compiled 1> with 1> [ 1> L=boost::interprocess::named_mutex 1> ] 1> c:\code\projects\testinterprocess\testinterprocess\testinterprocess.cpp(10) : see reference to function template instantiation 'void boost::interprocess::named_condition::wait<boost::interprocess::named_mutex>(L &)' being compiled 1> with 1> [ 1> L=boost::interprocess::named_mutex 1> ] 1>c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204): error C2064: term does not evaluate to a function taking 0 arguments

It is not obvious that the problem involves the use of a Mutex instead of a ScopedLock? or the like. While the example code makes this clear, if you examine only the documentation, this detail might be confusing.

Recommend adding a concept check to help guide someone towards using a lock instead of a mutex.

#7120 ambiguous overload of convert_construct in variant when one of variant's value types derives from variant new ebf Bugs To Be Determined variant

Reported by jeffrey.hellrung, 22 months ago.

Description

#include <boost/variant.hpp>

struct X

: boost::variant< int >

{ };

void main() {

X x; boost::variant<X> y(x);

}

yields (MSVC9)

1>------ Build started: Project: scratch, Configuration: Debug Win32 ------ 1>Compiling... 1>main.cpp 1>c:\users\jeffrey\boost_1_49_0\boost\variant\variant.hpp(1405) : error C2666: 'boost::variant<T0_>::convert_construct' : 3 overloads have similar conversions 1> with 1> [ 1> T0_=X 1> ] 1> c:\users\jeffrey\boost_1_49_0\boost\variant\variant.hpp(1384): could be 'void boost::variant<T0_>::convert_construct<int,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>(const boost::variant<int> &,long)' 1> with 1> [ 1> T0_=X 1> ] 1> c:\users\jeffrey\boost_1_49_0\boost\variant\variant.hpp(1375): or 'void boost::variant<T0_>::convert_construct<int,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_,boost::detail::variant::void_>(boost::variant<int> &,long)' 1> with 1> [ 1> T0_=X 1> ] 1> c:\users\jeffrey\boost_1_49_0\boost\variant\variant.hpp(1315): or 'void boost::variant<T0_>::convert_construct<T>(T &,int,boost::mpl::false_)' 1> with 1> [ 1> T0_=X, 1> T=X 1> ] 1> while trying to match the argument list '(X, long)' 1> c:\users\jeffrey\scratch\main.cpp(10) : see reference to function template instantiation 'boost::variant<T0_>::variant<X>(T &)' being compiled 1> with 1> [ 1> T0_=X, 1> T=X 1> ]

Basically, the problem appears to be the call to

convert_construct(operand, 1L) operand is of type X

which cannot disambiguate between the overloads (simplified)

void convert_construct([const] boost::variant<T>& operand, long); void convert_construct(T& operand, int);

The former requires a derived->base conversion in the first argument, while the latter requires a long->int conversion in the second argument. Perhaps the dispatching among the convert_construct overloads should be more sophisticated?

#7126 function is_separator and boost::filesystem::slash<boost::filesystem::path>::value move to main hpp file new bemandawes Bugs To Be Determined filesystem

Reported by topilski@…, 22 months ago.

Description

Please add support get native path separator in main path.hpp header file, because this function now is inaccesible, and error appears (# error Compiling Filesystem version 2 file with BOOST_FILESYSTEM_VERSION defined != 2), this reprodused on boost 1.47 version

#7136 Correct documentation for BOOST_<level>_CLOSE_FRACTION is not reflected into released documents assigned renficiaud Bugs To Be Determined test

Reported by Yasutaka ATARASHI <atara-y@…>, 22 months ago.

Description

#3964 pointed out that documentation for BOOST_<level>_CLOSE_FRACTION is incorrect for unit of third parameter. The ticket was closed because trunk was fixed. However, after more than 2 years, the description in released document is still not changed: http://www.boost.org/doc/libs/1_50_0/libs/test/doc/html/utf/testing-tools/reference.html

Timestamp of the corresponding file in released boost_1_50_0.7z is 08/07/27 16:04:04. Therefore, release procedure or build procedure might be wrong, missing to update document.

#7138 Output of a UDT with autoprefix requires specialization of auto_prefix_norm new steven_watanabe Bugs Boost 1.51.0 units

Reported by pbristow, 22 months ago.

Description

Output of a UDT with autoprefix requires specialization of auto_prefix_norm for the scaling to take place. For example, to get expected scaling to kilometers from

quantity<length, measurement<double> > biglen(measurement<double>(12345.0,123.0)*meters); autoscaled = 12.345(+/-0.123) km

This can be achieved by adding this to measurement.hpp (where Y is the type of UDT)

// Specialization of autoprefix_norm for UDTboost::units::measurement<Y>
// See io.hpp.
// This specialization is required to get autoprefix to work with this class.

template<class Y>
typename autoprefix_norm_impl<boost::units::measurement<Y>, true>::type
autoprefix_norm(const boost::units::measurement<Y> & arg)
{
  return autoprefix_norm_impl<Y, true>::call(arg);
}

However this assumes that the class Y is convertible to double. autoprefix_norm_impl<T, true>::type appears to be always double. I am unclear if this is checked or is the responsibility or the user?

#7145 rational.hpp - Avoid repeated construction new turkanis Bugs To Be Determined rational

Reported by Dan Searles <dansearles@…>, 21 months ago.

Description

In rational.hpp, two times 'IntType? zero(0);' is used to "Avoid repeated construction" and two times 'int_type const zero( 0 );' is used. The two without the const may not be avoiding repeated construction. Since int_type is just a typedef from IntType?, it might be clearer if all int_type were replaced with IntType? and the typedef for int_type removed.

#7147 Pool in more depth documentation page has broken image links new cnewbold Bugs To Be Determined pool

Reported by scott@…, 21 months ago.

Description

If you navigate via browser to

http://www.boost.org/doc/libs/1_50_0/libs/pool/doc/html/boost_pool/pool/pooling.html

You will see several broken links to images, such as

http://www.boost.org/doc/libs/1_50_0/libs/pool/doc/images/pc1.png

The directory http://www.boost.org/doc/libs/1_50_0/libs/pool/doc/images/ is readable, and appears to contain the right files, but with differently-cased names (e.g. pc1.PNG).

I tried this with both Internet Explorer on Windows, and Chrome on Mac and Windows.

#7149 system failed to compile with BOOST_NO_EXCEPTIONS defined when -fno-exceptions is NOT used reopened bemandawes Bugs To Be Determined system

Reported by joeriedel@…, 21 months ago.

Description

This no longer compiles on mac osx GCC 4 with BOOST_NO_EXCEPTIONS defined but without -fno-exceptions. BOOST_NO_EXCEPTIONS can be used to simply disable exception handling in boost not necessarily to flag that exception handling is disabled at the compiler level:

http://www.boost.org/doc/libs/1_36_0/libs/utility/throw_exception.html

BOOST_NO_EXCEPTION can be used to supply a custom exception handler.

Wrapping the try block on line 136 on system/error_code.cpp with #ifndef BOOST_NO_EXCEPTIONS fixes this.

See ticket #2098

#7160 BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG and DATE_TIME_NO_DEFAULT_CONSTRUCTOR new az_sw_dude Bugs To Be Determined date_time

Reported by Ricky Stoneback <rwstoneback@…>, 21 months ago.

Description

I think I found a couple issues that are somewhat related to one another:

Issue 1 - Defining BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG and using the ptime default constructor along with a thread causes runtime crash

Steps to reproduce:

  1. Define BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG (to use nanosecond resolution in a posix_time) in the pre-processor definitions (VS2008).
  2. Create a boost::posix_time::ptime using the default constructor.
  3. Create a boost::thread and call join.

Example:

#include <iostream>
#include <boost/thread.hpp>

class ThreadClass
{
   public:
	ThreadClass()
	{
	}

	void operator()()
	{
	   return;
	}
};


int main()
{
	boost::posix_time::ptime currentTimeUTC;

	ThreadClass tc;
	boost::thread t(tc);
	t.join(); //causes a runtime access violation here

	std::cout << "done" << std::endl;
	system("pause");

	return 0;
}

Issue 2 - defining DATE_TIME_NO_DEFAULT_CONSTRUCTOR causes compile-time error "no appropriate default constructor available"

In Issue 1 above, if you do not use a default constructor for a ptime, it seems to fix the issue. So I figured that was fine and I could prevent a user of my library from using that default constructor by defining DATE_TIME_NO_DEFAULT_CONSTRUCTOR. However, this now breaks at compile time:

Steps to reproduce:

  1. Use the same code as above, just for ease of use.
  2. Define the pre-processor definition: DATE_TIME_NO_DEFAULT_CONSTRUCTOR.
  3. Compile the program.
  4. The following error is produced: error C2512: 'boost::posix_time::ptime' : no appropriate default constructor available e:\libraries\boost\boost_1_47\boost\thread\win32\thread_data.hpp 145

The issue, I believe, is that I am using a boost thread, which uses a ptime default constructor in its explicit timeout(sentinal_type) constructor when it doesn't set the abs_time member variable.

I am using Boost 1.47, however looking at the latest boost code (1.51), I don't see any fixes for these issues that stand out (I am not able to try the latest versions of Boost, so I apologize if they are fixed, but I would think that they are not)

#7161 Spirit.Classic with Boost.Thread v3 may fail compilation new djowel Bugs To Be Determined spirit

Reported by Kohei Takahashi <flast@…>, 21 months ago.

Description

Boost.Thread v3 may not provide the BOOST_ONCE_INIT. see http://www.boost.org/doc/libs/1_50_0/doc/html/thread/synchronization.html#thread.synchronization.once.once_flag

So, Spirit.Classic depends this behavior with BOOST_THREAD_VERSION=3, and may fail compilation.

I attached the patch for this issues.

#7165 cannot change BOOST_PHOENIX_LIMIT new theller Bugs To Be Determined phoenix

Reported by m.champlon@…, 21 months ago.

Description

Hi !

The following code :

#define BOOST_PHOENIX_LIMIT 20 #include <boost/phoenix.hpp>

fails to compile with boost 1.50 and msvc 2010 with an error trace starting with :

1>C:\dev\include\boost/phoenix/core/preprocessed/actor_30.hpp(10): error C2977: 'boost::proto::and_' : too many template arguments 1> C:\dev\include\boost/proto/matches.hpp(784) : see declaration of 'boost::proto::and_'

The following compiles :

#define BOOST_PHOENIX_LIMIT 20 #define BOOST_PROTO_MAX_LOGICAL_ARITY 20 #include <boost/phoenix.hpp>

In  http://boost.2283326.n4.nabble.com/phoenix-not-playing-nice-with-other-libs-td3489758.html Eric Niebler seems to suggest that proto::and_ should be split and nested to avoid having to change BOOST_PROTO_MAX_LOGICAL_ARITY, wouldn't that solve the issue ?

Thanks, MAT.

#7166 Phoenix unconditionally sets BOOST_PROTO_MAX_ARITY new theller Bugs To Be Determined phoenix

Reported by m.champlon@…, 21 months ago.

Description

Hi,

The following :

#define BOOST_PROTO_MAX_ARITY 20
#include <boost/phoenix.hpp>

exhibits the following warning with msvc 2010 and boost 1.50 :

1>C:\dev\include\boost/phoenix/core/limits.hpp(19): warning C4005: 'BOOST_PROTO_MAX_ARITY' : macro redefinition

This is rather inconvenient for the user of several libraries. I suggest to modify limits.hpp to change :

#if defined(BOOST_PHOENIX_LIMIT)
#define BOOST_PROTO_MAX_ARITY BOOST_PHOENIX_LIMIT

to :

 #if defined(BOOST_PHOENIX_LIMIT)
# if !defined( BOOST_PROTO_MAX_ARITY )
#  define BOOST_PROTO_MAX_ARITY BOOST_PHOENIX_LIMIT
# elif (BOOST_PROTO_MAX_ARITY < BOOST_PHOENIX_LIMIT)
#  error "BOOST_PROTO_MAX_ARITY is set too low"
# endif

or see the attached patch.

Thanks, MAT.

#7176 Infinite loop in regex.replace rule. new vladimir_prus Bugs To Be Determined build

Reported by Dmitriy Kinoshenko <dvb.kharkov@…>, 21 months ago.

Description

regex.replace falls into infinite "while $(parts)" loop if "match" parameter is empty string. Example:

import regex ;

str = blabla ; from = "" ; to = ":" ; res = [ regex.replace $(str) $(from) $(to) ] ; ECHO res: ; ECHO $(res) ;

#7178 [mc] Message compiler toolset broken new vladimir_prus Bugs To Be Determined build

Reported by andysem, 21 months ago.

Description

For some reason, the resource compiler no longer waits for the message compiler output. This results in compilation failures like this:

msvc.compile.mc bin.v2\libs\log\build\msvc-10.0\release\debug-symbols-on\threading-multi\simple_event_log.h
MC: Compiling libs\log\src\simple_event_log.mc
...skipped <pbin.v2\libs\log\build\msvc-10.0\release\debug-symbols-on\threading-multi>simple_event_log_res.obj for lack of <pbin.v2\libs\log\build\msvc-10.0\release\debug-symbols-on\threading-multi-object(res-scanner)@4128>simple_event_log.rc...

This is a partial compilation log from  Boost.Log project. You can check out trunk or branches/v1 for testing.

After the (unsuccessful) compilation I can see simple_event_log.rc, simple_event_log.h and MSG00001.bin files in the output directory, so the problem is probably caused by resource compiler being invoked too soon.

The Boost.Log Jamfile was not changed for a long time with respect to the .mc compilation, an it worked some time ago. Unfortunately, I cannot tell when it stopped working.

#7181 'boost::phoenix::actor<Expr>' : default constructor could not be generated new theller Bugs To Be Determined phoenix

Reported by m.champlon@…, 21 months ago.

Description

Hi,

The following code :

#include <boost/phoenix/bind.hpp>

void f() {}
void g()
{
    boost::phoenix::bind( &f );
}

generates with msvc 2010 the following warnings :

1>C:\dev\include\boost/phoenix/core/actor.hpp(273): warning C4510: 'boost::phoenix::actor<Expr>' : default constructor could not be generated
1>          with
1>          [
1>              Expr=boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval,boost::proto::argsns_::list1<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<0,void,void (__cdecl *)(void)>>,0>>,1>
1>          ]
1>          ..\..\src\blablabla.cpp(15) : see reference to class template instantiation 'boost::phoenix::actor<Expr>' being compiled
1>          with
1>          [
1>              Expr=boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval,boost::proto::argsns_::list1<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<0,void,void (__cdecl *)(void)>>,0>>,1>
1>          ]
1>C:\dev\include\boost/phoenix/core/actor.hpp(273): warning C4610: struct 'boost::phoenix::actor<Expr>' can never be instantiated - user defined constructor required
1>          with
1>          [
1>              Expr=boost::proto::exprns_::basic_expr<boost::phoenix::detail::tag::function_eval,boost::proto::argsns_::list1<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,boost::proto::argsns_::term<boost::phoenix::detail::function_ptr<0,void,void (__cdecl *)(void)>>,0>>,1>
1>          ]
1>

I suppose one way to supress them would be to add them to the pragma disable at the top of phoenix/core/actor.hpp

Cheers,
MAT.

#7184 atomic_cas32() uses Linux-only compiler intrinsic new igaztanaga Bugs To Be Determined interprocess

Reported by jbaker@…, 21 months ago.

Description

atomic_cas32() incorrectly assumes _sync_val_compare_and_swap() intrinsic is available on any host OS using GCC4.1+ when, as of GCC4.4, it is only available on Linux. This renders it unportable.

Problem was observed on QNX Neutrino 6.5.0.

#7189 [gil] conflict between boost range and boost gil new hljin Bugs To Be Determined GIL

Reported by kaischroeder3@…, 21 months ago.

Description

The following does not compile because it cannot be resolved whether a call to boost::range::fill_n or std::fill_n is correct

#include <boost/array.hpp> #include <boost/gil/image_view.hpp> #include <boost/gil/image.hpp> #include <boost/gil/typedefs.hpp>

#include <boost/range/algorithm/fill_n.hpp>

namespace gil = boost::gil;

int main( int argc, char argv) {

gil::image<boost::array<float,2> > img;

std::fill( gil::view(img).begin(), gil::view(img).end(), boost::array<float,2>() );

}

Error:

[100%] Building CXX object CMakeFiles/test_misc.dir/test_misc.cpp.o In file included from /usr/include/boost/gil/image.hpp:29:0,

from /media/data2TB/data_win/Code/weavepattern/ActiveGrid/tests/test_misc.cpp:3:

/usr/include/boost/gil/algorithm.hpp: In function ‘void std::fill(boost::gil::iterator_from_2d<IL>, boost::gil::iterator_from_2d<IL>, const V&) [with IL = boost::gil::memory_based_2d_locator<boost::gil::memory_based_step_iterator<boost::array<float, 2ul>*> >, V = boost::array<float, 2ul>]’: /media/data2TB/data_win/Code/weavepattern/ActiveGrid/tests/test_misc.cpp:14:86: instantiated from here /usr/include/boost/gil/algorithm.hpp:382:13: error: call of overloaded ‘fill_n(boost::array<float, 2ul>*&, std::ptrdiff_t&, const boost::array<float, 2ul>&)’ is ambiguous /usr/include/boost/gil/algorithm.hpp:382:13: note: candidates are: /usr/include/c++/4.6/bits/stl_algobase.h:775:5: note: _OI std::fill_n(_OI, _Size, const _Tp&) [with _OI = boost::array<float, 2ul>*, _Size = long int, _Tp = boost::array<float, 2ul>] /usr/include/boost/range/algorithm/fill_n.hpp:31:22: note: ForwardRange?& boost::range::fill_n(ForwardRange?&, Size, const Value&) [with ForwardRange? = boost::array<float, 2ul>*, Size = long int, Value = boost::array<float, 2ul>] /usr/include/boost/range/algorithm/fill_n.hpp:41:28: note: const ForwardRange?& boost::range::fill_n(const ForwardRange?&, Size, const Value&) [with ForwardRange? = boost::array<float, 2ul>*, Size = long int, Value = boost::array<float, 2ul>] make[3]: * [CMakeFiles/test_misc.dir/test_misc.cpp.o] Error 1

#7195 Regression test svn checkout fails, retries aren't setup correctly new grafik Bugs To Be Determined Regression Testing

Reported by teeks99@…, 21 months ago.

Description

When a svn checkout fails, the script will attempt to retry the checkout. However, when it failed it left the directory structure in a state that requires a 'svn cleanup' before trying again. Thus the 5 tries that the script makes to keep going all fail (svn: E155004: Working copy 'C:\local\regression\boost' locked).

I need to manually run 'svn cleanup' on my directory before I can try running the regression tests again.

I've attached the windows terminal output.

#7202 filesystem: Function remove_all_aux() with an argument of type system::error_code& can throw exception in case of filesystem error new bemandawes Bugs To Be Determined filesystem

Reported by batsun@…, 21 months ago.

Description

Function remove_all_aux() calls non-exception safe fs::directory_iterator constructor (without argument of system::error_code& type).

For example, in case of free file descriptors lack in filesystem this constructor can throw an exception "Too many open files".

The better way is to use exception-safe overload of fs::directory_iterator constructor (with argument of system::error_code& type).

Possible fix is in attachment.

The issue is actual for any version from 1.47 to 1.50

#7211 path_locale destructor crashes when overloaded operator new and delete are present new bemandawes Bugs To Be Determined filesystem

Reported by Michel Lemay <flaming_mike_@…>, 21 months ago.

Description

path_locale is defined using this construct in path.cpp:

std::locale path_locale(std::locale(), new windows_file_codecvt);

Under the debugger of VC10/11, the destructor of std::locale calls free() for this facet pointer when refcount reaches 0.

I ackknowledge this is a bug in dinkumware implementation of the microsoft STL. See for mor information:

 http://connect.microsoft.com/VisualStudio/feedback/details/750951/std-locale-implementation-in-crt-assumes-all-facets-to-be-allocated-on-crt-heap-and-crashes-in-destructor-in-debug-mode-if-a-facet-was-allocated-by-a-custom-allocator

That said, I suggest a workaround made using only standard calls.

in v3/src/windows_file_codecvt.hpp, change the constructor to pass along default refcount:

explicit windows_file_codecvt(size_t refs = 0)

: std::codecvt<wchar_t, char, std::mbstate_t>(refs) {}

and in v3/src/path.cpp, define path_locale like this:

windows_file_codecvt windows_cvt_path_locale(1);

std::locale path_locale(std::locale(), &windows_cvt_path_locale);

#7216 qcc.jam file could use a minor update for ar new vladimir_prus Bugs To Be Determined build

Reported by steve.lemay@…, 21 months ago.

Description

The qcc.jam file is apparently intended for building on a QNX OS hosted target. It is common for the QNX source to be cross compiled on MS Windows and the default archive utility is not available. Would you please add a comment and alternate solution around line 220 like the following. This would probably save new Boost users from having to track down a solution to this in the future.

# Modify archive command for cross-compiling for QNX NTO using a MS Windows hosted environment (x86 target used as example). # ntox86-ar rc "$(<)" "$(>)"

#7219 boost::optional<int> gives strict alias warning on GCC 4.4.6, breaks at runtime new fcacciola Bugs To Be Determined optional

Reported by Tony.Astolfi@…, 21 months ago.

Description

Here is my test code:

#include <boost/optional.hpp>

struct my_type
{
#if 1 // change to 0 to see the problem disappear
    typedef boost::optional<int> value_type;
#else
    typedef boost::optional<int __attribute((__may_alias__))> value_type;
#endif

    value_type value_;

    void set (int value)
    {
        value_ = value;
    }
                
    value_type get ()
    {
        return value_;
    }

}; // class event

void testCase ()
{
    my_type a;
    a.set(4);
    bool const b = 4 == ( *a.get() );
    if( !b ) abort(); // will abort unless 'may_alias' attribute is added to 'int'
}

Here is my compile line:

g++ -c src/thread/unittest/test_gcc_bug.cpp -o ../../../derived/glnxa64/obj/deployment_server/foundation/util/src/thread/unittest/test_gcc_bug.o -MD -MF ../../../derived/glnxa64/obj/deployment_server/foundation/util/src/thread/unittest/test_gcc_bug.d -MP -MT ../../../derived/glnxa64/obj/deployment_server/foundation/util/src/thread/unittest/test_gcc_bug.o -I../../../src/include -I../../../derived/glnxa64/src/include -I../include -I../../include -I//mathworks/hub/3rdparty/R2013a/356881/glnxa64/boost/include -I//mathworks/hub/3rdparty/R2013a/356141/glnxa64/cpp11compat/include -I//mathworks/hub/3rdparty/R2013a/356141/glnxa64/cpp11compat/include -I//mathworks/hub/3rdparty/R2013a/350182/glnxa64/protobuf/include -I//mathworks/hub/3rdparty/R2013a/350182/glnxa64/tbb/include   -DBOOST_FILESYSTEM_VERSION=2 -DBOOST_ASIO_DISABLE_EVENTFD -DBOOST_ASIO_DISABLE_EPOLL    -DTBB_AVAILABLE -O2 -pipe -pthread -fPIC -std=c++98 -fvisibility=hidden -g -D_POSIX_C_SOURCE=199506L -fno-omit-frame-pointer -DNDEBUG -W -Wcast-align -Wall -Wwrite-strings -Wpointer-arith -Wcast-qual -Wno-unused -Woverloaded-virtual -Wnon-virtual-dtor -Wno-ignored-qualifiers

I was also able to work around it by changing the return type of certain optional_base<T> methods (i.e. get_impl()) to 'T attribute((may_alias))&' (or whatever the analogous pointer or reference type is).

#7229 g++ 4.0.2 ICE in boost/fusion/view/iterator_range.hpp assigned eric_niebler Bugs To Be Determined fusion

Reported by Luc J. Bourhis <luc_j_bourhis@…>, 21 months ago.

Description

~> g++ --version

g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)

Note: This is the latest update on Fedora Core 4 before it became unsupported.

~> cat ice.cpp

#include <boost/fusion/view/iterator_range.hpp> 

~> g++ -I/path/to/boost -c ice.cpp

/home/luc/Developer/cctbx/boost/boost/fusion/view/iterator_range/detail/segmented_iterator_range.hpp:407: internal compiler error: Segmentation fault

This is in trunk rev 79740. Git bisect found that trunk rev 73854 was the first bad commit (but with the ICE happening in a different Boost header though).

#7235 mapped_region not accepting size = 0 new igaztanaga Bugs To Be Determined interprocess

Reported by matthieu.dorier@…, 21 months ago.

Description

Since Linux 2.6.12, and on other platforms, mmap is supposed to fail if the specified "size" parameter is 0. This causes some problems in all the Boost.Interprocess library since pretty much all the high-level structures (managed_shared_memory, for instance) use mapped_region (thus mmap) with size = 0, usually when the object is created with the "open_only" flag.

I have observed this bug on BlueGene?/P's CNK environment, with gcc 4.1.2. It seems logical to me that, when opening an existing shared structure, the size doesn't have to be known. I don't have any solution yet...

#7249 tools/build/v2/test/startup_v2.py fails if boost-build is already installed new vladimir_prus Bugs To Be Determined build

Reported by dev-zero@…, 20 months ago.

Description

I got the following error after I installed boost-build and tried to rerun the tests in temporary build directory:

startup_v2 : DIFFERENCE --- /var/tmp/paludis/dev-util-boost-build-1.50.0/temp/tmp7UjRdwexpected 2012-08-19 11:44:11.236819301 +0200 +++ /var/tmp/paludis/dev-util-boost-build-1.50.0/temp/tmpA2P_sAactual 2012-08-19 11:44:11.236819301 +0200 @@ -1,2 +1,3 @@ -Unable to load Boost\.Build: could not find "boost-build.jam" -.*Attempted search from .* up to the root \ No newline at end of file + +error: error: no Jamfile in current directory found, and no target references specified. + Unable to compute difference: diff -u /var/tmp/paludis/dev-util-boost-build-1.50.0/temp/tmp7UjRdwexpected /var/tmp/paludis/dev-util-boost-build-1.50.0/temp/tmpA2P_sAactual FAILED

Reason is: passing the empty string to bjam lets it fallback to the default which is not what is wanted in that test. Attached patch changes the path to something invalid.

#7252 bootstrap.sh only works if called as ./bootstrap.sh new vladimir_prus Bugs To Be Determined Building Boost

Reported by Júlio Hoffimann <julio.hoffimann@…>, 20 months ago.

Description

Sometimes we need to be able to call bootstrap.sh from outside the Boost root directory. The following tiny patch allows the bootstrap.sh script to be called from anywhere:

Replace the line 184:

my_dir="."

by

my_dir="${0%/bootstrap.sh}"

#7253 [Boost.Build] Escape command line properly when calling assembler on MSVC new vladimir_prus Bugs To Be Determined build

Reported by Pekka Seppänen <pekka.seppanen@…>, 20 months ago.

Description

Hi.

As of Boost.Context release (since Boost 1.51.0) assembler related build rules are actually used. However, currently these make no attempt whatsoever to properly escape the command line arguments (mostly global defines, that may have characters such as "<" and ">" that are interpreted by command prompt, not good).

The following patch proxies command line arguments thru a RSP file, as done with C/C++ compiling/build rules.

The patch does

a) Add an ASM_RSPLINE under rule get-rspline,

b) Add a rule compile.asm that calls get-rspline and compile-asm,

c) Move the actual assembler call under actions compile-asm, that uses the generated ASM_RSPLINE,

d) Remove toolset.flags msvc.compile.asm DEFINES as these are now inherited from toolset.flags msvc.compile DEFINES.

That should fix it once and for all.

#7256 wrong error message for program options with dashes new vladimir_prus Bugs To Be Determined program_options

Reported by thomas.zuhl@…, 20 months ago.

Description

Hi, I defined some options:

optionsDescription.add_options()
     ....
    ("output-file,o", program_options::value<std::string>(), "Result file")
     ....;

Now, when I start my program without an argument (e.g. ./myprog -o) the error message says:

the required argument for option '--file' is missing

instead of

the required argument for option '--output-file' is missing

This worked at least with version 1.48.

#7257 Boost.Test alters and does not restore ostream precision after any Test macro new rogeeff Bugs To Be Determined test

Reported by pbristow, 20 months ago.

Description

Boost.Test alters and does not restore ostream precision after any Test macro.

std::cout.precision(17);

std::streamsize precision1 = std::cout.precision(); 17

BOOST_TEST_MESSAGE(""); or any BOOST_TEST_* calls.

std::streamsize precision2 = std::cout.precision(); 6 (default)

BOOST_CHECK_EQUAL(precision1, precision2); expect both 17

This means that it is necessary to reset precision after every call to a BOOST_TEST_* macro, which is a tiresome and unexpected feature.

#7258 boost::filesystem::create_directories(const &path) returns false if the path contains a slash at the end of the string new bemandawes Bugs To Be Determined filesystem

Reported by francis.thibault@…, 20 months ago.

Description

for example, if we want to create that following directory: path="C:/users/test/"

the function create_directories(path) returns false even if the directory is created and exists.

However, if we remove the slash at the end of the string path="C:/users/test", the function returns true.

Is it the normal behavior of that function?

Thanks.

#7260 Header order conflicts between Thread and ASIO new chris_kohlhoff Bugs To Be Determined asio

Reported by joshuadavidson@…, 20 months ago.

Description

This problem is still present as of 1.50. Link to discussion:  http://lists.boost.org/boost-users/2012/06/74823.php

Consider this following simple app:

#include <boost/thread/thread.hpp>

#include <boost/asio.hpp>

#include <boost/thread/recursive_mutex.hpp>

 

 

int main() {

 

                return 0;

}

If you try to build that on Windows, you receive the following error:

In file included from c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/recursive_mutex.hpp:14:0,

                 from c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/recursive_mutex.hpp:14,

                 from build.cpp:3:

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'void boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::lock()':

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:52:21: error: '_InterlockedExchange' is not a member of 'boost::detail'

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'void boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::unlock()':

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:71:21: error: '_InterlockedExchange' is not a member of 'boost::detail'

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'bool boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::try_basic_lock(long int)':

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:91:21: error: '_InterlockedExchange' is not a member of 'boost::detail'

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp: In member function 'bool boost::detail::basic_recursive_mutex_impl<underlying_mutex_type>::try_timed_lock(long int, const boost::system_time&)':

c:/mingw/lib/gcc/../../x86_64-w64-mingw32/include/boost/thread/win32/basic_recursive_mutex.hpp:102:21: error: '_InterlockedExchange' is not a member of 'boost::detail'

If asio.hpp is moved ahead of the thread headers, the error goes away. We’ve been trying to dictate #include order to work around this problem, but it keeps cropping up.

#7261 Boost.Units quantity output overflows ostream width field new steven_watanabe Bugs To Be Determined units

Reported by pbristow, 20 months ago.

Description

Boost.Units quantity output overflows ostream width field

quantity<length> ql = 2345.6 * meters;

std::cout << std::setw(20) << ql << std::endl;

outputs 22 chars instead of 20 chars.

The reason is that the first item value() is output using the ios width setting, but the second unit() 'm' (and separating space) is not.

if os.width() > 0 then a way is to build a single string of the quantity with the width specified for example using an ostringstream (otherwise, outputing value and unit (perhaps autoprefixed to km) severally would overflow the width).

(else if os.width() <= 0 then output directly to ostream os as at present).

A test and a patch to deal with this is attached.

(This is not necessarily the most efficient way to deal with this but appears to work).

#7268 Invalid DST for Europe/Paris before 1996 (using tzdatabase) new az_sw_dude Bugs To Be Determined date_time

Reported by guillaume.v.sanchez@…, 20 months ago.

Description

Hello,

Let me start with an example : For 1992, boost::datetime gives me (using the given timezone database) DST period from 1992-Mar-29 02:00:00 TO 1992-Oct-25 03:00:00

That's simply wrong. For 1996 and following years, it's correct, simply because, in 1996, France decided that DST occurs in the end of October. Before that date, it occured in the end of September.

Here is a table of true DST dates (dates are in European form, "day/month") :

1976 : 28/3 -- 26/9
1977 : 3/4 -- 5/9
1978 : 2/4 -- 1/10
1979 : 1/4 -- 30/9 

1980 : 6/4 -- 28/9 
1981 : 29/3 -- 27/9 
1982 : 28/3 -- 26/9 
1983 : 27/3 -- 25/9 
1984 : 25/3 -- 30/9 
1985 : 31/3 -- 29/9 
1986 : 30/3 -- 28/9 
1987 : 29/3 -- 27/9 
1988 : 27/3 -- 25/9 
1989 : 26/3 -- 24/9

1990 : 25/3 -- 30/9
1991 : 31/3 -- 29/9 
1992 : 29/3 -- 27/9 
1993 : 28/3 -- 26/9 
1994 : 27/3 -- 25/9
1995 : 26/3 -- 24/9 

================

1996 : 31/3 -- 27/10 
1997 : 30/3 -- 26/10 
1998 : 29/3 -- 25/10
1999 : 28/3 -- 31/10

2000 : 26/3 -- 29/10
2001 : 25/3 -- 28/10
2002 : 31/3 -- 27/10
2003 : 30/3 -- 26/10
2004 : 28/3 -- 31/10
2005 : 27/3 -- 30/10
2006 : 26/3 -- 29/10
2007 : 25/3 -- 28/10
2008 : 30/3 -- 26/10 
2009 : 29/3 -- 25/10 

2010 : 28/3 -- 24/10 
2011 : 27/3 -- 30/10

Thank you, Guillaume

#7273 Files created by boost::iostreams::mapped_file have unexpected permissions on Linux new turkanis Bugs To Be Determined iostreams

Reported by Mika Fischer <mika.fischer@…>, 20 months ago.

Description

The mapped_file class opens the file unconditionally via:

::open(p.path.c_str(), flags, S_IRWXU);

Which sets the permissions to read, write, execute for the owner and no permissions for group or others.

This is quite unexpected, and since it cannot be changed by the caller, I think a more sane default behavior would be to just use the default of open and let the user's umask decide the permission of newly created files.

I.e. just remove the last parameter:

::open(p.path.c_str(), flags);
#7274 svn server error 413 new dgregor Bugs To Be Determined trac / subversion

Reported by bartus@…, 20 months ago.

Description

Hi!

I cant preform svn update, on day old copy, without geting this error message: svn: Server sent unexpected return value (413 Request Entity Too Large) in response to REPORT request for '/repository/!svn/vcc/default'

regard.bartus

#7275 SIGSEGV in boost::asio::connect when compiled with g++ -std=c++0x new chris_kohlhoff Bugs To Be Determined asio

Reported by Alan Yuelkenbeck <ayuelkenbeck@…>, 20 months ago.

Description

Works fine when not compiled with -std=c++0x. GCC v. 4.6.3 on ubuntu 12.04 Linking to static libboost_thread, libboost_system (1.50.0 release config) Does not matter if server code is listening or not.

Minimal reproducible code below:

int main(int argc, char *argv[]) {

boost::asio::io_service service;

using namespace boost::asio::ip;

tcp::resolver resolver(service); tcp::resolver::query query(tcp::v4(), "127.0.0.1", "50001"); tcp::resolver::iterator itr = resolver.resolve(query);

if (itr != tcp::resolver::iterator()) {

tcp::socket s(service); boost::asio::connect(s, itr); Segmentation Fault Here

}

}

Callstack:

#0 0x8054d6e boost::asio::detail::reactive_socket_service_base::close(this=0x16, impl=..., ec=...) (reactive_socket_service_base.ipp:103) #1 0x8058f1a boost::asio::stream_socket_service<boost::asio::ip::tcp>::close(this=0x2, impl=..., ec=...) (stream_socket_service.hpp:151) #2 0x80589d5 boost::asio::basic_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >::close(this=0xbffff318, ec=...) (basic_socket.hpp:339) #3 0x8058186 boost::asio::connect<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp>, boost::asio::ip::basic_resolver_iterator<boost::asio::ip::tcp>, boost::asio::detail::default_connect_condition>(s=..., begin=..., end=..., connect_condition=..., ec=...) (connect.hpp:120) #4 0x80578a5 boost::asio::connect<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp>, boost::asio::ip::basic_resolver_iterator<boost::asio::ip::tcp> >(s=..., begin=..., ec=...) (connect.hpp:56) #5 0x8056dd2 boost::asio::connect<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp>, boost::asio::ip::basic_resolver_iterator<boost::asio::ip::tcp> >(s=..., begin=...) (connect.hpp:47) #6 0x8052f41 main(argc=1, argv=0xbffff874) (main.cpp:27)

Thank you.

#7288 Under windows it is possible to use io_service::poll without a previous call to reset! new chris_kohlhoff Bugs To Be Determined asio

Reported by code.databyte@…, 20 months ago.

Description

I found out, that it is possible under windows to use io_service::poll without calling reset on the same service before.

Under Linux the internal variable "stopped_" is checked in the immplementation. The windows immplementation doesent do that, although the documentation says: "The poll() function runs handlers [...] until the io_service has been stopped [...]."

#7295 mapped_region large file throw exception new igaztanaga Bugs To Be Determined interprocess

Reported by anonymous, 20 months ago.

Description

using namespace boost::interprocess;

const std::size_t FileSize? = 10000000000; if(argc == 1) { Parent process executes this

{ Create a file

std::filebuf fbuf; fbuf.open("e:
output
file.bin", std::ios_base::in | std::ios_base::out

| std::ios_base::trunc | std::ios_base::binary);

Set the size fbuf.pubseekoff(FileSize?-1, std::ios_base::beg); fbuf.sputc(0);

} Remove file on exit struct file_remove {

~file_remove (){ file_mapping::remove("file.bin"); }

} destroy_on_exit;

Create a file mapping file_mapping m_file("e:
output
file.bin", read_write);

Map the whole file with read-write permissions in this process try{ mapped_region region(m_file, read_write);

Get the address of the mapped region void * addr = region.get_address(); std::size_t size = region.get_size();

Write all the memory to 1 std::memset(addr, 1, size); } catch( boost::interprocess::interprocess_exception& ex ){

cout << "\njjhhh" << ex.what() << endl;

} Launch child process std::string s(argv[0]); s += " child ";

if(0 != std::system(s.c_str()))

return 1;

}

mapped_region region(m_file, read_write); throw a exception

#7299 Spirit Karma static assert with unicode enabled on Win32 and Win64 new hkaiser Bugs To Be Determined spirit

Reported by Dave Bailey <David.Bailey@…>, 20 months ago.

Description

The following code causes a static assert in boost/spirit/home/karma/detail/output_iterator.hpp. The problem is that buffer_sink stores charactes in a std::basic_string<wchar_t>, but when BOOST_SPIRIT_UNICODE is defined, the output character size is 32-bit. On Windows, wchar_t is 16-bit, which will always hit the static assert. On Linux, wchar_t is 32-bit so we don't have the issue.

#ifndef BOOST_SPIRIT_UNICODE
#define BOOST_SPIRIT_UNICODE
#endif

#include <boost/config/warning_disable.hpp>
#include <boost/spirit/home/qi.hpp>
#include <boost/spirit/home/karma.hpp>
#include <string>

namespace karma = boost::spirit::karma;

template<typename OutputIterator>
struct unicode_char_
 : public karma::grammar<OutputIterator, ::boost::spirit::char_encoding::unicode::char_type()>
{
    unicode_char_() : base_type(thechar)
    {
        using karma::unicode::char_;
        thechar = char_;
    }
    karma::rule<OutputIterator, ::boost::spirit::char_encoding::unicode::char_type()> thechar;
};

int main()
{
    typedef std::basic_string<boost::spirit::char_encoding::unicode::char_type> unicode_string;
    typedef std::back_insert_iterator<unicode_string> unicode_back_insert_iterator_type;

    unicode_string input; 
    unicode_string output;

    unicode_back_insert_iterator_type insert_iter(output);

    unicode_char_<unicode_back_insert_iterator_type> unichar;

    karma::generate(insert_iter,unichar,input);

    return 0;
}

#7304 size of a fusion sequences is signed, should be unsigned new djowel Bugs To Be Determined fusion

Reported by mgaunard, 20 months ago.

Description

fusion::result_of::size< fusion::vector<int, int> >::type::value is signed, even though it should be size_t.

It appears the problem is two-fold:

  • fusion::result_of::size<T>::value is not the same type as fusion::result_of::size<T>::type::value_type
  • size of fusion::vector is defined to be a mpl::int_ (it also seems it is the case for all fusion sequences types!)

The fact that this is wrongly signed causes all sorts of warnings.

#7305 zip_view silently ignores elements new djowel Bugs To Be Determined fusion

Reported by mgaunard, 20 months ago.

Description

zip_view takes the minimum size of all the sequences it is given. As a result it may silently ignore elements, which is not desirable.

I think it would be better if it checked all sequences were the same size.

#7307 boost::filesystem::remove_all(dirname,ec) throws on write protected directories new bemandawes Bugs To Be Determined filesystem

Reported by bach@…, 20 months ago.

Description

Hi there,

according to the documentation, functions with error_code should not throw except if storage cannot be allocated.

The following throws if directory "bla" exists but is write protected:

  string bla("bla");
  boost::system::error_code ec;
  boost::filesystem::remove_all(bla,ec);

The bla directory looks like this:

ls -l bla
d--------- 2 bach bach     4096 2012-08-30 23:56 bla

Output of the program is:

terminate called after throwing an instance of "boost::filesystem::filesystem_error" what(): boost::filesystem::directory_iterator::construct: Permission denied: "bla" Aborted

System: Ubuntu 9.10 Boost: 1.50, looking through change notes for 1.51 I did not see any entries for filesystem which could address this.

Best,

Bastien

#7310 filesystem::path::iterator::operator+ is unusable due to compile error new bemandawes Bugs To Be Determined filesystem

Reported by Craig Dickson <cdickson@…>, 20 months ago.

Description

Boost 1.50, MS Visual Studio 2010. I find that if I attempt to use the + operator on a path::iterator, I get a compiler error saying that the method "advance" is not part of path::iterator. If I comment out my use of this operator, and instead use only ++, then everything compiles.

Here are the details from the compiler:

boost/iterator/iterator_facade.hpp(544): error C2039: 'advance' : is not a member of 'boost::filesystem::path::iterator'
    boost/filesystem/path.hpp(570) : see declaration of 'boost::filesystem::path::iterator'
    boost/iterator/iterator_facade.hpp(690) : see reference to function template instantiation 'void boost::iterator_core_access::advance<Derived>(Facade &,__w64 int)' being compiled
    with
    [
        Derived=boost::filesystem::path::iterator,
        Facade=boost::filesystem::path::iterator
    ]
    boost/iterator/iterator_facade.hpp(689) : while compiling class template member function 'boost::filesystem::path::iterator &boost::iterator_facade<Derived,Value,CategoryOrTraversal>::operator +=(__w64 int)'
    with
    [
        Derived=boost::filesystem::path::iterator,
        Value=const boost::filesystem::path,
        CategoryOrTraversal=boost::bidirectional_traversal_tag
    ]
    boost/filesystem/path.hpp(574) : see reference to class template instantiation 'boost::iterator_facade<Derived,Value,CategoryOrTraversal>' being compiled
    with
    [
        Derived=boost::filesystem::path::iterator,
        Value=const boost::filesystem::path,
        CategoryOrTraversal=boost::bidirectional_traversal_tag
    ]
#7313 filesystem reference doc shows path::u16string(), but it doesn't exist new bemandawes Bugs To Be Determined filesystem

Reported by Craig Dickson <cdickson@…>, 20 months ago.

Description

The Boost 1.50 filesystem reference says that filesystem::path has methods u16string(), generic_u16string(), u32string() and generic_u32string(), but they don't exist in the code. MS Visual Studio 2010's C++ compiler can't find them, and a grep of the boost::filesystem source doesn't find them either. Please either implement these methods or remove them from the docs.

(My preference would be that you implement these methods, and also, for completeness, add u8string() and generic_u8string(), which would return UTF-8 instead of using the current locale.)

#7315 A fusion adapted struct with a single member doesn't work with the Qi list operator new djowel Bugs To Be Determined spirit

Reported by vexocide, 20 months ago.

Description

As demonstrated in the attached file a fusion adapted struct with a single member doesn't work with the Qi list operator whereas its equivalent based on the kleen operator does work.

#7316 Build boost.python fails with python 3.2.3 new rwgk Bugs To Be Determined Python

Reported by Sergey Dmitriev <dmi3evsv@…>, 20 months ago.

Description
$ ./b2 -q -d+2 variant=release link=shared threading=multi runtime-link=shared  | grep err
libs/mpi/src/python/datatypes.cpp:20:33: error: ‘PyInt_Type’ was not declared in this scope
libs/mpi/src/python/py_environment.cpp:53:37: error: cannot convert ‘char**’ to ‘wchar_t**’ for argument ‘2’ to ‘void PySys_SetArgv(int, wchar_t**)’

$ uname -a
Linux asus 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

$ python3 --version
Python 3.2.3

$ echo "import sys; print( sys.prefix )" | python3
/usr

$  cat project-config.jam | grep python
using python : 3.2 : /usr ;
#7319 Take care of c++std-lib-32966 issue assigned viboes Bugs To Be Determined thread

Reported by viboes, 20 months ago.

Description

Take care of the issue raised by Howard Hinnant in

[c++std-lib-32966] Public service announcement concerning ~condition_variable_any()

"Both condition_variable and condition_variable_any are based on the POSIX pthread_cond_t. One of the very subtle behaviors of pthread_cond_t is that it is ok for a pthread_cond_t to be destroyed after all waiting threads have been signaled (assuming no new threads initiate a wait). There's even an example demonstrating this at  http://www.unix.org/online.html under the specification for pthread_cond_destroy.

This subtlety is reflected in the Requires clause for the destructor of both condition_variable and condition_variable_any:

Requires: There shall be no thread blocked on *this. [Note: That is, all threads shall have been notified; they may subsequently block on the lock specified in the wait. This relaxes the usual rules, which would have required all wait calls to happen before destruction. Only the notification to unblock the wait must happen before destruction. The user must take care to ensure that no threads wait on *this once the destructor has been started, especially when the waiting threads are calling the wait functions in a loop or using the overloads of wait, wait_for, or wait_until that take a predicate. — end note ]

To be *perfectly* clear, the following is ok:

  Thread A                    Thread B
   ...                        lk.lock()
   ...                        cv.wait(lk)
  lk.lock()                      ...
  cv.notify_one()                ...
  cv.~condition_variable_any()   ...
  lk.unlock()                    ...
    ...                       finally exits cv.wait  // ok, not a data race

"

#7320 Warnings "duplicate friend declaration" with Intel C++ Compiler XE 12.1.5.344 new emildotchevski Bugs To Be Determined exception

Reported by abrarov@…, 20 months ago.

Description

There are some warnings "duplicate friend declaration" with Intel C++ Compiler XE 12.1.5.344 at Windows (Windows 7 SP1 Pro) during building of programs using Boost.Exception:

1>..\..\..\..\boost_1_51_0\boost/exception/exception.hpp(258): warning #367: duplicate friend declaration
1>            friend struct exception_detail::get_info<throw_function>;
1>            ^
1>  
1>..\..\..\..\boost_1_51_0\boost/exception/exception.hpp(259): warning #367: duplicate friend declaration
1>            friend struct exception_detail::get_info<throw_file>;
1>            ^
1>  
1>..\..\..\..\boost_1_51_0\boost/exception/exception.hpp(260): warning #367: duplicate friend declaration
1>            friend struct exception_detail::get_info<throw_line>;
1>            ^

The warning level is Level4 (/W4).

#7332 Missing inline directives in crc.hpp new dlwalker Bugs To Be Determined crc

Reported by Sergey Fokin <drigh@…>, 20 months ago.

Description

see diff with fix

#7340 Visual studio iostreams warnings new turkanis Bugs To Be Determined iostreams

Reported by Alan Birtles <alan.birtles@…>, 20 months ago.

Description

Visual studio 2010 raises "conditional expression is constant" warnings from chain.hpp. This can be fixed by simply including the disable_warnings header in chain.hpp

Visual studio 2010 raises various "unreachable code" warnings. This can be fixed by adding warning 4702 in disable_warnings.hpp

Visual studio 2012 raises a "inherits via dominance" warning from stream.hpp (see  http://connect.microsoft.com/VisualStudio/feedback/details/733720/inheriting-from-std-fstream-produces-c4250-warning for the cause of this warning). This requires including the disable_warnings header in stream.hpp and adding warning 4250 to disable_warnings.

#7341 Vector subscript out of range exception when calling weighted_core_numbers reopened jewillco Bugs To Be Determined graph

Reported by Ian Robertson <irober67@…>, 20 months ago.

Description

I get a vector subscript out of range exception when calling the weighted_core_numbers function in the boost graph library. The exception is actually thrown from within the mutable_queue::update function, but I can't tell if the error is in mutable_queue or in weighted_core_numbers.

The attached test program is sufficient to show the problem. The test network is taken from Figure 1 of the Batagelj-Zaversnik paper ( http://vlado.fmf.uni-lj.si/pub/networks/doc/cores/cores.pdf), with random integer weights of 1, 2, or 3 added to each edge.

#7344 Free properties not available in conditional rule new vladimir_prus Bugs To Be Determined build

Reported by anonymous, 20 months ago.

Description

Free properties are not propagated to common-properties2 rule in targets.jam file. Rationale behind this is to optimise caching of already created property-set objects (exactly as stated in rule common-properties, which contains the call).

However, this optimisation causes that free features are not passed e.g. to user-defined rules used for evaluation of <conditional> properties (see example below in the second code listing).

Therefore I would propose to drop this optimisation and propagate also free properties (see code listing below). The other possible solution would be to just pass free properties to the common-properties2 rule and thus make them available to the algorithm, but this will introduce another bug (property-set object from cache will be used even though it contains values created from different free properties).

SOLUTION PROPOSAL

rule common-properties ( build-request requirements )
{
    local props = [ property-set.create
        [ $(requirements).base ]
        [ $(requirements).incidental ]
        [ $(requirements).free ]
    ] ;

    local key = .rp.$(build-request)-$(props) ;
    if ! $($(key))
    {           
        $(key) = [ common-properties2 $(build-request) $(props) ] ;        
    }        
    return $($(key)) ;
}

BUG REPRODUCTION

import feature ;


feature.feature define-prefix : : free ;

rule define-target-os ( properties * )
{
  local define-prefix = [ feature.get-values define-prefix : $(properties) ] ;
  define-prefix ?= "" ;
  local target-os = [ feature.get-values target-os : $(properties) ] ;
  return <define>$(define-prefix)TARGET_OS_$(target-os:U) ;
}


project /root
  : requirements
      <define-prefix>FOOBAR_
      <conditional>@define-target-os
;


exe hello
 : #sources
     hello.cpp
 : #requirements
;
#7353 no newline at end of file reopened djowel Bugs To Be Determined fusion

Reported by habdank@…, 20 months ago.

Description

Dears,

Some Boost packages causes flood of warnings "no newline at end of file" on gcc compiler.

As example:

Line 15773: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_fwd.hpp:21:7: warning: no newline at end of file
	Line 15788: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_fwd.hpp:21:7: warning: no newline at end of file
	Line 15800: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_fwd.hpp:21:7: warning: no newline at end of file
	Line 15815: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_fwd.hpp:21:7: warning: no newline at end of file
	Line 15830: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_fwd.hpp:21:7: warning: no newline at end of file
	Line 15845: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_fwd.hpp:21:7: warning: no newline at end of file
	Line 15860: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_fwd.hpp:21:7: warning: no newline at end of file
	Line 15875: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_fwd.hpp:21:7: warning: no newline at end of file
	Line 15931: ../../../../externals/boost/fusion/tuple/detail/preprocessed/make_tuple.hpp:21:7: warning: no newline at end of file
	Line 15945: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_tie.hpp:21:7: warning: In file included from ../../../../externals/boost/fusion/tuple/tuple_tie.hpp:18no newline at end of file
	Line 15959: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_tie.hpp:21:7: warning: no newline at end of file
	Line 15973: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple.hpp:21:7: warning: no newline at end of file
	Line 15987: ../../../../externals/boost/fusion/tuple/detail/preprocessed/make_tuple.hpp:21:7: warning: no newline at end of file
	Line 16001: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_tie.hpp:21:7: warning: no newline at end of file
	Line 16015: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple.hpp:21:7: warning: no newline at end of file
	Line 16029: ../../../../externals/boost/fusion/tuple/detail/preprocessed/make_tuple.hpp:21:7: warning: no newline at end of file
	Line 16043: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_tie.hpp:21:7: warning: no newline at end of file
	Line 16057: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple.hpp:21:7: warning: no newline at end of file
	Line 16071: ../../../../externals/boost/fusion/tuple/detail/preprocessed/make_tuple.hpp:21:7: warning: no newline at end of file
	Line 16085: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_tie.hpp:21:7: warning: no newline at end of file
	Line 16099: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple.hpp:21:7: warning: no newline at end of file
	Line 16113: ../../../../externals/boost/fusion/tuple/detail/preprocessed/make_tuple.hpp:21:7: warning: no newline at end of file
	Line 16127: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_tie.hpp:21:7: warning: no newline at end of file
	Line 16141: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple.hpp:21:7: warning: no newline at end of file
	Line 16155: ../../../../externals/boost/fusion/tuple/detail/preprocessed/make_tuple.hpp:21:7: warning: no newline at end of file
	Line 16169: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_tie.hpp:21:7: warning: no newline at end of file
	Line 16183: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple.hpp:21:7: warning: no newline at end of file
	Line 16197: ../../../../externals/boost/fusion/tuple/detail/preprocessed/make_tuple.hpp:21:7: warning: no newline at end of file
	Line 16211: ../../../../externals/boost/fusion/tuple/detail/preprocessed/tuple_tie.hpp:21:7: warning: no newline at end of file
#7356 program crashed when using phoenix::switch_,case<> with STL::for_each, using std::vector<int> as the container new theller Bugs To Be Determined phoenix

Reported by wqgg123@…, 20 months ago.

Description

Problem: the program is listed as bellow, complied with mingw32-gcc-4.6.2, enabling std++0x. The program is OK when running in debug model, but crashed in release mode. The error code is -1073741819.

#include <iostream> #include <vector> #include <algorithm> #include <boost/phoenix.hpp>

using namespace std; using namespace boost; using phoenix::placeholders::arg1;

int main() {

vector<int> vec = {1, 2, 3, 4, 5, 6, 7, 8, 9};

for_each(vec.begin(), vec.end(),

switch_(arg1) [

phoenix::case_<1>(cout << phoenix::val("One") << '\n'), phoenix::case_<2>(cout << phoenix::val("Two") << '\n'), phoenix::default_(cout << phoenix::val("other value") << '\n')

]);

return 0;

}

#7364 ambiguity error constructing std::vector from assign::list_of new nesotto Bugs To Be Determined assign

Reported by eric_niebler, 20 months ago.

Description

The problem is due to the addition of rvalue-reference container constructors. The following fails to compile with vc10:

#include <vector>
#include <boost/assign/list_of.hpp>

int main()
{
    std::vector<int> i(boost::assign::list_of(1));
}

The error is:

1>c:\boost\org\trunk\libs\proto\scratch\main.cpp(6): error C2668: 'std::vector<_Ty>::vector' : ambiguous call to overloaded function
1>          with
1>          [
1>              _Ty=int
1>          ]
1>          c:\program files (x86)\microsoft visual studio 10.0\vc\include\vector(593): could be 'std::vector<_Ty>::vector(std::vector<_Ty> &&)'
1>          with
1>          [
1>              _Ty=int
1>          ]
1>          c:\program files (x86)\microsoft visual studio 10.0\vc\include\vector(515): or       'std::vector<_Ty>::vector(unsigned int)'
1>          with
1>          [
1>              _Ty=int
1>          ]
1>          while trying to match the argument list '(boost::assign_detail::generic_list<T>)'
1>          with
1>          [
1>              T=int
1>          ]
1>
1>Build FAILED.
#7366 program_options/variables_map.hpp warning C4275 new vladimir_prus Bugs To Be Determined program_options

Reported by maciek.siemczyk@…, 20 months ago.

Description

When trying to build release version (debug version builds successfully) of our library with boost 1.49 I get the following warning:

1>d:\sb\EventEngine_trunk\outputs\intermediates\include\boost/program_options/variables_map.hpp(148) : warning C4275: non dll-interface class 'std::_Container_base_aux' used as base for dll-interface class 'std::_Container_base_aux_alloc_real<_Alloc>' 1> with 1> [ 1> _Alloc=std::allocator<std::pair<const std::string,boost::program_options::variable_value>> 1> ] 1> d:\Software\VS2008\VC\include\xutility(377) : see declaration of 'std::_Container_base_aux'

Our software has treat warnings as errors enabled so I have to resort to disabling that compiler warning in order to build. Are there any plans to address this?

#7369 grow() resets permissions new igaztanaga Bugs To Be Determined interprocess

Reported by Aaron Wright <Aaron_Wright@…>, 20 months ago.

Description

I need to create shared memory with unrestricted permissions (0666). This works fine. When I attempt to grow the shared memory, using the grow() function, the permissions get reset to 0644.

I followed the code a bit and saw that it was using ftruncate. Checking the man page for ftruncate reveals, "the set-user-ID and set-group-ID permission bits may be cleared." Not sure what affects the "may" clause, but it did it every time for me. Umask was set to 0000.

Obviously this only effects systems using ftruncate. Windows works correctly.

Not sure on what versions may be needed, but: libc6 - 2.11.1 libglib2.0 - 2.24.1 gcc - 4.4.3

#7371 boost::spirit::classic::char_parser<DerivedT>::parse is incrementing the scanner's first iterator directly instead of using the provided iterator_policy new djowel Bugs To Be Determined spirit

Reported by mhilferink@…, 20 months ago.

Description

In boost\spirit\home\classic\core\primitives\primitives.hpp

boost::spirit::classic::char_parser<DerivedT>::parse is defined to increment the scanner's first iterator directly instead of using the provided iterator_policy.

I'm using a scanner with an iterator that doesn't have a ++ operator and provided an iteration policy with redefined advance, get, and at_end methods.

This works fine if the following patch is implemented in boost\spirit\home\classic\core\primitives\primitives.hpp:

  if (!scan.at_end())
  {
      value_t ch = *scan;
      if (this->derived().test(ch))
      {
          iterator_t save(scan.first);
-         ++scan.first; 
+         ++scan; 
          return scan.create_match(1, ch, save, scan.first);
      }
  }

This patch forwards the increment request to scanner_policies<streamer_policy>::advance to let it do its thing with scan.first

I've seen this (and corrected it locally) at least in boost.sprit from boost version 1.40.0 and 1.51.0

Can somebody with RW access to boost.spirit implement this? Or tell me I should adapt my iterator objects directly.

I'm new to GIT and not a spirit developer, but I can try to make a git pull request if that is the way to send-in change requests.

#7377 Abort trap when using Program Options new vladimir_prus Bugs To Be Determined program_options

Reported by lordthistle@…, 20 months ago.

Description

Hello,

I tried to run the simple example provided on the web site at the following URL (file 'first'):

http://www.boost.org/doc/libs/1_51_0/doc/html/program_options/tutorial.html#id2547756

When I run: ./test_po a b c d e OR ./test_po --compression 1 there are no problems.

When I run ./test_po --compression ./test_po -compression ./test_po -a OR ./test_po -a 1 ./test_po -aa oR ./test_po --a 1 the program fails due to an abort trap.

This is my working environment:

  • boost 1.51.1
  • OS X 10.6.8
  • g++ i686-apple-darwin10-g++-4.2.1

Please let me know in case you need more info.

Regards

#7379 Boost Format strings causing memory leaks new samuel_krempp Bugs To Be Determined format

Reported by Jason Vincent <jason.vincent@…>, 20 months ago.

Description

I determined that certain format string used in a boost::wformat object will leak memory. I was using a formatter to convert a value to a floating point value with and without a percent symbol at the end.

The two format strings I was using were:

L"%1$.1f"
  • format with one decimal place of precision
L"%1$.0f %%"
  • format with no decimal places but add a percent sign

I determined that removing the "%%" reduced some of the memory leaks, and removing the "$.1f" or "$.0f" eliminated the remaining memory leaks.

This was done using Boost v 1.44 with Visual Studio 2010 on Win 7 64-bit.

For more context here is part of the code that I can share:

note, mFormatter is a boost::wformat member object

MyObject::MyObject() :
    mNumDecimalPlaces   (1),
    mFormatter          (L"%1$.1f")  //--- THIS LEAKED
{
}


std::wstring MyObject::PercentToString(const FLOAT iMin,
                                       const FLOAT iMax,
                                       const FLOAT iPercent)
{
    FLOAT value = PercentToValue(iMin, iMax, iPercent);

    return boost::str(mFormatter % value); //--- THIS LEAKED
}
#7385 Unused parameter causes compilation error new vladimir_prus Bugs To Be Determined program_options

Reported by lcarreon@…, 19 months ago.

Description

When the compiler is set to treat warnings as errors, the line #253:

virtual void set_option_name(const std::string& option_name) {}

in the file program_options/errors.hpp, causes a compilation error.

#7391 phoenix::insert compile fails with libc++ new theller Bugs To Be Determined phoenix

Reported by Naomasa Matsubayashi, 19 months ago.

Description

Following code produces a compile error with libc++.

#include <vector>
#include <boost/phoenix.hpp>

int main() {
  std::vector< int > hoge;
  std::vector< int > fuga;
  namespace phx = boost::phoenix;
  phx::insert( phx::placeholders::_1, phx::placeholders::_2, fuga.begin(), fuga.end() )( hoge, hoge.end() );
}

That is because phoenix::insert expects the member function insert returns void when was is called with 3 arguments. That is correct in C++03 but not in C++11.( All insert overloads returns an iterator in C++11 [23.3.7.1] )

Since libstdc++ returns void even if the code was compiled as C++11, the problem doesn't appear. But at least with libc++, it fails to compile and following error message is produced.

      void function 'operator()' should not return a value [-Wreturn-type]
                return c.insert(arg1, arg2, arg3);
                ^      ~~~~~~~~~~~~~~~~~~~~~~~~~~

This patch fixed the problem on libc++. I think it needs more intelligent way to detect environments those insert always return a iterator. But I don't have any good idea on that :(

--- boost/phoenix/stl/container/container.hpp
+++ boost/phoenix/stl/container/container.hpp
@@ -425,6 +425,9 @@
                 choice_1;
 
                 typedef
+#ifdef _LIBCPP_VERSION
+                    iterator_of<C>
+#else
                     boost::mpl::eval_if_c<
                         boost::mpl::and_<
                             boost::is_same<Arg3, mpl::void_>
@@ -433,8 +436,8 @@
                       , iterator_of<C>
                       , boost::mpl::identity<void>
                     >
+#endif
                 choice_2;
-
             public:
 
                 typedef typename
#7396 filesystem::path::remove_all(path, error_code) throws filesystem_error exception new bemandawes Bugs To Be Determined filesystem

Reported by Craig Dickson <cdickson@…>, 19 months ago.

Description

Several methods in filesystem::path, including remove_all, have an overload in which an extra error_code& argument is taken. According to the docs, this is supposed to cause failure (other than failure to allocate storage) to be reported in the error_code rather than as a thrown filesystem_error exception. However, remove_all can still throw filesystem_error exceptions because it uses a directory_iterator internally but makes no attempt to catch exceptions thrown by it. For example, if a subdirectory is deleted by another thread or process just before remove_all tries to list its contents, directory_iterator_construct will throw a filesystem_error that propagates up to remove_all's caller.

As a side note, I think path and directory_iterator are both excessively exception-happy. It makes them painful to use.

#7404 filesystem::canonical fails on UNC paths on Windows new bemandawes Bugs To Be Determined filesystem

Reported by Craig Dickson <cdickson@…>, 19 months ago.

Description

The filesystem library function canonical(p, base) fails for all UNC paths on Windows because it gets an "invalid path" error when it calls symlink_status at line 816 of operations.cpp. Example: For the path "server/share/file", the first time execution reaches line 816 of operations.cpp, it calls is_symlink(detail::symlink_status("server", ec)) and ec is set to the Windows "invalid path" system error code.

#7406 Documentation lists the wrong constructor for char_delimiters_separator new jsiek Bugs To Be Determined tokenizer

Reported by Therefore <therefore@…>, 19 months ago.

Description

http://www.boost.org/doc/libs/1_39_0/libs/tokenizer/char_delimiters_separator.htm

lists as the constructor:

explicit char_delimiters_separator(bool return_delims = false,
 const Char* returnable = "",const Char* nonreturnable = "" )

when it is in fact:

explicit char_delimiters_separator(bool return_delims = false,
   const Char* returnable = 0,const Char* nonreturnable = 0)

from token_functions.hpp

#7419 Support multiple calls to framework::init() allowing wrappers to support running tests using test tools in full systems new rogeeff Bugs To Be Determined test

Reported by Jamie Allsop <ja11sop@…>, 19 months ago.

Description

Boost.Test is designed on the assumption that a special main() function will be provided to ensure the test framework is initialised properly and that the function needed to add test suites for execution is properly provided. This works well for simple test programs.

However another important use case we have and I'm sure others too is that we also wish to run our production systems 'as-if' in production but have tests execute when run in a 'testing' mode.

This has the benefit of allowing full use of all the Boost.Test tool facilities and makes test points easily recognisable. Additionally it also means the test out analysis tools that we use for Boost.Test in our unit testing can be used without modification. Hence on a coding level we use the same test code as for unit tests and we then benefit from being able to directly interpret the results, just as we do for normal unit tests.

In order to support this within the Boost.Test framework (we use the unit-test framework for this as we simply require access to the tools and reporting facilities) we must make it possible to write a test runner wrapper than can ultimately call boost::unit_test::framework::init() more than once.

A minimal test runner class might look like this (taken from a real code but stripped down so will not work as is):

namespace test {

class runner
{
public:

    using master_test_suite_t  = boost::unit_test::master_test_suite_t;
    using test_suite_t         = boost::unit_test::test_suite;
    using call_add_tests_t     = boost::function<void( master_test_suite_t& )>;

public:

    static
    void store_properties( /* properties from commandline or config file */ )
    {
        auto& Runner = instance();
        Runner.store_arguments( /* properties */ );
    }

    static
    int run( const std::string& Title, const call_add_tests_t& Callback )
    {
        auto& Runner = instance();

        Runner.set_title( Title );
        Runner.set_add_tests_callback( Callback );

#ifdef BOOST_TEST_ALTERNATIVE_INIT_API
        boost::unit_test::init_unit_test_func init_func = &runner::init_unit_test;
#else
        boost::unit_test::init_unit_test_func init_func = &runner::init_unit_test_suite;
#endif
        return boost::unit_test::unit_test_main( init_func, Runner.argc(), Runner.argv() );
    }

private:

    runner()
    {
    }

    static runner& instance()
    {
        static runner Runner;
        return Runner;
    }

private:

    static
    bool init_unit_test()
    {
        init_unit_test_suite( 0, 0 );
        return true;
    }

    static
    boost::unit_test::test_suite* init_unit_test_suite( int argc, char* argv[] )
    {
        auto AddTests = runner::instance().get_add_tests_callback();
        if( AddTests )
        {
            AddTests( boost::unit_test::framework::master_test_suite() );
        }
        return 0;
    }

private:

    void store_arguments( /* properties */  )
    {
        ArgumentStrings_ = /* copy of Boost.Test relevant properties */
        Arguments_ = /* pointers to actual strings in ArgumentStrings_ */
    }

private:

    int argc() const
    {
        return ArgumentStrings_.size();
    }

    char** argv() const
    {
        return const_cast<char**>( &Arguments_[0] );
    }

    void set_title( const std::string& Title )
    {
        if( ArgumentStrings_.empty() )
        {
            ArgumentStrings_.push_back( Title );
            Arguments_.push_back( ArgumentStrings_[0].c_str() );
            Arguments_.push_back( 0 );
        }
        else
        {
            ArgumentStrings_[0] = Title;
            Arguments_[0] = ArgumentStrings_[0].c_str();
        }
    }

    void set_add_tests_callback( const call_add_tests_t& Callback )
    {
        Callback_ = Callback;
    }

    const call_add_tests_t& get_add_tests_callback()
    {
        return Callback_;
    }

private:

    call_add_tests_t            Callback_;
    std::vector<std::string>    ArgumentStrings_;
    std::vector<const char*>    Arguments_;
};

} // test

We would use a runner like this as follows:

    // Implement a function to add tests to the Master Test Suite
    // Note this can be a member function and simply call
    // another member to collate the test suites
    void add_tests( test::runner::master_test_suite_t& MasterSuite )
    {
        MasterSuite.add( scenario_test_suite() );
    }

    // A
    test::runner::test_suite_t* scenario_test_suite()
    {
        auto* test_suite = BOOST_TEST_SUITE( Name_.c_str() );

        test_suite->add( BOOST_TEST_CASE( boost::bind( &self_t::validate_incoming_messages, this->shared_from_this() ) ) );
        test_suite->add( BOOST_TEST_CASE( boost::bind( &self_t::validate_outgoing_messages, this->shared_from_this() ) ) );
        test_suite->add( BOOST_TEST_CASE( boost::bind( &self_t::validate_data_messages,     this->shared_from_this() ) ) );

        return test_suite;
    }

    // Calling test() actually causes the tests to be executed
    // We assume in this example that the object that
    // test() belongs to is a shared_ptr
    void test()
    {
        test::runner::run( Name_, boost::bind( &self_t::add_tests, this->shared_from_this(), _1 ) );
    }

The attached patch makes the above code possible by doing 2 things:

  1. If the macro BOOST_TEST_USE_QUALIFIED_COMMANDLINE_ARGUMENTS is defined then the Boost.Test command line arguments are scoped using boost.test.* as a prefix. This means commandline arguments used to control tests will not interfere with command line arguments used to control the code being tested. --log_level is an excellent example of why you might need to do that. --boost.test.log_level is much clearer and will not clash.
  1. Calls to boost::unit_test::framework::init() will occur each time run() is called. However with the patch each call resets the framework to a consistent initial state and the tests proceed as expected as if the framework had been called once from main().

We are using this patch with boost 1.48 right now (and so it is very slightly different due to the changes between 1.48 and trunk) and it allows us to run our main processes in a 'test' mode generating full test result output with timings that are then sent to our build server. It works very well, has no impact on normal unit test usage and is a very small change for a very big gain.

This patch along with the patches attached to these tickets:

#7397
Boost.Test, since boost 1.48 is using the deprecated Boost.Timer class - it should be updated to use the new class
#7410
Test Units (Cases and Suites) in Boost.Test do not capture __FILE__ and __LINE__ at declaration point making it impossible to provide source file linking using external test management tools
#7417
Detailed test status is not available in the Boost.Test log (status, assertions, passed) and so live test case status cannot be tracked

...combine to significantly improve the value of Boost.Test in terms of integration with thirdparty analysis tools and integration with other code libraries.

Given the small changes that are made I'd like to see them hopefully make it into the next boost release.

#7420 If I call managed_shared_memory() function when I create a lot of objects, it ocurrs error. new igaztanaga Bugs To Be Determined interprocess

Reported by anonymous, 19 months ago.

Description

I want to call managed_shared_memory(), when I create a lot of objects... however,it ocurrs error. In additional, it's too show to create shared memory and segment..

You can check a attached file.

Should I call managed_shared_memory() only one time?

please answer..

#7423 std::map::erase returns iterator in C++11 mode instead of void, should be handled properly new theller Bugs To Be Determined phoenix

Reported by Andrei Elovikov <a.elovikov@…>, 19 months ago.

Description

The issue is with the following code: boost/phoenix/stl/container.hpp, line 284

        namespace result_of
        {
            template <typename C, typename Arg1, typename Arg2 = mpl::void_>
            struct erase
            {
                //  BOOST_MSVC #if branch here in map_erase_result non-
                //  standard behavior. The return type should be void but
                //  VC7.1 prefers to return iterator_of<C>. As a result,
                //  VC7.1 complains of error C2562:
                //  boost::phoenix::stl::erase::operator() 'void' function
                //  returning a value. Oh well... :*

                typedef
                    boost::mpl::eval_if_c<
                        boost::is_same<
                            typename remove_reference<Arg1>::type
                          , typename iterator_of<C>::type
                        >::value
#if defined(BOOST_MSVC)// && (BOOST_MSVC <= 1500)
                      , iterator_of<C>
#else
                      , boost::mpl::identity<void>
#endif
                      , size_type_of<C>
                    >
                map_erase_result;

                typedef typename
                    boost::mpl::eval_if_c<
                        has_mapped_type<C>::value
                      , map_erase_result
                      , iterator_of<C>
                    >::type
                type;
            };
        }

It seems that MSVC's behaviour becomes the standard one with C++11.

Also the current check seems to be done incorrectly because Intel Compiler uses MSVC's stl library on Windows, so checking for _MSC_VER will be more appropriate, I think.

#7433 MSVC runtime check fix in crc reopened dlwalker Bugs To Be Determined crc

Reported by Franz Detro <franz.detro@…>, 19 months ago.

Description

With MSVC in debug mode and runtime checks enabled, we encounter an issue in crc.hpp.

Please find attached a simple patch against boost 1.51.0 which fixes this issue.

#7434 Lock used in flyweight causes erroneous "unused variable" warning when compiling with clang new joaquin Bugs To Be Determined flyweight

Reported by Pierre Imai <pierre.imai@…>, 19 months ago.

Description

The lock functionality in boost/flyweight/detail/flyweight_core.hpp causes the following warning when compiled with "Apple clang version 4.0 (tags/Apple/clang-421.0.60) (based on LLVM 3.1svn)" with option "-Wunused-variable":

In file included from /opt/local/include/boost/flyweight/flyweight.hpp:22:
/opt/local/include/boost/flyweight/detail/flyweight_core.hpp:189:22: error: unused variable 'lock' [-Werror,-Wunused-variable]
    lock_type        lock(mutex());

This problem can be fixed by adding the following code to the file, before / after the corresponding blocks for MSVC

#ifdef __clang__
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wunused-variable"
#endif
#ifdef __clang__
#pragma clang diagnostic pop
#endif
#7435 Crash with format using UTF16 strings on MacOS X new samuel_krempp Bugs To Be Determined format

Reported by Franz Detro <franz.detro@…>, 19 months ago.

Description

Due to cross-platform issues with Microsoft Windows, we are using std::strings with unsigned shorts as UTF16 strings.

We experience crashes when using boost::format in combination with these strings.

Please find attach a simple fix which solves this issue for us. We are using this code since some years on Windows and Unix, too, without any negative side-effects.

It would be great if you could double-check this change and commit it to future boost versions.

#7436 Missing python dlls new rwgk Bugs To Be Determined Python

Reported by habdank@…, 19 months ago.

Description

Dears,

When I am building boost 1.50 using:

b2 --toolset=msvc-9.0 --build-type=complete --without-mpi --build-dir=..\lib_msvc9_x86_p26 --stagedir=..\lib_msvc9_x86_p26 install

boost-python dlls are not created. in version 1.45 they had been created.

How can I build boost-python dlls? There are boost python static libs. There are other dlls present (e.g. boost-system), so it is rather boost-python package problem or special case of boost build tool chain.

Also there is general problem that mentioned commanline options are not creating delivery folder with all important binaries as it was in the past.

Regards, Seweryn Habdank-Wojewodzki.

#7440 boost::filesystem compile error on solaris 10 new bemandawes Bugs To Be Determined filesystem

Reported by aleksandar.vukajlovic@…, 19 months ago.

Description

It fails to compile on gcc 4.7.2 with compile flags cxxflags=-std=c++0x

libs/filesystem/src/operations.cpp: In function 'void boost::filesystem::detail: :permissions(const boost::filesystem::path&, boost::filesystem::perms, boost::system::error_code*)': libs/filesystem/src/operations.cpp:1412:11: error: '::fchmodat' has not been declared

in line 1410 there is:

&& !(defined(__SUNPRO_CC) || defined(sun)) \

proper check for solaris would be:

&& !(defined(__SUNPRO_CC) || defined(sun) || defined(__sun)) \
#7450 Buggy rounded_arith.hpp new bgubenko Bugs To Be Determined interval

Reported by Luca Di Gaspero <l.digaspero@…>, 19 months ago.

Description

The rounded_arith file is currently buggy, because it misses an explicit this-> to some function calls (due to the evolution in template compilation of g++ since version 4.0). I attach the small patch to get it working.

#7451 clang-linux.jam : cflags/cxxflags feature is added twice to compiler's command line (other features possibly as well) new vladimir_prus Bugs To Be Determined build

Reported by oakad@…, 19 months ago.

Description

The crux of the issue appears to be here:

--- clang-linux.jam.orig 2012-10-01 20:31:55.253818173 +1000 +++ clang-linux.jam 2012-10-01 20:29:05.048627617 +1000 @@ -66,8 +66,8 @@

############################################################################### # Flags

-toolset.flags clang-linux.compile OPTIONS <cflags> ; -toolset.flags clang-linux.compile OPTIONS <cxxflags> ; +#toolset.flags clang-linux.compile OPTIONS <cflags> ; +#toolset.flags clang-linux.compile OPTIONS <cxxflags> ;

toolset.flags clang-linux.compile OPTIONS <optimization>off : ; toolset.flags clang-linux.compile OPTIONS <optimization>speed : -O3 ;

Flags are apparently already added by the "base" module and then again by the inherited one (does it make sense?).

#7453 Dead link in date::time docs new az_sw_dude Bugs To Be Determined date_time

Reported by wlandry@…, 19 months ago.

Description

In the list of references

 http://boost-sandbox.sourceforge.net/doc/html/date_time/details.html#date_time.references

the link to Will Linden's list of calendar links

 http://www.ecben.net/calendar.shtml

is a dead link.

#7454 Compilation error using gcc 4.1.2 (free not in std namespace) new matthiasschabel Bugs To Be Determined units

Reported by anonymous, 19 months ago.

Description

Error /home/davidsj2/include/boost/units/detail/utility.hpp: In function 'std::string boost::units::detail::demangle(const char*)': /home/davidsj2/include/boost/units/detail/utility.hpp:48: error: 'mm_free' is not a member of 'std'

On that line, you'll find:

std::free(realname);

In order to get the software to build, I had to change to:

free(realname);

Environment [davidsj2@optimus ~]$ gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --disable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-52) [davidsj2@optimus ~]$ uname -a Linux optimus 2.6.18-275.7.1.el5.572g0000 #1 SMP Mon Oct 31 19:15:23 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux [davidsj2@optimus ~]$ tail /home/davidsj2/include/boost/version.hpp

BOOST_LIB_VERSION must be defined to be the same as BOOST_VERSION but as a *string* in the form "x_y[_z]" where x is the major version number, y is the minor version number, and z is the patch level if not 0. This is used by <config/auto_link.hpp> to select which library version to link to.

#define BOOST_LIB_VERSION "1_51"

#endif

#7460 owi_mt_tests.cpp:89: error: 'TIME_UTC' is not a member of 'boost' new djowel Bugs To Be Determined spirit

Reported by greg.nowakowski@…, 19 months ago.

Description

Release 1.50.0 is not compiling on Linux with gcc-4.1.2 when running boost_1_50_0/libs/spirit/classic/test test.

Test run using command:

../../../../bjam -a >test.result

Here is the problem:

gcc.compile.c++ ../../../../bin.v2/libs/spirit/classic/test/owi_mt_tests.test/gcc-4.1.2/debug/threading-multi/owi_mt_tests.o
owi_mt_tests.cpp: In static member function 'static long unsigned int test_task<ClassT>::increase_test_size(long unsigned int)':
owi_mt_tests.cpp:89: error: 'TIME_UTC' is not a member of 'boost'
owi_mt_tests.cpp: In function 'void concurrent_creation_of_objects()':
owi_mt_tests.cpp:190: error: 'TIME_UTC' is not a member of 'boost'

It should be using TIME_UTC_ and not TIME_UTC. I am surprised this bug hasn't been reported before.

Blessings, Greg.

#7472 [Preprocessor] include wstringize.hpp missing in preprocessor.hpp new no-maintainer Bugs To Be Determined preprocessor

Reported by tobias.loew, 19 months ago.

Description

The documentation states that preprocessor.hpp includes the entire library but wstringize.hpp is missing.

#7475 Functions redeclared inline after been called new bemandawes Bugs To Be Determined system

Reported by viboes, 19 months ago.

Description

THe following warnings appear with intel-12.1.3 compiler

../../../boost/system/error_code.hpp(489): remark #522: function "boost::system::error_category::default_error_condition" redeclared "inline" after being called
      inline error_condition error_category::default_error_condition( int ev ) const
                                             ^

../../../boost/system/error_code.hpp(494): remark #522: function "boost::system::error_category::equivalent(int, const boost::system::error_condition &) const" redeclared "inline" after being called
      inline bool error_category::equivalent( int code,
                                  ^

../../../boost/system/error_code.hpp(500): remark #522: function "boost::system::error_category::equivalent(const boost::system::error_code &, int) const" redeclared "inline" after being called
      inline bool error_category::equivalent( const error_code & code,
                                  ^

See the attached patch that solves the issue.

#7477 boost:::format will not compile under VC++ without "Microsoft language extensions" reopened samuel_krempp Bugs To Be Determined format

Reported by Jive Dadson <jdadson@…>, 19 months ago.

Description

Boost::format will not compile under Microsoft VC++ unless Microsoft Language Extensions (/Za) are turned OFF. When MS Language Extensions are turned ON, the compiler complains because boost overrides some virtual functions in std:: classes with functions lacking a "throw()" specifier. One of the functions is the destructor ~basic_streambuf().

I do not know if this is a bug or a misunderstanding on my part. If it is a bug, I do not know whether it is on the MS or boost side. However, it should be a simple matter to decorate those functions with "throw()." That could save someone a lot of trouble.

#7480 Runtime failures in let_tests.test new theller Bugs To Be Determined phoenix

Reported by michel, 19 months ago.

Description

When compiling libs/phoenix/scope/let_tests.cpp on gcc 4.5, 4.7, 4.8 (experimental) and clang 3.0, 3.1, 3.2 (trunk) with optimization flag -O2 or -O3, runtime test failures (i.e. BOOST_TEST failures) occurs. The failures occur both in C++03 and C++11 modes and both with BOOST_RESULT_OF_USE_DECLTYPE and without BOOST_RESULT_OF_USE_DECLTYPE.

lambda_tests.test also generates runtime failures. It fails on gcc 4.6, too. I think there are other failed test cases when compiling with optimization flag -O2 or -O3.

#7481 lambda_tests.test fails to compile with BOOST_RESULT_OF_USE_DECLTYPE new theller Bugs To Be Determined phoenix

Reported by michel, 19 months ago.

Description

#5687 (some evaluation functions do not work with BOOST_RESULT_OF_USE_DECLTYPE) is generally fixed by Eric recently. But libs/phoenix/scope/lambda_tests.cpp fails to compile on gcc 4.4-4.8 and clang 2.8-3.0 with BOOST_RESULT_OF_USE_DECLTYPE. Eric also reported it fails to compile on MSVC with BOOST_RESULT_OF_USE_DECLTYPE.

The compilation succeeds on clang 3.1-3.2 (which have N3276 decltype support).

#7482 Build from source with MinGW on Windows new timblechmann Bugs To Be Determined Building Boost

Reported by RusBaratov@…, 19 months ago.

Description

Hello, I've trying to build boost with mingw, and I've got error, when --layout=system option is used.

check out (with cygwin):

> svn co http://svn.boost.org/svn/boost/trunk boost-trunk
> svnversion
80897

build (windows cmd.exe):

> g++ --version
g++ (Built by MinGW-builds projects) 4.7.1
> cd boost-trunk
> .\bootstrap gcc

build with --layout=tagged works fine:

> .\b2 --toolset=gcc --layout=tagged

but build with --layout=system failed:

> .\b2 --toolset=gcc --layout=system
...
error: Duplicate name of actual target: <pstage\lib>libboost_atomic.a
error: previous virtual target { common%common.copy-libboost_atomic.a.STATIC_LIB { gcc%gcc.archive-libboost_atomic.a.STATIC_LIB { gcc%gcc.compile.c++-
lockpool.o.OBJ { lockpool.cpp.CPP } } } }
error: created from ./stage-proper
error: another virtual target { common%common.copy-libboost_atomic.a.STATIC_LIB { gcc%gcc.archive-libboost_atomic.a.STATIC_LIB { gcc%gcc.compile.c++-l
ockpool.o.OBJ { lockpool.cpp.CPP } } } }
error: created from ./stage-proper
error: added properties: <debug-symbols>off <define>NDEBUG <inlining>full <optimization>speed <runtime-debugging>off <variant>release
error: removed properties: <debug-symbols>on <inlining>off <optimization>off <runtime-debugging>on <variant>debug
M:/boost-trunk/tools/build/v2/build\virtual-target.jam:491: in actualize-no-scanner from module object(file-target)@4808
M:/boost-trunk/tools/build/v2/build\virtual-target.jam:134: in object(file-target)@4808.actualize from module object(file-target)@4808
M:/boost-trunk/tools/build/v2\build-system.jam:736: in load from module build-system
M:\boost-trunk\tools\build\v2/kernel\modules.jam:289: in import from module modules
M:\boost-trunk\tools\build\v2/kernel/bootstrap.jam:139: in boost-build from module
M:\boost-trunk\boost-build.jam:17: in module scope from module
#7494 boost::replace_all is very slow on debug build when Format size is big assigned marshall Bugs To Be Determined string_algo

Reported by Jan Vonasek <jan.vonasek@…>, 19 months ago.

Description

Method boost::replace_all(SequenceT& Input, const Range1T& Search, const Range2T& Format) on debug build takes very long time when Format size is about 300k. On call stack I can see push_front for every char.

When I use std::find and std::replace in loop it is cca 10 times faster.

I have Boost library 1.45, Visual Studio 2010, Win7 x64 SP1, 6-core CPU.

#7502 Planarity test runs in quadratic time on some graphs new jewillco Bugs To Be Determined graph

Reported by Jan Hązła <jan.hazla@…>, 19 months ago.

Description

The planarity test in the graph library (boyer_myrvold_planarity_test) seems to run in quadratic time for a certain class of graph.

I attached a program that demonstrates the problem. The program reads number N from stdin, generates a certain graph and runs the planarity test on it.

The graph is a bipartite graph K_{2,n} with some additional edges -- specifically, 2 "left" vertices of the bipartite graph are connected with an edge and n "right" vertices form a path. Note that the order of edge insertion matters -- the problem disappears if we change it.

Unfortunately I don't understand the planarity test enough to fix the problem. What I established (and what makes me believe it runs in quadratic time) is that for my graph in function walkdown (in planar_details/boyer_myrvold_impl.hpp; I understand the function is called once for each vertex) there is a loop on line 663 that is executed k times when the function was called for (k+1)-th time. This loop seems to have to do with Kuratowski subgraph detection, but I can't say anything more about it.

My configuration is Mac OS 10.8 with MacPorts?, g++ 4.7 and boost 1.51. I also reproduced it on some Linux and Windows configurations.

#7504 boost::interprocess::basic_vectorbuf calls std::char_traits<char>::pbump() with potentially mismatching data type new igaztanaga Bugs To Be Determined interprocess

Reported by mbradshaw@…, 19 months ago.

Description

boost::interprocess::basic_vectorbuf::seekoff() makes a call to base_t::pbump(), but the datatypes (may) mismatch for the parameter (and do on my system). std::char_traits<char>::pbump() takes an int (according to the standard), but basic_vectorbuf() is passing it a value of type CharTraits::off_type, which is implementation defined. Since std::char_traits<char>::off_type is __int64 on my system, I am getting a warning about a conversion from __int64 to int.

I don't know what the most appropriate solution is (maybe just a static_cast), but it would be nice to have this resolved so I can get back down to 0 warnings in my codebase.

I am using Visual Studio 2010 and the latest Boost (and I just check svn trunk and it has the same issue). I get this warning when creating a boost::interprocess::basic_vectorstream like so:

basic_vectorstream<std::vector<char>, std::char_traits<char>> vs;

#7506 unique_path Fails on Windows for Temporary User Profiles new bemandawes Bugs To Be Determined filesystem

Reported by steve@…, 19 months ago.

Description

boost::filesystem::unique_path is failing on Windows if the user has a temporary (read-only) profile (e.g. guest account). I have tracked the problem down to a failure in libs/filesystem/src/unique_path.cpp when it calls CryptAcquireContextW.

CryptAcquireContextW is failing with the arguments used. It appears that this is by design, for read-only profiles. See  http://blogs.msdn.com/b/alejacma/archive/2007/10/23/rsacryptoserviceprovider-fails-when-used-with-mandatory-profiles.aspx for some background information.

I have modified the dwFlags argument of both calls to CryptAcquireContextW, adding CRYPT_VERIFYCONTEXT | CRYPT_SILENT and it is now working for me. I'm no expert on the Win32 crypto API so I'm not sure if this is a valid solution in all contexts.

#7507 BGL subgraph copy constructor buggy new jewillco Bugs To Be Determined graph

Reported by Amyn Bennamane <amynbe@…>, 19 months ago.

Description

Hello,

I store subgraph objects in a std::list.

After this, most of the data contained in subgraphs are lost.

Attached is a minimalist code that creates a root graph and two childen, and then displays them directly, then insert them into a (copy-on-write) list, then displays them again.

The root redisplays too much, and children lose data.

I am on MacOSX with gcc 6; maybe on other platforms the copy would not happen, since I don't modify the graphs between insertion and display.

Here is my output:

From the stack: 
(root) graph: 6(0,2) 4(1,2) 
num_edges= 2
subgraph: 0(0,1) 
num_edges= 1
subgraph: 0(0,1) 
num_edges= 1

From list: 
graph: 0(0,1) 1(1,2) 2(1,3) 6(2,5) 3(4,1) 4(4,5) 5(5,3) 
num_edges= 7
graph: 
num_edges= 0
graph: 
num_edges= 0
#7508 Boost timezonedb incorrect Brazil DST specification new az_sw_dude Bugs To Be Determined date_time

Reported by anonymous, 19 months ago.

Description

Today our applications running in Brazil have the incorrect time. We tracked it down to an error in the boost date_time_zonespec.csv specification for America/Sao_Paulo. It specifies that the DST change starts on the second Sunday of October (yesterday). However, it actually starts on the third Sunday (see the attached document from exchange). I downloaded the latest version of boost (1.51), and it is also incorrect there. Also note that Linux does have the correct time. I intend to submit a bug report to Boost, but I don’t know if you prefer if the external communication to go through your team.

Incorrect: "America/Sao_Paulo","BRT","BRT","BRST","BRST","-03:00:00","+01:00:00","2;0;10","+00:00:00","3;0;2","+00:00:00"

Should be (for all BRST): "America/Sao_Paulo","BRT","BRT","BRST","BRST","-03:00:00","+01:00:00","3;0;10","+00:00:00","3;0;2","+00:00:00"

#7517 indirect_streambuf: invalid state change if write() writes less data then requested new turkanis Bugs To Be Determined iostreams

Reported by Oleg Liatte <oleg.liatte@…>, 18 months ago.

Description

Currently indirect_streambuf::sync_impl() calls setp() to update pbase() without any regard to current pbase() value. With unreliable write() it will lead to buffer consistency loss and data duplication if write() doesn't satisfy request fully two or more times in a row.

As a solution setp() should use pbase() as current buffer begin instead of out().begin(). See patch.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Note: See TracQuery for help on using queries.