C# and mfc

[Jprisco]

Im just wondering if you will be able to use mfc in c#.. Im pretty new to programming and have been studying mfc. this is something Ive heard next to nothing about and id like to know as soon as possible if i am wasting my time at this point as I will probably start learning c# as soon as a compiler is available...

52901368

You are definitely wasting your time on MFC. It junky old stuff. Concentrate on new stuff like C# or Java.

[Dinu]

But C# is based on MFC library, or am I wrong?

Dinu Sco*****

[thegios]

No, u're not wrong. And NO, it's not a waste of time learning MFC: it's the must if wanna develop in win32 env (assuming u're not developing in VB). More, C# uses MFC and VB components: C# does not have its own class library so you will be using the VB and VC++ libraries.

I've seen things u ppl couldn't believe...

C# does not use MFC and VB components... it has the "ability" to use those libraries/components. And no, it is not built on top of MFC as one of the previous posters stated/asked.

[ALM]

I believe you're wrong. Where did you read or hear that?

As far as what I've read, C# will have access to a new "Common Language Subset" library which will also be available to C++ and VB.

Regards,
Alvaro

So then its safe to say that you can use normal class libs currently used in vc++ (MFC,ATL) in this new c#???

[jfergason]

I'm pretty sure that you will be able to use mfc in your C# programs. Although I wouldn't recommend learning C# as it is essentially a subset of C++ but more restrictive in the fact that it binds you to the Windows Operating Environment.

[Jprisco]

Thats a very good point that I kind hace overlooked.....Does this mean that C# will only be usefull on the windows platform???
Another question is how valueable is it to be able to program for different platforms...
Im still new to programming and hoping one day to get into the field I need to know what is most important , or valuable things to know /study
I appreciate the great reponse and the info that you have all provided....
J.Prisco

52901368

When I was an undergraduate at SDSU (San Diego State University) they taught C++. After 4 years I return for some Masters classes and now Java has taken the place of C++. Right now I would say Java is a sure bet for at least the next few years to come. Take a look at the want ads in many of the hot programmers areas such as Silicon Valley, Dallas, Austin, etc and you'll see a lot of companies asking for Java programmers.

Certainly not. You connot use MFC and especialy ATL or WTL with C# cause it does NOT support many features used in this libraries. With C# you can ONLY use COM-ojects like in VB.

[aamirdogar]

How do u say that it is only for windows.

thing is that it is portable and when u can port some code then where does the dependencies comes in.

Aamir

So what is knowlege of mfc or atl good for outside of c++??

[Karmus]

Im just wondering if you will be able to use mfc in c#.. Im pretty new to programming and have been studying mfc. this is something Ive heard next to nothing about and id like to know as soon as possible if i am wasting my time at this point as I will probably start learning c# as soon as a compiler is available...


I'm pretty sure you are confused right now, so I'll try to clarify some things.

First, C# is not tied in to the Windows environment. Why? C# was submitted to ECMA, an standards committee, by Microsoft. C# will be a subset of C++, like C++ is a subset of C. So anything like MFC or Win32 functions *should* work when using a MS C# compiler.

Second, MFC is just an encapsulation of the Win32 API. The Win32 API is just a set of functions itself, not defined as the libraries to C#, therefore it's incorrect to say that MFC and Win32 is a standard library of C#. In fact, the API's themselves are just functions of C code and assembly language.

The purpose of C# is to create an extension to current C++ standards, enabling programmers to do more things or make things easier.

Yes, C# can work cross-platform if you conform to future C# standards (and standard libraries) set by ECMA. You will need to just recompile codes on other platforms, just like C and C++. Of course, if you use Win32 API functions (or COM, or MFC, etc.), it is not cross-platform compatible. :)

One word of advice, you may want to try to learn Win32 API first before MFC. Why? You'll figure that a lot more things you need to do will require the API functions, in addition to MFC, which is just an encapsulation of it. Of course, if you are not really interested on what goes on inside of MFC, you can just learn MFC.

Frank

[ravish]

May be just the programming experience of C++. I dont think in anyway C# will be related to MFC. But things developed using MFC can be used in c#. It will be a new language as C++ came from C,and before we assume something let us see how it develops. It might be too early to assume, we shall wait till PDC, I beleive we will know more about it then.
Ravi

[ALM]

First, C# is not tied in to the Windows environment. Why? C# was submitted to ECMA, an standards committee, by Microsoft. C# will be a subset of C++, like C++ is a subset of C. So anything like MFC or Win32 functions *should* work when using a MS C# compiler.

I have to disagree. C#, being a Microsoft product, is definitely tied to the Windows environment. The language may have been submitted to ECMA but it doesn't mean that it will be approved as a standard. And even then it doesn't mean that it will work across platforms. I don't believe that C# is a subset or superset of C++. It's merely based off of it. It has some features that C++ doesn't have and C++ has features that C# doesn't have. Also, I'd consider C++ a superset of C not a subset, like you say. It adds features (hence the ++ in the name) to C. And yes Win32 functions will be callable from C# but not MFC classes. MFC is a C++ library which I very much doubt will be accessible to C# (the same way it's not accessible to VB).

Second, MFC is just an encapsulation of the Win32 API. The Win32 API is just a set of functions itself, not defined as the libraries to C#, therefore it's incorrect to say that MFC and Win32 is a standard library of C#. In fact, the API's themselves are just functions of C code and assembly language.

Again, I disagree. MFC is a C++ library with many classes whose functions wrap around the Win32 API. MFC has many classes (such as CString, CDocument, CException, CArray, CList) which don't deal with the Win32 API. They merely help you write Win32 applications in C++. By the way, Win32 can be considered a "library" since its functions are contained in several DLLs (kernel32.dll, user32.dll, etc).

The purpose of C# is to create an extension to current C++ standards, enabling programmers to do more things or make things easier.

I think the purpose of C# is to provide a competitive replacement to Microsoft's current Java offering (which is all but dead). It is based on C++ and Java but adds many features to make COM programming easier.

Yes, C# can work cross-platform if you conform to future C# standards (and standard libraries) set by ECMA. You will need to just recompile codes on other platforms, just like C and C++. Of course, if you use Win32 API functions (or COM, or MFC, etc.), it is not cross-platform compatible. :)

I'm not sure about this. I think Microsoft is adding so many Windows/COM specific features onto the language that it will be very difficult to port to other platforms (that don't support COM, for example).

One word of advice, you may want to try to learn Win32 API first before MFC. Why? You'll figure that a lot more things you need to do will require the API functions, in addition to MFC, which is just an encapsulation of it. Of course, if you are not really interested on what goes on inside of MFC, you can just learn MFC.

That's not bad advice. I think it never hurts to know how things are done at the low level. However, in this day in age where one VB statement can do what it would take 10 written in C with the Win32 API, I'd say forget it! Learn how to become productive in the most popular languages, today: VB, tomorrow: C#.

Regards,
Alvaro

[Karmus]

I have to disagree. C#, being a Microsoft product, is definitely tied to the Windows environment. The language may have been submitted to ECMA but it doesn't mean that it will be approved as a standard. And even then it doesn't mean that it will work across platforms

Where in the specifications say that it's tied to the Windows environment? The language is open and free for anyone to implement on a compiler. Though, MS maybe the first ones to implement it, it doesn't mean anyone else can.

. I don't believe that C# is a subset or superset of C++. It's merely based off of it. It has some features that C++ doesn't have and C++ has features that C# doesn't have. Also, I'd consider C++ a superset of C not a subset, like you say. It adds features (hence the ++ in the name) to C. And yes Win32 functions will be callable from C# but not MFC classes. MFC is a C++ library which I very much doubt will be accessible to C# (the same way it's not accessible to VB).

Fair enough. I'll say it's just an extension to C++. In all respects, you should be able to program in C, C++, or C# on this kind of compiler.

Again, I disagree. MFC is a C++ library with many classes whose functions wrap around the Win32 API. MFC has many classes (such as CString, CDocument, CException, CArray, CList) which don't deal with the Win32 API. They merely help you write Win32 applications in C++. By the way, Win32 can be considered a "library" since its functions are contained in several DLLs (kernel32.dll, user32.dll, etc).

I'm not going to argue this for now because I'm starting on Prosise's book. I just finished reading Petzold's.

