base_from_member suggestions
I used base_from_member today for the first time. It got me out of a sticky situation, but I think it could use a few modifications. Since it is designed to be used as a base class but does not have any virtual functions, the copy constructor, assignment operator, and destructor should all be protected. Joe Gottman
"Joe Gottman" <jgottman@carolina.rr.com> wrote in message news:cmro5r$o56$1@sea.gmane.org...
I used base_from_member today for the first time. It got me out of a sticky situation, but I think it could use a few modifications. Since it is designed to be used as a base class but does not have any virtual functions, the copy constructor, assignment operator, and destructor should all be protected.
I seem to remember someone proposing something similar for std::unary_function ;-) The argument seems even weaker here: base_from_member is designed for private inheritance, so it's hard to see how it can be misused by clients of a derived class. There's one change I'd like to see: the constructors should take rvalue references ;-)
Joe Gottman
On 11/9/04 9:18 PM, "Jonathan Turkanis" <technews@kangaroologic.com> wrote:
"Joe Gottman" <jgottman@carolina.rr.com> wrote in message news:cmro5r$o56$1@sea.gmane.org...
I used base_from_member today for the first time. It got me out of a sticky situation, but I think it could use a few modifications. Since it is designed to be used as a base class but does not have any virtual functions, the copy constructor, assignment operator, and destructor should all be protected.
I seem to remember someone proposing something similar for std::unary_function ;-) The argument seems even weaker here: base_from_member is designed for private inheritance, so it's hard to see how it can be misused by clients of a derived class.
There's one change I'd like to see: the constructors should take rvalue references ;-)
But that would prevent lvalue references from ever being used. However, since we can't explicitly specify the template parameters for a templated constructor, could reference arguments (of either type) ever be used? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
"Daryle Walker" <darylew@hotmail.com> wrote in message news:BAY16-DAV11C01AF63D07C2AE25621DBFC10@phx.gbl...
On 11/9/04 9:18 PM, "Jonathan Turkanis" <technews@kangaroologic.com> wrote:
There's one change I'd like to see: the constructors should take rvalue references ;-)
But that would prevent lvalue references from ever being used.
I was kidding, of course, since we don't have rvalue references yet; but under the current proposal, the correct way to write forwarding functions would be to have all the functions parameters declared as rvalue references. (See http://tinyurl.com/62smc.)
However, since we can't explicitly specify the template parameters for a templated constructor, could reference arguments (of either type) ever be used?
Forwarding constructors which take arguments by reference should generally use const references. (See #2 of http://tinyurl.com/6enrw.) I wouldn't want to suggest that you switch to const references at this point, because I can't say it wouldn't break some existing code. (Someone else can probably say.) Jonathan
On 11/9/04 7:42 PM, "Joe Gottman" <jgottman@carolina.rr.com> wrote:
I used base_from_member today for the first time. It got me out of a sticky situation, but I think it could use a few modifications. Since it is designed to be used as a base class but does not have any virtual functions, the copy constructor, assignment operator, and destructor should all be protected.
Explicitly adding copying methods prevents BFM from being used with non-copy-able types. The implicit versions, including the possibility that they would be disabled, work just fine. The opportunities for abuse having those three methods public would have to involve the user not using the template as intended and then deliberately setting up a dangerous situation. (Why would you have a BFM pointer [to use for an inappropriate deletion] in the first place? BFM has no functionality besides its set-up duties.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
participants (3)
-
Daryle Walker -
Joe Gottman -
Jonathan Turkanis