January 2010 - Boost-users - lists.preview.boost.org

[asio] asio-client only connects to server when on same machine
by Grotjahn Clemens (CM-AI/PJ-CF22) 15 Jan '10

15 Jan '10

hello, i just found out what was wrong. it was an empty, uninitialised string that indeed made my client connect only to localhost.... now everything is fine! thanks

1 0

Windows: Mixed .NET and native C++ with Boost
by Richwin, Dr. Matthias 15 Jan '10

15 Jan '10

Hi all, I try the following scenario: - a C++ library (my own code), unmanaged, makes use of boost (e.g. regex) - a C++ .NET application (windows forms based) planned as GUI (having used Borland C++ builder in the past, the windows forms approach looks quite appealing to me) - my C++ library header is included in the .Net form header file wrapped in a #pragma unmanaged/managed pair. I compiles and links well. For simple test purposes, I instantiate a class from my C++ library in the form constructor. Calling some unmanaged code from my library there creates a debug assertion: "Debug Assertion Failed! [...] Expression: _CrtIsValidHeapPointer(pUserData) " The call stack at that moment is as follows ("Application.exe" is my Windows Forms Application): > msvcr90d.dll!_msize_dbg(void * pUserData=0x8914c5e3, int nBlockUse=2) Zeile 1511 + 0x30 Bytes C++ msvcr90d.dll!_dllonexit_nolock(int (void)* func=0x89521903, void (void)* * * pbegin=0x0012f000, void (void)* * * pend=0x0012eff8) Zeile 295 + 0xd Bytes C msvcr90d.dll!__dllonexit(int (void)* func=0x89521903, void (void)* * * pbegin=0x0012f000, void (void)* * * pend=0x0012eff8) Zeile 273 + 0x11 Bytes C Application.exe!_onexit(int (void)* func=0x0046dce0) Zeile 110 + 0x1b Bytes C Application.exe!atexit(void (void)* func=0x0046dce0) Zeile 127 + 0x9 Bytes C Application.exe!boost::re_detail::`dynamic initializer for 'block_cache''() Zeile 191 + 0x2b Bytes C++ [Übergang von Verwaltet zu Systemeigen] Application.exe!_initterm(void** pfbegin = 0x0046E3A4, void pfend = ) Zeile 130 C++ Application.exe!<CrtImplementationDetails>::LanguageSupport::InitializeNative() Zeile 555 C++ Application.exe!<CrtImplementationDetails>::LanguageSupport::_Initialize() Zeile 678 C++ Application.exe!<CrtImplementationDetails>::LanguageSupport::Initialize() Zeile 876 C++ Application.exe!?.cctor@@$$FYMXXZ() Zeile 922 + 0x9 Bytes C++ [Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für mscorwks.dll] ntdll.dll!7c91d39c() kernel32.dll!7c839736() ntdll.dll!7c91d39c() kernel32.dll!7c839736() kernel32.dll!7c809b32() kernel32.dll!7c80ae80() ntdll.dll!7c91dfac() kernel32.dll!7c8329b0() mscoree.dll!79007c24() kernel32.dll!7c817067() To me, it looks like the DLL initialization failed. Is anybody out there who might help me with this issue? I am completely new to this .Net thing... Best regards Matthias Leopold KOSTAL GmbH & Co. KG - Sitz Lüdenscheid, Registergericht Iserlohn HRA 2854, phG Kostal Verwaltungsgesellschaft mbH, Registergericht Iserlohn HRB 4061 - USt-Id-Nr./Vat No.: DE 125800885 Post- und Werksanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: +49 2351 16-0 * Telefax: +49 2351 16-2400 Bellmerei Geschäftsführung: Dipl.-Kfm. Helmut Kostal (Vorsitzender), Dipl.-Oec. Andreas Kostal, Dipl.-Wirtsch.-Ing. Hermann Eidel, Dipl.-Ing. Marwin Kinzl, Dr.-Ing. Ludger Laufenberg

3 2

[multiarray] problems passing views by reference
by Rhys Ulerich 14 Jan '10

14 Jan '10

Recently, Hanan Sadar asked about a multi_array fill implementation [1]. The standard std::fill_n(x.data(),x.num_elements(),v) answer only works when x is a boost::multi_array or boost::multi_array_ref but does not handle the general MultiArray concept. I decided to implement an arbitrary dimensional MultiArray fill capable of handling such views correctly. It's been absolutely miserable for reasons I don't understand but which resemble comments from James Amundson's recent thread [2]. Attached is my attempt with two exasperating lines marked by "Cannot use reference, why?". For a non-multi_array, non-multi_array_ref instance (i.e. a view) using a signature like template< class Array, class V > void operator()(Array x, const V &v); allows the code to compile and operate correctly. However, it incurs pass-by-value overhead. Using a signature like template< class Array, class V > void operator()(Array &x, const V &v); using pass-by-reference dies at compilation time. All of my attempts to use MultiArray's associated typedefs die, including hours of mucking with MultiArray::reference. What am I missing here? Why can't I pass a general MultiArray view type by reference? - Rhys [1] http://groups.google.com/group/boost-list/browse_thread/thread/829ebea7fef2… [2] http://groups.google.com/group/boost-list/browse_thread/thread/4531a7c35a58…

2 3

Re: [Boost-users] [asio] asio-client only connects to server when on same machine
by Jason Felice 14 Jan '10

14 Jan '10

On Thu, Jan 14, 2010 at 10:25 AM, Nicola Michael Gutberlet <Nicola.Gutberlet(a)hhi.fraunhofer.de> wrote: > Just an idea popping up in my mind: firewall? More likely, the server binds to localhost (loopback).

1 0

boost python macro hell
by Neal Becker 14 Jan '10

14 Jan '10

Probably OT, but I'm trying to generate modules programmatically. Each module with be generated using -DSIMCASE=n and will create a module called ldpc_n.so. I can't get this macro to work, this is my latest try: #define SIMCASE 10 #define NAME ldpc_ ## SIMCASE #define MODULE_START BOOST_PYTHON_MODULE (NAME) Later I have: MODULE_START { ... } Results in: In file included from ldpc_x.cc:12: ldpc.cc: In function 'void initldpc_SIMCASE()': ldpc.cc:100: error: 'init_module_ldpc_SIMCASE' was not declared in this scope Looks like 2 problems there: 1 is that 'SIMCASE' did not have it's #defined value substituted, second is that (as evidenced by the error) this interacted wierdly with the BOOST_PYTHON_MODULE macro.

3 4

Re: [Boost-users] variadic template function using fusion vector
by noman javed 14 Jan '10

14 Jan '10

We want to hide from user the creation of the vector. The user just need to call the execute function like that execute(FOB,bar1,bar2,...,barn). Where the FOB is any function object followed by the original data. Regards Noman Javed

3 2

[variant][graph] Conflict ?
by Maxime van Noppen 14 Jan '10

14 Jan '10

Hi, I recently upgraded the boost version used four our project from boost 1.39 to boost 1.41 and encountered a very strange compilation error. I managed to reduce the problem to this minimal test case : ----------var.cc--------------- #include <boost/variant.hpp> #include <boost/graph/breadth_first_search.hpp> int main() { boost::variant<char, bool> v; boost::get<int>(v); } ---------------------------- This doesn't compile on Linux 64bits with gcc 4.4.2 20091208 and produces this error message : ---------------------------- > In file included from /usr/include/boost/graph/graph_concepts.hpp:17, > from /usr/include/boost/graph/breadth_first_search.hpp:21, > from var.cc:2: > /usr/include/boost/property_map/property_map.hpp: In instantiation of ‘boost::property_traits<int>’: > /usr/include/boost/graph/two_bit_color_map.hpp:46: instantiated from ‘boost::two_bit_color_map<int>’ > var.cc:8: instantiated from here > /usr/include/boost/property_map/property_map.hpp:31: error: ‘int’ is not a class, struct, or union type > /usr/include/boost/property_map/property_map.hpp:32: error: ‘int’ is not a class, struct, or union type > /usr/include/boost/property_map/property_map.hpp:33: error: ‘int’ is not a class, struct, or union type > /usr/include/boost/property_map/property_map.hpp:34: error: ‘int’ is not a class, struct, or union type ---------------------------- Could there be a conflict between boost.variant and boost.graph or did I miss something ? Thanks, -- Maxime

2 4

[asio] asio-client only connects to server when on same machine
by Grotjahn Clemens (CM-AI/PJ-CF22) 14 Jan '10

14 Jan '10

hi everybody, i have an issue with my asio-client that wants to connect to an asio-server. when i set my server on a machine in our network to listening on a port (>1024) and then try to connect with my client via this port, i get a "Connection refused"-exception. this happens every time the server and client are located on different machines. if i try this on the same machine it works fine! also, if i try to connect via telnet from another machine it works! here's the client-setup-code snippet, maybe i missed a special config there?: tcp::resolver resolver( _io ); //_io is class-member tcp::resolver::query query( server, port ); //server and port are char-buffers tcp::resolver::iterator iter = resolver.resolve( query ); _socket = new tcp::socket( _io ); tcp::resolver::iterator end; // End marker. boost::system::error_code error = error::host_not_found; while (error && iter != end) { _socket->close(); _socket->connect(*iter++, error); } if (error) throw boost::system::system_error( error ); } catch( std::exception& e ) { cout << "NetClient Konstruktor: " << e.what() << endl; }

2 1

[GIL] Black filled or not ?
by Eloi Du Bois 14 Jan '10

14 Jan '10

Hi all ! I would like to know, when creating an image like that: rgb32f_image_t img(w, h); is the image filled with 0 by default or should I call fill_pixels ? Thank you ! Eloi.

4 8

Re: [Boost-users] [math][special_functions] Why is cbrt(x) slower than pow(x, 1/3)?
by Tim Odenthal 14 Jan '10

14 Jan '10

On Thursday 14 January 2010 07:14:28 boost-users-request(a)lists.boost.org wrote: > So I tried to improve performance on my first guess, namely > > > pow(x, > > 1/3) using boost::math::cbrt(). To my astonishment, this is much slower > > than > > the original code. I wrote a small test program to check this claim; > > compiling > > with g++ (Ubuntu 4.4.1-4ubuntu9) 4.4.1 (-O3) on a Intel Core i7 CPU I get > > the > > following timings (averaging the time over 10 trials): > > average time to compute 5000000 roots with pow(): 0.603 s. > > average time to compute 5000000 roots with boost::cbrt(): 1.087 s. > > average time to compute 5000000 roots with improved boost::cbrt(): 1.015 > > s. > > average time to compute 5000000 roots with exp(1/3*log()): 0.541 s. > > I'll investigate that - I admit I haven't profiled that function up till > now - and I suspect you're on the right lines by suspecting that the > current implementation may be slow in finding the initial starting guess. > > I suspect that some of the std:: functions may be faster if they're > implemented as intrinsics, BTW have you tried ::cbrt in math.h ? > > Cheers, John. > Hi! Thanks a lot for the suggestion: I didn't know that std::cbrt() exists! I alway relied on cplusplus.com as reference; I will have to change that! Of course this is again a lot faster: average time to compute 5000000 roots with pow(): 0.613 s. average time to compute 5000000 roots with cbrt(): 0.464 s. Thanks again - I am happy now... ;-) Tim

2 1