CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 3 of 3 FirstFirst 123
Results 31 to 36 of 36
  1. #31
    Join Date
    Apr 2004
    Location
    Canada
    Posts
    1,342

    Re: Why does std::vector require its elements to be assignable?

    Quote Originally Posted by kempofighter View Post
    You are right - I didn't think that one through well enough. It is impossible for default assignment to work for classes with const attributes. I duplicated your problem with a user defined struct type so I understand now. That is a really interesting issue. For any class with non-static, const members you couldn't always use that type with STL sequence containers. The concept of assignment doesn't make sense for that case since after the assignment the two classes could never be equal. So I guess in your case, why does the pair have to be const for T1? I have never run across this problem in any of my designs. In my experience I have always had situations where a class with constants either has a) static constants for all objects b) non-static constants but the class is a singleton type or c) used enum type for declaring sets of constants. With an enum decl within a class the class you don't have to instantiate the enum to use the constants and the values are the same for all class instances so it is similar to having static constants.
    In my case, the vector's element type is map<T, U>::value_type which happens to be pair<const T, U>. There are good reasons why map<T, U> uses pair<const T, U> instead of pair<T, U> as its value type (the keys determine the ordering of the elements, so if you were allowed to change the key, the ordering could change without the map knowing it), but in this case it's really annoying because I can't store its value type in a vector.

    My workaround in this case is to store pair<T, U> in the vector, but now I have to do an extra copy when I call map's insert() method because map's insert() method takes a pair<const T, U>& parameter, and so a temporary pair<const T, U> object has to be constructed from the pair<T, U> that's in the vector.
    Old Unix programmers never die, they just mv to /dev/null

  2. #32
    Join Date
    Jul 2002
    Location
    Portsmouth. United Kingdom
    Posts
    2,727

    Re: Why does std::vector require its elements to be assignable?

    Quote Originally Posted by HighCommander4 View Post
    Why should the assignability requirement be any different? (And please don't say "because the standard says so". I'd like to know the rationale behind the standard.)
    Maybe the rational was not to constrain the STL implementor?
    Adding the extra contraints to the standard may have been thought to be too restrictive and force the implementation down a narrow (and maybe sub-optimal) path.
    "It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong."
    Richard P. Feynman

  3. #33
    Join Date
    Aug 2005
    Location
    San Diego, CA
    Posts
    1,054

    Question Re: Why does std::vector require its elements to be assignable?

    Quote Originally Posted by HighCommander4 View Post
    In my case, the vector's element type is map<T, U>::value_type which happens to be pair<const T, U>. There are good reasons why map<T, U> uses pair<const T, U> instead of pair<T, U> as its value type (the keys determine the ordering of the elements, so if you were allowed to change the key, the ordering could change without the map knowing it), but in this case it's really annoying because I can't store its value type in a vector.
    Agreed so maybe you need to rethink the design? I don't understand why you would want to copy the key/value pair into the vector in the first place.

    Quote Originally Posted by HighCommander4 View Post

    My workaround in this case is to store pair<T, U> in the vector, but now I have to do an extra copy when I call map's insert() method because map's insert() method takes a pair<const T, U>& parameter, and so a temporary pair<const T, U> object has to be constructed from the pair<T, U> that's in the vector.
    Perhaps you could show us an example and let us know what you are doing? Why are you copying key value pairs from a map into a vector and then back into a map?

    It seems to me that when you do this you have to make copies regardless. Didn't we already agree that the push_back requires copy construction? Likewise when you insert into the map won't it copy construct during the insertion? I'm not sure where you think you are forced into making additional copies that you wouldn't otherwise have to make.

  4. #34
    Join Date
    Apr 2004
    Location
    Canada
    Posts
    1,342

    Re: Why does std::vector require its elements to be assignable?

    Quote Originally Posted by HighCommander4
    What I really want to know is, is it possible to implement vector in a way that certain operations can be performed without the requirement of assignability?

    I suspect the answer is yes, and if so, the next question that naturally arises is, why doesn't the standard mandate such an implementation?
    For what it's worth, the C++0x standard specifies fine-grained requirements for each of the STL container member functions rather than imposing requirements on the container as a whole. In particular, push_back() (for both vector and deque) requires only that the element type be copy constructible, not assignable (if anyone's interested, the relevant sections are 23.2.3/16 and 23.2.1/13).

    I reported this issue to GCC's libstdc++, and they promptly fixed their vector implementation
    Last edited by HighCommander4; July 25th, 2011 at 03:29 PM.
    Old Unix programmers never die, they just mv to /dev/null

  5. #35
    Join Date
    Jun 2009
    Location
    France
    Posts
    2,513

    Re: Why does std::vector require its elements to be assignable?

    That was an interesting read. The thread is old, but I think I'll chip in my two cents:

    Why not use a boost::ptr_vector? Basically, it is a self-maintained container of pointers to objects, making all the requirements met by default.

    That and boost::ptr_vector is always a great container for large objects.
    Is your question related to IO?
    Read this C++ FAQ article at parashift by Marshall Cline. In particular points 1-6.
    It will explain how to correctly deal with IO, how to validate input, and why you shouldn't count on "while(!in.eof())". And it always makes for excellent reading.

  6. #36
    Join Date
    Apr 2004
    Location
    Canada
    Posts
    1,342

    Re: Why does std::vector require its elements to be assignable?

    Quote Originally Posted by monarch_dodra View Post
    That was an interesting read. The thread is old, but I think I'll chip in my two cents:

    Why not use a boost::ptr_vector? Basically, it is a self-maintained container of pointers to objects, making all the requirements met by default.
    The same reason C++ arrays aren't like Java arrays: we want to avoid extra allocations when not necessary.
    Old Unix programmers never die, they just mv to /dev/null

Page 3 of 3 FirstFirst 123

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured