objects with member references..

D

Dave Townsend

Hi,

I came across a little problem the other day, I wonder
if anyone has a more elegant solution:

I have a class which has some "pixmap" members, this is
a QT-data type which is similar to a bitmap on Windows.
A number of the objects are created and share the same set of
pixmaps, so a reference I thought would be a good thing here.

I thought it would be a good thing to

class Foo
{
public:
Foo( ..... QPixmap& pix .....)
_pix(pix)
{}
private:
QPixmap& _pix;

};

Ok, this worked fine. Then I wanted to use an STL Map , this
is where the trouble began since I needed to have a default constructor to
satisfy
the map template, but how do I handle that? I tried some thing like this:

Foo()
:_pixmap( QPixmap() )
{}

but this is bogus since the temporary will be destroyed after the
constructor finishes.
I thought I could create a static Qpixmap which is just used to satisfy the
constructor:

static QPixmap _defaultPix;

Foo()
:_pixmap( _defaultPix)
{}

However, this will not work - the Pixmap cannot be constructed correctly
until other
parts of the application framework have been initialized , instead the
constructor throws and kills the application.

So right now I've gone back to using pointers instead of references, but I'm
unhappy
about that. Any ideas ?

dave
 
D

David Hilsee

Dave Townsend said:
Hi,

I came across a little problem the other day, I wonder
if anyone has a more elegant solution:

I have a class which has some "pixmap" members, this is
a QT-data type which is similar to a bitmap on Windows.
A number of the objects are created and share the same set of
pixmaps, so a reference I thought would be a good thing here.

I thought it would be a good thing to

class Foo
{
public:
Foo( ..... QPixmap& pix .....)
_pix(pix)
{}
private:
QPixmap& _pix;

};

Ok, this worked fine. Then I wanted to use an STL Map , this
is where the trouble began since I needed to have a default constructor to
satisfy
the map template, but how do I handle that? I tried some thing like this:

Foo()
:_pixmap( QPixmap() )
{}

but this is bogus since the temporary will be destroyed after the
constructor finishes.
I thought I could create a static Qpixmap which is just used to satisfy the
constructor:

static QPixmap _defaultPix;

Foo()
:_pixmap( _defaultPix)
{}

However, this will not work - the Pixmap cannot be constructed correctly
until other
parts of the application framework have been initialized , instead the
constructor throws and kills the application.

I don't understand why this approach doesn't work. Would a Singleton with a
getDefaultQPixmax() fix the problem?
So right now I've gone back to using pointers instead of references, but I'm
unhappy
about that. Any ideas ?

Have you considered avoiding operator[] (which is what I assume is causing a
problem) and instead using find/insert? If a default constructor doesn't
make sense for your Foo class, then operator[] may be the wrong member to
use for accessing and inserting elements in the std::map. IIRC, item 24 in
"Effective STL" by Meyers had example code that showed a simple way to avoid
operator[].
 
D

Dave Townsend

David Hilsee said:
Dave Townsend said:
Hi,

I came across a little problem the other day, I wonder
if anyone has a more elegant solution:

I have a class which has some "pixmap" members, this is
a QT-data type which is similar to a bitmap on Windows.
A number of the objects are created and share the same set of
pixmaps, so a reference I thought would be a good thing here.

I thought it would be a good thing to

class Foo
{
public:
Foo( ..... QPixmap& pix .....)
_pix(pix)
{}
private:
QPixmap& _pix;

};

Ok, this worked fine. Then I wanted to use an STL Map , this
is where the trouble began since I needed to have a default constructor to
satisfy
the map template, but how do I handle that? I tried some thing like this:

Foo()
:_pixmap( QPixmap() )
{}

but this is bogus since the temporary will be destroyed after the
constructor finishes.
I thought I could create a static Qpixmap which is just used to satisfy the
constructor:

static QPixmap _defaultPix;

Foo()
:_pixmap( _defaultPix)
{}

However, this will not work - the Pixmap cannot be constructed correctly
until other
parts of the application framework have been initialized , instead the
constructor throws and kills the application.

I don't understand why this approach doesn't work. Would a Singleton with a
getDefaultQPixmax() fix the problem?
So right now I've gone back to using pointers instead of references, but I'm
unhappy
about that. Any ideas ?

Have you considered avoiding operator[] (which is what I assume is causing a
problem) and instead using find/insert? If a default constructor doesn't
make sense for your Foo class, then operator[] may be the wrong member to
use for accessing and inserting elements in the std::map. IIRC, item 24 in
"Effective STL" by Meyers had example code that showed a simple way to avoid
operator[].

Ok. I'd thought about the Singleton, but I'd always thought of singletons
returning
pointers to object, but I now realize you can return a reference too.

I think the suggestion about avoiding the operator[] is probably best - I
only created the
default constructor to please the MSVC compiler, if there's a way of
avoiding operator[]
that would be better since copying these objects doesn't make a lot of sense
anyway.

