3

The standard library vector prevents us from constructing a vector of consts. My question is why? I read the answers on apparently similar questions to mine and I'm not really convinced. So let's dig into some examples and see what happens:

  1. vector<const int> : there is no harm in relocating const int if we need to
  2. Const flat objects (objects with no pointers to resources): those objects can be moved easily without any problem
  3. Const Objects using shared smart pointers are easily copy constructible: in this case relocation is possible

The only apparent case (to me) that needs the object to be non constant is when the objects contains raw pointers to other resources (and in modern C++, those tend to be rare)

For me it is like a vendor of a TV set preventing me to switch it on (by some mechanism) between 4am and 5am just because some random channel plays loud music at that time and his TV can't support that level of sound!! where a simple warning could be sufficient

Soulimane Mammar
  • 1,658
  • 12
  • 20
  • Const objects cannot be moved, if memory serves. – Michael Surette Feb 25 '19 at 05:34
  • I remember reading a dupe somewhere before. – Passer By Feb 25 '19 at 05:37
  • Have you seen [this question](https://stackoverflow.com/questions/17313062/vector-of-const-objects-giving-compile-error)? – 1201ProgramAlarm Feb 25 '19 at 05:37
  • @1201ProgramAlarm, I know that vector needs a non const type to work. I'm just wondering why this restriction when a warning about edge cases is sufficient – Soulimane Mammar Feb 25 '19 at 05:43
  • @uv_ I read that – Soulimane Mammar Feb 25 '19 at 05:44
  • 2
    @SoulimaneMammar: "*there is no harm in relocating const int if we need to*" OK then, show the code that would do so. – Nicol Bolas Feb 25 '19 at 05:49
  • @NicolBolas what about coping it and deleting the old one (this is moving for me) – Soulimane Mammar Feb 25 '19 at 05:53
  • 2
    @SoulimaneMammar: "*this is moving for me*" It doesn't matter what is "moving for you"; it's not moving as far as C++ is concerned. And no, `vector` is not allowed to perform reallocation just because you insert an item into the list. It can only perform reallocation if its capacity is exceeded. And we *really* don't want another `vector` situation, where specializations of the type have different fundamental behaviors. – Nicol Bolas Feb 25 '19 at 06:01
  • @NicolBolas As far as I know there is no moving without any kind of copying. It is just copying as less as possible. For vector I totally agree with you, the benefit of the actual implementation is just for huge vectors otherwise I prefer wasting some bytes for a clean semantic – Soulimane Mammar Feb 25 '19 at 06:13
  • 3
    Did you come across [*this question*](https://stackoverflow.com/questions/6954906)? In particular, Howard Hinnant's answer? – StoryTeller - Unslander Monica Feb 25 '19 at 06:36
  • I'm frustrated !! my question is not a **duplicate** of [this](https://stackoverflow.com/questions/6954906). I read it over and over and it doesn't answer the WHY part. I'm pretty sure that the standard committee has enough reasons for these kind of decisions – Soulimane Mammar Feb 25 '19 at 09:38

0 Answers0