cpp-netlib-devel — Developers Mailing List

[cpp-netlib-devel] Why header only? (was Re: Dependence on std::string)

[Dean M. B. <mik...@gm...>]

Hi Matt!

On 7/17/07, Matt Gruenke <mgr...@in...> wrote:
> Glyn Matthews wrote:
>
> > Another thing I see is that boost filesystem and boost program_options
> > have
> > dealt with a very similar problem to this.  But if we use the same
> > approach
> > (see the file "boost/detail/utf8_codecvt_facet.hpp" )  then we'd have to
> > accept the use of a cpp source file, meaning we will no longer have a
> > header
> > only library.
>
>
> Why is that so bad?  More to the point, why would it be a requirement
> for something as big as a network protocol library to be header-only?
>

Okay, let me try to answer why it should be header only:

* Only pay for what you use -- with how templates work in C++, only
the things that are actually used will be made part of the binary
output. That means, even if you have a class that has an inordinate
number of member methods, only those methods you actually use will be
compiled to the final output binary. That's space efficiency without
having to rely on the compiler's non-standard optimizations (like dead
code removal, etc. if you didn't use templates).

* Cross-platform functionality without the baggage -- with the target
of being usable on all platforms on which the Boost C++ library can be
used in, the idea now is to not require applications that need to use
the network library to link externally to a shared library. This
allows the users to actually get the functionality they need into the
application -- and since we're not implementing system-level
implementations of the network protocols, making your applications
require a shared library would be just "not courteous". Again, the
point here is that we can allow people to leverage on client/server(?)
source-level implementations without having them link to an external
library.

* Version Freeze and Backward Compatibility -- as an offshoot of the
above, when we put out changes we just need to worry about people who
will be using the new version of the library in their projects "to
build" and not have to worry about applications that link to the
library externally and breaking API's in that manner. I envision the
library to be useful for enabling applications to invoke remote
network resources using a simple set of functions and objects in a
very efficient manner -- adding an external library to be required to
run the application is _not_ included in the "simple set of functions
and objects in a very efficient manner".

So as much as possible, we avoid dynamic polymorphic types because it
requires Runtime Type Information (RTTI) which tends to slow down
code. We also avoid externally built libraries for applications to
link to because that makes the solution practically more complex -- in
the sense that it introduces (IMO) unnecessary external dependencies.
Couple these things together, having RTTI in external libraries makes
your application bloated and unnecessarily complex.

If there's one compelling reason why we should build external
libraries (which I honestly think there isn't) I would love to hear
it. On the other hand, I don't think there is a reason for us _not_ to
strive to make this library header only by exploiting the C++ language
features that we have at our disposal.

I hope this makes sense. :-)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] Dependence on std::string

[Cheng L. <rhy...@gm...>]

By the way, I wish that Dean may explain the seven proposed tags in 
detail, especially the binary tag and the stream tag which seems may 
feed my appetite :-D

连城 wrote:
> Hi, Glyn
>
> I am recently working on a binary protocol oriented network framework
> based on ASIO in my project. So I do care more about a binary protocol
> oriented message type. so I have once asked Dean a question during a
> private communication:
>
>    What's the granularity of the Tag template parameter of
>    basic_message<> template? One tag per message type (I means
>    text/binary here) or one tag per protocol?
>
> And Dean replied:
>
>    The Tag template parameter is meant to differentiate the message
>    types -- for easy extension. That means, to be clear, the message
>    tags I envision are:
>
>    tags::unicode
>    tags::text (tags::default_)
>    tags::binary
>    tags::stream
>    tags::serializable_text
>    tags::serializable_binary
>    tags::serializable_xml
>
>    Among many others I haven't thought of yet. :D
>
>    They are tags, because I don't intend to put the overhead of an
>    abstract message class as the base class for all the message
>    types.  That allows us to implement a basic_message<tags::text>
>    and basic_message<tags::binary>, and specialize the
>    implementations without having to rely on inheritance and runtime
>    polymorphism.
>
> As Dean stated, with such tags, we can specialize different message
> types. And I think the message type tags should imply the underlying
> storage policy of that type of basic_message. Say, tags::text
> (tags::default_) implies an std::string storage facility, while
> tags::unicode implies an std::wstring storage facility, and
> tags::stream may implies a boost::asio::streambuf storage facility (as
> what I've done in my own project). So I suggest we could include a
> storage_type in the tags struct:
>
>    struct tags {
>        struct default_ {
>            typedef std::string storage_type;
>        };
>
>        typedef default_::text;
>
>        struct unicode {
>            typedef std::wstring storage_type;
>        };
>
>        struct stream {
>            typedef boost::asio::streambuf storage_type;
>        };
>
>        ...
>    };
>
>    typedef basic_message<tags::text> message;
>    typedef basic_message<tags::unicode> wmessage;
>    typedef basic_message<tags::stream> smessage;
>    ...
>
> Would this be sane?
>
> Cheers
> Cheng
>
>
> Glyn Matthews wrote:
>> Guys,
>>
>> I've been giving a little thought to something Dean mentioned in his 
>> last message about using std::string in the network library.
>>
>> The first thing I thought of was that Dean stated that "everything is 
>> a template".  Apart of course from std::string.  I have created a 
>> branch in SVN named gxm) which replaces all references to std::string 
>> with an extra template parameter.  Happily, this passes all the 
>> original tests (with an additional template specialization so that 
>> const char * is converted to a std::string).  However, this creates a 
>> problem (certainly with GCC) because the wchar_t typedef is the same 
>> as char and its not possible to overload const wchar_t * in the same 
>> way.  So the following code will not compile:
>>
>> wmessage wmsg;
>> wmsg << header(L"wide characters");
>>
>> Another thing I see is that boost filesystem and boost 
>> program_options have dealt with a very similar problem to this.  But 
>> if we use the same approach (see the file 
>> "boost/detail/utf8_codecvt_facet.hpp" )  then we'd have to accept the 
>> use of a cpp source file, meaning we will no longer have a header 
>> only library.
>>
>> What do others think about this?
>>
>> G
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Cpp-netlib-devel mailing list
>> Cpp...@li...
>> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>>   
>
>

