Few design questions and auto_ptr

[Soumen]

For one of my project, I want to use auto_ptr. But I'm facing few
issues.

1. Say I've Controller class. I don't want to allow user to create
object of this class unless all arguments
are valid. So I've made the constructor private and given one
static method to create an object of this
class. Since one of senior members in the team doesn't like
throwing exception, I've made this static
method to return NULL pointer when arguments are not valid. But
that stops using auto_ptr since it
cannot accept NULL, I guess. Is there any better way to do this?

2. Now, I've a Cache class in which few members are auto_ptr. Those
basically some pointer to few
STL type map or set etc. Now users of this Cache class needs read
access to these data. Is returning
a const reference a good idea? Returning the member itself will
cause transfer of ownership and I guess
returning a pointer is not a good idea since the user has control
of destroying the object pointed by it.

Let me know your views. This may be trivial design issues to most of
you. But I'm not an expert in
design issues. Thanks in advance to all your help.

Regards,
~ Soumen

 

[Barry]

For one of my project, I want to use auto_ptr. But I'm facing few
issues.

1. Say I've Controller class. I don't want to allow user to create
object of this class unless all arguments
are valid. So I've made the constructor private and given one
static method to create an object of this
class. Since one of senior members in the team doesn't like
throwing exception, I've made this static
method to return NULL pointer when arguments are not valid. But
that stops using auto_ptr since it
cannot accept NULL, I guess. Is there any better way to do this?

No, it accepts
as auto_ptr has a constructor
explicit auto_ptr(X* p =0) throw();

and you can call "get()" to test if the underlying pointer is null or not.

2. Now, I've a Cache class in which few members are auto_ptr. Those
basically some pointer to few

why dynamic allocating map/set here?
why not just use map/set as member?
I think you only need to use pointer as template argument for set/map.

STL type map or set etc. Now users of this Cache class needs read
access to these data. Is returning
a const reference a good idea? Returning the member itself will
cause transfer of ownership and I guess

returning a pointer is not a good idea since the user has control
of destroying the object pointed by it.

you can't avoid everyone to do a evil thing with a programming language.
One can also delete a pointer taken from the const reference as well.


if reference satisfies your need, mainly you never return a null pointer
to represent a failure, then returning a const reference of Type is fine.

But I guess a Cache can't guarantee that every query operation will success.

 

[Yannick Tremblay]

For one of my project, I want to use auto_ptr. But I'm facing few
issues.

1. Say I've Controller class. I don't want to allow user to create
object of this class unless all arguments
are valid. So I've made the constructor private and given one
static method to create an object of this
class. Since one of senior members in the team doesn't like
throwing exception, I've made this static
method to return NULL pointer when arguments are not valid. But
that stops using auto_ptr since it
cannot accept NULL, I guess. Is there any better way to do this?

Yes, obviously there is a better way: use exceptions.
Do you think the "senior member" might need to update himself maybe? :-(
Does the "senior member" realises that if current C++ is used,
exceptions can be thrown by new or any C++ standard library utility so
regardless if you are actually explicitly throwing exception in your
code, you still need to program in an exception safe way and catch any
exceptions thrown by the standard library?
Does the "senior member" realises that since you have to handle
exceptions anyway, you may as well use them in your code too rather
than have a duplicate error mechanism of exceptions _and_ error return
code (even worse error magic return value) and as such have the worse
of both world.

Obviously, there are some particular situations where exceptions might
be undesirable. In that case, there should be no exceptions whatsoever
in the system and only a subset of C++ with no exceptions at all
should be used. But most of the time, peoples that "don't like
throwing exceptions" are in deep need of retraining and are bad
mentors for junior programmers.

2. Now, I've a Cache class in which few members are auto_ptr. Those
basically some pointer to few
STL type map or set etc. Now users of this Cache class needs read
access to these data. Is returning
a const reference a good idea? Returning the member itself will
cause transfer of ownership and I guess
returning a pointer is not a good idea since the user has control
of destroying the object pointed by it.

Assuming:

Cache
{
private:
std::auto_ptr<std::map<key_t, value_t> > m_theMap;
}

This is quite possibly a Java-ism that could be better rewritten most
of the time as:

Cache
{
private:
std::map<key_t, value_t> m_theMap;
}

Unless you can give a good justification for using the first form, use
the second form.

The second thing you mention is getting access to this data. It
sounds as if you are thinking of:

Cache
{
public:
std::map<key_t, value_t> const & getInternatMapAccess()
{ return m_theMap; };
private:
std::map<key_t, value_t> m_theMap;
}

and expect the client to directly query the std::map

A much better encapsulation would be to provide a querying interface
to your cache e.g.:

Cache
{
public:
value_t query(key_t key); // use const & if copying is expensive
private:
std::map<key_t, value_t> m_theMap;
}

This way, your client is isolated of the Cache implementation. You
could use a std::map, std::set or external SQL database for your data
and the client wouldn't care. It also eliminates your problem since
by not giving access to your internal to a client, the client can't
mess with your internals.

Yan

 

[Andre Kostur]

(e-mail address removed) (Yannick Tremblay) wrote in


Why can't auto_ptr accept NULL?

 

[Soumen]

Thanks to all for the responses. Sorry, I did a mistake that it
doesn't accept
NULL. Since I cannot use exception, I need to use return NULL in case
of error
and get() method to check against NULL.

Yes, obviously there is a better way: use exceptions.
Do you think the "senior member" might need to update himself maybe? :-(
Does the "senior member" realises that if current C++ is used,
exceptions can be thrown by new or any C++ standard library utility so
regardless if you are actually explicitly throwing exception in your
code, you still need to program in an exception safe way and catch any
exceptions thrown by the standard library?
Does the "senior member" realises that since you have to handle
exceptions anyway, you may as well use them in your code too rather
than have a duplicate error mechanism of exceptions _and_ error return
code (even worse error magic return value) and as such have the worse
of both world.

Obviously, there are some particular situations where exceptions might
be undesirable. In that case, there should be no exceptions whatsoever
in the system and only a subset of C++ with no exceptions at all
should be used. But most of the time, peoples that "don't like
throwing exceptions" are in deep need of retraining and are bad
mentors for junior programmers.


Assuming:

Cache
{
private:
std::auto_ptr<std::map<key_t, value_t> > m_theMap;

}

This is quite possibly a Java-ism that could be better rewritten most
of the time as:

Cache
{
private:
std::map<key_t, value_t> m_theMap;

}

Unless you can give a good justification for using the first form, use
the second form.

The second thing you mention is getting access to this data. It
sounds as if you are thinking of:

Cache
{
public:
std::map<key_t, value_t> const & getInternatMapAccess()
{ return m_theMap; };
private:
std::map<key_t, value_t> m_theMap;

}

and expect the client to directly query the std::map

Actually, I've set and a map. User would iterate over the set
and do find on map (set will have more entries than the map).
I need to return const reference of set and have a member
method to find on map.

 

[Yannick Tremblay]

Actually, I've set and a map. User would iterate over the set
and do find on map (set will have more entries than the map).
I need to return const reference of set and have a member
method to find on map.

I am not sure about this design. I don't clearly understand what you
are storing in your cache and how it is to be used by the clients but
it seems to me that the fact that you happen to have a set and a map
is more of a Cache implementation issues than a thing that is relevant
to the interface.

Is this relevant to the client that it needs to iterate over the set
for the actual task the client wants to achieve or couldn't you
simplify it to "the client wants the next value" e.g.:

Interface:
value_t getNextValue();

Implementation:
Iterate over the set
get the value from the map



Yan