I think the purpose of C# is to provide a competitive replacement to Microsoft's current Java offering (which is all but dead). It is based on C++ and Java but adds many features to make COM programming easier.

Actually, MS's competitive product to Java was supposed to be "Cool", which MS has stated that C# isn't. Though, maybe C#'s only purpose is to make it easier to program. But, I'll bet that the edge that C# will have is performance, which seems to be haunting Java for a while.

I'm not sure about this. I think Microsoft is adding so many Windows/COM specific features onto the language that it will be very difficult to port to other platforms (that don't support COM, for example).

That may be so, though, it isn't impossible. That's probably what a lot of people said when C++ came out.

I think it never hurts to know how things are done at the low level. However, in this day in age where one VB statement can do what it would take 10 written in C with the Win32 API, I'd say forget it! Learn how to become productive in the most popular languages, today: VB, tomorrow: C#.

I agree with you to some extent, though C/C++ cannot be replaced with VB. The only advantage I see to VB is rapid development for a users interface. When it comes to internal performance and calculations, C/C++ will have to be employed.

Frank

[ALM]

OK, here I go again...

Where in the specifications say that it's tied to the Windows environment? The language is open and free for anyone to implement on a compiler. Though, MS maybe the first ones to implement it, it doesn't mean anyone else can.

I haven't read that it's tied to Windows but the fact that it's tied to COM pretty much ties it to Windows (at least today). Also, the NGWS library (which C# will work with) will contain many Windows-specific GUI components.

I guess the question I have for you is: where does it say that it ISN'T tied to the Windows environment? And were does it say that it's "free" for anyone to implement? It's Microsoft's language; are they giving away the rights to write compilers for it?

Actually, MS's competitive product to Java was supposed to be "Cool", which MS has stated that C# isn't. Though, maybe C#'s only purpose is to make it easier to program. But, I'll bet that the edge that C# will have is performance, which seems to be haunting Java for a while.