Re: [cpp-netlib-devel] Dependence on std::string

[<rhy...@gm...>]

Hi, Glyn

I am recently working on a binary protocol oriented network framework
based on ASIO in my project. So I do care more about a binary protocol
oriented message type. so I have once asked Dean a question during a
private communication:

    What's the granularity of the Tag template parameter of
    basic_message<> template? One tag per message type (I means
    text/binary here) or one tag per protocol?

And Dean replied:

    The Tag template parameter is meant to differentiate the message
    types -- for easy extension. That means, to be clear, the message
    tags I envision are:

    tags::unicode
    tags::text (tags::default_)
    tags::binary
    tags::stream
    tags::serializable_text
    tags::serializable_binary
    tags::serializable_xml

    Among many others I haven't thought of yet. :D

    They are tags, because I don't intend to put the overhead of an
    abstract message class as the base class for all the message
    types.  That allows us to implement a basic_message<tags::text>
    and basic_message<tags::binary>, and specialize the
    implementations without having to rely on inheritance and runtime
    polymorphism.

As Dean stated, with such tags, we can specialize different message
types. And I think the message type tags should imply the underlying
storage policy of that type of basic_message. Say, tags::text
(tags::default_) implies an std::string storage facility, while
tags::unicode implies an std::wstring storage facility, and
tags::stream may implies a boost::asio::streambuf storage facility (as
what I've done in my own project). So I suggest we could include a
storage_type in the tags struct:

    struct tags {
        struct default_ {
            typedef std::string storage_type;
        };

        typedef default_::text;

        struct unicode {
            typedef std::wstring storage_type;
        };

        struct stream {
            typedef boost::asio::streambuf storage_type;
        };

        ...
    };

    typedef basic_message<tags::text> message;
    typedef basic_message<tags::unicode> wmessage;
    typedef basic_message<tags::stream> smessage;
    ...

Would this be sane?

Cheers
Cheng


Glyn Matthews wrote:
> Guys,
>
> I've been giving a little thought to something Dean mentioned in his 
> last message about using std::string in the network library.
>
> The first thing I thought of was that Dean stated that "everything is 
> a template".  Apart of course from std::string.  I have created a 
> branch in SVN named gxm) which replaces all references to std::string 
> with an extra template parameter.  Happily, this passes all the 
> original tests (with an additional template specialization so that 
> const char * is converted to a std::string).  However, this creates a 
> problem (certainly with GCC) because the wchar_t typedef is the same 
> as char and its not possible to overload const wchar_t * in the same 
> way.  So the following code will not compile:
>
> wmessage wmsg;
> wmsg << header(L"wide characters");
>
> Another thing I see is that boost filesystem and boost program_options 
> have dealt with a very similar problem to this.  But if we use the 
> same approach (see the file "boost/detail/utf8_codecvt_facet.hpp" )  
> then we'd have to accept the use of a cpp source file, meaning we will 
> no longer have a header only library.
>
> What do others think about this?
>
> G
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>   

Re: [cpp-netlib-devel] Dependence on std::string

[Glyn M. <gly...@gm...>]

Matt,

On 17/07/07, Matt Gruenke <mgr...@in...> wrote:
>
> Glyn Matthews wrote:
>
> > Another thing I see is that boost filesystem and boost program_options
> > have
> > dealt with a very similar problem to this.  But if we use the same
> > approach
> > (see the file "boost/detail/utf8_codecvt_facet.hpp" )  then we'd have to
> > accept the use of a cpp source file, meaning we will no longer have a
> > header
> > only library.
>
>
> Why is that so bad?  More to the point, why would it be a requirement
> for something as big as a network protocol library to be header-only?



I don't think this is so bad, but the original rationale document as set out
by Dean specifically mentions that he wants this as a header only library.
 Glyn

Re: [cpp-netlib-devel] Dependence on std::string

[Matt G. <mgr...@in...>]

Glyn Matthews wrote:

