Thread: C++/CLI arrogance

  1. #16
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    >All they did was add the ability to do managed stuff to the existing compiler

    Thats not the part the makes people upset. Its the part about depricating the standard library and trying to force people into using this stuff. (eg. If you don't use CLR your code isn't safe... blah blah blah..)

  2. #17
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    Mario F. They provided a different way of accessing the system api. Before it was win32 api which also was not part of standard C++. All other code, you guessed it... can be standard C++. Same as before, except that the API side is better now.

    This really has no major impact on the use of C++ in windows developent unless stubborn C++ programmers refuse to use it, in which case, C++ will shrink in popularity. Great move guys.
    Last edited by FillYourBrain; 07-27-2006 at 10:28 AM.
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  3. #18
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    Quote Originally Posted by Perspective
    >All they did was add the ability to do managed stuff to the existing compiler

    Thats not the part the makes people upset. Its the part about depricating the standard library and trying to force people into using this stuff. (eg. If you don't use CLR your code isn't safe... blah blah blah..)
    actually you need /clr:safe to accomplish that. But yeah, calling the standard library depricated is a problem. That's not really a function of the CLR so much though. It's a separate issue with the new C++ compiler. (there is a difference)
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  4. #19
    System Novice siavoshkc's Avatar
    Join Date
    Jan 2006
    Location
    Tehran
    Posts
    1,246
    Quote Originally Posted by FillYourBrain
    cl test.cpp
    produced test.exe
    size 53k

    cl /clr test.cpp
    produced test.exe
    size 23k
    Really? Intresting!
    I compiled your code:
    non clr =5.5k
    clr =24.5k

    Both were optimized.
    Quote Originally Posted by FillYourBrain
    Before it was win32 api which also was not part of standard C++. All other code, you guessed it... can be standard C++. Same as before, except that the API side is better now.
    OS API has nothing to do with .Net. As far as I know .net uses windows API for Windows apps. Correct me if I am wrong.
    Last edited by siavoshkc; 07-27-2006 at 10:52 AM.
    Learn C++ (C++ Books, C Books, FAQ, Forum Search)
    Code painter latest version on sourceforge DOWNLOAD NOW!
    Download FSB Data Integrity Tester.
    Siavosh K C

  5. #20
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    Quote Originally Posted by siavoshkc
    Really? Intresting!
    I compiled your code:
    non clr =5.5k
    clr =24.5k

    Both were optimized.
    don't know what the differences were. Regardless, as I said before it's linking in the clr stuff but that doesn't change the fact that the code is compiled native, same as before.

    Quote Originally Posted by siavoshkc
    OS API has nothing to do with .Net. As far as I know >net uses windows API for Windows apps. Correct me if I am wrong.
    this now is totally wrong. .NET is the new windows API. It's intended to replace Win32.

    edit: it's partially wrong. for the moment, .NET does use the Win32 API. They will be moving that over time. Win32 will become a wrapper, supported for backward compatibility.
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  6. #21
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    >.NET is the new windows API

    Wasn't .NET supposed to be the new windows API, but then they scrapped it because they couldn't get it to work properly (along with MONAD and WinFS)


    *legitimate question, not just a poke at MS

  7. #22
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    well, could be. Can't say that I have the inside scoop on MS strategy. Got any ref to that?
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  8. #23
    System Novice siavoshkc's Avatar
    Join Date
    Jan 2006
    Location
    Tehran
    Posts
    1,246
    that doesn't change the fact that the code is compiled native, same as before.
    .net code should be in MSIL (CLI) to be portable.
    Learn C++ (C++ Books, C Books, FAQ, Forum Search)
    Code painter latest version on sourceforge DOWNLOAD NOW!
    Download FSB Data Integrity Tester.
    Siavosh K C

  9. #24
    Dump Truck Internet valis's Avatar
    Join Date
    Jul 2005
    Posts
    357
    I'm just blowing smoke, but it seems like the syntactic differences offer little advantage over current C++ save it's not compatible with standard compilers. ref and value for example could have been implemented using the scope resolution operator.
    KDE 4 is going to be cross compatible over all operating systems worthy of speaking of (including the big unix based systems), much prettier than .net (more configurable) and hell--it will probably be faster. The problem I have with .net is that it's only cross compatible over the operating systems microsoft chooses, this includes systems such as: windows vista, windows xp, windows ce, and windows 2000.

  10. #25
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    Quote Originally Posted by siavoshkc
    .net code should be in MSIL (CLI) to be portable.
    but in the case of C++/CLI, That's not the case with any part of it that is not done in the "managed" syntax. Which is the point of what I'm saying. If you don't use the managed parts, you don't get MSIL
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  11. #26
    System Novice siavoshkc's Avatar
    Join Date
    Jan 2006
    Location
    Tehran
    Posts
    1,246
    Yes it seems that windows API is going to be .net
    .net3 (WinFX) for Vista.
    Learn C++ (C++ Books, C Books, FAQ, Forum Search)
    Code painter latest version on sourceforge DOWNLOAD NOW!
    Download FSB Data Integrity Tester.
    Siavosh K C

  12. #27
    pronounced 'fib' FillYourBrain's Avatar
    Join Date
    Aug 2002
    Posts
    2,297
    Quote Originally Posted by valis
    I'm just blowing smoke, but it seems like the syntactic differences offer little advantage over current C++ save it's not compatible with standard compilers. ref and value for example could have been implemented using the scope resolution operator.
    I actually agree with this (though I don't see how the scope resolution operator could help with the problem). What I mean is that they could have hidden managed pointers behind some sort of managed pointer object. All of the .NET stuff could have been hidden in libraries that standard C++ stuff calls. Then you'd have g++ able to access it just as easily. Big benefit there. But they didn't. Does that make it evil? eh, don't care. I still won't refuse to use it because I'm not a language nazi.
    "You are stupid! You are stupid! Oh, and don't forget, you are STUPID!" - Dexter

  13. #28
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    But with Vista, it's still .Net 3 being implemented on top of the WinAPI, not vice versa. It'll take MS a long, long time to actually change that. Besides, the only thing they could do is implement .Net on top of the direct system calls, making it parallel to the WinAPI. There is little sense in then implementing the WinAPI on top of .Net. It only complicates things. Consider:
    1) You'd go from unmanaged (kernel) to managed (.Net) back to unmanaged (WinAPI). Huge and useless performance overhead.
    2) You'd have to convert the object-oriented .Net API back to the pseudo-object-oriented WinAPI. Huge design and probably code overhead, and useless, when you can just implement it with system calls.
    3) You'd have to somehow protect the managed classes while they're in use by the unmanaged code. Very complicated problem.

    The WinAPI won't go away for a long, long time. MS still has special handling in the OS to ensure some old Win95 applications can run - perhaps even something for Win 3.x apps. Would they really remove the API that allows these applications to run? Would they really re-implement a lot of working code in .Net just for the sake of removing the API?

    They won't.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  14. #29
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    I still won't refuse to use it because I'm not a language nazi.
    But saying traditional C++ is 'un-safe' to me is being one. And that's exactly what I'm reading all throughout this book. Don't you see what they are doing? They see Java's VM, steal it, modify it, and come out with .NET. Heck even the court system said they stole it and had to pay fines. Now they tout this as the 'only' way to program so we should all drop traditional C++ to use CLI. In fact if we don't, we will be left behind.

    All the while they tout on the public side that piracy is such a very bad thing and causes programmers to lose their job, etc, etc. That portion is right, but a company known for being guilty of it (and in this case as well), they should take a dose of their own medicine. It would be no different than any of us tearing apart the API, copying most of it, altering it here and there to do what we want, and then touting it as a revolutionary technology that we should all use. We'd be in court tomorrow I guarantee it.


    C++/CLI is the Java VM revamped, revised, altered to fit specifically Windows the best and other platforms as long as they have a VM, called a CLR instead of a VM. Bad idea? No, but they aren't going about it quite 'fairly'.

    I'll use it to stay up to date but my opinions stay the same. It is an attempt by one of the big boys to force you into a programming model and not one that is better, just one that was invented by them.

  15. #30
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    OK, I need to let out a short rant. I've been seeing this in all the .Net debates here for too long.

    The CLI and the CLR are the virtual machine, runtime system, and library collection. They are one thing.

    C++/CLI, C#, VB.Net, J#, JScript.Net and all the many others are programming languages or specific implementations of programming language that make use of the CLI. They typically output CIL bytecode, they make use of the CLI garbage collector, they adhere to the CLI type system (mostly).

    These are two very different things. It is possible to compile straight C++ to CIL bytecode, you just won't be using the features very well - basically you'll have all the disadvantages and none of the advantages.

    So please keep discussion about CLI/CLR apart from discussion of specific languages targetting that platform. Mixing them only makes a charged topic confusing, too.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed