Menu
▾
▴
cpp-netlib-devel
|
From: Fernando P. <fpe...@gm...> - 2010-06-03 13:56:51
|
Hello,
I am new in the list.
I write this because I want to talk to Dean or Glyn about the NetLib.
I downloaded cpp-netlib-0.5, cpp-netlib-0.6 and cpp-netlib-0.61yesterday.
I found some problems in the library.
I tested the "Hello World Client" example on MSVC 9.0 on Windows XP.
The issues are:
1. Dependencies to OpenSSL.
The "boost/network/protocol/http/impl/sync_connection_base.hpp"
depends on "boost/network/protocol/http/impl/sync_connection_base.hpp" and
the las depends on "boost/asio/ssl.hpp"
I am not using secure connections.
2. Compilation error.
The "boost/network/uri/http/detail/parse_specific.hpp" file has the
following lines:
*if (not boost::iequals(parts.scheme.substr(0, 4), "http"))*
and
*if (not boost::iequals(parts.scheme.substr(0, 5), "https"))*
The keyword "not" is undeclared.
Could be this way?
*#define not !*
3. Async operations.
This is not an error, but I think the library should support
asynchronous operations, like ASIO. I have not found it.
Sorry if this mail was sent to a wrong list. In this case, please tell me
where I can send.
Count on me to lend a hand with the development of netlib
Regards,
Fernando Pelliccioni.
*
<http://sourceforge.net/projects/cpp-netlib/files/cpp-netlib/0.5/cpp-netlib-0.5.zip/download>
*
|
|
From: Dean M. B. <mik...@gm...> - 2010-06-03 14:21:44
|
Hi Fernando! On Thu, Jun 3, 2010 at 9:30 PM, Fernando Pelliccioni <fpe...@gm...> wrote: > Hello, > > I am new in the list. Welcome! :) > I write this because I want to talk to Dean or Glyn about the NetLib. You wrote to the right place. :D > > I downloaded cpp-netlib-0.5, cpp-netlib-0.6 and cpp-netlib-0.61yesterday. > I found some problems in the library. > Cool! :) > I tested the "Hello World Client" example on MSVC 9.0 on Windows XP. > The issues are: > > 1. Dependencies to OpenSSL. > The "boost/network/protocol/http/impl/sync_connection_base.hpp" > depends on "boost/network/protocol/http/impl/sync_connection_base.hpp" and > the las depends on "boost/asio/ssl.hpp" > > I am not using secure connections. > Yes, I'm working on it at the moment. On the 0.7-devel branch, I shall be pushing soon a fix that allows users to define the BOOST_NETWORK_NO_HTTPS command-line option to disable support for secure connections. I'm working on getting this tested as well locally to make sure that the examples and other things can be built without support for or dependency on OpenSSL. > > 2. Compilation error. > The "boost/network/uri/http/detail/parse_specific.hpp" file has the > following lines: > > if (not boost::iequals(parts.scheme.substr(0, 4), "http")) > > > and > > if (not boost::iequals(parts.scheme.substr(0, 5), "https")) > > > The keyword "not" is undeclared. > > Could be this way? > > #define not ! > This is a notorious problem with MSVC 8/9 -- which is not a problem with MSVC 10. I thought there was already a fix that should have fixed this, but I don't know the correct search term. Someone has already sent in a patch for this before, I can't believe it hasn't made it into the library yet! Does anybody remember what that file is that should be included to enable this in MSVC 8/9? > > 3. Async operations. > This is not an error, but I think the library should support > asynchronous operations, like ASIO. I have not found it. > I hear you, I'm working on it as I take a break and respond to you on the list. :) > > Sorry if this mail was sent to a wrong list. In this case, please tell me > where I can send. You sent it to the right list. :) > Count on me to lend a hand with the development of netlib > That sounds great! Thanks Fernando! :) -- Dean Michael Berris deanberris.com |
|
From: Kim G. <kim...@gm...> - 2010-06-03 14:38:39
|
Hi Dean, On Thu, Jun 3, 2010 at 16:21, Dean Michael Berris <mik...@gm...> wrote: > > This is a notorious problem with MSVC 8/9 -- which is not a problem > with MSVC 10. > > I thought there was already a fix that should have fixed this, but I > don't know the correct search term. Someone has already sent in a > patch for this before, I can't believe it hasn't made it into the > library yet! > > Does anybody remember what that file is that should be included to > enable this in MSVC 8/9? According to previous discussion it should be in iso646.h. See http://en.wikipedia.org/wiki/Iso646.h for more details. - Kim |
|
From: Matt T. <mat...@gm...> - 2010-06-03 23:37:25
|
Heya Dean, > Yes, I'm working on it at the moment. On the 0.7-devel branch, I shall > be pushing soon a fix that allows users to define the > BOOST_NETWORK_NO_HTTPS .... Great, thanks for this! But have you considered making HTTPS an opt-in feature instead? So you'd have to define BOOST_NETWORK_HTTPS to *allow* HTTPS connections. I'm not of a strong opinion either way but, in particular, I suspect that the most common complaint we'll face from devs new to cpp-netlib is that "the code doesn't compile" because they didn't know to add a #define or a dependency to OpenSSL. Cheers, Matt |
|
From: Dean M. B. <mik...@gm...> - 2010-06-03 14:27:47
|
On Thu, Jun 3, 2010 at 10:21 PM, Dean Michael Berris <mik...@gm...> wrote: > Hi Fernando! > > On Thu, Jun 3, 2010 at 9:30 PM, Fernando Pelliccioni > <fpe...@gm...> wrote: >> >> 1. Dependencies to OpenSSL. >> The "boost/network/protocol/http/impl/sync_connection_base.hpp" >> depends on "boost/network/protocol/http/impl/sync_connection_base.hpp" and >> the las depends on "boost/asio/ssl.hpp" >> >> I am not using secure connections. >> > > Yes, I'm working on it at the moment. On the 0.7-devel branch, I shall > be pushing soon a fix that allows users to define the > BOOST_NETWORK_NO_HTTPS command-line option to disable support for I meant, BOOST_NETWORK_NO_HTTPS macro not command-line option. > secure connections. I'm working on getting this tested as well locally > to make sure that the examples and other things can be built without > support for or dependency on OpenSSL. > >> >> 2. Compilation error. >> The "boost/network/uri/http/detail/parse_specific.hpp" file has the >> following lines: >> >> if (not boost::iequals(parts.scheme.substr(0, 4), "http")) >> >> >> and >> >> if (not boost::iequals(parts.scheme.substr(0, 5), "https")) >> >> >> The keyword "not" is undeclared. >> >> Could be this way? >> >> #define not ! >> > > This is a notorious problem with MSVC 8/9 -- which is not a problem > with MSVC 10. > > I thought there was already a fix that should have fixed this, but I > don't know the correct search term. Someone has already sent in a > patch for this before, I can't believe it hasn't made it into the > library yet! > > Does anybody remember what that file is that should be included to > enable this in MSVC 8/9? > And Google is my friend: #include <ciso646> HTH -- Dean Michael Berris deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-06-03 14:42:27
|
Fernando Pelliccioni wrote: > 1. Dependencies to OpenSSL. > The "boost/network/protocol/http/impl/sync_connection_base.hpp" depends on "boost/network/protocol/http/impl/sync_connection_base.hpp" and the las depends on "boost/asio/ssl.hpp" I had this problem as well... I just commented out the stuff I didn't need in sync_connection_base. In my opinion a better fix is to factor https_sync_connection out into a different header file that is only #included if the user includes, for example, a hypothetical protocol/https/client.hpp This was is very unsurprising... never use anything from protocol/https, and you'll never have a dependency on SSL. Erik |
|
From: Dean M. B. <mik...@gm...> - 2010-06-03 14:49:52
|
On Thu, Jun 3, 2010 at 10:42 PM, Nelson, Erik - 2 <eri...@ba...> wrote: > Fernando Pelliccioni wrote: > >> 1. Dependencies to OpenSSL. >> The "boost/network/protocol/http/impl/sync_connection_base.hpp" depends on >> "boost/network/protocol/http/impl/sync_connection_base.hpp" and the las >> depends on "boost/asio/ssl.hpp" > > I had this problem as well… I just commented out the stuff I didn’t need in > sync_connection_base. In my opinion a better fix is to factor > https_sync_connection out into a different header file that is only > #included if the user includes, for example, a hypothetical > protocol/https/client.hpp > Well, it's not that simple you know. The reason is that the URL to get/post/delete/put/head is a runtime value. We do some pretty clever static+runtime dispatch to determine whether to create an https connection object that knows how to establish https connections and handle the request/response appropriately. The reason I opt for a macro to disable it is because I personally think you ought to know what you're doing with an HTTP client library if you specifically opt out of using SSL. The manifestation of this is as a macro you define that says explicitly that you don't want HTTPS support -- and the runtime dispatcher will just throw an exception if you give it an HTTPS URI. > This was is very unsurprising… never use anything from protocol/https, and > you’ll never have a dependency on SSL. > I've already refactored the code locally so the HTTPS handling is already in a different file. The wiring though is surrounded by the macro as discussed above. Patience is a virtue -- expect a push from me in a bit, although expect things might be broken because I'm still working on the async HTTP stuff, so for the brave please feel free to pull as soon as I push and see if I really broke anything. ;) -- Dean Michael Berris deanberris.com |
|
From: Dean M. B. <mik...@gm...> - 2010-06-03 14:52:51
|
On Thu, Jun 3, 2010 at 10:49 PM, Dean Michael Berris <mik...@gm...> wrote: > > Patience is a virtue -- expect a push from me in a bit, although > expect things might be broken because I'm still working on the async > HTTP stuff, so for the brave please feel free to pull as soon as I > push and see if I really broke anything. ;) > And you can now test this from 0.7-devel on http://github.com/mikhailberis/cpp-netlib -- bug reports and violent reactions would be welcome in case it's broken by me. :) -- Dean Michael Berris deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-06-03 15:19:05
|
Dean Michael Berris wrote: > Erik nelson wrote: >> I had this problem as well… I just commented out the stuff I didn’t need in >> sync_connection_base. In my opinion a better fix is to factor >> https_sync_connection out into a different header file that is only >> #included if the user includes, for example, a hypothetical >> protocol/https/client.hpp > Well, it's not that simple you know. It never is :) and I know you have a lot more experience with this than me. I'm using cpp-netlib in our production app, and just trying to put out there my experiences. > The reason is that the URL to get/post/delete/put/head is a runtime > value. We do some pretty clever static+runtime dispatch to determine > whether to create an https connection object that knows how to > establish https connections and handle the request/response > appropriately. That's maybe a fundamental difference in our use cases... the http/https part of the URL is *never* a runtime value for me, so there's no need for the static+runtime dispatch. Might it be possible to factor out the dispatcher such that you have only as many dependencies as you wanted? For example typedef dispatcher<http> http_dispatcher; // only handles http URLS typedef dispatcher<https> https_dispatcher; // only handles https URLS typedef dispatcher<https, http> https_http_dispatcher; // handles https or http URLS typedef dispatcher<https, http, ftp> https_http_ftp_dispatcher; // handles https or http or ftp URLS I know the names are unhandy, but at some level, dispatching is kind of an orthogonal task to what URL set is going to be used, and I don't see how it's going to be extensible to other URL types. > The reason I opt for a macro to disable it is because I personally > think you ought to know what you're doing with an HTTP client library > if you specifically opt out of using SSL. The manifestation of this is > as a macro you define that says explicitly that you don't want HTTPS > support -- and the runtime dispatcher will just throw an exception if > you give it an HTTPS URI. I'd maybe argue the opposite... the https use case is more complex, with more complex dependencies, so you ought to know what you're doing if you want to *include* https support. Plain http is about as vanilla as it gets. > Patience is a virtue Not intending to be impatient or complaining... whatever you decide is fine by me- you are the one doing the heavy lifting, and it totally your call. Erik |
|
From: Dean M. B. <mik...@gm...> - 2010-06-03 15:51:31
|
On Thu, Jun 3, 2010 at 11:16 PM, Nelson, Erik - 2 <eri...@ba...> wrote: > Dean Michael Berris wrote: > >> Well, it's not that simple you know. > > It never is :) and I know you have a lot more experience with this than me. I'm using cpp-netlib in our production app, and just trying to put out there my experiences. > That's good to know, cpp-netlib is in production somewhere! :D >> The reason is that the URL to get/post/delete/put/head is a runtime >> value. We do some pretty clever static+runtime dispatch to determine >> whether to create an https connection object that knows how to >> establish https connections and handle the request/response >> appropriately. > > That's maybe a fundamental difference in our use cases... the http/https part of the URL is *never* a runtime value for me, so there's no need for the static+runtime dispatch. Well, actually, it kinda is a runtime value for everyone using cpp-netlib. Even if it's hard-coded (the URL), it still has to be parsed at runtime. That means, at compile-time, there's no way for the library to know from a type standpoint that the URI is an HTTP or HTTPS URI. This is the reason there's a mix of static and runtime dispatch -- static dispatch for the tags, runtime dispatch for determining whether it's HTTP or HTTPS. > Might it be possible to factor out the dispatcher such that you have only as many dependencies as you wanted? > > For example > > typedef dispatcher<http> http_dispatcher; // only handles http URLS > typedef dispatcher<https> https_dispatcher; // only handles https URLS > typedef dispatcher<https, http> https_http_dispatcher; // handles https or http URLS > typedef dispatcher<https, http, ftp> https_http_ftp_dispatcher; // handles https or http or ftp URLS > > I know the names are unhandy, but at some level, dispatching is kind of an orthogonal task to what URL set is going to be used, and I don't see how it's going to be extensible to other URL types. > If you look at the way the dispatch happens, it's really simple: if it's an "https://..." then create an instance of an https_sync_connection object and get a handle to it using a reference to a sync_connection_base (the virtual base type). This is purely dynamic dispatch, no need for a layer for dispatching. :) It's the factory+strategy patterns combined, only the factory is static while the strategy is dynamic. :D >> The reason I opt for a macro to disable it is because I personally >> think you ought to know what you're doing with an HTTP client library >> if you specifically opt out of using SSL. The manifestation of this is >> as a macro you define that says explicitly that you don't want HTTPS >> support -- and the runtime dispatcher will just throw an exception if >> you give it an HTTPS URI. > > I'd maybe argue the opposite... the https use case is more complex, with more complex dependencies, so you ought to know what you're doing if you want to *include* https support. Plain http is about as vanilla as it gets. > That makes sense, but then I would solve it using macro's still -- adding a different header to include just HTTP is just wasteful IMO. I may be convinced otherwise, and as you know patches/pull-requests are totally welcome. :D >> Patience is a virtue > > Not intending to be impatient or complaining... whatever you decide is fine by me- you are the one doing the heavy lifting, and it totally your call. > That's alright, my version of the fix is already up in the 0.7-devel branch. :) -- Dean Michael Berris deanberris.com |
|
From: Fernando P. <fpe...@gm...> - 2010-06-03 15:35:10
|
Perfect Duean, Great news!!!
Only a question:
Why not do
if ( *!* boost::iequals(parts.scheme.substr(0, 5), "https") )
instead of
if ( *not *boost::iequals(parts.scheme.substr(0, 5), "https") )
?
Regards,
Fernando.
On Thu, Jun 3, 2010 at 11:27 AM, Dean Michael Berris <mik...@gm...
> wrote:
> On Thu, Jun 3, 2010 at 10:21 PM, Dean Michael Berris
> <mik...@gm...> wrote:
> > Hi Fernando!
> >
> > On Thu, Jun 3, 2010 at 9:30 PM, Fernando Pelliccioni
> > <fpe...@gm...> wrote:
> >>
> >> 1. Dependencies to OpenSSL.
> >> The
> "boost/network/protocol/http/impl/sync_connection_base.hpp"
> >> depends on "boost/network/protocol/http/impl/sync_connection_base.hpp"
> and
> >> the las depends on "boost/asio/ssl.hpp"
> >>
> >> I am not using secure connections.
> >>
> >
> > Yes, I'm working on it at the moment. On the 0.7-devel branch, I shall
> > be pushing soon a fix that allows users to define the
> > BOOST_NETWORK_NO_HTTPS command-line option to disable support for
>
> I meant, BOOST_NETWORK_NO_HTTPS macro not command-line option.
>
> > secure connections. I'm working on getting this tested as well locally
> > to make sure that the examples and other things can be built without
> > support for or dependency on OpenSSL.
> >
> >>
> >> 2. Compilation error.
> >> The "boost/network/uri/http/detail/parse_specific.hpp" file has
> the
> >> following lines:
> >>
> >> if (not boost::iequals(parts.scheme.substr(0, 4),
> "http"))
> >>
> >>
> >> and
> >>
> >> if (not boost::iequals(parts.scheme.substr(0, 5),
> "https"))
> >>
> >>
> >> The keyword "not" is undeclared.
> >>
> >> Could be this way?
> >>
> >> #define not !
> >>
> >
> > This is a notorious problem with MSVC 8/9 -- which is not a problem
> > with MSVC 10.
> >
> > I thought there was already a fix that should have fixed this, but I
> > don't know the correct search term. Someone has already sent in a
> > patch for this before, I can't believe it hasn't made it into the
> > library yet!
> >
> > Does anybody remember what that file is that should be included to
> > enable this in MSVC 8/9?
> >
>
> And Google is my friend: #include <ciso646>
>
> HTH
>
> --
> Dean Michael Berris
> deanberris.com
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>
|
|
From: Dean M. B. <mik...@gm...> - 2010-06-03 15:38:38
|
On Thu, Jun 3, 2010 at 11:34 PM, Fernando Pelliccioni <fpe...@gm...> wrote: > Perfect Duean, Great news!!! > > Only a question: > > Why not do > > if ( ! boost::iequals(parts.scheme.substr(0, 5), "https") ) > > instead of > > if ( not boost::iequals(parts.scheme.substr(0, 5), "https") ) > > ? > Good question... I have no good answer except that the version with the "not" reads better. It's a matter of taste -- I just might remove the 'not', 'and', and 'or' keywords if I get tired of fighting it. ;) -- Dean Michael Berris deanberris.com |
|
From: Fernando P. <fpe...@gm...> - 2010-06-03 15:43:18
|
I think it is good for readability. It's the first time that I see it ... :) On Thu, Jun 3, 2010 at 12:38 PM, Dean Michael Berris <mik...@gm... > wrote: > On Thu, Jun 3, 2010 at 11:34 PM, Fernando Pelliccioni > <fpe...@gm...> wrote: > > Perfect Duean, Great news!!! > > > > Only a question: > > > > Why not do > > > > if ( ! boost::iequals(parts.scheme.substr(0, 5), "https") ) > > > > instead of > > > > if ( not boost::iequals(parts.scheme.substr(0, 5), "https") ) > > > > ? > > > > Good question... I have no good answer except that the version with > the "not" reads better. > > It's a matter of taste -- I just might remove the 'not', 'and', and > 'or' keywords if I get tired of fighting it. ;) > > -- > Dean Michael Berris > deanberris.com > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Cpp-netlib-devel mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel > |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-06-03 15:51:45
|
Fernando Pelliccioni wrote: > Why not do > if ( ! boost::iequals(parts.scheme.substr(0, 5), "https") ) > instead of > if ( not boost::iequals(parts.scheme.substr(0, 5), "https") ) I prefer the second way- it's more expressive and it's standards-compliant. This is a bug in the Microsoft compiler. Erik |
|
From: Fernando P. <fpe...@gm...> - 2010-06-03 15:59:55
|
It is not a bug. The following code compiles well on MSVC 9 (Visual Studio
2008)
// -- begin code
#include <iostream>
#include <ciso646>
int main()
{
bool temp = true;
if ( not temp )
{
std::cout << "it's is false" << std::endl;
}
else
{
std::cout << "it's is true" << std::endl;
}
return 0;
}
// -- end
You just have to include <ciso646>
Regards,
Fernando.
On Thu, Jun 3, 2010 at 12:39 PM, Nelson, Erik - 2 <
eri...@ba...> wrote:
> Fernando Pelliccioni wrote:
>
> > Why not do
> > if ( ! boost::iequals(parts.scheme.substr(0, 5), "https") )
> > instead of
> > if ( not boost::iequals(parts.scheme.substr(0, 5), "https") )
>
> I prefer the second way- it's more expressive and it's standards-compliant.
> This is a bug in the Microsoft compiler.
>
> Erik
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>
|
|
From: Dean M. B. <mik...@gm...> - 2010-06-03 16:15:41
|
Hi Fernando, On Thu, Jun 3, 2010 at 11:59 PM, Fernando Pelliccioni <fpe...@gm...> wrote: [snip] > Please don't top-post -- it's getting hard to follow discussions if your response is above the message you're responding to. Please keep the context required and respond in-line so that we have nice archives and would allow others to easily follow the discussion. Thanks -- this also serves as a reminder to everyone (those abiding and not abiding). :) Have a great one guys! -- Dean Michael Berris deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-06-03 17:23:21
|
Fernando Pelliccioni wrote: > It is not a bug. The following code compiles well on MSVC 9 (Visual Studio 2008) > You just have to include <ciso646> It is a bug- 'and', 'not', etc. are reserved words in C++, and MSVC9 is nonconformant when it #defines them as preprocessor macros. It cause troubles lots of places, not just here. Here's a link that discusses it further. http://books.google.com/books?id=Q4iP1mkfdtsC&pg=PT398&lpg=PT398&dq=ciso 646&source=bl&ots=wYn89ESX6p&sig=YJ9ZKxHVhGctK3_ruaAEuHYnRnM&hl=en&ei=q- MHTLCWGYWclgesspWADw&sa=X&oi=book_result&ct=result&resnum=8&ved=0CDoQ6AE wBw#v=onepage&q=ciso646&f=false Erik |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-06-03 17:25:45
|
Fernando Pelliccioni wrote: > It is not a bug. The following code compiles well on MSVC 9 (Visual Studio 2008) > You just have to include <ciso646> Sorry for the long URL... here's a shorter one http://bit.ly/8ZI4z3 |
|
From: Matt T. <mat...@gm...> - 2010-06-03 23:29:38
|
>> Why not do >> if ( ! boost::iequals(parts.scheme.substr(0, 5), "https") ) >> instead of >> if ( not boost::iequals(parts.scheme.substr(0, 5), "https") ) > > I prefer the second way- it's more expressive and it's standards-compliant. This is a bug in the Microsoft compiler. Dean's right, it's a matter of taste; I prefer it the first way. :) IMO, it's no less expressive and that use is far more common - and better understood - in the C++ domain. |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-06-04 01:43:57
|
Matt Trentini wrote: > But have you considered making HTTPS an opt-in feature instead? So > you'd have to define BOOST_NETWORK_HTTPS to *allow* HTTPS connections. > I'm not of a strong opinion either way but, in particular, I suspect > that the most common complaint we'll face from devs new to cpp-netlib > is that "the code doesn't compile" because they didn't know to add a > #define or a dependency to OpenSSL. +1 from me. OpenSSL might be installed by default on every GNU/Linux box, but it's not installed at all on most Windows C++ development machines. Our hello_world programs should "just work", in my opinion. Erik |
|
From: Dean M. B. <mik...@gm...> - 2010-06-04 04:53:37
|
On Fri, Jun 4, 2010 at 7:29 AM, Matt Trentini <mat...@gm...> wrote: >>> Why not do >>> if ( ! boost::iequals(parts.scheme.substr(0, 5), "https") ) >>> instead of >>> if ( not boost::iequals(parts.scheme.substr(0, 5), "https") ) >> >> I prefer the second way- it's more expressive and it's standards-compliant. This is a bug in the Microsoft compiler. > > Dean's right, it's a matter of taste; I prefer it the first way. :) > > IMO, it's no less expressive and that use is far more common - and > better understood - in the C++ domain. > Yeah, but I like English more personally. Again, it's really easy to fix and I just might do that if there's overwhelming opinion in support for the symbolic version versus the (standards-compliant) English-ish version. -- Dean Michael Berris deanberris.com |
|
From: Kim G. <kim...@gm...> - 2010-06-04 05:33:45
|
Hey Dean, On Fri, Jun 4, 2010 at 06:53, Dean Michael Berris <mik...@gm...> wrote: > > Yeah, but I like English more personally. Again, it's really easy to > fix and I just might do that if there's overwhelming opinion in > support for the symbolic version versus the (standards-compliant) > English-ish version. +1 for the symbolic notation from me! (<-- I like it so much I even managed to get it into this e-mail :) - Kim |
|
From: Fernando P. <fpe...@gm...> - 2010-06-04 13:02:48
|
On Thu, Jun 3, 2010 at 2:23 PM, Nelson, Erik - 2 < eri...@ba...> wrote: > Fernando Pelliccioni wrote: > > It is not a bug. The following code compiles well on MSVC 9 (Visual > Studio 2008) > > You just have to include <ciso646> > > It is a bug- 'and', 'not', etc. are reserved words in C++, and MSVC9 is > nonconformant when it #defines them as preprocessor macros. It cause > troubles lots of places, not just here. > > > It is true, there are reserved words This is from the Current Standard ISO/IEC 14882:2003(E) --- *Furthermore, the alternative representations shown in Table 4 for certain operators and punctuators (2.5) are reserved and shall not be used otherwise: Table 4—alternative representations __ ______________________________________________________ and and_eq bitand bitor compl not not_eq or or_eq xor xor_eq _ _______________________________________________________ * --- But the example I sent compiles and works! Regards, Fernando. > Here's a link that discusses it further. > > http://books.google.com/books?id=Q4iP1mkfdtsC&pg=PT398&lpg=PT398&dq=ciso > 646&source=bl&ots=wYn89ESX6p&sig=YJ9ZKxHVhGctK3_ruaAEuHYnRnM&hl=en&ei=q- > MHTLCWGYWclgesspWADw&sa=X&oi=book_result&ct=result&resnum=8&ved=0CDoQ6AE > wBw#v=onepage&q=ciso646&f=false<http://books.google.com/books?id=Q4iP1mkfdtsC&pg=PT398&lpg=PT398&dq=ciso%0A646&source=bl&ots=wYn89ESX6p&sig=YJ9ZKxHVhGctK3_ruaAEuHYnRnM&hl=en&ei=q-%0AMHTLCWGYWclgesspWADw&sa=X&oi=book_result&ct=result&resnum=8&ved=0CDoQ6AE%0AwBw#v=onepage&q=ciso646&f=false> > > Erik > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Cpp-netlib-devel mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel > |
|
From: Dean M. B. <mik...@gm...> - 2010-06-04 14:54:51
|
On Fri, Jun 4, 2010 at 9:02 PM, Fernando Pelliccioni <fpe...@gm...> wrote: > > But the example I sent compiles and works! > Yes, actually I checked the code and 0.6.1 should have that fixed. Is that not the case for you? -- Dean Michael Berris deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-06-04 14:49:51
|
Kim Gräsman wrote: > +1 for the symbolic notation from me! (<-- I like it so much I even > managed to get it into this e-mail :) I'm not clear on this... are you negating the +1? :D 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