Re: Never ever use a raw pointer when a smart pointer can do the
same job
* James Kanze:
On Aug 20, 7:33 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* Noah Roberts:
Alf P. Steinbach wrote:
* Noah Roberts:
and there's the other case when you don't care but
sometime down the road someone decides that a subclass
should be returned rather than the one you're
constructing.
You don't. That's totally evil. You're *changing the
behavior* without changing the type, leaving client code
stranded with mysterious behavior change.
That's only true if one of two things is true:
* Your client code is depending on the private behavior of
the class instead of the advertised pre/post conditions.
* Your new sub object violates the advertized pre/post
conditions of the class it inherits from.
If the new class changes nothing wrt. client code, then there
is absolutely no reason to foist a replacement on the client
code.
Huh? The behavior can easily depend on various elements in the
external environment. Under X, for example, it is frequent to
support several look and feels, determined from an environment
variable, a configuration file or whatever. The immediate
client of the code doesn't know or care about the look and feel,
it wants a button. So your factory function returns a button
with the correct look and feel.
The button example is a bit misleading since there are other concerns that can
force a factory function. Still, there's nothing that prevents direct 'new' of a
class 'Button', where the look and feel can depend on configuration, say. In
fact I have a class 'PushButton' that does this, and it required no special
support from me to get it to do that: a factory function would just be more
code, no-purpose code, and anyway, is clearly not required.
For that matter, I use a similar strategy for handling
differences between Windows and Unix: for reading directories,
for example, if I'm under Unix, the necessary data is a DIR*,
under Windows, a WIN32_FIND_DATA, but neither appears in the
class definition the client sees.
Consider normal code, this from a Boost documentation example:
bool find_file( const path & dir_path, // in this directory,
const std::string & file_name, // search for this name,
path & path_found ) // placing path here if found
{
if ( !exists( dir_path ) ) return false;
directory_iterator end_itr; // default construction yields past-the-end
for ( directory_iterator itr( dir_path );
itr != end_itr;
++itr )
{
if ( is_directory(itr->status()) )
{
if ( find_file( itr->path(), file_name, path_found ) ) return true;
}
else if ( itr->leaf() == file_name ) // see below
{
path_found = itr->path();
return true;
}
}
return false;
}
Would you really have the 'directory_iterator' allocated by a factory function,
with the client code dealing with a pointer to the iterator, as Noah, and now (I
think inadvertently) you, argues that it should be, or that it's natural to do?
ool find_file( const path & dir_path, // in this directory,
const std::string & file_name, // search for this name,
path & path_found, // placing path here if found
const iter_factory& factory ) // platform-specific iterators
{
if ( !exists( dir_path ) ) return false;
directory_iterator::auto_ptr end_itr = factory.new_iter(); // past-the-end
for ( directory_iterator::auto_ptr itr = factory.new_iter( dir_path );
*itr != *end_itr;
++*itr )
{
if ( is_directory((*itr)->status()) )
{
if ( find_file( (*itr)->path(), file_name, path_found ) ) return true;
}
else if ( (*itr)->leaf() == file_name ) // see below
{
path_found = (*itr)->path();
return true;
}
}
return false;
}
I think not. ;-)
I thought you'd understand that from my comments, but I wasn't
clear enough.
So let me put it this way: *either* the new class is different
in some way that affects behavior, in which case you're
changing the behavior, or else it's not, in which case it's
not very smart to do a lot of work to replace the original.
You seem to be missing the difference between contractual
behavior, and implementation behavior.
I don't think that *I* have given that impression.
Cheers,
- Alf