> Another thing I see is that boost filesystem and boost program_options 
> have
> dealt with a very similar problem to this.  But if we use the same 
> approach
> (see the file "boost/detail/utf8_codecvt_facet.hpp" )  then we'd have to
> accept the use of a cpp source file, meaning we will no longer have a 
> header
> only library.


Why is that so bad?  More to the point, why would it be a requirement 
for something as big as a network protocol library to be header-only?


Matt

[cpp-netlib-devel] Dependence on std::string

[Glyn M. <gly...@gm...>]

Guys,

I've been giving a little thought to something Dean mentioned in his last
message about using std::string in the network library.

The first thing I thought of was that Dean stated that "everything is a
template".  Apart of course from std::string.  I have created a branch in
SVN named gxm) which replaces all references to std::string with an extra
template parameter.  Happily, this passes all the original tests (with an
additional template specialization so that const char * is converted to a
std::string).  However, this creates a problem (certainly with GCC) because
the wchar_t typedef is the same as char and its not possible to overload
const wchar_t * in the same way.  So the following code will not compile:

wmessage wmsg;
wmsg << header(L"wide characters");

Another thing I see is that boost filesystem and boost program_options have
dealt with a very similar problem to this.  But if we use the same approach
(see the file "boost/detail/utf8_codecvt_facet.hpp" )  then we'd have to
accept the use of a cpp source file, meaning we will no longer have a header
only library.

What do others think about this?

G

Re: [cpp-netlib-devel] Eureka! ODR-safe placeholder implementation which works in MSVC

[Dean M. B. <mik...@gm...>]

Ei Glyn!

On 7/7/07, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean, good to hear from you!
>

It feels great to be back in C++ development... I can't imagine how
developers who've done the switch from problem solvers to
whip-crackers are managing... ;-) I just hope I can stay in this C++
hacking mode a bit more. :)

> On 07/07/07, Dean Michael Berris <mik...@gm...> wrote:
> > I'd appreciate it if anyone can check in GCC whether the latest in the
> > SVN repo will build and pass the tests correctly.
>
> I can confirm that the tests pass on Linux with GCC (4.1.2) and also with
> the Intel compiler (9.1).
>

Nice! Thanks Glyn!

> > Thanks in advance! Now I can move forward to implementing the common
> > transformations for network messages.
> >
> > How's everybody doing?
>
> Fine.  I'm glad to hear that some progress has been made here, I was a bit
> worried that it has kind of fizzled out.  What according to you is the next
> stage of development, and how can we get involved?
> Glyn
>

The next stage of development would be to build around this simple
message type, and implement what's immediately necessary to get an
HTTP client out the door. There are a few things which I would like to
set as guidelines for the forward progress of the project:

 * The style should be consistent. If you check the code, everything
-- and I mean everything -- is a template (either a template method, a
template class, a nested template class, etc). The rationale for this
is that we'd like to keep external dependencies only limited to the
Boost C++ Library (latest in CVS or SVN when that move happens) and
the STL, and as much as possible not much else.

 * Use TMP (Template MetaProgramming) whenever possible to leverage on
earlier work and static properties of C++.

 * Implement common transformations from one message type to another
using free functions and non-mutable copy semantics (first). That
means let's use the message class as much as possible, make copies
instead of hold references wherever possible to make thread-safe
programming a bit easier, and put in as much extensibility as we can.
Example would be to implement a boost::network::http::request type
which already has default information in the headers and can be
copy-constructed from an existing message instance -- and specific
transformations just for http-request/response messages. I can go into
detail if someone would like to take on this challenge sooner than
later. ;)

If anybody can point out other nit-picks (like my use and dependence
on std::string) and perhaps check in patches to the code without
having to change the tests, that would be greatly appreciated. If
there's anything else, like additional functionality you'd like to put
in, please check in both the unit test which shows the interface and
how it's intended to be used, and the implementation.

I would like to encourage branching if you think you'll be checking in
too many things and breaking a lot of already existing code. You can
use a prefix (like in my case dmcb) as the branch name if and when you
do decide to branch off the main trunk.

I would also like to start the discussion about what other features
you'd like to see the message type and eventually the HTTP client
library support for the first release of the library. Setting feature
milestones (similar to what the RATIONALE document already contains)
would be a good idea for us to gauge when we can do a release and how
much effort we still need to do to come up with something "acceptable"
to the community.

Please let me know your thoughts. :)

Have a great weekend everyone!

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] Eureka! ODR-safe placeholder implementation which works in MSVC

[Glyn M. <gly...@gm...>]

Hi Dean, good to hear from you!

On 07/07/07, Dean Michael Berris <mik...@gm...> wrote:

> I'd appreciate it if anyone can check in GCC whether the latest in the
> SVN repo will build and pass the tests correctly.


I can confirm that the tests pass on Linux with GCC (4.1.2) and also with
the Intel compiler (9.1).


> Thanks in advance! Now I can move forward to implementing the common
> transformations for network messages.
>
> How's everybody doing?


Fine.  I'm glad to hear that some progress has been made here, I was a bit
worried that it has kind of fizzled out.  What according to you is the next
stage of development, and how can we get involved?
Glyn

