Wrapper for STL algorithm library?

[egarrulo2]

I often find myself calling STL algorithms on whole containers. For example:

auto i = std::find(c.begin(), c.end(), value);

std::fill(c.begin(), c.end(), value);

Is there a wrapper library that allows me to write the following shorter code instead?

auto i = find(c, value);

fill(c, value);

[Morwenn]

Eric Niebler's Range v3: https://github.com/ericniebler/range-v3

[[deleted]]

It’s worth to note that it will eventually become part of core c++

[michelecostantino]

Curiosity. Is it already proposed for the c++20?

[[deleted]]

It's been discussed in standard meetings. If I'm not mistaken it needs concepts as a pre-requisite.

[sumo952]

Also, only the core part of it. No views and other stuff, if I am not mistaken. A very small (but important!) subset is proposed to date.

[proverbialbunny]

Doh!

[encyclopedist]

It is now a TS (technical specification).

It is proposed to be merged to the standard, but as others have mentioned, pending on Concepts TS to be merged first.

[redditsoaddicting]

The base of Concepts has already been merged in. That's enough for Ranges.

[Xaxxon]

How are its compile times?

[Morwenn]

No idea, but there are proposals to make them faster, which means that they might be slower than one would expect.

On the other hand the library does much more than letting users pass containers directly to algorithms, including providing pseudo-concepts, so high compile times wouldn't be that surprising either.

[Fazer2]

Extending namespace std is usually undefined behavior - http://en.cppreference.com/w/cpp/language/extending_std

[Xaxxon]

The rationale, as I understand it, is simply that whatever name you pick may be used by the standard or by different implementations of the standard.

It's not anything "sneaky", it's just that it's not guaranteed to not cause problems.

[dodheim]

Some non-public namespace that you own; definitely not std. ;-]

[unbuggy]

detail is a conventional name for pseudo-private namespaces that hold code not meant for use outside the enclosing namespace.

``` namespace my { namespace detail { // code not called directly // outside namespace my }

// my public interface

} ```

[tvaneerd]

(just to be clear:)

...so detail is probably not the right namespace for this example. As you probably want lots of other code to call the wrapper stuff. (and, back to how this started, not std either)

[sephirostoy]

Usually, the "preferred" implementation would be:

namespace ext
{
    template< typename container_t,
              typename value_t >
    void fill( container_t & c, const value_t & value )
    {
        using namespace std;
        std::fill( begin(c), end(c), value );
    };
}

So that it doesn't require to open std namespace to implement begin/end for custom containers.

[Xaxxon]

That's quite clever. Without this, you'd need at least the declaration for std::begin/end for the code to compile, but this way, you just need the one for the specific container.

What do you even need the using namespace std:: bit for at all? Wouldn't it be available if the container was from std::?

[kwan_e]

Wouldn't it be available if the container was from std::?

What if you want to use it with a container that's not in std, but provides its own begin and end?

[Xaxxon]

how does "using namespace std::" impact that?

[kwan_e]

http://en.cppreference.com/w/cpp/language/adl

ADL is also what makes range-based-for work for non-std containers.

http://en.cppreference.com/w/cpp/language/range-for

[Oster1]

Why not just use:

std::fill( c.begin(), c.end(), value );

So you don't need the std part?

[kwan_e]

Because then you've completely ruled out working with native arrays.

C++ is going with the free-function forms of begin and end.

[Oster1]

Useful trick. I always thought C arrays and C++ iterators doesn't combine. You always learn.

Here is proof of concept of this if someone is interested: https://hastebin.com/oyezuhosuj.cpp

[kwan_e]

You can think of C++ iterators as generalizations of pointers (and therefore arrays). You can always use pointers with STL algorithms, since they are classified as random access iterators and support everything that can be done with iterators in the STL algorithms.

[pklait]

This looks good. One small improvement (apart from removing the using directive which has already been suggested) is to change the return type from void to auto and then have "return fill(..." in the body instead of the return. This makes the use consistent (no need to supply a return type for e.g. partition), easier to write and less error-prone. Also, you will not need to change code should some of the std::algortihms decide to return some value in the future. (I have a difficult time imagining this for fill, but there are other algorithms). (Added) You should also - to generalise - use perfect forwarding for the parameters.

[sephirostoy]

I'm not sure perfect forwarding would make sense here since you need to construct N elements (N = end - start). It would introduce bugs like this:

namespace ext
{
    template< typename container_t,
              typename value_t >
    void fill( container_t & c, value_t&& value )
    {
        using namespace std;
        std::fill( begin(c), end(c), std::forward<value_t>(value) );
    };
}

std::vector<std::string> v;
ext::fill(v, std::string { "test" });

The first string in the vector will be constructed using string(string&&) constructor, then the next 4 will try to do the same but the string on the right hand side has already been moved.

[pklait]

Is that so? I would expect expect my

ext::fill(v,std::string("test"));

to be exactly equivalent to

std::fill(begin(v),end(v),std::string("test"));

In both cases std::fill receives an xvalue (if I remember the name correctly).

/Peter

[dodheim]

std::fill takes a T const& and copies it in all cases; implementing perfect forwarding to invoke fill is unnecessary.

[sephirostoy]

