4 ms·

The mistake wasn't in offering .NET. The mistake was in letting C++ rot for 10 years. They are suffering now because of the lack of an efficient and modern nati

The mistake wasn't in offering .NET. The mistake was in letting C++ rot for 10 years. They are suffering now because of the lack of an efficient and modern native code development tool.

hvs 15y ago
I'm not sure what you mean by "rot". Microsoft is supporting C++0x and has created Microsoft AMP. Visual Studio is still the best development environment available, bar none. How is it not "efficient" or "modern"?
- ldar15 15y ago
  "efficient" DRY: as a programmer you know that having to maintain two identical copies of something to keep them in sync is bad. You should refactor. Now take that idea and make it part of the language: header files. You have to declare every method in the source file, and then again, in the header file. That at least made some sense for C, because header files were small, compared to source files. Only a few key methods needed to be in the header files. Now take C++: the entire class declaration has to be in the header file, including all the private methods. Now every source file has to parse a much greater amount of header files. For bonus points, don't change the rule that a header file can be included multiple times, with multiple different active #defines. So you cant optimize that. Then, even if you do start using microsoft specific #pragma's, of compiler-recognizable #ifdef MYFILE_H #define MYFILE_H, these files can still render different syntax trees between different source files, so you can't parse them one per project. Then, introduce templates. Basically, remove the need for a source file at all, and declare that huge reams of code will actually be in header files. Bonus: dont declare a new form of source file, just keep using header files for this, again with the rules that the same header file (of templates) can mean multiple different things in any given source file, despite the fact that this is guaranteed to Not Do You What You Expect even if you were foolish enough to do it. The only template "improvement" in C++0x is "extern templates", which is basically a huge goddam hack that says to the compiler "look I know you've had to parse+comprehend this template code for every single source file but please dont actually generate the machine code in my object file". Finally, get together and decide that of all the things fucked up about C++, its the lack of threading support that is the big problem for us all. Seriously? There isn't any way to make Visual C++ "efficient" because it compiles C++. Likewise, "modern". If you mean "efficient" for typing / editing, then I'd recommend you have a look at Visual SlickEdit (if you are the IDE type) and even then you will be light years behind what a modern IDE can do with a modern language.
  - alok-g 15y ago
    Love it man! Thanks >> even then you will be light years behind what a modern IDE can do with a modern language Could you point me to one? Especially interested in high-performance ones.
- forgotAgain 15y ago
  By rot for example I mean not supporting WTL from within the tools development group. The only WTL tool that integrated into VS was developed by some guy in Eastern Europe. There was nothing from MS. As another example the largest software company in the world making tens of billions of dollars a year and they license a cheesy MFC widget library (in VS 2008 SP2?) instead of having internal resources to develop their own. I agree that VS is the best development tool but the MS development tool group supported C++ poorly from 1998 to 2010. It appears that it is changing but it has appeared that way several times but always it turned into a one shot deal with no follow through.
- ldar15 15y ago
  And if there is a language that is screaming out for an AMP equivalent its C#: it has structs for efficient memory organization. It has hands-off memory management, meaning that the GPU back-end can do it differently than a CPU back-end. It has attributes, meaning an easy way for you, the programmer, to provide hints to the back end, in a non-hack, already built-in kind of way.
ldar15 15y ago
I agree with your conclusion (suffering for lack of modern native code development) but disagree with your solution. C# still has the potential to be vastly superior to C++ for "native" development. The problem is that they spent the last 10 years working exclusively on neat features like LINQ instead of something that they promised back in 2002. I wish I had a link to the article, but back in 2002 I read an article from one of the C# leads stating that, unlike C++, the CLR would be able to do processor specific optimizations at code generation time. It also talked about inline functions, and that it didnt matter that C# didnt have an inline keyword because of course the JITter would do that automatically. Roll on 2011, and my lovely Matrix44.Multiply(Vector4[] foo) neither inlines the internal Matrix44.Multiply(Vector4 bar) nor does it SIMD any of it even if I inline it myself. Ditto for Matrix34.Multiply(ArrayOfStructs baz). Then there are the kind of performance guided global optimizations that you could do with a language like C#, using data-driven compilers, or manual-driven attributes. Memory management, for example, could be class/struct specific giving those classes performance as good as any C++ custom memory management (e.g. pools), while allowing initial development to proceed rapidly. Sadly, none of this came to pass. If anyone wanted to hire me to work at a games company it would be on the condition that the first thing I got to do was write a C# toolset that did exactly this. (Funnily enough, nobody has hired me, but the idea of scrabbling in the just-post-punch-card shit that is C++ is enough to discourage me from dropping the requirement).
- kenjackson 15y ago
  Roll on 2011, and my lovely Matrix44.Multiply(Vector4[] foo) neither inlines the internal Matrix44.Multiply(Vector4 bar) nor does it SIMD any of it even if I inline it myself. Ditto for Matrix34.Multiply(ArrayOfStructs baz). The CLR does inline, but it has restrictions that you're probably hitting. But it doesn't do processor specific opts. That does suck. Then there are the kind of performance guided global optimizations that you could do with a language like C#, using data-driven compilers, or manual-driven attributes. The CLR does have a profile based optimization system, but according to this article, it is internal-only. http://msdn.microsoft.com/en-us/magazine/dd569747.aspx http://msdn.microsoft.com/en-us/magazine/dd569747.aspx Oh well.
  - 15y ago

