Thread: api or mfc

  1. #31
    Registered User
    Join Date
    Jun 2008
    Posts
    266
    i was never a fan of .net. .net is very slow compared to c++ and i dont think .net will ever replace c++, even in companies.

  2. #32
    Registered User
    Join Date
    Jun 2008
    Posts
    266
    i actually do care about portability. the only problem is i dont like 3rd party libraries that much. the day the standard libraries get grahics, sound, and networking libraries i will become a portable programmer.

  3. #33
    Deathray Engineer MacGyver's Avatar
    Join Date
    Mar 2007
    Posts
    3,210
    So until then you won't use graphics, sound, or networking?

  4. #34
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Quote Originally Posted by lruc
    i was never a fan of .net. .net is very slow compared to c++ and i dont think .net will ever replace c++, even in companies.
    Oh well... I don't think this "C# is slow" mantra will ever end. It's been discussed so many times of these forums and it hasn't yet.

    Just do yourself a favor... don't... buy... the... C#... is... slow... argument. You won't regret it. If that's your problem with C#, then you clearly need to study it better.

    Quote Originally Posted by lruc
    i actually do care about portability. the only problem is i dont like 3rd party libraries that much. the day the standard libraries get grahics, sound, and networking libraries i will become a portable programmer.
    uh? You just don't like them because you don't know them, or you don't like them for a specific reason you are not sharing with us. I'm most curious as to what the collective of 3rd party libraries has that makes you not liking it...

    Since the answer is probably going to frustrate me, I suggest instead your reevaluate your position and consider that the strength of C++ lies exactly on its 3rd party libraries. The language itself, plus Standard Library and STL is pretty much dull and boring... unless you are a 3rd party library developer. Which obviously you are not.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  5. #35
    Registered User
    Join Date
    Jun 2008
    Posts
    266
    c# being slow is something i have just heard many times and you might be right, but i really dont know. also, its not so much that i dont like 3rd party libraries so much as i prefer the api's instead. was that frustrating???

  6. #36
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    The slowness of C# compiled code isnt a property of the language itself, but a consequence of its implimentation. The first C/C++ compilers werent all that fast compared to assembly, bu tthye improve over time. Im sure of C# recieves a lot of attention it will improve over time as well. Its really more of a transitional language though, meant to help stear VB users towards C/C++ without the steep learnign curve of a comlete switch. In microsofts own words C/C++ are the language of choice for performance and raw computing power. They also stopped supporting FoxPro so both of the foxpro users are looking for a replacement language.

  7. #37
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    C# is just Microsoft's own attempt to monopolize the programming market, if you ask me.
    They don't own C/C++, but they can have a lot of say in C#.
    I doubt C# will get faster due to its nature. It's interpreted and compiled. Maybe you could say dynamically recompiled.
    But the fact is that it is not native code and therefore will always run slower than C/C++, regardless of what Microsoft says.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #38
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Well, regardless what you good people say, I say C# is not slower than C++ for the type of applications it targets. And when it is, it's almost always negligible.

    For all that matters, my beloved C++/wxWidgets is at least one magnitude slower than C# on most windows related tasks. And yet... you guessed it... nobody seems to care. I don't hear a ruckus about it, do any of you? (and still is a quiet promising way of programming for Windows... or no one uses CodeBlocks anymore... because it's slow?)

    It becomes an issue if the 0.1 seconds it takes to load a 10,000 item list control after you click a button is unacceptable and what you want is 0.08 seconds. But then... well, lets just say the bottleneck is almost always on the code and rarely on the language.

    If you want to squeeze every bit of performance of your GUI application, the best option - and the one that brings sure results - is changing programmers, not programming languages.
    Last edited by Mario F.; 07-01-2008 at 10:32 AM.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  9. #39
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    ...I wouldn't put much effort in learning MFC at this point since Microsoft clearly wants to get rid of it as soon as it can.
    This obviously is incorrect since Microsoft just updated the entire MFC framework as of MSVS 2008. Microsoft is going to publish whatever the devs will buy and they found a lot of devs wanted an update to MFC so that's exactly what they gave them.

    But it is true that even Microsoft clearly states that they have no intention of replacing C/C++ via C# or any other language out there. They recommend C/C++ over all others if you need raw power. Fact is most applications do not and C# will suffice.

    In my own experience C# apps do run a bit slower than MFC apps. Whether this is because I suck at C# or not is definitely up for debate. Overall I find it takes more time for common dialogs to come up and for common controls to do their 'thing' whatever that may be. It feels as if .NET takes a very long time to load 'something' when you are using the default controls and dialogs but I've never discovered what it is or read anything as to why this may occur. Perhaps this is more of a problem with .NET than C# since C# seems to do quite well for most in XNA. So perhaps the more correct answer is that .NET is slower than the CRT which I believe we all would agree on.

    C# is a very nice language though and .NET supports just about anything you would want to do and more. I honestly cannot make a recommendation between C# and MFC C++ apps. For me the final decision is how easily will the tool interface with existing tools? Another big question is what are the current crop of tools written in and if I change that do I unnecessarily increase the maintenance task? Most of these decisions are made far above my pay grade but that is some of the thought process they have told us they use to determine which language to use for tools. Is it easier to teach new devs MFC or C#? If most the tools are in C# using MFC may not be a wise choice and vice versa. For now most of our GUI tools are written in C#. I will say this has made it difficult at times to interface with existing code for testing and so forth since managed and unmanaged code do not play well together. If somehow the interop between C# and C++ could be eased a bit I think it would be even more widely used. For now it usually comes down to making a COM component that acts as a wrapper or writing a C style wrapper that wraps access to the C++ class. The wrapper then can be called from C# since C calls are not using this call and the wrapper then calls the C++ functions.
    Last edited by VirtualAce; 07-01-2008 at 10:01 PM.

  10. #40
    train spotter
    Join Date
    Aug 2001
    Location
    near a computer
    Posts
    3,868
    Your choice of framework / API shoud depend on where you want to go with programming.

    The software houses I have worked for have only used WIN32 and MFC. (for C/C++ GUIs)

    None used any third party API commercially.

    You may dislike MFC, but it is not going anywhere quickly. We are simply not porting to .NET (nor to Vista).

    If you plan a programming career, experience with the frameworks / APIs used commercially is more important than which one YOU prefer.
    "Man alone suffers so excruciatingly in the world that he was compelled to invent laughter."
    Friedrich Nietzsche

    "I spent a lot of my money on booze, birds and fast cars......the rest I squandered."
    George Best

    "If you are going through hell....keep going."
    Winston Churchill

  11. #41
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    Quote Originally Posted by Bubba View Post
    This obviously is incorrect since Microsoft just updated the entire MFC framework as of MSVS 2008.
    Didn't know about this. Just took a quick look. It however seems to me mostly a cosmetic getting up-to-date effort, Bubba. Mostly new controls. Although, the new shell management classes and TR1 support seem no doubt a great addition. They also say they will keep improving it...

    Well glad I'm wrong on this one. It's been my reasoning that one of Microsoft wishes behind .Net is exactly to cut down on C++ development on windows on account of all security issues that plague the operating system. MFC would, on this case, be a priority target. The pushing of C#, no framework support for C++, an outdated MFC, a .Net based OS, all contributed to this general feeling I had; basically that Microsoft is winking everyone into .net development and to drop C++/MFC/Win32.

    I'm still somewhat unsure. I wonder how much of that upgrade wasn't the result of pressure from major customers and public in general... and, at the same time, Microsoft realization C# didn't really replace C++ as much as they wished.
    Last edited by Mario F.; 07-02-2008 at 06:56 AM.
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  12. #42
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,195
    C/C++ are MS's bread and butter, they will not 'deprecate' it in our lifetime. MFC and .NET are fine for most applications, but new and innovative and particularly science and engineering related development requires more than just out of the box classes. This is one of the reasons I was appalled to find no support for inline assembly in x64, since the very market that is most likely to use x64 is the same market that is most likely to use inline assembly (engineers).

  13. #43
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    You're not alone in that you are appalled to see no inline asm support in x86.
    It has been one of the reasons I've been reluctant to embrace x64. Although, nowadays, I'm less likely to rely on asm. Still, it's a very big shortcoming of ms, if you ask me.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Win32 API and MFC
    By loopshot in forum C++ Programming
    Replies: 6
    Last Post: 12-07-2004, 11:58 AM
  2. OLE Clipboard :: Win32 API vs. MFC
    By kuphryn in forum Windows Programming
    Replies: 3
    Last Post: 08-11-2002, 05:57 PM
  3. Thread Synchronization :: Win32 API vs. MFC
    By kuphryn in forum Windows Programming
    Replies: 2
    Last Post: 08-09-2002, 09:09 AM
  4. WIndows programming?
    By hostensteffa in forum Windows Programming
    Replies: 7
    Last Post: 06-07-2002, 08:52 PM
  5. MFC or Windows API
    By aresashura in forum Windows Programming
    Replies: 7
    Last Post: 12-01-2001, 10:21 PM