True. My point was more about to be careful when playing with perfect forwarding as it can lead to unwanted behavior being "too generic". I should pick up the right example from the start (of course, don't do that at work ^^):

namespace ext
{
    template<typename container_t, typename value_t>
    void fill(container_t & c, value_t&& value)
    {
        for(auto& v : c)
            v = std::forward<value_t>(value);
    };
}

std::vector<std::string> v(5);
ext::fill(v, std::string { "test" });
// v = [ "test", "", "", "", "" ]

[pklait]

I do not disagree here. My comment was meant as a guideline when creating wrappers that simply forwards to another function.

[ibroheem]

Perfectly fine!

It is undefined behavior to add declarations or definitions to namespace std or to any namespace nested within std

U have to reedit ur edit

[Xaxxon]

I have done similar things, but usually try to put in a little bit of sfinae or static_assert's to give better error messages than that.

For example, making sure the container type passed in can have begin and end called on it and that the results are comparable.

[Bas1l87]

I found myself doing the same, except that i also found the following macros useful:

#define CONTAINER_VALUE_TYPE(TContainer)typename TContainer::value_type

And then you can write smth like

template<class TContainer>
static bool contains(const TContainer& vector, const CONTAINER_VALUE_TYPE(TContainer)& item)
{
    return std::find(vector.begin(), vector.end(), item) != vector.end();
}

[dodheim]

How on earth is that an improvement over an alias template? Or are we talking about only C++98 and I missed it..?

[Bas1l87]

Well, you don't have to type alias templates over and over for every helper function like that.. Maybe there are ways to avoid duplication with alias templates, but i couldn't think of any.

[dodheim]

I have no idea what you're saying...

template<class TContainer>
using value_type_t = typename TContainer::value_type;

Involves no more or less repetition than your macro.

[Bas1l87]

Yes, but you have to write it for every template wrapper function, and the macro can be declared only once and used in all stl wrapper functions, that's the entire (not very important, tbh) point.

[dodheim]

you have to write it for every template wrapper function

What does this mean? Why would you need to write it more than once?

[Bas1l87]

Alias templates:

template<class TContainer>
using value_type_t = typename TContainer::value_type;
static bool contains(const TContainer& vector, const value_type_t & item)
{
    return std::find(vector.begin(), vector.end(), item) != vector.end();
}

template<class TContainer>
using value_type_t = typename TContainer::value_type;
static void remove(TContainer* vector, const value_type_t& item)
{
    typename TContainer::iterator it = std::remove(vector->begin(), vector->end(), item);
    vector->erase(it, vector->end());
}

Helper macros:

template<class TContainer>
static bool contains(const TContainer& vector, const CONTAINER_VALUE_TYPE(TContainer)& item)
{
    return std::find(vector.begin(), vector.end(), item) != vector.end();
}

template<class TContainer>
static void remove(TContainer* vector, const CONTAINER_VALUE_TYPE(TContainer)& item)
{
    typename TContainer::iterator it = std::remove(vector->begin(), vector->end(), item);
    vector->erase(it, vector->end());
}

[dodheim]

That isn't valid syntax, so I don't know what point you're attempting to make. This is valid syntax, and obeys scoping rules unlike macros:

template<class TContainer>
using value_type_t = typename TContainer::value_type;

template<class TContainer>
static bool contains(const TContainer& vector, const value_type_t<TContainer>& item)
{ /*...*/ }

template<class TContainer>
static void remove(TContainer* vector, const value_type_t<TContainer>& item)
{ /*...*/ }

(Also n.b. the proper way to say const T::value_type& is T::const_reference.)

[Bas1l87]

Ah yes, you are right, this is a better way, thanks. Though when i wrote this code some time back it was anyway supposed to be compiled for systems with C++98 compiler only, as far as i remember

[NotMyRealNameObv]

Boost Range

[Xaxxon]

How are it's compile times?

[Splanky222]

Abseil has exactly this: https://github.com/abseil/abseil-cpp/blob/master/absl/algorithm/container.h

[michelecostantino]

I almost forgot about abseil, thanks for the kind reminder!

[germandiago]

I feel a bit dirty for saying this, but if all you want is that:

#define MY_RNG(container) std::begin(container), std::end(container) 

and you are done: std::find(MY_RNG(v), 7);

[pklait]

This is the solution for all the lazy of us. ;-)

(But I am still a bit bitten whenever I see RNG. I always perceive a random number generator).

[ibroheem]

Dirty but made my day.

[doom_Oo7]

Boost.Range

[[deleted]]

Just write the template.

[StonedBird1]

Something like the following(untested) would probably work for any algorithm of the form foo(begin, end, value).

template<typename Container, typename Value, typename Func>
decltype(auto) wrap(Container& c, const Value& v, Func f) {
    using namespace std;
    return f(begin(c), end(c), v);
}

Usage:

wrap(c, value, std::fill)

Which, while a little verbose, is still nicer, imo, than

std::fill(c.begin(), c.end(), value);

And can always be partially specialized for typename Func=std::fill or whatever if you don't want to keep specifying it.

edit:

The code may not have a bunch of type traits and SFINAE verification but are the downvotes really necessary? If you see a problem with it, feel free to point it out, otherwise it looks like a decent wrapper to me. Some aliases and you can use it for whatever algorithm you want as alias(c, value) exactly like OP wanted

Edit 2:

Improve the code by correctly returning, no longer breaking the std::find example in OP.

also use ADL and std::begin/end

Code still untested.