thanks,
dave.
 
D

David Hilsee

I think the suggestion about avoiding the operator[] is probably best - I
only created the
default constructor to please the MSVC compiler, if there's a way of
avoiding operator[]
that would be better since copying these objects doesn't make a lot of sense
anyway.

Copying, or contructing via a default constructor? I was commenting on the
default constructor, not on the copy constructor or the assignment operator.
 
J

John Harrison

Since the pixmap pointer/reference is private why do you care if it is
implemented as a pointer or reference? Your users certainly won't care. Just
do whatever comes easiest. Why not use references externally but pointers
internally, like this

class Foo
{
public:
Foo() : _pix(0) {}
Foo( ..... QPixmap& pix .....) : _pix(&pix) {}
private:
QPixmap* _pix;
};

Having a default constructor can be useful for reasons other than using
map::eek:perator[].

john
 
D

Dave Townsend

John Harrison said:
Since the pixmap pointer/reference is private why do you care if it is
implemented as a pointer or reference? Your users certainly won't care. Just
do whatever comes easiest. Why not use references externally but pointers
internally, like this

class Foo
{
public:
Foo() : _pix(0) {}
Foo( ..... QPixmap& pix .....) : _pix(&pix) {}
private:
QPixmap* _pix;
};

Having a default constructor can be useful for reasons other than using
map::eek:perator[].

john

Yes, I considered that situation, but I thought it was a blemish and ugly.
I've found
using references is a more robust way of doing things, so I tend to opt for
that approach.

A default constructor in the particullar situation is probably not a good
idea, these objects don't
really have a default state, so that was a mistake in my modelling of them.
Its probably
a good idea to forbid the assignment of these objects ( they are similar to
widgets or Windows
objects, which are not copyable (sp ?) , so users of the class don't tread
on that booby trap.

dave
 
J

John Harrison

Dave Townsend said:
John Harrison said:
Dave Townsend said:
Hi,

I came across a little problem the other day, I wonder
if anyone has a more elegant solution:

I have a class which has some "pixmap" members, this is
a QT-data type which is similar to a bitmap on Windows.
A number of the objects are created and share the same set of
pixmaps, so a reference I thought would be a good thing here.

Since the pixmap pointer/reference is private why do you care if it is
implemented as a pointer or reference? Your users certainly won't care. Just
do whatever comes easiest. Why not use references externally but pointers
internally, like this

class Foo
{
public:
Foo() : _pix(0) {}
Foo( ..... QPixmap& pix .....) : _pix(&pix) {}
private:
QPixmap* _pix;
};

Having a default constructor can be useful for reasons other than using
map::eek:perator[].

john

Yes, I considered that situation, but I thought it was a blemish and ugly.
I've found
using references is a more robust way of doing things, so I tend to opt for
that approach.

A default constructor in the particullar situation is probably not a good
idea, these objects don't
really have a default state, so that was a mistake in my modelling of them.
Its probably
a good idea to forbid the assignment of these objects ( they are similar to
widgets or Windows
objects, which are not copyable (sp ?) , so users of the class don't tread
on that booby trap.

OK but one of your requirements was to use the object in a std::map. IIRC
it's a requirement that classes in any STL container must implement the
assignment operator.

Also using references makes it impossible to implement a swap member
function; which is useful even for objects which are not copyable.

john
 
P

Paul

Dave Townsend said:
Hi,

I came across a little problem the other day, I wonder
if anyone has a more elegant solution:

I have a class which has some "pixmap" members, this is
a QT-data type which is similar to a bitmap on Windows.
A number of the objects are created and share the same set of
pixmaps, so a reference I thought would be a good thing here.

I thought it would be a good thing to

class Foo
{
public:
Foo( ..... QPixmap& pix .....)
_pix(pix)
{}
private:
QPixmap& _pix;

};

Where, and in what type of container if any, are the shared objects stored?
This is an important part of your problem IMO.
Ok, this worked fine. Then I wanted to use an STL Map , this
is where the trouble began since I needed to have a default constructor to
satisfy
the map template, but how do I handle that? I tried some thing like this:

Foo()
:_pixmap( QPixmap() )
{}

but this is bogus since the temporary will be destroyed after the
constructor finishes.
I thought I could create a static Qpixmap which is just used to satisfy the
constructor:

static QPixmap _defaultPix;

Foo()
:_pixmap( _defaultPix)
{}

However, this will not work - the Pixmap cannot be constructed correctly
until other
parts of the application framework have been initialized , instead the
constructor throws and kills the application.

Can't you have a default pixmap object adjacent to the other pixmap objects?
So right now I've gone back to using pointers instead of references, but I'm
unhappy
about that. Any ideas ?

When using pointers where are these shared pixmap objects stored?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top