Make string_ref understand allocators

[deanberris]

No description provided.

[glynos]

I can't merge these commits as the first one is part of another pull request and requires changes (see #2 )

I see nothing wrong with what you've added re the allocators, but at the moment I can't build it.

[deanberris]

Interesting. I prefer really not having these macros sprinkled in the code. I'm disappointed that Microsoft is taking its time in getting C++11 in the hands of more people. I'm already at odds with the way the URI implementation has these macros all over the place but I understand it is a necessary evil at this time.

Do you prefer a header where the NETWORK_* macros should be defined?

[glynos]

I much prefer not to have these macros all over the place too, and I make a point of limiting them to only those places where they're required (i.e. when I can't get the same code to compile on each platform I test on).

In order to allow the uri project to be standalone, unfortunately I see no option but to duplicate them.

So in:

uri/src/network/uri/config.hpp

and use the macro prefix: NETWORK_URI_

and in the main project, I would propose:

config/src/network/config.hpp

and use the macro prefix NETWORK_

[glynos]

I applied this by cherry-picking the commit with the allocator code. Verified that it compiles and unit tests run:

e3ed456

[glynos]

Dean,

I know I merged this a couple of days ago but on reflection, I have a question.

What are the allocators for? With string_ref there is no allocation, by definition. I double checked Jeffrey Yassin's string_ref proposal and indeed, he makes no reference to allocators in the definition of the template class string_ref.

[deanberris]

Right, so actually I was only supposed to do the template part in the conversion operator -- it should be able to deduce the type of the allocator for the string. I'm not entirely sure whether Jeffrey's paper does the magic that way, but nonetheless the idea was:

template <class Allocator>
explicit operator basic_string<CharT, CharTraits, AllocL> () const {
  return basic_string<CharT, CharTraits, AllocL>(start, end);
}

It might still work without the allocator though, you might want to give it a shot. I forget why I had chosen to add the allocator to the type in the string_ref implementation.