[cpp-netlib-devel] Eureka! ODR-safe placeholder implementation which works in MSVC

[Dean M. B. <mik...@gm...>]

Okay guys, I know it's long overdue... But after a post in Boost C++
Developer's mailing list, Joaquin Munoz was able to give me pointers
as to go about using ODR-safe placeholder implementations.

Now the tests build and pass (for the message transformer) work in MSVC! Yay!

I'd appreciate it if anyone can check in GCC whether the latest in the
SVN repo will build and pass the tests correctly.

Thanks in advance! Now I can move forward to implementing the common
transformations for network messages.

How's everybody doing?

Hope to hear from you again guys!

PS. Real life has been good to me. I've just committed to a
relationship, and though I've only very little time to be able to do
any non-work related open source development (even though I will have
some time on my hands to work on open source work during work hours)
you should be able to expect a lot more code check ins from me now
that one of the major roadblocks (for me) have been passed. Looking
forward to working on the message-type compliant HTTP client lib soon!

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] Follow Up on RATIONALE comments

[Stjepan R. <st...@as...>]

Hi all,

On 6/10/07, Dean Michael Berris <mik...@gm...> wrote:
> It's a long weekend here in the Philippines, and I've been taking a
> lot of time reflecting on the C++ Networking Library's goals and
> scope. I have posted (which I've attached again here) the RATIONALE
> for developing the library.

Thanks for the RATIONALE - always good to further clarify the big
picture.  I'm not too knowledgeable about networking so I can't speak
much to the feasibility / adequacy of the scope, all I can say is that
it sounds good to me because of the following dependency chain: (which
I just looked up and if anyone wants to correct me or clarify that
would be great):

* ESMTP includes SMTP AUTH
* SMTP uses SASL
* SASL is all about authentication, and that's what I am interested in
the most :-)

I know other people expressed interest in authentication - if someone
wants to take the lead on the authentication aspects and figure out
what tasks need to be done, that would be very helpful for me.  If
someone tells me "implement this algorithm with this interface" I can
do that, otherwise I might be more like a fish on dry land with this
project :-)  I just haven't seen / used / made much networking code to
know where to start myself.

Thanks,

Stjepan

Re: [cpp-netlib-devel] get_real_algorithm compilation error

[Dean M. B. <mik...@gm...>]

On 6/11/07, Cheng Lian <rhy...@gm...> wrote:
>
> As gcc suggests, I added the `template' keyword as following, and it
> works fine:
>
> template <class Algorithm, class Selector>
>     struct get_real_algorithm {
>         typedef typename Algorithm::template type<Selector> type;
>     };
>
> I haven't try the original code under any version of msvc, but I think
> msvc may be more fault tolerant than gcc. I had once encountered a
> similar situation about `typename' :-)
>

Indeed. Nice catch! Thanks Cheng!

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

[cpp-netlib-devel] get_real_algorithm compilation error

[Cheng L. <rhy...@gm...>]

Hi,

Today I updated my svn working directory, and, WOW, new updates! But my 
gcc 4.1.2 complains while compiling the message_transform_test.cpp:

../../../boost/network/message/transformers.hpp:21: error: non-template 
‘type’ used as template
../../../boost/network/message/transformers.hpp:21: note: use 
‘Algorithm::template type’ to indicate that it is a template
../../../boost/network/message/transformers.hpp:21: error: declaration 
does not declare anything

    "g++"  -ftemplate-depth-128 -O0 -fno-inline -Wall -g  
-DBOOST_TEST_NO_AUTO_LINK=1  -I"../../.." -I"/usr/src/boost_1_34_0" -c 
-o "bin/gcc-4.1.2/debug/link-static/message_test.o" "message_test.cpp"

As gcc suggests, I added the `template' keyword as following, and it 
works fine:

template <class Algorithm, class Selector>
    struct get_real_algorithm {
        typedef typename Algorithm::template type<Selector> type;
    };

I haven't try the original code under any version of msvc, but I think 
msvc may be more fault tolerant than gcc. I had once encountered a 
similar situation about `typename' :-)

Cheers
Cheng

Re: [cpp-netlib-devel] test files

[Cheng L. <rhy...@gm...>]

Hi, Christian

I'm afraid msvc 7.1 and boost 1.34 are both innocent :-) The problem is 
this line in both message_test.cpp and message_transform_test.cpp:

#define BOOST_TEST_MODULE message test

Once you define the BOOST_TEST_MODULE in one compile unit, Boost.Test 
actually puts a main() in it. Since there are two BOOST_TEST_MODULE 
defined, two main() are defined. In Dean's Jamfile.v2, message_test.cpp 
and message_transform_test.cpp are compiled separately into two 
executables. If you'd like to build the tests with msvc 7.1, I'm afraid 
you should put these two unit tests into two separate project.

Cheers
Cheng

Christian Henning wrote:
> nope, I'm using Visual Studio 7.1 SP1 with boost 1.34. Guess that's
> the reason why it fails.
>
>
> On 6/11/07, Dean Michael Berris <mik...@gm...> wrote:
>   
>> On 6/11/07, Christian Henning <chh...@gm...> wrote:
>>     
>>> Hi,
>>>
>>> I'm having a problem with the two test files. I cannot have them both
>>> in my project the linker will complain then.
>>>
>>> message_test.obj : error LNK2005: "class boost::unit_test::test_suite
>>> * __cdecl init_unit_test_suite(int,char * * const)"
>>> (?init_unit_test_suite@@YAPAVtest_suite@unit_test@boost@@HQAPAD@Z)
>>> already defined in message_transform_test.obj
>>>
>>>       
>> What version of Boost are you using?
>>
>> I'm currently developing the C++ Networking library against Boost CVS HEAD.
>>
>> Are you using Boost.Build to build the unit tests as well?
>>
>> --
>> Dean Michael C. Berris
>> http://cplusplus-soup.blogspot.com/
>> mikhailberis AT gmail DOT com
>> +63 928 7291459
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Cpp-netlib-devel mailing list
>> Cpp...@li...
>> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>>
>>     
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>
>   

Re: [cpp-netlib-devel] MSVC Problem with 'extern' placeholders

[Dean M. B. <mik...@gm...>]

Hi Christian,

On 6/11/07, Christian Henning <chh...@gm...> wrote:
> Hi Dean, I think the MS compiler is right. Defining a variable extern
> means it has external linkage. We shouldn't try to be "too smart" in
> fooling the compiler. This code can break with every new compiler
> version.
>

Although it does make sense that extern will cause for
compilation/linking to require that the object be allocated somewhere,
if you check the code again for the transform template method, it
doesn't use the extern variables.

  template <class Algorithm, class Selector>
  inline impl::transform_impl<Algorithm, Selector>
  transform(Algorithm, Selector) {
    return impl::transform_impl<Algorithm, Selector>();
  };

That means, when transform(to_header_, source_) is called, nothing
should require linkage to to_header_ and source_ since transform(...)
doesn't use it (but the type information) anywhere.

> I don't see it as a problem when using parenthesis. boost::gil does
> something similar
>
> channel_t& c = get_color( pixel, red_t() );
>

True, but this doesn't scale well when we start implementing stuff
like operator&, operator|, and other operator overloads.

> But if you don't like that then there are other ways, like using an
> enum ( I know it's old school ) or use total template specialization.
> I'm sure there are other ways.
>

Total template specialization doesn't make sense yet, especially if
there's no _easy_ way of invoking transform(...) with placeholders.
Enums are out of the question. ;-)

I guess what I'm really looking for is how boost::bind's _1, _2, _N works... :-D

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] MSVC Problem with 'extern' placeholders

[Christian H. <chh...@gm...>]

Hi Dean, I think the MS compiler is right. Defining a variable extern
means it has external linkage. We shouldn't try to be "too smart" in
fooling the compiler. This code can break with every new compiler
version.

I don't see it as a problem when using parenthesis. boost::gil does
something similar

channel_t& c = get_color( pixel, red_t() );

But if you don't like that then there are other ways, like using an
enum ( I know it's old school ) or use total template specialization.
I'm sure there are other ways.

Christian

On 6/11/07, Dean Michael Berris <mik...@gm...> wrote:
> Hi Christian,
>
> On 6/11/07, Christian Henning <chh...@gm...> wrote:
> >
> > And there were no problems. Does that makes sense to you?
> >
>
> Two issues here:
>
> 1. The unit test is a specification on how the interface is meant to
> be. Although your solution would work, the readability of additional
> parentheses aren't very appealing to me. The unit test is an example
> in itself of how the interface *should* look like and I'd like
> to_upper_ (and other future transformations to be implemented) to not
> have the extra parentheses.
>
>   msg << transform(to_upper_, source_) ;
>
> Reads better IMO than
>
>   msg << transform(to_upper_(), source_()) ;
>
> The same way
>
>   boost::bind(&function, _1) ;
>
> Reads better than
>
>   boost::bind(&function, _1()) ;
>
> 2. The premium is put on readability and extensibility. The transform
> template function is meant to extend to more than just a pair of
> parameters. For flexibility's sake, see the example below:
>
>   msg << transform(to_upper_, source_ & destination_)
>     << transform(headers_, to_upper_ & trim_)
>   ;
>
> With template metaprogramming, operator& can be overloaded to produce
> a composite selector and composite transformations. This gives
> 'transform' a flexible enough interface which allows:
>
>   msg << transform(to_upper_, source_) << transform(source_, to_upper_) ;
>
> Of course, with the help of template metaprogramming. In this regard,
> having extra parentheses doesn't help with readability.
>
> NOTE: This is the direction of the transformation interface (and other
> interfaces to the message type in general), to leverage on
> compile-time meta-programming to produce readable and flexible
> interfaces.
>
> The above are the two rationale's for why I opted for 'extern
> to_upper_placeholder to_upper_' instead of making it a typedef in the
> first place. It just so happened that my first iteration
> implementation hit a snag (which I sure hope would be temporary).
>
> So the real question now would be (assuming it works with GCC) how we
> can allow the above parentheses-less while keeping MSVC and other
> compilers happy?
>
> --
> Dean Michael C. Berris
> http://cplusplus-soup.blogspot.com/
> mikhailberis AT gmail DOT com
> +63 928 7291459
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

Re: [cpp-netlib-devel] MSVC Problem with 'extern' placeholders

[Dean M. B. <mik...@gm...>]

Hi Christian,

On 6/11/07, Christian Henning <chh...@gm...> wrote:
>
> And there were no problems. Does that makes sense to you?
>

Two issues here:

1. The unit test is a specification on how the interface is meant to
be. Although your solution would work, the readability of additional
parentheses aren't very appealing to me. The unit test is an example
in itself of how the interface *should* look like and I'd like
to_upper_ (and other future transformations to be implemented) to not
have the extra parentheses.

  msg << transform(to_upper_, source_) ;

Reads better IMO than

  msg << transform(to_upper_(), source_()) ;

The same way

  boost::bind(&function, _1) ;

Reads better than

  boost::bind(&function, _1()) ;

2. The premium is put on readability and extensibility. The transform
template function is meant to extend to more than just a pair of
parameters. For flexibility's sake, see the example below:

  msg << transform(to_upper_, source_ & destination_)
    << transform(headers_, to_upper_ & trim_)
  ;

With template metaprogramming, operator& can be overloaded to produce
a composite selector and composite transformations. This gives
'transform' a flexible enough interface which allows:

  msg << transform(to_upper_, source_) << transform(source_, to_upper_) ;

Of course, with the help of template metaprogramming. In this regard,
having extra parentheses doesn't help with readability.

NOTE: This is the direction of the transformation interface (and other
interfaces to the message type in general), to leverage on
compile-time meta-programming to produce readable and flexible
interfaces.

The above are the two rationale's for why I opted for 'extern
to_upper_placeholder to_upper_' instead of making it a typedef in the
first place. It just so happened that my first iteration
implementation hit a snag (which I sure hope would be temporary).

So the real question now would be (assuming it works with GCC) how we
can allow the above parentheses-less while keeping MSVC and other
compilers happy?

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] test files

[Dean M. B. <mik...@gm...>]

On 6/11/07, Christian Henning <chh...@gm...> wrote:
> nope, I'm using Visual Studio 7.1 SP1 with boost 1.34. Guess that's
> the reason why it fails.
>

How do you build the unit tests? You don't use Boost.Build v2?

If you have configured Boost 1.34 correctly and installed Boost.Jam to
your PATH, you should be able to go to libs/network/test and do
'bjam'. This also requires that you have the BOOST_ROOT environment
variable set to where the Boost distribution root is.

HTH

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] test files

[Christian H. <chh...@gm...>]

nope, I'm using Visual Studio 7.1 SP1 with boost 1.34. Guess that's
the reason why it fails.


On 6/11/07, Dean Michael Berris <mik...@gm...> wrote:
> On 6/11/07, Christian Henning <chh...@gm...> wrote:
> > Hi,
> >
> > I'm having a problem with the two test files. I cannot have them both
> > in my project the linker will complain then.
> >
> > message_test.obj : error LNK2005: "class boost::unit_test::test_suite
> > * __cdecl init_unit_test_suite(int,char * * const)"
> > (?init_unit_test_suite@@YAPAVtest_suite@unit_test@boost@@HQAPAD@Z)
> > already defined in message_transform_test.obj
> >
>
> What version of Boost are you using?
>
> I'm currently developing the C++ Networking library against Boost CVS HEAD.
>
> Are you using Boost.Build to build the unit tests as well?
>
> --
> Dean Michael C. Berris
> http://cplusplus-soup.blogspot.com/
> mikhailberis AT gmail DOT com
> +63 928 7291459
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

Re: [cpp-netlib-devel] test files

[Dean M. B. <mik...@gm...>]

On 6/11/07, Christian Henning <chh...@gm...> wrote:
> Hi,
>
> I'm having a problem with the two test files. I cannot have them both
> in my project the linker will complain then.
>
> message_test.obj : error LNK2005: "class boost::unit_test::test_suite
> * __cdecl init_unit_test_suite(int,char * * const)"
> (?init_unit_test_suite@@YAPAVtest_suite@unit_test@boost@@HQAPAD@Z)
> already defined in message_transform_test.obj
>

What version of Boost are you using?

I'm currently developing the C++ Networking library against Boost CVS HEAD.

Are you using Boost.Build to build the unit tests as well?

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] MSVC Problem with 'extern' placeholders

[Christian H. <chh...@gm...>]

Dean,

I just put a typedef on front of:

typedef to_upper_placeholder to_upper_;
typedef selectors::source_selector source_;
typedef selectors::destination_selector destination_;

I changed the test code to:

msg << transform(to_upper_(), source_());

And there were no problems. Does that makes sense to you?

Christian


On 6/11/07, Christian Henning <chh...@gm...> wrote:
> Dean, if you remove the extern specifier it compiles fine on my
> machine. I'm using MSVC 7.1. Why did you decided to implement it this
> way? Is it possible to just typedef this information?
>
> Thanks,
> Christian
>
>
>
> On 6/11/07, Dean Michael Berris <mik...@gm...> wrote:
> > Hi Everyone,
> >
> > I've only recently been developing with MSVC, and while I've been
> > trying to implement the transformations to the message class I hit a
> > nasty snag. Let me identify what the problem is.
> >
> > First, in boost/network/message/transformers/to_upper.hpp I have the following:
> >
> >     struct to_upper_placeholder {
> >         template <class Selector>
> >             struct type : public impl::to_upper_transformer<Selector> { };
> >     } ;
> >
> >     extern to_upper_placeholder to_upper_;
> >
> > I also have in boost/network/message/transformers/selectors.hpp:
> >
> >     namespace selectors {
> >         struct source_selector { };
> >         struct destination_selector { };
> >     }; // namespace selectors
> >
> >     extern selectors::source_selector source_;
> >     extern selectors::destination_selector destination_;
> >
> > What I'm concerned about, is that the MSVC linker keeps asking for
> > where to look for these externs when I have the following function
> > template in boost/network/transformers.hpp :
> >
> >
> >     template <class Algorithm, class Selector>
> >         inline impl::transform_impl<Algorithm, Selector>
> >         transform(Algorithm, Selector) {
> >             return impl::transform_impl<Algorithm, Selector>();
> >         };
> >
> > This is used in the unit test (which fails to compile in MSVC 8)
> > libs/network/test/message_transform_test.cpp :
> >
> >     using namespace boost::network;
> >
> >     message msg;
> >     msg << source("me");
> >     BOOST_CHECK_EQUAL ( source(msg), "me" );
> >     msg << transform(to_upper_, source_);
> >     BOOST_CHECK_EQUAL ( source(msg), "ME" );
> >
> > Clearly, the 'transform' template method only requires the type
> > information of to_upper_ (an extern to_upper_placeholder) and source_
> > (an extern selectors::source_selector) but MSVC seems to require that
> > they be linkable from somewhere.
> >
> > Any thoughts on the matter? I haven't tried this in GCC yet, but I'm
> > confident that GCC would know that I don't really need to link to
> > these instances -- that I just need the type to be deduced in the
> > 'transform' template and not care about the actual instances.
> >
> > Help and insight would be most appreciated.
> >
> > Thanks and hope to hear from any one of you soon!
> >
> > (Please update to Revision 17 to get the latest unit tests and
> > implementations from trunk/)
> >
> > --
> > Dean Michael C. Berris
> > http://cplusplus-soup.blogspot.com/
> > mikhailberis AT gmail DOT com
> > +63 928 7291459
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Cpp-netlib-devel mailing list
> > Cpp...@li...
> > https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
> >
>

[cpp-netlib-devel] test files

[Christian H. <chh...@gm...>]

Hi,

I'm having a problem with the two test files. I cannot have them both
in my project the linker will complain then.

message_test.obj : error LNK2005: "class boost::unit_test::test_suite
* __cdecl init_unit_test_suite(int,char * * const)"
(?init_unit_test_suite@@YAPAVtest_suite@unit_test@boost@@HQAPAD@Z)
already defined in message_transform_test.obj

Christian

Re: [cpp-netlib-devel] MSVC Problem with 'extern' placeholders

[Christian H. <chh...@gm...>]

Dean, if you remove the extern specifier it compiles fine on my
machine. I'm using MSVC 7.1. Why did you decided to implement it this
way? Is it possible to just typedef this information?

Thanks,
Christian



On 6/11/07, Dean Michael Berris <mik...@gm...> wrote:
> Hi Everyone,
>
> I've only recently been developing with MSVC, and while I've been
> trying to implement the transformations to the message class I hit a
> nasty snag. Let me identify what the problem is.
>
> First, in boost/network/message/transformers/to_upper.hpp I have the following:
>
>     struct to_upper_placeholder {
>         template <class Selector>
>             struct type : public impl::to_upper_transformer<Selector> { };
>     } ;
>
>     extern to_upper_placeholder to_upper_;
>
> I also have in boost/network/message/transformers/selectors.hpp:
>
>     namespace selectors {
>         struct source_selector { };
>         struct destination_selector { };
>     }; // namespace selectors
>
>     extern selectors::source_selector source_;
>     extern selectors::destination_selector destination_;
>
> What I'm concerned about, is that the MSVC linker keeps asking for
> where to look for these externs when I have the following function
> template in boost/network/transformers.hpp :
>
>
>     template <class Algorithm, class Selector>
>         inline impl::transform_impl<Algorithm, Selector>
>         transform(Algorithm, Selector) {
>             return impl::transform_impl<Algorithm, Selector>();
>         };
>
> This is used in the unit test (which fails to compile in MSVC 8)
> libs/network/test/message_transform_test.cpp :
>
>     using namespace boost::network;
>
>     message msg;
>     msg << source("me");
>     BOOST_CHECK_EQUAL ( source(msg), "me" );
>     msg << transform(to_upper_, source_);
>     BOOST_CHECK_EQUAL ( source(msg), "ME" );
>
> Clearly, the 'transform' template method only requires the type
> information of to_upper_ (an extern to_upper_placeholder) and source_
> (an extern selectors::source_selector) but MSVC seems to require that
> they be linkable from somewhere.
>
> Any thoughts on the matter? I haven't tried this in GCC yet, but I'm
> confident that GCC would know that I don't really need to link to
> these instances -- that I just need the type to be deduced in the
> 'transform' template and not care about the actual instances.
>
> Help and insight would be most appreciated.
>
> Thanks and hope to hear from any one of you soon!
>
> (Please update to Revision 17 to get the latest unit tests and
> implementations from trunk/)
>
> --
> Dean Michael C. Berris
> http://cplusplus-soup.blogspot.com/
> mikhailberis AT gmail DOT com
> +63 928 7291459
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Cpp-netlib-devel mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpp-netlib-devel
>

