Yes, the world has evolved.
Printable View
There is no such thing as a low power language because whether a language runs as compiled or interpreted is not a property of the language itself. All languages can be run both as compiled or interpreted.
Furthermore, there are interpretators that effectively run compiled native code. They're called Just-In-Time (JIT) compilers and this is how both the Java Virtual Machine (JVM) and the Common Language Runtime (CLR) of .NET work.
https://en.wikipedia.org/wiki/Just-in-time_compilation
It means today all major languages are effectively compiled. For general applications it's no longer possible to claim that a compiled C++ program will perform better than the same program written in another language that runs on the JVM or the CLR. This is also why C++ is under pressure. It can no longer pull rank when it comes to efficiency. Other factors jump to the foreground when it's decided which language to use.
Thanks wolle. Do any of you guys have experience with C++/CLI? Apparently it's a set of extensions which allow C++ code to be compiled to run under CLR and .NET (rather than being platform specific) and it's effectively a replacement for the now deprecated Managed C++.
I'm guessing there must be limitations (maybe all the supporting DLLs need to use C++/CLI too?)
Have a look at https://www.codeproject.com/articles...han-10-minutes
Also see this thread http://forums.codeguru.com/showthrea...to-learn-c-cli
Yes I evaluated C++/CLI for use in a new application many years ago as an alternative to C#. The idea was that it would allow me to write a proper Windows application for example using WPF for a GUI while still writing the internal core stuff in portable standard C++.
The problem at that time was that almost no one seemed to be using C++/CLI. There wasn't much info about the language, not many examples, no developer community and no clear info about the direction of the language, so I decided against the idea.
But it seems Microsoft is still supporting C++/CLI actively. This is the most recent info I could find,
https://msft.today/the-future-of-c-cli-and-net-core-3/
(Warning. Kaspersky told me this site is unsafe but I took a chance since it's Microsoft after all)
I would carefully analyze every word in this article with a magnifying glass and make sure I fully understood every implication before committing to C++/CLI.
Thank you so much for the commenters. IT really clear my all doubts.
Incidentally... I discovered recently that msbuild projects can now be configured to use a compiler called Clang, as an alternative to Visual C++. Clang allows compiling for both Windows & Linux, though there's no OS-X support yet AFAIK.
So it looks like Microsoft is finally making a serious effort at cross-platform support for C++ (it's just taken VC++ out of the picture...)
I've tried some preliminary experiments with Visual Studio + Clang and they seemed to work very will together. :thumb: I haven't yet established if the same .vcxproj files are usable with both Windows & Linux (tho' that'd be a big plus if it's possible!!)
Clang, VS, GCC et al support for the various C++ versions differ. For details see https://en.cppreference.com/w/cpp/compiler_support
Incidentally? I mentioned this in post #15 already.
I think Microsoft slowly has realized that trying to keep developers loyal by locking them in is an increasingly bad idea. Promoting the use of CMake and Clang with Visual Studio would've been unthinkable just a couple of years ago. Now this is happening and I'm sure more is coming.
Oops - this conversation ended up getting split between various different threads (so it's been hard to keep track of who said what...)
Yes I hope so... back in it's heyday, MSVC was easily the world's best C++ compiler but its lack of cross-platform support ended up putting a massive dent in its reputation. Introducing support for Clang (even if it's only on Linux initially) is an important step in the right direction - but to get back to its previous reputation, Visual Studio will need to add further C++ support for building on MacOS (and not sticking with just Linux).
Let's just hope that Microsoft has managed to figure that out !!
Eh, VS has supported cross platform development since at least since 2017 (can't remember if also 2015 had it).
I work more or less 100% with embedded software but I remember that a full installation made it possible to develop for "all" platforms, it even contained emulators for them. Since the app world isn't my world I didn't try it out though but according to other people you have to have a Mac on your network to be able to build for iOS and as I understand it's because of Apple requirements.
I did try to build (with gcc) and debug on an embedded target though and that worked pretty alright. The eclipse based debuggers I've encountered sucks for embedded C++ but with VS you get the expected behaviour. Since C++ works for embedded targets I don't understand why it shouldn't be supported for other development?
The only thing I find disappointing is that the project isn't setup the same way as a windows application, instead it's with some json files. I would have preferred it to be just the same as having both win32 & win64 targets in a solution.
Gosh, that really is a disappointment... over the Christmas period I've been creating a bootable USB stick so I can boot my PC into Linux. My intention was to install VS on it and see how the Linux version compares to the Windows one that I'm familiar with. And I must admit, I'd also hoped that sln files and vcxproj files would work for both platforms. If the build system is different for each platform, that's a pretty big drawback... :(
Oh, maybe I was a bit unclear regarding this. :(
There's no Linux version of VS, you just install the cross platform tools. After the installation you will have both a VS compiler and gcc (and also clang if you select that). I haven't tried using a compiler installation outside VS yet but I think that will work just as well. To debug a Linux application you run ssh to another machine. Maybe even WSL can be used but so far I haven't tried that. To debug on an embedded target you use for instance OpenOCD.
Yep, the json is a disappointment and I hope that MS change their mind in the future.