27

I desire to propose a complete and consistent name and wording for all the existing tags that refer to the C++ containers. They include , , , , , , , , .

The purpose is to replace the current names and descriptions with a new one that is consistent among containers. About the name, different proposals have been advanced to link the std prefix with the actual name, such as std-, std--, std., std... Since the first one is simpler and consistent with already-existing naming convention, it has been preferred. The excerpt explicitly indicates the programming language and library, basic characteristics (time-complexity, value type) and (eventually) the underlying data structure. Furthermore, it is also specified if the tag may be used to refer to other containers, like in the case of associative and unordered associative containers.

Since this proposal is a work in progress, I would like to receive opinions and feedbacks. With it, I also hope to create a reference for future tag edits.

Changes to the proposal can be found in the edits history, including credits.

Proposed excerpt wording

std::array is a class of the C++ Standard Library (since C++11). It is a container that encapsulates a fixed-size array.

std::vector is a class of the C++ Standard Library. It is a container that supports amortized constant-time insert and erase operations only at the end, while they are linear-time elsewhere. It is usually implemented as a dynamically-allocated array.

std::deque is a class of the C++ Standard Library. It is a container that supports amortized constant-time insert and erase operations at both the beginning and the end, while they are linear-time elsewhere. It is usually implemented as a hashed array tree.

std::forward_list is a class of the C++ Standard Library (since C++11). It is a container that supports constant-time insert and erase operations at any position in the sequence. It is usually implemented as a singly-linked list.

std::list is a class of the C++ Standard Library. It is a container that supports constant-time insert and erase operations at any position in the sequence. It is usually implemented as a doubly-linked list.

std::set/std::multiset is a class of the C++ Standard Library. It is an associative container that supports logarithmic-time search, insert and erase operations. It is usually implemented as a red-black tree.

std::map/std::multimap is a class of the C++ Standard Library. It is an associative container that supports logarithmic-time search, insert and erase operations. It is usually implemented as a red-black tree.

std::unordered_set/std::unordered_multiset is a class of the C++ Standard Library (since C++11). It is an unordered associative container that supports amortized constant-time search, insert and erase operations. It is usually implemented as a separate-chaining hash table.

std::unordered_map/std::unordered_multimap is a class of the C++ Standard Library (since C++11). It is an unordered associative container that supports amortized constant-time search, insert and erase operations. It is usually implemented as a separate-chaining hash table.

24
  • 1
    Some of those tags already exist. What are your plans for the questions with those tags who don't cover your new tag definitions?
    – Dominique
    Commented Jun 24 at 11:17
  • 1
    @Dominique, all tags already exists: the purpose is not to replace them, but their description.
    – LoS
    Commented Jun 24 at 11:24
  • 1
    @Dominique, edit tag wiki is a common operation, but sometimes the descriptions are superficial and inconsistent. Thus, I want to provide a "standard" description for them. It is important to note that all questions with that tags continues to be valid, since their meaning is absolutely the same.
    – LoS
    Commented Jun 24 at 11:32
  • 1
    I would prefer to add :: to the tag name.
    – usr1234567
    Commented Jun 24 at 14:06
  • 1
    A uniform naming scheme is definitely desirable. It's something that's relatively easy for a moderator to fix, and should be done so there's less possible confusion as to what the tag is for, as there are some uses of these tags in non-C++ questions. However, I'm wondering why they all have no separator between the std and the name. For example, should they be std-array, std--array, std.array, std..array, c++-std-array, c++-std--array, c++-std.array, c++-std..array, or some other format using the permitted characters.
    – Makyen Mod
    Commented Jun 24 at 14:08
  • 2
    @usr1234567 : is not a permitted character in tag names. See "What symbols/characters are not allowed in tags?"
    – Makyen Mod
    Commented Jun 24 at 14:09
  • 1
    @Makyen Good question, I have no idea why there's no separator after std. I think it would be better to have a - (given that : is not permitted), as there's no other good choice really IMO. No strong feelings on any particular choice though (other than c++- prefix feeling very redundant).
    – cigien
    Commented Jun 24 at 14:39
  • @cigien "other than c++- prefix feeling very redundant" why though, c++ isn't the only language that uses std as name for the standard library.
    – cafce25
    Commented Jun 24 at 14:40
  • 3
    @cafce25 Ah, true. I was thinking that seeing c++ and c++-std-map on a question would be redundant, but ensuring that the tag isn't accidentally used on questions in a different language is also important. Maybe a c++- prefix isn't a bad idea after all.
    – cigien
    Commented Jun 24 at 14:43
  • 1
    @LoS It's certainly possible, and desirable, to have consistent naming. For moderators, renaming a tag (on non-deleted questions) is easy (even though the UI for it isn't clear). While you're welcome to include the naming you'd prefer in the question, I'd suggest mentioning the other possibilities (and that : isn't a permitted character, unfortunately). I'd suggest also linking to searches for each of the tags without the c++ tag (e.g., [unordered-map] -[c++]), as non-C++ uses will need to be handled.
    – Makyen Mod
    Commented Jun 24 at 14:45
  • 1
    Fortunately, there aren't that many questions which use these tags in non-C++ contexts.
    – Makyen Mod
    Commented Jun 24 at 14:48
  • 1
    I agree with the proposal. Most correct would have been to omit std entirely since it is not part of the class name. However I can see the point in keeping std::array separate from the general array/list/set etc tags since that would make the general tags more ambiguous.
    – Lundin
    Commented Jun 25 at 6:32
  • 2
    All those "classes" are actually class templates.
    – Friedrich
    Commented Jun 25 at 7:00
  • 1
    @Makyen Ok, thanks. That's unfortunate. Then I'll try to write an answer that proposes some changes, while noting that implementing it might not be easy. At the very least I want to avoid completely butchering all the container related tags, as the only currently submitted answer is suggesting.
    – cigien
    Commented Jun 27 at 15:26
  • 1
    @LoS There's nothing that can be done at the moment, I think. The issue is that the tags won't simply be renamed, even if the names are universally agreed upon: the questions without a std prefix that end up getting renamed will have to be investigated for non-C++ uses, which will be substantial work. Personally, I think the renaming suggestions in the question are good, though there potentially are some minor improvements to be made. Quuxplusone's answer is the only one, but it doesn't have sufficient support, IMO, to be implemented (especially given how many questions it will touch).
    – cigien
    Commented Jul 5 at 13:31

1 Answer 1

5

The renamed tags being proposed seem unobjectionable and consistent to me. However, I question whether we need all those tags in the first place! I mean, looking at the tree containers, if we're not splitting std-map from std-multimap, then why bother splitting std-set from std-map?

IMO all of these tags should be subsumed into a tag named something like stl-containers.

I glanced specifically at stdvector, because it did occur to me that vector is important and has interesting problems that don't apply to any of the other containers. But it looks to me like that category is currently full of newbie questions that just happen to involve looping over a vector of stuff, and don't actually have anything interesting to do with vector itself, at all. Those questions shouldn't be tagged stdvector. So burninating the stdvector tag and forcing people to think about whether they truly have a stl-containers question or some other kind of question (e.g. an algorithmic question, a buffer-overflow question, a syntax question) would be good, IMHO.

