Menu
▾
▴
cpp-netlib-devel
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-20 20:43:59
|
Hi there,
I'm playing with the hello_world.cpp (current one in
mikhailberis-cpp-netlib git) and have a couple of questions. Here's the
start of my compiler output
1>http_server.cpp
1>Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. For
example:
1>- add -D_WIN32_WINNT=0x0501 to the compiler command line; or
1>- add _WIN32_WINNT=0x0501 to your project's Preprocessor Definitions.
1>Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target).
1>c:\work\boost\boost/network/protocol/http/traits/impl/request_methods.
ipp(37) : error C2059: syntax error : 'constant'
Comments/Questions:
1) I know that _WIN32_WINNT is #defined in the jamfile, but I'm curious
if anyone knows why this warning comes up with cpp-netlib... We use
boost extensively but have never needed to #define this
2) the error comes from
request_methods.ipp, on line
static char const * const DELETE = "DELETE";
Winnt.h #defines DELETE. If I change the offending line in
request_methods.ipp to 'DELETE_', that seems to fix it
After I fix that, the next error I get is:
1>c:\work\boost\boost/network/uri/http/detail/parse_specific.hpp(74) :
error C2065: 'not' : undeclared identifier
Adding #include <ciso646> to parse_specific.hpp gets it on the road, but
then I come to something I don't see any obvious answer to:
1>c:\work\boost\boost/network/uri/http/uri.hpp(36) : error C2597:
illegal reference to non-static member
'boost::network::uri::basic_uri<boost::network::tags::http_default_8bit_
tcp_resolve>::string_type'
It's complaining about this code
uint32_t port() const {
return parts_.port ? *(parts_.port) :
(boost::iequals(parts_.scheme, string_type("https"))
? 443u : 80u);
}
Am I doing something wrong? Or is this known to be broken right now?
I'm using a copy of Dean's code that I pulled down today. Any guidance
would be appreciated.
Thanks
Erik
|
|
From: Glyn M. <gly...@gm...> - 2010-01-20 21:01:31
|
Hi Erik,
2010/1/20 Nelson, Erik - 2 <eri...@ba...>
> Hi there,
>
> I'm playing with the hello_world.cpp (current one in
> mikhailberis-cpp-netlib git) and have a couple of questions. Here's the
> start of my compiler output
>
> 1>http_server.cpp
> 1>Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. For
> example:
> 1>- add -D_WIN32_WINNT=0x0501 to the compiler command line; or
> 1>- add _WIN32_WINNT=0x0501 to your project's Preprocessor Definitions.
> 1>Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target).
> 1>c:\work\boost\boost/network/protocol/http/traits/impl/request_methods.
> ipp(37) : error C2059: syntax error : 'constant'
>
>
> Comments/Questions:
> 1) I know that _WIN32_WINNT is #defined in the jamfile, but I'm curious
> if anyone knows why this warning comes up with cpp-netlib... We use
> boost extensively but have never needed to #define this
>
This comes from boost asio (boost/asio/detail/socket_types.hpp), there must
be something in your configuration - the order in which you include
windows.h, perhaps.
> 2) the error comes from
> request_methods.ipp, on line
> static char const * const DELETE = "DELETE";
> Winnt.h #defines DELETE. If I change the offending line in
> request_methods.ipp to 'DELETE_', that seems to fix it
>
Can you submit a patch?
>
> After I fix that, the next error I get is:
> 1>c:\work\boost\boost/network/uri/http/detail/parse_specific.hpp(74) :
> error C2065: 'not' : undeclared identifier
>
> Adding #include <ciso646> to parse_specific.hpp gets it on the road, but
> then I come to something I don't see any obvious answer to:
>
> 1>c:\work\boost\boost/network/uri/http/uri.hpp(36) : error C2597:
> illegal reference to non-static member
> 'boost::network::uri::basic_uri<boost::network::tags::http_default_8bit_
> tcp_resolve>::string_type'
>
> It's complaining about this code
>
> uint32_t port() const {
> return parts_.port ? *(parts_.port) :
> (boost::iequals(parts_.scheme, string_type("https"))
> ? 443u : 80u);
> }
>
>
> Am I doing something wrong? Or is this known to be broken right now?
> I'm using a copy of Dean's code that I pulled down today. Any guidance
> would be appreciated.
>
>
You're not doing anything wrong if all you're doing is trying to build a
test... we're still short of being release ready but this code hasn't
changed since 0.4 so I can't explain this error. Dean?
G
|
|
From: Jeroen H. <vex...@gm...> - 2010-01-20 21:07:38
Attachments:
uri.patch
|
Hi Erik,
On Wed, Jan 20, 2010 at 21:43, Nelson, Erik - 2
<eri...@ba...> wrote:
> Hi there,
>
> I'm playing with the hello_world.cpp (current one in
> mikhailberis-cpp-netlib git) and have a couple of questions. Here's the
> start of my compiler output
>
> 1>http_server.cpp
> 1>Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. For
> example:
> 1>- add -D_WIN32_WINNT=0x0501 to the compiler command line; or
> 1>- add _WIN32_WINNT=0x0501 to your project's Preprocessor Definitions.
> 1>Assuming _WIN32_WINNT=0x0501 (i.e. Windows XP target).
> 1>c:\work\boost\boost/network/protocol/http/traits/impl/request_methods.
> ipp(37) : error C2059: syntax error : 'constant'
>
>
> Comments/Questions:
> 1) I know that _WIN32_WINNT is #defined in the jamfile, but I'm curious
> if anyone knows why this warning comes up with cpp-netlib... We use
> boost extensively but have never needed to #define this
> 2) the error comes from
> request_methods.ipp, on line
> static char const * const DELETE = "DELETE";
> Winnt.h #defines DELETE. If I change the offending line in
> request_methods.ipp to 'DELETE_', that seems to fix it
>
> After I fix that, the next error I get is:
> 1>c:\work\boost\boost/network/uri/http/detail/parse_specific.hpp(74) :
> error C2065: 'not' : undeclared identifier
>
> Adding #include <ciso646> to parse_specific.hpp gets it on the road, but
> then I come to something I don't see any obvious answer to:
>
> 1>c:\work\boost\boost/network/uri/http/uri.hpp(36) : error C2597:
> illegal reference to non-static member
> 'boost::network::uri::basic_uri<boost::network::tags::http_default_8bit_
> tcp_resolve>::string_type'
>
> It's complaining about this code
>
> uint32_t port() const {
> return parts_.port ? *(parts_.port) :
> (boost::iequals(parts_.scheme, string_type("https"))
> ? 443u : 80u);
> }
>
>
> Am I doing something wrong? Or is this known to be broken right now?
> I'm using a copy of Dean's code that I pulled down today. Any guidance
> would be appreciated.
>
> Thanks
>
> Erik
>
I've written a patch which might fix the two URI related errors,
though I currently have no way of testing them as I have no Windows
install around, please give them a shot and let me know.
Yours,
Jeroen Habraken
|
|
From: Dean M. B. <mik...@gm...> - 2010-01-20 21:10:33
|
On Thu, Jan 21, 2010 at 5:01 AM, Glyn Matthews <gly...@gm...> wrote:
>
> 2010/1/20 Nelson, Erik - 2 <eri...@ba...>
>>
>> After I fix that, the next error I get is:
>> 1>c:\work\boost\boost/network/uri/http/detail/parse_specific.hpp(74) :
>> error C2065: 'not' : undeclared identifier
>>
>> Adding #include <ciso646> to parse_specific.hpp gets it on the road, but
>> then I come to something I don't see any obvious answer to:
>>
It seems that you're using the version in the 'master' branch. Can you
try the latest from 0.5-devel?
Anyway the "real" fix would be to change 'not' into !.
>> 1>c:\work\boost\boost/network/uri/http/uri.hpp(36) : error C2597:
>> illegal reference to non-static member
>> 'boost::network::uri::basic_uri<boost::network::tags::http_default_8bit_
>> tcp_resolve>::string_type'
>>
>> It's complaining about this code
>>
>> uint32_t port() const {
>> return parts_.port ? *(parts_.port) :
>> (boost::iequals(parts_.scheme, string_type("https"))
>> ? 443u : 80u);
>> }
>>
>>
>> Am I doing something wrong? Or is this known to be broken right now?
>> I'm using a copy of Dean's code that I pulled down today. Any guidance
>> would be appreciated.
>>
>
> You're not doing anything wrong if all you're doing is trying to build a
> test... we're still short of being release ready but this code hasn't
> changed since 0.4 so I can't explain this error. Dean?
>
Right now I don't have a means of testing on the Windows platform so I
can't diagnose easily.
This looks like a missing typedef in the definition of the basic_uri template.
You can add 'typedef typename string<Tag>::type string_type' at the
start of the basic_uri template. Let me know if that helps.
--
Dean Michael Berris
cplusplus-soup.com | twitter.com/deanberris
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
|
|
From: Glyn M. <gly...@gm...> - 2010-01-20 21:17:11
|
Hi, 2010/1/20 Dean Michael Berris <mik...@gm...> > On Thu, Jan 21, 2010 at 5:01 AM, Glyn Matthews <gly...@gm...> > wrote: > > > > 2010/1/20 Nelson, Erik - 2 <eri...@ba...> > >> > >> After I fix that, the next error I get is: > >> 1>c:\work\boost\boost/network/uri/http/detail/parse_specific.hpp(74) : > >> error C2065: 'not' : undeclared identifier > >> > >> Adding #include <ciso646> to parse_specific.hpp gets it on the road, but > >> then I come to something I don't see any obvious answer to: > >> > > It seems that you're using the version in the 'master' branch. Can you > try the latest from 0.5-devel? > > Anyway the "real" fix would be to change 'not' into !. > Just a point about the use of `not` and `or` that have made their way into the code, but I had no idea that these were keywords in C++. In fact, IMO they're much clearer than writing `!` or `||` etc. but I've never seen this. Can anyone explain why they exist but are never used? Thanks, G |
|
From: Dean M. B. <mik...@gm...> - 2010-01-20 21:38:07
|
On Thu, Jan 21, 2010 at 5:17 AM, Glyn Matthews <gly...@gm...> wrote: > > 2010/1/20 Dean Michael Berris <mik...@gm...> >> >> On Thu, Jan 21, 2010 at 5:01 AM, Glyn Matthews <gly...@gm...> >> wrote: >> > >> > 2010/1/20 Nelson, Erik - 2 <eri...@ba...> >> >> >> >> After I fix that, the next error I get is: >> >> 1>c:\work\boost\boost/network/uri/http/detail/parse_specific.hpp(74) : >> >> error C2065: 'not' : undeclared identifier >> >> >> >> Adding #include <ciso646> to parse_specific.hpp gets it on the road, >> >> but >> >> then I come to something I don't see any obvious answer to: >> >> >> >> It seems that you're using the version in the 'master' branch. Can you >> try the latest from 0.5-devel? >> >> Anyway the "real" fix would be to change 'not' into !. > > Just a point about the use of `not` and `or` that have made their way into > the code, but I had no idea that these were keywords in C++. In fact, IMO > they're much clearer than writing `!` or `||` etc. but I've never seen > this. Can anyone explain why they exist but are never used? > I think it's because vendors aren't quick to support them natively in the compiler. GCC takes this in stride just fine as does other vendors (Intel's compiler is another one I know that works pretty well). I would quote the appropriate parts of the C++ standard if I had a copy (which I promise I should buy someday soon) but anyway it's something really annoying to me for non-conformant compilers like MSVC. I also like them better but unfortunately to support more compilers we're going to have to stick with !, ||, && et al. -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-20 21:50:17
|
Hi, On Wed, Jan 20, 2010 at 22:37, Dean Michael Berris <mik...@gm...> wrote: > On Thu, Jan 21, 2010 at 5:17 AM, Glyn Matthews <gly...@gm...> wrote: >> >> 2010/1/20 Dean Michael Berris <mik...@gm...> >>> >>> On Thu, Jan 21, 2010 at 5:01 AM, Glyn Matthews <gly...@gm...> >>> wrote: >>> > >>> > 2010/1/20 Nelson, Erik - 2 <eri...@ba...> >>> >> >>> >> After I fix that, the next error I get is: >>> >> 1>c:\work\boost\boost/network/uri/http/detail/parse_specific.hpp(74) : >>> >> error C2065: 'not' : undeclared identifier >>> >> >>> >> Adding #include <ciso646> to parse_specific.hpp gets it on the road, >>> >> but >>> >> then I come to something I don't see any obvious answer to: >>> >> >>> >>> It seems that you're using the version in the 'master' branch. Can you >>> try the latest from 0.5-devel? >>> >>> Anyway the "real" fix would be to change 'not' into !. >> >> Just a point about the use of `not` and `or` that have made their way into >> the code, but I had no idea that these were keywords in C++. In fact, IMO >> they're much clearer than writing `!` or `||` etc. but I've never seen >> this. Can anyone explain why they exist but are never used? >> > > I think it's because vendors aren't quick to support them natively in > the compiler. GCC takes this in stride just fine as does other vendors > (Intel's compiler is another one I know that works pretty well). I > would quote the appropriate parts of the C++ standard if I had a copy > (which I promise I should buy someday soon) but anyway it's something > really annoying to me for non-conformant compilers like MSVC. > > I also like them better but unfortunately to support more compilers > we're going to have to stick with !, ||, && et al. > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > Just found http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B#C.2B.2B_operator_synonyms which is the best explanation I've found so far and quotes the relevant parts in the cite-note I believe. As a side-note, I too prefer `and` over `&&`, though for portability I think we should stick to the latter. Jeroen |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-20 23:25:29
|
Dean Michael Berris wrote: > I think it's because vendors aren't quick to support them natively in > the compiler. GCC takes this in stride just fine as does other > vendors (Intel's compiler is another one I know that works pretty > well). I would quote the appropriate parts of the C++ standard if I > had a copy (which I promise I should buy someday soon) but anyway > it's something really annoying to me for non-conformant compilers > like MSVC. > > I also like them better but unfortunately to support more compilers > we're going to have to stick with !, ||, && et al. I'd say just put #include <ciso646> up high and continue to use them. They are standard C++, and they're much more descriptive than the !&&#|| stuff. Don't cave in to the noncompliant compiler vendors! Erik |
|
From: Dean M. B. <mik...@gm...> - 2010-01-21 05:43:02
|
On Thu, Jan 21, 2010 at 7:25 AM, Nelson, Erik - 2 <eri...@ba...> wrote: > Dean Michael Berris wrote: >> I think it's because vendors aren't quick to support them natively in >> the compiler. GCC takes this in stride just fine as does other >> vendors (Intel's compiler is another one I know that works pretty >> well). I would quote the appropriate parts of the C++ standard if I >> had a copy (which I promise I should buy someday soon) but anyway >> it's something really annoying to me for non-conformant compilers >> like MSVC. >> >> I also like them better but unfortunately to support more compilers >> we're going to have to stick with !, ||, && et al. > > I'd say just put #include <ciso646> up high and continue to use them. > They are standard C++, and they're much more descriptive than the !&&#|| > stuff. Don't cave in to the noncompliant compiler vendors! > Yeah, I suppose that would work. ;) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-21 16:00:22
|
Dean Michael Berris wrote: > It seems that you're using the version in the 'master' branch. Can > you try the latest from 0.5-devel? I'm using the code that I checked out from http://github.com/mikhailberis/cpp-netlib/blob/0.5-devel/ Is that correct? Erik |
|
From: Dean M. B. <mik...@gm...> - 2010-01-21 17:13:15
|
On Fri, Jan 22, 2010 at 12:00 AM, Nelson, Erik - 2 <eri...@ba...> wrote: > Dean Michael Berris wrote: >> It seems that you're using the version in the 'master' branch. Can >> you try the latest from 0.5-devel? > > I'm using the code that I checked out from > > http://github.com/mikhailberis/cpp-netlib/blob/0.5-devel/ > > Is that correct? > Yup, if it's a problem there then a fix would be nice to get. :) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-21 16:50:31
|
Glyn Matthews wrote: >> 2) the error comes from request_methods.ipp, on line >> static char const * const DELETE = "DELETE"; >> Winnt.h #defines DELETE. If I change the offending line in >> request_methods.ipp to 'DELETE_', that seems to fix it > Can you submit a patch? I've tried a bit to get the git dev tools set up, but the company firewall doesn't allow SSH traffic as far as I can tell, and I haven't managed to figure out how to clone the repository over http. At any rate, in \boost\network\protocol\http\traits\impl\request_methods.ipp I changed static char const * const DELETE = "DELETE"; to static char const * const DELETE_ = "DELETE"; and made the corresponding change to the next line. apologies for the un-handy patch style... I'll try to figure out a better way. Erik |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-21 16:57:44
|
Jeroen Habraken wrote: >I've written a patch which might fix the two URI related errors, though I currently have no way of testing them as I have no Windows install around, please give them a shot and let me know. I just took the typedef patch, which worked fine. Thanks much. The other patch was for the and/not/or broken compiler thing, which I fixed temporarily with the include. Whatever the collective decision is about how to solve that in the repository is fine with me- I'll get it when it comes out in 0.5 Thanks Erik |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X