|
Going through an adjustment period as I have just "upgraded" from Visual Studio 6 to Visual Studio 2005. I am having a few problems adjusting, although they are not so serious. I have, however, just discovered that a managed class (ie: declared as:
<code>ref class CMyClass</code>
cannot apparently have any friend classes. I assume therefore that if I want to work with inheritance I should avoid use of managed classes, correct? Or is there a way to access the protected members of a managed class? If not, then what is the advantage of a managed class in C++? I realize they are created on a garbage collected stack, but if inheritance cannot be used aren't we sacrificing alot of the functionality and power of C++? Yes, I know I can just declare my classes as unmanaged, but I am curious as to the answers to the above questions.
Thanks.
Windows with no internet connection is safe, but that's not what Windows was built for.
|
|
|
|
|
The Apocalyptic Teacup wrote: I assume therefore that if I want to work with inheritance I should avoid use of managed classes, correct?
Inheritance has nothing to do with friend classes. But, yes, the .NET framework does not support friend classes. Which sucks.
The Apocalyptic Teacup wrote: Or is there a way to access the protected members of a managed class?
Yes, derive your classes from them ( inheritance ). Or, put the classes that work together in an assembly and use 'internal'
The Apocalyptic Teacup wrote: If not, then what is the advantage of a managed class in C++?
The fact that it can use the .NET framework
The Apocalyptic Teacup wrote: but if inheritance cannot be used
Just not true
The Apocalyptic Teacup wrote: aren't we sacrificing alot of the functionality and power of C++?
The whole point of C++/CLI is that you can access the power of C++, things like templates ( no, generics suck and do not count ) and the STL are available to you.
The Apocalyptic Teacup wrote: Yes, I know I can just declare my classes as unmanaged
You probably should, if you can, it means you don't rely on the framework. Why add baggage if you don't need it ?
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: Inheritance has nothing to do with friend classes. But, yes, the .NET framework does not support friend classes. Which sucks.
Yes, okay true. Re-reading my post I see I worded that very badly. Anyways, I had a nice class all written up with protected member functions, etc... it was great and then I tried to derive a class (declared as friend) from it and - wow - the compiler errors. Do you have any idea why friend classes can't be used? Do they interfere with the garbage collection?
Windows with no internet connection is safe, but that's not what Windows was built for.
|
|
|
|
|
The Apocalyptic Teacup wrote: then I tried to derive a class (declared as friend)
Why would you declare a derived class as a friend ?
The Apocalyptic Teacup wrote: Do you have any idea why friend classes can't be used?
Because the .NET teams always seem to go for the 'lite' implimentation.
The Apocalyptic Teacup wrote: Do they interfere with the garbage collection?
I don't see how that's possible.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: Why would you declare a derived class as a friend ?
OMG I'm tired. I meant I declared a friend class an instantiated it. 
Windows with no internet connection is safe, but that's not what Windows was built for.
|
|
|
|
|
*grin* OK. Just making sure we're on th same page.
Basically, with .NET, they always try to make the language easy. friend classes are probably too hard, when the idea of allowing fall through in switch statements is completely impossible. I wonder if C++/CLI allows const methods, because C# and VB do not.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: I wonder if C++/CLI allows const methods,
Sure, as long as you don't declare them with the const keyword 
Direct quote from my output window...
"'const' and 'volatile' qualifiers on member functions of managed types are not supported"
|
|
|
|
|
Christian Graus wrote: *grin* OK. Just making sure we're on th same page.
Actually, I don't know what page I'm on anymore. Originally I was asked to write this code in VBA under Excel so that "others could use it easily". When I protested about how it would be excruciatingly slow (it's computationally intensive) nobody listened. But I coded it in VBA as requested.
After I coded it and it was shown to be excruciatingly slow they suggested Matlab. Again, I protested (Matlab is interpreted to). Nonetheless I coded it in Matlab. Again, painfully slow - actually worse than in VBA.
Finally I got my way and was invited to code it in C++. In a demonstration of my original point, one calculation went from 90 minutes under VBA to 6 minutes in C++. I started writing it in VS6 until it was suggested we "upgrade" to Visual Studio 2005. I was happty about being able to write it in c++, but this managed code stuff, well, I just don't know about this. Anyways, it's been a learning experience up to now.
Windows with no internet connection is safe, but that's not what Windows was built for.
|
|
|
|
|
Well, you don't have to use managed code, you shouldn't unless you specifically need it.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
This actually belongs in the C++/CLI forum ( you threw me, I actually told a few people they were in the C++/CLI forum  )
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: This actually belongs in the C++/CLI forum ( you threw me, I actually told a few people they were in the C++/CLI forum
Shows how much I know about CLI! 
Windows with no internet connection is safe, but that's not what Windows was built for.
|
|
|
|
|
In addition to Christian's excellent reply...
You also can't use multiple inheritance.
There's ways around all of it though, for the most part.
Access to protected members can be done through properties. From an OOP purist (I am not) point
of view, friend classes are probably a kludge anyway
You can't derive from multiple classes but you can derive from multiple interfaces.
Anyway, just because it's there doesn't mean you have to use it. If you're not using the .NET
framework then certainly don't use managed classes or even compile to CLR.
I personally use C++ for almost everything and managed C++ only for access to features of the
.NET framework, controlling compilation with #pragma managed/#pragma unmanaged.
Mark
|
|
|
|
|
Mark Salsbery wrote: friend classes are probably a kludge anyway
A little. But, making a property public throws away encapsulation entirely.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: A little. But, making a property public throws away encapsulation entirely.
How does that differ from using friend?
(I'm not arguing Like I said I'm no purist and I have some friend classes in my code. Just
enquiring for my own knowledge)
Mark
|
|
|
|
|
Mark Salsbery wrote: How does that differ from using friend?
I can decide who my friends are, and with whom I share things that are private. If I make those things public, then anyone has access to them.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Gotcha, thanks 
|
|
|
|
|
I guess with friend there's more control with granting specific access, where with a property
there's none.
Mark
|
|
|
|
|
Yes, exactly.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
The Apocalyptic Teacup wrote: If not, then what is the advantage of a managed class in C++?
C++/CLI is not really C++; it is a new programming language that targets .NET platform and aims to be backward compatible with C++.
|
|
|
|
|
Managed C++ (or C++/CLI as it's called in VC2005) isn't something you just tack onto an existing project. You should redo the code as managed only if you intend to make use of the BCL or want your code to be usable by other managed apps.
|
|
|
|
|
hi
is it posible that i can use an diectshow graph inside an dll ?
so i want to call this dll ofer an com interface .
the output of the filter is only a file.
with kind regards enrico hofmann
|
|
|
|
|
gigo2k6 wrote: is it posible that i can use an diectshow graph inside an dll ?
Why not?
gigo2k6 wrote: o i want to call this dll ofer an com interface .
If you want to create a COM object in-process (a COM DLL), then why not?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
ahh ok / is there a good manual for creating a dll for com on c++ ?
i also prefer german language if available, but english is also ok...
with kind regards enrico hofmann
|
|
|
|
|
gigo2k6 wrote: ahh ok / is there a good manual for creating a dll for com on c++ ?
Of course there are a lot (but I don't know them...)
When building a COM DLL, basically you have three ways:
(1) Using MFC COM support. This maybe the 'easyest way' (AFAIK Jeff Prosise's "Programming Windows With MFC" contains an introduction about, maybe enough...)
(2) Using ATL. This is a bit lower level, but it is also lighter and gives you (at least in my opinion) more power. About the argument I remember only Shepherd G., King B., "Inside ATL" a quite advanced book (Anyway using the ATL COM Wizard of Visual Studio it's strighforward).
(3) Handcrafting your COM component: there is a beatyful article series, written by Jeff Glatt, here at CodeProject, starting with [^].
hope that helps
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
If I programmatically create a CListCtrl in report mode (or derived class) without the WS_VISIBLE attribute, it blows chunks trying to init a header for it.
It blows when, during my header init, I try to delete any old header columns that might be there already. The header init is in a separate DLL, if that matters. Here's the line of code that blows:
int nColumnCount = pList->GetHeaderCtrl()->GetItemCount();
Any clues as to why this happens, or a workaround?
Thanx.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