23
  • Your idea may be useful, even if it requires careful study because it means to retag thousands posts. And find a way (ex. creating a dedicated post on Meta) to avoid that other users may reintroduce them in the future, far enough into the future our conversion would be forgotten. Surely, the application of the same idea to other C++-related tags may reduce the tag fragmentation: for example, the tag is-same, which has been used only 17 times, may be merged into the tag type-traits.
    – LoS
    Commented Jun 25 at 14:06
  • @LoS there are tools available to all users that will make this trivial.
    – Braiam
    Commented Jun 25 at 14:16
  • @Braiam, I was not referring to the operation of merging tags, but the potential consequences.
    – LoS
    Commented Jun 25 at 14:33
  • 1
    "to avoid that other users may reintroduce them in the future" — My impression is that if this goes through, then the old tags would all become synonyms/redirects to the stl-containers tag, so accidental recreation wouldn't be likely. Commented Jun 25 at 15:43
  • 4
    The acronym STL is problematic. You need to be acquainted with the history and evolution of C++ to understand it. Let's not force SO users to learn about things that happened over 30 years ago. Coincidentally, there's a question about it.
    – Friedrich
    Commented Jun 25 at 19:19
  • 1
    What about std-containers instead of stl-containers? And would Boost be a factor here at all? Probably not. But, IIRC, the STL as it existed prior to standardization had some stuff that didn't make into the Standard C++ library, so I agree that stl-containers is probably not the best choice. Commented Jun 25 at 19:59
  • 1
    I don't think the acronym "STL" is problematic (except insofar as it also refers to @STL, St Louis, and the SGI STL). All C++ users know what an "STL container" is, and the use of the term "STL" for the standard library is unique to C++. (E.g., the Java collections library is a "standard" library, but is unmistakeably not the STL.) Contrariwise, no C++ programmer uses "STD containers", but other languages' programmers might. Commented Jun 26 at 1:20
  • 3
    The various kinds of containers have similar APIs, sure, but by no means identical (esp. set vs. map), and combining them all seems like an overreach. If someone has a question about a particular container API, I think they ought to be able to indicate that. What value is there in "forcing" an asker to generalize to other containers they may not know or care about? And what then if it does not generalize? (The absence of std-multimap is just a reflection of that container's relative lack of popularity.) Commented Jun 26 at 1:37
  • 1
    @LoS "this problem can not be fixed or worsen by a tag unification" - our bar for making a change that affects thousands of questions should be a just a little bit higher.
    – Friedrich
    Commented Jun 26 at 12:11
  • 1
    @LoS I was trying to say the following: a big change like turning all the std-related tags into one tag will change thousands of existing questions. We need a good reason to do so, like a major improvement. Something that does not fix the original problem but does not make anything worse seems like a weak reason. We put in work and gain (almost?) nothing. That doesn't seem worth it.
    – Friedrich
    Commented Jun 26 at 19:00
  • 1
    @Friedrich, no, I was not talking about the change itself: I was referring to the specific case of the tag stdvector. In particular, I was saying that a lot of questions are tagged with the incorrect tag vector, instead of stdvector, but this problem can not be solved by the tag unification, and therefore it is not worth to worry about this thing. The problem is simply not related to how the tags are in general, but the genuine ignorance of some new users.
    – LoS
    Commented Jun 27 at 7:01
  • 1
    @LoS thanks, I got lost somewhere in this discussion. You also wrote an interesting thing: "reduce tag fragmentation - it is easier to look for questions that refer to one or more C++ containers, without the need of looking for all single tags" - searching for multiple tags: now trivially easy, after the introduction of the one tag to rule them all: looking for one specific container will be impossible. BTW, ignorance is in no way limited to new users only.
    – Friedrich
    Commented Jun 27 at 7:56
  • 1
    I don't understand the motive for replacing specific tags on thousands of questions with a highly generic (and not particularly useful) tag. What does it tell me if a question has an [stl-containers] tag? It's not a useful categorization IMO. Also, if I want to look for questions about, say, the c++ std::priority_queue, wouldn't the related tag be useful to have? Also, regarding the map/multimap split, there is in fact a tag for [multimap]. In fact, every single container a tag already (e.g. [unordered_multiset]), it's just that the OP has not enumerated every one.
    – cigien
    Commented Jun 27 at 10:46
  • 2
    @Braiam Quux's observation may be true for a commonly used container like vector, but for the less common ones, e.g. unordered_multiset stackoverflow.com/questions/tagged/unordered-multiset and unordered_multimap stackoverflow.com/questions/tagged/unordered-multimap, the tagging is pretty much spot on. We'd be throwing out the baby with the bathwater if we simply merged all those tags into one overly generic tag.
    – cigien
    Commented Jun 27 at 15:19
  • 2
    @cigien: I dunno, I glanced at [unordered-multimap] and see a lot tagged [stl] and/or [containers]; one tagged [unordered-multimap] but asking about unordered_map; one tagged with all four unordered associative containers' tags; etc. I claim that (1) literally no answerer is searching for questions specifically about unordered_multimap; (2) if you did want to, you could almost as easily search [stl-containers] unordered_multimap instead of [unordered-multimap], and you'd get more accurate results that way, too. Tags do not need to reinvent full-text search. Commented Jun 27 at 19:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .