Cannot use C++ range-v3 library

[shyun3]

Describe the bug The C++ reference clearly lists range-v3 as available but including its headers conflicts with the test suite.

To Reproduce Without changing anything else, try including a range-v3 header at the top of the file and try compiling. Example:

#include <range/v3/all.hpp>

Expected behavior If the code compiled before, it should continue compiling. Instead error messages such as the following are emitted:

In file included from main.cpp:6:
In file included from ./solution.cpp:4:
In file included from /usr/local/include/range/v3/all.hpp:17:
In file included from /usr/local/include/range/v3/action.hpp:32:
In file included from /usr/local/include/range/v3/action/split.hpp:30:
/usr/local/include/range/v3/view/split.hpp:100:24: error: expected member name or ';' after declaration specifiers
            It curr_ = It();
                       ^~~~
/usr/local/include/igloo/core/alternativeregistrationaliases.h:22:22: note: expanded from macro 'It'
#define It(specName) \
                     ^
/usr/local/include/igloo/core/registration.h:50:3: note: expanded from macro '\
IGLOO_SPEC_REGISTRATION'
  IGLOO_PRIVATE_SPEC_REGISTRATION(specName, false, false)
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/include/igloo/core/registration.h:47:25: note: expanded from macro 'IGLOO_PRIVATE_SPEC_REGISTRATION'
  virtual void specName()
  ~~~~~~~~~~~~          ^
In file included from main.cpp:6:
In file included from ./solution.cpp:4:
In file included from /usr/local/include/range/v3/all.hpp:17:
In file included from /usr/local/include/range/v3/action.hpp:32:
In file included from /usr/local/include/range/v3/action/split.hpp:30:
/usr/local/include/range/v3/view/split.hpp:100:24: error: expected expression
/usr/local/include/igloo/core/alternativeregistrationaliases.h:22:22: note: expanded from macro 'It'
#define It(specName) \
                     ^
/usr/local/include/igloo/core/registration.h:50:3: note: expanded from macro '\
IGLOO_SPEC_REGISTRATION'
  IGLOO_PRIVATE_SPEC_REGISTRATION(specName, false, false)
  ^
/usr/local/include/igloo/core/registration.h:40:3: note: expanded from macro 'IGLOO_PRIVATE_SPEC_REGISTRATION'
  struct SpecRegistrar_##specName \
  ^
2 errors generated.

[kazk]

:man_facepalming:

I thought users confirmed range-v3 was usable. I don't think I made any changes since then.

Something similar happened when trying to make fmt work (https://github.com/codewars/runner/issues/87#issuecomment-719774878). I forgot the details.

[XRFXLP]

That's not the right way to use it on codewars. Include it as following:

#include <range/v3/view/all.hpp>

Example:

#include <iostream>
#include <range/v3/view/take.hpp>
#include <range/v3/view/all.hpp>

int func(){
  std::vector<int> vec = {4, 5, 6, 10};
  auto stuff = ranges::views::all(vec)  | ranges::views::take(2);

  for(auto x: stuff)
    std::cout << x << std::endl;

  return 0;
}

Check this kumite for the same.

[Urfoex]

Yeah: https://github.com/codewars/runner/issues/87#issuecomment-719774878

Issue of adding range-v3: https://github.com/codewars/runner/issues/42

Like @XRFXLP says, try to just include what you need. There was one header making problems because of igloos macro…

But also I think, it was kind of working in the end 🤔 At least the tests would suggest it. Kind of 🤔

[ForceKorn]

Hi, I recently started using ranges-v3 on Codwars and ran into this problem too.

If you have access to the source files of range-v3 library, you can change the template parameter and all its references in the "struct here" structure from "template \<typename It>" to "template \<typename ItType>" to preserve the semantics but break the ambiguous syntax of " It();" instruction. So for example your "range/v3/view/split.hpp" file would be like this template<typename ItType> struct here { ItType curr_ = ItType(); ItType& current_(ignore_t) noexcept ... }

instead of template<typename It> struct here { It curr_ = It(); It& current_(ignore_t) noexcept ... }

I assume that "range/v3/view/split.hpp" header file is root for other "split.hpp" files, like "range/v3/action/split.hpp", so it can fix other dependant files.

[triplejam]

Still not fixed. split() is useful for strings

[omaf2021]

I still hope someone takes a jab at finally fixing this issue. Cluttering the code with an excess of headers is suboptimal and also means you have to keep going back and fixing the headers as you code. Also, the range-v3 docs only present a one-way direction of information when it comes to header files: if you know the header file, you can easily see all the utilities declared in it; however, if you have a particular utility in mind, you can't see the header in which it is declared. This sometimes necessitates having to dig through all headers to figure out where some utilities are declared - for example, the fact that ranges::views::values resides in <range/v3/views/map.hpp> is not intuitive because it doesn't follow the general naming heuristic.

Also, as others have mentioned, splitting a container based on a delim is genuinely something you can't do cleanly (let alone in less than a single line) in plain C++. The fact that ranges::views::split in particular in unusable is such a shame; it is one of the most compelling use-cases for range-v3 to begin with.

[ForceKorn]

Hi again. We actually can use split algorithm from range-v3 library, at least two my solutions were accepted. In order to use split, you need to wrap your code with preprocessor code that disbales IGLOO for current block of code. Something like:

#undef It // Disabling IGLOO macros

#include <header1>
#include <header2>
...

task() {
    Your code here ...
}

#define It(specName) IGLOO_SPEC_REGISTRATION(specName) // Restoring IGLOO macros

I'm not sure how stable this solution is, but as example I`ve solve "Convert a string to an array" and "Reversed Words" 8 kyu katas. You can navigate to each 'Solutions' tab and sort by 'Newest' to see how it can be done.

[omaf2021]

Hello, I am aware of this workaround and also mentioned it in my previous issue. Thank you for laying it out explicitly for people viewing the comments. However, this feels extremely hacky and I would rather not include split.hpp at all than tamper with the macros like this.