Quote:
...disabling = operators, and so on. This is great and all, it doesn't hurt to be careful I guess, but it looks like his teachers insisted more on those mostly academic issues then for things that actually happen in the industry, such as buffer overflows.
The thing is, its almost trivial. For any class where there is doubt, just inherit from boost::noncopyable. If necessary, later on you can go back and implement the correct deep copying semantics. You can even write this tiny helper class yourself, so you don't need to depend on boost:
class noncopyable {protected: noncopyable(){}private: // deliberately private and unimplemented, don't copy me! noncopyable& operator =(const noncopyable &); noncopyable(const noncopyable &);};class Foo : noncopyable { // Now you only have to worry about getting the desctructor right};
Takes no time at all, and will catch errors. It is hardly some obscure acedemic principle here, all it takes is to accidentally pass Foo by value where a reference was intended - which is an easy mistake to make. The cost/benefit analysis clearly tips this into the realm of practical considerations.
I'd agree with you about non-explicit constructors, they've never been an issue for me and I consider worrying about them a little pedantic. As you said, maybe in a library API I might go the extra mile but not for internal classes.
Quote:
n any case, I wanted to present a way to work with multi-dimensional arrays without having to use the STL or boost, which is obviously not the favorite way to achieve it here.
I actually don't use boost::mutli_array for 2D arrays, I would find it inconvenient to use.
But I'd rather write the simple class I presented earlier (with the_edd's correction) than have to implement a destructor, etc. It works with copying if that is required, it has std::vector<>'s usual index checks too in debug mode. And later on, if profiling justifies it, I can re-implement using raw allocation if necessary.
Quote:
I don't believe it is so dangerous, but whatever.
I believe can see where you're coming from. In some code bases, by value copies are never done. I suspect that a copy by value of a non-trivial type would probably be as big a code smell to you as the lack of copying semantics is to us. You would just "see" it when you look at the code. I understand this feeling, I too have a number of subconscious checks that I make when running through code; one of them is uncommented deep copies of complex types.
