Menu
▾
▴
cpp-netlib-devel — Developers Mailing List
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(52) |
Jun
(30) |
Jul
(17) |
Aug
(9) |
Sep
(4) |
Oct
(7) |
Nov
(11) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(1) |
Mar
(37) |
Apr
(28) |
May
(15) |
Jun
(28) |
Jul
(7) |
Aug
(125) |
Sep
(116) |
Oct
(85) |
Nov
(14) |
Dec
(6) |
| 2009 |
Jan
(11) |
Feb
(4) |
Mar
(5) |
Apr
|
May
(9) |
Jun
(5) |
Jul
(4) |
Aug
(40) |
Sep
(1) |
Oct
(19) |
Nov
(43) |
Dec
(45) |
| 2010 |
Jan
(76) |
Feb
(95) |
Mar
(3) |
Apr
(23) |
May
(39) |
Jun
(54) |
Jul
(6) |
Aug
(13) |
Sep
(12) |
Oct
(59) |
Nov
(53) |
Dec
(43) |
| 2011 |
Jan
(43) |
Feb
(44) |
Mar
(25) |
Apr
(23) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
|
From: Ryan B. <rb...@pd...> - 2011-02-18 18:23:34
|
Correct, I'm using netlib 0.8.1.
Fortunately I figured it out, after taking a break from the problem.
The fix was to remove BOOST_NO_INTRINSIC_WCHAR_T define that we have been using to build boost.
Here is the error, in case anyone else comes across the same problem.
1>C:\Work\trunk\boost_1_45_0\boost/type_traits/make_unsigned.hpp(38) : error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>'
1> with
1> [
1> x=false
1> ]
1> C:\Work\trunk\boost_1_45_0\boost/type_traits/make_unsigned.hpp(130) : see reference to class template instantiation 'boost::detail::make_unsigned_imp<T>' being compiled
1> with
1> [
1> T=wchar_t
1> ]
1> C:\Work\trunk\boost_1_45_0\boost/spirit/home/support/utf8.hpp(35) : see reference to class template instantiation 'boost::make_unsigned<T>' being compiled
1> with
1> [
1> T=wchar_t
1> ]
1> C:\Work\trunk\boost_1_45_0\boost/spirit/home/support/info.hpp(53) : see reference to function template instantiation 'boost::spirit::utf8_string boost::spirit::to_utf8<wchar_t>(Char)' being compiled
1> with
1> [
1> Char=wchar_t
1> ]
Thanks
-----Original Message-----
From: Dean Michael Berris [mailto:mik...@gm...]
Sent: Thursday, February 17, 2011 7:25 PM
To: C++ Networking Library Developers Mailing List
Cc: Ryan Barr
Subject: Re: [cpp-netlib-devel] compile error building with boost 1.45 and VS2008
Hi Ryan,
On Fri, Feb 18, 2011 at 6:46 AM, Ryan Barr <rb...@pd...> wrote:
> Hi, I’m trying to use your library for my project, but I get the following
> compile error when I add
>
> #include <boost/network/protocol/http/client.hpp>
>
> To my code.
>
Can you post a minimal example? How about if you just include that in
an (empty) cpp file like this:
#include <boost/network/protocol/http/client.hpp>
int main(int argc, char * argv[]) {
return 0;
}
Do you still get the error?
>
>
> error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>'
>
> C:\Work\trunk\boost_1_45_0\boost\type_traits\make_unsigned.hpp 38
>
>
>
> I’m using boost 1.45 and have tried cpp-netlib 0.8 and current development
> version.
>
0.8.1 you mean?
>
>
> All my other code that relies on boost works fine.
>
>
>
> I’m on Vista x86, using VS2008. I use CMake and I defined
> BOOST_FILESYSTEM_VERSION to 2.
>
>
>
> Any ideas?
>
>
It would be hard to diagnose the problem without more context. Can you
post the full error? Or is the above the full error that you get?
Unfortunately I have no access to VS2008 at the moment. For the
meantime maybe others can help out?
>
> Thank you
>
I'm sorry I can't be of much help yet. Looking forward to being able
to help you out more later.
--
Dean Michael Berris
about.me/deanberris
|
|
From: Dean M. B. <mik...@gm...> - 2011-02-18 03:28:51
|
On Thu, Feb 17, 2011 at 11:18 PM, Gregory Symons <gs...@dr...> wrote: > On Thu, 2011-02-17 at 11:07 +0800, Dean Michael Berris wrote: >> On Thu, Feb 17, 2011 at 1:22 AM, Gregory Symons >> <gs...@dr...> wrote: >> > So now that I've got things building in Linux (I'm working on cleaning >> > up those changes for pull request), I also need things to build on >> > Windows with VS 2010 (no openssl for now; we actually don't need secure >> > connections in our product. Yet:). Has anyone tried to do that? I'm >> > seeing some weird compile errors, and I want to make sure they're not >> > caused by my CMake hacks before I think about them too hard. >> > >> >> Cool! >> >> BTW, the CMake configuration (in 0.9-devel) will try to look for >> OpenSSL and if it's not found a preprocessor definition is avoided >> that would make the library rely on OpenSSL. More specifically, if it >> can't find OpenSSL development files, BOOST_NETWORK_ENABLE_HTTPS is >> not defined. > > I saw that, but the CMakelists.txt for the examples still explicitly > adds OPENSSL_LIBRARIES to the link, and CMake complains about it being > set to not found. That change is among the others that I made > Ah, for the *examples*. I never actually thought of that part. >> >> > I'm actually using the Windows SDK (not a full version of Visual Studio) >> > with CMake generated solution files and MSBuild. >> > >> > Here are some example errors that I'm seeing. Like I said, they're >> > weird: >> > > >> > >> >> Hmm... these errors looks suspicious. These don't happen on Linux? > > No. As far as I can tell, everything builds cleanly on Linux. As it > turns out, I rolled back both to a virgin 0.9-devel and a 0.8.1-devel > and tried to build against a static boost without any of the CMake > hackery (except the OpenSSL one for the examples), and still couldn't > build. > > Has anyone tried to build with VS 2010 before this? I saw some > references to VS 2008 on the list, but none for VS 2010. > I had been developing on VS 2010 for a while last yer, but I've since Oct. 2010 have not had access to VS 2010 again. Do you know exactly where in which test this is failing? I can't shake the feeling that this might have something to do with Boost.Test or another Boost library's differences in Windows and Linux. Looking forward to hearing from you again soon and hopefully cracking this VS2010 nut without me having access to that compiler in the meantime. -- Dean Michael Berris about.me/deanberris |
|
From: Dean M. B. <mik...@gm...> - 2011-02-18 03:25:34
|
Hi Ryan,
On Fri, Feb 18, 2011 at 6:46 AM, Ryan Barr <rb...@pd...> wrote:
> Hi, I’m trying to use your library for my project, but I get the following
> compile error when I add
>
> #include <boost/network/protocol/http/client.hpp>
>
> To my code.
>
Can you post a minimal example? How about if you just include that in
an (empty) cpp file like this:
#include <boost/network/protocol/http/client.hpp>
int main(int argc, char * argv[]) {
return 0;
}
Do you still get the error?
>
>
> error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>'
>
> C:\Work\trunk\boost_1_45_0\boost\type_traits\make_unsigned.hpp 38
>
>
>
> I’m using boost 1.45 and have tried cpp-netlib 0.8 and current development
> version.
>
0.8.1 you mean?
>
>
> All my other code that relies on boost works fine.
>
>
>
> I’m on Vista x86, using VS2008. I use CMake and I defined
> BOOST_FILESYSTEM_VERSION to 2.
>
>
>
> Any ideas?
>
>
It would be hard to diagnose the problem without more context. Can you
post the full error? Or is the above the full error that you get?
Unfortunately I have no access to VS2008 at the moment. For the
meantime maybe others can help out?
>
> Thank you
>
I'm sorry I can't be of much help yet. Looking forward to being able
to help you out more later.
--
Dean Michael Berris
about.me/deanberris
|
|
From: Ryan B. <rb...@pd...> - 2011-02-17 22:46:21
|
Hi, I'm trying to use your library for my project, but I get the following
compile error when I add
#include <boost/network/protocol/http/client.hpp>
To my code.
error C2027: use of undefined type 'boost::STATIC_ASSERTION_FAILURE<x>'
C:\Work\trunk\boost_1_45_0\boost\type_traits\make_unsigned.hpp 38
I'm using boost 1.45 and have tried cpp-netlib 0.8 and current development
version.
All my other code that relies on boost works fine.
I'm on Vista x86, using VS2008. I use CMake and I defined
BOOST_FILESYSTEM_VERSION to 2.
Any ideas?
Thank you
|
|
From: Gregory S. <gs...@dr...> - 2011-02-17 15:19:12
|
On Thu, 2011-02-17 at 11:07 +0800, Dean Michael Berris wrote: > On Thu, Feb 17, 2011 at 1:22 AM, Gregory Symons > <gs...@dr...> wrote: > > So now that I've got things building in Linux (I'm working on cleaning > > up those changes for pull request), I also need things to build on > > Windows with VS 2010 (no openssl for now; we actually don't need secure > > connections in our product. Yet:). Has anyone tried to do that? I'm > > seeing some weird compile errors, and I want to make sure they're not > > caused by my CMake hacks before I think about them too hard. > > > > Cool! > > BTW, the CMake configuration (in 0.9-devel) will try to look for > OpenSSL and if it's not found a preprocessor definition is avoided > that would make the library rely on OpenSSL. More specifically, if it > can't find OpenSSL development files, BOOST_NETWORK_ENABLE_HTTPS is > not defined. I saw that, but the CMakelists.txt for the examples still explicitly adds OPENSSL_LIBRARIES to the link, and CMake complains about it being set to not found. That change is among the others that I made > > > I'm actually using the Windows SDK (not a full version of Visual Studio) > > with CMake generated solution files and MSBuild. > > > > Here are some example errors that I'm seeing. Like I said, they're > > weird: > > > > > > Hmm... these errors looks suspicious. These don't happen on Linux? No. As far as I can tell, everything builds cleanly on Linux. As it turns out, I rolled back both to a virgin 0.9-devel and a 0.8.1-devel and tried to build against a static boost without any of the CMake hackery (except the OpenSSL one for the examples), and still couldn't build. Has anyone tried to build with VS 2010 before this? I saw some references to VS 2008 on the list, but none for VS 2010. > Looking forward to the completed CMake hacks. :) > > Thanks for the effort Gregory! -- Gregory Symons <gs...@dr...> Developer DrillingInfo <http://www.drillinginfo.com> |
|
From: Dean M. B. <mik...@gm...> - 2011-02-17 03:08:27
|
On Thu, Feb 17, 2011 at 1:42 AM, Gregory Symons <gs...@dr...> wrote: > On Wed, 2011-02-16 at 11:22 -0600, Gregory Symons wrote: > > BTW, I'm trying to build against the 0.9-devel branch from > <http://github.com/cpp-netlib/cpp-netlib>. Given that I'm now hacking on > things, I'm working on moving to > <http://github.com/mikhailberis/cpp-netlib>. > That would be most appreciated. :) Looking forward to the pull requests! :D -- Dean Michael Berris about.me/deanberris |
|
From: Dean M. B. <mik...@gm...> - 2011-02-17 03:07:38
|
On Thu, Feb 17, 2011 at 1:22 AM, Gregory Symons <gs...@dr...> wrote: > So now that I've got things building in Linux (I'm working on cleaning > up those changes for pull request), I also need things to build on > Windows with VS 2010 (no openssl for now; we actually don't need secure > connections in our product. Yet:). Has anyone tried to do that? I'm > seeing some weird compile errors, and I want to make sure they're not > caused by my CMake hacks before I think about them too hard. > Cool! BTW, the CMake configuration (in 0.9-devel) will try to look for OpenSSL and if it's not found a preprocessor definition is avoided that would make the library rely on OpenSSL. More specifically, if it can't find OpenSSL development files, BOOST_NETWORK_ENABLE_HTTPS is not defined. > I'm actually using the Windows SDK (not a full version of Visual Studio) > with CMake generated solution files and MSBuild. > > Here are some example errors that I'm seeing. Like I said, they're > weird: > > ".\cpp-netlib\CPP-NETLIB.sln" (default target) (1) -> > ".\cpp-netlib\libs\network\test\http > \cpp-netlib-http-client_constructor_test.vcxproj.metaproj > " (default target) (3) -> > ".\cpp-netlib\libs\network\test\http > \cpp-netlib-http-client_constructor_test.vcxproj" (defaul > t target) (6) -> > (ClCompile target) -> > .\boost\boost/asio/io_service.hpp(533): error C2248: > 'boost::noncopyable_::noncopyable::non > copyable' : cannot access private member declared in class > 'boost::noncopyable_::noncopyable' [.\cpp-netlib\libs\network\test\http > \cpp-netlib-http-client_constructor_test.vcxproj] > > ".\cpp-netlib\CPP-NETLIB.sln" (default target) (1) -> > ".\cpp-netlib\libs\network\test\http > \cpp-netlib-http-client_get_different_port_test.vcxproj.m > etaproj" (default target) (7) -> > ".\cpp-netlib\libs\network\test\http > \cpp-netlib-http-client_get_different_port_test.vcxproj" > (default target) (8) -> > .\cpp-netlib > \boost/network/protocol/http/policies/simple_connection.hpp(57): error > C2440: ' > initializing' : cannot convert from 'std::_Tree_const_iterator<_Mytree>' > to 'std::_Tree_const_iterator<_Mytree>' [.\cpp-netlib\libs\network\test > \http\cpp-netlib-http-client_get_different_port_test.vcxproj] > .\cpp-netlib > \boost/network/protocol/http/policies/simple_connection.hpp(58): error > C2678: binary '!=' : no operator found which takes a left-hand operand > of type 'std::_Tree_const_iterator<_Mytree>' (or there is no accepta > ble conversion) [.\cpp-netlib\libs\network\test\http > \cpp-netlib-http-client_get_different_port_test.vcxproj] > Hmm... these errors looks suspicious. These don't happen on Linux? > There are other problems that are definitely the result of my > (apparently still incomplete) CMake hacks to build against dynamic > libraries, but the compile errors don't make any sense. > Looking forward to the completed CMake hacks. :) Thanks for the effort Gregory! -- Dean Michael Berris about.me/deanberris |
|
From: Gregory S. <gs...@dr...> - 2011-02-16 17:42:38
|
On Wed, 2011-02-16 at 11:22 -0600, Gregory Symons wrote: > So now that I've got things building in Linux (I'm working on cleaning > up those changes for pull request), I also need things to build on > Windows with VS 2010 (no openssl for now; we actually don't need secure > connections in our product. Yet:). Has anyone tried to do that? I'm > seeing some weird compile errors, and I want to make sure they're not > caused by my CMake hacks before I think about them too hard. > > I'm actually using the Windows SDK (not a full version of Visual Studio) > with CMake generated solution files and MSBuild. [snip] > There are other problems that are definitely the result of my > (apparently still incomplete) CMake hacks to build against dynamic > libraries, but the compile errors don't make any sense. BTW, I'm trying to build against the 0.9-devel branch from <http://github.com/cpp-netlib/cpp-netlib>. Given that I'm now hacking on things, I'm working on moving to <http://github.com/mikhailberis/cpp-netlib>. -- Gregory Symons <gs...@dr...> Developer DrillingInfo <http://www.drillinginfo.com> |
|
From: Gregory S. <gs...@dr...> - 2011-02-16 17:22:29
|
So now that I've got things building in Linux (I'm working on cleaning up those changes for pull request), I also need things to build on Windows with VS 2010 (no openssl for now; we actually don't need secure connections in our product. Yet:). Has anyone tried to do that? I'm seeing some weird compile errors, and I want to make sure they're not caused by my CMake hacks before I think about them too hard. I'm actually using the Windows SDK (not a full version of Visual Studio) with CMake generated solution files and MSBuild. Here are some example errors that I'm seeing. Like I said, they're weird: ".\cpp-netlib\CPP-NETLIB.sln" (default target) (1) -> ".\cpp-netlib\libs\network\test\http \cpp-netlib-http-client_constructor_test.vcxproj.metaproj " (default target) (3) -> ".\cpp-netlib\libs\network\test\http \cpp-netlib-http-client_constructor_test.vcxproj" (defaul t target) (6) -> (ClCompile target) -> .\boost\boost/asio/io_service.hpp(533): error C2248: 'boost::noncopyable_::noncopyable::non copyable' : cannot access private member declared in class 'boost::noncopyable_::noncopyable' [.\cpp-netlib\libs\network\test\http \cpp-netlib-http-client_constructor_test.vcxproj] ".\cpp-netlib\CPP-NETLIB.sln" (default target) (1) -> ".\cpp-netlib\libs\network\test\http \cpp-netlib-http-client_get_different_port_test.vcxproj.m etaproj" (default target) (7) -> ".\cpp-netlib\libs\network\test\http \cpp-netlib-http-client_get_different_port_test.vcxproj" (default target) (8) -> .\cpp-netlib \boost/network/protocol/http/policies/simple_connection.hpp(57): error C2440: ' initializing' : cannot convert from 'std::_Tree_const_iterator<_Mytree>' to 'std::_Tree_const_iterator<_Mytree>' [.\cpp-netlib\libs\network\test \http\cpp-netlib-http-client_get_different_port_test.vcxproj] .\cpp-netlib \boost/network/protocol/http/policies/simple_connection.hpp(58): error C2678: binary '!=' : no operator found which takes a left-hand operand of type 'std::_Tree_const_iterator<_Mytree>' (or there is no accepta ble conversion) [.\cpp-netlib\libs\network\test\http \cpp-netlib-http-client_get_different_port_test.vcxproj] There are other problems that are definitely the result of my (apparently still incomplete) CMake hacks to build against dynamic libraries, but the compile errors don't make any sense. -- Gregory Symons <gs...@dr...> Developer DrillingInfo <http://www.drillinginfo.com> |
|
From: Dean M. B. <mik...@gm...> - 2011-02-16 03:59:38
|
On Wed, Feb 16, 2011 at 11:28 AM, Oleg Malashenko <ole...@gm...> wrote: > On 16.02.2011 12:46, Dean Michael Berris wrote: >> On Wed, Feb 16, 2011 at 10:38 AM, Oleg Malashenko >> <ole...@gm...> wrote: >>> On 16.02.2011 03:38, Gregory Symons wrote: >>>> The following tests FAILED: >>>> 14 - cpp-netlib-hello_world (Failed) >>>> 15 - cpp-netlib-http_async_server (Failed) >>>> 16 - cpp-netlib-http_server_async_less_copy (Failed) >>>> 17 - mime-roundtrip (Failed) >>>> >>>> Looking closely at the verbose test output, it looks like they all >>>> failed because the address they were trying to bring up the server on >>>> was still in use. >>>> >>> >>> Will you please try it with the following patch? >>> >> >> Why isn't this a pull request Oleg? :D >> > > Because I don't know if it is going to work. Actually, you're right. It won't work... > In fact, terminating test > applications is not the best way to close network sockets (see > http_server_async_less_copy). If test suite doesn't actually try to run > several tests simultaneously and they all try bind to the same port, > than I think we hit TIME_WAIT problem here. > http://hea-www.harvard.edu/~fine/Tech/addrinuse.html > ... because there's no cross-platform reliable way to run the test from Python and tell the spawned process to die -- unless you want to deal with pipes and all that (not-so-)goodness. Unless someone wants to maintain a signal handler for Windows and various flavors of Unix just for the test servers (I don't), it's better to have the port be a runtime parameter to the application, and use one port for each test. Also maybe making a test-specific "kill handler", like a special URL that would actually trigger a call to a server's stop method would be a good way to do it. Even then though the TIMED_WAIT problem would still be there on the server port in which case we'll still need the runtime port number option. > Oh, and Gregory, I almost forgot about sync server. Here is the new > patch, that sets SO_REUSEADDR in sync_server as well as in async_server. > This will only work if it's the same binary trying to re-use the address. In 0.9-devel I already have this as a constructor parameter. Also, this has some serious weirdness on Windows too as reported by Erik a while back -- which is why the SO_REUSEADDR setting was removed from the server core and moved into a Boost.Parameter option in 0.9-devel. HTH -- Dean Michael Berris about.me/deanberris |
|
From: Oleg M. <ole...@gm...> - 2011-02-16 03:28:43
|
On 16.02.2011 12:46, Dean Michael Berris wrote: > On Wed, Feb 16, 2011 at 10:38 AM, Oleg Malashenko > <ole...@gm...> wrote: >> On 16.02.2011 03:38, Gregory Symons wrote: >>> The following tests FAILED: >>> 14 - cpp-netlib-hello_world (Failed) >>> 15 - cpp-netlib-http_async_server (Failed) >>> 16 - cpp-netlib-http_server_async_less_copy (Failed) >>> 17 - mime-roundtrip (Failed) >>> >>> Looking closely at the verbose test output, it looks like they all >>> failed because the address they were trying to bring up the server on >>> was still in use. >>> >> >> Will you please try it with the following patch? >> > > Why isn't this a pull request Oleg? :D > Because I don't know if it is going to work. In fact, terminating test applications is not the best way to close network sockets (see http_server_async_less_copy). If test suite doesn't actually try to run several tests simultaneously and they all try bind to the same port, than I think we hit TIME_WAIT problem here. http://hea-www.harvard.edu/~fine/Tech/addrinuse.html Oh, and Gregory, I almost forgot about sync server. Here is the new patch, that sets SO_REUSEADDR in sync_server as well as in async_server. -- Best regards, Oleg Malashenko. |
|
From: Dean M. B. <mik...@gm...> - 2011-02-16 02:52:00
|
On Wed, Feb 16, 2011 at 10:38 AM, Oleg Malashenko <ole...@gm...> wrote: > On 16.02.2011 03:38, Gregory Symons wrote: >> The following tests FAILED: >> 14 - cpp-netlib-hello_world (Failed) >> 15 - cpp-netlib-http_async_server (Failed) >> 16 - cpp-netlib-http_server_async_less_copy (Failed) >> 17 - mime-roundtrip (Failed) >> >> Looking closely at the verbose test output, it looks like they all >> failed because the address they were trying to bring up the server on >> was still in use. >> > > Will you please try it with the following patch? > Why isn't this a pull request Oleg? :D -- Dean Michael Berris about.me/deanberris |
|
From: Oleg M. <ole...@gm...> - 2011-02-16 02:39:10
|
On 16.02.2011 03:38, Gregory Symons wrote: > The following tests FAILED: > 14 - cpp-netlib-hello_world (Failed) > 15 - cpp-netlib-http_async_server (Failed) > 16 - cpp-netlib-http_server_async_less_copy (Failed) > 17 - mime-roundtrip (Failed) > > Looking closely at the verbose test output, it looks like they all > failed because the address they were trying to bring up the server on > was still in use. > Will you please try it with the following patch? -- Best regards, Oleg Malashenko. |
|
From: Dean M. B. <mik...@gm...> - 2011-02-15 17:57:11
|
On Wed, Feb 16, 2011 at 1:38 AM, Gregory Symons <gs...@dr...> wrote: > On Wed, 2011-02-16 at 01:17 +0800, Dean Michael Berris wrote: >> Hi Gregory, >> >> On Tue, Feb 15, 2011 at 11:42 PM, Gregory Symons > [snip] >> > >> > My boost has everything built as shared libraries, so I've tried adding >> > BOOST_TEST_DYN_LINK and BOOST_TEST_MAIN to CXXFLAGS, but that doesn't >> > seem to have an effect. >> > >> > Any ideas? >> > >> >> Actually, currently the unit tests require that Boost.Test be linked >> in statically. >> >> I haven't added in the capability for configuring the testing system >> through CMake to accept these or additional settings. > > That would explain it. I'm not terribly familiar with CMake, and looking > through the FindBoost documentation, I didn't see an easy way to > determine that things should be dynamically linked. After hacking > CMakelists.txt to have the BOOST_TEST_DYN_LINK in the compile flags, I > was able to get everything to build. But I'm pretty sure that's not the > "right" way to do it. > Well, that would one way to do it -- but there's a more generic way which should allow users to define variables on the cmake command-line to give more information to cmake and allow the generated build files to contain the correct directives. That requires some cmake kung fu that I haven't the time to deal with yet. ;) > Once they built, I had several test failures: > > The following tests FAILED: > 14 - cpp-netlib-hello_world (Failed) > 15 - cpp-netlib-http_async_server (Failed) > 16 - cpp-netlib-http_server_async_less_copy (Failed) > 17 - mime-roundtrip (Failed) > > Looking closely at the verbose test output, it looks like they all > failed because the address they were trying to bring up the server on > was still in use. > Yes, which since you've mentioned you're on Ubuntu, is actually expected. I haven't found a solution to this problem yet though, feedback and suggestions would be most appreciated. Short of installing a signal handler on the server code (which would not be easy to make cross-platform), I don't see a way to make this easily done unless I use different ports for each server (or take the port as an argument on the command-line). Pull requests for those would be greatly appreciated. :D Thanks Gregory for reporting! :) -- Dean Michael Berris about.me/deanberris |
|
From: Gregory S. <gs...@dr...> - 2011-02-15 17:38:41
|
On Wed, 2011-02-16 at 01:17 +0800, Dean Michael Berris wrote: > Hi Gregory, > > On Tue, Feb 15, 2011 at 11:42 PM, Gregory Symons [snip] > > > > My boost has everything built as shared libraries, so I've tried adding > > BOOST_TEST_DYN_LINK and BOOST_TEST_MAIN to CXXFLAGS, but that doesn't > > seem to have an effect. > > > > Any ideas? > > > > Actually, currently the unit tests require that Boost.Test be linked > in statically. > > I haven't added in the capability for configuring the testing system > through CMake to accept these or additional settings. That would explain it. I'm not terribly familiar with CMake, and looking through the FindBoost documentation, I didn't see an easy way to determine that things should be dynamically linked. After hacking CMakelists.txt to have the BOOST_TEST_DYN_LINK in the compile flags, I was able to get everything to build. But I'm pretty sure that's not the "right" way to do it. Once they built, I had several test failures: The following tests FAILED: 14 - cpp-netlib-hello_world (Failed) 15 - cpp-netlib-http_async_server (Failed) 16 - cpp-netlib-http_server_async_less_copy (Failed) 17 - mime-roundtrip (Failed) Looking closely at the verbose test output, it looks like they all failed because the address they were trying to bring up the server on was still in use. -- Gregory Symons <gs...@dr...> Developer DrillingInfo <http://www.drillinginfo.com> |
|
From: Dean M. B. <mik...@gm...> - 2011-02-15 17:17:57
|
Hi Gregory, On Tue, Feb 15, 2011 at 11:42 PM, Gregory Symons <gs...@dr...> wrote: > Hi, > > I'm trying to build the tests using gcc 4.4 on linux, and I can't seem > to figure out what's going wrong. Running cmake works fine, and the > boost libraries are all found correctly, but when I run make, it fails > to link on the first test: > > Linking CXX executable ../../../build/tests/cpp-netlib-http_1_0_test > /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o: In function > `_start': > (.text+0x20): undefined reference to `main' > collect2: ld returned 1 exit status > make[2]: *** [build/tests/cpp-netlib-http_1_0_test] Error 1 > make[1]: *** > [libs/network/test/CMakeFiles/cpp-netlib-http_1_0_test.dir/all] Error 2 > make: *** [all] Error 2 > > My boost has everything built as shared libraries, so I've tried adding > BOOST_TEST_DYN_LINK and BOOST_TEST_MAIN to CXXFLAGS, but that doesn't > seem to have an effect. > > Any ideas? > Actually, currently the unit tests require that Boost.Test be linked in statically. I haven't added in the capability for configuring the testing system through CMake to accept these or additional settings. HTH -- Dean Michael Berris about.me/deanberris |
|
From: Gregory S. <gs...@dr...> - 2011-02-15 15:42:23
|
Hi, I'm trying to build the tests using gcc 4.4 on linux, and I can't seem to figure out what's going wrong. Running cmake works fine, and the boost libraries are all found correctly, but when I run make, it fails to link on the first test: Linking CXX executable ../../../build/tests/cpp-netlib-http_1_0_test /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: ld returned 1 exit status make[2]: *** [build/tests/cpp-netlib-http_1_0_test] Error 1 make[1]: *** [libs/network/test/CMakeFiles/cpp-netlib-http_1_0_test.dir/all] Error 2 make: *** [all] Error 2 My boost has everything built as shared libraries, so I've tried adding BOOST_TEST_DYN_LINK and BOOST_TEST_MAIN to CXXFLAGS, but that doesn't seem to have an effect. Any ideas? -- Gregory Symons <gs...@dr...> Developer DrillingInfo <http://www.drillinginfo.com> |
|
From: Dean M. B. <mik...@gm...> - 2011-02-15 00:44:56
|
2011/2/15 Stéphane Charette <ste...@gm...>: > Trying to use cpp-netlib for the first time. Development environment (I > don't get to control this) is Ubuntu 10.04. > Cool! > Default boost in Ubuntu 10.04 is 1.40, which doesn't work for cpp-netlib. > Immediately dies during compilation of my test app due to > boost/thread/future.hpp not existing. > Yes, and it's generally discouraged to use the Boost that's distributed with the Linux distributions. Always get your Boost from http://www.boost.org/ and the sourceforge link that's provided there. > That brought me to boost v1.42 from > https://launchpad.net/~gezakovacs/+archive/boost. > > This one doesn't work due to boost/range/algorithm/transform.hpp not > existing, and dozens of things like: > /usr/include/boost/thread/future.hpp:93: error: ‘mutex’ in namespace ‘boost’ > does not name a type > /usr/include/boost/thread/future.hpp:94: error: ‘condition_variable’ in > namespace ‘boost’ does not name a type > /usr/include/boost/thread/future.hpp:95: error: ‘condition_variable_any’ is > not a member of ‘boost’ > Yes, 1.42 won't work. > I'm in the process of figuring out how to get boost 1.45 installed. How can > I find out what minimum version of boost is required for cpp-netlib? > The minimum is 1.45. > And if I was to downgrade cpp-netlib to something earlier than 0.8.1, do I > have a chance of getting cpp-netlib working with boost 1.42? > Hmmm... that's tricky. I think 0.7 will work with 1.42 but you don't get the async features in 0.8 and later versions. Earlier versions than 0.7 isn't really recommended as a lot of things have already happened between 0.7 and 0.8 -- for now your best bet would be to use 0.8 with Boost 1.45. HTH -- Dean Michael Berris about.me/deanberris |
|
From: Dean M. B. <mik...@gm...> - 2011-02-15 00:37:52
|
2011/2/15 Stéphane Charette <ste...@gm...>: > I'm compiling my test app with Boost v1.45 and cpp-netlib 0.8.1. I see the > following warnings in the build logs: > > In file included from > /usr/local/include/cpp-netlib/boost/network/message.hpp:16, > from /usr/local/include/cpp-netlib/boost/network.hpp:15, > from /home/stephane/workspace/[cut]: > /usr/local/include/cpp-netlib/boost/network/message/directives.hpp: In > constructor > ‘boost::network::source_directive_base::normal_visitor<Message>::normal_visitor(const > Message&)’: > /usr/local/include/cpp-netlib/boost/network/message/directives.hpp:26: > warning: declaration of ‘message’ shadows a member of 'this' [-Wshadow] > /usr/local/include/cpp-netlib/boost/network/message/directives.hpp: In > constructor > ‘boost::network::source_directive_base::pod_visitor<Message>::pod_visitor(const > Message&)’: > /usr/local/include/cpp-netlib/boost/network/message/directives.hpp:26: > warning: declaration of ‘message’ shadows a member of 'this' [-Wshadow] > Which compiler are you using and on what platform? Also are you using bjam to build or are you using CMake? It also looks like you're using it in your own application. It would be great if you can post a minimal example that would help me better diagnose the problem. > And: > > In file included from > /usr/local/include/cpp-netlib/boost/network/protocol/http/response.hpp:15, > from > /usr/local/include/cpp-netlib/boost/network/protocol/http.hpp:15, > from > /usr/local/include/cpp-netlib/boost/network/protocol.hpp:15, > from /usr/local/include/cpp-netlib/boost/network.hpp:16, > from /home/stephane/workspace/[cut]: > /usr/local/include/cpp-netlib/boost/network/protocol/http/message/directives/status_message.hpp: > In constructor > ‘boost::network::http::status_message_directive_base::normal_visitor<Message>::normal_visitor(const > Message&)’: > /usr/local/include/cpp-netlib/boost/network/protocol/http/message/directives/status_message.hpp:15: > warning: declaration of ‘message’ shadows a member of 'this' [-Wshadow] > /usr/local/include/cpp-netlib/boost/network/protocol/http/message/directives/status_message.hpp: > In constructor > ‘boost::network::http::status_message_directive_base::pod_visitor<Message>::pod_visitor(const > Message&)’: > /usr/local/include/cpp-netlib/boost/network/protocol/http/message/directives/status_message.hpp:15: > warning: declaration of ‘message’ shadows a member of 'this' [-Wshadow] > > And: > > In file included from > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/message_traits.hpp:53, > from > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits.hpp:15, > from > /usr/local/include/cpp-netlib/boost/network/protocol/http/message.hpp:16, > from > /usr/local/include/cpp-netlib/boost/network/protocol/http/response.hpp:36, > from > /usr/local/include/cpp-netlib/boost/network/protocol/http.hpp:15, > from > /usr/local/include/cpp-netlib/boost/network/protocol.hpp:15, > from /usr/local/include/cpp-netlib/boost/network.hpp:16, > from /home/stephane/workspace/[cut]: > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/delimiters.ipp: > At global scope: > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/delimiters.ipp:17: > warning: type qualifiers ignored on function return type > [-Wignored-qualifiers] > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/delimiters.ipp:22: > warning: type qualifiers ignored on function return type > [-Wignored-qualifiers] > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/delimiters.ipp:27: > warning: type qualifiers ignored on function return type > [-Wignored-qualifiers] > In file included from > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/message_traits.hpp:54, > from > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits.hpp:15, > from > /usr/local/include/cpp-netlib/boost/network/protocol/http/message.hpp:16, > from > /usr/local/include/cpp-netlib/boost/network/protocol/http/response.hpp:36, > from > /usr/local/include/cpp-netlib/boost/network/protocol/http.hpp:15, > from > /usr/local/include/cpp-netlib/boost/network/protocol.hpp:15, > from /usr/local/include/cpp-netlib/boost/network.hpp:16, > from /home/stephane/workspace/[cut]: > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:16: > warning: type qualifiers ignored on function return type > [-Wignored-qualifiers] > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:21: > warning: type qualifiers ignored on function return type > [-Wignored-qualifiers] > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:26: > warning: type qualifiers ignored on function return type > [-Wignored-qualifiers] > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:31: > warning: type qualifiers ignored on function return type > [-Wignored-qualifiers] > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:36: > warning: type qualifiers ignored on function return type > [-Wignored-qualifiers] > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:41: > warning: type qualifiers ignored on function return type > [-Wignored-qualifiers] > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:46: > warning: type qualifiers ignored on function return type > [-Wignored-qualifiers] > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:51: > warning: type qualifiers ignored on function return type > [-Wignored-qualifiers] > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:56: > warning: type qualifiers ignored on function return type > [-Wignored-qualifiers] > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:61: > warning: type qualifiers ignored on function return type > [-Wignored-qualifiers] > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:66: > warning: type qualifiers ignored on function return type > [-Wignored-qualifiers] > /usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:71: > warning: type qualifiers ignored on function return type > [-Wignored-qualifiers] > This is a new one on me. I think 0.9-devel has been developed with the -Wall option, but this one looks like you're using the -pedantic option (is that correct?). I'll try building/running the tests with -Wall on 0.8.1 and see if I can reproduce. Also, do you mind filing issues on https://github.com/cpp-netlib/cpp-netlib/issues so that we can track the progress on this? Thanks for reporting Stephane! -- Dean Michael Berris about.me/deanberris |
|
From: Stéphane C. <ste...@gm...> - 2011-02-14 23:09:37
|
I'm compiling my test app with Boost v1.45 and cpp-netlib 0.8.1. I see the
following warnings in the build logs:
In file included from
/usr/local/include/cpp-netlib/boost/network/message.hpp:16,
from /usr/local/include/cpp-netlib/boost/network.hpp:15,
from /home/stephane/workspace/[cut]:
/usr/local/include/cpp-netlib/boost/network/message/directives.hpp: In
constructor
‘boost::network::source_directive_base::normal_visitor<Message>::normal_visitor(const
Message&)’:
/usr/local/include/cpp-netlib/boost/network/message/directives.hpp:26:
warning: declaration of ‘message’ shadows a member of 'this' [-Wshadow]
/usr/local/include/cpp-netlib/boost/network/message/directives.hpp: In
constructor
‘boost::network::source_directive_base::pod_visitor<Message>::pod_visitor(const
Message&)’:
/usr/local/include/cpp-netlib/boost/network/message/directives.hpp:26:
warning: declaration of ‘message’ shadows a member of 'this' [-Wshadow]
And:
In file included from
/usr/local/include/cpp-netlib/boost/network/protocol/http/response.hpp:15,
from
/usr/local/include/cpp-netlib/boost/network/protocol/http.hpp:15,
from
/usr/local/include/cpp-netlib/boost/network/protocol.hpp:15,
from /usr/local/include/cpp-netlib/boost/network.hpp:16,
from /home/stephane/workspace/[cut]:
/usr/local/include/cpp-netlib/boost/network/protocol/http/message/directives/status_message.hpp:
In constructor
‘boost::network::http::status_message_directive_base::normal_visitor<Message>::normal_visitor(const
Message&)’:
/usr/local/include/cpp-netlib/boost/network/protocol/http/message/directives/status_message.hpp:15:
warning: declaration of ‘message’ shadows a member of 'this' [-Wshadow]
/usr/local/include/cpp-netlib/boost/network/protocol/http/message/directives/status_message.hpp:
In constructor
‘boost::network::http::status_message_directive_base::pod_visitor<Message>::pod_visitor(const
Message&)’:
/usr/local/include/cpp-netlib/boost/network/protocol/http/message/directives/status_message.hpp:15:
warning: declaration of ‘message’ shadows a member of 'this' [-Wshadow]
And:
In file included from
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/message_traits.hpp:53,
from
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits.hpp:15,
from
/usr/local/include/cpp-netlib/boost/network/protocol/http/message.hpp:16,
from
/usr/local/include/cpp-netlib/boost/network/protocol/http/response.hpp:36,
from
/usr/local/include/cpp-netlib/boost/network/protocol/http.hpp:15,
from
/usr/local/include/cpp-netlib/boost/network/protocol.hpp:15,
from /usr/local/include/cpp-netlib/boost/network.hpp:16,
from /home/stephane/workspace/[cut]:
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/delimiters.ipp:
At global scope:
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/delimiters.ipp:17:
warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/delimiters.ipp:22:
warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/delimiters.ipp:27:
warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
In file included from
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/message_traits.hpp:54,
from
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits.hpp:15,
from
/usr/local/include/cpp-netlib/boost/network/protocol/http/message.hpp:16,
from
/usr/local/include/cpp-netlib/boost/network/protocol/http/response.hpp:36,
from
/usr/local/include/cpp-netlib/boost/network/protocol/http.hpp:15,
from
/usr/local/include/cpp-netlib/boost/network/protocol.hpp:15,
from /usr/local/include/cpp-netlib/boost/network.hpp:16,
from /home/stephane/workspace/[cut]:
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:16:
warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:21:
warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:26:
warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:31:
warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:36:
warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:41:
warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:46:
warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:51:
warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:56:
warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:61:
warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:66:
warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
/usr/local/include/cpp-netlib/boost/network/protocol/http/traits/impl/headers.ipp:71:
warning: type qualifiers ignored on function return type
[-Wignored-qualifiers]
|
|
From: Stéphane C. <ste...@gm...> - 2011-02-14 20:17:40
|
Trying to use cpp-netlib for the first time. Development environment (I don't get to control this) is Ubuntu 10.04. Default boost in Ubuntu 10.04 is 1.40, which doesn't work for cpp-netlib. Immediately dies during compilation of my test app due to boost/thread/future.hpp not existing. That brought me to boost v1.42 from https://launchpad.net/~gezakovacs/+archive/boost. This one doesn't work due to boost/range/algorithm/transform.hpp not existing, and dozens of things like: /usr/include/boost/thread/future.hpp:93: error: ‘mutex’ in namespace ‘boost’ does not name a type /usr/include/boost/thread/future.hpp:94: error: ‘condition_variable’ in namespace ‘boost’ does not name a type /usr/include/boost/thread/future.hpp:95: error: ‘condition_variable_any’ is not a member of ‘boost’ I'm in the process of figuring out how to get boost 1.45 installed. How can I find out what minimum version of boost is required for cpp-netlib? And if I was to downgrade cpp-netlib to something earlier than 0.8.1, do I have a chance of getting cpp-netlib working with boost 1.42? Stéphane Charette |
|
From: Dean M. B. <mik...@gm...> - 2011-02-01 22:28:04
|
On Wed, Feb 2, 2011 at 6:21 AM, Nelson, Erik - 2 <eri...@ba...> wrote: > Dean wrote: >> >> Why is copying into a string a problem in the first place? >> > > It's not... you were talking about the extensively documented problem of sending binary as 7-bit clear on the internet- that seems unrelated to whether or not the netlib container is a std::string or something else. > Right, so why are we talking about this again? :D > >> >>>> Erik wrote: >>>>> auto_ptr<MyObject> obj(new MyObject); >>>>> response << body(obj); > > Dean wrote: >> >> Uh oh, this is dangerous because the user can use the obj right >> after the data is passed to the response. > > Erik wrote: >>> Nope- the auto_ptr will be cleared when the ownership transfers to >>> the response, right? > > > Dean wrote: >> Well, after the `response << body(obj)` line, obj is still accessible >> to the user. It's not guaranteed that the user will do this line at >> the end of the handler body. > > Not so. obj is not accessible if ownership has been transferred to the response. Two auto_ptrs can't refer to the same object. > See this code: std::auto_ptr<Foo> f(new Foo); response << body(f); // which would never happen, if I can do anything about it... ;) f->bar(); // and here you get a segfault and angry users. ;) Which is exactly what I want to avoid if I can help it. :) -- Dean Michael Berris about.me/deanberris |
|
From: Nelson, E. - 2 <eri...@ba...> - 2011-02-01 22:21:25
|
Dean wrote: >>> Well, the problem with sending binary data as 7-bit clear over the >>> network has been documented extensively over the Internet. The spec >>> clearly states that you have to be transferring data safe to >>> transfer over 7-bit transfers encoding -- meaning that's technically ASCII >>> text. It is an accident that images are being sent in the clear as >>> binary data, and if you notice in history this is largely why people >>> (browser developers and server developers) had to agree that they >>> would just take whatever was sent over the wire in the body and just >>> have the MIME identifiers there. >>> Erik wrote: >> Either way you're sending binary in these examples... the only issue >> was whether that binary should be copied into a std::string > > Why is copying into a string a problem in the first place? > It's not... you were talking about the extensively documented problem of sending binary as 7-bit clear on the internet- that seems unrelated to whether or not the netlib container is a std::string or something else. > >>> Erik wrote: >>>> auto_ptr<MyObject> obj(new MyObject); >>>> response << body(obj); Dean wrote: > >> Uh oh, this is dangerous because the user can use the obj right > after the data is passed to the response. Erik wrote: >> Nope- the auto_ptr will be cleared when the ownership transfers to >> the response, right? Dean wrote: > Well, after the `response << body(obj)` line, obj is still accessible > to the user. It's not guaranteed that the user will do this line at > the end of the handler body. Not so. obj is not accessible if ownership has been transferred to the response. Two auto_ptrs can't refer to the same object. Erik ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. |
|
From: Nelson, E. - 2 <eri...@ba...> - 2011-02-01 21:41:08
|
> Kim Gräsman wrote on Tuesday, February 01, 2011 3:10 PM > > I agree with this. Using auto_ptr to transfer ownership seems like a > no-brainer. However, it doesn't really solve the > transfer-data-without-copy problem, at least not entirely. > > What if I have a char buffer I got out of some C API, and I'd like to > transfer that; > > char buffer[1024]; > unsigned long bufsize = sizeof(buffer) / sizeof(*buffer); > GetUserNameA(buffer, &bufsize); > > // Now what? > > I think in the cases where your data comes from somewhere out of your > control and it's not packed in an auto_ptr, you'll be just as screwed > as with the current std::string -- in order to get it transferable you > would have to reallocate it into an auto_ptr, and that might even > involve packing it into an auto_ptr< vector<T> >, which feels pretty > raw. > Agreed, a little raw, but clear, and not the worst thing I'll probably do today :P auto_ptr<vector<char> > buffer(new vector<char>(1024)); unsigned long bufsize = buffer->size(); GetUserNameA(&(*buffer)[0], &bufsize); buffer->resize(bufsize); response << body(buffer); not possible to get a leak, and I think there's always going to be a little gear grinding when you mix in the C API. Erik ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. |
|
From: Dean M. B. <mik...@gm...> - 2011-02-01 21:19:44
|
On Wed, Feb 2, 2011 at 3:24 AM, Nelson, Erik - 2
<eri...@ba...> wrote:
>> Dean Michael Berris wrote on Tuesday, February 01, 2011 1:20 PM
>>
>> Well, the problem with sending binary data as 7-bit clear over the
>> network has been documented extensively over the Internet. The spec
>> clearly states that you have to be transferring data safe to transfer
>> over 7-bit transfers encoding -- meaning that's technically ASCII
>> text. It is an accident that images are being sent in the clear as
>> binary data, and if you notice in history this is largely why people
>> (browser developers and server developers) had to agree that they
>> would just take whatever was sent over the wire in the body and just
>> have the MIME identifiers there.
>>
>
> Either way you're sending binary in these examples... the only issue was whether that binary should be copied into a std::string
>
Why is copying into a string a problem in the first place?
>>
>> See, the fact that I'm even using std::string is already something I
>> detest (read the thread about [string]proposal on the Boost ML ;) ) --
>
> I've been reading the (extensive) [string] proposal on boost. :)
>
Ah, so you know the reason why I want a better string is so that I can
use it in cpp-netlib, no? :D
>> but at the moment it is the most sane and simple thing to do lacking a
>> proper efficient segmented data storage mechanism around (no
>> std::deque has its own issues, and ptr_list<array<T,N> > is too
>> "esoteric"). Forcing people to deal with std::vector<char> is just
>> unnecessary when std::string is much more familiar however ugly.
>
> I'm not proposing vector<char>- the foundation of my point is the library *should not* make the container choice for the user. There is no choice that works well for everyone.
>
Right, and it has never been a choice made by the library. It just so
happened that the default is std::string for the string. Anybody can
extend the tag dispatch mechanisms and create their own tags that
define a different string<Tag>::type to yield something other than
std::string.
Actually if I remember correctly, there is a body<Tag>::type
metafunction that I was using to determine what the type of the body
should be. Basically these extension points are still undocumented at
this point and I'm thinking about how to make configuring the types
easier maybe with macro's instead of forcing people who want to extend
the library to learn all the traits and metafunctions that depend on
the tag dispatch. ;)
>> Erik wrote:
>>>
>>> auto_ptr<MyObject> obj(new MyObject);
>>> response << body(obj);
>>>
>
>> Uh oh, this is dangerous because the user can use the obj right after
>> the data is passed to the response.
>
> Nope- the auto_ptr will be cleared when the ownership transfers to the response, right?
>
Well, after the `response << body(obj)` line, obj is still accessible
to the user. It's not guaranteed that the user will do this line at
the end of the handler body. Also, it's not safe to take an arbitrary
void* as well and write that out to the network. That's asking for
trouble not only with the protocol but with C++ in general.
Also, auto_ptr is going away for good reason -- it's an awfully
non-value-semantics playing type.
>> Erik wrote:
>>> should be sufficient for POD types, and for non-POD types, maybe
>>> you'd need something like
>>>
>>> auto_ptr<vector<char> > obj(new vector<char>());
>>> response << body(&(*obj)[0], obj->size(), obj);
>>>
>>
>> And this is just ugly. ;)
>
> A little... think of it from a user standpoint- how would you send an arbitrary object in the response body?
You can't, you need to linearize it to a container that is suitable
for network transfer. That's the whole point of the interface defining
the types -- I'm not about to go back to the days of C where I'll just
treat a thunk of memory as data that I can safely use in the library.
See, the point of the interface is to make things *easy*. There's
absolutely no point in allowing a pointer to an arbitrary type in
memory to be serialized out to a socket. There's 0 utility in that.
Remember also that we're talking about the *synchronous*
implementation. This means there's defined semantics for what a
response type is. If you need to be sending arbitrarily large data in
memory, *don't use the synchronous interface*. Look at what the
fileserver example in 0.9-devel does -- which is actually portable to
0.8.1 IIRC.
> Can you write anything cleaner or more intuitive than
>
> response << body(void*, length) ? The way you're describing makes you write
>
> response.content.resize(length);
> memcpy((void*)response.content.data(), &object, length);
>
> That looks less ugly? More intuitive?
>
Well, there are a few reasons why your suggestion is ugly:
1) You're passing in a naked pointer. That's C'ish of you to suggest. ;)
2) Also, it's largely bad form to try to take a void* when you can get
the type of the object directly. What I aim to do as a library
designer responsible for the interface and the implementation is to
enforce the safety of the interface and the operations which I use.
3) There's absolutely 0 reason for you not to use the string when the
semantics of the handler is to craft a string response. If you want to
send data, you need to send a string in. Even if it is binary data.
There is swap idiom you can use if you don't want copies. It's been
with the STL since the beginning:
std::string my_long_serialized_string = "...";
swap(response.content, my_long_serialized_string); // look ma, no copy
>
>> Erik wrote:
>>>> The response can delete it whenever it's done with doing whatever it
>>> does.
>>>
>>
>> That's bad design. :D
>>
>
> That's what it happens in the current implementation...
Nope.
> the only difference is that it is deleting a copy (that's in the body) instead of the original.
Again, nope. The response object lives as long as the connection is
alive. Nothing gets deleted until all shared references to the
connection go out of scope.
> The issue here is that the lifetime of the response object is longer than the lifetime of the handler function. The solution is going to be to have the response destroy the body memory, either in std::string form (like now) or in original-object form. Either way the response is taking ownership of the memory that it is sending down the wire.
>
So how do you intend to support request pipelining on an
implementation as you propose? As it is at the moment there is no
guarantee as to *when* an object will be deleted. This is a
non-deterministic code path. The last thing I want to do is introduce
memory management code in the network implementation when that stuff
should be handled automatically.
There's no *easy* way to achieve what you want to achieve with the
synchronous server implementation. There's a reason why I had to write
an asynchronous server implementation precisely for serving huge
amounts of data, supporting a streaming use case, etc.
>>
>> Unfortunately, that's not much better than saying:
>>
>> std::ifstream f(...);
>> response.content.reserve(file_size);
>> f.read(response.content.data(), file_size);
>>
>> Am I missing something?
>
> I think this example illustrates my point about the trickiness of the interface. There are two reasons this won't work.
>
> 1. response.content.data() returns const char*, right? You can't write into that.
You're right. D'oh.
> 2. After this is run, response.content.size() will always be zero, right? And nothing will be sent?
>
Yeah. *facepalm*
> You probably wrote these bugs because you're up too late. :) Still, they show the brittleness of using a string like this.
>
Or probably because I wasn't thinking straight generally. :P
The better way is here:
std::ifstream input(...);
response.content.reserve(file_size);
std::copy(istreambuf_iterator<char>(input.rdbuf()),
istreambuf_iterator<char>(),
std::back_inserter(response.content));
/me <3 the STL sometimes. ;)
>>
>> For data that's already in memory I get the utility of being able to
>> refer to the bytes directly. Unfortunately making the library
>> deallocate memory that the user allocated is, quite bluntly, bad form
>> and error prone.
>>
>> Makes sense?
>>
>
> I'd say that passing ownership of an object to a library is neither bad form nor error prone. Sutter has a good writeup of using auto_ptr effectively in 'Exceptional C++' that seems applicable. Transferring object ownership with auto_ptr is safe, efficient, and idiomatic.
>
Eh? Are you seriously suggesting to me that passing a raw pointer up
to a calling function and expecting that calling function to manage
the memory for you is good form?
Remember, the response object is created before it's even called --
the implementation *should not be responsible for managing the memory
of the extension (in which case this is the handler)*. That is what I
refer to as bad form along with the ugliness that is auto_ptr.
> Anyway, you're putting the sweat equity into cpp-netlib, and are closer to the project. My only original observation was 'The same question will come up again and again because it's a surprising interface'. It clearly can work as it is, but it is surprising. That's why he didn't figure it out by himself.
>
And the answer will be the same, turn your data into a string and
stuff that into the response.content (at least for 0.8/0.8.1). With
0.9-devel there should be a better way, but nothing like what's
already being suggested. I'm considering adding an optional completion
callback to the response type, to allow for "chaining writes" even in
the synchronous interface. I'm leaning towards the one I described
earlier with a variant solution:
variant<
string_type,
tuple<
boost::asio::const_buffer,
function<
void(boost::asio::const_buffer, boost::system::error_code)
>
>
> content;
This means you can either assign a string to it, or assign a tuple of
a boost::asio::const_buffer and a completion handler that takes care
of the data in the buffer, and knows what to do with the error code
passed in. It's a lot more complicated I know, but that's the only way
I can think of to allow the synchronous server to deal with the case
where you would like to chain writes instead of sending a big thunk of
data (also a good way to enforce chunked encoding on the synchronous
interface). This is a lot more scalable too, now I just have to think
about whether there's a good way to do this without breaking too much
code that's using the 0.8-line idiom.
HTH
--
Dean Michael Berris
about.me/deanberris
|
7 messages has been excluded from this view by a project administrator.