The mistake wasn't in offering .NET. The mistake was in letting C++ rot for 10 years. They are suffering now because of the lack of an efficient and modern native code development tool.

hvs 15y ago

I'm not sure what you mean by "rot". Microsoft is supporting C++0x and has created Microsoft AMP. Visual Studio is still the best development environment available, bar none. How is it not "efficient" or "modern"?

ldar15 15y ago
"efficient" DRY: as a programmer you know that having to maintain two identical copies of something to keep them in sync is bad. You should refactor. Now take that idea and make it part of the language: header files. You have to declare every method in the source file, and then again, in the header file. That at least made some sense for C, because header files were small, compared to source files. Only a few key methods needed to be in the header files. Now take C++: the entire class declaration has to be in the header file, including all the private methods. Now every source file has to parse a much greater amount of header files. For bonus points, don't change the rule that a header file can be included multiple times, with multiple different active #defines. So you cant optimize that. Then, even if you do start using microsoft specific #pragma's, of compiler-recognizable #ifdef MYFILE_H #define MYFILE_H, these files can still render different syntax trees between different source files, so you can't parse them one per project. Then, introduce templates. Basically, remove the need for a source file at all, and declare that huge reams of code will actually be in header files. Bonus: dont declare a new form of source file, just keep using header files for this, again with the rules that the same header file (of templates) can mean multiple different things in any given source file, despite the fact that this is guaranteed to Not Do You What You Expect even if you were foolish enough to do it. The only template "improvement" in C++0x is "extern templates", which is basically a huge goddam hack that says to the compiler "look I know you've had to parse+comprehend this template code for every single source file but please dont actually generate the machine code in my object file". Finally, get together and decide that of all the things fucked up about C++, its the lack of threading support that is the big problem for us all. Seriously? There isn't any way to make Visual C++ "efficient" because it compiles C++. Likewise, "modern". If you mean "efficient" for typing / editing, then I'd recommend you have a look at Visual SlickEdit (if you are the IDE type) and even then you will be light years behind what a modern IDE can do with a modern language.
- alok-g 15y ago
  Love it man! Thanks >> even then you will be light years behind what a modern IDE can do with a modern language Could you point me to one? Especially interested in high-performance ones.
forgotAgain 15y ago
By rot for example I mean not supporting WTL from within the tools development group. The only WTL tool that integrated into VS was developed by some guy in Eastern Europe. There was nothing from MS. As another example the largest software company in the world making tens of billions of dollars a year and they license a cheesy MFC widget library (in VS 2008 SP2?) instead of having internal resources to develop their own. I agree that VS is the best development tool but the MS development tool group supported C++ poorly from 1998 to 2010. It appears that it is changing but it has appeared that way several times but always it turned into a one shot deal with no follow through.
ldar15 15y ago
And if there is a language that is screaming out for an AMP equivalent its C#: it has structs for efficient memory organization. It has hands-off memory management, meaning that the GPU back-end can do it differently than a CPU back-end. It has attributes, meaning an easy way for you, the programmer, to provide hints to the back end, in a non-hack, already built-in kind of way.

ldar15 15y ago

I agree with your conclusion (suffering for lack of modern native code development) but disagree with your solution. C# still has the potential to be vastly superior to C++ for "native" development. The problem is that they spent the last 10 years working exclusively on neat features like LINQ instead of something that they promised back in 2002. I wish I had a link to the article, but back in 2002 I read an article from one of the C# leads stating that, unlike C++, the CLR would be able to do processor specific optimizations at code generation time. It also talked about inline functions, and that it didnt matter that C# didnt have an inline keyword because of course the JITter would do that automatically. Roll on 2011, and my lovely Matrix44.Multiply(Vector4[] foo) neither inlines the internal Matrix44.Multiply(Vector4 bar) nor does it SIMD any of it even if I inline it myself. Ditto for Matrix34.Multiply(ArrayOfStructs baz). Then there are the kind of performance guided global optimizations that you could do with a language like C#, using data-driven compilers, or manual-driven attributes. Memory management, for example, could be class/struct specific giving those classes performance as good as any C++ custom memory management (e.g. pools), while allowing initial development to proceed rapidly. Sadly, none of this came to pass. If anyone wanted to hire me to work at a games company it would be on the condition that the first thing I got to do was write a C# toolset that did exactly this. (Funnily enough, nobody has hired me, but the idea of scrabbling in the just-post-punch-card shit that is C++ is enough to discourage me from dropping the requirement).

kenjackson 15y ago
Roll on 2011, and my lovely Matrix44.Multiply(Vector4[] foo) neither inlines the internal Matrix44.Multiply(Vector4 bar) nor does it SIMD any of it even if I inline it myself. Ditto for Matrix34.Multiply(ArrayOfStructs baz). The CLR does inline, but it has restrictions that you're probably hitting. But it doesn't do processor specific opts. That does suck. Then there are the kind of performance guided global optimizations that you could do with a language like C#, using data-driven compilers, or manual-driven attributes. The CLR does have a profile based optimization system, but according to this article, it is internal-only. http://msdn.microsoft.com/en-us/magazine/dd569747.aspx http://msdn.microsoft.com/en-us/magazine/dd569747.aspx Oh well.
- 15y ago