|
Boost : |
From: Aleksey Gurtovoy (alexy_at_[hidden])
Date: 2001-07-07 22:44:29
Peter Dimov wrote:
> I disagree with the 'noncopyable' guideline. Here's why:
>
> * Deriving from noncopyable invokes warnings/remarks from
> MSVC and Intel C++.
So does the following definition:
struct something
{
something(int i) : i_(i) {}
int& i_;
};
[MSVC, warning level 4]
E:\depot\libs\something.cpp(6) : warning C4512: 'something' : assignment
operator could not be generated
E:\depot\libs\something.cpp(3) : see declaration of 'something'
This doesn't prevent you from using references as class members (where
appropriate), does it? ;)
> In order to suppress them, I have to
> declare the copy constructor and the assignment operator
> private, which defeats the purpose.
A better way to suppress them is to write "#pragma warning(disable: 4511
4512)" :). Personally, I think that the above warning is useless. You'll
find out that "assignment operator could not be generated" as soon as you
try to use one. Warning about it at the point of class definition is like
shouting "you can't walk into this door!" to every person who just happened
to walk down the corridor ;).
> * In order to derive from boost::noncopyable, I have to introduce a
> dependency on boost/utility.hpp. Since headers with such names tend to
> change frequently, this means frequent recompilations for no apparent
> reason.
This is a valid concern. In some sense, 'utility.hpp' is much like
'smart_ptr.hpp' header (and a few others) - they both need to be splitted.
This way those who don't care about unnecessary dependencies still could
include 'boost/utility.hpp', and others who do, could happily go with
'boost/utility/noncopyable.hpp'.
Hmm.. here is a link to the proposed update to the library -
http://groups.yahoo.com/group/boost/files/utility/. Basically, the new
directory structure looks like this:
boost/utility.hpp
boost/utility/checked_delete.hpp
boost/utility/next.hpp
boost/utility/noncopyable.hpp
boost/utility/tie.hpp
...
and the documentation and examples were updated to reflect these changes.
IMO, if we agree with these changes, cost of including
'boost/utility/noncopyable.hpp' header would become a non-issue. BTW, "Boost
Library reuse" page cities 'boost::noncopyable' as an "Example where another
boost component should certainly be used", see
http://www.boost.org/more/library_reuse.htm.
Aleksey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk