Chris M. Thomasson wrote:
<cp********@gma il.comwrote
> I have a local class inside a function template. I am able to wrap
any type in my local class. Is it legal C++? What type of class is
Local? Is it a class template or regular class?
<snipCode to define an abstract interface, and a function template
whose instantiations return pointers to dynamically allocated instances
of local classes implementing the interface. (Whew.) </snip>
You have memory leaks. BTW, excuse me for being so dense,
You're excused. ;)
but what
advantages does this technique have over something like:
struct foo_impl {
virtual ~foo_impl() = 0;
virtual void print() const = 0;
};
Boo. A class called foo_impl with only pure virtual methods is a
contradiction in terms.
typedef foo_impl const& foo;
Boo. A reference type whose name does not end in "ref" or "reference"
is a debugging mess waiting to happen. Just wait until some unwary
client tries to create a vector<foo>.
<snipCode that replaces the OP's local classes with instantiations of
a template that all derive from the common interfaces, and avoids the
OP's dynamic allocation by returning the instances by value (and
requiring the client code to bind those temporary instances to
const-references). </snip>
Boo to your deprecated use of static. And in what way is std::endl
superior to '\n'? If there's really a need to flush std::cout's buffer,
and if the code might run on a platform where '\n' doesn't cause that to
happen anyway, wouldn't it be clearer to call flush directly?
Furthermore, boo to main(void), which is in no way clearer than main().
Bravo to your replacement of dynamic allocation with automatic. Still,
your code does not achieve the same thing as the OP's:
(1) Your client can't call non-const methods of foo, whereas the OP's
client can. You've changed the interface's only method to be const, but
that changes the meaning, and breaks any subclasses not included in the
posted code.
(2) You can't treat pretend a reference is an object for anything other
than trivial use. You can't have collections of them, for example.
(3) You can't pass your wrappers any farther up the stack (in contrast
to the OP's pointers to free store). For example:
foo rewrap(int i) { return wrap(i); }
int main() {
// ok
foo f = wrap(5); f.print();
// run-time error: pure virtual method called
foo g = rewrap(5); g.print();
return 0;
}
(4) I foresee type-slicing problems. I'm not sure where they're hiding
yet, but I can smell them from here.
--
[ See
http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]
