Re: [cpp-netlib-devel] OpenSSL and cpp-netlib

[Nelson, E. - 2 <eri...@ba...>]

From: Dean Michael Berris Sent: Friday, February 19, 2010 11:20 AM

> Yes, even a #include is a compile-time option. This also allows you to
define
> the macro from the command-line of the compiler if it's allowed, or
> from the .cpp file before >including cpp-netlib HTTP-related headers.

I guess I was thinking of it another way... For example, there are lots
of things in boost that I don't use, yet I don't need to #define any
macros whatsoever- I simply don't include the header files.

More specifically, if I want to use only the 'new' Spirit, and not the
classic Spirit, I don't need to

#define DISABLE_CLASSIC_SPIRIT

I simply #include the files that have the functionality that I need.

In sync_connection_base.hpp, classes https_sync_connection and
http_sync_connection are defined.  It's not clear to me why
http_sync_connection should require boost/asio/ssl.hpp to be included...
if these two classes were defined in separate files (say
https_sync_connection.hpp and http_sync_connection.hpp) couldn't we
avoid the need to have a command-line #define to eliminate something
that my program never requested?

I'm not sure exactly how the design evolved, but I'm guessing it started
with just http and then https was added, leading to the branching on
'bool https' in sync_connection_base::new_connection.

I haven't looked through the code, but it feels a little like https is a
little uncomfortable there... suppose some other transports become
available for http, and we end up with 'httpa', 'httpb', and 'httpc'.
It seems to me that #defining three more things that I don't want to
use, and adding three more args to sync_connection_base::new_connection
would feel a little strange.

Anyway, this is just my viewpoint- I know you've got tons of stuff to
do, and my parents always told me not to get in the way of the person
doing the work.  However you decide to handle it is fine with me.

Erik