dascandy@gmail.com
10/18/2008 6:02:00 PM
On Oct 17, 1:34 pm, Stephen Horne <sh006d3...@blueyonder.co.uk> wrote:
> Presumably the newMock method is basically allocating some memory and
> casting a pointer?
Mostly that. It also includes a number of ugly structures that
determine, given a member function pointer, what its signature is,
which virtual function it is, they then instantiate a function using
templates for handling that member and put it in the right place.
It'll be open source when I get this bit working (or when I am sure
that it won't be working).
> The only reason I can think why this wouldn't work is if you don't
> know anything about the Interface class and therefore don't know which
> methods to implement. I guess, given the template parameter to the
> newMock method, this may well be the case - but it still seems
> strange.
Exactly. It's a generic mocking framework and the concept is that
given just a generic header, plus a call to the least of functions you
need to call / type, you can create a mock. So if in any way possible,
I want to prevent you from having to instantiate every class yourself.
For the cases where you have no (public) member variables it's pretty
easy since you can skip the constructor, when you have no pure
virtuals you can just call the constructor, but when you have both you
have to call it but can't... which you're likely to have in template
method classes and in classes with intelligent member variables (event
list members, property-wrapping members) that are meant to be public.
> I wouldn't be surprised if some distant future C++ standard provides
> sufficient reflection features for a template to identify and
> implement all pure virtuals for a given class, but I do mean *distant*
> future.
I very much doubt that from ever becoming true, especially as you
don't really need it all that much in code not like this.
> Failing the factory method option, I'm not sure there's even a
> constructor to call. I mean, yes, there may be some code waiting to be
> called from *another* constructor, but there's no way to access it
> that I know of, other than to define a derived non-abstract class.
I'm certain that the constructor for the base class is sufficient to
call to create the abstract class, and that the compiler can easily
generate it if you find some way of generating a call to it.
This far I'll handle this case in documentation that, if you have
member variables and pure virtuals, you have to create a subclass.
Since it's a minor use case it's a nuisance, but it would be so nice
to just wrap that bit of typing into one bit of complex code that
saves me tens or hundreds of classes later on.
Thanks for your insight!
Peter