I've actually read (on forums like this one) that C# is "Cool". I don't know where you've read that it isn't but other people have said that this is it. (God, I hope it is; I'd hate for Microsoft to announce yet another language in the future.)

Regards,
Alvaro

[whbloodworth]

I haven't read that it's tied to Windows but the fact that it's tied to COM pretty much ties it to Windows (at least today). Also, the NGWS library (which C# will work with) will contain many Windows-specific GUI components.

I believe people are reading too much into the COM and C# connection. I, personally, think what they mean by every C# object will automatically be a COM object means is that the object layout will be compatible with that of a COM object. If that is the meaning, there is no tie to the operating system.

I guess the question I have for you is: where does it say that it ISN'T tied to the Windows environment? And were does it say that it's "free" for anyone to implement? It's Microsoft's language; are they giving away the rights to write compilers for it?

Why assume C# is tied to an OS when all the proposed documentation for it give no hint in that direction? Where does it say that it is not free for anyone to implement? Microsoft is proposing a new language and it is too early to tell whether or not they will attempt to let an outside standards committee “smooth out” the “sharp” edges. Pun intended. No need to argue over an unpredictable piece right now. Let’s just concentrate on the facts we do have.

I've actually read (on forums like this one) that C# is "Cool". I don't know where you've read that it isn't but other people have said that this is it. (God, I hope it is; I'd hate for Microsoft to announce yet another language in the future.)

It seems to have “good intentions” and that can’t hurt. Java had good intentions and still does but Java can’t get to where C# can. From reading the intro to C# on MS’s site, the tie to VB sounds to me like they’re referring to the GUI IDE… not the language itself… let’s hope!


Great Success REQUIRES Great Effort!

[Karmus]

I guess the question I have for you is: where does it say that it ISN'T tied to the Windows environment? And were does it say that it's "free" for anyone to implement? It's Microsoft's language; are they giving away the rights to write compilers for it?

Wouldn't submitting the language to ECMA allow for anyone to implement the language (as an international standard)? Sun withdrew Java to the same comittee because they wanted to keep control on it. As for the Windows environment part, I guess we will have to wait and see.

I've actually read (on forums like this one) that C# is "Cool". I don't know where you've read that it isn't but other people have said that this is it. (God, I hope it is; I'd hate for Microsoft to announce yet another language in the future.)
"Microsoft officials have said publicly that C# has no connection to the Java killer that the company had been developing last year, which was code-named Cool. Officials acknowledged that Cool was a set of C++ extensions on which the company was working. But developers briefed by Microsoft said that Microsoft was positioning Cool as a language that would be a head-to-head competitor with Java."

Link: http://www.zdnet.com/zdnn/stories/news/0,4586,2594130,00.html

[whbloodworth]

Certainly not. You connot use MFC and especialy ATL or WTL with C# cause it does NOT support many features used in this libraries.

Just because C# doesn't support multiple implementation inheritance and templates does not mean that it cannot use MFC and ATL. Functions/Classes that are exported from a DLL can be used from any language that has the ability to load that DLL and call exported functions.

With C# you can ONLY use COM-ojects like in VB.

That is completely untrue. That statement implies that C# code can only operate on IDispatch-based COM objects. C# will have the ability to access both early and late bound COM components. Here is a direct quote from the introduction to C#:

"Including native support for the Component Object Model (COM) and Windows®-based APIs."

Would you agree or disagree that MFC is a "Windows®-based API"? After all, MFC is just basically wrapper classes around the Win32 API.

Great Success REQUIRES Great Effort!

If your not going to use C++ they're pretty much worthless.

If you look at the properties in the word document for the C# language specification you'll notice that it specifically states that it's COOL.

In reply to:

I have to disagree. C#, being a Microsoft product, is definitely tied to the Windows environment. The language may have been submitted to ECMA but it doesn't mean that it will be approved as a standard. And even then it doesn't mean that it will work across platforms. I don't believe that C# is a subset or superset of C++. It's merely based off of it. It has some features that C++ doesn't have and C++ has features that C# doesn't have. Also, I'd consider C++ a superset of C not a subset, like you say. It adds features (hence the ++ in the name) to C. And yes Win32 functions will be callable from C# but not MFC classes. MFC is a C++ library which I very much doubt will be accessible to C# (the same way it's not accessible to VB).



I agrea with Karmus on the ECMA thing. Microsoft want's to show that it can share too with it's (still) promises to make some of the Windows code public and the way it's starting to react on Linux (although i'm not very familiar on that subject). I expect that it will be free to implement by anyone.
In reply to:

Again, I disagree. MFC is a C++ library with many classes whose functions wrap around the Win32 API. MFC has many classes (such as CString, CDocument, CException, CArray, CList) which don't deal with the Win32 API. They merely help you write Win32 applications in C++. By the way, Win32 can be considered a "library" since its functions are contained in several DLLs (kernel32.dll, user32.dll, etc).



I really have to disagree again. MFC really is just a small wrapper around Win32 API calls. The CString and CList classes are just some small classes to show that they did spend at least some time on developing MFC. What it really is is an attempt to make Win32 object orientated.
In reply to:

I think the purpose of C# is to provide a competitive replacement to Microsoft's current Java offering (which is all but dead). It is based on C++ and Java but adds many features to make COM programming easier.



Yes, i agrea. Java has alot of features I've been wanting to see in C++ for a long time. The simple cosmetic features like the way "public" is used, how everything is bound to classes and the use of the "using" statement are ways to make code more managable and readable. Features like garbage collection, better type checking and variable initialisation are things that really are usable.
The disadvantage of cool features like garbage collection is that it takes up time, alot of time. Knowing Microsoft doesn't really know how to write fast code (for the runtime engine which is probably needed for C#) makes it even worse. But there are two things that counter this. First, computers are getting faster and faster so it's just a smaller issue nowadays. Besides that, as I understand right now, C# is really just something to write interfaces. Fast code can be supplied in DLL's using C / C++ compilers and COM objects and you write the interface using C#. I'm currently working on a small program for private use. I've been working for a week now on the "simple" interface and I expect to get the backbone working in three days using the internet and all. This is why C# is a good new thing. It'll speed up the first part of the development.
In reply to:

That's not bad advice. I think it never hurts to know how things are done at the low level. However, in this day in age where one VB statement can do what it would take 10 written in C with the Win32 API, I'd say forget it! Learn how to become productive in the most popular languages, today: VB, tomorrow: C#.



Since VB is mentioned, this. C# probably is not a replacement for VB. No self respecting software developer uses VB if he has any other choice (no offence). I've tried to do some things in VB but when i wanted to implement GETMINMAXINFO I was stuck. It took me two whole days to get it to work. I hope C# will prove to give a way to create interfaces as easilly as VB and still give me the ability to do things like implementing GETMINMAXINFO, but I still am sceptical. Only the future will tell.

Regard,
Pieter van Ginkel.

In reply to:

I'm pretty sure that you will be able to use mfc in your C# programs. Although I wouldn't recommend learning C# as it is essentially a subset of C++ but more restrictive in the fact that it binds you to the Windows Operating Environment.



Yes and no. C# does not bind you to the Window platform. Have you seen one single place where it says that it is only possible to implement C# on Windows platforms... no? So have I. Still, you're right that it probably will be just a version of MFC for the user interface. Ofcourse, if someone feels like it he or she is free to create a full user interface library for Linux or OS/2. I just guess that you and I aren't the only ones that don't see that happening any time soon.

Regard,
Pieter van Ginkel.

[rpmodell]

In reply to:

You are definitely wasting your time on MFC. It junky old stuff. Concentrate on new stuff like C# or Java.



First, when you make a statement, please try to give it some fundation. Besides taht, C# is not a GUI language, it's a programming language. It'll still need a GUI system like MFC. MFC isn't junk, it's just difficult to use. Let's all hope that they make a better system this time, will we?

[rpmodell]

In reply to:

No, u're not wrong. And NO, it's not a waste of time learning MFC: it's the must if wanna develop in win32 env (assuming u're not developing in VB). More, C# uses MFC and VB components: C# does not have its own class library so you will be using the VB and VC++ libraries.



I've read this too and I don't really understand. C# is supposed to use the libraries VB and VC++ are using. When you'd say something like that abou Inprise's Delphi / Builder systems I'd understand (i.e. VCL, visual component library). The only thing that both VB and VC++ are using are Win32 API and some random ActiveX components. Can someone please explain what great library is meant with all of this???

Regard,

Pieter van Ginkel

[rpmodell]

In reply to:

That is completely untrue. That statement implies that C# code can only operate on IDispatch-based COM objects. C# will have the ability to access both early and late bound COM components. Here is a direct quote from the introduction to C#:

"Including native support for the Component Object Model (COM) and Windows®-based APIs."



I disagrea. The statements made by Microsoft clearly specifiy that C# is a purely COM based language. I have no realy idea what this means but I distinctly remember that I've read something like every object being a COM object.
In reply to:

Would you agree or disagree that MFC is a "Windows®-based API"? After all, MFC is just basically wrapper classes around the Win32 API.



Finally someone that understands. MFC isn't anything but a try to make the Win32 API object orientated.

Regards,

Pieter van Ginkel

I can't see how C# can use MFC directly. MFC is a C++ class library. C# is not C++. It's a proprietary Microsoft hack. Unless C# is designed to understand native C++ linkage (decorated names). Which I doubt. And even if it does, I still wouldn't touch it with a bargepole.

The statement that C# can only use COM-objects does not imply only the use of IDispatch-based COM objects. You can add support to access COM objects via function ptr tables to most languages: Java/J++, VB, C, etc etc. So I agree with you, C# will have early-bound COM support.

I also agree MFC is fundamentally a set of wrapper classes for the Windows API. But it does try to encourage a higher-level abstraction for application development, namely the document-view architecture. Flawed though that is. It also handles a lot of nasty low-level Windows boilerplate for you. Faced with programming Win32 in raw C or even C++ and using MFC, I know which I'd choose.

I disagree with you about VB. I don't know what kind of software are you developing, but if you have tried database stuff you have to agreed with me that VB is a great tool. Developing in C++ when all you need is ActiveX, ADO, SQL is a mess, because you can deleiver the same funtionality using VB 5 or more times faster. If you need to make any thing can't be implemented on VB you can make a wrapper COM using C++ and integrate it nicely with VB.
Sure, VB has many places of improvments. I think the most important are a better COM integration has you said, specially implementing interfaces and a well defined thread support.

Regards

[whbloodworth]

I disagree with you about VB. I don't know what kind of software are you developing, but if you have tried database stuff you have to agreed with me that VB is a great tool. Developing in C++ when all you need is ActiveX, ADO, SQL is a mess, because you can deleiver the same funtionality using VB 5 or more times faster.

Yes, it is faster to develop... but every COM object you create in VB must carry the VB runtime with it. Therefore, the COM DLL size is almost always a megabyte in size or more. This is not good for ActiveX controls that are meant to provide functionality for a web page. Also, the performance is not comparable between the two compiled DLLs (VB & VC).

If you need to make any thing can't be implemented on VB you can make a wrapper COM using C++ and integrate it nicely with VB.
Sure, VB has many places of improvments. I think the most important are a better COM integration has you said, specially implementing interfaces and a well defined thread support.

All good points. VB has its place. There is no arguing that it is good for a lot of things. There shouldn't be any arguing the fact that there are a lot of things VB is not appropriate for. C# is going to take design from Java, speed, efficiency, and type-safety from C++, and I'm guessing the GUI development will take from the VB arena. This should be very nice.

W. Bloodworth


Great Success REQUIRES Great Effort!

[whbloodworth]

I can't see how C# can use MFC directly. MFC is a C++ class library. C# is not C++. It's a proprietary Microsoft hack. Unless C# is designed to understand native C++ linkage (decorated names).

Firstly, C# is not proprietary. You have no proof of that fact. And how do you think VB can load up a DLL that was compiled in C++ and access the exported functions in that DLL? C# is much closer to C++ than VB. C# will probably have the exact same object model and structure layout. Since all C# objects are COM objects, the binary layout would be compatible with C++ objects written the exact same way.

I also agree MFC is fundamentally a set of wrapper classes for the Windows API. But it does try to encourage a higher-level abstraction for application development, namely the document-view architecture. Flawed though that is. It also handles a lot of nasty low-level Windows boilerplate for you. Faced with programming Win32 in raw C or even C++ and using MFC, I know which I'd choose.

I agree completely. We can only hope... and I'm assuming from the introductory documentation that MS has come up with some way to use other libraries already in existence.

W. Bloodworth

Great Success REQUIRES Great Effort!

[whbloodworth]

I disagree. The statements made by Microsoft clearly specifiy that C# is a purely COM based language. I have no realy idea what this means but I distinctly remember that I've read something like every object being a COM object.

If you don't know what it means to be a COM object then how can you possibly begin to disagree?

W. Bloodworth

Great Success REQUIRES Great Effort!

[rpmodell]

If you don't know what it means to be a COM object then how can you possibly begin to disagree?

I'm simply saying what i read in the announcements. I'm not even trying to agree or disagree.

[whbloodworth]

I'm simply saying what i read in the announcements. I'm not even trying to agree or disagree.

Alright. COM is a binary standard. That means that is not tied to any platform. Any component that can conform to that binary standard can use/write COM. C# objects, by default, conform to that binary standard. This is in no way causing it to be a proprietary language... which so many people seem to be confused about.

W. Bloodworth

Great Success REQUIRES Great Effort!

[whbloodworth]

Your quote about MFC...

If your not going to use C++ they're pretty much worthless.

Any language that has the ability to load a DLL into memory and access the exported methods in that DLL has the ability to use the MFC library.

W. Bloodworth

Great Success REQUIRES Great Effort!

[rpmodell]

Thanks for clearing that up Mr. Bloodworth.

Regards,

Pieter van Ginkel.

Yes, it is faster to develop... but every COM object you create in VB must carry the VB runtime with it. Therefore, the COM DLL size is almost always a megabyte in size or more. This is not good for ActiveX controls that are meant to provide functionality for a web page. Also, the performance is not comparable between the two compiled DLLs (VB & VC).

The VB runtime is not included with the COM object. You do need the VB runtime DLL's on the target system but I wouldn't mind betting that most people will already have it, even the non developers.

I used to think that no self respecting developer uses VB but then I realised that I hadn't used VB since version 3. Checkout http://www.vbaccelerator.com/ (VB Accelerator) and http://www.ur.co.nz/vbmem2.htm (VB Ripple example on Unlimeted Realities) for some of the amazing things you can do in VB.

Back on topic C# is not C++ therefore you cannot use MFC or C++ in C#. I assume that, over time, libraries that reproduce this functionality will appear.

Looking forward to the Beta :-)

adam

Until C# has been accepted/ratified/whatevered by an independent standards body, it's proprietary. As are VB and Java. C# is no different (at present).

VB (and C for that matter) cannot access exported *C++* functions from a DLL. VB does of course understand C linkage. It has to, since that what the Windows API uses.
It doesn't understand C++ linkage (decorated names). That's why C++ has the external C linkage option. Do you really think VB can access a function called
"??5@YGAAVCArchive@@AAV0@AAPAVCRichEditCntrItem@@@Z"?

As I said, if C# doesn't understand C++ linkage, then it too will not be able to use MFC.

COM objects are a completely different matter. They have a standard binary layout. What language you write that COM object in doesn't (shouldn't?) matter. Or so Microsoft keep telling us. Although I can smell a COM component written in VB a mile away! (It doesn't crash or leak: only (half) joking :-))

[whbloodworth]

VB (and C for that matter) cannot access exported *C++* functions from a DLL. VB does of course understand C linkage. It has to, since that what the Windows API uses.
It doesn't understand C++ linkage (decorated names). That's why C++ has the external C linkage option. Do you really think VB can access a function called
"??5@YGAAVCArchive@@AAV0@AAPAVCRichEditCntrItem@@@Z"?

Do you actually think developers have to call LoadLibrary and pass in the above string telling it to load that function?

As I said, if C# doesn't understand C++ linkage, then it too will not be able to use MFC.

You state this as if it is a fact. There has been no publication, that I am aware of, stating what the linkage of C# will be. Are you just guessing?

W. Bloodworth

Great Success REQUIRES Great Effort!

LoadLibrary? I don't think you understood my point. Maybe I'm poor at explaining. C++ can resolve calls to functions in MFC42.DLL at link time by using the import library MFC42.LIB. I suppose you could dynamically link using LoadLibrary/GetProcAddress if you wanted to do things the hard way. Although I can't see the point if you're using MFC42.DLL. As for VB, the VB compiler resolves calls from VB to exported C functions in DLLs (USER32.DLL, for example). AFAIK, you can't (currently) use GetProcAddress in VB because it returns the address of a function.

Did I say I knew what C#'s linkage was going to be? No. I said *if* C# doesn't understand C++ decorated names, then it won't be able to use MFC. The same way that VB cannot use MFC because MFC exports C++ decorated names. Look at MFC42.DEF et al and you'll see what I mean. MFC is only a bunch of C++ classes after all. Are you seriously suggesting VB can call C++ functions(including constructors, operators, virtual functions) directly?

[whbloodworth]

LoadLibrary? I don't think you understood my point. Maybe I'm poor at explaining. C++ can resolve calls to functions in MFC42.DLL at link time by using the import library MFC42.LIB. I suppose you could dynamically link using LoadLibrary/GetProcAddress if you wanted to do things the hard way. Although I can't see the point if you're using MFC42.DLL.

The point is that you don't have to link at compile time with the LIB file. You have the option of using LoadLibrary/GetProcAddress (except in VB... but who cares about VB). C# does still have pointers so it can load functions at runtime. I think we're on the same line of thinking anyway.

Did I say I knew what C#'s linkage was going to be? No. I said *if* C# doesn't understand C++ decorated names...

My apologies. I didn't see your "if" there. In response to the other... I am stating that C# has the ability to load DLLs at runtime and call exported functions... that was (and is) the only point I was/am making. I do not know VB nor do I care to (and never will) therefore I couldn't care less what it's capabilities of calling MFC functions are (or aren't).

