interesting problem( map<int , vector<string > & > tmp; // it donotwork )

[Pallav singh]

Hi All ,

i am getting an interesting problem
map<int , vector<string > & > tmp; // it donot work
map<int , vector<string > * > tmp; // it work

++++++++++++++++++++++++++++++++++++++++++++++++

kindly let me know the reason

#include <iostream.h>
#include <map>
#include <vector>
#include <string>

using namespace std;

int main()
{
vector< string > v1 , v2;
map<int , vector<string > & > tmp;
map<int , vector<string > & >::iterator iter1,iter2;
tmp.insert(pair<int ,vector<string> & >(1,v1));
tmp.insert(pair<int ,vector<string> & >(2,v2));

v1.push_back("Pallav1");
v1.push_back("Sharmad1");
v1.push_back("Ajay1");

v2.push_back("Pallav2");
v2.push_back("Sharmad2");
v2.push_back("Ajay2");

for(int i = 0 ; i < v1.size() ; i++ )
cout<< v1.at(i) << endl;

for(int i = 0 ; i < v2.size() ; i++ )
cout<< v2.at(i) << endl;

iter1 = tmp.begin();
iter2 = tmp.end();

for(iter1 ; iter1 != iter2 ; iter1++ )
{ cout<<"++++++++++++++++++++++++++++++++++++"<<endl;
cout<<"first value :: "<<(*iter1).first ;
for(int i = 0 ; i < ((*iter1).second)->size() ;i++)
cout<<((*iter1).second)->at(i) <<endl;
}

return 0;
}


Thanks
Pallav Singh

 

[Victor Bazarov]

i am getting an interesting problem
map<int , vector<string > & > tmp; // it donot work

References are not objects and cannot be stored in standard containers
(or any other containers for that matter). Nothing really "interesting"
about it.

[..]

V

 

[Juha Nieminen]

map<int , vector<string > & > tmp; // it donot work

You cannot instantiate references because references are not "real"
types. That's why references cannot be stored into data containers.

A pointer is a real type and can be instantiated and assigned.

 

[Noah Roberts]

(e-mail address removed)>, (e-mail address removed)
says...

Hi All ,

i am getting an interesting problem
map<int , vector<string > & > tmp; // it donot work
map<int , vector<string > * > tmp; // it work

In standard terms attempting to store a reference in a container is
nonsense. In practical terms I think what you'll most commonly run
afoul of is that they are not assignable or default constructable.

 

[Jiøí Paleèek]

References are not objects and cannot be stored in standard containers
(or any other containers for that matter).

Certainly not. References are not objects in standardese, but this doesn't
prevent anyone to store them in a container. The thing that does is that
they have no reference (ie. there's no T& &) and they are not assignable.

You can, however, create containers that store references, and there are
containers that really do, like boost::tuple.

Regards
Jiri Palecek

 

[Noah Roberts]

Certainly not. References are not objects in standardese, but this doesn't
prevent anyone to store them in a container. The thing that does is that
they have no reference (ie. there's no T& &) and they are not assignable.

You can, however, create containers that store references, and there are
containers that really do, like boost::tuple.

boost::tuple isn't a container. It's actually a completely different
structure entirely. When you create a boost::tuple you're actually
forming something more resembling a basic struct than something
resembling a container of any sort. It's only iteratable at the meta
level.

 

[Victor Bazarov]

Certainly not. References are not objects in standardese, but this
doesn't prevent anyone to store them in a container. The thing that does
is that they have no reference (ie. there's no T& &) and they are not
assignable.

You can, however, create containers that store references, and there are
containers that really do, like boost::tuple.

The word "container" in the normal human sense means that the contained
item can be placed from outside in, or the one that is currently in the
container can be *replaced* with another one. You can't do that with
references. boost::tuple is not a container of references, it's a
wrapper. It is relatively easy to create a wrapper for a reference so
that it would be easier to store it in the standard container, but it
does not mean that you can store reference in a "container".

OOD has "containment" relationship, which in C++ terms means that the
"container" object has the "contained" object as its member. It is
certainly possible with references. It does not represent, however, the
containment in the same sense as used with std::vector or std::map, for
instance.

V

 

[Victor Bazarov]

(e-mail address removed)>, (e-mail address removed)
says...

In standard terms attempting to store a reference in a container is
nonsense. In practical terms I think what you'll most commonly run
afoul of is that they are not assignable or default constructable.

Actually the default-constructible is not a requirement for standard
container elements. Copy-constructible, however, is. And AIUI,
references *are* copy-constructible.

V

 

[Noah Roberts]

Actually the default-constructible is not a requirement for standard
container elements. Copy-constructible, however, is. And AIUI,
references *are* copy-constructible.

Yeah, maybe that was just a requirement of some containers, like vector.

In my less than formal stages I made some std::vector code that used
references. Worked just fine until it didn't. You can create the empty
vector, use push_back, etc... as soon as you try to initialize it to
some size or assign to any element you're screwed.

 

[Bo Persson]

Yeah, maybe that was just a requirement of some containers, like
vector.

In my less than formal stages I made some std::vector code that used
references. Worked just fine until it didn't. You can create the
empty vector, use push_back, etc... as soon as you try to
initialize it to some size or assign to any element you're screwed.

Copy constructible and assignable is the formal minimum requirements.

Some operations, like resize(42), also requires the elements to be
default constructible. Like you noticed, if you don't use resize, you
get away with that requirement.


Bo Persson

 

[James Kanze]

[...]

Copy constructible and assignable is the formal minimum requirements.

Some operations, like resize(42), also requires the elements to be
default constructible. Like you noticed, if you don't use resize, you
get away with that requirement.

Just a nit, but none of the standard containers ever require
default constructible for the container itself. The do have
functions with a default argument of T(), however, and if you
use the default argument, obviously, T() must be a legal
expression.

Also, I think that the next version of the standard will relax
the requirements for node based containers, and only require
CopyConstructible, and not Assignable. In which case, maybe
something like std::link< MyType& > will be legal. (I can't
access my copy of the draft from here, however, and so can't
verify this, so take it with a grain of salt.)

 

[Juha Nieminen]

Some operations, like resize(42), also requires the elements to be
default constructible.

Is that true even if you supply an object as second parameter?

 

[Bo Persson]

Is that true even if you supply an object as second parameter?

Probably, as C++0x has made it two separate functions - one with a
default value and one with a user supplied value.


Bo Persson