[cpp-netlib-devel] MSVC Problem with 'extern' placeholders

[Dean M. B. <mik...@gm...>]

Hi Everyone,

I've only recently been developing with MSVC, and while I've been
trying to implement the transformations to the message class I hit a
nasty snag. Let me identify what the problem is.

First, in boost/network/message/transformers/to_upper.hpp I have the following:

    struct to_upper_placeholder {
        template <class Selector>
            struct type : public impl::to_upper_transformer<Selector> { };
    } ;

    extern to_upper_placeholder to_upper_;

I also have in boost/network/message/transformers/selectors.hpp:

    namespace selectors {
        struct source_selector { };
        struct destination_selector { };
    }; // namespace selectors

    extern selectors::source_selector source_;
    extern selectors::destination_selector destination_;

What I'm concerned about, is that the MSVC linker keeps asking for
where to look for these externs when I have the following function
template in boost/network/transformers.hpp :


    template <class Algorithm, class Selector>
        inline impl::transform_impl<Algorithm, Selector>
        transform(Algorithm, Selector) {
            return impl::transform_impl<Algorithm, Selector>();
        };

This is used in the unit test (which fails to compile in MSVC 8)
libs/network/test/message_transform_test.cpp :

    using namespace boost::network;

    message msg;
    msg << source("me");
    BOOST_CHECK_EQUAL ( source(msg), "me" );
    msg << transform(to_upper_, source_);
    BOOST_CHECK_EQUAL ( source(msg), "ME" );

Clearly, the 'transform' template method only requires the type
information of to_upper_ (an extern to_upper_placeholder) and source_
(an extern selectors::source_selector) but MSVC seems to require that
they be linkable from somewhere.

Any thoughts on the matter? I haven't tried this in GCC yet, but I'm
confident that GCC would know that I don't really need to link to
these instances -- that I just need the type to be deduced in the
'transform' template and not care about the actual instances.

Help and insight would be most appreciated.

Thanks and hope to hear from any one of you soon!

(Please update to Revision 17 to get the latest unit tests and
implementations from trunk/)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459

Re: [cpp-netlib-devel] Follow Up on RATIONALE comments

[Glyn M. <gly...@gm...>]

Hi Dean,

On 10/06/07, Dean Michael Berris <mik...@gm...> wrote:
>
> Hi Everyone,
>
> I would like to spend the week discussing everyone's comments and
> suggestions regarding the RATIONALE document. This will allow me to
> make the appropriate changes/additions before we really start digging
> into the details of the implementation.
>
> I certainly feel this is a necessary step to be able to systematically
> move forward with this project.


Personally, I'm happy with what you've given as the goals, but I'd also add
that it should be simple to be able to add custom protocols.  We can provide
the common implementations that you described, but I think the success of
the library will depend on the ability of library users to use their own.
Others on this list know more about the feasibility of providing a DNS
implementation.  Otherwise what you describe can already be useful and I
think we have enough expertise among us to produce something pretty
effective.

Please let me know your thoughts about the project, so we can finally
> get going towards a direction we all would feel comfortable going to.
>
> Thank you very much, and I certainly hope to hear from everyone soon.
>
> Have a great weekend everyone!



You too,
Glyn

[cpp-netlib-devel] Follow Up on RATIONALE comments

[Dean M. B. <mik...@gm...>]

Hi Everyone,

It's a long weekend here in the Philippines, and I've been taking a
lot of time reflecting on the C++ Networking Library's goals and
scope. I have posted (which I've attached again here) the RATIONALE
for developing the library.

It would be great if we can somehow put a schedule/timeline as to what
we want to accomplish by when. This will also give us a chance to
allot time for the project (in case we have some ;) ) during our days,
and so that we can get a feel of whatever our challenges and
approaches will be.

I would like to spend the week discussing everyone's comments and
suggestions regarding the RATIONALE document. This will allow me to
make the appropriate changes/additions before we really start digging
into the details of the implementation.

I certainly feel this is a necessary step to be able to systematically
move forward with this project.

Please let me know your thoughts about the project, so we can finally
get going towards a direction we all would feel comfortable going to.

Thank you very much, and I certainly hope to hear from everyone soon.

Have a great weekend everyone!

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459