Menu
▾
▴
cpp-netlib-devel
|
From: Glyn M. <gly...@gm...> - 2008-10-07 10:23:08
|
Kim,
2008/10/7 Kim Gräsman <kim...@gm...>
> I think I was having problems with the different shapes of different
> types of URIs, and that each scheme should probably be represented by
> its own class. I'm not sure, for example, what the HTTP client should
> do if it's presented with an FTP URL.
>
I don't know if its worth the hassle of having a distinct class for each
scheme. I was thinking about building URIs using directives in a similar
way to what we have with messages:
boost::network::uri uri;
uri << scheme("http")
<< authority("www.boost.org")
<< path("path")
<< query("x=5")
<< fragment("bananas")
;
boost::network::http::request request(uri);
OR
boost::network::http::request request(uri.string());
And for parsing:
std::string scheme = boost::network::uri::scheme(uri);
std::string authority = boost::network::uri::authority(uri);
etc.
Is this too simplistic? Do you see any problems with this approach?
Glyn
|
|
From: K. G. <kim...@gm...> - 2008-10-07 10:58:12
|
Hi Glyn,
On Tue, Oct 7, 2008 at 12:12, Glyn Matthews <gly...@gm...> wrote:
>
> I don't know if its worth the hassle of having a distinct class for each
> scheme. I was thinking about building URIs using directives in a similar
> way to what we have with messages:
>
> boost::network::uri uri;
> uri << scheme("http")
> << authority("www.boost.org")
> << path("path")
> << query("x=5")
> << fragment("bananas")
> ;
It looks nice in a way, but I'm not sure how often you start with
components and want to join them into a URI? I think the usual use
case is you have a URI string and want to modify parts of it. But this
API would allow that too, I suppose.
> Is this too simplistic? Do you see any problems with this approach?
Depending on the variance of URIs, though, this might not be
simplistic enough :-)
I think there may be enough format variance to justify a
directive-based model, rather than just a simple data class, though.
Interesting.
- Kim
|
|
From: Glyn M. <gly...@gm...> - 2008-10-07 11:24:17
|
Hi,
2008/10/7 Kim Gräsman <kim...@gm...>
> Hi Glyn,
>
> On Tue, Oct 7, 2008 at 12:12, Glyn Matthews <gly...@gm...>
> wrote:
> >
> > I don't know if its worth the hassle of having a distinct class for each
> > scheme. I was thinking about building URIs using directives in a similar
> > way to what we have with messages:
> >
> > boost::network::uri uri;
> > uri << scheme("http")
> > << authority("www.boost.org")
> > << path("path")
> > << query("x=5")
> > << fragment("bananas")
> > ;
>
> It looks nice in a way, but I'm not sure how often you start with
> components and want to join them into a URI? I think the usual use
> case is you have a URI string and want to modify parts of it. But this
> API would allow that too, I suppose.
Yeah, you could always accept a string in the constructor arguments:
boost::network::uri uri("http//www.boost.org/path?x=5#bananas");
Or:
boost::network::uri uri("http//www.boost.org/path");
uri << query("x=5") << query("y=6");
Or:
boost::network::uri boost_org("http//www.boost.org/");
boost::network uri;
uri << boost_org << path("path") << query_param("x", 5);
I think the directives can be considered as helpers, not really as *the* way
of building URIs. Building URIs from strings will be most common.
G
|
|
From: K. G. <kim...@gm...> - 2008-10-07 20:30:57
|
Hi Glyn,
On Tue, Oct 7, 2008 at 13:19, Glyn Matthews <gly...@gm...> wrote:
>
> boost::network::uri uri("http//www.boost.org/path");
> uri << query("x=5") << query("y=6");
>
> Or:
> boost::network::uri boost_org("http//www.boost.org/");
> boost::network uri;
> uri << boost_org << path("path") << query_param("x", 5);
>
> I think the directives can be considered as helpers, not really as *the* way
> of building URIs. Building URIs from strings will be most common.
Nice. I'll play around with it, time permitting. I'm on parental
leave, so my daily schedule is highly dependent on the whims of my
one-year-old :-)
- Kim
|
|
From: Dean M. B. <mik...@gm...> - 2008-10-08 22:25:08
|
Hey Guys!
Sorry I was out for a bit. Personal health issues aside, I should be
back on track.
On Wed, Oct 8, 2008 at 4:30 AM, Kim Gräsman <kim...@gm...> wrote:
> Hi Glyn,
>
> On Tue, Oct 7, 2008 at 13:19, Glyn Matthews <gly...@gm...> wrote:
>>
>> boost::network::uri uri("http//www.boost.org/path");
>> uri << query("x=5") << query("y=6");
>>
>> Or:
>> boost::network::uri boost_org("http//www.boost.org/");
>> boost::network uri;
>> uri << boost_org << path("path") << query_param("x", 5);
>>
>> I think the directives can be considered as helpers, not really as *the* way
>> of building URIs. Building URIs from strings will be most common.
>
I like this! :D
> Nice. I'll play around with it, time permitting. I'm on parental
> leave, so my daily schedule is highly dependent on the whims of my
> one-year-old :-)
Sweet. :) If you need any help on directives, you can look at how I do
it with the network::message implementation.
One thing we can do is simply use a Boost.Fusion associative sequence
(a fusion map) like we do now to build and store the URI parts in the
HTTP request's 'uri' method.
If you think about it, we just need to generalize the URI parsing and
it shouldn't be hard to factor this out.
If we can do it real soon (along with fixing the Python server tests)
maybe 0.3 will be a more jam-packed release than what I originally
envisioned. ;-)
--
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
|
|
From: K. G. <kim...@gm...> - 2008-10-09 07:07:49
|
Hi guys, On Thu, Oct 9, 2008 at 00:25, Dean Michael Berris <mik...@gm...> wrote: > >> Nice. I'll play around with it, time permitting. I'm on parental >> leave, so my daily schedule is highly dependent on the whims of my >> one-year-old :-) > > Sweet. :) If you need any help on directives, you can look at how I do > it with the network::message implementation. Yes, I've looked at it a bit already, thanks. > One thing we can do is simply use a Boost.Fusion associative sequence > (a fusion map) like we do now to build and store the URI parts in the > HTTP request's 'uri' method. > > If you think about it, we just need to generalize the URI parsing and > it shouldn't be hard to factor this out. I've already factored this out into a simplistic uri class, but no directive support yet. Not sure I can cook anything up with any speed, but I'm experimenting... - Kim |
|
From: Glyn M. <gly...@gm...> - 2008-10-09 08:07:38
|
Hi Dean, 2008/10/9 Dean Michael Berris <mik...@gm...> > Hey Guys! > > Sorry I was out for a bit. Personal health issues aside, I should be > back on track. > OK, good :) I hope you're better already. If we can do it real soon (along with fixing the Python server tests) > maybe 0.3 will be a more jam-packed release than what I originally > envisioned. ;-) > Do you have a plan for 0.3? * Fixing the tests * Updating docs * URI parsing * anything else? Glyn |
|
From: Dean M. B. <mik...@gm...> - 2008-10-13 01:58:14
|
Hi Glyn, On Thu, Oct 9, 2008 at 4:07 PM, Glyn Matthews <gly...@gm...> wrote: > Hi Dean, > > 2008/10/9 Dean Michael Berris <mik...@gm...> >> >> Hey Guys! >> >> Sorry I was out for a bit. Personal health issues aside, I should be >> back on track. > > OK, good :) I hope you're better already. > Thanks. :) >> If we can do it real soon (along with fixing the Python server tests) >> maybe 0.3 will be a more jam-packed release than what I originally >> envisioned. ;-) > > Do you have a plan for 0.3? > > * Fixing the tests I think this is done in http_integration. > * Updating docs This is still a TODO for me. :D > * URI parsing If Kim has something up in the subversion tree, it might be good to have it initially merged into trunk. I can then try and merge the URI parsing parts from trunk to http_integration, use the URI parsing in the http::request object. > * anything else? I'm waiting for a plan of attack for the MIME library, which is growing more and more interesting as the days go on. I've also been in contact with a few people who've already been using the library (release 0.2) and they're growing more and more interested in: - how we'll support 1.1 - whether asynchronous body readers will be supported (streaming callbacks) There's also some insight about mimicking whatever CURL has, but that's a little too ambitious for us at the moment. :D HTH! -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: Glyn M. <gly...@gm...> - 2008-10-09 08:08:49
|
Hi Kim, 2008/10/9 Kim Gräsman <kim...@gm...> > > I've already factored this out into a simplistic uri class, but no > directive support yet. > > Not sure I can cook anything up with any speed, but I'm experimenting... > Can you create a branch from trunk for this, so we can follow your updates? Ta, Glyn |
|
From: K. G. <kim...@gm...> - 2008-10-09 15:22:20
|
Hi Glyn, On Thu, Oct 9, 2008 at 10:08, Glyn Matthews <gly...@gm...> wrote: > > Can you create a branch from trunk for this, so we can follow your updates? How about the http_integration branch? That's where I am at the moment... I can just check in the uri and uri_tests without integrating with the rest of the code, if you want. - K |
|
From: Glyn M. <gly...@gm...> - 2008-10-09 18:39:49
|
Hi Kim, 2008/10/9 Kim Gräsman <kim...@gm...> > Hi Glyn, > > On Thu, Oct 9, 2008 at 10:08, Glyn Matthews <gly...@gm...> > wrote: > > > > Can you create a branch from trunk for this, so we can follow your > updates? > > How about the http_integration branch? That's where I am at the > moment... I can just check in the uri and uri_tests without > integrating with the rest of the code, if you want. > Well it's not really part of the HTTP integration. And it's not much better doing all development in a single branch than doing it all in trunk. What I think is best is to develop different tasks in different branches, while testing against trunk. Ideally, branches should correspond to a task/subproject on the sf site too. G |
|
From: K. G. <kim...@gm...> - 2008-10-10 12:55:57
|
Hi guys, On Thu, Oct 9, 2008 at 20:39, Glyn Matthews <gly...@gm...> wrote: > > Well it's not really part of the HTTP integration. And it's not much better > doing all development in a single branch than doing it all in trunk. What I > think is best is to develop different tasks in different branches, while > testing against trunk. Ideally, branches should correspond to a > task/subproject on the sf site too. I created a branch succinctly called 'uri', on https://cpp-netlib.svn.sourceforge.net/svnroot/cpp-netlib/branches/uri I've committed the first fumbling parts there, in /boost/network/uri.hpp and /libs/network/test/uri_test.hpp. At least it's a start, not sure where to go from there... I didn't parameterize the string type mainly because the default tag is under network/protocol/http, and the URI goes one level up in the hierarchy, but I suppose I could introduce a temporary tag to wrap the string typedef. - Kim |
|
From: Glyn M. <gly...@gm...> - 2008-10-10 12:59:30
|
Hi Kim, 2008/10/10 Kim Gräsman <kim...@gm...> > > I created a branch succinctly called 'uri', on > https://cpp-netlib.svn.sourceforge.net/svnroot/cpp-netlib/branches/uri > > I've committed the first fumbling parts there, in > /boost/network/uri.hpp and /libs/network/test/uri_test.hpp. > > At least it's a start, not sure where to go from there... > Thanks. I'll take a look when I have time over the weekend. Glyn |
|
From: Glyn M. <gly...@gm...> - 2008-10-12 11:22:25
|
Hi Kim, 2008/10/10 Glyn Matthews <gly...@gm...> > Hi Kim, > > 2008/10/10 Kim Gräsman <kim...@gm...> > >> >> I created a branch succinctly called 'uri', on >> https://cpp-netlib.svn.sourceforge.net/svnroot/cpp-netlib/branches/uri >> >> I've committed the first fumbling parts there, in >> /boost/network/uri.hpp and /libs/network/test/uri_test.hpp. >> >> At least it's a start, not sure where to go from there... >> > > Thanks. I'll take a look when I have time over the weekend. > I've taken a look, and the tests seem OK. It didn't compile on GCC because you'd left all the typenames in, but I did a bit of refactoring to fix this. I made it a template (basic_url) and provided a default typedef. This is similar to the way we're using basic_message, so it's more consistent. I think for basic_message and basic_url, it would eventually be necessary to refactor the traits because they will have a lot in common. I've added a single unit test case which will test the syntax we discussed. The next stage will be to develop the directives to make this work. HTH, Glyn |
|
From: K. G. <kim...@gm...> - 2008-10-13 06:46:29
|
Hi Glyn, On Sun, Oct 12, 2008 at 12:52, Glyn Matthews <gly...@gm...> wrote: > > I've taken a look, and the tests seem OK. It didn't compile on GCC because > you'd left all the typenames in, but I did a bit of refactoring to fix > this. I made it a template (basic_url) and provided a default typedef. > This is similar to the way we're using basic_message, so it's more > consistent. I think for basic_message and basic_url, it would eventually be > necessary to refactor the traits because they will have a lot in common. Yes, that was something I was thinking of as well, but I didn't want to duplicate the tags/traits. For a start, though, this looks good, then we can work towards unifying them. I continued trying to get the tags/traits in place, but I never managed to get it to work. I wasn't sure whether to base traits around boost::network::default_tags or uri::tags -- the latter requires that uri is defined, which I think creates a circular dependency between uri.hpp and traits/string.hpp. Thanks for helping, - Kim |
|
From: Dean M. B. <mik...@gm...> - 2008-10-13 02:04:09
|
Hi Kim, On Fri, Oct 10, 2008 at 8:55 PM, Kim Gräsman <kim...@gm...> wrote: > Hi guys, > > On Thu, Oct 9, 2008 at 20:39, Glyn Matthews <gly...@gm...> wrote: >> >> Well it's not really part of the HTTP integration. And it's not much better >> doing all development in a single branch than doing it all in trunk. What I >> think is best is to develop different tasks in different branches, while >> testing against trunk. Ideally, branches should correspond to a >> task/subproject on the sf site too. > > I created a branch succinctly called 'uri', on > https://cpp-netlib.svn.sourceforge.net/svnroot/cpp-netlib/branches/uri > > I've committed the first fumbling parts there, in > /boost/network/uri.hpp and /libs/network/test/uri_test.hpp. > Quick question: where did you branch from? trunk or http_integration? > At least it's a start, not sure where to go from there... > > I didn't parameterize the string type mainly because the default tag > is under network/protocol/http, and the URI goes one level up in the > hierarchy, but I suppose I could introduce a temporary tag to wrap the > string typedef. > That raises a good issue though: should we have a single place to have the tags hierarchy depicted? I'm thinking: namespace network { struct tags { struct http { struct message { struct tag { }; }; // ... }; struct message { struct tag { }; }; // ... }; } That way we can build traits on top of this hierarchy under a different namespace 'traits': namespace network { namespace traits { template <class Tag> string; template <class Tag> buffer; template <class Tag> ostringstream; template <class Tag> char_; // ... } } And specialize them as necessary as well? -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-10-13 07:24:21
|
Hi Dean, On Mon, Oct 13, 2008 at 04:04, Dean Michael Berris <mik...@gm...> wrote: >> >> I created a branch succinctly called 'uri', on >> https://cpp-netlib.svn.sourceforge.net/svnroot/cpp-netlib/branches/uri >> >> I've committed the first fumbling parts there, in >> /boost/network/uri.hpp and /libs/network/test/uri_test.hpp. >> > > Quick question: where did you branch from? trunk or http_integration? >From trunk. >> I didn't parameterize the string type mainly because the default tag >> is under network/protocol/http, and the URI goes one level up in the >> hierarchy, but I suppose I could introduce a temporary tag to wrap the >> string typedef. > > That raises a good issue though: should we have a single place to have > the tags hierarchy depicted? > > I'm thinking: > > namespace network { > struct tags { > struct http { > struct message { > struct tag { }; > }; > // ... > }; > struct message { > struct tag { }; > }; > // ... > }; > } It feels a little strange pushing the tags together, but I can't say why, really... It creates sort of a hotspot, where everybody will have to make edits in order to add new protocols, etc. That's probably not a huge problem. > That way we can build traits on top of this hierarchy under a > different namespace 'traits': > > namespace network { namespace traits { > template <class Tag> string; > template <class Tag> buffer; > template <class Tag> ostringstream; > template <class Tag> char_; > // ... > } } I think it makes sense to keep the traits together, there's bound to be a lot of overlap (especially around strings). > And specialize them as necessary as well? Most of the specializations are useful on a global level, but at the same time it would be nice to keep the specializations close to the code that uses them, rather than listing unrelated but similar specs (string<message_tag>, string<uri_tag>) one after another. I don't have any good suggestions... Is there a way of reusing tag/traits definitions, so that one can create a 'base' definition with the string stuff, and then 'derive' and add more protocol-specific definitions? I'm just thinking out loud... - Kim |
|
From: Glyn M. <gly...@gm...> - 2008-10-13 09:51:24
|
Hi,
2008/10/13 Kim Gräsman <kim...@gm...>
> On Mon, Oct 13, 2008 at 04:04, Dean Michael Berris
> > That raises a good issue though: should we have a single place to have
> > the tags hierarchy depicted?
> >
> > I'm thinking:
> >
> > namespace network {
> > struct tags {
> > struct http {
> > struct message {
> > struct tag { };
> > };
> > // ...
> > };
> > struct message {
> > struct tag { };
> > };
> > // ...
> > };
> > }
>
> It feels a little strange pushing the tags together, but I can't say
> why, really... It creates sort of a hotspot, where everybody will have
> to make edits in order to add new protocols, etc. That's probably not
> a huge problem.
>
It could be a problem. I share your concern about this. But I don't know a
solution to this yet.
>
> > That way we can build traits on top of this hierarchy under a
> > different namespace 'traits':
> >
> > namespace network { namespace traits {
> > template <class Tag> string;
> > template <class Tag> buffer;
> > template <class Tag> ostringstream;
> > template <class Tag> char_;
> > // ...
> > } }
>
> I think it makes sense to keep the traits together, there's bound to
> be a lot of overlap (especially around strings).
right. But I think it might be better named:
namespace network { namespace traits {
template <class Tag> string_type;
template <class Tag> buffer_type;
template <class Tag> ostringstream_type;
template <class Tag> char_type;
}}
On an unrelated note, doesn't using ostringstream always require
basic_string? And char_type is not orthogonal to string_type and char_type.
> > And specialize them as necessary as well?
>
> Most of the specializations are useful on a global level, but at the
> same time it would be nice to keep the specializations close to the
> code that uses them, rather than listing unrelated but similar specs
> (string<message_tag>, string<uri_tag>) one after another.
>
> I don't have any good suggestions... Is there a way of reusing
> tag/traits definitions, so that one can create a 'base' definition
> with the string stuff, and then 'derive' and add more
> protocol-specific definitions? I'm just thinking out loud...
>
I'm not sure what you mean here. Can you elaborate?
Glyn
|
|
From: Dean M. B. <mik...@gm...> - 2008-10-13 10:46:01
|
Hi Glyn,
On Mon, Oct 13, 2008 at 5:47 PM, Glyn Matthews <gly...@gm...> wrote:
>
> 2008/10/13 Kim Gräsman <kim...@gm...>
>>
>> On Mon, Oct 13, 2008 at 04:04, Dean Michael Berris
>> > That raises a good issue though: should we have a single place to have
>> > the tags hierarchy depicted?
>> >
[snip code]
>>
>> It feels a little strange pushing the tags together, but I can't say
>> why, really... It creates sort of a hotspot, where everybody will have
>> to make edits in order to add new protocols, etc. That's probably not
>> a huge problem.
>
> It could be a problem. I share your concern about this. But I don't know a
> solution to this yet.
>
Yeah, I thought about it a little more, and instead of using a 'struct
tags' I think it should remain a namespace. So it'd look like:
namespace network { namespace tags {
struct default_ { };
} }
That way we can add more tags to this central namespace as protocols
get implemented along the way.
>>
>> > That way we can build traits on top of this hierarchy under a
>> > different namespace 'traits':
>> >
>> > namespace network { namespace traits {
>> > template <class Tag> string;
>> > template <class Tag> buffer;
>> > template <class Tag> ostringstream;
>> > template <class Tag> char_;
>> > // ...
>> > } }
>>
>> I think it makes sense to keep the traits together, there's bound to
>> be a lot of overlap (especially around strings).
>
> right. But I think it might be better named:
> namespace network { namespace traits {
> template <class Tag> string_type;
> template <class Tag> buffer_type;
> template <class Tag> ostringstream_type;
> template <class Tag> char_type;
> }}
>
The _type will then be redundant for using traits:
template <> struct string_type<network::tags::default_> {
typedef std::string type;
};
//...
string_type<>::type instance; // ugly? redundant _type and ::type?
> On an unrelated note, doesn't using ostringstream always require
> basic_string? And char_type is not orthogonal to string_type and char_type.
>
template <> string<network::tags::default_> {
typedef std::string type;
};
template <> struct string<network::tags::wide_default_> {
typedef std::wstring type;
};
template <> struct ostringstream<network::tags::default_> {
typedef std::ostringstream type;
};
template <> struct ostringstream<network::tags::default_> {
typedef std::wstringstream type;
};
:-D
--
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
|
|
From: K. G. <kim...@gm...> - 2008-10-13 12:11:51
|
Hi Dean,
On Mon, Oct 13, 2008 at 12:45, Dean Michael Berris
<mik...@gm...> wrote:
>
>> On an unrelated note, doesn't using ostringstream always require
>> basic_string? And char_type is not orthogonal to string_type and char_type.
>>
>
> template <> string<network::tags::default_> {
> typedef std::string type;
> };
>
> template <> struct string<network::tags::wide_default_> {
> typedef std::wstring type;
> };
>
> [...]
I wonder if what Glyn is looking for is something like:
template <> char_based_traits<network::tags::default_> {
typedef std::string string_type;
typedef std::ostringstream ostringstream_type;
typedef char char_type;
};
so that related traits are defined together, and orthogonal traits
separately. Just guessing, though. But it doesn't make intuitive sense
to me to specialize them separated from each other, when they're all
based on the definition of char.
- Kim
|
|
From: K. G. <kim...@gm...> - 2008-10-13 12:26:57
|
HI Glyn, On Mon, Oct 13, 2008 at 11:47, Glyn Matthews <gly...@gm...> wrote: > >> Most of the specializations are useful on a global level, but at the >> same time it would be nice to keep the specializations close to the >> code that uses them, rather than listing unrelated but similar specs >> (string<message_tag>, string<uri_tag>) one after another. >> >> I don't have any good suggestions... Is there a way of reusing >> tag/traits definitions, so that one can create a 'base' definition >> with the string stuff, and then 'derive' and add more >> protocol-specific definitions? I'm just thinking out loud... > > I'm not sure what you mean here. Can you elaborate? Sure, I'll try. If we look at this specific example, where we've added basic_uri, it doesn't share tag with basic_message (default_tags vs. tags::default_). So with every template that needs a new tag, but shares traits with existing classes/templates (typically string, ostringstream, char_), we have to duplicate these definitions. That's why I was wondering if there's a mechanism to reuse the traits between different tags. Does that even make sense? :) - Kim |
|
From: Glyn M. <gly...@gm...> - 2008-10-13 12:38:38
|
Hi Kim, 2008/10/13 Kim Gräsman <kim...@gm...> > HI Glyn, > > That's why I was wondering if there's a mechanism to reuse the traits > between different tags. > > Does that even make sense? :) > That's what I thought in the first place. I always intended default_tags and tags::default_ to be the same thing in the end and that's what we should try and achieve. G |
|
From: Dean M. B. <mik...@gm...> - 2008-10-13 12:31:56
|
On Mon, Oct 13, 2008 at 8:05 PM, Kim Gräsman <kim...@gm...> wrote:
>
> I wonder if what Glyn is looking for is something like:
>
> template <> char_based_traits<network::tags::default_> {
> typedef std::string string_type;
> typedef std::ostringstream ostringstream_type;
> typedef char char_type;
> };
>
> so that related traits are defined together, and orthogonal traits
> separately. Just guessing, though. But it doesn't make intuitive sense
> to me to specialize them separated from each other, when they're all
> based on the definition of char.
>
This is the same problem the standard iterator traits introduce -- a
blob -- which is bad design, and very unwieldy.
I think I've discussed this before as to why I don't like trait blobs
and why I prefer individual trait types. It has something to do with
extensibility and for enforcing good design.
At any rate, it _should_ remain as individual types instead of blobs
precisely because you only need to specify the trait supported --
sometimes it doesn't make sense to support for instance a
'transfer_buffer' trait type for other traits since it only applies to
protocol traits which involve customization of the
transfer_buffer<...>::type based on the tag.
Some traits don't need to be specialized for certain tags, and
mis-using these traits with unsupported tags should yield a clear
compile-time error which says that a specialization for a certain
trait type cannot be found.
--
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
|
|
From: Glyn M. <gly...@gm...> - 2008-10-13 12:43:19
|
Hi Dean,
2008/10/13 Dean Michael Berris <mik...@gm...>
> On Mon, Oct 13, 2008 at 8:05 PM, Kim Gräsman <kim...@gm...>
> wrote:
> >
> > I wonder if what Glyn is looking for is something like:
> >
> > template <> char_based_traits<network::tags::default_> {
> > typedef std::string string_type;
> > typedef std::ostringstream ostringstream_type;
> > typedef char char_type;
> > };
> >
> > so that related traits are defined together, and orthogonal traits
> > separately. Just guessing, though. But it doesn't make intuitive sense
> > to me to specialize them separated from each other, when they're all
> > based on the definition of char.
> >
>
> This is the same problem the standard iterator traits introduce -- a
> blob -- which is bad design, and very unwieldy.
>
I understand the problem with blobs, but my question related to standards
remains: would it be more advantageous to use this more flexible design than
to wander too far from the standard mechanism? Especially considering that
string, char_ and ostringstream are tightly coupled.
G
|
|
From: Dean M. B. <mik...@gm...> - 2008-10-13 12:39:24
|
On Mon, Oct 13, 2008 at 7:58 PM, Kim Gräsman <kim...@gm...> wrote: > HI Glyn, > > On Mon, Oct 13, 2008 at 11:47, Glyn Matthews <gly...@gm...> wrote: >> >>> Most of the specializations are useful on a global level, but at the >>> same time it would be nice to keep the specializations close to the >>> code that uses them, rather than listing unrelated but similar specs >>> (string<message_tag>, string<uri_tag>) one after another. >>> >>> I don't have any good suggestions... Is there a way of reusing >>> tag/traits definitions, so that one can create a 'base' definition >>> with the string stuff, and then 'derive' and add more >>> protocol-specific definitions? I'm just thinking out loud... >> >> I'm not sure what you mean here. Can you elaborate? > > Sure, I'll try. > > If we look at this specific example, where we've added basic_uri, it > doesn't share tag with basic_message (default_tags vs. > tags::default_). > Why not use tags::default_ like basic_message? > So with every template that needs a new tag, but shares traits with > existing classes/templates (typically string, ostringstream, char_), > we have to duplicate these definitions. > Do you really need a new tag? > That's why I was wondering if there's a mechanism to reuse the traits > between different tags. > I don't think there's a need for a different tag if you intend to work with the default tag, which is already defined in the library. Unless you want another point of customization, in which case it's better to just re-use the existing default_ tag. The reason we have a http::message_tag is because there are traits supported by http::message_tag that don't support the default_ tag. It's also a point of customization intended for extension -- so if you want a different storage mechanism for HTTP Messages (like unordered multi-maps for headers, etc.) then you create your own tag and specialize the traits you want to support explicitly. I don't see a need for a basic_uri template to define it's own tag different from the default_ tag especially if you just intend to re-use the same traits used for the message traits. I'd even think we should promote the traits for the message class to a higher traits namespace, to be (re)used throughout the project. ;-) > Does that even make sense? :) I think I'm still missing details as to why you need a separate tag apart from the default_ tag that's already available. -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
×
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