Re: [boost] no matching function for call to boost::algorithm::split
Olaf van der Spek wrote:
I'm not sure. The code snippet you sent seems fine, so maybe the problem is elsewhere. I would check includes and namespaces.
I've now got: #include <boost/algorithm/string.hpp> #include <string> #include <vector>
std::string f() { return ""; }
int main() { std::vector<std::string> v; boost::split(v, f(), boost::is_any_of(",")); return 0; }
split_test.cpp: In function 'int main()': split_test.cpp:13: error: invalid initialization of non-const reference of type 'std::string&' from a temporary of type 'std::string'
This is because f() is returning a std::string and this is being passed to the RangeT & argument in the split function. Due to C++ rules, performing the T -> T & conversion is invalid. Try defining f() as: const std::string f() { return ""; } HTH, - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
On 3/14/06, Reece Dunn <msclrhd@hotmail.com> wrote:
Olaf van der Spek wrote:
I'm not sure. The code snippet you sent seems fine, so maybe the problem is elsewhere. I would check includes and namespaces.
I've now got: #include <boost/algorithm/string.hpp> #include <string> #include <vector>
std::string f() { return ""; }
int main() { std::vector<std::string> v; boost::split(v, f(), boost::is_any_of(",")); return 0; }
split_test.cpp: In function 'int main()': split_test.cpp:13: error: invalid initialization of non-const reference of type 'std::string&' from a temporary of type 'std::string'
This is because f() is returning a std::string and this is being passed to the RangeT & argument in the split function. Due to C++ rules, performing the T -> T & conversion is invalid. Try defining f() as:
const std::string f() { return ""; }
Thanks, that did the trick. I understand T -> T& isn't valid (although I don't like that), but why doesn't it automatically do T -> const T&?
On 3/15/06, Olaf van der Spek <olafvdspek@gmail.com> wrote:
This is because f() is returning a std::string and this is being passed to the RangeT & argument in the split function. Due to C++ rules, performing the T -> T & conversion is invalid. Try defining f() as:
const std::string f() { return ""; }
Thanks, that did the trick. I understand T -> T& isn't valid (although I don't like that), but why doesn't it automatically do T -> const T&?
Pavol?
On Mon, Mar 27, 2006 at 02:53:41PM +0200, Olaf van der Spek wrote:
On 3/15/06, Olaf van der Spek <olafvdspek@gmail.com> wrote:
This is because f() is returning a std::string and this is being passed to the RangeT & argument in the split function. Due to C++ rules, performing the T -> T & conversion is invalid. Try defining f() as:
const std::string f() { return ""; }
Thanks, that did the trick. I understand T -> T& isn't valid (although I don't like that), but why doesn't it automatically do T -> const T&?
Sorry, somehow I thought, that it is solved. The main reason why it works this way is the template instantiation process. const T& is more specific type then T& and so if T& matches the template signature, it is used. As I mentioned in another post, this behaviour is implemented in the library intentionaly, since it disallows to pass temporary objects as the arguments on the certain places. Specificaly the search algorithms might give unexpected results, since they return a reference into the input. Same is true for the split algorithm if you use vector<iterator_range> to hold results. This solution is suggested in the docs as a way to optimize spliting operation. There were also other reason, but they were mostly of technical character so I won't mention them here. Best regards, Pavol.
On 3/27/06, Pavol Droba <droba@topmail.sk> wrote:
Thanks, that did the trick. I understand T -> T& isn't valid (although I don't like that), but why doesn't it automatically do T -> const T&?
Sorry, somehow I thought, that it is solved. The main reason why it works this way is the template instantiation process. const T& is more specific type then T& and so if T& matches the template signature, it is used.
But in this case it can't be used.
As I mentioned in another post, this behaviour is implemented in the library intentionaly, since it disallows to pass temporary objects as the arguments on the certain places.
I understand, but isn't it possible to have both advantages? For example, by adding a function that takes const T&? Or should all functions (in all applications and libraries) return const string instead of just string?
On Mon, Mar 27, 2006 at 05:47:35PM +0200, Olaf van der Spek wrote:
On 3/27/06, Pavol Droba <droba@topmail.sk> wrote:
Thanks, that did the trick. I understand T -> T& isn't valid (although I don't like that), but why doesn't it automatically do T -> const T&?
Sorry, somehow I thought, that it is solved. The main reason why it works this way is the template instantiation process. const T& is more specific type then T& and so if T& matches the template signature, it is used.
But in this case it can't be used.
As I mentioned in another post, this behaviour is implemented in the library intentionaly, since it disallows to pass temporary objects as the arguments on the certain places.
I understand, but isn't it possible to have both advantages? For example, by adding a function that takes const T&?
This is an option, but there are several problem. First there are some older compilers, that do not support partial template ordering. Also it would multiply number of functions 2 times. I'm not sure if it is worth it.
Or should all functions (in all applications and libraries) return const string instead of just string?
Well no, you should make a copy and store it into a variable. There is copying there anyway and if you don't mind returning std::string, you probably don't have problems with performance issues. Regards, Pavol.
On 3/27/06, Pavol Droba <droba@topmail.sk> wrote:
Or should all functions (in all applications and libraries) return const string instead of just string?
Well no, you should make a copy and store it into a variable. There is copying there anyway and if you don't mind returning std::string, you probably don't have problems with performance issues.
But that doesn't look nice and introduces additional variables.
On Tue, Mar 28, 2006 at 12:55:19AM +0200, Olaf van der Spek wrote:
On 3/27/06, Pavol Droba <droba@topmail.sk> wrote:
Or should all functions (in all applications and libraries) return const string instead of just string?
Well no, you should make a copy and store it into a variable. There is copying there anyway and if you don't mind returning std::string, you probably don't have problems with performance issues.
But that doesn't look nice and introduces additional variables.
If I find some time, I will have a look. Maybe I'll come up with something. Regards, Pavol
On 3/29/06, Pavol Droba <droba@topmail.sk> wrote:
On Tue, Mar 28, 2006 at 12:55:19AM +0200, Olaf van der Spek wrote:
On 3/27/06, Pavol Droba <droba@topmail.sk> wrote:
Or should all functions (in all applications and libraries) return const string instead of just string?
Well no, you should make a copy and store it into a variable. There is copying there anyway and if you don't mind returning std::string, you probably don't have problems with performance issues.
But that doesn't look nice and introduces additional variables.
If I find some time, I will have a look. Maybe I'll come up with something.
Thanks. I'm actually wondering, is this really an issue of the current library? If so, why does VC8 not give an error/warning? Could this be a gcc issue instead?
On Wed, Mar 29, 2006 at 08:32:40PM +0200, Olaf van der Spek wrote:
On 3/29/06, Pavol Droba <droba@topmail.sk> wrote:
On Tue, Mar 28, 2006 at 12:55:19AM +0200, Olaf van der Spek wrote:
On 3/27/06, Pavol Droba <droba@topmail.sk> wrote:
Or should all functions (in all applications and libraries) return const string instead of just string?
Well no, you should make a copy and store it into a variable. There is copying there anyway and if you don't mind returning std::string, you probably don't have problems with performance issues.
But that doesn't look nice and introduces additional variables.
If I find some time, I will have a look. Maybe I'll come up with something.
Thanks. I'm actually wondering, is this really an issue of the current library? If so, why does VC8 not give an error/warning?
The reason is quite simple: because it is crapy compiler. If it would work according to standard, it should report an error. Still it might be possible, that there is some compatibility mode turned on by default, that disables this error.
Could this be a gcc issue instead?
No it is not a gcc issue. It was done intentionaly the way it is. Regards, Pavol.
participants (3)
-
Olaf van der Spek -
Pavol Droba -
Reece Dunn