1

Ranges-v3 proposal allows us to write code like

auto f () { return range () | view::transform ([] (auto x) { return x *2; }); }

This is very cool. But I guess that it's impossible to use such code in a reusable way (i.e. in headers), because of odr. Even worse, in every cpp file the result type of such function will be different leading to linker errors. Is the only way to use ranges in headers to write old-fashioned functor classes or I'm missing something?

Alex Telishev
  • 2,264
  • 13
  • 15
  • you miss that lamda is anonymous feature and conceptually it should be used to simplify the implementation of the code, rather than declaring class – rikimaru2013 Jan 11 '16 at 10:03
  • @rikimaru2013 And what is your solution - to write a whole class with `operator()` and captured variables for such simple function? That throws us back to 200x. Of course I can do it for some cases, but to do it every time I want to simply create a range of submembers of some type is tedious. – Alex Telishev Jan 11 '16 at 10:16
  • If declared `inline`, this shouldn’t violate ODR. Or am I overlooking something? – Konrad Rudolph Jan 11 '16 at 10:39
  • There is only one definition of the lambda in `f`. – Jarod42 Jan 11 '16 at 10:46
  • Put the function definition in an unnamed namespace? – cpplearner Jan 11 '16 at 11:24
  • @KonradRudolph Every time you write even the same lambda it has different type (including same .h file in different cpp files). And so these functions have different return type that I guess is odr violation (it's like inline int f (); and inline double f (); in different files). – Alex Telishev Jan 11 '16 at 11:31
  • @cpplearner Interesting idea, but you can't do it for member functions. – Alex Telishev Jan 11 '16 at 11:33
  • @Alex Just because the lambda *inside* the function is different doesn’t make the return type different if the lambda type is erased (don’t know what ranges-v3 does). But *regardless of that*, `inline` simply mandates that the definitions need to be identical. I don’t know whether the standard specifies whether this identity is on the textual level or on the level of internal compiler-generated types. The latter is of course conceivable but would be a bad decision as your question illustrates. I think it’s in fact the former: that is, compilers must simply ensure that this works. – Konrad Rudolph Jan 11 '16 at 14:26

0 Answers0