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

Mark Michelson mmichelson at digium.com
Thu Dec 16 23:56:11 UTC 2010


> 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.
>
>    
Well, I tried to create a non-member operator char [] as well as a 
non-member operator const char *. GCC doesn't much care for either.

The operator char [] version:
operator char [](std::string str)
{
return str.c_str();
}

/home/putnopvut/asteriskscf/integration/gitall/ice-util-cpp/StateReplicator/src/MemcachedStateReplicatorStorage.h:91: 
error: function definition does not declare parameters
make[2]: *** 
[ice-util-cpp/StateReplicator/src/CMakeFiles/StateReplicator.dir/MemcachedStateReplicatorStorage.cpp.o] 
Error 1


The operator const char * version:
operator const char *(std::string str)
{
return str.c_str();
}

/home/putnopvut/asteriskscf/integration/gitall/ice-util-cpp/StateReplicator/src/MemcachedStateReplicatorStorage.h:91: 
error: ‘AsteriskSCF::StateReplication::operator const 
char*(std::string)’ must be a nonstatic member function

So making the conversion a non-member function is expressly forbidden in 
the second case. In the first case, the compiler seems a bit...confused. 
It's certainly possible I messed up the syntax though.



More information about the asterisk-scf-dev mailing list