I am not sure whether it is a personal perspective or just a common feeling. I think in most cases, python's API is much more intuitive than C++ STL library APIs.

If it is not a subjective judgement, could anyone explain why?

closed as not constructive by Mason Wheeler, ChrisF Sep 17 '11 at 14:42

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    Intuition is subjective. But perhaps someone will have a useful opinion... – Jon Purdy Sep 17 '11 at 8:26
  • I find the exact opposite. But that's because I learned C++ first. I am sure if I had learned python first I would be in the boat. – Martin York Sep 17 '11 at 16:15
  • This is rather a question of language use and experience, as both APIs are highly consistent with the general features and programming style of their respective languages. So it is more a question how well you are versed in these languages. And this again depends on your personal experience and preferences. So no, only you can explain why, as it is a subjective judgement. – Christian Rau Sep 17 '11 at 16:16

I find the STL pretty intuitive. It is extremely consistent, and the wording is clear. Of course consistency does not imply ease of discovery, however once you've discovered a given container or algorithms, you should be at ease with the others.

Some examples:

  • size, empty, clear are present on all containers, with the same signature. They have the same complexity (with an exception for std::list::size).
  • push_back is available on all containers that support insertion at the end: vector, deque, list, ... regardless of their internal implementation. The signature and complexity are nigh identical (from amortized O(1) to true O(1)) so there is no surprise.
  • copy takes a range of iterators as input, and a single iterator as output. The same applies to other algorithms: a range of iterators as input (+ another single iterator for a second input) and a single iterator as output.

I personally find it easy to use a "new" container (unordered_map ?) because I am in familiar hands.

  • 1
    The C++ standard library definitely has it's unintuitive aspects. For example, std::remove_if doesn't do the whole job of removing the unwanted items - that's why we need the whatever.erase (std::remove_if (...), whatever.end ()); idiom. Of course the name is about the best name that functionality can have, and there's a reason for providing that functionality rather than a full removal, but nevertheless this isn't very intuitive. The point being that where there's a conflict, C++ is biassed towards efficiency and flexibility rather than towards intuitiveness. – Steve314 Sep 17 '11 at 19:16
  • @Steve: I agree, remove_if could have been better named (let's face it, it's very much a stable_partition....). – Matthieu M. Sep 17 '11 at 19:39
  • 1
    not really - only the resulting predicate == true partition of the sequence will contain the results you'd expect from a stable partition, the other partition (the bit discarded by the erase part of the idiom) probably contains the original unmodified items irrespective of whether they pass or fail the predicate, though I don't know if the standard guarantees that. The function copies values down that need to be kept. Doing extra copying to preserve the unwanted values would be inefficient when the normal next step is to erase them anyway. – Steve314 Sep 17 '11 at 23:37

It's absolutely subjective.

The C++ STL library will be much more intuitive to someone who's very comfortable with C++.

The Python libs will be much more intuitive to those well versed in Python.

The longer you spend with a language, the more you become comfortable with it and the more it makes sense. Or, the more you try to force it to make sense to refrain from losing your mind (depending on the language in question - think Javascript and scope chain for example, or just Brainf**k all on its own ;))

  • While true, I suppose there must be a reason why boost is often preferred to stl. – back2dos Sep 17 '11 at 8:42
  • 5
    @back2dos: Er, because Boost mainly provides a whole lot of things not in the standard library? – user7043 Sep 17 '11 at 9:04
  • 1
    @back2dos: boost is not preferred to STL. boost is basically additional to the STL, basically it is a testing ground for new functionality that (if proven useful) will be added to the STL. – Martin York Sep 17 '11 at 16:18
  • @delnan: You completely missed my point. I am talking about the boost features, that provide alternatives to existing standard library solutions, starting with some fundamental things like pointers, but also collections, functors and iteration. When it comes to the functionality, the intersection between boost and stl takes up quite a lot of the stl in fact, only that boost exposes much of that functionality through higher level abstractions. – back2dos Sep 17 '11 at 20:46

Intuitiveness is pretty subjective, but there a few points that I can be objectively made.

1) Python's API have more stuff in them

Python's various objects have much more functionality. Compare what you can do with a python string and a C++ string. Or the python random functionality vs. c++ random functionality. A concrete example, selecting a random element from a list/vector.

items[rand() % items.size()]



Python has move a lot more into the standard library which make it easier to use.

2) Invoking Python's functionality typically takes less verbiage.

For example, comparing sorting lists and vectors.

std::sort(items.begin(), items.end())



What if you want to sort by custom criteria?

bool name_compare(std::string & left, std::string & right)
    return left.size() < right.size();
std::sort(items.begin(), items.end(), name_compare)


items.sort(key = len)

3) Literals produces standard library values

In C++ string literals produces char arrays and array literals produces arrays. Neither produces the C++ object which would be useful. In contrast, Python provides literals for producing the most useful type of data structures.


I haven't noticed any difference in intuitiveness, but C++ interfaces are naturally more complicated since they have to specify whether to pass objects by pointer, reference, value or move semantics, and who is responsible for deleting any objects involved. Additionally C++ developers are very concerned with low-level efficiency, which can lead them to provide multiple different ways to access the same functionality.

  • 1
    It may be more complex for the library writers because of the different usage semantics. But for the user it should be just as trivial. The whole who is responsable for deleting an object has been solved (over a decade ago) we just have to stop C programmers from coming and making a mess by using pointers (C++ programmers only use smart pointers or references). – Martin York Sep 17 '11 at 16:21

Not the answer you're looking for? Browse other questions tagged or ask your own question.