[asterisk-scf-dev] Changes regarding state replicator keys

[Ken Hunt]

----- Original Message -----
> From: "Mark Michelson" <mmichelson at digium.com>
> To: asterisk-scf-dev at lists.digium.com
> Sent: Tuesday, December 14, 2010 7:13:22 AM
> Subject: Re: [asterisk-scf-dev] Changes regarding state replicator keys
> On 12/14/2010 08:28 AM, Kevin P. Fleming wrote:
> > On 12/14/2010 05:53 AM, Brent Eagles wrote:
> >
> >> On Mon, Dec 13, 2010 at 01:39:06PM -0600, David M. Lee wrote:
> >>
> >>> On Dec 13, 2010, at 12:01 PM, Mark Michelson wrote:
> >>>
> >>>
> >>>> 1) Instead of using a templated type for the key, use
> >>>> std::string.
> >>>> std::string has a .c_str() method that will give a const char *
> >>>> to the
> >>>> actual string content, and std::string has a size() method for
> >>>> reporting
> >>>> the size of the string.
> >>>>
> >>> +1. If you have some class you want to use for your identifier,
> >>> you
> >>> just need to make sure that you can convert that class to
> >>> std::string.
> >>>
> >>> Conversions from std::string to the id class are probably an
> >>> anti-pattern, since you're then using the identity column for more
> >>> than just identity. You can easily put such information in the
> >>> value
> >>> that's being stored, so that's not too limiting.
> >>>
> >>
> >> I had to think about this one a little bit because I didn't quite
> >> get
> >> David's point. It did finally dawn on me that we were talking
> >> specifically about replication, not general database type stuff.
> >> *If*
> >> we were building some mechanism for storing arbitrary data, then it
> >> would make sense to have some versatility with respect to the key
> >> type.
> >> However, this is specific to replication so it is not that big of a
> >> deal
> >> to restrict the key type to strings.
> >>
> >> On a related note, does memcached restrict key length?
> >>
> >> <snip>
> >>
> >> I also agree with David on the other two possibilities, so I'm just
> >> going to snip those out.
> >>
> > My preference would be to not restrict the user of the template to
> > only
> > being able to use std::string for keys. I can easily envision
> > applications where the key will be a structure of multiple fields,
> > and
> > forcing the user of the template to have to convert to/from
> > std::string
> > seems unnecessary.
> >
> > My vote would be for the template to just continue to accept a
> > template
> > type parameter (K), and require that that type have a size() member
> > function, an 'operator char[]' conversion function, and a
> > constructor
> > that accepts 'char[], int'.
> >
> I can't see the benefit requiring an 'operator char[]' conversion
> function over requiring that the key type be a std::string. Both
> require
> the same types of conversions to be done, but with std::string, you at
> least have some helpful built-in operators to help build the string
> for
> you. I wouldn't be surprised to find that most implementations of
> operator char[] for a key type would end up using std::string in order
> to build the char sequence.
> 
> The other reason I don't like this idea is that it doesn't allow for
> std::string to be used as a key type any more since std::string does
> not
> have an 'operator char[]' conversion function (though it really seems
> like it should).
> 

You could add the 'operator char[]' conversion as a non-member function, and the compiler will use it if it's in scope of the unit being compiled. But... conversion functions that allow for implicit conversions are sort of evil anyway. However, C++0x has support for explicit conversion functions. Here's an article that describes the newer syntax: 
http://www.devx.com/cplus/10MinuteSolution/39438/1954

That article is talking about member functions, but it should work for non-member functions as well. (At least, I don't see why it wouldn't!) Anyway, more to think about.