|
Hey Edward,
I believe this is due to a compiler bug. I've just blogged about it here and have also referenced this thread :
C++/CLI bug : Operator overloading in an interface[^]
You can workaround it for now by directly calling the operator :
int amt = Base::operator * (d);
I've reported it to the VC++ team - and if they acknowledge that it is a bug and not by design, I'll open a Connect bug for it.
|
|
|
|
|
Interesting enough one can not even create an operator for an interface in C#. I have suggested to Microsoft that one should be allowed to create an operator for an interface in C# also. In fact in C# one can not create any static members for an interface.
You can view my suggestion at https://connect.microsoft.com/VisualStudio/feedback/details/536835/allow-operators-for-an-interface-in-c[^].
Thanks for reporting this to the VC++ team, especially since if I reported the bug myself Microsoft would have definitely issued "Will not fix" after admitting it is a bug whereas once somebody else reports it there is a faint chance that they will consider fixing it for the 2010 release or beyond.Edward Diener
|
|
|
|
|
Well considering that C# does not permit static methods in interfaces, it would be quite unlikely that they'd permit operator overloading which requires static methods. Some people were hopeful that since C# now supports extension methods, this would be enhanced to support extension operators but apparently that did not happen for VS 2010. Would have been neat. Oh well.
Btw, if you really need to overload the * unary operator, C# does not permit that either, so you'd either have to wait for C++/CLI to get fixed or code it in an msil assembly (assuming you need it that badly) 
|
|
|
|
|
Obviously C# should allow static data, methods, properties, and events in interfaces. But that is not my problem if I code in C++/CLI.
I could substitute another operator which C# does permit in place of the * unary operator. I am not worried about that. I am thinking of using an explicit cast operator for C# compatibility in areas where I would normally use the * unary operator while also keeping the * unary operator for C++/CLI programmers.Edward Diener
|
|
|
|
|
I saw that Wesley Yao has answered you in the MSDN thread. I am not 100% in agreement with the behavior though. Operators are implemented via static methods in .NET and thus for operators, name lookup should (in my opinion) be extended to look up all the way to the base interface (if any). Anyway we at least know now that it is not an official bug and is by design
|
|
|
|
|
Interesting discussion.
BTW, What is the benefit of allowing static methods in an interface? I couldn't think about any good reason of having static methods in an interface.
Nishant Sivakumar wrote: Operators are implemented via static methods in .NET and thus for operators, name lookup should (in my opinion) be extended to look up all the way to the base interface (if any).
Correct. It is happening currently if base type is a class. As I said, I don't know why they allow static member functions in an interface which is making all these confusion.
Best wishes,
Navaneeth
|
|
|
|
|
Edward Diener wrote: Obviously C# should allow static data, methods, properties, and events in interfaces.
Why do you think allowing static members on an interface is required?Best wishes,
Navaneeth
|
|
|
|
|
In order to code operators for an interface.
In dotNet all operators must be static methods in order to be CLS compliant.
There is no reason interfaces should not have operators just like classes do. If I have some functionality written in terms of interfaces, why should I not be allowed to use operators, where appropriate, instead of member functions ? Here is a simple, trivial example in C++/CLI:
interface class MultiplyTwoIntegers
{
int Multiply(int);
static int operator * (MultiplyTwoIntegers ^ first, MultiplyTwoIntegers ^ second) { return(first -> Multiply(second));
};
ref class MyInteger : MultiplyTwoIntegers
{
// Some functionality...
int Multiply(int other)
{
// ... some functionality return an int
}
}
int DoTheMultiplyAmongOtherThings(MultiplyTwoIntegers ^ one, MultiplyTwoIntegers ^ two)
{
int result(one * two);
// Some processing ...
return result;
}
// Somewhere else we have this code
MyInteger ^ my1(gcnew MyInteger);
MyInteger ^ my2(gcnew MyInteger);
int result(DoTheMultiplyAmongOtherThings(my1,my2));
As I said this is a trivial example but in real world programming much functionality can be created based on interfaces being passed to functionality and operating on those interfaces. Allowing operators for interfaces makes the syntax much nicer than if they are not allowed. This should be no different from classes. In C++/CLI one can code the above without error, since interface operators are allowed. In C# interface operators are not allowed, nor are any static functions, properties, or events for an interface.Edward Diener
|
|
|
|
|
Edward Diener wrote: There is no reason interfaces should not have operators just like classes do.
I agree if .NET allows operator overloads as non-static methods. Unfortunately, .NET requires operator methods to be static and having static members to be part of an interface doesn't make sense. Because interface methods are used through the instance variable and static members are not accessible through instance variable. This is the reason why .NET uses interfaces like IComparable, IEquatable etc to do operations where a operator overload could have made more sense.
Edward Diener wrote: Here is a simple, trivial example in C++/CLI:
If you don't care about your code to be used by other .NET languages, you can ensure the contract with the help of templates. Something like,
template<typename T>
int multiply(T first, T second)
{
return first * second;
}You can pass in any type that has got proper operator overloaded.
Best wishes,
Navaneeth
|
|
|
|
|
If static methods are not accesible through instance variables why do static operators work for class instances ? Your argument makes no sense because it is apparent that static operators work with class instances, so there is no reason why they should not work with interface variables instantiated from class instances. The fact that they do work with interface variables instantiated with class instances also shows that your argument is wrong BTW. Try it in C++/CLI and you will see that they do work as advertised.
The fact that C# does not allow what C++/CLI does allow does not bother me that much. I only wanted to have C# follow the CLI just as C++/CLI. Arguing that it can not work when clearly it does seems fruitless to me.
Somehow I think you are talking about C++/CLI as if it is just native C++. C++/CLI is a superset of C++ but it is not the same language. As far as using templates, I am very much aware of their capabilities but I am currently writing C++/CLI code to be used by other dotNet languages which means following the CLI standard as much as possible.Edward Diener
|
|
|
|
|
Edward Diener wrote: If static methods are not accesible through instance variables why do static operators work for class instances ?
That is a syntactic sugar. When compiler sees expression int result = first * second where first and second are instance variables of type Foo, it checks that operator overload is available and if it is available, this expression will be rewritten like int result = Foo.op_Multiply(first, second).
If you are interested why operator overloads are static, take a look at what Eric Lippert says[^].
Edward Diener wrote: Try it in C++/CLI and you will see that they do work as advertised.
What do you mean by that?
Edward Diener wrote: Somehow I think you are talking about C++/CLI as if it is just native C++
No. I know the difference quite well.
Best wishes,
Navaneeth
|
|
|
|
|
>> Try it in C++/CLI and you will see that they do work as advertised.
> What do you mean by that?
You can currently create a static operator in C++/CLI for an interface and use it when dealing with the interface. It does not have to be only a static operator for a class to work properly. Whether it is syntactic sugar or not means nothing to me as to whether it works or not. Unlike many people I view syntactic sugar as often very important and justified.Edward Diener
|
|
|
|
|
I want to write an application, that monitors a third party application, by examining the properties and values of those properties associated with that application's controls. For example, if the control is a button, I'd like to get a list of all it's properties and their values (e.g. if the button is enabled or disabled). If the application has a grid or spreadsheet component, I'd like to get the number of columns, rows, the column headers, and the values in the individual cells. I know how to get a window/control's text with GetWindowText, however; I need much more info than that.
Can this be done? The internet searches I have done to date, (and I have searched other forums) have come up short. Can anyone give me advice/pointers or point me to resources to help me?
Thanks!Today's Beautiful Moments are
Tomorrow's Beautiful Memories
|
|
|
|
|
| The only suggestion I can offer is to check the type of control when you get a handle to it, and then use the other Win32 calls to check the different styles and states it is using. This will mean checking all the options for every type of control; a fairly tedious task. txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
This isn't really an answer for you, but on that other OS, system support for this kind of thing is in "Universal Access", which is a suite of tools for supporting people with disabilities. Are there similar facilities in Windows?
|
|
|
|
|
Ron Aldrich wrote: Are there similar facilities in Windows?
Not that I'm aware of. You could try searching Google to see if anyone else has come up with a solution.txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
I have a class in C++ (unmanaged) which I would like to place a wrapper around in managed (visual) C++ in order to create a dll which I can use in C# applications as a class library.
I'm having quite a bit of trouble getting this to work by following MSDN's article here:
http://msdn.microsoft.com/en-us/library/aa712961%28VS.71%29.aspx[^]
and was wondering if this is even possible in VS2008? If there's a tutorial showing how to do this I'd be greatly interested in seeing it.
Thanks for any help / advice
Gvanto
|
|
|
|
|
I've done this several times. If you have a specific question, I'd be glad to do what I can to help.
|
|
|
|
|
Hi Richard,
I'm just after an example of how to do it.
Came across this: Managing the Unmanaged Code[^]
In VS2008, what project do I need to create to get started in this?
Cheers
gvanto
|
|
|
|
|
You create a new C++ project (MFC allowable) and then once it's created, go into the project properties and enable CLR support.
Now your C++ project can mix managed and unmanaged code.
|
|
|
|
|
thanks Richard with some fiddling got it working!
pretty stoked, the possibilities are now endless
|
|
|
|
|
Hi,Im using WPF as C# dll in VC++.Im sending datas to the Listbox inthe third tabitem in a tabcontrol by using this coding.
void CToolTab::SendPresetmenu(CString menu)
{
FrameworkElement^ page;
String ^ msg = gcnew String( menu );
Globals1::gwpreset->AddPresetmenu(msg);
page = Globals1::gwpreset;
Globals1::gHwndSource->RootVisual = page;
}
By this code,wat happend is my entire tabcontrol becomes a third tab item.there is not other tabs .
If i commented those last two bolded line.Full tabcotrol appears correctly but the listbox doesnot contain text.
How can i do that?Anu
|
|
|
|
|
I created a c++ .net dll, in which I need to implement logging. I decided to go with Microsoft Enterprise Library's Logging.
Now, I am calling this dll from a COM application (I created a .tlb from the dll to use in the COM application), and the error I am getting is this:
Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
How can I get around this??
TIA
|
|
|
|
|
chana gibber wrote: Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
That is pretty straightforward. Is that file exist?Best wishes,
Navaneeth
|
|
|
|
|
yes, the file exists in the debug folder of my (c++) dll.
It did not get carried over to the debug folder of the COM exe.
What do I need to do with Microsoft's dll in order to get it running in my exe?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
