|
mmontagne wrote: if they are still forced to cast when our code creates instances of MyClassDescendants for them.
I don't understand. If you have a factory that returns a "base" class how do you access extended attributes of the derived type without casting to the derived type?
led mike
|
|
|
|
|
That's the way it works with Delphi/CPPB class references -- which is desirable for the purposes, and what I'm hoping to emulate/replicate in managed C++.
When you assign the class identifier (name) of a derived class to a class reference and pass the class reference to a factory method, it calls the constructor of the derived class and constructs an instance of the derived class which does not have to be cast. Of course, as the derived class inherits the members of the base class, it is also safe to call the methods of the base class in the derived class instances.
So this capability is exceedingly simple and clean. All you have to do is declare a class reference type, and variables/arguments of this class reference type. The class names/identifiers of the base type and all of its descendants are legal values to assign to the class reference variables or arguments. Your factory method simply takes a class reference and calls the proper constructor.
So for instance (in Delphi syntax), here is one valuable way to implement class references in a factory object:
MyBaseClassReferenceType = class of MyBaseClass; // Type/class definition (complete).
// The following is a field declared in TMyFactoryObject base class, which orients all (similar) methods to any focused FactoryCreationClass descendant:
FFactoryCreationClass: MyBaseClassReferenceType; // Member variable/field. In Delphi, instance types are declared after a colon, which is preceded by the reference (pointer) name.
// "class" methods are roughly the equivalent of static functions of C++. This one "class"/static method instance thus is shared by all TMyFactoryObject instances and descendants, but returns the desired, constructed FactoryCreationClass instance to the calling TMyFactoryObject (as intended):
class function TMyFactoryObject.CreateBaseOrAnyDescendantFactory(TMyFactoryObject: FactoryObjectInstance): MyBaseClassReferenceType; // Return types, in Delphi, are declared after the method signature.
begin
Result := FactoryObjectInstance.FFactoryCreationClass.CommonConstructorName(ArgumentsRequiredByFactoryCreationClass);
end;
This of course is powerful, fast (it's all inherently pointer based), and produces exceedingly light footprints.
So, I understand why you would ask the question, as this does not fit cleanly within the pattern of ANSI C++, because when we call the constructor of the base class name (which has a different identifer/name, versus the shared name of overridden constructors in Delphi) this will only create the parts of the base class. Here, what's happening is the constructor of the intended descendant is indeed called (which inherits the same name, "Create", of the constructor of the base). The nomenclature indicates this descendant constructor (or the base constructor, if the base class is assigned to FFactoryCreationClass). Thus, a descendant instance is returned which does not require casting.
Hmmmm... now that we think of it, probably this ambiguous identification of the necessary constructor explains the need for said Activator class, eh?
-- modified at 16:01 Friday 29th September, 2006
|
|
|
|
|
mmontagne wrote: When you assign the class identifier (name) of a derived class to a class reference and pass the class reference to a factory method, it calls the constructor of the derived class and constructs an instance of the derived class which does not have to be cast.
That sounds like you're asking for a "virtual constuctor", which does not exist in C++. The types of objects being constructed have to be known at compile time. Google for "virtual constuctor" and you'll see some ways of hand-rolling this.
|
|
|
|
|
Thanks Mike,
However, it's not really, simply a virtual constructor issue, even in Delphi or C++ Builder.
I'm aware both that we have no virtual constructors, and that we cannot call virtual methods from constructors. The nature of the constructors is not really the issue. The real issue is identifying the proper constructor of an unknown class from its class identifier. Here's the bare gist of what we need to do, expressed a bit differently:
We have a control which parents further controls of different types. Clients may populate this control with one type, with many types, and even with their own custom descendants of our base child types. Our root, composite component generates instances of these children, manages the spatial distribution and focusing of the children, routes calls to the focused child, and automates their destruction.
Clients/users may want to descend from the basic types which the original control manages; and we must also provide means for them to elect to create any one particular type (at a time) of the basic types which the control manages. This capability must be supported even at design time, in the development environment.
Because we cannot know what yet-to-exist descendants the clients of our control suite may derive from our base child classes, the necessary solution parallels our Delphi implementation, where the client can pass their class identifier (class reference) to our root control, from which our root control can identify and call the proper constructor of their descendant. Editors allow them to do this at design time, so that they do not even have to install their class/components in the IDE (which eliminates substantial work and technical difficulty for them).
The critical issue therefore is that we have to link a class identifier to the proper constructor for child classes which may not even exist at the time we produce our root component. Presently, we use a real class identifier (Delphi/CPPB "Class Reference") which is intrinsically associated with the constructor of the class; because, in Delphi/CPPB, we can call the proper constructor directly, because *it is* the default constructor of the class identifier.
But you have me thinking here. I suppose we could take a string identifier and constructor fields of a struct as our former argument, thus explicitly identifying the constructor to call -- although I don't know what issues might exist for supporting this valuable behavior at design time in VS. In other words, how would we store handles of constructors of client descendants in a collection property, so that they could be called at run time or design time?
|
|
|
|
|
PS.
All this (except how to store or manage class identifier *properties*) may be moot however, if the Activator class provides the needed services.
|
|
|
|
|
mmontagne wrote: But again, thanks for the starting point (which may be much more than that).
You're very welcome. Have you thought about combining the code above with a template to hide the cast and present a nice interface to users of your code?
|
|
|
|
|
Good suggestion. I'm not sure the Activator needs to be handled that way, but in either case, if there is an opportunity to build a generic/template, that is certainly how to approach this.
Where we are really stuck for the moment (we're new to VS) is component development references. We have a book on order, but have some steep issues which require that we know much more about classes and how their properties are registered/supported in the IDE than we're finding bundled/linked documentation for. Any suggestions for top quality references appreciated. The book we're looking at is "Programming .NET Components, 2nd Edition," by Juval Lowy. It's C# oriented, but we're hoping that the approaches/examples will be conducive to managed C++, if that will be preferrable for us. Otherwise, we'll have to look at doing these projects in C#. For the moment (until this book gets here and we have it under our belt), things are on hold.
Actually, we're doing a final release build in Delphi as we get ready for a serious VS push.
|
|
|
|
|
mike montagne wrote: Otherwise, we'll have to look at doing these projects in C#.
I dont see a huge advantage in managed c++ over c#. We have a lot of unmanaged c++ code that we would like to use from c# clients so I have been investigating using managed c++ to make wrapper classes for our existing libraries. It looks like we're going to go down this path and my next big challenge is to see how much of this we can generate.
Unless you think you can reuse a lot of the code from your Delhpi perhaps c# would be a good option.
I dont have any specific book recomendations. I would look for something that addresses the run time more than a particular language.
|
|
|
|
|
Thanks much for the advice. We're trying to weigh all this with an open mind. One thing we have been interested in (for our own style of doing things) is being able to run native code. That's a C++ thing. But if we can run C# components in native C++ implementations, the broad acceptance of C# as a more expedient tool has major influence on our own disposition. I suppose this book is going to be a hinge point.
|
|
|
|
|
I have a class that implements System::Collections::Generic::IEnumerable<> interface. System::Collections::Generic::IEnumerable<> is derived from System::Collections::IEnumerable and both have a pure virtual method called GetEnumerator() but with different return types.
To over come the "overloaded function differs only by return type" error I used an 'explicit override' as described in the documentation. The code looks like this....
virtual System::Collections::Generic::IEnumerator<OptiverAu::VaultDotNet::TradeDelta^>^ GetEnumerator()
{
//to be implemented
return nullptr;
}
//note the '= blah blah' (this is the expicit override)
virtual System::Collections::IEnumerator ^ GetEnumeratorNG() sealed = System::Collections::IEnumerable::GetEnumerator
{
return GetEnumerator();
}
Seems a wierd way of doing things but it works. Now I want to write a class that implements the System::Collections::Generic::IEnumerator<> generic interface to be returned from the GetEnumerator() function above
System::Collections::Generic::IEnumerator is derived from System::Collections::IEnumerator in the same way as the example above. Both have a 'pure virtual' property called Current but with different return types.
What is the syntax for an explicit override of a property? I have spent an entire day searching and cant find the answer anywhere.
|
|
|
|
|
You override the get and set and not the property itself
interface class IFoo
{
property int Count
{
int get();
void set(int);
}
};
ref class Foo : IFoo
{
public:
Foo() : m_count(1) {}
property int Size
{
virtual int get() = IFoo::Count::get
{
return m_count;
}
virtual void set(int value) = IFoo::Count::set
{
m_count = value;
}
}
private:
int m_count;
};
|
|
|
|
|
Thanks you VERY much. I tried just about every combination except renaming the property and putting the expicit override on the get() & set().
|
|
|
|
|
Hello,
How to call CoGetInterfaceAndReleaseStream(…) in a secondary thread in managed VC++.NET 2003 application? I can successfully call CoMarshalInterThreadInterfaceInStream(…) in the main thread. After that in the secondary thread I call CoInitialize(NULL) with S_OK result, but CoGetInterfaceAndReleaseStream(…) returns -2147352568 error code.
Please help!!!!!!!!
Regards,
Leonid
|
|
|
|
|
Hi friends,
Can anyone tell me what will be the output of the folloing code and whats the reason for that.
It will be a great help.
<br />
int x = 12;<br />
int y = 6;<br />
x = x++ + y++<br />
cout<<x<<endl<<y;<br />
can you tell me the output for C++ and Java compiler and whats the reason for the answer.
Thanks in Advance
Sushant Duggal.
|
|
|
|
|
Sushant Duggal wrote: can you tell me the output for C++ and Java compiler and whats the reason for the answer.
Yes I can... but then I would be doing your class assignment for you. 
led mike
|
|
|
|
|
Sushant Duggal wrote: cout<<x<<endl<<y;< blockquote="">
This code is making some assumptions that are now being shown for it to compile as C++. It's not going to compile for Java.
Beyond that, I agree with the other reply, you need to do your own homework.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Thanks for your reply friends,
But I just want to know the reason why the outputs differ.
i
In C++, The result is x=18.y=7
where as in Java, The result is x=19, and y=7
I want to know the reason for this output.
Is there a difference of stack implementation in the two languages or there is some other reason..
Please let me know.
Thanks,
Sushant Duggal.
|
|
|
|
|
++x guarentees that the number is incremented before it's returned. x++ guarentees it's incremented after, but not how LONG after.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Yes, I agree on your comment.
so do you want to say that there is no method to determine the value?
Sushant Duggal.
|
|
|
|
|
OK
now i got the point.
its correct to get 19 in C++,
but I still didnt understand why it comes 18 in java.
Can you comment on this?
Thanks
Sushant Duggal.
|
|
|
|
|
I believe it goes like this:
The ++ operator occurs in both languages AFTER x is given it's final value. The difference is that in Java, the values are by reference, so the value that x is assigned to, is the value that still has a ++ operator outstanding. so, x gets set to 18. y gets incremented, to 7, and x also gets incremented, but it's the same x that is 18, not a copy of x which is 16.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Oh - you also posted in the wrong forum, I didn't notice before.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Then where I would have posted this?
Sushant Duggal.
|
|
|
|
|
Managed C++/CLI is the forum for discussion of .NET C++, as it clearly states. This[^] is the general C++ forum.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
The ++ operator occurs in both languages AFTER x is given it's final <BR>value. The difference is that in Java, the values are by reference, so <BR>the value that x is assigned to, is the value that still has a ++ operator outstanding. so, x gets set to 18. y gets incremented, to 7,<BR> and x also gets incremented, but it's the same x that is 18, not a <BR>copy of x which is 16.
I can understand that in java, the values are by reference. that means X is incremented direectly where it is stored, it sets it to 12 + 6 = 18.
Confusion ..... when the X is going to incremented? and why it is not reflected(X's value is still 18).
Thanks For your Patience,
Sushant Duggal.
-- modified at 3:39 Thursday 28th September, 2006
Sushant Duggal.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