W. Bloodworth


Great Success REQUIRES Great Effort!

[ALM]

It's a known fact (at least by most competent C++ developers) that C++ classes exported from a DLL can only be used by other C++ modules (EXEs or DLLs) built with the same compiler. The reason is two-fold:

1. By default, the C++ compiler mangles the names of class member functions.

2. Regular member functions receive a hidden "this" parameter to represent the address of the object being worked with.

This is why C++ functions aren't accessible to C, VB, Pascal, etc. To make them accessible, they need to be declared as global functions with no name decorations (which extern "C" removes).

So if C# is going to have access to C++ classes (which I definitely doubt), it will need to know how to import C++ classes (with the mangled names) and be able to pass the member functions the hidden "this" pointer parameter.

Notice that this has nothing to do with MFC. MFC, like Anonymous has been trying to explain, is just a C++ class library. The fact that it wraps around the Win32 API is irrelevant. Borland has their own C++ class library with a lot of Win32 wrapper functions. Is C# going to read their classes too? Nope! Why? Because of the reasons I stated above. Besides, I think Borland even uses their own name-decoration scheme which isn't compatible with Microsoft's!

Is this clear to you now?
Alvaro

[ALM]

Wrong! MFC is a C++ class library; it can only be used by C++ modules. See my recent response to you: http://codeguru.earthweb.com/bbs/wt/showpost.pl?Board=CSharp&Number=175&page=0&view=collapsed&sb=5

