But marketing-wise or politically, where's the advantage to Microsoft in VC++ NOT supporting the other platforms? Like I've said elsewhere, it just makes it impossible any more to recommend VC++ as a serious development tool.
Printable View
But marketing-wise or politically, where's the advantage to Microsoft in VC++ NOT supporting the other platforms? Like I've said elsewhere, it just makes it impossible any more to recommend VC++ as a serious development tool.
Something just occurred to me this morning...
VC++ does seem intrinsically tied to other Microsoft technologies (such as MFC and Windows Forms) and obviously that wouldn't translate well to the non-Windows platforms. It occurred to me that maybe that's the reason why VC++ is getting left behind.
And yet they've managed to adapt Visual Basic so that it'll target other platforms... Doesn't Visual Basic have similar tie-ins?
That's because of .net which is available for other platforms - and Visual Basic .net uses .net. They haven't adapted VB as such. C++/cli was MS attempt for c++ xplatform as it used .net.Quote:
And yet they've managed to adapt Visual Basic so that it'll target other platforms... Doesn't Visual Basic have similar tie-ins?
VB.Net is a different language than the older VB6 like varieties. About the only thing VB.Net has in common with VB6 is some of the syntax, everything else is different.
So VB.Net isn't a good example here.
From what I understand, a reason for coding in C++/CLI is for C++/CLI code to be able to interact with C/C++ code and be exposed as a .Net assembly (in order for it to be consumed by other .Net assemblies and/or COM clients).
If this is the main reason, rather than going C++/CLI, I would put my C/C++ code inside a dll and call the dll inside a C# .Net assembly using pinvoke. That way, you can have the code written in C/C++ utilized and get the benefits of coding in a .Net tailored language like C#.
Quite frankly working in C# is so much easier - UI, database interaction, xml/json manipulation, working with classes, syntactical suger, the list goes on and on.
I spent many years coding in C++, and in my personal view, I am more productive and have way more options available coding in C#.
Btw, another option to coding a Forms UI application is to use WPF (I don't know if it is C# or VB.Net only).
It's cool because UI elements are described using a declarative syntax called xaml. Xaml defines the visual elements and the elements get bound to the data through a model (that's my 25 cent explaination anyway).
Now consider a simple app that has a button and when you click on the button, it plays a video that is displayed in the button.
Imagine how you would code this with C++ MFC or some other C++ UI framework?
In C# in a WPF app, it's about 10 lines of xaml.
Not that anyone has a need to play a video inside a button, but the difference in the lines of code between approaches is astounding.
[Post re C# moved to C-Sharp forum http://forums.codeguru.com/showthrea...ow-to-learn-c]
So after a lengthy discussion on the C# forum it feels like we've come full circle with this. The bottom line (with Visual Studio) is that there's no way to build a C++ app for anything other than Windows. Cross-platform builds are supported for other languages (C#, F# and Visual Basic) but not for C++.
Which begs the question... where's the benefit in making a move to C++/CLI ? Yes, it supports .NET but it doesn't support .NET Core which is a massive limit to its usefulness. .NET Core seems to be the key to preventing Visual C++ from descending into a legacy language.
Visual C++ devs need a credible cross-platform alternative to gcc. But just like us, MS seems to be going in circles and getting nowhere... :cry:
I must admit I'd be very reluctant to start any new project using Visual C++ - but for legacy projects it'd be nice to have a better cross-platform solution than gcc.