In article <7b************ *************** *******@s27g200 0prg.googlegrou ps.com>,
Soumen <so******@gmail .comwrote:
>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<s td::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_tm_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_tconst & getInternatMapA ccess()
{ return m_theMap; };
private:
std::map<key_t, value_tm_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_tm_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
