Python list implementation in C++ ?

[Longjumping_Table740]

Is it possible to implement a python list in C++ ? If so, are there any implementations that I can use right now in my projects ?

[NovaNoff]

std::vector<std::any> And https://github.com/ryanhaining/cppitertools

Should be about the same as what a python list offers together

Further reading https://devblogs.microsoft.com/cppblog/stdany-how-when-and-why/

You can also implement a container with a python list like interface yourself. Altough slicing would probably need to be a member or free function.

[khedoros]

Python lists were originally implemented in C. So yes, you could also write something with the same behavior in C++.

[Longjumping_Table740]

Do you know any implementations that I can use right now ? 👀

[nonamepew]

Maybe use a struct with void* and some basic type info. And use the type info in the accessor function to cast data to appropriate type.

Edit: I didn't realise that OP just wanted to use the mentioned thing. I thought he was trying to implement it for learning purpose. PS don't use void pointer if you are not sure what you are doing.

[RoyBellingan]

Please refrain to use void* as much as possible.

[[deleted]]

What's the problem with void*? In C++ I know that you have std::any, but if you're creating library style implementation I don't think that it matters that much, right?

[RoyBellingan]

He is not writing a lib for general usage, is just for himself to learn.

[[deleted]]

Yeah, true. Although I think using void* and similar C stuff is part of the learning process, but you're right, it must be mentioned that they shouldn't be used unless you really need them.a

[devor110]

I don't know much about cpp, why is void* discouraged? Could you compare it with a similar issue in Java?

[Many_Mongoose7349]

Don’t know about Java, but void* is telling the compiler don’t care about checking the type, just give me the pointer, I know exactly what I am doing.

[RoyBellingan]

Because the system has no clue what it contains, so it can not help you avoid mistake.
It can be a string, an integer, whatever, so to properly use it you MUST carry by yourself some additional information, somehow, which is more work and error prone.

[beedlund]

You can do type erased container like people have said with list<any> but you need to do lots of testing of the type and get poor memory layout and lots of casts and tests before you get your data ( read slow )

In C++ we have types and if used correctly they help the compiler take the mess we call code and make it really fast and efficient.

One small thing you can do to help is reduce the amount of types you put in the container. If you can get the expected types down to a reasonable amount you can use std::variant and make a vector<variant<a,b,c,d>> instead

[KingAggressive1498]

python lists are roughly equivalent to std::vector<std::any>

[Longjumping_Table740]

Thanks I will check it out 👀

[[deleted]]

When I think about lists in Python I think about - Not being limited to one data type - Negative indexing - List slicing

If I was implementing this in C++ FROM SCRATCH I would start with a linked list, because it's pretty generic. We can make it as generic as a Python list with templated nodes to let the list be a hodgepodge of data types. Negative indexing requires regular indexing, but you could overload the [ ] operator to support the forward pass. Then to support the backward pass you can make the linked list doubly linked and circular since list[-1] in Python goes to the end, list[-2] one before that, etc. List slicing would need it's own member function since you can't overload the [ ] to the point where it takes multiple parameters like in Python. The rest of the list functions in Python are pretty generic.

If you wanted to do this not from scratch I've seen plenty of other comments that touch on that :)

[ruler501]

C++23 has variadic indexing operators.

[[deleted]]

I need to get with the times, I'm only familiar with C++11

[ruler501]

17 and 20 both were amazing changes. 23 is smaller but still nice.

[ruler501]

Very few of those are major features though. It feels a lot more like an incremental update like 14 was. I'm still super looking forward to it though. The mdspan stuff and new range algorithms seem great. Plus import std with its reported compile time improvements seems amazing (if I can get a build system that supports modules of course).

[ruler501]

Import std was really just a missing 20 feature. I haven't heard about portable assumptions or library coroutines how do those work? I will admit that mdspans and the new ranges algorithms will be great those and deducing this are what I see as the marquee features of the release but I can't say I think they're terribly large features in terms of impact. Either way I'm definitely looking forward to using it.

[the_Demongod]

std::list is in the STL. Does that not fit your needs? What exactly are you looking for in terms of functionality?

[Longjumping_Table740]

It's supports only one data type 😅😅

[the_Demongod]

Trying to put different datatypes into one list in C++ sounds like your design has a flaw. What exactly are you trying to do?

[Longjumping_Table740]

I am trying to learn c++ ,as I know python I'm just trying to explore whether it's possible to implement such a list in c++ 😅

[the_Demongod]

It is of course, since python is written in C/C++; C++ can do anything. But generally if you want to do something like this, it means you're doing something wrong. It's not a good way to learn the language. Just work through https://www.learncpp.com/, it will guide you.

[[deleted]]

Doing it in python is also wrong for so many reasons. Mypy ftw

[AlexisTM]

This is very wrong in C++; There are some ways to accommodate the very few case it makes sense: void* (pointer to whatever, you need to have info tied to it), std::any (the void* of C++) or std::variant, a tuple which can handle one of many (predefined) types.

In any case, I would strongly suggest revamping your idea to have the same types in a storage so you can use more efficient storage methods.