objects with member references..

Discussion in 'C++' started by Dave Townsend, Sep 25, 2004.

  1. 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
    Dave Townsend, Sep 25, 2004
    #1
    1. Advertising

  2. Dave Townsend

    David Hilsee Guest

    "Dave Townsend" <> wrote in message
    news:...
    > 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[].

    --
    David Hilsee
    David Hilsee, Sep 25, 2004
    #2
    1. Advertising

  3. "David Hilsee" <> wrote in message
    news:...
    > "Dave Townsend" <> wrote in message
    > news:...
    > > 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[].
    >
    > --
    > David Hilsee
    >
    >


    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.
    Dave Townsend, Sep 25, 2004
    #3
  4. Dave Townsend

    David Hilsee Guest

    "Dave Townsend" <> wrote in message
    news:...
    <snip>
    > 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.

    --
    David Hilsee
    David Hilsee, Sep 25, 2004
    #4
  5. "Dave Townsend" <> wrote in message
    news:...
    >
    > "David Hilsee" <> wrote in message
    > news:...
    >> "Dave Townsend" <> wrote in message
    >> news:...
    >> > 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
    John Harrison, Sep 25, 2004
    #5
  6. "John Harrison" <> wrote in message
    news:...
    >
    > "Dave Townsend" <> wrote in message
    > news:...
    > >
    > > "David Hilsee" <> wrote in message
    > > news:...
    > >> "Dave Townsend" <> wrote in message
    > >> news:...
    > >> > 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.

    dave
    Dave Townsend, Sep 25, 2004
    #6
  7. "Dave Townsend" <> wrote in message
    news:...
    >
    > "John Harrison" <> wrote in message
    > news:...
    > >
    > > "Dave Townsend" <> wrote in message
    > > news:...
    > > >
    > > > "David Hilsee" <> wrote in message
    > > > news:...
    > > >> "Dave Townsend" <> wrote in message
    > > >> news:...
    > > >> > 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
    John Harrison, Sep 25, 2004
    #7
  8. Dave Townsend

    Paul Guest

    "Dave Townsend" <> wrote in message news:<>...
    > 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?
    Paul, Sep 25, 2004
    #8
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roger Leigh
    Replies:
    8
    Views:
    415
    Karl Heinz Buchegger
    Nov 17, 2003
  2. Replies:
    3
    Views:
    435
    Victor Bazarov
    Nov 10, 2004
  3. DanielEKFA
    Replies:
    8
    Views:
    589
    DanielEKFA
    May 16, 2005
  4. Replies:
    8
    Views:
    694
    Bruno Desthuilliers
    Dec 12, 2006
  5. K. Frank
    Replies:
    20
    Views:
    379
Loading...

Share This Page