STL & pipe, socket descriptors

[M.Endraszka]

Hi,

I am writing a simple irc-like server and came across weird behavior
while debugging. Could anyone tell me why the following happens :

I have a class which stores pipe descriptors as a member field.
Descriptors are initialized with pipe(descr) in class constructor.
Then I have an array of objects of this class, preferably a STL
vector. If I initialize the vector with:

vector<objectob jects(20);

all the objects have the same pipe descriptors (pipes are the same &
there is no point in have 20 of them)
this happens if I initialize with objects.push_ba ck(...) as well. If I
initilize objects like that :

object* first_object = new object;
object* second_object = new object;

it is ok. (the descriptors given by pipe(descr); are different)

I want to use STL vector/list/whatever but it just doesn't work. I can
understand that vector<objectob jects(20); may construct just one
object and then copy it 20 times, but shouldn't push_back() be any
better?

Please help.

Marcin Endraszka

[Robert Bauck Hamar]

M.*********@gma il.com wrote:

>
Hi,

I am writing a simple irc-like server and came across weird behavior
while debugging. Could anyone tell me why the following happens :

I have a class which stores pipe descriptors as a member field.
Descriptors are initialized with pipe(descr) in class constructor.
Then I have an array of objects of this class, preferably a STL
vector. If I initialize the vector with:

vector<objectob jects(20);

this calls

vector<object>: :vector(vector< object>::size_t ype, const object& t=object());

so the definition of objects is the same as if you wrote

vector<objectob jects(20, object());

and this creates 20 copies of the temporary created as second argument.

all the objects have the same pipe descriptors (pipes are the same &
there is no point in have 20 of them)
this happens if I initialize with objects.push_ba ck(...) as well.

What do you mean initialize with push_back?

vector<objectob jects;
for (int i = 0; i < 20; ++i)
objects.push_ba ck(object());

?

It's hard to guess without seeing any code.

--
rbh

[John Harrison]

M.*********@gma il.com wrote:

Hi,

I am writing a simple irc-like server and came across weird behavior
while debugging. Could anyone tell me why the following happens :

I have a class which stores pipe descriptors as a member field.
Descriptors are initialized with pipe(descr) in class constructor.
Then I have an array of objects of this class, preferably a STL
vector. If I initialize the vector with:

vector<objectob jects(20);

all the objects have the same pipe descriptors (pipes are the same &
there is no point in have 20 of them)
this happens if I initialize with objects.push_ba ck(...) as well. If I
initilize objects like that :

object* first_object = new object;
object* second_object = new object;

it is ok. (the descriptors given by pipe(descr); are different)

I want to use STL vector/list/whatever but it just doesn't work. I can
understand that vector<objectob jects(20); may construct just one
object and then copy it 20 times, but shouldn't push_back() be any
better?

Please help.

Marcin Endraszka

Post some code. Probably your definition of object is wrong, but who can
say without seeing some code.

john

[M.Endraszka]

On 16 Cze, 21:08, Robert Bauck Hamar <roberth+n...@i fi.uio.nowrote:

It's hard to guess without seeing any code.

class object
{
public:
int p[2];

object(int id)
{
pipe(p);
printf("Object %d has descriptor %d.",id,p[0]);
}

~object()
{
close(p[0]);
close(p[1]);
}
};
Static array of those will return eg.

object objects[3];
Object 1 has descriptor 7.
Object 2 has descriptor 9.
Object 3 has descriptor 11. (there are pairs of them of
c.)

STL vector will return:

vector<objectob jects;
objects.push_ba ck(1);objects.p ush_back(2);obj ects.push_back( 3);

Object 1 has descriptor 7.
Object 2 has descriptor 7.
Object 3 has descriptor 7.

Which is totally not what I want. What's more if there was a socket
descriptor no.7 before, I may get same pipe descriptor AND socket
descriptor at the same time, which is so wrong.

Ask whatever you need.

Marcin

[Thomas J. Gritzan]

M.*********@gma il.com wrote:

Static array of those will return eg.

object objects[3];
Object 1 has descriptor 7.
Object 2 has descriptor 9.
Object 3 has descriptor 11. (there are pairs of them of
c.)

STL vector will return:

vector<objectob jects;

Try at this point:

objects.reserve (3);

objects.push_ba ck(1);objects.p ush_back(2);obj ects.push_back( 3);

