Python list equivalent in C++? - c++

Could you please tell me what is the closest data type in C++ to python list? If there is nothing similar, how would you build it in C++?

If you're looking for standard one-dimensional data structures idiomatic to C++, std::vectors, std::lists, and arrays (or std::arrays) all have features similar to Python lists. Which of those data structure you want to choose depends on your requirements. std::vector is a very reasonable structure to default to if you're just looking to store a collection of items.
These data structures all require that each element is of the same type. Generally in C++ that is what you want. However, if you're specifically looking to store a variety of types in the same structure, there are a few options:
You can store void pointers. You will, however, need some way to figure out the type of each element and cast the pointer to the appropriate type to use each element.
If you have a specific set of types you wish to store, you can declare a union (which you'd generally wrap in a struct along with an enum to indicate the type being stored).

Maybe storing boost::any in a std::vector?
http://www.boost.org/doc/libs/1_54_0/doc/html/boost/any.html
Here is a simple working example. See James comments below too.
#include "../boost_1_54_0/boost/any.hpp"
#include <vector>
#include <string>
#include <iostream>
int main()
{
std::vector<boost::any> myList;
myList.push_back(std::string("Hello"));
myList.push_back(10);
myList.push_back(std::string("World"));
std::string any1 = boost::any_cast<std::string> (myList[0]);
int any2 = boost::any_cast<int> (myList[1]);
std::string any3 = boost::any_cast<std::string> (myList[2]);
std::cout<<any1<<" "<<any2<<" "<<any3<<std::endl;
return 0;
}

Actually no C++ container is equivalent to Python's list, which is partially a result of the very different object models of C++ and Python. In particular, the suggested and upvoted std::list is IMHO not even close to Python's list type, a I'd rather suggest std::vector or maybe std::deque. That said, it isn't clear what exactly it is that you want and how to "build it" strongly depends on what exactly "it" is, i.e. what you expect from the container.
I'd suggest you take a look at the C++ containers std::vector, std::deque and std::list to get an overview. Then look at things like Boost.Any and Boost.Variant that you can combine with them, maybe also one of the smart pointers and Boost.Optional. Finally, check out Boost.Container and Boost.Intrusive. If the unlikely case that none of these provide a suitable approximation, you need to provide a better explanation of what your actual goals are.

There is no real equivalent, and it would be extremely difficult
to provide one. Python and C++ are radically different
languages, and providing one really wouldn't make much sense in
the context of C++. The most important differences are that
everything in Python is dynamically allocated, and is an
"object", and that Python uses duck typing.
FWIW: one very early library (before templates) in C++ did offer
containers of Object*, with derived classes to box int,
double, etc. Actual experience showed very quickly that it
wasn't a good idea. (And I'm curious: does any one else
remember it? And particularly, exactly what it was
called---something with NHS in it, but I can't remember more.)

I am working on a wrapper for std::vector that makes it more like Python's lists named pylistpp. The API is just like Python. Example:
#include <list.hpp>
#include <iostream>
int main()
{
list<int> mylist;
mylist.append(5);
mylist.append(7);
int count = mylist.count(5);
std::cout << count << std::endl;
std::cout << mylist.pop(0) << std::endl;
std::cout << mylist.index(7);
return 0;
}

Related

When is useful to use std::any? [duplicate]

Since C++17 std::any is introduced. One can now write code like this
#include <iostream>
#include <any>
#include <string>
int main () {
const double d = 1.2;
std::any var = d;
const std::string str = "Hello World";
var = str;
}
A double is assigned to the variable var and than a std::string was assigned to it.
Why has std::any been introduced?
I think this is violating the least astonishment rule, because I find it hard to think of a situation, where this can be used to express more clearly, what I like to express.
Can somebody give me a good example, when std::any is beneficial.
https://gcc.godbolt.org/z/-kepOD
When to Use
void* as an extremely unsafe pattern with some limited use cases, std::any adds type-safety, and that’s why it has some real use cases.
Some possibilities:
In Libraries - when a library type has to hold or pass anything without knowing the
set of available types.
Parsing files - if you really cannot specify what are the supported
types.
Message passing.
Bindings with a scripting language.
Implementing an interpreter for a scripting language
User Interface - controls might hold anything
Entities in an editor
(ref)
I would summarize it as classic "use when you cannot avoid it".
I can only think of non-performance-critical implementations of dynamically typed scripting languages to represent variables from the scripting world, but even that with a stretch (Boost.Spirit/example/qi/compiler_tutorial does it without, for both the parser and the runtime).
For everything else from parsers (e.g. Boost.Spirit.X3) to library APIs (e.g. ASIO) there would usually be a faster/better/more-specific alternative, as very few things are really "anything", most are more specific than that.
std::variant and/or std::optional for "almost any value"
std::packaged_task / std::function + lambdas for "callback with arguments", which would be a case of void* in C APIs.
etc.
Specifically, I wouldn't blindly plug it as a replacement for a void*, as it may allocate memory on the heap, which can be deadly for high performance code.
std::any is a vocabulary type. When you need to store, well, some bit of anything, as a value you can use it.
There are a number of "first level" uses of it:
When interacting with scripting languages which themselves have such types, it is a natural fit.
When you have a property tree with highly polymorphic content, and the structure of the tree is decoupled from the producer and consumer of the tree.
When replacing the equivalent of a void* chunk of data being passed through an intermediate layer who really doesn't care what it is carrying.
It can also be used as a building block in other cases. For example, std::function could choose to store its value in the std::any:
template<class R, class...Args>
struct func<R(Args...)> {
mutable std::any state;
R(*f)(std::any& state, Args&&...) = nullptr;
template<class T>
void bind(T&& t) {
state = std::forward<T>(t);
f = [](std::any& state, Args&&...args)->R {
return std::any_cast<T&>(state)(std::forward<Args>(args)...);
};
}
R operator()(Args...args)const {
return f(state, std::forward<Args>(args)...);
}
};
that is a pretty small implementation of (most of) std::function. Basically I've used any to type erase copy/move/destroy.
You can using this elsewhere for similar problems (where you are type-erasing some operation and also want to type erase copy/move/destroy), or generalize it.
It's used in Wt, to provide a non-template interface for tabular data.
There are conversions to string for builtin and Wt types, and you can register additional conversions by specialising Wt::any_traits. This allows anything to be displayed as an entry in a table, the view classes don't have to know anything about the types they are displaying.

C++ Is a std::string a container?

This might be a simple question for some of you. But I was wondering if a std::string is a container. By container I mean the containers like for example std::vector, std::list and std::deque.
Since std::basic_string<> accepts other types than integral characters, but also is being optimized by working with character arrays. It isn't really clear to me in which category it falls.
This will compile:
#include <string>
#include <iostream>
int main() {
std::basic_string<int> int_str;
int_str.push_back(14);
return 0;
}
But by adding this line:
std::cout << int_str << std::endl;
It won't. So by these facts I could conclude that an std::basic_string was not intended to work with other types than characters.
It might be a strange question for you. The reason I need to know this is because I'm working on a framework and I'm still not able to determine in which category a "string" would fall.
Yes, the std::basic_string template fulfills all the requirements of the Container concept. However, I think it has stronger requirements on the contained type. Just trying to dig out exactly what.
(This is not Bjarne's Concepts. Just the bit of The Standard labeled "23.2.1 General container requirements".)
According to standards(2003,2011) std::basic_string is a container only for POD types.
I.e. fundamental types or plain structs/classes without constructors, destructors or virtual functions.
But gnu stdlib allow use non-POD types with std::basic_string. Here is an example of working with basic_string and non-POD types.
And if you what to make your example works you should define operator
std::ostream& operator<<(::std::ostream& out, std::basic_string<int> &dat)
{
out << dat[0];
return out;
}
Or something like that.
Well it is safe to say it is not a container at least not in the normal way you would think of an std container.
Most simple example is that you cant put any thing you want in it.
But it does have some classification of a container like the fact that you can put some of the basic types into it even if they are not chars, and perhaps most amazing thing is that you can get an iterator to it as if it was a normal container.
So is it a containr? I would say yes but! it is not an all genery one.

What are good use-cases for tuples in C++11?

What are good use-cases for using tuples in C++11? For example, I have a function that defines a local struct as follows:
template<typename T, typename CmpF, typename LessF>
void mwquicksort(T *pT, int nitem, const int M, CmpF cmp, LessF less)
{
struct SI
{
int l, r, w;
SI() {}
SI(int _l, int _r, int _w) : l(_l), r(_r), w(_w) {}
} stack[40];
// etc
I was considering to replace the SI struct with an std::tuple<int,int,int>, which is a far shorter declaration with convenient constructors and operators already predefined, but with the following disadvantages:
Tuple elements are hidden in obscure, implementation-defined structs. Even though Visual studio interprets and shows their contents nicely, I still can't put conditional breakpoints that depend on value of tuple elements.
Accessing individual tuple fields (get<0>(some_tuple)) is far more verbose than accessing struct elements (s.l).
Accessing fields by name is far more informative (and shorter!) than by numeric index.
The last two points are somewhat addressed by the tie function. Given these disadvantages, what would be a good use-case for tuples?
UPDATE Turns out that VS2010 SP1 debugger cannot show the contents of the following array std::tuple<int, int, int> stack[40], but it works fine when it's coded with a struct. So the decision is basically a no-brainer: if you'll ever have to inspect its values, use a struct [esp. important with debuggers like GDB].
It is an easy way to return multiple values from a function;
std::tuple<int,int> fun();
The result values can be used elegantly as follows:
int a;
int b;
std::tie(a,b)=fun();
Well, imho, the most important part is generic code. Writing generic code that works on all kinds of structs is a lot harder than writing generics that work on tuples. For example, the std::tie function you mentioned yourself would be very nearly impossible to make for structs.
this allows you to do things like this:
Store function parameters for delayed execution (e.g. this question )
Return multiple parameters without cumbersome (un)packing with std::tie
Combine (not equal-typed) data sets (e.g. from parallel execution), it can be done as simply as std::tuple_cat.
The thing is, it does not stop with these uses, people can expand on this list and write generic functionality based on tuples that is much harder to do with structs. Who knows, maybe tomorrow someone finds a brilliant use for serialization purposes.
I think most use for tuples comes from std::tie:
bool MyStruct::operator<(MyStruct const &o) const
{
return std::tie(a, b, c) < std::tie(o.a, o.b, o.c);
}
Along with many other examples in the answers here. I find this example to be the most commonly useful, however, as it saves a lot of effort from how it used to be in C++03.
I think there is NO good use for tuples outside of implementation details of some generic library feature.
The (possible) saving in typing do not offset the losses in self-documenting properties of the resulting code.
Substituting tuples for structs that just takes away a meaningful name for a field, replacing the field name with a "number" (just like the ill-conceived concept of an std::pair).
Returning multiple values using tuples is much less self-documenting then the alternatives -- returning named types or using named references. Without this self-documenting, it is easy to confuse the order of the returned values, if they are mutually convertible.
Have you ever used std::pair? Many of the places you'd use std::tuple are similar, but not restricted to exactly two values.
The disadvantages you list for tuples also apply to std::pair, sometimes you want a more expressive type with better names for its members than first and second, but sometimes you don't need that. The same applies to tuples.
The real use cases are situations where you have unnameable elements- variadic templates and lambda functions. In both situations you can have unnamed elements with unknown types and thus the only way to store them is a struct with unnamed elements: std::tuple. In every other situation you have a known # of name-able elements with known types and can thus use an ordinary struct, which is the superior answer 99% of the time.
For example, you should NOT use std::tuple to have "multiple returns" from ordinary functions or templates w/ a fixed number of generic inputs. Use a real structure for that. A real object is FAR more "generic" than the std::tuple cookie-cutter, because you can give a real object literally any interface. It will also give you much more type safety and flexibility in public libraries.
Just compare these 2 class member functions:
std::tuple<double, double, double> GetLocation() const; // x, y, z
GeoCoordinate GetLocation() const;
With a real 'geo coordinate' object I can provide an operator bool() that returns false if the parent object had no location. Via its APIs users could get the x,y,z locations. But here's the big thing- if I decide to make GeoCoordinate 4D by adding a time field in 6 months, current users's code won't break. I cannot do that with the std::tuple version.
Interoperation with other programming languages that use tuples, and returning multiple values without having the caller have to understand any extra types. Those are the first two that come to my mind.
I cannot comment on mirk's answer, so I'll have to give a separate answer:
I think tuples were added to the standard also to allow for functional style programming. As an example, while code like
void my_func(const MyClass& input, MyClass& output1, MyClass& output2, MyClass& output3)
{
// whatever
}
is ubiquitous in traditional C++, because it is the only way to have multiple objects returned by a function, this is an abomination for functional programming. Now you may write
tuple<MyClass, MyClass, MyClass> my_func(const MyClass& input)
{
// whatever
return tuple<MyClass, MyClass, MyClass>(output1, output2, output3);
}
Thus having the chance to avoid side effects and mutability, to allow for pipelining, and, at the same time, to preserve the semantic strength of your function.
F.21: To return multiple "out" values, prefer returning a struct or tuple.
Prefer using a named struct where there are semantics to the returned value. Otherwise, a nameless tuple is useful in generic code.
For instance, if returned values are value from the input stream and the error code, these values will not ego far together. They are not related enough to justify a dedicated structure to hold both. Differently, x and y pair would rather have a structure like Point.
The source I reference is maintained by Bjarne Stroustrup, Herb Sutter so I think somewhat trustworthy.

Most efficient way to process all items in an unknown container?

I'm doing a computation in C++ and it has to be as fast as possible (it is executed 60 times per second with possibly large data). During the computation, a certain set of items have to be processed. However, in different cases, different implementations of the item storage are optimal, so i need to use an abstract class for that.
My question is, what is the most common and most efficient way to do an action with each of the items in C++? (I don't need to change the structure of the container during that.) I have thought of two possible solutions:
Make iterators for the storage classes. (They're also mine, so i can add it.) This is common in Java, but doesn't seem very 'C' to me:
class Iterator {
public:
bool more() const;
Item * next();
}
Add sort of an abstract handler, which would be overriden in the computation part and would include the code to be called on each item:
class Handler {
public:
virtual void process(Item &item) = 0;
}
(Only a function pointer wouldn't be enough because it has to also bring some other data.)
Something completely different?
The second option seems a bit better to me since the items could in fact be processed in a single loop without interruption, but it makes the code quite messy as i would have to make quite a lot of derived classes. What would you suggest?
Thanks.
Edit: To be more exact, the storage data type isn't exactly just an ADT, it has means of only finding only a specific subset of the elements in it based on some parameters, which i need to then process, so i can't prepare all of them in an array or something.
#include <algorithm>
Have a look at the existing containers provided by the C++ standard, and functions such as for_each.
For a comparison of C++ container iteration to interfaces in "modern" languages, see this answer of mine. The other answers have good examples of what the idiomatic C++ way looks like in practice.
Using templated functors, as the standard containers and algorithms do, will definitely give you a speed advantage over virtual dispatch (although sometimes the compiler can devirtualize calls, don't count on it).
C++ has iterators already. It's not a particularly "Java" thing. (Note that their interface is different, though, and they're much more efficient than their Java equivalents)
As for the second approach, calling a virtual function for every element is going to hurt performance if you're worried about throughput.
If you can (pre-)sort your data so that all objects of the same type are stored consecutively, then you can select the function to call once, and then apply it to all elements of that type. Otherwise, you'll have to go through the indirection/type check of a virtual function or another mechanism to perform the appropriate action for every individual element.
What gave you the impression that iterators are not very C++-like? The standard library is full of them (see this), and includes a wide range of algorithms that can be used to effectively perform tasks on a wide range of standard container types.
If you use the STL containers you can save re-inventing the wheel and get easy access to a wide variety of pre-defined algorithms. This is almost always better than writing your own equivalent container with an ad-hoc iteration solution.
A function template perhaps:
template <typename C>
void process(C & c)
{
typedef typename C::value_type type;
for (type & x : c) { do_something_with(x); }
}
The iteration will use the containers iterators, which is generally as efficient as you can get.
You can specialize the template for specific containers.

What is std::pair?

What is std::pair for, why would I use it, and what benefits does boost::compressed_pair bring?
compressed_pair uses some template trickery to save space. In C++, an object (small o) can not have the same address as a different object.
So even if you have
struct A { };
A's size will not be 0, because then:
A a1;
A a2;
&a1 == &a2;
would hold, which is not allowed.
But many compilers will do what is called the "empty base class optimization":
struct A { };
struct B { int x; };
struct C : public A { int x; };
Here, it is fine for B and C to have the same size, even if sizeof(A) can't be zero.
So boost::compressed_pair takes advantage of this optimization and will, where possible, inherit from one or the other of the types in the pair if it is empty.
So a std::pair might look like (I've elided a good deal, ctors etc.):
template<typename FirstType, typename SecondType>
struct pair {
FirstType first;
SecondType second;
};
That means if either FirstType or SecondType is A, your pair<A, int> has to be bigger than sizeof(int).
But if you use compressed_pair, its generated code will look akin to:
struct compressed_pair<A,int> : private A {
int second_;
A first() { return *this; }
int second() { return second_; }
};
And compressed_pair<A,int> will only be as big as sizeof(int).
std::pair is a data type for grouping two values together as a single object. std::map uses it for key, value pairs.
While you're learning pair, you might check out tuple. It's like pair but for grouping an arbitrary number of values. tuple is part of TR1 and many compilers already include it with their Standard Library implementations.
Also, checkout Chapter 1, "Tuples," of the book The C++ Standard Library Extensions: A Tutorial and Reference by Pete Becker, ISBN-13: 9780321412997, for a thorough explanation.
You sometimes need to return 2 values from a function, and it's often overkill to go and create a class just for that.
std:pair comes in handy in those cases.
I think boost:compressed_pair is able to optimize away the members of size 0.
Which is mostly useful for heavy template machinery in libraries.
If you do control the types directly, it's irrelevant.
It can sound strange to hear that compressed_pair cares about a couple of bytes. But it can actually be important when one considers where compressed_pair can be used. For example let's consider this code:
boost::function<void(int)> f(boost::bind(&f, _1));
It can suddenly have a big impact to use compressed_pair in cases like above. What could happen if boost::bind stores the function pointer and the place-holder _1 as members in itself or in a std::pair in itself? Well, it could bloat up to sizeof(&f) + sizeof(_1). Assuming a function pointer has 8 bytes (not uncommon especially for member functions) and the placeholder has one byte (see Logan's answer for why), then we could have needed 9 bytes for the bind object. Because of aligning, this could bloat up to 12 bytes on a usual 32bit system.
boost::function encourages its implementations to apply a small object optimization. That means that for small functors, a small buffer directly embedded in the boost::function object is used to store the functor. For larger functors, the heap would have to be used by using operator new to get memory. Around boost version 1.34, it was decided to adopt this optimization, because it was figured one could gain some very great performance benefits.
Now, a reasonable (yet, maybe still quite small) limit for such a small buffer would be 8 bytes. That is, our quite simple bind object would not fit into the small buffer, and would require operator new to be stored. If the bind object above would use a compressed_pair, it can actually reduce its size to 8 bytes (or 4 bytes for non-member function pointer often), because the placeholder is nothing more than an empty object.
So, what may look like just wasting a lot of thought for just only a few bytes actually can have a significant impact on performance.
It's standard class for storing a pair of values. It's returned/used by some standard functions, like std::map::insert.
boost::compressed_pair claims to be more efficient: see here
std::pair comes in handy for a couple of the other container classes in the STL.
For example:
std::map<>
std::multimap<>
Both store std::pairs of keys and values.
When using the map and multimap, you often access the elements using a pointer to a pair.
Additional info: boost::compressed_pair is useful when one of the pair's types is an empty struct. This is often used in template metaprogramming when the pair's types are programmatically inferred from other types. At then end, you usually have some form of "empty struct".
I would prefer std::pair for any "normal" use, unless you are into heavy template metaprogramming.
It's nothing but a structure with two variables under the hood.
I actually dislike using std::pair for function returns. The reader of the code would have to know what .first is and what .second is.
The compromise I use sometimes is to immediately create constant references to .first and .second, while naming the references clearly.
What is std::pair for, why would I use it?
It is just as simple two elements tuple. It was defined in first version of STL in times when compilers were not widely supporting templates and metaprogramming techniques which would be required to implement more sophisticated type of tuple like Boost.Tuple.
It is useful in many situations. std::pair is used in standard associative containers. It can be used as a simple form of range std::pair<iterator, iterator> - so one may define algorithms accepting single object representing range instead of two iterators separately.
(It is a useful alternative in many situations.)
Sometimes there are two pieces of information that you just always pass around together, whether as a parameter, or a return value, or whatever. Sure, you could write your own object, but if it's just two small primitives or similar, sometimes a pair seems just fine.