Alvaro

[whbloodworth]

Alvaro,

What you can be sure of is that there will be a way provided to use existing libraries. Yesterday at the PDC, Microsoft demonstrated the ability to inherit from COBOL code and to step in the debugger from C# code into COBOL code. This, along your line of thinking (or pessimism) should be impossible. The proof is in the pudding. Just wait and see.

W. Bloodworth

Great Success REQUIRES Great Effort!

[ALM]

I'm not saying it's impossible to make it work in the future. I'm just telling you why today (with the existing compilers, linkers, etc.) it's nearly impossible for non-C++ modules to import C++ classes.

Microsoft certainly has the power to make all its languages/compilers binarily compatible with each other. And from what I've read that's what they want to accomplish, which would actually be nice!

Regards,
Alvaro

[whbloodworth]

I retract the statement. I confused the Win32 exported functions with the MFC wrappers around those functions.

W. Bloodworth

Great Success REQUIRES Great Effort!

You are totally wrong and less-mind.

Stupid

[Dinu]

A couple of words about previous poster.
C# is a new language and still there are a lot of discussions about it. On the other hand, I have a big experience in C/C++ programming and if you fink that you're very smart just because you know that C# is NOT based on MFC, then I don't.


Dinu Sco*****

If you are really planning on getting into the field, expect to learn many languages and libraries, it will be an ongoing process throughout your entire life. The industry is changing so quickly that it is not wise to lock yourself to a single language, plus new languages and extensions and libraries and tools are coming out all the time. Learning C++ or Java is probably a good idea to start since it will allow you to work with OO methodoligies and once you know C++ it's easier to move to other languages like VB. Although its not the first computer language thats the hardest to learn, its the second since it forces you to understand the generalities of computer languages in general, once you understand the basic building blocks of computer languages its easy to move from one to the other, which most people will likely be doing.