Object 1 has descriptor 7.
Object 2 has descriptor 7.
Object 3 has descriptor 7.

Which is totally not what I want.

You definitly violate the "rule of three". That may be the problem here.
Google for it. If it works with a reserve(3) in this example, that this is
your problem. The vector copies your objects and makes temporaries which
get destructed, closing your pipes. So the next pipe gets an old yet unused
descriptor.

--
Thomas
http://www.netmeister.org/news/learn2quote.html

[Robert Bauck Hamar]

M.*********@gma il.com wrote:

On 16 Cze, 21:08, Robert Bauck Hamar <roberth+n...@i fi.uio.nowrote:

>It's hard to guess without seeing any code.

class object
{
public:
int p[2];

object(int id)
{
pipe(p);
printf("Object %d has descriptor %d.",id,p[0]);
}

~object()
{

I'll give you a hint. Insert

printf("Descrip tors %d and %d closed\n", p[0], p[1]);

here.

close(p[0]);
close(p[1]);
}
};

--
rbh

[M.Endraszka]

On 16 Cze, 22:38, "Thomas J. Gritzan" <Phygon_ANTIS.. [e-mail]:

You definitly violate the "rule of three". That may be the problem here.
Google for it. If it works with a reserve(3) in this example, that this is
your problem. The vector copies your objects and makes temporaries which
get destructed, closing your pipes. So the next pipe gets an old yet unused
descriptor.

Ok. I see the sequence is CONSTRUCT TEMP -COPY TO DESTINATION ->
DESTROY TEMP
which I don't like, but still makes sense

Writing a copy constructor seems to help

object(object const& in)
{
id = in.id;
pipe(p);
}

I also added assigment operator as one of you suggested:

object& operator=(const object& in)
{
p[0] = in.p[0];
p[1] = in.p[1];
}

Though I think compiler generated one would do the same.
Thanks for mentioning the "rule of three"

Cheers

[Robert Bauck Hamar]

M.*********@gma il.com wrote:

On 16 Cze, 22:38, "Thomas J. Gritzan" <Phygon_ANTIS.. [e-mail]:

>You definitly violate the "rule of three". That may be the problem here.
Google for it. If it works with a reserve(3) in this example, that this
is your problem. The vector copies your objects and makes temporaries
which get destructed, closing your pipes. So the next pipe gets an old
yet unused descriptor.

Ok. I see the sequence is CONSTRUCT TEMP -COPY TO DESTINATION ->
DESTROY TEMP
which I don't like, but still makes sense.

It's what C++ does.

Writing a copy constructor seems to help

object(object const& in)
{
id = in.id;
pipe(p);
}

IMHO, this is the wrong solution. It creates a lot of pipes, and it makes
the object harder to use (copies aren't equal as one would usually expect).

I also added assigment operator as one of you suggested:

object& operator=(const object& in)
{
p[0] = in.p[0];
p[1] = in.p[1];
}

Though I think compiler generated one would do the same.

Your compiler would generate the same thing. You need the rule of three, but
not this way.

Solution 1)
class object {
... //as before
private:
void operator = (const object&); // No need to actually implement these
object(const object&);
};

vector<boost::s hared_ptr<objec t objects;
for (...)
objects.push_ba ck(boost::share d_ptr<object>(n ew object(i)));

This would make the objects non copyable, and your boost::shared_p tr takes
care of deleting. You could also use std::auto_ptr instead of
boost::shared_p tr.

Solution 2)
class object {
struct arr {
int p[2];
};
boost::shared_p tr<arrp;
public:
object() : p(new arr)
{ pipe(p->p); }
// compiler generated copy ctor, assignment op and dtor works
//...
};

Boost::shared_p tr can be downloaded from <URL:http://boost.org>. It's also
up for the new standard, and might be found if your compiler ships the tr1
libs. In that case it's called std::tr1::share d_ptr (turn on tr1 and
#include <memory>)

--
rbh

[Diego Martins]

On Jun 16, 7:34 pm, Robert Bauck Hamar <roberth+n...@i fi.uio.no>
wrote:

vector<boost::s hared_ptr<objec t objects;
for (...)
objects.push_ba ck(boost::share d_ptr<object>(n ew object(i)));

This would make the objects non copyable, and your boost::shared_p tr takes
care of deleting. You could also use std::auto_ptr instead of
boost::shared_p tr.

no, you couldn't

Diego