- Boost - lists.boost.org

interest in run-time typechecked replacement of void pointer ?
by Matus Chochlik 11 Feb '08

11 Feb '08

NOTE: Code to be discussed can be found in the Boost Vault in directory Memory/RawPtr, archive rawptr-draft-0.xx.zip (where xx is the current version of the draft) Shorter version: A class raw_ptr as a replacement for plain void* [void pointer] is suggested that does run-time typechecking in a similar way as Boost.Any does but follows syntax of void* as much as possible. Thus in the ideal case allowing find-replace substitution of void* in code without introducing syntax errors. A new cast type; raw_cast is suggested to replace static_cast when casting from untyped to typed pointer When a bad cast is detected (at run-time) a compile-time defined policy (by default calling of abort()) is executed. Longer version: Even though the use of untyped pointers in cpp applications is discouraged and can be usualy avoided by using templates or by other means, (like Boost.Any) there are situations where an untyped pointer ''must be used'' or is the best option. The disadvantages are obvious, by using the void* we are deprived of all information about the type the pointer points to. This can lead to hard to find, persistent bugs in larger programs. However in many applications that resort to using untyped pointers the code follows pattern shown by this pseudo-code: typedef <some-type> T; T* ptr_x = acquire_ptr_to<T>([argument-list]); ... void* raw_ptr_x = ptr_x; store(raw_ptr_x, key_to_x); ... T* ptr_x_2 = static_cast<T*>(retrieve(key_to_x)); use(ptr_x_2); i.e.: 1) Create or get a pointer to an instance of a known type. 2) Store or pass the address of the instance by the means of an untyped pointer. 3) Let the code logic to determine the correct type and cast the pointer back by the means of static_cast Even if the logic behind points 1) 2) and 3) is consistent subtle bugs can be introduced that may cause undefined behavior or application crashes. The proposed raw_ptr class that does the typechecking in a similar way as Boost.Any does and allows to detect bad casts from void* to typed pointer and act accoding to a policy defined at compile-time (i.e. throw an exception, call abort(), do nothing, etc.) The main difference between the proposed raw_ptr and ::boost::any is that raw_ptr tries to follow the syntactic properties of void* as much as possible. A new cast type, namely raw_cast<T>(x) is proposed to replace static_cast, when casting from raw_ptr to typed pointer.

1 0

This deadlocks on Linux but not on Windows
by Clark Sims 11 Feb '08

11 Feb '08

I would like it to deadlock on windows, because I just wrote a large header file, which assumes that a deadlock will occur. In fact, I don't know how I am going to program mutex's and locks, if they act like recursive locks on windows, but scoped locks on linux. #include <boost/thread/thread.hpp> #include <iostream> using namespace std; void hello() { cerr << "this should deadlock" << endl; boost::mutex foo; boost::mutex::scoped_lock lock1(foo); boost::mutex::scoped_lock lock2(foo); cerr << "if you see this, then there was no deadlock" << endl; } int main(int argc, char* argv[]) { boost::thread thrd(&hello); thrd.join(); return 0; } --------------------------------- Never miss a thing. Make Yahoo your homepage.

8 11

[asio] read_until.cpp fails to compile on HP-UX_ia64_gcc
by Boris Gubenko 11 Feb '08

11 Feb '08

A couple of days ago (don't know exactly when), two asio library tests based on single source -- read_until.cpp -- started to fail to compile on HP-UX_ia64_gcc as the following: ../boost/asio/detail/socket_ops.hpp: In function 'int boost::asio::detail::socket_ops::select(int, fd_set*, fd_set*, fd_set*, timeval*, boost::system::error_code&)': ../boost/asio/detail/socket_ops.hpp:634: error: cannot convert 'fd_set*' to 'int*' for argument '2' to 'int select(size_t, int*, int*, int*, const timeval*)' While compilation error is obvious and can be eliminated by compiling with _XOPEN_SOURCE_EXTENDED macro defined, I could not figure out by looking at SVN log what changes have caused it. I verified that with _XOPEN_SOURCE_EXTENDED macro defined, all asio library tests pass on HP-UX_ia64_gcc. On another HP-UX/gcc platform participating in Boost testing -- HP-UX_pa_risc_gcc -- they pass with and without this macro defined. The platform details: HP-UX_ia64_gcc : HP-UX 11.23 ia64 with gcc 4.2.1 HP-UX_pa_risc_gcc : HP-UX 11.11 PA-RISC with gcc 3.4.2 Is it expected that asio library tests on HP-UX/gcc should be compiled with _XOPEN_SOURCE_EXTENDED macro defined? (for example, for SOLARIS, asio/test/Jamfile.v2 defines _XOPEN_SOURCE=500 and __EXTENSIONS__) And what was the change that broke HP-UX_ia64_gcc ? Thanks, Boris

2 1

Re: [boost] [asio-users] Cancelation not working on windows?
by Roland Schwarz 11 Feb '08

11 Feb '08

This is my second attempt, since there was no meaningful answer on the first. I again apologize for cross-posting but I still have no idea which is the correct list to post asio related questions. Roland Schwarz wrote: > One of my objectives is getting cancellation in a > platform independent way. Since on windows blocking > io cannot be canceled I tried to use asio to emulate > the required behavior. > > This works well on linux, but the same code fails > on windows. During a debug session it appeared to me > as if the CancelIO call is not being honored (WindowsXP). > > Is this a bug in asio or am I doing something wrong. > > I put together a stripped down example to show > the "erroneous" behavior. > > The examples main thread connects to localhost port 80 and > then schedules an async read call. > > A second polling thread checks for ctrl-c beeing pressed > and invokes the sockets cancel function. > > On linux this causes the read handler to terminate with > Oeration Cancelled > as expected, but on windows the cancel request is simply > swallowed. > > Any help appreciated! > -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at # $Id: Jamroot 49 2008-01-08 14:20:45Z rs $ project cancel ; #use-project boost : "C:/projects/boost/trunk" ; use-project boost : /home/roland/projects/boost/trunk ; lib winsock : : <name>ws2_32 ; lib mswsock : : <name>mswsock ; exe cancel : cancel.cpp : <link>static <threading>multi <target-os>windows:<library>winsock <target-os>windows:<library>mswsock <target-os>windows:<define>_WIN32_WINNT=0x0500 <library>/boost//system <library>/boost//regex <library>/boost//date_time <library>/boost//thread ; install dist : cancel : <location>. ;

3 2

Review - Logging Library
by Tom Brinkman 11 Feb '08

11 Feb '08

* What is your evaluation of the design? Introduces alot of new concepts for something relatively simple, logging. A study of the headers suggests a boostified functional style, but with lots of macros, which some developers here have no objection over. I on the other hand would like to see less, or even no macros in the public interface. A functional, lambda style logging interface should be adequate. If a macro is needed, suggest it as a work-around, but dont force it on the user in the example(s). * What is your evaluation of the implementation? No issues. Author appears to be knowlegable in the problem domain. * What is your evaluation of the documentation? Overall, I didnt like the informal style, but I was able to get the information I needed. Author tries to be too "cute" or "friendly". Author should get rid of informal comments and replace them with more professional language. An example of informal language is: "Yup, we have other examples as well. We also have a starter project." * What is your evaluation of the potential usefulness of the library? Potential is high. Would I use this library. As it stands, no. The tradeoff/benefits still suggest to me that logging requirements are too application specific, and this library doesnt change that equation. If it had a simple, boostified, lambda interface, with no macros, and no learning curve, I would probably use it. As it stands, its too complicated, with too little benefit for me to us it. Sorry. * Did you try to use the library? With what compiler? Did you have any problems? It compiled on GCC, linux, ubuntu, with some warnings, which I ignored. * How much effort did you put into your evaluation? Three hours * Are you knowledgeable about the problem domain? Yes. * Do you think the library should be accepted as a Boost library? No. I would evaluate it again, if the author would create a more boost friendly, lambda style public interface. Tom Brinkman

2 1

[date_time] array bounds error
by Jonathan Wakely 10 Feb '08

10 Feb '08

In libs/date_time/src/gregorian/greg_month.cpp we have: short i = date_time::find_match(special_value_names, special_value_names, date_time::NumSpecialValues, s); This results in a read past the end of the array. I believe the caller should pass NumSpecialValues-1 and the error check after it should be if(i >= date_time::NumSpecialValues) { // match not found Jon -- "There are basically two types of people. People who accomplish things, and people who claim to have accomplished things. The first group is less crowded." - Mark Twain

1 1

[logging] Defining logs in header only implementations
by Jamie Allsop 10 Feb '08

10 Feb '08

Hi John, I'm guessing you missed my earlier post about this here, <http://lists.boost.org/Archives/boost/2008/01/132203.php> This is an issue I'd really want to see addressed. Jamie

2 7

[program_options] [patch] Command-line parser should check for argc == 0
by C. K. Jester-Young 10 Feb '08

10 Feb '08

In the program_options library, command-line parsing functions that take (argc, argv) arguments do not check for a zero argc. Thus, when argc is zero, the iterators passed to the vector constructor have first > last, which results in undefined behaviour. Patches are attached which address this (minimally, simply by treating argc as 1 when it's 0, since argv[0] is never used). According to the execve reference in Open Group Base Specifications Issue 6: Early proposals required that the value of argc passed to main() be "one or greater". This was driven by the same requirement in drafts of the ISO C standard. In fact, historical implementations have passed a value of zero when no arguments are supplied to the caller of the exec functions. This requirement was removed from the ISO C standard and subsequently removed from this volume of IEEE Std 1003.1-2001 as well. In practice, some operating systems, notably Linux, still do this, as aptly demonstrated with the following program: #include <errno.h> #include <stdio.h> #include <string.h> #include <unistd.h> int main(int argc, char **argv) { char *empty = (char *) 0; if (argc != 2) { fprintf(stderr, "usage: %s program\n", argc ? argv[0] : "(null)"); return 1; } execve(argv[1], &empty, &empty); fprintf(stderr, "Cannot run %s: %s\n", argv[1], strerror(errno)); return 1; } Then you can test with your favourite :-) programs to see how they behave (I've called the program zeroargc in the examples below): $ ./zeroargc usage: ./zeroargc program $ ./zeroargc ./zeroargc usage: (null) program Cheers, Chris.

2 1

[config][math][tr1]Link fixes
by Daniel James 10 Feb '08

10 Feb '08

Hi John, I've attached a patch for a few of your libraries. Mostly for link errors that were obscured by the link errors I caused. There are still a few left (in math and type traits I think, I'll need to rebuild the documentation to find out). Daniel

3 3

[xpressive] Lots of warnings on VS9
by Robert Dailey 10 Feb '08

10 Feb '08

Hi, I'm compiling the boost::xpressive library under Visual Studio 9 at warning level 4. At the bottom of this email are the endless pages of warnings I'm getting. Note that I am using the latest version of xpressive from the boost trunk. 1>c:\it\personal\rocket_test\sdk\boost\boost\xpressive\detail\core\peeker.hpp(276) : warning C4512: 'boost::xpressive::detail::xpression_peeker<Char>' : assignment operator could not be generated 1> with 1> [ 1> Char=char 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\detail\dynamic\matchable.hpp(67) : see reference to class template instantiation 'boost::xpressive::detail::xpression_peeker<Char>' being compiled 1> with 1> [ 1> Char=char 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\detail\dynamic\matchable.hpp(66) : while compiling class template member function 'void boost::xpressive::detail::matchable_ex<BidiIter>::peek(boost::xpressive::detail::xpression_peeker<Char> &) const' 1> with 1> [ 1> BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>, 1> Char=char 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\intrusive_ptr.hpp(83) : see reference to class template instantiation 'boost::xpressive::detail::matchable_ex<BidiIter>' being compiled 1> with 1> [ 1> BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\intrusive_ptr.hpp(82) : while compiling class template member function 'boost::intrusive_ptr<T>::~intrusive_ptr(void)' 1> with 1> [ 1> T=const boost::xpressive::detail::matchable_ex<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\detail\core\regex_impl.hpp(183) : see reference to class template instantiation 'boost::intrusive_ptr<T>' being compiled 1> with 1> [ 1> T=const boost::xpressive::detail::matchable_ex<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\type_traits\is_class.hpp(76) : see reference to class template instantiation 'boost::xpressive::detail::regex_impl<BidiIter>' being compiled 1> with 1> [ 1> BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\type_traits\is_class.hpp(121) : see reference to class template instantiation 'boost::detail::is_class_impl<T>' being compiled 1> with 1> [ 1> T=boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\type_traits\is_base_and_derived.hpp(210) : see reference to class template instantiation 'boost::is_class<T>' being compiled 1> with 1> [ 1> T=boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\type_traits\is_base_and_derived.hpp(225) : see reference to class template instantiation 'boost::detail::is_base_and_derived_impl<B,D>' being compiled 1> with 1> [ 1> B=boost::xpressive::detail::enable_reference_tracking<boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>>>, 1> D=boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\mpl\assert.hpp(148) : see reference to class template instantiation 'boost::is_base_and_derived<Base,Derived>' being compiled 1> with 1> [ 1> Base=boost::xpressive::detail::enable_reference_tracking<boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>>>, 1> Derived=boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\detail\utility\tracking_ptr.hpp(381) : see reference to class template instantiation 'boost::mpl::assert_arg_pred_not<P>' being compiled 1> with 1> [ 1> P=boost::is_base_and_derived<boost::xpressive::detail::enable_reference_tracking<boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>>>,boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\proto\expr.hpp(181) : see reference to class template instantiation 'boost::xpressive::detail::tracking_ptr<Type>' being compiled 1> with 1> [ 1> Type=boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>> 1> ] 1> c:\it\personal\rocket_test\sdk\boost\boost\xpressive\basic_regex.hpp(47) : see reference to class template instantiation 'boost::proto::exprns_::expr<Tag,Args>' being compiled 1> with 1> [ 1> Tag=boost::proto::tag::terminal, 1> Args=boost::proto::argsns_::args0<boost::xpressive::detail::tracking_ptr<boost::xpressive::detail::regex_impl<std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>>>>> 1> ] 1> c:\it\personal\rocket_test\source\rocketeventlisteners\mainmenu.cpp(63) : see reference to class template instantiation 'boost::xpressive::basic_regex<BidiIter>' being compiled 1> with 1> [ 1> BidiIter=std::_String_const_iterator<char,std::char_traits<char>,std::allocator<char>> 1> ]

7 19