Odd, since at the last place I worked we did exactly that. We had a number of c++ dll's compiled under VC being called via Borland compiled code. It was tricky and there were some limitations, but it was is possible.

[ALM]

Well, I bet your Borland code wasn't directly using classes imported from the VC DLL, right?

Dear Frank:

I am curious from whence your information on C# originates. The company (unnamed) I work for has been developing in the language for at least eight months, and I have personally been writing C# code for a few months, and I can't see the validity of your statement, "C# is a subset of C++" It isn't a subset, but more like a union and an intersection. You are comparing Apples to coffee tables.

As for MFC and Win32 - you can call unmanaged API's from C#; But the question is, Why bother?

-Anonymous C# Developer

[rsekharj]

It is never to be said that u are wasting ur time learning MFC. What I basically feel about MFC is that it gives U a fantastic idea and approach to the concept and hardships of huge programming. So it is better that u learn MFC and as the C# software comes along fall on a double track. By this ur technical knowhow will be more...

First, C# is not tied in to the Windows environment. Why? C# was submitted to ECMA, an standards committee, by Microsoft. C# will be a subset of C++, like C++ is a subset of C. So anything like MFC or Win32 functions *should* work when using a MS C# compiler.

Yes, C# can work cross-platform if you conform to future C# standards (and standard libraries) set by ECMA. You will need to just recompile codes on other platforms, just like C and C++. Of course, if you use Win32 API functions (or COM, or MFC, etc.), it is not cross-platform compatible. :)


Then, How larger C# libary? I wonder that...
subet mfc, win32 api, c++, c, and... etc (i guess java platform(?) in..)
only cross-complier support that all?

Jinho